Konfiguration
Spezifikationen der Steuerungsebene und des Load-Balancers
Die Knotenpoolspezifikationen der Steuerungsebene und des Load-Balancers sind spezifisch. Diese Spezifikationen deklarieren und steuern wichtige Clusterressourcen. Die kanonische Quelle für diese Ressourcen sind die entsprechenden Abschnitte in der Cluster-Konfigurationsdatei:
spec.controlPlane.nodePoolSpec
spec.loadBalancer.nodePoolSpec
Daher sollten Sie die Knotenpoolressourcen der obersten Ebene und die Load-Balancer-Knotenressourcen nicht direkt ändern. Ändern Sie stattdessen die zugehörigen Abschnitte in der Cluster-Konfigurationsdatei.
Installation
Die Clustererstellung schlägt fehl, wenn Multi-NIC, containerd
und HTTPS-Proxy verwendet werden.
Die Clustererstellung schlägt fehl, wenn die folgende Kombination von Bedingungen vorliegt:
Der Cluster ist so konfiguriert, dass
containerd
als Containerlaufzeit verwendet wird (nodeConfig.containerRuntime
ist in der Clusterkonfigurationsdatei aufcontainerd
gesetzt), der Standard für Anthos-Cluster auf Bare-Metal-Version 1.9.Der Cluster ist so konfiguriert, dass mehrere Netzwerkschnittstellen mit mehreren NICs für Pods bereitgestellt werden (
clusterNetwork.multipleNetworkInterfaces
ist in der Cluster-Konfigurationsdatei auftrue
gesetzt).Der Cluster ist für die Verwendung eines Proxys konfiguriert (
spec.proxy.url
wird in der Clusterkonfigurationsdatei angegeben). Obwohl die Clustererstellung fehlschlägt, wird diese Einstellung übernommen, wenn Sie versuchen, einen Cluster zu erstellen. Diese Proxyeinstellung wird möglicherweise als UmgebungsvariableHTTPS_PROXY
oder in der Konfigurationcontainerd
(/etc/systemd/system/containerd.service.d/09-proxy.conf
) angezeigt.
Als Behelfslösung für dieses Problem hängen Sie Dienst-CIDRs (clusterNetwork.services.cidrBlocks
) an die Umgebungsvariable NO_PROXY
auf allen Knotenmaschinen an.
Wenn nicht angegeben, wird containerRuntime
nicht standardmäßig auf containerd gesetzt.
In Anthos-Clustern auf Bare-Metal-Version 1.9.0 wurde der Standard containerRuntime
in der generierten Clusterkonfigurationsdatei von docker
auf containerd
aktualisiert. Wenn das Feld containerRuntime
nicht festgelegt oder aus der Clusterkonfigurationsdatei entfernt wird, wird containerRuntime
beim Erstellen von Clustern auf docker
gesetzt. Der Wert containerRuntime
sollte standardmäßig auf containerd
gesetzt sein, sofern er nicht explizit auf docker
festgelegt ist. Dieses Problem gilt nur für die Versionen 1.9.0 und 1.9.1.
Führen Sie die Schritte unter Clusterinformationen abrufen aus, um zu ermitteln, welche Containerlaufzeit Ihr Cluster verwendet.
Prüfen Sie den Wert von containerRuntime
im Abschnitt cluster.spec.nodeConfig
.
Die einzige Möglichkeit, die Containerlaufzeit zu ändern, ist das Upgrade Ihrer Cluster. Weitere Informationen finden Sie unter Containerlaufzeit ändern.
Dieses Problem wurde in Anthos-Clustern auf Bare-Metal-Version 1.9.2 behoben.
Inkompatibilität der Kontrollgruppe v2
Kontrollgruppe v2 (cgroup v2) wird in Anthos-Cluster auf Bare Metal 1.9 nicht offiziell unterstützt. Das Vorhandensein von /sys/fs/cgroup/cgroup.controllers
gibt an, dass Ihr System cgroup v2 verwendet.
Die Preflight-Prüfungen kontrollieren, dass cgroup v2 nicht auf der Clustermaschine verwendet wird.
Fehlermeldungen während der Installation
Bei der Untersuchung von Logs zur Clustererstellung können Sie unter Umständen vorübergehende Fehler beim Registrieren von Clustern oder Aufrufen von Webhooks feststellen. Diese Fehler können ignoriert werden, da die Installation diese Vorgänge so lange wiederholt, bis sie erfolgreich sind.
Preflight-Prüfungen und Anmeldedaten für Dienstkonten
Bei Installationen, die durch Administrator- oder Hybridcluster ausgelöst werden, also Cluster, die nicht mit bmctl
erstellt wurden, wie etwa Nutzercluster, werden bei der Preflight-Prüfung die Anmeldedaten des Google Cloud Platform-Dienstkontos oder deren zugehörigen Berechtigungen nicht geprüft..
Preflight-Prüfungen und Berechtigung verweigert
Während der Installation werden möglicherweise Fehler zu /bin/sh: /tmp/disks_check.sh: Permission denied
angezeigt.
Diese Fehlermeldungen werden angezeigt, weil /tmp
mit der Option noexec
bereitgestellt wird.
Damit bmctl
funktioniert, müssen Sie die Option noexec
aus dem Bereitstellungspunkt /tmp
entfernen.
Standardanmeldedaten für Anwendungen und bmctl
bmctl
verwendet Standardanmeldedaten für Anwendungen für die Validierung des Standortwerts des Clustervorgangs in cluster spec
, wenn dieser nicht auf global
gesetzt ist.
Damit ADC funktioniert, müssen Sie entweder die Umgebungsvariable GOOGLE_APPLICATION_CREDENTIALS
auf eine Datei mit den Anmeldedaten des Dienstkontos verweisen oder gcloud auth application-default login
ausführen.
Docker-Dienst
Wenn auf Computern von Clusterknoten die ausführbare Docker-Datei in der Umgebungsvariable PATH
vorhanden ist, der Docker-Dienst jedoch nicht aktiv ist, schlägt die Preflight-Prüfung fehl und meldet die Docker service is not active
. Sie können den Fehler beheben, indem Sie Docker entfernen oder den Docker-Dienst aktivieren.
Auf vSphere installieren
Wenn Sie Anthos-Cluster on Bare-Metal auf vSphere-VMs installieren, müssen Sie die Flags tx-udp_tnl-segmentation
und tx-udp_tnl-csum-segmentation
deaktivieren. Diese Flags beziehen sich auf die Auslagerung der Hardwaresegmentierung von vSphere. Treiber-VMXNET3 und funktionieren nicht mit dem GENEVE-Tunnel von Anthos-Clustern on Bare-Metal-Servern.
Führen Sie auf jedem Knoten den folgenden Befehl aus, um die aktuellen Werte für diese Flags zu prüfen.
ethtool -k NET_INTFC |grep segm
...
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
...
Ersetzen Sie NET_INTFC
durch die Netzwerkschnittstelle, die der IP-Adresse des Knotens zugeordnet ist.
Manchmal zeigt ethtool
in RHEL 8.4 an, dass diese Flags deaktiviert sind, obwohl sie aktiv sind. Um diese Flags explizit zu deaktivieren, aktivieren und deaktivieren Sie die Flags mit folgenden Befehlen.
ethtool -K ens192 tx-udp_tnl-segmentation on
ethtool -K ens192 tx-udp_tnl-csum-segmentation on
ethtool -K ens192 tx-udp_tnl-segmentation off
ethtool -K ens192 tx-udp_tnl-csum-segmentation off
Diese Flag-Änderung bleibt bei Neustarts nicht bestehen. Konfigurieren Sie die Startskripts so, dass diese Flags beim Systemstart explizit festgelegt werden.
Upgrades und Updates
bmctl
kann keine Nutzercluster niedrigerer Version erstellen, aktualisieren oder zurücksetzen.
Über die bmctl
-Befehlszeile kann kein Nutzercluster mit einer niedrigeren Nebenversion erstellt, aktualisiert oder zurückgesetzt werden, unabhängig von der Version des Administratorclusters. Sie können beispielsweise bmctl
mit der Version 1.N.X
nicht verwenden um einen Nutzercluster der Version 1.N-1.Y
zurückzusetzen, auch wenn der Administratorcluster ebenfalls die Version 1.N.X
hat.
Wenn Sie von diesem Problem betroffen sind, sollten Sie bei der Verwendung von bmctl
ähnliche Logs wie die folgenden sehen:
[2022-06-02 05:36:03-0500] error judging if the cluster is managing itself:
error to parse the target cluster: error parsing cluster config: 1 error
occurred:
* cluster version 1.8.1 is not supported in bmctl version 1.9.5, only
cluster version 1.9.5 is supported
Verwenden Sie zum Umgehen des Problems kubectl
, um die benutzerdefinierte Ressource des Nutzerclusters im Administratorcluster zu erstellen, zu bearbeiten oder zu löschen.
Die Möglichkeit, Nutzercluster zu aktualisieren, ist nicht betroffen.
Upgrade bleibt bei error during manifests operations
hängen
In einigen Situationen können Clusterupgrades nicht abgeschlossen werden und die bmctl
-Befehlszeile reagiert nicht mehr. Dieses Problem kann durch eine falsch aktualisierte Ressource verursacht werden. So können Sie feststellen, ob Sie von diesem Problem betroffen sind, und es beheben:
Prüfen Sie die
anthos-cluster-operator
-Logs und suchen Sie nach Fehlern, die den folgenden Einträgen ähneln:controllers/Cluster "msg"="error during manifests operations" "error"="1 error occurred: ... {RESOURCE_NAME} is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update
Diese Einträge sind ein Symptom einer falsch aktualisierten Ressource, wobei
{RESOURCE_NAME}
der Name der problematischen Ressource ist.Wenn Sie diese Fehler in Ihren Logs finden, entfernen Sie die Annotation
kubectl.kubernetes.io/last-applied-configuration
aus der Ressource aus der Lognachricht mitkubectl edit
.Speichern Sie die Änderungen und wenden Sie sie auf die Ressource an.
Wiederholen Sie das Clusterupgrade.
Upgrades schlagen in Clustern der Version 1.8 im Wartungsmodus fehl
Der Versuch, ein Cluster der Version 1.8.x auf Version 1.9.x zu aktualisieren, schlägt fehl, wenn zuvor Knotenmaschinen in den Wartungsmodus versetzt wurden. Dies liegt an einer Annotation, die auf diesen Knoten verbleibt.
So ermitteln Sie, ob Sie von diesem Problem betroffen sind:
Rufen Sie die Version des Clusters ab, den Sie aktualisieren möchten, indem Sie den folgenden Befehl ausführen:
kubectl --kubeconfig ADMIN_KUBECONFIG get cluster CLUSTER_NAME \ -n CLUSTER_NAMESPACE --output=jsonpath="{.spec.anthosBareMetalVersion}"
Wenn der zurückgegebene Versionswert für die Nebenversion 1.8 gilt (z. B.
1.8.3
), fahren Sie fort. Andernfalls gilt dieses Problem nicht für Sie.Prüfen Sie mit dem folgenden Befehl, ob der Cluster Knoten enthält, die zuvor in den Wartungsmodus versetzt wurden:
kubectl --kubeconfig ADMIN_KUBECONFIG get BareMetalMachines -n CLUSTER_NAMESPACE \ --output=jsonpath="{.items[*].metadata.annotations}"
Wenn die zurückgegebenen Annotationen
baremetal.cluster.gke.io/maintenance-mode-duration
enthalten, sind Sie von diesem bekannten Problem betroffen.
Damit die Blockierung des Cluster-Upgrades aufgehoben wird, führen Sie den folgenden Befehl für jede betroffene Knotenmaschine aus, um die Annotation baremetal.cluster.gke.io/maintenance-mode-duration
zu entfernen:
kubectl --kubeconfig ADMIN_KUBECONFIG annotate BareMetalMachine -n CLUSTER_NAMESPACE \
NODE_MACHINE_NAME baremetal.cluster.gke.io/maintenance-mode-duration-
bmctl update
entfernt keine Wartungsblöcke
Mit dem Befehl bmctl update
kann der Abschnitt maintenanceBlocks
nicht aus der Konfiguration der Clusterressource entfernt oder geändert werden. Weitere Informationen, einschließlich Anweisungen zum Entfernen von Knoten aus dem Wartungsmodus, finden Sie unter Knoten in den Wartungsmodus versetzen.
Einschränkung bei Nutzercluster-Patch-Upgrades
Nutzercluster, die von einem Administratorcluster verwaltet werden, müssen dieselbe Anthos-Cluster auf Bare Metal-Version oder maximal eine Nebenversion niedriger haben. Beispielsweise ist ein Administratorcluster der Version 1.9.0 (anthosBareMetalVersion: 1.9.0
), der Nutzercluster der Version 1.8.4 verwaltet, akzeptabel.
Eine Upgrade-Einschränkung verhindert, dass Sie Ihre Nutzercluster auf einen neuen Sicherheitspatch aktualisieren, wenn der Patch nach der Release-Version, die der Administratorcluster verwendet, veröffentlicht wird. Wenn Ihr Administratorcluster beispielsweise Version 1.7.2 hat, die am 2. Juni 2021 veröffentlicht wurde, können Sie Ihre Nutzercluster nicht auf Version 1.6.4 aktualisieren, da sie am 13. August 2021 veröffentlicht wurde.
Der Knotenausgleich kann nicht gestartet werden, wenn der Knoten außerhalb der Reichweite liegt
Der Draining-Vorgang für Knoten startet nicht, wenn der Knoten von Anthos-Cluster auf Bare Metal nicht erreicht werden kann. Wenn ein Knoten beispielsweise während eines Clusterupgrades offline geht, reagiert das Upgrade möglicherweise nicht mehr. Dies kommt aber nur selten vor. Um die Wahrscheinlichkeit eines solchen Problems zu minimieren, sollten Sie vor dem Upgrade prüfen, ob die Knoten ordnungsgemäß funktionieren.
Aktion
kubeconfig-Secret überschrieben
Der Befehl bmctl check cluster
überschreibt bei Ausführung in Nutzerclustern das kubeconfig-Secret des Nutzerclusters mit der Administratorcluster-kubeconfig. Das Überschreiben der Datei führt dazu, dass Standard-Clustervorgänge wie das Aktualisieren und Upgraden für betroffene Nutzercluster fehlschlagen. Dieses Problem betrifft die Anthos-Cluster auf Bare-Metal-Version 1.11.1 und frühere Versionen.
Führen Sie den folgenden Befehl aus, um festzustellen, ob ein Nutzercluster von diesem Problem betroffen ist:
kubectl --kubeconfig ADMIN_KUBECONFIG get secret -n cluster-USER_CLUSTER_NAME \
USER_CLUSTER_NAME -kubeconfig -o json | jq -r '.data.value' | base64 -d
Dabei gilt:
ADMIN_KUBECONFIG
: der Pfad zur kubeconfig-Datei des Administratorclusters.USER_CLUSTER_NAME
: der Name des zu prüfenden Nutzerclusters.
Wenn der Clustername in der Ausgabe (siehe contexts.context.cluster
in der folgenden Beispielausgabe) der Name des Administratorclusters ist, ist der angegebene Nutzercluster betroffen.
user-cluster-kubeconfig -o json | jq -r '.data.value' | base64 -d
apiVersion: v1
clusters:
- cluster:
certificate-authority-data:LS0tLS1CRU...UtLS0tLQo=
server: https://10.200.0.6:443
name: ci-aed78cdeca81874
contexts:
- context:
cluster: ci-aed78cdeca81874
user: ci-aed78cdeca81874-admin
name: ci-aed78cdeca81874-admin@ci-aed78cdeca81874
current-context: ci-aed78cdeca81874-admin@ci-aed78cdeca81874
kind: Config
preferences: {}
users:
- name: ci-aed78cdeca81874-admin
user:
client-certificate-data: LS0tLS1CRU...UtLS0tLQo=
client-key-data: LS0tLS1CRU...0tLS0tCg==
Mit den folgenden Schritten stellen Sie die Funktion in einem betroffenen Nutzercluster wieder her (USER_CLUSTER_NAME
):
Suchen Sie die kubeconfig-Datei des Nutzerclusters.
Anthos-Cluster auf Bare-Metal generiert die kubeconfig-Datei auf der Administrator-Workstation, wenn Sie einen Cluster erstellen. Die Datei befindet sich standardmäßig im Verzeichnis
bmctl-workspace/USER_CLUSTER_NAME
.Prüfen Sie, ob die kubeconfig-Datei die richtige Nutzercluster-kubeconfig ist:
kubectl get nodes --kubeconfig PATH_TO_GENERATED_FILE
Ersetzen Sie
PATH_TO_GENERATED_FILE
durch den Pfad zur Kubeconfig-Datei des Nutzerclusters. In der Antwort werden Details zu den Knoten für den Nutzercluster zurückgegeben. Prüfen Sie, ob die Maschinennamen für Ihren Cluster korrekt sind.Führen Sie den folgenden Befehl aus, um die beschädigte kubeconfig-Datei im Administratorcluster zu löschen:
kubectl delete secret -n USER_CLUSTER_NAMESPACE USER_CLUSTER_NAME-kubeconfig
Führen Sie den folgenden Befehl aus, um das richtige kubeconfig-Secret wieder im Administratorcluster zu speichern:
kubectl create secret generic -n USER_CLUSTER_NAMESPACE USER_CLUSTER_NAME-kubeconfig \ --from-file=value=PATH_TO_GENERATED_FILE
Snapshot als angemeldeter Nutzer ohne Root-Berechtigung erstellen
Wenn Sie containerd als Containerlaufzeit verwenden, muss zur Ausführung eines Snapshots als Nicht-Root-Nutzer /usr/local/bin
im PATH des Nutzers enthalten sein. Andernfalls schlägt der Vorgang mit dem Fehler crictl: command not found
fehl.
Wenn Sie nicht als Root-Nutzer angemeldet sind, wird sudo
zum Ausführen der Snapshot-Befehle verwendet. Der PATH sudo
kann sich vom Root-Profil unterscheiden und darf nicht /usr/local/bin
enthalten.
Sie können diesen Fehler beheben, indem Sie secure_path
in /etc/sudoers
so aktualisieren, dass /usr/local/bin
eingeschlossen wird. Alternativ können Sie einen symbolischen Link für crictl
in einem anderen /bin
-Verzeichnis erstellen.
Anthos VM Runtime
Beim Neustart eines Pods ändern sich die IP-Adressen der VMs auf dem Pod oder gehen ganz verloren. Wenn sich die IP-Adresse einer VM ändert, wirkt sich das nicht auf die Erreichbarkeit von VM-Anwendungen aus, die als Kubernetes-Dienst bereitgestellt werden. Wenn die IP-Adresse verloren geht, müssen Sie dhclient
von der VM aus ausführen, um eine IP-Adresse für die VM zu erhalten.
Logging und Monitoring
Fehlende Logs nach einem Netzwerkausfall
Wenn Ihr Cluster nach einem Netzwerkausfall wiederhergestellt wird, werden in einigen Fällen möglicherweise keine neuen Logs in Cloud Logging angezeigt. Außerdem werden in Ihren Logs für stackdriver-log-forwarder
möglicherweise mehrere Nachrichten wie diese angezeigt:
re-schedule retry=0x7fef2acbd8d0 239 in the next 51 seconds
Starten Sie den Pod stackdriver-log-forwarder
neu, um die Logweiterleitung wieder zu aktivieren. Wenn der Log-Forwarder innerhalb von 4,5 Stunden nach dem Ausfall neu gestartet wird, werden die gepufferten Logs an Cloud Logging weitergeleitet. Logs, die älter als 4,5 Stunden sind, werden gelöscht.
Intermittierende Messwertexportunterbrechungen
Bei Anthos-Clustern auf Bare-Metal-Versionen 1.9.x und 1.10.x können Unterbrechungen beim normalen, kontinuierlichen Export von Messwerten oder fehlende Messwerte auf einigen Knoten auftreten. Wenn dieses Problem Ihre Cluster betrifft, können Datenlücken für die folgenden Messwerte (mindestens) auftreten:
kubernetes.io/anthos/container_memory_working_set_bytes
kubernetes.io/anthos/container_cpu_usage_seconds_total
kubernetes.io/anthos/container_network_receive_bytes_total
Aktualisieren Sie Ihre Cluster auf Version 1.10.3 oder höher, um dieses Problem zu beheben.
Wenn Sie kein Upgrade durchführen können, führen Sie die folgenden Schritte aus:
Öffnen Sie die Ressource
stackdriver
zum Bearbeiten:kubectl -n kube-system edit stackdriver stackdriver
Fügen Sie dem
stackdriver
-Manifest den folgendenresourceAttrOverride
-Abschnitt hinzu, um die CPU-Anfrage fürgke-metrics-agent
von10m
auf50m
zu erhöhen:spec: resourceAttrOverride: gke-metrics-agent/gke-metrics-agent: limits: cpu: 100m memory: 4608Mi requests: cpu: 50m memory: 200Mi
Ihre bearbeitete Ressource sollte in etwa so aussehen:
spec: anthosDistribution: baremetal clusterLocation: us-west1-a clusterName: my-cluster enableStackdriverForApplications: true gcpServiceAccountSecretName: ... optimizedMetrics: true portable: true projectID: my-project-191923 proxyConfigSecretName: ... resourceAttrOverride: gke-metrics-agent/gke-metrics-agent: limits: cpu: 100m memory: 4608Mi requests: cpu: 50m memory: 200Mi
Speichern Sie die Änderungen und schließen Sie den Texteditor.
Führen Sie den folgenden Befehl aus, um zu prüfen, ob Ihre Änderungen wirksam wurden:
kubectl -n kube-system get daemonset gke-metrics-agent -o yaml | grep "cpu: 50m"
Der Befehl sucht
cpu: 50m
, wenn Ihre Änderungen wirksam wurden.Wenn Sie verhindern möchten, dass folgende Änderungen rückgängig gemacht werden, skalieren Sie
stackdriver-operator
herunter:kubectl -n kube-system scale deploy stackdriver-operator --replicas=0
Öffnen Sie
gke-metrics-agent-conf
zum Bearbeiten:kubectl -n kube-system edit configmap gke-metrics-agent-conf
Bearbeiten Sie die Konfiguration, um alle Instanzen von
probe_interval: 0.1s
inprobe_interval: 13s
zu ändern:183 processors: 184 disk_buffer/metrics: 185 backend_endpoint: https://monitoring.googleapis.com:443 186 buffer_dir: /metrics-data/nsq-metrics-metrics 187 probe_interval: 13s 188 retention_size_mib: 6144 189 disk_buffer/self: 190 backend_endpoint: https://monitoring.googleapis.com:443 191 buffer_dir: /metrics-data/nsq-metrics-self 192 probe_interval: 13s 193 retention_size_mib: 200 194 disk_buffer/uptime: 195 backend_endpoint: https://monitoring.googleapis.com:443 196 buffer_dir: /metrics-data/nsq-metrics-uptime 197 probe_interval: 13s 198 retention_size_mib: 200
Speichern Sie die Änderungen und schließen Sie den Texteditor.
Starten Sie das DaemonSet
gke-metrics-agent
neu:kubectl -n kube-system rollout restart daemonset gke-metrics-agent
Sicherheit
Container kann nicht in VOLUME
schreiben, das in Dockerfile mit containerd und SELinux definiert ist
Wenn Sie containerd als Containerlaufzeit verwenden und auf Ihrem Betriebssystem SELinux aktiviert ist, ist das in der Anwendungs-Dockerfile definierte VOLUME
möglicherweise nicht beschreibbar. Beispielsweise können Container, die mit dem folgenden Dockerfile erstellt wurden, nicht in den Ordner /tmp
schreiben.
FROM ubuntu:20.04
RUN chmod -R 777 /tmp
VOLUME /tmp
Führen Sie den folgenden Befehl auf dem Knoten aus, auf dem der problematische Container gehostet wird, um zu prüfen, ob Sie von diesem Problem betroffen sind:
ausearch -m avc
Wenn Sie von diesem Problem betroffen sind, wird ein denied
-Fehler wie der folgende angezeigt:
time->Mon Apr 4 21:01:32 2022 type=PROCTITLE msg=audit(1649106092.768:10979):
proctitle="bash" type=SYSCALL msg=audit(1649106092.768:10979): arch=c000003e
syscall=257 success=no exit=-13 a0=ffffff9c a1=55eeba72b320 a2=241 a3=1b6
items=0 ppid=75712 pid=76042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="bash" exe="/usr/bin/bash"
subj=system_u:system_r:container_t:s0:c701,c935 key=(null) type=AVC
msg=audit(1649106092.768:10979): avc: denied {
write } for pid=76042 comm="bash"
name="ad9bc6cf14bfca03d7bb8de23c725a86cb9f50945664cb338dfe6ac19ed0036c"
dev="sda2" ino=369501097 scontext=system_u:system_r:container_t:s0:c701,c935
tcontext=system_u:object_r:container_ro_file_t:s0 tclass=dir permissive=0
Führen Sie eine der folgenden Änderungen aus, um dieses Problem zu umgehen:
- Deaktivieren Sie SELinux.
- Verwenden Sie das VOLUME-Feature nicht in Dockerfile.
Cluster-CA-Rotation (Vorschaufunktion)
Die Cluster-Zertifizierungsstelle wird während des Upgrades rotiert. Die Unterstützung für On-Demand-Rotation ist ein Vorschaufeature.
Anthos-Cluster on Bare Metal rotiert kubelet
-Zertifikate automatisch.
Jeder kubelet
-Knoten-Agent kann eine Anfrage zur Signierung des Zertifikats (Certificate Signing Request, CSR) senden, wenn ein Zertifikat die Ablaufzeit überschreitet. Ein Controller in Ihren Administratorclustern validiert und genehmigt die CSR.
Nachdem Sie in einem Cluster eine CA-Rotation (User Cluster Certificate Authority) durchgeführt haben, schlagen alle Nutzerauthentifizierungsabläufe fehl. Diese Fehler treten auf, da die in Authentifizierungsabläufen verwendete benutzerdefinierte ClientConfig-Ressource während der CA-Rotation nicht mit den neuen CA-Daten aktualisiert wird. Wenn Sie für Ihren Cluster eine CA-Rotation durchgeführt haben, prüfen Sie, ob das Feld certificateAuthorityData
in default
ClientConfig des Namespace kube-public
die ältere Cluster-CA enthält.
Aktualisieren Sie das Feld certificateAuthorityData
mit der aktuellen Cluster-CA, um das Problem manuell zu beheben.
SELinux-Fehler bei der Pod-Erstellung
Die Pod-Erstellung schlägt manchmal fehl, wenn SELinux verhindert, dass die Containerlaufzeit Labels auf tmpfs
-Bereitstellungen festlegt. Dieser Fehler ist selten, kann aber auftreten, wenn SELinux im Modus Enforcing
ist, und in einigen Kerneln.
Mit folgendem Befehl prüfen Sie in den kubelet
-Logs, ob SELinux die Ursache für Fehler bei der Pod-Erstellung ist:
journalctl -u kubelet
Wenn SELinux dazu führt, dass die Pod-Erstellung fehlschlägt, enthält die Befehlsantwort einen Fehler wie den folgenden:
error setting label on mount source '/var/lib/kubelet/pods/
6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x':
failed to set file label on /var/lib/kubelet/pods/
6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x:
permission denied
Führen Sie folgenden Befehl aus, um zu kontrollieren, dass dieses Problem mit der SELinux-Erzwingung zusammenhängt:
ausearch -m avc
Dieser Befehl durchsucht die Auditlogs nach Berechtigungsfehlern des Zugriffsvektor-Cache (Access Vector Cache, AVC). Die Ausgabe avc: denied
in der folgenden Beispielantwort bestätigt, dass Fehler bei der Pod-Erstellung mit der SELinux-Erzwingung zusammenhängen.
type=AVC msg=audit(1627410995.808:9534): avc: denied { associate } for
pid=20660 comm="dockerd" name="/" dev="tmpfs" ino=186492
scontext=system_u:object_r:container_file_t:s0:c61,c201
tcontext=system_u:object_r:locale_t:s0 tclass=filesystem permissive=0
Die Ursache dieses Problems der Pod-Erstellung mit SELinux ist ein Kernel-Fehler in den folgenden Linux-Images:
- Red Hat Enterprise Linux (RHEL)-Releases vor 8.3
- CentOS-Releases vor 8.3
Sie können das Problem durch einen Neustart des Computers beheben.
Damit Fehler bei der Pod-Erstellung vermieden werden, verwenden Sie RHEL 8.3 oder höher oder CentOS 8.3 oder höher, da diese Versionen den Kernel-Fehler behoben haben.
Netzwerk
Quell-IP von Clients mit gebündeltem Layer-2-Load-Balancing
Wenn Sie die externe Trafficrichtlinie auf Local
setzen, können Routingfehler wie No route to host
für das gebündelte Layer-2-Load-Balancing auftreten. Die Richtlinie für externen Traffic ist standardmäßig auf Cluster
(externalTrafficPolicy: Cluster
) gesetzt. Mit dieser Einstellung verarbeitet Kubernetes den gesamten Cluster-Traffic. Dienste vom Typ LoadBalancer
oder NodePort
können externalTrafficPolicy: Local
verwenden, um die Quell-IP-Adresse des Clients beizubehalten.
Bei dieser Einstellung verarbeitet Kubernetes jedoch nur den lokalen Knoten-Traffic.
Wenn Sie die Quell-IP-Adresse des Clients beibehalten möchten, ist möglicherweise eine zusätzliche Konfiguration erforderlich, damit die Dienst-IP-Adressen erreichbar sind. Konfigurationsdetails finden Sie unter Gebündeltes Client-IP-Adressen beibehalten.
Durch Ändern von firewalld werden Cilium-iptable-Richtlinienketten gelöscht
Wenn Sie Anthos-Cluster on Bare-Metal ausführen und firewalld
entweder in CentOS oder Red Had Enterprise Linux (RHEL) aktiviert ist, können Änderungen an firewalld
die Cilium-iptables
-Ketten im Hostnetzwerk entfernen. Die iptables
-Ketten werden vom anetd
-Pod beim Start hinzugefügt. Der Verlust der Cilium-iptables
-Ketten führt dazu, dass die Pod-Verbindung zum Knoten außerhalb des Knotens unterbrochen wird.
Änderungen an firewalld
, die die iptables
-Ketten entfernen, sind unter anderem:
firewalld
mitsystemctl
neu startenfirewalld
mit dem Befehlszeilenclient neu laden (firewall-cmd --reload
)
Sie können dieses Verbindungsproblem beheben, indem Sie anetd
auf dem Knoten neu starten. Suchen Sie den anetd
-Pod und löschen Sie ihn mit den folgenden Befehlen, um anetd
neu zu starten:
kubectl get pods -n kube-system
kubectl delete pods -n kube-system ANETD_XYZ
Ersetzen Sie ANETD_XYZ durch den Namen des anetd
-Pods.
Doppelte egressSourceIP
-Adressen
Bei Verwendung der Feature-Vorschau des NAT-Gateways für ausgehenden Traffic besteht die Möglichkeit, Trafficauswahlregeln festzulegen, die eine egressSourceIP
-Adresse angeben, die bereits für ein anderes EgressNATPolicy
-Objekt verwendet wird. Dies kann zu Konflikten beim Routing von ausgehendem Traffic führen. Erkundigen Sie sich bei Ihrem Entwicklungsteam, welche Floating-IP-Adressen zur Verfügung stehen, bevor Sie die egressSourceIP
-Adresse in Ihrer benutzerdefinierten EgressNATPolicy
-Ressource angeben.
Pod-Verbindungsfehler aufgrund von E/A-Zeitüberschreitungen und Reverse-Pfadfilterung
Anthos-Cluster auf Bare Metal konfigurieren die Reverse-Pfadfilterung auf Knoten, um die Quellvalidierung (net.ipv4.conf.all.rp_filter=0
) zu deaktivieren. Wenn die Einstellung rp_filter
in 1
oder 2
geändert wird, schlagen Pods aufgrund von Zeitüberschreitungen außerhalb des Knotens fehl.
Beobachtete Verbindungsfehler, die mit IP-Adressen des Kubernetes-Dienstes kommunizieren, sind ein Symptom für dieses Problem. Im Folgenden finden Sie einige Beispiele für die möglichen Fehlertypen:
Wenn alle Pods für einen bestimmten Knoten nicht mit den Dienst-IP-Adressen kommunizieren, meldet der Pod
istiod
möglicherweise einen Fehler wie den folgenden:{"severity":"Error","timestamp":"2021-11-12T17:19:28.907001378Z", "message":"watch error in cluster Kubernetes: failed to list *v1.Node: Get \"https://172.26.0.1:443/api/v1/nodes?resourceVersion=5 34239\": dial tcp 172.26.0.1:443: i/o timeout"}
Für den auf jedem Knoten ausgeführten Daemon-Satz
localpv
wird im Log möglicherweise eine Zeitüberschreitung wie die folgende angezeigt:I1112 17:24:33.191654 1 main.go:128] Could not get node information (remaining retries: 2): Get https://172.26.0.1:443/api/v1/nodes/NODE_NAME: dial tcp 172.26.0.1:443: i/o timeout
Die Reverse-Pfadfilterung wird mit rp_filter
-Dateien im IPv4-Konfigurationsordner (net/ipv4/conf/all
) festgelegt. Mit dem Befehl sysctl
werden Einstellungen für die Reverse-Pfadfilterung in einer Netzwerksicherheits-Konfigurationsdatei gespeichert, z. B. /etc/sysctl.d/60-gce-network-security.conf
. Der Befehl sysctl
kann die Einstellung für die Reverse-Pfadfilterung überschreiben.
Zur Wiederherstellung der Pod-Verbindung können Sie net.ipv4.conf.all.rp_filter
entweder manuell auf 0
zurücksetzen oder den anetd
-Pod neu starten, um net.ipv4.conf.all.rp_filter
wieder auf 0
zurückzusetzen. Wenn Sie den Pod anetd
neu starten möchten, verwenden Sie die folgenden Befehle, um den Pod anetd
zu finden und zu löschen. Stattdessen wird ein neuer Pod anetd
gestartet:
kubectl get pods -n kube-system
kubectl delete pods -n kube-system ANETD_XYZ
Ersetzen Sie ANETD_XYZ
durch den Namen des anetd
-Pods.
Führen Sie den folgenden Befehl aus, um net.ipv4.conf.all.rp_filter
manuell festzulegen:
sysctl -w net.ipv4.conf.all.rp_filter = 0
Cluster-IP-Adressen vom Typ Bootstrap und IP-Adressen von Clusterknoten:
192.168.122.0/24
und 10.96.0.0/27
sind die Standard-Pod- und Dienst-CIDRs, die vom Bootstrap-Cluster (Typ) verwendet werden. Preflight-Prüfungen schlagen fehl, wenn sie sich mit IP-Adressen von Clusterknoten überschneiden. Zur Vermeidung des Konflikts können Sie die Flags --bootstrap-cluster-pod-cidr
und --bootstrap-cluster-service-cidr
an bmctl
übergeben, um andere Werte anzugeben.
Überlappende IP-Adressen in verschiedenen Clustern
Es gibt während der Aktualisierung keine Validierung für überlappende IP-Adressen über verschiedene Cluster hinweg. Die Validierung gilt nur beim Erstellen des Clusters/Knotenpools.
Betriebssystem
Fehler beim Erstellen oder Upgraden von Clustern unter CentOS
Im Dezember 2020 gab die CentOS-Community und Red Hat die Einstellung von CentOS bekannt.
Am 31. Januar 2022 erreicht CentOS 8 das Ende des Produktzyklus (End of Life, EOL). Aufgrund der EOL-Dauer funktionieren yum
-Repositories nicht mehr für CentOS, was dazu führt, dass Clustererstellung und Cluster-Upgrade-Vorgänge fehlschlagen. Dies gilt für alle unterstützten Versionen von CentOS und betrifft alle Versionen von Anthos-Clustern auf Bare-Metal.
Um das Problem zu umgehen, führen Sie die folgenden Befehle aus, damit Ihr CentOS einen Archiv-Feed verwendet:
sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-Linux-*
sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' \ /etc/yum.repos.d/CentOS-Linux-*
Als langfristige Lösung sollten Sie zu einem anderen unterstützten Betriebssystem migrieren.
Einschränkungen des Betriebssystem-Endpunkts
Bei RHEL und CentOS gibt es eine Beschränkung auf Clusterebene von 100.000 Endpunkten.
Diese Zahl ist die Summe aller Pods, auf die ein Kubernetes-Dienst verweist. Wenn zwei Dienste auf dieselbe Gruppe von Pods verweisen, wird dies als zwei separate Gruppen von Endpunkten gezählt. Die zugrunde liegende nftable
-Implementierung unter RHEL und CentOS führt diese Einschränkung aus. Es ist keine Systeminstabilität von Anthos-Cluster on Bare Metal.
Zurücksetzen/Löschen
Namespace löschen
Das Löschen eines Namespace verhindert, dass neue Ressourcen in diesem Namespace erstellt werden, einschließlich Jobs zum Zurücksetzen von Maschinen. Wenn Sie einen Nutzercluster löschen, müssen Sie zuerst das Clusterobjekt löschen, bevor Sie seinen Namespace löschen. Andernfalls können die Jobs zum Zurücksetzen der Maschinen nicht erstellt werden und beim Löschen wird der Bereinigungsvorgang der Maschine übersprungen.
containerd-Dienst
Mit dem Befehl bmctl reset
werden keine containerd
-Konfigurationsdateien oder -Binärdateien gelöscht. Der Dienst containerd systemd
bleibt aktiv.
Mit dem Befehl werden die Container gelöscht, in denen für den Knoten geplante Pods ausgeführt werden.