Linux Foundation Certified Kubernetes Network Engineer

The CNI specification is how a runtime asks a plugin to wire up a pod. You see how a plugin is called, install and configure one, and compare overlay, routed and eBPF-based designs against what a cluster needs.

• The CNI contract: ADD, DEL and CHECK
• Where plugin binaries and configuration live on a node
• Installing a CNI plugin on a new cluster
• Chaining plugins and plugin order
• Overlay, routed and eBPF datapaths compared
• Migrating between plugins: what to plan for

You build The same cluster built twice with different CNI plugins, with a comparison of their datapaths.

Running out of addresses is a slow failure you can see coming. You plan pod, service and node ranges, understand how nodes receive their slices of the cluster range, and handle dual-stack and growth.

• Pod, service and node address ranges
• How nodes are allocated pod CIDRs
• IPAM modes in common CNI plugins
• Sizing ranges for growth
• IPv4, IPv6 and dual-stack clusters
• Diagnosing address exhaustion and overlap

You build An addressing plan for a multi-cluster estate, checked for overlaps and room to grow.

Some workloads need a second network for storage, telemetry or packet processing. You attach extra interfaces with Multus, define additional networks, and see how routing and policy treat them.

• Why a pod needs more than one interface
• Multus and the network attachment definition
• Secondary network types: macvlan, ipvlan and bridge
• Addressing and routes on secondary interfaces
• Policy and secondary interfaces: what is covered
• Verifying interfaces from inside the pod

You build A pod attached to the cluster network and a secondary network, with routing verified from inside it.

When a connection fails, the answer is in the packets. You use ip, ss, conntrack, iptables, nftables and tcpdump to see where traffic is dropped, rewritten or misrouted, and enter a pod’s namespace to look from its side.

• Reading routes, addresses and neighbors with ip
• Capturing traffic with tcpdump and reading the output
• Listing and tracing iptables and nftables rules
• Connection tracking and NAT state
• Entering a pod namespace with nsenter
• MTU, fragmentation and why large packets fail
• A method for isolating a connectivity fault

You build A troubleshooting playbook with captures for five failure types, each traced to the rule or route at fault.

Services give pods stable addresses, and kube-proxy or its replacement makes them real. You trace a service address to a backend, compare proxy modes and replacements, and control source addresses and traffic locality.

• ClusterIP, NodePort and LoadBalancer in the datapath
• kube-proxy modes and what each programs
• Replacing kube-proxy with an eBPF datapath
• External traffic policy and source IP preservation
• Session affinity and endpoint slices
• Headless services and direct pod addressing

You build A traced path for one service request, showing each translation from service address to pod.

Names are how services find each other, and DNS faults look like everything else. You read and change the Corefile, tune search domains and ndots, forward to outside resolvers, and debug slow or failing lookups.

• How service and pod names resolve
• The Corefile and its plugins
• Search domains, ndots and extra lookups
• Stub domains and forwarding to upstream resolvers
• Caching, scaling and node-local DNS caches
• Debugging DNS from a pod

You build A customized CoreDNS configuration with split-horizon forwarding and a test for each rule.

The Gateway API separates the people who run gateways from the people who route through them. You define classes, gateways and routes, split traffic by header and weight, and delegate safely across namespaces.

• GatewayClass, Gateway and route roles
• HTTPRoute matching on host, path and header
• Weighted splits and request mirroring
• Cross-namespace routes and reference grants
• TLS listeners and passthrough
• Status conditions: why a route is not accepted

You build A shared gateway with team-owned routes, weighted rollouts and TLS.

Larger platforms push traffic beyond one cluster and one direction. You pin egress to known addresses, discover and balance services across clusters, advertise networks with BGP, and route long-lived, uneven language model requests.

• Egress gateways and stable source addresses
• Advertising pod and service networks with BGP
• Cross-cluster service discovery
• Load-balancing algorithms and their trade-offs
• Routing language model traffic: streams and uneven cost
• Failover between clusters

You build Two clusters sharing a service, with egress through a fixed address and a tested failover.

A flat network is an open door. You write network policies that default to deny, encrypt traffic between nodes and between pods, issue certificates for gateways, and give each workload an identity that peers can verify.

• Network policy design: default deny and allow lists
• Extended policy models in CNI plugins
• Node-to-node encryption with WireGuard or IPsec
• Pod-to-pod mutual TLS
• Certificates for Gateway listeners with cert-manager
• Workload identity and authenticating pods

You build A segmented set of namespaces with encrypted traffic, verified peers and policies tested from both sides.

You cannot fix a network you cannot see. You collect metrics on drops, latency and errors, trace requests end to end, and log traffic flows so that an audit or an incident review has facts to work from.

• Network metrics from nodes, CNI and proxies
• Dropped packets, retransmits and latency signals
• Flow logs and what they record
• Distributed tracing across services and gateways
• Dashboards and alerts for network health
• Using logs to audit who talked to whom

You build A network dashboard and alert set, and a flow-log query that reconstructs one incident.

Design the network for a multi-team cluster, then diagnose faults planted in it. You choose the datapath, plan addresses, set up services, DNS, gateways and security, and trace each fault down to a packet.

• Choosing a datapath and an addressing plan
• Wiring services, DNS and gateways
• Applying policy and encryption
• Instrumenting the network
• Diagnosing five planted faults to packet level
• Documenting the design and its limits

You build A documented cluster network design with a fault log tracing each problem to the packet.