Advanced

Kubernetes is ontworpen om zelf-herstellend te zijn, maar wat betekent dat eigenlijk? En belangrijker: wat gebeurt er als de componenten die het herstel doen zelf falen? Ik heb Kubernetes clusters door allerlei failures heen geleid — gepland, ongepland, en “hold my beer” experimenten. Hier is wat er daadwerkelijk gebeurt als dingen kapot gaan. De Componenten Die Kunnen Falen Voordat we in failure scenario’s duiken, laten we uitzetten waarmee we werken: ...

Als er iets misgaat in Kubernetes, is het vaak etcd. API server timeout? Check etcd. Pods stuck in pending? Misschien etcd. Cluster voelt traag? Waarschijnlijk etcd. Toch behandelen de meeste Kubernetes operators etcd als een black box. Het is gewoon “de database” die naast het control plane draait. Maar etcd begrijpen maakt je dramatisch beter in Kubernetes operaties. Laat me je meenemen naar binnen. Wat is etcd? etcd is een gedistribueerde key-value store. Zie het als een zeer betrouwbaar woordenboek waar meerdere servers het over eens zijn. Kubernetes gebruikt het om alle cluster state op te slaan: elke pod, deployment, secret, configmap en custom resource leeft in etcd. ...

Toen ik voor het eerst een “productie” Kubernetes cluster opzette, had ik één control plane node. Het werkte prima totdat het niet meer werkte — een kapotte disk haalde het hele cluster neer. Elke pod, elke service, alles. Die dag leerde me wat “single point of failure” echt betekent. Kubernetes High Availability is niet optioneel voor productie. Maar er is een keuze die veel mensen in verwarring brengt: draai je etcd op je control plane nodes (stacked), of op aparte dedicated nodes (external)? Laat me beide benaderingen uitleggen. ...