Production networking and ingress — the cluster's connectivity

A cluster that routes traffic in a lab needs five more things before it carries production: a CNI that actually enforces policy, CoreDNS sized and spread so that one node cannot take resolution with it, default-deny NetworkPolicy with explicit allows, an Ingress or Gateway API implementation in front of it, and cert-manager issuing and renewing TLS so that nobody has to remember to. Each covers a failure the others cannot: a missing NetworkPolicy is invisible until an audit finds it, and an expired certificate is an outage scheduled months in advance. The stack below is built in that order, and every component in it has to justify its place.

The production networking

The production networking is the cluster’s connectivity. The production networking is composed of:

• CNI (Cilium / Calico). The cluster’s network.
• CoreDNS (2 replicas). The cluster’s DNS.
• NetworkPolicy: Default-deny + explicit allow.
• Ingress / Gateway API. The cluster’s external routing.
• cert-manager (TLS). The cluster’s TLS.

flowchart TB
    subgraph N["Networking"]
        CNI["CNI (Cilium)"]
        DNS["CoreDNS (2x)"]
        NLP["NetworkPolicy"]
    end
    subgraph IW["Ingress"]
        ING["Ingress / Gateway API"]
        TLS["cert-manager"]
    end
    CNI --> DP["eBPF datapath"]
    DNS --> PODS["Pod DNS"]
    NLP --> DEFAULT["default-deny"]
    NLP --> EXPLICIT["explicit allow"]
    ING --> TLS
    TLS --> CERT["Let's Encrypt"]

The production networking is the cluster’s connectivity.

The CNI

The CNI is the cluster’s network. The CNI is composed of:

• Cilium or Calico. The CNI plugin.
• eBPF or iptables. The datapath.

flowchart LR
    A[Pod] --> B[CNI plugin]
    B --> C[eBPF / iptables]
    C --> D[Node network]

The CNI is the cluster’s network.

The CoreDNS

The CoreDNS is the cluster’s DNS. The CoreDNS is composed of 2 replicas for HA.

flowchart LR
    A[Pod] --> B[resolv.conf]
    B --> C[kube-dns Service]
    C --> D[CoreDNS-01]
    C --> E[CoreDNS-02]

The CoreDNS is the cluster’s DNS.

The NetworkPolicy

The NetworkPolicy is the cluster’s network isolation. The NetworkPolicy is default-deny + explicit allow.

# Default-deny
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

The NetworkPolicy is the cluster’s network isolation.

The Ingress

The Ingress is the cluster’s external routing. The Ingress (or Gateway API) is composed of:

• Ingress Controller. The cluster’s external routing. (e.g., NGINX, Traefik).
• TLS. The cluster’s TLS.

flowchart LR
    A[External] --> B[Ingress Controller]
    B --> C[Service]
    C --> D[Pod]

The Ingress is the cluster’s external routing.

The cert-manager

The cert-manager is the cluster’s TLS. The cert-manager is composed of:

• cert-manager. The cluster’s TLS.
• Let’s Encrypt. The cluster’s certificate authority.

flowchart LR
    A[Ingress] --> B[cert-manager]
    B --> C[Let's Encrypt]

The cert-manager is the cluster’s TLS.

The deployment

The deployment is the canonical production networking deployment:

# 1. Install the CNI
helm install cilium cilium/cilium --namespace kube-system

# 2. Install the CoreDNS (HA)
helm install coredns coredns/coredns --namespace kube-system --set replicas=2

# 3. Apply the NetworkPolicy
kubectl apply -f default-deny.yaml

# 4. Install the Ingress
helm install ingress-nginx ingress-nginx/ingress-nginx --namespace ingress-nginx

# 5. Install the cert-manager
helm install cert-manager jetstack/cert-manager --namespace cert-manager

The deployment is the production networking.

The production discipline

The production networking is the cluster’s hypothesis. The discipline is to walk the 11-step methodology applied to the production networking, identify the cause, apply the remediation. The cluster’s discipline is the same scale-free: every component is justified.

Quiz

Production discipline

• Walk the 11-step methodology. The methodology is the diagnostic.
• Identify the gaps. The gaps are the cluster’s missing components.
• Deploy the production networking. The deployment is the cluster’s recovery.
• Verify the networking. The verification is the cluster’s evidence.
• Document the networking. The runbook is the cluster’s reference.