Storage-Attached Indexing (SAI) is Cassandra's modern approach to secondary indexing. It promises efficient queries on non-partition-key columns without the scaling problems of legacy secondary indexes. But SAI has boundaries — and when your query crosses them, Cassandra can end up performing slower than if the index didn't exist at all.

This post walks through how SAI works under the hood, when it can be used, and when Cassandra bypasses it entirely — even when your WHERE clause references a SAI-indexed column.

If you've ever needed to test multi-cluster Kubernetes features locally -- things like service mesh federation, cross-cluster service discovery, or multi-cluster networking -- you've probably hit the same wall I did: pods in one Kind cluster can't talk to pods in another. Their IPs are trapped inside their respective Docker containers with no route between them.

This post covers how to solve that by creating a flat network where any pod in any cluster can reach any other pod by IP.

When would you need this?​

You'd reach for this setup when:

• Testing multi-cluster service meshes (Istio, Linkerd, Cilium) locally before deploying to real infrastructure
• Developing cross-cluster controllers that need direct pod-to-pod communication
• Reproducing multi-cluster networking bugs in a lightweight local environment
• Validating flat-network assumptions before committing to a CNI or network topology in production

If your use case also needs cross-cluster DNS resolution (pods addressing services by name across clusters), skip ahead to the Cilium recommendation below. If you just need IP-level reachability, the native routing approach will get you there with zero extra dependencies.

Istio handles mTLS beautifully when you're routing traffic through Kubernetes services. You flip on strict mode, everything keeps working, and you go home happy. But the moment you need to address pods directly by IP -- say, for cross-cluster communication over a flat network -- things get weird. Strict mTLS breaks in ways that are surprisingly hard to debug.

This post walks through that exact scenario: how to get Istio's mTLS working when your traffic targets pod IPs instead of service names.

When would you need this?​

If you're addressing pods by IP rather than by service name, this post is for you. Common scenarios:

• Multi-cluster with a flat network -- pods are routable by IP across clusters, but you don't have shared DNS or a common service registry. You can't just curl my-service.namespace because that service doesn't exist in the calling cluster.
• ServiceEntry + WorkloadEntry patterns -- you're grouping remote pod IPs under a logical hostname using Istio primitives, essentially building your own cross-cluster service discovery.
• Migrating workloads off-cluster -- VMs or legacy pods that need to participate in the mesh but aren't behind a Kubernetes Service.

In all these cases, Istio doesn't have a native Service object to associate with the destination pod. And that's where strict mTLS falls apart, because Istio relies on that association to know the destination's identity.

The short version: your WorkloadEntry needs a serviceAccount field, and your ServiceEntry needs the correct subjectAltNames. Keep reading for the full debugging story.