Categorie archief: Deployment

[Rancher] cattle-cluster-agent kan niet verbinden

Geplaatst op door

Op een downstream K3s cluster kan de cattle-cluster-agent niet verbinden met de rancher-server. oorzaak is de DNS-record die niet gevonden kan worden. Een log van de pod geeft de volgende foutmelding:

ERROR: https://rancher.digitalinfo.nl/ping is not accessible (Could not resolve host: rancher.digitalinfo.nl)

Dit kan opgelost worden door de deployment aan te passen en er een dnsConfig in aan te passen. Deze wordt dan alsvolgt:

dnsConfig:
  nameservers:
  - 8.8.8.8
dnsPolicy: None

Hierna worden de Pods ververst en zal de rancher server gevonden worden via de Google DNS server (8.8.8.8). Voorwaarde is uiteraard wel dat je jouw rancher DNS-record geregistreerd hebt in een externe DNS server.

Forceer een Kubernetes Deployment re-deploy

Geplaatst op door

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] Forceer een Deployment re-deploy

Geplaatst op door

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!

Chaos in Kubenetes

Geplaatst op door

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] Chaos in Kubenetes

Geplaatst op door

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 →

Update GitLab

Geplaatst op door

Al een tijdje stond in de GUI van GitLab de melding:

dus het volgende commando ingegeven:

sudo yum install -y gitlab-ce

Hierna verscheen de melding:

gitlab preinstall: Your version of PostgreSQL is no longer supported. Please upgrade your PostgreSQL version.
gitlab preinstall: Check https://docs.gitlab.com/omnibus/update/#updating-gitlab-10-0-or-newer for details.

Dus… eerst PostgreSQL updaten:

sudo gitlab-ctl pg-upgrade

en daarna de GitLab update zelf:

sudo yum install -y gitlab-ce

Hierna is GitLab nu versie 8.17.2 vervangen door versie10.5.4!