Nice article ;) > The number of rules may be large, which may be problematic for certain traffic forwarding implementations (iptables linearly evaluates every

Nice article ;) > The number of rules may be large, which may be problematic for certain traffic forwarding implementations (iptables linearly evaluates every rule) Kube proxy also supports ipvs out of the box, and some CNI (like Cilium) can also replace kube proxy and rely on eBPF. > When a Pod is moved to another node, the traffic will be forwarded twice until the old DNS entry expires Not sure to understand this one. On a standard setup what happens is: - Pod A is running on a node, receiving traffic from a service - The pod is stopped by kubelet (that send a SIGTERM to it). - The pod should gracefully shutdown. During the shutdown phase, only _existing_ connections are forwarded to the stopping pod, new ones will be already forwarded elsewhere. - If the pod stops before the terminationGracePeriodSeconds duration (default 30s), everything is fine. Else, the pod is killed by kubelet. So it's developers that should make sure pods handle signals correctly. "Misbehaving clients (eg: ones that do not re-resolve DNS before reconnecting) will continue to work" => the services IP is stable so clients don't need to re-resolve. > Why does it not matter if the state is unstable? If I'm operating a cluster that can't settle, I'd like to know immediately! Kubernetes exposes a lot of metrics, on the control plane components or kubelet, usually using the Prometheus format. Look for example at the metrics exposed by kube state metrics: https://github.com/kubernetes/kube-state-metrics/tree/main/docs/metrics https://github.com/kubernetes/kube-state-metrics/tree/main/d... With controllers metrics + kube state metrics about most Kubernetes resources, you can easily build alerts when a resource fails to reconcile. > Basically, Horizontal Pod Autoscaler but with sensors which are not just "CPU" Take a look at KEDA, it's exactly this: https://keda.sh/ https://keda.sh/ It "extends" the autoscaler capabilities. If you're running Prometheus you can for example scale on any metric that is stored in Prometheus (and so exposed by your application/infrastructure components: queue depth, latency, request rate...). Kubernetes was built to be extended like this. Same for your question "Why are the storage and networking implementations "out of tree" (CNI / CSI)?", to my experience support is very good today on various cloud providers or on premise infra components. Look at Karpenter for example, it's IMO a revolution in the Kubernetes node management world.