Maar er is altijd de Container Runtime Interface (CRI) die ervoor zorgt dat de images die gemaakt zijn met docker kunnen (blijven) werken in een Kubernetes cluster.
Dus, waar gaat dit dan over?
Lees verderCategoriearchief: Kubernetes
[K8S] Efficiente workloads
De efficientie van workloads worden voor een groot deel bepaald door de gebruikte resource-requests en resource-limits. Hoe dichter deze bij elkaar liggen, hoe efficienter de workload is. Het gevaar is echter dat met opstarten van een workload vaak meer CPU en memory gebruikt wordt en deze dient dan wel onder de resource-limit te blijven. Voor wat betreft memory-limit-overschrijding zal de pod opnieuw gestart worden door een Out-Of-Memory (OOM) event en overschrijding van het CPU-Limiet leidt tot CPU-trothling wat vertragingen in CPU time veroorzaakt. Voor beide limieten geldt uiteraard dat deze de Rancher-project resource-quota niet kan overschrijden en de node waarop de workload staat dient uiteraard de noodzakelijke CPU en Memory te kunnen leveren.
[K8S] ugrade via RKE
Het cluster dat ik in gebruik heb is aangemaakt met RKE (Rancher Kubernetes Engine) via een cluster.yml bestand en het commando ‘rke up‘ Zie hier de beschrijving. Nu is de versie die gebruikt wordt voor Kubernets v1.17.5 en ik wil nu upgraden naar versie 1.18.6. De versies die ondersteund worden vind je hier.
Om dit te doen met rke, dient de volgende regel in de cluster.yml file gezet te worden:
kubernetes_version: v1.18.6-rancher1-1
en vervolgens de upgrade starten met:
$ rke up
Eén voor één zullen de nodes nu ge-upgrade worden, eerst in ‘Cordoned‘ status, dan upgraden…
en vervolgens weer in ‘Active‘ status met de nieuwe versie.
Hoe simpel kan het zijn… 😉
[K8S] Forceer een Deployment re-deploy
Soms wil je een re-deploy doen van de pods in een Kubernetes deployment.
Er is geen nieuwe versie van de image dus een ‘set image’ is hier dan niet van toepassing.
Het opschalen met ‘scale’ up en dan weer down geeft geen garantie dat de nieuwe pods blijven draaien. Ook wil je geen onderbreking in de bereikbaarheid van de deployment dus schalen naar 0 is geen optie (de strategy zal het wellicht ook niet toestaan).
Dus de enige optie is een ‘redeploy label‘ in de deployment patchen en dat ziet er alsvolgt uit:
$ kubectl -n your-namespace patch deployment your-deployment -p "{\"spec\": {\"template\": {\"metadata\": { \"labels\": { \"redeploy\": \"$(date +%s)\"}}}}}"
Als je een watch op de pods zet zie je de nieuwe pods ge-deployed worden.
$ kubectl get pods -w
Have fun!
[K8S] deployment zonder code
Rancher is een populair beheersprogramma voor Kubernetes clusters. Ook kan met de Rancher Server GUI een nieuwe deployment uitgerold worden zonder dat er ook maar één regel yaml-code hoeft te worden geschreven. Hoe? Kijk hier maar voor een voorbeeld!
[K8S] Chaos in Kubenetes
Kubernetes maakt gebruik van deployments waarmee pods (daar waar de containers in zitten) herstart kunnen worden als zij vastlopen, teveel computer resources gebruiken, of een updated versie krijgen, enz. Dat is de kracht van K8S!
Maar kan elke applicatie er wel tegen om opnieuw ge-deployed te worden? Wat als er niets aan de hand is en de applicatie pas na lange tijd gaat herstarten? Bij NetFlix dachten de engineers in 2011 dat er een applicatie moest komen die applicaties willekeurig, expres, gaat herstarten, en ze noemden dit ‘Chaos Monkey‘.
Lees verder[K8S] Namespace blijft hangen op Terminating
Dan is dit wellicht de oplossing:
$ kubectl cluster-info Kubernetes master is running at https://localhost:6443 KubeDNS is running at https://localhost:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.Lees verder