Stop Exposing NodePorts to the World

If I see one more NodePort exposed directly to the public internet on a production cluster, I might just unplug the rack myself. Kubernetes networking is deceptively simple until it isn't. You start with a Service, maybe an Ingress, and everything pings. Then traffic spikes during a Black Friday sale, or a DDOS attack hits from a botnet in the Pacific, and suddenly your iptables rules are eating 40% of your CPU.

I've spent the last decade debugging packet drops at 3 AM. In 2024, the landscape has shifted. We aren't just chaining iptables anymore; we are moving packets in the kernel with eBPF. For Norwegian businesses dealing with strict GDPR requirements and the need for low latency to customers in Oslo and Bergen, the standard "managed K8s" default settings are rarely enough. You need raw control.

The CNI Battlefield: Why eBPF is the Only Logical Choice

In the early days (think 2016), we used Flannel. It was simple, it created a VXLAN overlay, and it worked. But it was slow. Encapsulation overhead kills throughput. In October 2024, if you are building a high-performance cluster on CoolVDS, you should be looking at Cilium or Calico with eBPF mode enabled.

Why? Because iptables is a linked list. O(n) complexity. When you have 5,000 services, finding the right rule takes measurable time. eBPF (Extended Berkeley Packet Filter) uses a hash map. O(1) complexity. It's constant time, regardless of cluster size.

Here is how we deploy Cilium with strict kube-proxy replacement on our KVM-based instances:

helm install cilium cilium/cilium --version 1.16.1 \n  --namespace kube-system \n  --set kubeProxyReplacement=true \n  --set k8sServiceHost=${API_SERVER_IP} \n  --set k8sServicePort=${API_SERVER_PORT} \n  --set loadBalancer.mode=dsr

Notice the dsr (Direct Server Return) mode. This allows the backend pod to reply directly to the client without passing back through the load balancer node. On a network like ours, peered directly at NIX (Norwegian Internet Exchange), this shaves off vital milliseconds.

The Death of Ingress, The Rise of Gateway API

The standard Ingress resource was a mess of annotations. Nginx specific? HAProxy specific? It was chaos. As of late 2024, the Gateway API is the mature standard we rely on. It separates the role of the Cluster Operator (who manages the load balancer) from the Developer (who defines the routes).

Here is a production-ready HTTPRoute designed for a multi-tenant setup, common for agencies hosting multiple Norwegian e-commerce sites on a single CoolVDS cluster:

apiVersion: gateway.networking.k8s.io/v1\nkind: HTTPRoute\nmetadata:\n  name: store-route\n  namespace: production\nspec:\n  parentRefs:\n  - name: external-gateway\n  hostnames:\n  - "butikk.example.no"\n  rules:\n  - matches:\n    - path:\n        type: PathPrefix\n        value: /api/v2\n    filters:\n    - type: RequestHeaderModifier\n      requestHeaderModifier:\n        add:\n        - name: X-Region-Context\n          value: "no-osl-1"\n    backendRefs:\n    - name: api-service\n      port: 8080\n      weight: 90\n    - name: api-canary\n      port: 8080\n      weight: 10

This configuration handles canary deployments natively. No messy nginx config injection required.

Latency: The Norwegian Context

Physics is stubborn. Speed of light in fiber is finite. If your servers are in Frankfurt and your users are in Trondheim, you are adding 20-30ms of round-trip time (RTT) purely due to geography. For a database transaction requiring multiple round trips, that adds up to a sluggish UI.

Hosting on CoolVDS in Norway ensures your data stays within the jurisdiction of the Datatilsynet (Data Protection Authority) and keeps RTT to Norwegian ISPs under 5ms. We optimize our KVM host networking stack to pass packets to your VM with zero friction.

Pro Tip: Always check your MTU. The default 1500 is safe, but if you are running an overlay network on top of a VPS, the inner packet header adds overhead. If the outer packet fragments, performance tanks. On CoolVDS, we support Jumbo Frames where applicable, but setting your CNI MTU to 1450 is a safe bet to avoid fragmentation issues.

Security Policies: Deny by Default

Kubernetes allows all traffic between namespaces by default. This is insane. If one pod is compromised, the attacker can scan your entire internal network. We implement a "Zero Trust" model using NetworkPolicy.

Here is the baseline policy every single one of our clients should apply immediately:

apiVersion: networking.k8s.io/v1\nkind: NetworkPolicy\nmetadata:\n  name: default-deny-all\n  namespace: default\nspec:\n  podSelector: {}\n  policyTypes:\n  - Ingress\n  - Egress\n--- \napiVersion: networking.k8s.io/v1\nkind: NetworkPolicy\nmetadata:\n  name: allow-dns\n  namespace: default\nspec:\n  podSelector: {}\n  policyTypes:\n  - Egress\n  egress:\n  - to:\n    - namespaceSelector:\n        matchLabels:\n          kubernetes.io/metadata.name: kube-system\n    ports:\n    - protocol: UDP\n      port: 53\n    - protocol: TCP\n      port: 53

This locks down the namespace. Nothing gets in or out unless you explicitly whitelist it. It's harsh, but it's secure.

Debugging the Black Box

When packets disappear, kubectl logs won't save you. You need to get your hands dirty. We provide full root access on CoolVDS instances, meaning you can install the tools you actually need.

1. Check the routes inside the container:

2. Verify CNI status:

3. The Nuclear Option: nsenter

Sometimes you need to debug from the node's perspective but inside the pod's network namespace. nsenter is your best friend.

The Hardware Reality

Software defined networking is great, but it burns CPU cycles. If you are running a heavy K8s cluster on a budget VPS with "shared" vCPUs, your network latency will jitter uncontrollably because your neighbors are stealing your CPU time for packet processing. K8s networking is CPU-bound.

This is where CoolVDS differs. We don't oversubscribe our cores. When you push 5Gbps of traffic through an ingress controller, the CPU cycles are yours. We use VirtIO drivers that map directly to our NVMe storage and 10Gb network cards, reducing the hypervisor tax.

Final Thoughts

Kubernetes networking in 2024 is about precision. It's about moving from iptables to eBPF, from Ingress to Gateway API, and from "somewhere in the cloud" to "physically close to your users." Don't let network latency be the reason your application feels slow.

Spin up a high-performance node on CoolVDS today, install Cilium, and watch your latency drop.