Categorie archief: Kubernetes

[ArgoCD] Repository Credentials

Geplaatst op door

Om niet elke keer bij het toevoegen van een repository in ArgoCD de credentials op te moeten geven, is het handig om Repository Credentials toe te voegen. Doe je dit bijvoorbeeld voor een groep genaamd ‘argocd’ dan hoef je geen credentials meer op te geven bij het toevoegen van een repository in deze groep.

Op de commandline:

argocd repocreds add https://gitlab.com/argocd --username user --password password

Hierbij is het password bijvoorbeeld het ‘Impersonation token‘ van deze gebruiker die je via Admin -> Users -> de gebruiker -> Impersonation Tokens kunt zetten met (tenminste) ‘read_repository‘ rechten.

Repositories in deze groep kunnen dan toegevoegd worden met:

argocd repo add https://gitlab.com/argocd/voorbeeld.git

[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.

[K8s] NFS Provisioner

Geplaatst op door

Binnen Kubernetes bestaat de mogelijkheid om PVC’s aan te maken op NFS-shares. Dit kan door een PV aan te maken met type NFS, maar het kan ook dynamisch met een NFS Provisioner.

Gebruik Helm om de repo toe te voegen en installeer de NFS Provisioner met Helm.

Lees verder →

[K8S] Efficiente workloads

Geplaatst op door

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.

Kubernetes ugrade via RKE

Geplaatst op door

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] ugrade via RKE

Geplaatst op door

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… 😉

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!