Skip to content
Published on

Networking 2026 Complete Guide - Cilium, WireGuard, Tailscale, Nebula, Istio, Envoy, Cloudflare Tunnel Deep Dive

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

Intro — May 2026, networking has quietly standardized

Back in 2020 the K8s networking market was a free-for-all of 7~8 CNIs, "team VPN" meant enduring OpenVPN config hell, and adopting a service mesh was a death sentence labeled "200MB sidecar memory." As of May 2026, that landscape has changed almost entirely. Cilium has become the de facto K8s CNI standard, Tailscale has swept the small-to-mid team VPN segment, and Istio's ambient mode is finally production-ready, cutting sidecar memory overhead by more than half. WireGuard has been in the Linux mainline for six years, and QUIC + HTTP/3 are the default transport for CDN backbones.

This piece isn't about "which tool is good or bad." It's an honest look at who uses what, where, and how, as of May 2026. CNI, overlay VPN, service mesh, L7 gateway, ZTNA, IPv6/QUIC, and the operational realities in Korean and Japanese ISP environments — all covered.

The 2026 networking stack — broken into 6 layers

The big picture first. The standard 2026 production networking stack divides into these 6 layers.

  1. L2/L3 datapath: eBPF, XDP, tc, OVS, kernel netfilter, DPDK
  2. K8s CNI: Cilium, Calico, Antrea, Flannel
  3. Overlay VPN / mesh: WireGuard, Tailscale, Nebula, ZeroTier, Twingate, OpenZiti, Boundary
  4. Service mesh: Istio (ambient), Linkerd, Consul Connect, Kuma
  5. L7 proxy/gateway: Envoy, NGINX, HAProxy, Caddy 2, Traefik, KrakenD, Kong, Tyk
  6. Edge tunneling: Cloudflare Tunnel, ngrok, frp, localtunnel, Tunnelmole

Traditionally 12 was infra team, 34 was platform team, 5~6 was app/edge team. By 2026 those boundaries have blurred. Cilium targets 1, 2, and 4 at once (ServiceMesh mode). Tailscale dominates 3 and reaches into ZTNA (parts of 6). Below we walk through each layer.

Cilium — the de facto K8s CNI standard

Cilium became a CNCF Graduated project in 2024, and as of 2026 it holds the #1 K8s CNI adoption position. The core is the eBPF datapath. Because packets are handled by eBPF programs inside the kernel — not through iptables/netfilter chains — latency at 10k-service scale is less than half of iptables-based kube-proxy, and CPU drops by 30%+.

As of May 2026, the Cilium 1.16/1.17 lineup's key components are:

  • Cilium Agent: loads and manages eBPF programs on each node
  • Cilium Operator: cluster-wide state reconciliation
  • Hubble: L3~L7 flow visibility + metrics (also exports via OpenTelemetry)
  • Cilium ServiceMesh: sidecar-less mesh mode (Envoy shared per node)
  • ClusterMesh: multi-cluster service connectivity
  • Tetragon: eBPF-based runtime observability + enforcement

A typical Cilium NetworkPolicy looks like this.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-api-from-frontend
  namespace: prod
spec:
  endpointSelector:
    matchLabels:
      app: api
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: '8080'
              protocol: TCP
          rules:
            http:
              - method: GET
                path: /v1/.*
              - method: POST
                path: /v1/orders

This policy enforces not just L3/L4 but also L7 HTTP method + path inside eBPF. It never drops down to iptables like standard Calico mode. That's precisely Cilium's differentiator over other CNIs.

Cilium ServiceMesh — mesh without sidecars

A traditional service mesh (Istio 1.x sidecar mode, Linkerd) injects a sidecar proxy into every pod. 1000 pods means 1000 proxies eating RAM. Cilium ServiceMesh takes a different approach.

  • One Envoy per node as a shared instance (only for traffic that needs L7 policy)
  • L4 traffic handled directly by the eBPF datapath (including mTLS, with SPIFFE/SPIRE identity)
  • Sidecar mode also supported (for gradual migration)

In 2024~2025, Istio created ambient mode for the exact same reason. The market reached consensus that "sidecar overhead is no longer acceptable." Cilium had eBPF, so it could go one step further.

WireGuard — the new VPN baseline

Since WireGuard was mainlined into Linux 5.6 in 2020, by 2026 it has effectively become the base protocol for every VPN product. The ~400-line kernel module lightness, fixed cipher suite (ChaCha20/Poly1305/Curve25519), single UDP port, and node-key-based identity model are the essentials.

Manual configuration is this simple.

[Interface]
PrivateKey = SERVER_PRIVATE_KEY
Address = 10.10.0.1/24
ListenPort = 51820

[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.10.0.2/32
PersistentKeepalive = 25

WireGuard itself has no user management, NAT traversal, key distribution, or ACLs. That's its virtue of simplicity but also the reason "it's hard to use raw." The 2026 stack built on top of WireGuard:

  • Tailscale: WireGuard + coordinator (control plane) + ACL + DERP relay
  • Headscale: open-source reimplementation of the Tailscale control plane
  • boringtun: Cloudflare's Rust-based WireGuard userspace implementation
  • wireguard-go: official Go userspace implementation (covers Linux/macOS/Windows/iOS/Android)

Tailscale is the most successful commercial product among these. Headscale is picked by teams that need self-hosted control plane.

Tailscale + Headscale — how small teams forget VPN operations

Tailscale's value proposition is simple: don't operate a VPN gateway. Every node connects peer-to-peer, and the control plane (Tailscale.com) handles only key exchange and ACLs. For NAT traversal, DERP (Designated Encrypted Relay for Packets) acts as a fallback.

ACLs are written in HuJSON (JSON with comments).

{
  "groups": {
    "group:devs": ["alice@example.com", "bob@example.com"],
    "group:ops": ["carol@example.com"]
  },
  "tagOwners": {
    "tag:prod": ["group:ops"]
  },
  "acls": [
    {
      "action": "accept",
      "src": ["group:devs"],
      "dst": ["tag:prod:22", "tag:prod:443"]
    },
    {
      "action": "accept",
      "src": ["group:ops"],
      "dst": ["*:*"]
    }
  ],
  "ssh": [
    {
      "action": "check",
      "src": ["group:devs"],
      "dst": ["tag:prod"],
      "users": ["ubuntu", "root"]
    }
  ]
}

Tailscale SSH's "check" action requires Tailscale's own authentication on node access. It effectively bypasses SSH key distribution. Headscale accepts the same ACL format and operates as a self-hosted alternative.

Nebula, ZeroTier, Twingate, OpenZiti, Boundary — other mesh/ZTNA

If Tailscale emphasizes "managed control plane," Nebula is the opposite. Built by Slack for their own infrastructure and open-sourced in 2019, Nebula is a self-PKI + UDP mesh overlay. Identity is certificate-based, and "lighthouse" nodes assist NAT traversal. In 2024 the internal Slack team spun out as Defined Networking (defined.net) offering a managed form too. When government/large enterprise has a "no external control plane" requirement, self-hosted Nebula is the answer.

Other camps worth noting:

  • ZeroTier: P2P virtual Ethernet since 2014. Provides L2 emulation, useful for legacy broadcast-dependent apps.
  • Twingate: Managed ZTNA. Doesn't use WireGuard, has its own protocol. Clientless option is the strength.
  • OpenZiti: NetFoundry's full-OSS ZTNA. App SDK embed model (applications connect directly via the ziti SDK).
  • HashiCorp Boundary: VPN-less ZTNA. Integrates with Vault for credential brokering.

The selection criteria here are control plane hosting policy and clientless option availability. Government/regulated industries prefer self-hosted; SaaS startups prefer managed.

Service mesh 2026 — Istio ambient mode finally GA

Until 2024, the biggest objection to adopting a service mesh was "sidecars are too heavy." 50150MB RAM per pod, startup latency, debugging complexity. After Istio 1.221.24 in 2025, ambient mode went GA and that argument weakened.

Istio ambient's architecture:

  • ztunnel (zero-trust tunnel): one lightweight L4 mTLS proxy per node (replaces per-pod sidecars)
  • waypoint proxy (Envoy): one per namespace, only for traffic that needs L7 policy
  • Sidecar mode supported in parallel (for gradual migration)

An Istio AuthorizationPolicy example:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: api-allow-frontend
  namespace: prod
spec:
  selector:
    matchLabels:
      app: api
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ['cluster.local/ns/prod/sa/frontend']
      to:
        - operation:
            methods: ['GET', 'POST']
            paths: ['/v1/*']

principals is in SPIFFE ID form. It's automatically verified during the mTLS handshake.

Linkerd 2.16+ — "simplicity" as the weapon

Linkerd is intentionally smaller than Istio. It uses its own Rust proxy (linkerd2-proxy) and limits features to reduce operational burden. As of May 2026, Linkerd 2.16/2.17 has not adopted ambient-style multi-mode and sticks with the single sidecar model. It's CNCF Graduated, and license policy changes (Buoyant's tightened commercial licensing) became a 2024~2025 community issue.

Consul Connect, AWS App Mesh, OSM, Kuma

  • Consul Connect: HashiCorp. Integration with Vault/Nomad is the strength. Strong outside K8s for VM-environment mesh.
  • AWS App Mesh: Sunset announced in 2025. New adoption not recommended.
  • OSM (Open Service Mesh, Microsoft): Archived in 2023. Effectively deprecated.
  • Kuma: OSS mesh sponsored by Kong. Multi-zone model. Konnect/Mesh commercial available.

This area has effectively narrowed to a three-way race: Istio ambient vs Linkerd vs Cilium ServiceMesh.

eBPF networking — Cilium, Calico eBPF, Antrea eBPF, bpfilter

eBPF isn't just about being fast. The essential point is that packet processing finishes inside the kernel without userspace code. Among 2026 K8s CNIs offering eBPF modes:

  • Cilium: eBPF is the core. Uses XDP (driver stage), tc (traffic control), and sockops (socket fast path) all together.
  • Calico eBPF dataplane: Alternative to the existing iptables/IPVS mode. Can replace kube-proxy.
  • Antrea eBPF mode: Sponsored by VMware Tanzu. Partial eBPF acceleration on top of OVS.
  • bpfilter: Experimental iptables→eBPF translation layer in the Linux mainline. Gradually adopted in 2025 5.18+ kernels.

Cilium uses XDP because packets are handled at the NIC driver stage, avoiding SKB allocation cost altogether. Accelerating LoadBalancer/NodePort paths via XDP yields nearly 100x PPS on the same node.

L7 proxy comparison — Envoy, NGINX, HAProxy, Caddy 2, Traefik

The L7 proxy/gateway landscape in 2026:

  • Envoy: CNCF Graduated. The de facto data plane standard for service meshes. Adopted by Istio/Cilium/Consul.
  • NGINX: Still #1 for single-instance load balancing. Post-F5 acquisition split into OSS and NGINX Plus.
  • HAProxy: L4/L7 + broad protocol support. Still high adoption in fintech/banks.
  • Caddy 2: Web server with the smoothest ACME issuance/renewal in 2026. HTTP/3 enabled by default.
  • Traefik: K8s Ingress + Docker friendly. CRD-based IngressRoute is the strength.
  • KrakenD: API gateway specialty. Strong at multi-backend aggregation.
  • Tyk: API gateway + portal/analytics bundle. Enterprise license.
  • Kong Gateway: Both K8s and on-prem. Kong Ingress Controller (KIC) + Mesh (Kuma) bundle.

A small Envoy snippet (L7 routing + mTLS upstream):

static_resources:
  listeners:
    - name: ingress
      address:
        socket_address: { address: 0.0.0.0, port_value: 8443 }
      filter_chains:
        - filters:
            - name: envoy.filters.network.http_connection_manager
              typed_config:
                '@type': type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                stat_prefix: ingress_http
                route_config:
                  virtual_hosts:
                    - name: api
                      domains: ['api.example.com']
                      routes:
                        - match: { prefix: '/v1' }
                          route: { cluster: api_v1 }
  clusters:
    - name: api_v1
      connect_timeout: 0.5s
      type: STRICT_DNS
      load_assignment:
        cluster_name: api_v1
        endpoints:
          - lb_endpoints:
              - endpoint:
                  address:
                    socket_address: { address: api-v1.prod.svc.cluster.local, port_value: 8080 }
      transport_socket:
        name: envoy.transport_sockets.tls
        typed_config:
          '@type': type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext

Not many teams hand-write YAML like this. Most have a control plane (Istio/Cilium/Contour) auto-generate it.

Kubernetes Gateway API — the next-gen standard replacing Ingress

The Gateway API, which went 1.0 GA in 2024, has by 2026 become the de facto successor to Ingress. Key differences:

  • GatewayClass / Gateway / HTTPRoute / TCPRoute / GRPCRoute role separation
  • Permission split between infra team (Gateway) and app team (HTTPRoute)
  • Vendor-neutral + standardized traffic split, header matching, mirroring

A Gateway API HTTPRoute example:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
  namespace: prod
spec:
  parentRefs:
    - name: public-gateway
      namespace: infra
  hostnames: ['api.example.com']
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v1
      backendRefs:
        - name: api-v1
          port: 8080
          weight: 90
        - name: api-v2
          port: 8080
          weight: 10

Istio, Cilium, Envoy Gateway, NGINX, Kong, Traefik, and Contour all ship Gateway API implementations. Ingress still works in 2026, but new adoption is steered toward Gateway API.

QUIC + HTTP/3 — production reality in 2026

QUIC (RFC 9000) and HTTP/3 (RFC 9114) are by 2026 the default for CDN and mobile traffic. Cloudflare, Google, and Facebook serve 70~80% of traffic over HTTP/3. Four years after standardization, every modern browser supports them.

QUIC's advantages:

  • TLS 1.3 baked in (1-RTT handshake, 0-RTT resumption)
  • Avoids TCP head-of-line blocking (multiplexing over UDP)
  • Connection migration (sessions survive IP changes, useful for mobile)

But operational reality isn't easy.

  • Firewalls/load balancers may block UDP 443 or fail to deep-inspect it
  • L4 load balancer stickiness is hard (connection-ID based)
  • Kernel UDP fast path is less optimized than TCP (io_uring, UDP GSO/GRO arrived relatively recently)

As of May 2026 the recommendation is to enable HTTP/3 but always maintain HTTP/2 fallback. CDNs like Cloudflare handle this automatically. If you run Envoy/NGINX/Caddy yourself, you must advertise both h3 and h2 via ALPN and open UDP 443.

DNS-over-HTTPS / DNS-over-QUIC — privacy + censorship circumvention

DoH (RFC 8484) and DoQ (RFC 9250) are by 2026 default options in mobile OSes. iOS supports DoH via Private Relay; Android supports DoT/DoH via Private DNS settings. Two operational concerns matter:

  • Internal DNS policies can be bypassed: If a user's browser queries Cloudflare 1.1.1.1 directly, internal-domain split horizon fails. The solution is split-horizon DNS + DDR (Discovery of Designated Resolvers, RFC 9462).
  • Used as a censorship-circumvention tool: Government-level DoH blocking exists (parts of Russia, Iran). Korea and Japan don't block it.

In enterprise environments, the pattern of serving an internal resolver over DoH (AdGuard Home, Pi-hole + Cloudflared, NextDNS) has grown.

mTLS + ACME — the end of certificate automation in 2026

By 2026 mTLS has standardized in two directions. External traffic uses ACME (RFC 8555) -based Let's Encrypt + ZeroSSL for 90-day cert auto-issue/renew. Internal traffic uses SPIFFE/SPIRE (or Istio CA, Cilium ID) for auto-issued mTLS.

Caddy 2 handles ACME most seamlessly. A one-line config auto-issues certs.

api.example.com {
  reverse_proxy api.prod.svc.cluster.local:8080
  encode gzip zstd
  tls admin@example.com
}

Internal mTLS expresses workload identity in SPIFFE ID form (spiffe://cluster.local/ns/prod/sa/api). Istio, Cilium, and Consul are all SPIFFE-compatible.

Cloudflare Tunnel, ngrok, frp, localtunnel — edge tunnels

The 2026 pattern for exposing a service behind a firewall:

  • Cloudflare Tunnel (cloudflared): outbound tunnel from Cloudflare edge to origin. Even the free plan is powerful.
  • ngrok: #1 for demo/dev. Paid plans add managed domains/OAuth.
  • frp: open-source reverse proxy. Self-hosted ngrok alternative.
  • localtunnel: simplest npm-based tunnel. Throwaway testing.
  • Tunnelmole: similar to localtunnel but self-hostable.

A Cloudflare Tunnel config example:

tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef
credentials-file: /etc/cloudflared/6ff42ae2.json

ingress:
  - hostname: api.example.com
    service: http://localhost:8080
  - hostname: ssh.example.com
    service: ssh://localhost:22
  - service: http_status:404

Edge tunnels enable external access in environments without public IPs (home NAS, internal dev boxes, edge IoT). Combined with ZTNA, this becomes a VPN-less remote access model.

ZTNA matrix — Tailscale vs Cloudflare Zero Trust vs Twingate

ZTNA (Zero Trust Network Access) has settled as the model replacing VPN. Comparing the three representative solutions:

  • Tailscale: WireGuard-based mesh. Rich modules (SSH/Funnel/Subnet Router). Free plan for under 100 users.
  • Cloudflare Zero Trust (formerly Cloudflare for Teams): Uses Cloudflare edge. Bundles Access (web app SSO), Tunnel, and WARP client. Free up to 50 users.
  • Twingate: ZTNA pure-play. Clientless option, fine-grained per-resource ACL.

Selection criteria depends on the dominant use case.

  • Mesh between team nodes + SSH + file sharing-centric → Tailscale
  • Web app SSO + external exposure + WARP global PoP → Cloudflare Zero Trust
  • Fine-grained ACL + clientless emphasis → Twingate

IPv6 + CGNAT — the migration that didn't end in 2026

IPv6 was standardized in 1998, yet full migration is incomplete in 2026. As of May 2026, global IPv6 adoption hovers around 45%. In Korea, KT/SKT offer IPv6 dual-stack on parts of wireless, but wired remains dominated by IPv4 + NAT. Japan's IIJ/NTT have aggressively adopted IPv4 over IPv6 (MAP-E, DS-Lite).

CGNAT (Carrier-Grade NAT) is the two-tier NAT ISPs introduced to cope with the IPv4 exhaustion. Home routers receive private IPs in 100.64.0.0/10. The pain points:

  • Inbound port forwarding is impossible (hurts home server operators)
  • NAT traversal (UDP hole punching) is hard (impacts P2P games/comms)
  • User tracking via logs/security is harder (multiple users share the same public IP)

The fix is the IPv6 dual-stack + managed tunnel (Tailscale/Cloudflare Tunnel) combo. To expose a home NAS, Cloudflare Tunnel works behind CGNAT by routing via outbound connection.

BGP + Anycast — how the CDN backbone works

The core of a CDN (Cloudflare, Fastly, Akamai, Bunny, KeyCDN) is Anycast IP. The same IP advertised via BGP from hundreds of PoPs worldwide makes user packets route to the nearest PoP via BGP best-path. The results:

  • Geographic proximity becomes automatic, no DNS round-robin needed
  • DDoS gets distributed absorption (attack traffic spreads across PoPs)
  • Single PoP failure auto-routes via BGP reconvergence

For Anycast to work, you need an AS (Autonomous System) number and IP block registration. You get these from RIPE/ARIN/APNIC. Typical SaaS doesn't need to do this directly — they rent a CDN.

SD-WAN + ZTNA convergence — the state of SASE

Since 2020 the term SASE (Secure Access Service Edge) has bundled SD-WAN + ZTNA + SWG (Secure Web Gateway) + CASB. As of 2026 the representative vendors in this space:

  • Cloudflare (Cloudflare One): Zero Trust + Magic WAN + Gateway bundle
  • Zscaler: ZIA (internet access) + ZPA (private access) + Posture
  • Cisco (Cisco+ Secure Connect, Meraki + Umbrella + Duo): managed integration
  • Palo Alto Prisma Access: enterprise SASE
  • Netskope: SSE pure-play

The OSS/self-hosted camp builds similar outcomes with Tailscale + Cloudflare Tunnel + internal IdP + DoH resolver. The price drops to roughly 1/10.

Korea/Japan ISP context — KT/LG U+/SKT, NTT/IIJ/SoftBank

Useful things to know when operating networking in Korea and Japan. Korea offers some dual-stack on wireless, but wired remains dominated by IPv4 + NAT. Japan is far ahead on IPv6 adoption.

  • KT (AS4766): Korea's largest backbone. Many international links. Home plans 100M~10G.
  • LG U+ (AS3786): Strong in media/IDC. Partial IDC partnerships with NHN/Kakao.
  • SKT/SK Broadband (AS9318): #1 wireless. Wired is SK Broadband.
  • NTT Communications (AS4713): Japan's largest backbone. Global Tier-1.
  • IIJ (AS2497): Leader in IPv6/MAP-E. Strong in enterprise.
  • SoftBank (AS17676): Mobile and wired simultaneously. Integrated with Yahoo Japan.
  • KDDI/au (AS2516): Japan mobile + wired. Partners with WIRELESS CITY PLANNING.

Korea→Japan/US RTT is 3040ms, Japan→US West is around 100120ms. Korea has the special factor of the government integrated network (national IT communications network) policy. Japan's IPv6 IPoE adoption via NTT is so widespread that home users routinely receive IPv6 prefix delegation. As a result, running a home server with custom domain + IPv6 + dynamic DNS is more common in Japan than in Korea.

Comparison matrix — pick a tool by use case

A summary table:

  • K8s CNI: Cilium (default), Calico (conservative ops), Antrea (VMware environments), Flannel (legacy)
  • Team VPN: Tailscale (SaaS), Headscale (self-hosted), Nebula (self PKI), manual WireGuard (special cases)
  • Service mesh: Istio ambient (full features), Linkerd (simplicity), Cilium ServiceMesh (eBPF integration), Consul Connect (HashiCorp stack)
  • L7 gateway: Envoy Gateway/Istio (mesh-integrated), NGINX/HAProxy (traditional), Caddy 2 (#1 for ACME automation), Kong/Traefik (K8s Ingress)
  • Edge tunnel: Cloudflare Tunnel (production), ngrok (demo), frp (self-hosted)
  • ZTNA: Tailscale (node mesh), Cloudflare Zero Trust (web apps + mesh), Twingate (clientless), OpenZiti (app SDK)

The criteria are always the same: integration with the existing stack, operational headcount, self-hosting mandates, and license policy.

Security context — threats still alive in 2026

Security issues specific to the networking tools themselves are worth noting.

  • WireGuard key compromise: keys are plain files, so node compromise is immediate breach. Without automated key rotation, the risk is real.
  • Cilium eBPF privileges: CAP_BPF + CAP_NET_ADMIN are required. Node compromise gives broad kernel visibility.
  • Istio CA compromise: every workload identity in the cluster can be forged. HSM/Vault backend is recommended.
  • Cloudflare Tunnel tokens: token equals trust. Secrets Manager + regular rotation is mandatory.
  • DoH/DoQ bypass: if clients escape to external DoH, internal logging has blind spots. DDR + policy enforcement needed.

Many 2026 breaches start with identity loss (keys, tokens, certs). The essence is ID management, not network ACLs.

Wrap-up — recommended stack as of May 2026

Finally, the "if starting a new company today" recommendation.

  • K8s CNI: Cilium 1.16+. Enable eBPF + ServiceMesh from the start.
  • Team VPN/ZTNA: Tailscale (or self-hosted Headscale). Cloudflare Tunnel as auxiliary for external exposure.
  • Service mesh: If you already have Cilium ServiceMesh, use that. If a separate path is required, Istio ambient.
  • L7 gateway: Envoy Gateway or Istio + Gateway API. Standalone: Caddy 2.
  • DNS: internal DoH resolver (AdGuard Home/Pi-hole/NextDNS) + Cloudflare 1.1.1.1.
  • Certificates: external = Let's Encrypt + Caddy/cert-manager. Internal = SPIFFE/SPIRE or mesh-integrated.
  • Monitoring: Hubble (Cilium) + Prometheus + Grafana + OpenTelemetry.

This combo scales almost as-is from a 10-person startup to 1000-person scale. The essence of 2026 networking is the combination of "battle-tested OSS + one or two managed control planes." The era of self-operating OpenVPN is over.

References

Discuss on Twitter • View on GitHub