‘Ter lering ende vermaeck‘ wil ik in mijn on-premise Rancher Management clusters een Azure K8s cluster toevoegen. Om dat te doen is een ‘Cloud Credential‘ nodig voor Azure. Er zijn gratis trial subscriptions mogelijk voor Azure en daar maak ik dan ook gebruik van: https://azure.microsoft.com/nl-nl/free/
Lees verder[K8s] NFS Provisioner
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[Proxmox] NFS share toevoegen aan VM
Op een NFS server (NAS, Storage Sever, etc..) worden NFS shares aangemaakt die via een NFS client gemount kunnen worden in een VM. Met Proxmox kunnen de NFS shares gemount worden op de pve en dan gebruikt worden als extra disk aan een VM. Op zich vrij eenvoudig, hier een beknopte uitleg.
Lees verder[K8S] Docker afgeschaft vanaf v1.20
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 verder[K8S] cgroup driver naar systemd
Volgens https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/ dient het aanbeveling om ‘systemd‘ te gebruiken als driver voor cgroups. Dit komt de stabiliteit van docker ten goede. Vóór Kubernetes versie 1.21 is de standaard nog om hier ‘cgroupfs’ voor te gebruiken maar aangezien kubeadm systemd gebruikt om kubelet aan te sturen is dit nu de nieuwe standaard en de default vanaf v1.21.
Lees verder[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.
[Ubuntu] disk resize ‘on-the-fly’
Via Proxmox (of VMWare) is een extra disk toegevoegd aan een VM. Deze disk is in de VM de tweede disk, dus ‘/dev/sdb‘ en deze is 100Gb. Nu willen we deze uitbreiden met 20Gb echter zonder downtime van de VM, met andere woorden: ‘on the fly’.
Binnen Proxmox kan de disk groter gemaakt worden, dus die maken we 120G.
Lees verder[RPi] Gebruik system-LED voor functie
Mijn Raspberry Pi Kubernetes Cluster bestaat uit 3 nodes: 1 master (Control Plane en ETCD) en 2 workers. Een extra Raspberry Pi dient als Reverse-Proxy. Om in één oogopslag te zien welke Raspberry Pi welke role heeft, gebruik ik hiervoor de system-board LED’s.
Lees verder[Proxmox] Disk vervangen door SSD
Zeker met virtualisatie geldt: “hoe sneller de disk hoe beter” en daarom ga ik een langzame HDD disk vervangen door een snelle(re) SSD disk. Als eerste de aansluitingen controleren…
Lees verder[Rancher] Continuous Delivery eenvoudiger in v2.5
In Rancher 2.5 is nu standaard Fleet opgenomen om Multi-Cluster beheer eenvoudiger te maken voor wat betreft Continuous Delivery. Lees dit artikel voor meer informatie en een tweetal voorbeelden om apps uit te rollen.
[Rundeck] CentOS8 accepteert geen OpenSSH keys
De ssh-keys gegenereerd met ssh-keygen wordt standaard aangemaakt in het OpenSSH formaat. Dit zie je terug aan de eerste en laatste regel in het certificaat:
-----BEGIN OPENSSH PRIVATE KEY----- ... -----END OPENSSH PRIVATE KEY-----
Voor ssh-sessies naar andere hosts is dit prima, maar Rundeck (versie 3.3.4) geeft een foutmelding bij connecties naar andere hosts.
De oorzaak ligt in het feit dat het OpenSSH-formaat niet werkt en er een RSA_formaat wordt verwacht. Met het volgende commando kun je een bestaand OpenSSH formaat key omzetten naar een RSA-formaat:
$ ssh-keygen -p -m PEM -f id_rsa
De -p optie geeft de optie om een nieuw bestand te maken, de -m optie geeft aan dat dit dan in het PEM-formaat (RSA) dient te zijn, de -f is de ‘oude’ OpenSSH key.
De eerste en laatste regels geven weer dat het formaat nu RSA is:
-----BEGIN RSA PRIVATE KEY----- ... -----END RSA PRIVATE KEY-----
Rundeck zal deze RSA-key nu wel kunnen gebruiken en de connecties komen tot stand.
Rundeck op CentOS8 accepteert geen OpenSSH keys
De ssh-keys gegenereerd met ssh-keygen wordt standaard aangemaakt in het OpenSSH formaat. Dit zie je terug aan de eerste en laatste regel in het certificaat:
-----BEGIN OPENSSH PRIVATE KEY----- ... -----END OPENSSH PRIVATE KEY-----
Voor ssh-sessies naar andere hosts is dit prima, maar Rundeck (versie 3.3.4) geeft een foutmelding bij connecties naar andere hosts:
De oorzaak ligt in het feit dat het OpenSSH-formaat niet werkt en er een RSA_formaat wordt verwacht. Met het volgende commando kun je een bestaand OpenSSH formaat key omzetten naar een RSA-formaat:
$ ssh-keygen -p -m PEM -f id_rsa
De -p optie geeft de optie om een nieuw bestand te maken, de -m optie geeft aan dat dit dan in het PEM-formaat (RSA) dient te zijn, de -f is de ‘oude’ OpenSSH key.
De eerste en laatste regels geven weer dat het formaat nu RSA is:
-----BEGIN RSA PRIVATE KEY----- ... -----END RSA PRIVATE KEY-----
Rundeck zal deze RSA-key nu wel kunnen gebruiken en de connecties komen tot stand.