Kubernetes - Networking
- "IP-per-pod" model: each
Pod
has a unique IP; aPod
is equivalent to a VM or a host (which have unique IPs). Pods can be load-balanced. - Containers within a Pod use networking to communicate via loopback. Container to container: use
localhost
. - Pods can communicate with all other pods on any other node without NAT.
- Agents on a node (e.g. system daemons, kubelet) can communicate with all pods on that node.
- Isolation (restricting what each pod can communicate with) is defined using
NetworkPolicy
. Network policies are implemented by the network (CNI) plugins. - Upper Networking: kubernetes defined networking.
- pod to internet traffic needs to go through a NAT Gateway.
Kubernetes Networking
There are two components to networking.
- Kubernetes cluster networking, i.e., pod-to-pod connectivity, or "data plane". Can be provided by bundling Cilium (eBPF based programmable dataplane) (run Cilium in overlay mode if you do not require L2 connectivity between all nodes or an SDN).
- L4 load balancing: can be provided by bundling MetalLB.
Kubernetes Engine clusters are provisioned with an IP range that is automatically determined during cluster creation, in an existing project subnet.
CNI
Since Kubernetes 1.24, management of the CNI is no longer in scope for kubelet
. CNI plugins are managed by a Container Runtime (e.g. containerd).
CNI is used by container runtimes: The container/pod initially has no network interface. CNI is used so the pods can accept traffic directly, which keeps network latency as low as possible.
CNI flow:
- When the container runtime expects to perform network operations on a container,
kubelet
calls the CNI plugin with the desired command. - The container runtime also provides related network configuration and container-specific data to the plugin.
- The CNI plugin performs the required operations and reports the result.
https://github.com/containernetworking/cni
Implementations
- Flannel and Weavenet: easy setup and configuration.
- Calico: better for performance since it uses an underlay network through BGP.
- Cilium: utilizes a completely different application-layer filtering model through BPF and is more geared towards enterprise security. Can replace kube-proxy (with iptables). eBPF is superior to iptables.
GKE Dataplane V2 migrated from Calico (Calico CNI and Calico Network Policies, rely heavily on IPtables functionality in the Linux kernel, IPtables provide a flexible, but not programmable datapath that enables K8s networking functions) to a programmable datapath. based on eBPF/Cilium.
anetd
is the networking controller, which replaces calico-*
and kube-proxy-*
pods. anetd
/cilium holds metadata (network policies, configured k8s services and their endpoints) and accounts metrics (conntrack entries, dropped, forwarded traffic) related to all networking in the nodes.
DNS
Every Service
and Pod
defined in the cluster (including the DNS server itself) is assigned a DNS name. You can contact Service
s with consistent DNS names instead of IP addresses.
Since kubeadm
v1.24, the only supported cluster DNS application is CoreDNS
. (Support for kube-dns
was removed.)
Load Balancing
- L4 Load Balancer: should support TCP/UDP loadbalancing and high availability. It should work in a world where nodes are in different L2 subnets. E.g.
- metalLB for workloads.
- keepalived + haproxy for control plane nodes.
- L7 Load Balancer: e.g. via Istio ingress gateway
SNMP
Get metrics from the network switches
snmp-exporter
to expose the SNMP data to Prometheus.
SNMP is a known resource hog.
Gateway
https://gateway-api.sigs.k8s.io/
(Ingress api version 2)
The Gateway API is a SIG-Network project being built to improve and standardize service networking in Kubernetes.
https://istio.io/latest/blog/2022/gateway-api-beta/
Gateway
=> VirtualService
=> Service
apiVersion: networking.istio.io/v1beta1
kind: Gateway
Gateway=proxy=load balancer
Gateway describes a load balancer operating at the edge of the mesh receiving incoming or outgoing HTTP/TCP connections.
Defines exposed ports and protocols
Every Gateway
is backed by a Service
of type LoadBalancer
.
VirtualService
configure the L7 LoadBalancing or reverse proxy, split traffic e.g. if uri prefix is /api/
, go to service 1, if /
go to service 2.
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
A VirtualService
can be bound to a gateway to control the forwarding of traffic arriving at a particular host or gateway port.
Dualstack
k8s dualstack: both ipv4 and ipv6: https://kubernetes.io/docs/concepts/services-networking/dual-stack/