Kubernetes kann einem ganz schön auf die Nerven gehen!
Wenn alles gut ist, ist alles gut. Über den Sinn eines Setups macht man sich in den letzten Jahren sowieso kaum noch Gedanken. Aber Spaß an der Arbeit hat man - manchmal.
Wie dem auch sei, man schlägt sich ganz schön auf die Füße, wenn man nicht ALLES, was einem auf die Füße fallen könnte, vorher eingrenzt und deklariert. Auf einem meiner Cluster hatte ich den Fall, dass durch ein kaputtes Deployment so viele evicted Pods hinzukamen, dass keine neuen Pods mehr gestartet werden konnten.
Schnelle Abhilfe schafft hier folgendes Kommando:
kubectl delete pods --field-selector status.phase=Failed -ALetztens hatte ich eine halbwegs interessante Aufgabe: Ein bereits getätigtes Deployment in einem Kubernetes Cluster soll um die eigene Konfiguration erweitert werden. Dabei wird einem jedoch nicht die Möglichkeiet gegeben eine eigene Configmap oder sowas zu definieren.
Was kann man in einem solchen Fall tun? Wir können nun ganz stumpf die vorhandene Configmap kopieren, mit unseren Werten ergänzen und das Original überschreiben.
Kann man machen, ist dann halt kacke!
Auf diese Weise kriegen wir natürlich keine Updates von dem Deployment mit, sofern welche eingespielt werden. Was geht also noch?
Patchen!
Geil - ich kann den Teil der YAML nachbauen, den ich ergänzt/gepatcht haben will und diesen dann einfach mit kubectl drauf hauen - damit die die vorhandene Resource nur... gepatcht und nicht überschrieben!
kubectl patch configmap MYFANCYCONFIGMAP -n K8SNAMESPACE --patch-file./PATCHFILE.yamlIch bin begeistert!
Auch wenn es mir manchmal so scheint, als wäre es nicht mehr üblich, so versuche ich die Software in meinem Lager aktuell zu halten. Allein schon um mir keine Sorgen machen zu müssen, wenn es mal in Richtung Sicherheit geht.
Bei so Funky-Software-Products wie Kubernetes ist es um so wichtiger - ansonsten hat man richtig Arbeit, wenn es mal wirklich sein muss.
In vorausgesetzt man hat genug Platz auf / kann man auf einem CentOS wie folgt ein Upgrade von zum Beispiel 1.13.x auf 1.14.x durchführen:
yum clean all
yum makecache
yum list --showduplicates kubeadm --disableexcludes=kubernetes
**Hier sucht man sich die aktuellste Version heraus**
yum install -y kubeadm-**1.14.1-0** --disableexcludes=kubernetes
kubeadm upgrade plan
**Nun bekommt man gesagt, was man tun muss**
kubeadm upgrade apply v1.14.1
systemctl daemon-reload
systemctl restart kubeletWenn man dann irgendwann
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.14.1". Enjoy!
auf dem Schirm hat ist schon die Hälfte gewonnen. Mal sollte nun natürlich noch schauen, dass man seine restlichen Komponenten aktuell hält:
yum install -y kubelet-1.14.1-0 kubectl-1.14.1-0 --disableexcludes=kubernetesJetzt geht es weiter bei den Minions.
yum clean all
yum makecache
yum install -y kubeadm-1.14.1-0 --disableexcludes=kubernetes
kubeadm upgrade node config --kubelet-version v1.14.1
yum install -y kubelet-1.14.1-0 kubectl-1.14.x-0 --disableexcludes=kubernetes
systemctl daemon-reload
systemctl restart kubeletKontrolle ist besser als Vertrauen. Daher auf einem Knoten das folgende Kommando ausführen:
kubectl get nodes
und hoffen das nirgends ein NotReady steht... Ansonsten ist dann wohl alles getan.
Wenn man mehrer Knoten hat und keinen Bock verspürt ein Ansible Skript zu bauen, dann kann man super ClusterSSH nutzen und sich ein bischen mehr wie ein Operator fühlen.
Quellen und Links: