← Engineering Blog
PlatformYAMLNetwork Modes2026-07-10 · 6 min

Configuring MeshAtom Network Modes with Namespace Annotations

How Platform Architects toggle CNI Replacement, Overlay, Passthrough, and Strict mTLS via a single namespace annotation — no CRDs required.

MeshAtom keeps configuration where Kubernetes operators already look: the namespace object. Instead of introducing custom CRDs or a cluster-scoped control plane, Platform Architects select a dynamic network mode with one annotation. The namespace-bound DaemonSet agent watches that annotation and hot-reloads eBPF programs accordingly.

The annotation contract

All four modes are selected through meshatom.io/network-mode. Valid values are cni-replacement, cni-overlay, passthrough, and strict-mtls. Optional companion annotations tune encryption and wake-on-request behavior without leaving the namespace.

Namespace annotated for Plug-and-Play CNI Overlay

apiVersion: v1
kind: Namespace
metadata:
  name: payments
  annotations:
    # Required: select one of the four dynamic network modes
    meshatom.io/network-mode: "cni-overlay"

    # Optional: encryption policy layered on top of the mode
    # flex | strict | pass  (mode-specific defaults apply if omitted)
    meshatom.io/encryption: "strict"

    # Optional: enable Smart Scale-to-Zero for idle workloads
    meshatom.io/scale-to-zero: "enabled"

Mode reference

1. Native CNI Replacement

annotations:
  meshatom.io/network-mode: "cni-replacement"

MeshAtom owns routing and identity-based mTLS in the kernel data path (tc / XDP). Use this when you want full-stack autonomy and the lowest latency — no Flannel/Calico encapsulation tax.

2. Plug-and-Play CNI Overlay

annotations:
  meshatom.io/network-mode: "cni-overlay"
  meshatom.io/encryption: "strict"

Runs on top of AWS-VPC CNI, Azure CNI, Calico, or any existing CNI. Encryption and policy run before the underlying CNI encapsulates packets, so you get enterprise mTLS without a CNI migration.

3. Smart Local Passthrough

annotations:
  meshatom.io/network-mode: "passthrough"

Same-node pod traffic bypasses the encryption pipeline via eBPF topology maps. Cross-node traffic still gets bidirectional mTLS. Ideal for dense nodes where co-located chatter dominates CPU.

4. Strict Pod-to-Pod mTLS

annotations:
  meshatom.io/network-mode: "strict-mtls"
  meshatom.io/encryption: "strict"

Every packet leaving a pod boundary is signed and encrypted in-kernel — including same-node traffic. Target this for PCI-DSS / HIPAA style isolation.

Rolling a mode change safely

Because MeshAtom is namespace-scoped, flipping an annotation only reloads eBPF programs for that namespace. Dev can move from cni-overlay to strict-mtls without touching Production.

Hot-switch mode on a single namespace

kubectl annotate namespace payments \
  meshatom.io/network-mode=strict-mtls --overwrite

# Agent reconciles within seconds — no DaemonSet restart required
kubectl -n payments get events --field-selector reason=MeshAtomModeReload
No CRDs. No cluster-admin. Mode selection is a namespace annotation your existing GitOps pipeline can already manage.