Kubespray Kubernetes-implementatie: Rocky Linux 9 en Cilium operationele gids

AI_Manager

Dit is een gids voor het implementeren van Kubernetes met Kubespray. We maken een reproduceerbaar cluster op Rocky Linux 9-nodes met behulp van Kubespray en Ansible, en implementeren en valideren vervolgens 3 control planes, een etcd-quorum, een API VIP en het Cilium-netwerk. De focus ligt niet alleen op het uitvoeren van de commando’s, maar ook op het waarborgen van de weerbaarheid tegen storingen en het faciliteren van upgrades.

De Kubernetes 1.31.6-versie uit eerdere artikelen bereikte het einde van de ondersteuning in november 2025. Deze herziene versie is gebaseerd op Kubernetes 1.35.4 en de gebundelde Cilium 1.19.3, zoals geleverd in Kubespray 2.31.0 per juli 2026. Controleer echter vóór de daadwerkelijke implementatie altijd de checksum van de gekozen Kubespray-tag en de Kubernetes-compatibiliteitsmatrix van Cilium.

Versies en ondersteuningsbereik voor de Kubespray Kubernetes-implementatie

De nieuwste versie van Kubernetes betekent niet automatisch dat deze een gezamenlijk gevalideerde combinatie vormt met Kubespray en Cilium. Hoewel de nieuwste stabiele versie van Kubernetes in juli 2026 1.36.2 is, is de standaardwaarde van Kubespray 2.31.0 1.35.4. Controleer bovendien de gegarandeerde e2e-lijst in de stabiele documentatie van Cilium en valideer combinaties buiten deze lijst apart vóór ingebruikname.

Topologie van de Kubespray Kubernetes-implementatie

De API VIP moet niet uit één enkele HAProxy bestaan, maar uit ten minste twee proxy’s met VRRP of een bestaande load balancer. De 6443 health check van de VIP moet worden doorgestuurd naar de kube-apiserver van alle control planes. Zorg er bovendien voor dat de IP-planning definitief is vastgesteld, zodat de CIDR’s voor nodes, pods en services niet overlappen met interne netwerken, VPN’s of opslagnetwerken.

Naamresolutie en poortcontrole

getent hosts api.k8s.example.com cp01 cp02 cp03 wk01 wk02 wk03

for host in cp01 cp02 cp03 wk01 wk02 wk03; do
  printf '%-6s ' "$host"
  timeout 3 bash -c "</dev/tcp/${host}/22" && echo SSH_OK || echo SSH_FAIL
done

timeout 3 bash -c '</dev/tcp/api.k8s.example.com/6443'   && echo API_VIP_OK || echo API_VIP_FAIL

Kubespray Kubernetes-implementatie: Voorafgaande controle van Rocky Linux 9-nodes

Omdat Kubespray containerd, kubelet, kernelmodules en sysctl beheert, moeten er geen afzonderlijke installatiescripts vooraf worden uitgevoerd. Controleer in plaats daarvan op alle nodes het OS, de CPU, het geheugen, de schijf, cgroups, tijdsynchronisatie en eventuele sporen van bestaande container-runtimes.

cat /etc/rocky-release
uname -r
timedatectl status
free -h
lsblk -f
findmnt -no FSTYPE,OPTIONS / /var
stat -fc %T /sys/fs/cgroup
swapon --show
rpm -qa | grep -E 'kube(let|adm|ctl)|containerd|docker|cri-o' || true

Kubernetes 1.35 gaat standaard uit van cgroup v2. Vertrouw niet op omwegen voor cgroup v1, maar behoud de systemd cgroup v2-configuratie van Rocky Linux 9. Schakel SELinux en firewalld niet zomaar uit, maar verifieer de ondersteuningsmethode in de Kubespray-releasedocumentatie en de netwerk-ACL’s van uw organisatie.

Toegewezen beheerdersaccount en registratie van SSH-hostkeys

ssh-keygen -t ed25519 -a 100 -f ~/.ssh/kubespray_ed25519

for host in cp01 cp02 cp03 wk01 wk02 wk03; do
  ssh-copy-id -i ~/.ssh/kubespray_ed25519.pub "ansible@${host}"
  ssh-keyscan -H "$host" >> ~/.ssh/known_hosts.new
done

sort -u ~/.ssh/known_hosts.new >> ~/.ssh/known_hosts
rm -f ~/.ssh/known_hosts.new
chmod 0600 ~/.ssh/known_hosts

Vergelijk de resultaten van ssh-keyscan met de vingerafdrukken van een vertrouwde console of assetbeheersysteem voordat u ze registreert. Als u StrictHostKeyChecking uitschakelt, kunnen man-in-the-middle-aanvallen niet worden gedetecteerd. Geef het ansible-account alleen de noodzakelijke sudo-rechten en sta geen directe SSH-aanmeldingen voor root toe.

Kubespray Kubernetes-implementatie: Vastleggen van de 2.31.0-uitvoeringsomgeving

Zet de bestanden voor de Kubespray Kubernetes-implementatie vast op een release-tag in plaats van op de main-branch. Door een Python-omgeving en requirements.txt te gebruiken, kunt u dezelfde controleomgeving reproduceren zonder de systeem-Python en Ansible-afhankelijkheden te vermengen.

sudo dnf install -y git python3.12 python3.12-pip

git clone --branch v2.31.0 --depth 1   https://github.com/kubernetes-sigs/kubespray.git
cd kubespray
git verify-tag v2.31.0 || git show --show-signature --no-patch v2.31.0

python3.12 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install --requirement requirements.txt

python --version
ansible --version
git describe --tags --always

Git-handtekeningverificatie is alleen zinvol als de vertrouwde maintainer-sleutel via een afzonderlijk kanaal is gecontroleerd. In een afgesloten netwerk moeten de checksum en herkomst van het release-archief, de Python-wheel en de container-image in een verbonden netwerk worden geverifieerd voordat ze naar een goedgekeurde repository worden overgebracht.

Kubespray Kubernetes-implementatie: Inventory opstellen

inventory/prod/inventory.yml

cp -a inventory/sample inventory/prod
cat > inventory/prod/inventory.yml <<'YAML'
all:
  hosts:
    cp01: {ansible_host: 10.20.0.11, ip: 10.20.0.11, access_ip: 10.20.0.11}
    cp02: {ansible_host: 10.20.0.12, ip: 10.20.0.12, access_ip: 10.20.0.12}
    cp03: {ansible_host: 10.20.0.13, ip: 10.20.0.13, access_ip: 10.20.0.13}
    wk01: {ansible_host: 10.20.0.21, ip: 10.20.0.21, access_ip: 10.20.0.21}
    wk02: {ansible_host: 10.20.0.22, ip: 10.20.0.22, access_ip: 10.20.0.22}
    wk03: {ansible_host: 10.20.0.23, ip: 10.20.0.23, access_ip: 10.20.0.23}
  children:
    kube_control_plane:
      hosts: {cp01: {}, cp02: {}, cp03: {}}
    kube_node:
      hosts: {wk01: {}, wk02: {}, wk03: {}}
    etcd:
      hosts: {cp01: {}, cp02: {}, cp03: {}}
    k8s_cluster:
      children:
        kube_control_plane: {}
        kube_node: {}
    calico_rr:
      hosts: {}
YAML

Houd het aantal etcd-leden op een oneven getal. Definieer control plane en worker niet door elkaar; gebruik ansible_host voor het SSH-verbindingsadres en ip/access_ip voor het communicatieadres tussen nodes. Controleer bij NAT- of multi-NIC-omgevingen het geadverteerde adres en de routering afzonderlijk.

Open de volgende drie bestanden in een editor om de betreffende sleutels toe te voegen of bestaande waarden te wijzigen. Elk voorbeeld is YAML voor in het bestand, geen shell-commando.

Kernwaarden voor inventory/prod/group_vars/all/all.yml

ansible_user: ansible
ansible_ssh_private_key_file: ~/.ssh/kubespray_ed25519

loadbalancer_apiserver:
  address: 10.20.0.10
  port: 6443

kubeconfig_localhost: true
kubectl_localhost: true

Kubernetes en standaardbeveiligingsinstellingen

Voor kube_version en cilium_version in Kubespray v2.31.0 moet u numerieke versies zonder v-prefix gebruiken. Omdat Kubespray zelf een prefix toevoegt aan download-URL’s en container-tags, mag u deze niet invoeren zoals in v1.35.4. Wijzig de waarden in de voorbeeld-YAML naar de onderstaande waarden en voeg geen dubbele sleutels toe.

kube_version: 1.35.4
container_manager: containerd
kube_network_plugin: cilium

kube_service_addresses: 10.233.0.0/18
kube_pods_subnet: 10.233.64.0/18
cluster_name: cluster.local

kube_api_anonymous_auth: false
remove_anonymous_access: true
kubernetes_audit: true
supplementary_addresses_in_ssl_keys:
  - 10.20.0.10
  - api.k8s.example.com

De Pod- en Service-CIDR’s mogen absoluut niet overlappen met routers, VPN’s of datacenters. Het achteraf wijzigen van een CIDR die al in gebruik is, kan resulteren in een migratie naar een volledig nieuw cluster. Zorg dat de API VIP en DNS-naam zijn opgenomen in de SAN van het kube-apiserver-certificaat.

Cilium-overlay en Hubble-configuratie

cilium_version: 1.19.3
cilium_tunnel_mode: vxlan
cilium_identity_allocation_mode: crd
cilium_ipam_mode: kubernetes
cilium_cni_exclusive: true

cilium_enable_hubble: true
cilium_hubble_install: true
cilium_hubble_tls_generate: true
cilium_enable_hubble_ui: false

De kube-proxy replacement is geen eenvoudige prestatie-optie, maar een wijziging van het service-datapad. In deze basisgids behouden we kube-proxy. Als u de replacement gebruikt, moet u cilium_kube_proxy_replacement, API global endpoint, DSR/SNAT en de host-firewall afzonderlijk ontwerpen en onderwerpen aan belasting- en faaltesten.

Validatie vóór de implementatie van Kubespray Kubernetes

CIDR-conflicten en inventory-structuur

ip route
ip -4 address show

grep -R --line-number -E   'kube_(service_addresses|pods_subnet)|loadbalancer_apiserver|kube_version|cilium_version'   inventory/prod/group_vars

ansible-inventory -i inventory/prod/inventory.yml --graph
ansible-inventory -i inventory/prod/inventory.yml --list   > inventory/prod/inventory-expanded.json

Controle van SSH, sudo en Python

ansible -i inventory/prod/inventory.yml all -m ping
ansible -i inventory/prod/inventory.yml all --become   -m command -a 'id'
ansible -i inventory/prod/inventory.yml all --become   -m shell -a 'python3 --version; stat -fc %T /sys/fs/cgroup; swapon --show'

Alleen een succesvolle ping-module is niet voldoende. Controleer of become non-interactief werkt en of de Python-interpreter en cgroup v2 consistent zijn op alle nodes. Sla het Ansible Vault-wachtwoordbestand en de SSH-privésleutel niet op in de repository.

Review van playbook-syntaxis en wijzigingslijsten

ansible-playbook -i inventory/prod/inventory.yml   cluster.yml --syntax-check

git status --short
git diff -- inventory/prod/group_vars inventory/prod/inventory.yml

tar --exclude='credentials' --exclude='artifacts'   -czf "inventory-prod-$(date +%F).tgz" inventory/prod

Uitvoering van de Kubespray Kubernetes-implementatie

Voer niet vanaf het begin willekeurige tags uit op alle nodes. Voer de officiële cluster.yml uit met een gevalideerde inventory. Bij een fout moet u de initiële fouttaak en de status van de node controleren voordat u hetzelfde commando opnieuw uitvoert. Hoewel Kubespray streeft naar idempotentie, zijn externe load balancers en netwerken aparte entiteiten.

mkdir -p logs

ansible-playbook -i inventory/prod/inventory.yml   cluster.yml --become   2>&1 | tee "logs/cluster-$(date +%F-%H%M%S).log"

test ${PIPESTATUS[0]} -eq 0

Bij gebruik van tee kan de laatste exit-code van de shell die van tee zijn, dus controleer het resultaat van ansible-playbook met PIPESTATUS[0]. Omdat logs hostnamen, IP-adressen en taakresultaten kunnen bevatten, moet u toegangsrechten en bewaartermijnen vaststellen en gevoelige informatie verwijderen voordat u ze extern deelt.

Validatie van de resultaten van de Kubespray Kubernetes-implementatie

kubeconfig en control plane-eindpunt

find inventory/prod/artifacts -maxdepth 2 -type f -ls

install -d -m 0700 "$HOME/.kube"
install -m 0600 inventory/prod/artifacts/admin.conf "$HOME/.kube/config"

kubectl config view --minify
kubectl cluster-info
kubectl get --raw='/readyz?verbose'

De bestandsnaam van het artifact kan variëren afhankelijk van de gekozen Kubespray-tags en configuratie, dus controleer eerst de resultaten van find. Aangezien kubeconfig cluster-admin-referenties bevat, moet u deze niet in openbare homedirectories of CI-artifacts plaatsen; beheerders dienen OIDC en RBAC met minimale rechten te gebruiken.

Status van nodes, etcd en systeem-Pods

kubectl get nodes -o wide
kubectl get pods -A -o wide
kubectl get --raw='/livez?verbose'

ansible -i inventory/prod/inventory.yml etcd --become   -m command -a 'systemctl status etcd --no-pager'

kubectl -n kube-system get endpoints kube-dns
kubectl get events -A --sort-by='.lastTimestamp' | tail -n 50

Status van Cilium en Hubble

kubectl -n kube-system rollout status daemonset/cilium --timeout=10m
kubectl -n kube-system get pods -l k8s-app=cilium -o wide

cilium status --wait --wait-duration 10m
cilium connectivity test

kubectl -n kube-system get secret | grep -i hubble
kubectl -n kube-system logs deployment/hubble-relay --tail=100

De cilium connectivity test maakt meerdere namespaces en Pods aan, dus voer deze uit in een test-namespace die voldoet aan het operationele beleid en ruim deze na afloop op. Alle Cilium DaemonSets, operators, CoreDNS en service-routing op alle nodes moeten correct functioneren voordat u overgaat tot het implementeren van workloads.

Kubespray Kubernetes-implementatie: Validatie van workloads en NetworkPolicy

Smoke test voor implementatie, Service en DNS

kubectl create namespace smoke-test
kubectl -n smoke-test create deployment web   --image=registry.k8s.io/e2e-test-images/agnhost:2.53   -- /agnhost netexec --http-port=8080
kubectl -n smoke-test expose deployment web --port=80 --target-port=8080
kubectl -n smoke-test rollout status deployment/web --timeout=5m

kubectl -n smoke-test run client --rm -it --restart=Never   --image=docker.io/library/busybox:1.36.1 --command -- /bin/sh -c 'nslookup web; wget -qO- http://web/'

Standaard weigeren en vervolgens expliciet toestaan

cat <<'YAML' | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: web-default-deny
  namespace: smoke-test
spec:
  podSelector: {matchLabels: {app: web}}
  policyTypes: [Ingress]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: web-allow-client
  namespace: smoke-test
spec:
  podSelector: {matchLabels: {app: web}}
  policyTypes: [Ingress]
  ingress:
    - from:
        - podSelector: {matchLabels: {run: client}}
      ports:
        - {protocol: TCP, port: 8080}
YAML

kubectl -n smoke-test get networkpolicy

U moet het succes vóór beleidstoepassing, het falen na standaard weigeren en het succes na expliciete toestemming verifiëren. Als u ook DNS-egress beperkt, controleer dan de werkelijke selector van de kube-dns-service en UDP/TCP 53. Verwijder na de test de resources met kubectl delete namespace smoke-test.

etcd-snapshots en voorbereiding op herstel

Automatiseer etcd-snapshots direct na voltooiing van de Kubespray Kubernetes-implementatie. Maak de snapshot op één lid, kopieer deze naar een versleutelde opslag buiten het cluster en leg de herstelprocedure vast, inclusief inventory, certificaten en Kubespray-tags.

# Uitvoeren op één etcd-knooppunt met standaard host-implementatiemethode.
sudo systemctl cat etcd
sudo grep -E '^ETCD_(LISTEN_CLIENT_URLS|TRUSTED_CA_FILE|CERT_FILE|KEY_FILE)=' /etc/etcd.env

sudo bash -euo pipefail <<'BASH'
backup_dir=/var/backups/etcd
install -d -m 0700 "$backup_dir"
snapshot="$backup_dir/snapshot-$(date +%F-%H%M%S).db"
node_name=$(hostname -s)
ca=/etc/ssl/etcd/ssl/ca.pem
cert="/etc/ssl/etcd/ssl/admin-${node_name}.pem"
key="/etc/ssl/etcd/ssl/admin-${node_name}-key.pem"
for file in "$ca" "$cert" "$key"; do test -r "$file"; done
etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert="$ca" --cert="$cert" --key="$key" snapshot save "$snapshot"
etcdutl snapshot status "$snapshot" --write-out=table
BASH

In de standaard etcd_deployment_type: host wordt etcd uitgevoerd als een systemd-service. Controleer de werkelijke eindpunten en certificaatpaden in /etc/etcd.env en systemctl cat etcd en pas de waarden hierop aan. Als de inventory-hostnaam verschilt van de OS-hostnaam, pas dan ook de bestandsnaam van het admin-certificaat aan naar het werkelijke bestand. Test herstel niet in hetzelfde cluster, maar valideer periodiek het herstel van snapshots, het opstarten van de API en de objectintegriteit in een geïsoleerde omgeving.

Certificaten, audits en operationele controles

sudo kubeadm certs check-expiration
kubectl auth can-i --list
kubectl auth can-i create clusterrolebindings --as=system:anonymous

kubectl get --raw='/metrics' | grep -E   'apiserver_request_total|apiserver_request_duration_seconds' | head

kubectl get nodes -o json | jq -r   '.items[] | [.metadata.name,.status.nodeInfo.kubeletVersion,.status.nodeInfo.containerRuntimeVersion] | @tsv'

• Controleer of kubectl-verzoeken succesvol blijven wanneer een API VIP, DNS of een control plane-node wordt gestopt.
• Koppel etcd-leden, leader-status, DB-grootte en het succes van snapshots aan waarschuwingen.
• Monitor het bestandssysteem van de node, inodes, geheugendruk, PID-druk en de capaciteit van het image-bestandssysteem.
• Verzend auditlogs van de kube-apiserver naar een centrale opslag en pas beleid toe voor manipulatiepreventie en retentie.
• Verwijder de cluster-admin kubeconfig van dagelijkse accounts en gebruik OIDC, RBAC en korte sessies.
• Observeer Cilium-drops, beleidsoordelen, DNS-fouten en het verlopen van Hubble-certificaten.

Kubespray Kubernetes-upgrade

Verhoog de Kubernetes minor-versie stap voor stap en volg het version skew-beleid. Controleer eerst of de doel-Kubernetes-patch en de Cilium-versie aanwezig zijn in de checksum en ondersteuningslijst van de doel-Kubespray-tag. Controleer vervolgens etcd-snapshots, workload-back-ups, PodDisruptionBudget en beschikbare capaciteit.

git fetch --tags --prune
git tag --sort=-version:refname | head

# Kopieer de bestaande inventory in een nieuwe kloon/venv en beoordeel de verschillen.
git diff v2.31.0..'<TARGET_KUBESPRAY_TAG>' --   inventory/sample roles/kubespray_defaults docs

ansible-playbook -i inventory/prod/inventory.yml   upgrade-cluster.yml --become --syntax-check

ansible-playbook -i inventory/prod/inventory.yml   upgrade-cluster.yml --become   2>&1 | tee "logs/upgrade-$(date +%F-%H%M%S).log"

test ${PIPESTATUS[0]} -eq 0

Lees de dringende upgrade-opmerkingen van de nieuwe release voordat u upgrade-cluster.yml uitvoert. Let in het bijzonder op Kubespray 2.31 met betrekking tot cgroup v1, de beëindigde ingress-nginx, de gearchiveerde Kubernetes Dashboard, etcd-voorloopversies en verwijderde variabelen. Start de control plane en workers niet allemaal tegelijk opnieuw op.

Veelvoorkomende fouten en veilige alternatieven

Checklist voor Kubespray Kubernetes-implementatie

1. Kubespray-tags en Python/Ansible-requirements zijn vastgezet.
2. Ondersteuningsdocumentatie voor de combinatie van Kubernetes, Cilium en containerd is gecontroleerd.
3. 3 control plane/etcd-nodes en meerdere API-load balancers zijn voorbereid.
4. CIDR-bereiken voor Pods, Services, nodes, VPN en opslag overlappen niet.
5. SSH-hostkeys, sudo-bereik en de opslag van Vault en privésleutels zijn geverifieerd.
6. Connectiviteit van nodes, API, CoreDNS en Cilium, evenals NetworkPolicy, zijn getest.
7. etcd-snapshots worden extern opgeslagen en hersteltrainingen in isolatie zijn voltooid.
8. Monitoring van certificaatverloop, auditlogs, resource pressure en Cilium-drops is ingesteld.
9. Vóór upgrades worden urgente opmerkingen, version skew, PDB’s en beschikbare capaciteit beoordeeld.

Gerelateerde bronnen

• Officiële Kubespray v2.31.0 release
• Officiële Kubernetes-releases en ondersteuningsperioden
• Officiële Kubernetes version skew-policy
• Officiële Kubernetes-compatibiliteitsvereisten voor Cilium
• Gids voor Ansible-playbooks, Vault en rolling deployments
• Gids voor het diagnosticeren van schijf- en inode-tekorten in Linux
• Gids voor Linux-containers en cgroups v2

Samenvatting van de Kubespray Kubernetes-implementatie

Het implementeren van Kubernetes met Kubespray draait niet alleen om één succesvolle uitvoering van cluster.yml, maar om het valideren van versiecombinaties, consensus tussen 3 nodes, API-endpoints, netwerken en herstelplannen. Zet de release-tag en inventory vast, beperk anonieme toegang en test daadwerkelijk de connectiviteit van Cilium, NetworkPolicy en etcd-herstel. Alleen door aan deze criteria te voldoen, kan de Rocky Linux 9-oefening worden opgeschaald naar een operationeel Kubernetes-platform.