Cluster-Innereien: Logging, MachineConfig und etcd

1 Drei Zustandsketten

Alle drei Themen beantworten dieselbe Betriebsfrage: Wo entsteht Zustand, wer hält ihn und wie kommst du im Fehlerfall wieder daran?

2 Gesundheit vor der Diagnose prüfen

Das Lab benötigt cluster-admin. Alle Befehle in diesem Abschnitt lesen nur.

oc whoami
oc auth can-i '*' '*' --all-namespaces
oc get nodes
oc get co machine-config etcd
oc get mcp
oc get pods -n openshift-etcd -o wide

3 Einen Logpfad untersuchen

OpenShift kann aktuelle Container-Logs ohne zentralen Logging-Stack anzeigen. Diese Logs liegen zunächst am Node und verschwinden mit Rotation, Pod-Löschung oder Node-Verlust.

oc get pods -n library
oc logs -n library deployment/catalog-service --tail=50
oc logs -n library deployment/catalog-service --since=10m --timestamps

# nach einem Container-Neustart den vorherigen Container lesen
oc logs -n library pod/<pod-name> --previous --tail=50

oc logs fragt über den API-Server den Kubelet des Nodes ab. Der Kubelet ist der Node-Prozess, der Pods startet und ihren Zustand meldet. Er ist keine dauerhafte Logdatenbank.

Node- und Plattform-Logs

$node = oc get node -l node-role.kubernetes.io/control-plane -o jsonpath='{.items[0].metadata.name}'
oc adm node-logs $node --unit=kubelet --tail=50
oc adm node-logs $node --unit=crio --tail=50

node=$(oc get node -l node-role.kubernetes.io/control-plane -o jsonpath='{.items[0].metadata.name}')
oc adm node-logs "$node" --unit=kubelet --tail=50
oc adm node-logs "$node" --unit=crio --tail=50

4 Erkennen, ob zentrales Logging installiert ist

OpenShift Logging ist nicht automatisch Bestandteil jedes Clusters. In Logging 6 verwaltet der Logging Operator Sammlung und Weiterleitung, der Loki Operator den Speicher und der Cluster Observability Operator die Anzeige.

oc api-resources | Select-String -Pattern 'ClusterLogForwarder|LokiStack'
oc get csv -A | Select-String -Pattern 'logging|loki|observability'
oc get clusterlogforwarder -A
oc get lokistack -A
oc get pods -n openshift-logging

oc api-resources | grep -E 'ClusterLogForwarder|LokiStack'
oc get csv -A | grep -Ei 'logging|loki|observability'
oc get clusterlogforwarder -A
oc get lokistack -A
oc get pods -n openshift-logging

Auf der kleinen SNO ist kein Logging-Stack die vernünftige Vorgabe. Loki benötigt dauerhaften Objektspeicher und zusätzliche Ressourcen. Für kurze Diagnose reicht oc logs. Für Aufbewahrung oder Audit muss ein zentraler Zielpfad geplant werden.

5 Node-Konfiguration zum Ursprung zurückverfolgen

Der Machine Config Operator, kurz MCO, verwaltet das Betriebssystem der RHCOS- oder SCOS-Nodes. Direkte SSH-Änderungen sind Drift und keine dauerhafte Konfiguration.

oc get co machine-config
oc get mcp
oc get mc -o 'custom-columns=NAME:.metadata.name,GENERATED-BY:.metadata.ownerReferences[0].kind'

$node = oc get node -l node-role.kubernetes.io/control-plane -o jsonpath='{.items[0].metadata.name}'
oc get node $node -o jsonpath='{.metadata.annotations.machineconfiguration\.openshift\.io/currentConfig}{"\n"}{.metadata.annotations.machineconfiguration\.openshift\.io/desiredConfig}{"\n"}{.metadata.annotations.machineconfiguration\.openshift\.io/state}{"\n"}{.metadata.annotations.machineconfiguration\.openshift\.io/reason}{"\n"}'

$rendered = oc get mcp master -o jsonpath='{.status.configuration.name}'
oc get mc $rendered -o yaml

oc get co machine-config
oc get mcp
oc get mc -o 'custom-columns=NAME:.metadata.name,GENERATED-BY:.metadata.ownerReferences[0].kind'

node=$(oc get node -l node-role.kubernetes.io/control-plane -o jsonpath='{.items[0].metadata.name}')
oc get node "$node" -o jsonpath='{.metadata.annotations.machineconfiguration\.openshift\.io/currentConfig}{"\n"}{.metadata.annotations.machineconfiguration\.openshift\.io/desiredConfig}{"\n"}{.metadata.annotations.machineconfiguration\.openshift\.io/state}{"\n"}{.metadata.annotations.machineconfiguration\.openshift\.io/reason}{"\n"}'

rendered=$(oc get mcp master -o jsonpath='{.status.configuration.name}')
oc get mc "$rendered" -o yaml

6 Eine MachineConfig sicher proben

Du legst lokal ein Manifest an und lässt nur API-Schema und Admission prüfen. Der Dry-Run erzeugt kein Clusterobjekt und löst keinen Node-Neustart aus.

@'
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  name: 99-master-mco-lab
  labels:
    machineconfiguration.openshift.io/role: master
spec:
  config:
    ignition:
      version: 3.4.0
    storage:
      files:
        - path: /etc/mco-lab-marker
          mode: 420
          overwrite: true
          contents:
            source: data:text/plain;charset=utf-8,mco-lab%0A
'@ | Set-Content -LiteralPath .\machineconfig-mco-lab.yaml -Encoding utf8

oc apply --dry-run=server -f .\machineconfig-mco-lab.yaml
oc diff -f .\machineconfig-mco-lab.yaml

cat > machineconfig-mco-lab.yaml <<'EOF'
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  name: 99-master-mco-lab
  labels:
    machineconfiguration.openshift.io/role: master
spec:
  config:
    ignition:
      version: 3.4.0
    storage:
      files:
        - path: /etc/mco-lab-marker
          mode: 420
          overwrite: true
          contents:
            source: data:text/plain;charset=utf-8,mco-lab%0A
EOF

oc apply --dry-run=server -f machineconfig-mco-lab.yaml
oc diff -f machineconfig-mco-lab.yaml

machineconfig-mco-lab.yaml ist eine Datei, die du anlegst. /etc/mco-lab-marker würde erst bei einem echten Apply vom MCO generiert. Der Rückgabecode 1 von oc diff bedeutet normalerweise „Unterschied gefunden“ und ist hier kein Fehler.

Die lokale Übungsdatei kannst du danach mit Remove-Item -LiteralPath .\machineconfig-mco-lab.yaml oder unter Bash mit rm -- machineconfig-mco-lab.yaml entfernen.

7 etcd vor dem Backup untersuchen

Ein etcd-Snapshot schützt Kubernetes- und OpenShift-API-Objekte. Er enthält keine Daten aus Persistent Volumes und ersetzt kein Anwendungsbackup.

oc get co etcd
oc get etcd cluster -o yaml
oc get pods -n openshift-etcd -l app=etcd -o wide
oc get --raw='/readyz?verbose'
oc get clusterversion version -o jsonpath='{.status.desired.version}{"\n"}'

8 Ein echtes etcd-Backup erzeugen

Das offizielle Skript ist Teil des etcd Cluster Operators. Es erzeugt einen Datenbank-Snapshot und ein Archiv mit den Static-Pod-Ressourcen.

Control-Plane-Node ermitteln

$node = oc get node -l node-role.kubernetes.io/control-plane -o jsonpath='{.items[0].metadata.name}'
$node
oc debug --as-root node/$node

node=$(oc get node -l node-role.kubernetes.io/control-plane -o jsonpath='{.items[0].metadata.name}')
printf '%s\n' "$node"
oc debug --as-root "node/$node"

Im Debug-Pod ausführen

chroot /host
mkdir -p /home/core/assets/etcd-backup
/usr/local/bin/cluster-backup.sh /home/core/assets/etcd-backup
ls -lh /home/core/assets/etcd-backup
exit
exit

9 Backup außerhalb des Clusters sichern

Eine Datei auf derselben SNO hilft nicht bei Node- oder Disk-Verlust. Kopiere beide erzeugten Dateien auf den Laptop und danach in deinen verschlüsselten Backup-Speicher.

$node = oc get node -l node-role.kubernetes.io/control-plane -o jsonpath='{.items[0].metadata.name}'
$nodeIp = oc get node $node -o jsonpath='{.status.addresses[?(@.type=="InternalIP")].address}'
$destination = ".\backups\etcd-$(Get-Date -Format yyyyMMdd-HHmmss)"
New-Item -ItemType Directory -Path $destination -Force
scp -r "core@${nodeIp}:/home/core/assets/etcd-backup/*" $destination
Get-ChildItem -LiteralPath $destination
Get-FileHash -Algorithm SHA256 -Path "$destination\*"

node=$(oc get node -l node-role.kubernetes.io/control-plane -o jsonpath='{.items[0].metadata.name}')
node_ip=$(oc get node "$node" -o jsonpath='{.status.addresses[?(@.type=="InternalIP")].address}')
destination="./backups/etcd-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$destination"
scp -r "core@${node_ip}:/home/core/assets/etcd-backup/." "$destination/"
find "$destination" -maxdepth 1 -type f -print
sha256sum "$destination"/*

Falls die ermittelte InternalIP vom Laptop nicht erreichbar ist, verwendest du stattdessen die erreichbare Tailscale- oder Host-Adresse desselben Nodes. Der Node-Name und die Zieladresse müssen weiterhin zum gleichen Control-Plane-Node gehören.

Der Ordner backups/etcd-<zeit>/ wird von dir angelegt. Er gehört nicht ins Git-Repository. Der Snapshot enthält Clusterobjekte und damit möglicherweise Secrets. Verschlüssele und schütze ihn wie Zugangsdaten.

10 Die drei Sicherungsarten nicht verwechseln

• Logs sind keine Backups. Sie erklären Ereignisse, stellen aber keinen Zustand wieder her.
• MachineConfig ist gewünschte Node-Konfiguration. Sie sichert keine Daten und gehört als selbst angelegtes Manifest ins Git.
• etcd-Backup ist versionsgebunden. Dokumentiere die genaue Cluster-Version zusammen mit den Prüfsummen.
• Ein SNO-Snapshot ersetzt keine externe Kopie. Provider-, Konto- oder Regionsverlust bleibt sonst derselbe Ausfallbereich.

11 Lernkontrolle