Infrastructuur opschalen met Kubernetes en RKE2: een productiediepe duik

Een Kubernetes-cluster in productie draaien is één ding. Het runnen van een systeem dat onvoorspelbare verkeerspieken kan opvangen, storingen in het controlevlak kan overleven, huurderisolatie kan afdwingen en uw operationele team duidelijk inzicht kan geven in elke laag van het systeem: dat is een heel andere uitdaging. RKE2, Rancher's Kubernetes-distributie van de volgende generatie, is speciaal gebouwd voor omgevingen waar over deze vereisten niet onderhandelbaar is.

Dit artikel behandelt de volledige levenscyclus van een RKE2-implementatie op productieniveau: initiële clusterarchitectuur, automatisch schalen op pod- en knooppuntniveau, controlevlakken met hoge beschikbaarheid, resourcebeheer en observatie met Prometheus en Grafana.

Waarom RKE2?

RKE2 onderscheidt zich van de upstream Kubernetes en van zijn voorganger RKE1 op drie belangrijke gebieden. Ten eerste wordt het standaard geleverd met een CIS Kubernetes Benchmark-geharde configuratie: toegangscontrollers, auditlogboekregistratie, pod-beveiliging en TLS-instellingen zijn vooraf geconfigureerd om een ​​CIS Level 1-scan te doorstaan ​​zonder handmatige tussenkomst. Ten tweede voldoet het aan FIPS 140-2, waardoor het geschikt is voor implementaties bij de overheid en gereguleerde sectoren. Ten derde worden containers rechtstreeks ingebed en verzonden met een eigen CNI (Canal of Cilium, afhankelijk van uw configuratiekeuze), waardoor de oppervlakte van externe afhankelijkheden die u moet beheren, wordt verkleind.

RKE2 is ook luchtspleetvriendelijk. De installatiebundel bevat alle vereiste containerimages, wat enorm belangrijk is bij on-premises en edge-implementaties waar internettoegang vanaf clusterknooppunten beperkt of onmogelijk is.

Clusterarchitectuur

Een productie RKE2-cluster is verdeeld in serverknooppunten (die het besturingsvlak en etcd uitvoeren) en agentknooppunten (die werklasten uitvoeren). De aanbevolen topologie voor hoge beschikbaarheid bestaat uit drie of vijf serverknooppunten en een variabel aantal agentknooppunten, georganiseerd in knooppuntpools op werklastklasse.

# /etc/rancher/rke2/config.yaml (server node)
token: <shared-cluster-token>
tls-san:
  - 10.0.0.10          # VIP or load balancer address
  - k8s.internal.example.com
cni: cilium
cluster-cidr: 10.42.0.0/16
service-cidr: 10.43.0.0/16
etcd-expose-metrics: true
kube-apiserver-arg:
  - "audit-log-path=/var/log/kubernetes/audit.log"
  - "audit-log-maxage=30"
  - "audit-log-maxsize=100"

# /etc/rancher/rke2/config.yaml (agent node)
server: https://10.0.0.10:9345
token: <shared-cluster-token>
node-label:
  - "workload-class=general"
  - "topology.kubernetes.io/zone=eu-west-1a"

Installeer de server op uw eerste knooppunt op het besturingsvlak en sluit u vervolgens aan bij de resterende serverknooppunten en alle agentknooppunten met hetzelfde token en het VIP-adres. RKE2 kiest automatisch etcd-leiders en beheert het quorum.

# Install and start RKE2 server
curl -sfL https://get.rke2.io | INSTALL_RKE2_TYPE=server sh -
systemctl enable --now rke2-server.service

# Retrieve the node token for joining additional nodes
cat /var/lib/rancher/rke2/server/node-token

# Install and start RKE2 agent (on worker nodes)
curl -sfL https://get.rke2.io | INSTALL_RKE2_TYPE=agent sh -
systemctl enable --now rke2-agent.service

knooppuntpools en plaatsing van werklasten

Niet alle workloads hebben hetzelfde resourceprofiel. Stateless webservices hebben andere vereisten dan GPU-inferentietaken, geheugenintensieve analyseworkloads of latentiegevoelige databases. Door agentknooppunten te organiseren in pools met verschillende labels en verontreinigingen kan Kubernetes elke werklastklasse plannen op hardware van de juiste grootte.

# Label a node pool for memory-intensive workloads
kubectl label nodes worker-mem-{1..4} workload-class=memory-optimised
kubectl taint nodes worker-mem-{1..4} workload-class=memory-optimised:NoSchedule

# Label a separate pool for general compute
kubectl label nodes worker-gen-{1..8} workload-class=general

# Deployment targeting the memory-optimised pool
apiVersion: apps/v1
kind: Deployment
metadata:
  name: analytics-engine
spec:
  template:
    spec:
      nodeSelector:
        workload-class: memory-optimised
      tolerations:
        - key: workload-class
          operator: Equal
          value: memory-optimised
          effect: NoSchedule
      containers:
        - name: analytics
          image: registry.internal/analytics:v2.3.1
          resources:
            requests:
              memory: "8Gi"
              cpu: "2"
            limits:
              memory: "16Gi"
              cpu: "4"

Horizontale Pod Autoscaler

De Horizontal Pod Autoscaler (HPA) past het aantal replica's van een implementatie of StatefulSet aan op basis van waargenomen statistieken. CPU-gebruik is de klassieke trigger, maar moderne HPA-configuraties kunnen ook worden geschaald op basis van aangepaste statistieken die door uw applicatie worden vrijgegeven of op basis van externe statistieken uit bronnen zoals de diepte van de berichtenwachtrij.

Zorg er eerst voor dat de Metrics Server actief is; RKE2 bundelt deze niet standaard.

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-server-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 65
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 70
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  # wait 5 minutes before scaling down
      policies:
        - type: Percent
          value: 25
          periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
        - type: Percent
          value: 100
          periodSeconds: 30

Hetbehavior-blok is van cruciaal belang voor de stabiliteit. Zonder een stabilisatieperiode voor het terugschalen zal een korte verkeersdaling de pods voortijdig verwijderen, waardoor u te weinig voorzieningen krijgt als de belasting terugkeert. Het asymmetrische beleid – agressief opschalen, conservatief terugschalen – is de juiste standaard voor de meeste productieworkloads.

Verticale Pod Autoscaler

De Vertical Pod Autoscaler (VPA) past de CPU en geheugenverzoeken op individuele pods aan op basis van waargenomen gebruik. Het lost een veelvoorkomend probleem op: ontwikkelaars stellen initiële resourceverzoeken in op basis van giswerk, en die waarden worden nooit bijgewerkt, wat leidt tot verspillende overprovisioning of tot OOMKilled-pods onder belasting.

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: worker-vpa
  namespace: production
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: background-worker
  updatePolicy:
    updateMode: "Auto"     # or "Off" to only view recommendations
  resourcePolicy:
    containerPolicies:
      - containerName: worker
        minAllowed:
          cpu: 100m
          memory: 256Mi
        maxAllowed:
          cpu: 4
          memory: 8Gi
        controlledResources: ["cpu", "memory"]

Houd er rekening mee dat VPA in deAuto-modus pods zal verwijderen en opnieuw opstarten om nieuwe bronwaarden toe te passen. Voor services waarbij verzoeken tijdens de vlucht niet kunnen worden onderbroken, voert u VPA uit in deOff-modus om aanbevelingen te genereren die u handmatig of via een GitOps-workflow toepast tijdens onderhoudsvensters.

Belangrijk:HPA en VPA mogen niet tegelijkertijd dezelfde bron (CPU of geheugen) in dezelfde implementatie beheren. Gebruik HPA voor CPU-gestuurde horizontale schaling en VPA in deOff-modus voor de juiste grootte van het geheugen, of gebruikKEDAvoor gebeurtenisgestuurde schaling waarbij fijnmazige controle nodig is.

Cluster-autoscaler

Pod-autoscalers werken binnen de bestaande knooppuntcapaciteit. Wanneer die capaciteit is uitgeput (pods zitten vast inPendingomdat geen enkel knooppunt over voldoende bronnen beschikt), hebt u de Cluster Autoscaler nodig om nieuwe knooppunten in te richten. Omgekeerd, wanneer knooppunten aanzienlijk onderbenut zijn, kan de Cluster Autoscaler deze leegmaken en buiten gebruik stellen om de infrastructuurkosten te verlagen.

Bij bare-metal of on-premises implementaties kan de Cluster Autoscaler worden geïntegreerd met de inrichtingslaag van uw infrastructuur. Voor cloudimplementaties bieden providers zoals AWS, GCP en Azure native node-groepintegraties. Het volgende voorbeeld toont de kernconfiguratie voor een AWS Auto Scaling Group.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cluster-autoscaler
  namespace: kube-system
spec:
  template:
    spec:
      containers:
        - name: cluster-autoscaler
          image: registry.k8s.io/autoscaling/cluster-autoscaler:v1.29.0
          command:
            - ./cluster-autoscaler
            - --cloud-provider=aws
            - --nodes=2:10:k8s-general-worker-asg
            - --nodes=1:4:k8s-memory-worker-asg
            - --scale-down-delay-after-add=10m
            - --scale-down-unneeded-time=10m
            - --scale-down-utilization-threshold=0.5
            - --skip-nodes-with-local-storage=false
            - --expander=least-waste
          env:
            - name: AWS_REGION
              value: eu-west-1

De optie--expander=least-wastevertelt de autoscaler om de voorkeur te geven aan de knooppuntgroep die de kleinste hoeveelheid ongebruikte bronnen zou hebben na het onderbrengen van de in behandeling zijnde pod, waardoor de kosten worden geminimaliseerd. Alternatieve expanders zijn onder meerrandom,most-podsenpriority.

Besturingsvliegtuig met hoge beschikbaarheid

Een besturingsvlak met drie knooppunten met ingebedde etcd is de minimaal haalbare HA-topologie. etcd vereist quorum: een meerderheid van de leden moet gezond zijn voordat het cluster schrijfbewerkingen kan accepteren. Met drie leden kun je één mislukking tolereren; met vijf leden kun je er twee tolereren.

De knooppunten op het besturingsvlak moeten achter een load balancer zitten. Voor cloudimplementaties werkt een TCP-load balancer die zich richt op poort 6443 (kube-apiserver) en 9345 (RKE2-registratie) goed. On-premises implementaties maken doorgaans gebruik van keepalived met een virtueel IP-adres.

# keepalived.conf on control-plane nodes
vrrp_instance VI_1 {
    state MASTER        # BACKUP on the other two nodes
    interface eth0
    virtual_router_id 51
    priority 100        # 90 and 80 on the other two nodes
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass securepassword
    }
    virtual_ipaddress {
        10.0.0.10/24    # VIP used in tls-san and agent server address
    }
}

Valideer dat etcd in orde is na elke bewerking op het besturingsvlak. RKE2 bundeltetcdctlbij/var/lib/rancher/rke2/bin/etcdctl.

ETCDCTL_API=3 /var/lib/rancher/rke2/bin/etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/var/lib/rancher/rke2/server/tls/etcd/server-ca.crt \
  --cert=/var/lib/rancher/rke2/server/tls/etcd/client.crt \
  --key=/var/lib/rancher/rke2/server/tls/etcd/client.key \
  endpoint health --cluster

Resourcequota en limietbereiken

In multi-tenant clusters – waar verschillende teams of applicaties dezelfde fysieke infrastructuur delen – zijn ResourceQuotas en LimitRanges essentiële vangrails. ResourceQuota's stellen harde limieten in voor het totale resourceverbruik binnen een naamruimte. LimitRanges stellen standaard- en maximumwaarden in voor individuele containers, waardoor wordt voorkomen dat een verkeerd geconfigureerde implementatie om onbegrensde bronnen vraagt.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-alpha-quota
  namespace: team-alpha
spec:
  hard:
    requests.cpu: "20"
    requests.memory: 40Gi
    limits.cpu: "40"
    limits.memory: 80Gi
    count/deployments.apps: "20"
    count/services: "15"
    persistentvolumeclaims: "10"
    requests.storage: 500Gi

apiVersion: v1
kind: LimitRange
metadata:
  name: team-alpha-limits
  namespace: team-alpha
spec:
  limits:
    - type: Container
      default:
        cpu: 500m
        memory: 512Mi
      defaultRequest:
        cpu: 100m
        memory: 128Mi
      max:
        cpu: "8"
        memory: 16Gi
    - type: PersistentVolumeClaim
      max:
        storage: 100Gi

Het toepassen van LimitRanges zorgt ervoor dat ontwikkelaars die vergeten resourceverzoeken op te geven nog steeds verstandige standaardwaarden krijgen in plaats van nul CPU aan te vragen, wat ertoe zou leiden dat de planner de pod ergens zou plaatsen en mogelijk andere werklasten op hetzelfde knooppunt zou uithongeren.

-bewaking met Prometheus en Grafana

Waarneembaarheid in een Kubernetes-cluster bestaat uit drie pijlers: statistieken, logboeken en traces. Prometheus verzorgt de verzameling van statistieken; Grafana verzorgt de visualisatie. Hetkube-prometheus-stackHelm-diagram implementeert de volledige stapel – Prometheus Operator, Alert Manager, Grafana, knooppuntexporteurs en een uitgebreide set vooraf gebouwde dashboards – in één enkele opdracht.

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set prometheus.prometheusSpec.retention=30d \
  --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.storageClassName=longhorn \
  --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.resources.requests.storage=100Gi \
  --set grafana.adminPassword=<secure-password> \
  --set alertmanager.alertmanagerSpec.storage.volumeClaimTemplate.spec.resources.requests.storage=10Gi

RKE2 geeft etcd-statistieken weer wanneeretcd-expose-metrics: trueis ingesteld in de serverconfiguratie. Voeg een ServiceMonitor toe zodat Prometheus ze schrapt.

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: rke2-etcd
  namespace: monitoring
  labels:
    release: kube-prometheus-stack
spec:
  namespaceSelector:
    matchNames: [kube-system]
  selector:
    matchLabels:
      app.kubernetes.io/name: rke2-etcd
  endpoints:
    - port: metrics
      scheme: https
      tlsConfig:
        caFile: /etc/prometheus/secrets/etcd-client-cert/ca.crt
        certFile: /etc/prometheus/secrets/etcd-client-cert/client.crt
        keyFile: /etc/prometheus/secrets/etcd-client-cert/client.key

Essentiële waarschuwingsregels

Vooraf gebouwde dashboards vormen een startpunt, maar aangepaste waarschuwingsregels die zijn afgestemd op uw omgeving zorgen ervoor dat technici op afroep kunnen handelen voordat gebruikers een probleem opmerken.

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: workload-alerts
  namespace: monitoring
  labels:
    release: kube-prometheus-stack
spec:
  groups:
    - name: pod-health
      rules:
        - alert: PodCrashLooping
          expr: rate(kube_pod_container_status_restarts_total[10m]) > 0.5
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} is crash-looping"

        - alert: NodeMemoryPressure
          expr: |
            (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) < 0.1
          for: 2m
          labels:
            severity: warning
          annotations:
            summary: "Node {{ $labels.node }} memory below 10%"

        - alert: HPAMaxedOut
          expr: |
            kube_horizontalpodautoscaler_status_current_replicas
            == kube_horizontalpodautoscaler_spec_max_replicas
          for: 15m
          labels:
            severity: warning
          annotations:
            summary: "HPA {{ $labels.namespace }}/{{ $labels.horizontalpodautoscaler }} at maximum replicas"

Vooral deHPAMaxedOut-waarschuwing is in de praktijk waardevol. Wanneer een HPA gedurende langere tijd op het maximum is vastgezet, betekent dit dat het verkeer uw huidige plafond is ontgroeid. U moet het maximum verhogen of capaciteit toevoegen aan de knooppuntpool – en dat wilt u weten vóór de volgende piek, niet tijdens de piek.

Beste productiepraktijken

Pod-verstoringsbudgetten

Een PodDisruptionBudget (PDB) beperkt hoeveel pods in een implementatie tegelijkertijd niet beschikbaar kunnen zijn tijdens vrijwillige verstoringen zoals het leeglopen van knooppunten. Zonder PDB's kan het leegmaken van een knooppunt voor onderhoud een hele implementatie offline brengen.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-server-pdb
  namespace: production
spec:
  minAvailable: 2       # or use maxUnavailable: 1
  selector:
    matchLabels:
      app: api-server

Topologiespreidingsbeperkingen

Standaard verspreidt de planner replica's over knooppunten met behulp van een best-effort-algoritme. Beperkingen voor topologiespreiding geven u harde garanties dat replica's worden gedistribueerd over beschikbaarheidszones of rekken.

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app: api-server

Upgradestrategie

RKE2 ondersteunt doorlopende upgrades via de System Upgrade Controller. U definieert een plan dat zich richt op server- of agentknooppunten en specificeert de doelversie; de controller leegt, upgradet en ontkoppelt knooppunten opeenvolgend.

apiVersion: upgrade.cattle.io/v1
kind: Plan
metadata:
  name: rke2-server-upgrade
  namespace: system-upgrade
spec:
  concurrency: 1
  cordon: true
  nodeSelector:
    matchExpressions:
      - { key: node-role.kubernetes.io/control-plane, operator: In, values: ["true"] }
  serviceAccountName: system-upgrade
  upgrade:
    image: rancher/rke2-upgrade
  version: v1.29.4+rke2r1

etcd Back-up en herstel

RKE2 kan automatisch geplande etcd-snapshots maken. Zorg ervoor dat ze naar duurzame opslag buiten het cluster worden geschreven (een S3-bucket of een externe NFS-koppeling) in plaats van naar een lokale schijf op de knooppunten op het besturingsvlak.

# /etc/rancher/rke2/config.yaml additions for automated snapshots
etcd-snapshot-schedule-cron: "0 */6 * * *"    # every 6 hours
etcd-snapshot-retention: 10
etcd-snapshot-dir: /mnt/nfs/etcd-snapshots

# Manual snapshot
rke2 etcd-snapshot save --name pre-upgrade-$(date +%Y%m%d)

# Restore from snapshot (run on a single server node with cluster stopped)
rke2 server --cluster-reset --cluster-reset-restore-path=/path/to/snapshot.db

Conclusie

Het schalen van de infrastructuur met RKE2 is geen enkele configuratiewijziging; het is een systeem van in elkaar grijpende mogelijkheden dat samen moet worden ontworpen en beheerd. Het automatisch schalen van horizontale pods verwerkt kortstondige verkeersbursts op werklastniveau. Automatisch schalen van verticale pods houdt resourceverzoeken in de loop van de tijd eerlijk. De Cluster Autoscaler zorgt ervoor dat de onderliggende knooppuntcapaciteit de totale vraag van uw pod-autoscalers volgt. Node-pools en topologiebeperkingen zorgen ervoor dat workloads op de juiste hardware terechtkomen. Resourcequota en limietbereiken beschermen tenants tegen elkaar. PodDisruptionBudgets en spreidingsbeperkingen in de topologie verscherpen de beschikbaarheid. En Prometheus met Grafana geeft uw team de zichtbaarheid om degradatie te detecteren voordat er sprake is van een storing.

RKE2 verdient zijn plaats in de productie juist omdat het een aanzienlijk deel van deze stapel voorgehard en vooraf geïntegreerd verzendt. Het is uw verantwoordelijkheid om de knoppen te begrijpen, ze af te stemmen op de kenmerken van uw werkbelasting en de operationele discipline op te bouwen (runbooks, waarschuwingsroutering, upgradecadans, back-upvalidatie) die van een goed geconfigureerd cluster een echt betrouwbaar platform maakt.