containerd-Konfiguration in GKE-Knoten anpassen

Autopilot Standard

Auf dieser Seite wird beschrieben, wie Sie die Konfiguration der containerd-Containerlaufzeit auf Ihren GKE-Knoten (Google Kubernetes Engine) anpassen. Bevor Sie dieses Dokument lesen, sollten Sie mit dem Konzept der Containerlaufzeit vertraut sein und wissen, warum es hilfreich sein kann, sie anzupassen.

containerd-Konfiguration in GKE

Sie können eine Reihe von Optionen in der containerd-Laufzeit manuell auf GKE-Knoten konfigurieren, auf denen ein Betriebssystem wie Container-Optimized OS ausgeführt wird. Wenn Sie die Laufzeit anpassen, können Sie spezielle Anforderungen wie den Zugriff auf private Image-Registries konfigurieren. Zum Festlegen dieser Optionen erstellen Sie eine YAML-Datei mit der Bezeichnung Laufzeitkonfigurationsdatei und übergeben die Datei beim Erstellen oder Aktualisieren eines Clusters an GKE.

Mit dieser Methode zur Anpassung von containerd können Sie die Bereitstellung privilegierter DaemonSets vermeiden, die ein Sicherheitsrisiko darstellen. Wenn Sie GKE eine Laufzeitkonfigurationsdatei bereitstellen, erstellt GKE Ihre Knoten neu und aktualisiert die containerd-Datei config.toml auf jedem Knoten mit Ihrer Konfiguration. Die Konfiguration bleibt über die Beendigung, Upgrades und Neuerstellungen von Knoten bestehen.

Mit der Laufzeitkonfigurationsdatei können Sie nur Optionen in containerd konfigurieren. GKE unterstützt auch die Konfiguration bestimmter kubelet-Optionen und Low-Level-Linux-Kernel-Optionen. Dazu wird eine separate Datei verwendet, die als Knotensystemkonfigurationsdatei bezeichnet wird. Weitere Informationen finden Sie unter Knotensystemkonfiguration anpassen.

Beschränkungen

Sie können eine Laufzeitkonfigurationsdatei nicht verwenden, um containerd-Einstellungen in Windows-Knoten-Images zu ändern.

Verfügbare containerd-Konfigurationsoptionen

In den folgenden Abschnitten werden die Optionen beschrieben, die Sie mit einer Laufzeitkonfigurationsdatei konfigurieren können.

Hinweis: Wenn Sie containerd-Registries festlegen, empfehlen wir die Verwendung der registryHosts-Konfiguration, die mehr Registrierungsfelder abdeckt, anstelle von privateRegistryAccessConfig. Und registryHosts überschreibt alle übereinstimmenden FQDNs in privateRegistryAccessConfig.

privateRegistryAccessConfig

Greifen Sie auf private Image-Registrys mit privaten Anmeldedaten zu, die Sie in Secret Manager speichern.

Diese Option ist ab GKE-Version 1.27.3-gke.1700 für Container-Optimized OS-Knoten-Images und ab Version 1.33 für Ubuntu-Knoten-Images verfügbar.

Eine Anleitung finden Sie unter Auf private Registrys mit privaten CA-Zertifikaten zugreifen.

privateRegistryAccessConfig:
  enabled: true
  certificateAuthorityDomainConfig:
  - gcpSecretManagerCertificateConfig:
    secretURI: "SECRET_LOCATION"
  fqdns:
  - "FQDN1"
  - "FQDN2"

Diese Konfiguration enthält die folgenden Felder:

• enabled: Ein boolescher Wert zum Aktivieren der Konfiguration einer privaten Registry. Wenn Sie enabled: false festlegen, löschen Sie alle anderen Felder im Element privateRegistryAccessConfig.
• certificateAuthorityDomainConfig: Enthält bis zu fünf Zertifikat- und FQDN-Definitionen.
• gcpSecretManagerCertificateConfig: Enthält ein in Secret Manager gespeichertes Zertifikat und ein Array von FQDNs.
• secretURI: Der Speicherort des Zertifikats im Secret Manager. privateRegistryAccessConfig unterstützt globale Secrets nur in secretURI.
• fqdns: Eine Liste vollständig qualifizierter Domainnamen privater Registries. Sie können auch IPv4-Adressen verwenden. Wir empfehlen jedoch die Verwendung des FQDN.

registryHosts

Konfigurieren Sie erweiterte Einstellungen für containerd-Registries, z. B. Funktionen, benutzerdefinierte Header und Zertifikate. Dies entspricht der hosts.toml von containerd.

Diese Option ist für GKE-Versionen 1.34.1-gke.2980000 oder höher verfügbar.

registryHosts:
- server: "REGISTRY_SERVER_FQDN"
  hosts:
  - host: "MIRROR_FQDN"
    capabilities:
    - "HOST_CAPABILITY_PULL"
    - "HOST_CAPABILITY_RESOLVE"
    - "HOST_CAPABILITY_PUSH"
    overridePath: false
    dialTimeout: "30s"
    header:
    - key: "HEADER_KEY"
      value:
      - "HEADER_VALUE_1"
      - "HEADER_VALUE_2"
    ca:
    - gcpSecretManagerSecretUri: "projects/PROJECT_ID_OR_NUMBER/secrets/CA_SECRET/versions/VERSION"
    client:
    - cert:
        gcpSecretManagerSecretUri: "projects/PROJECT_ID_OR_NUMBER/secrets/CLIENT_CERT_SECRET/versions/VERSION"
      key:
        gcpSecretManagerSecretUri: "projects/PROJECT_ID_OR_NUMBER/secrets/CLIENT_KEY_SECRET/versions/VERSION"

Diese Konfiguration enthält die folgenden Felder:

• server: Der Hostname des Registrierungsservers (z. B. example.com). Damit wird die Konfigurationsdatei auf dem Knoten benannt. Dies sollte ein voll qualifizierter Domainname oder eine IPv4-Adresse sein.
• hosts: Eine Liste der hostspezifischen Konfigurationen für die server.
• host: Der Hostname eines Registry-Spiegels (z. B. mirror.example.com). Dies sollten vollständig qualifizierte Domainnamen oder IPv4-Adressen sein.
• capabilities: Eine Liste von Funktionen, die angibt, welche Vorgänge ein Host ausführen kann. Folgende Werte werden unterstützt:
  • HOST_CAPABILITY_PULL: Stellt die Möglichkeit dar, Manifeste und Blobs nach Digest abzurufen.
  • HOST_CAPABILITY_RESOLVE: Stellt die Möglichkeit dar, Manifeste anhand des Namens abzurufen.
  • HOST_CAPABILITY_PUSH: Stellt die Möglichkeit dar, Blobs und Manifeste zu pushen.
  Wenn nichts angegeben ist, sind alle Funktionen aktiviert.
• overridePath: Boolescher Wert. Wenn true, wird der API-Root-Endpunkt des Hosts im URL-Pfad und nicht in der API-Spezifikation definiert. Dies kann mit nicht konformen OCI-Registries verwendet werden, bei denen das Präfix /v2 fehlt. Die Standardeinstellung ist false.
• dialTimeout: Ein Dauerstring (z. B. "30s"), der die maximal zulässige Dauer für den Abschluss eines Verbindungsversuchs angibt. Der maximal zulässige Wert beträgt "180s". Wenn nichts anderes festgelegt ist, wird von containerd standardmäßig "30s" verwendet. Der Wert muss eine Dezimalzahl in Sekunden mit dem Suffix s sein.
• header: Eine Liste benutzerdefinierter HTTP-Header, die an den Registry-Host gesendet werden sollen.
  • key: Der Headerschlüssel.
  • value: Eine Liste von Header-Werten.
• ca: Eine Liste der Zertifikatskonfigurationen für die Zertifizierungsstelle des Registry-Hosts. Eine Anleitung zum Erstellen von Secrets für Zertifikate und zum Konfigurieren der erforderlichen Berechtigungen finden Sie unter Öffentliche CA-Schlüssel in Secret Manager speichern.
  • gcpSecretManagerSecretUri: Der URI eines Secrets im Secret Manager, das das CA-Zertifikat enthält. Es unterstützt sowohl globale als auch regionale Secrets. Die Formate für die jeweiligen Secret-Typen sind folgende:
    • Globales Format für vertrauliche Daten: projects/PROJECT_ID_OR_NUMBER/secrets/SECRET_NAME/versions/VERSION.
    • Format des regionalen Secrets: projects/PROJECT_ID_OR_NUMBER/locations/REGION/secrets/SECRET_NAME/versions/VERSION.
• client: Eine Liste von Clientzertifikaten und Schlüsselpaaren für die Authentifizierung beim Registry-Host. Eine Anleitung zum Erstellen von Secrets für Zertifikate und zum Konfigurieren der erforderlichen Berechtigungen finden Sie unter Öffentliche CA-Schlüssel in Secret Manager speichern.
  • cert: Die Konfiguration des Clientzertifikats.
  • gcpSecretManagerSecretUri: Der URI eines Secrets im Secret Manager, das das Clientzertifikat enthält. Es unterstützt sowohl globale als auch regionale Secrets.
  • key: Die Konfiguration des privaten Clientschlüssels.
  • gcpSecretManagerSecretUri: Der URI eines Secrets im Secret Manager, das den Clientschlüssel enthält. Es unterstützt sowohl globale als auch regionale Secrets.

writableCgroups

Stellen Sie das /sys/fs/cgroup-Dateisystem im Lese-/Schreibmodus bereit, damit Arbeitslasten die Ressourcen ihrer untergeordneten Prozesse verwalten können.

Diese Option ist für GKE-Versionen 1.34.1-gke.2541000 oder höher verfügbar.

Weitere Informationen finden Sie unter Schreibbare Cgroups für Container konfigurieren.

writableCgroups:
  enabled: true

containerd-Konfiguration auf neue Cluster anwenden

In diesem Abschnitt erfahren Sie, wie Sie eine containerd-Konfigurationsdatei anwenden, wenn Sie einen neuen GKE-Cluster erstellen.

Führen Sie den folgenden Befehl aus, um Autopilot-Cluster zu erstellen:

gcloud container clusters create-auto CLUSTER_NAME \
    --location=LOCATION \
    --scopes="cloud-platform" \
    --containerd-config-from-file="PATH_TO_CONFIG_FILE"

Ersetzen Sie Folgendes:

• CLUSTER_NAME: Der Name des neuen Clusters.
• LOCATION: Der Compute Engine-Standort für Ihren neuen Cluster.
• PATH_TO_CONFIG_FILE: Der Pfad zur von Ihnen erstellten Konfigurationsdatei, z. B. ~/containerd-configuration.yaml.

Sie können die containerd-Konfiguration für neue Standardcluster aktivieren. Führen Sie dazu den Befehl gcloud container clusters create mit denselben Optionen aus.

containerd-Konfiguration auf neue Knotenpools anwenden

Sie können die containerd-Konfiguration mit dem folgenden Befehl auf einen neuen GKE-Knotenpool anwenden:

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --scopes="cloud-platform" \
    --containerd-config-from-file="PATH_TO_CONFIG_FILE"

Ersetzen Sie Folgendes:

• NODE_POOL_NAME ist der Name des neuen Knotenpools.
• CLUSTER_NAME den Namen des vorhandenen Clusters.
• LOCATION: Der Compute Engine-Standort für Ihren neuen Knotenpool.
• PATH_TO_CONFIG_FILE: Der Pfad zur von Ihnen erstellten Konfigurationsdatei, z. B. ~/containerd-configuration.yaml.

containerd-Konfiguration auf vorhandene Cluster anwenden

In diesem Abschnitt erfahren Sie, wie Sie eine containerd-Konfiguration auf vorhandene Cluster und Knoten anwenden.

Hinweis: Beim Aktualisieren eines Clusters mit einer containerd-Konfiguration werden die Knoten neu erstellt, um die Konfiguration anzuwenden. Dies kann zu vorübergehenden Unterbrechungen bei der Ausführung von Arbeitslasten führen. GKE erstellt Knoten nur dann neu, wenn automatische Upgrades aktiviert sind. Bei dieser Neuerstellung werden alle von Ihnen festgelegten Wartungsfenster berücksichtigt. In Standardclustern, für die keine automatischen Upgrades aktiviert sind, müssen Sie Ihre Knoten manuell neu erstellen, um die Konfiguration anzuwenden.

Zugriffsbereiche prüfen

Vorhandene Cluster müssen den Zugriffsbereich cloud-platform haben, um dieses Feature verwenden zu können. In diesem Abschnitt erfahren Sie, wie Sie Ihre Zugriffsbereiche prüfen und einen vorhandenen Cluster mit einer neuen oder geänderten Konfigurationsdatei für private Registrys aktualisieren.

Weitere Informationen zu den Standardzugriffsbereichen in neuen Clustern finden Sie unter Zugriffsbereiche in GKE.

Autopilot-Zugriffsbereiche prüfen

Führen Sie dazu diesen Befehl aus:

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --flatten=nodeConfig \
    --format='csv[delimiter="\\n",no-heading](oauthScopes)'

Wenn Ihr Cluster nicht den Zugriffsbereich https://www.googleapis.com/auth/cloud-platform hat, erstellen Sie einen neuen Cluster mit diesem Zugriffsbereich.

Standardzugriffsbereiche prüfen

Prüfen Sie die Zugriffsbereiche eines Standardclusters in einem Knotenpool:

gcloud container node-pools describe NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --format='value[delimiter="\\n"](config.oauthScopes)'

Ersetzen Sie NODE_POOL_NAME durch den Namen des Knotenpools.

Wenn Ihr Cluster nicht den Zugriffsbereich https://www.googleapis.com/auth/cloud-platform hat, erstellen Sie einen neuen Knotenpool mit dem Zugriffsbereich cloud-platform und löschen Sie den vorhandenen Knotenpool.

Cluster für die Verwendung der Konfigurationsdatei aktualisieren

Führen Sie dazu diesen Befehl aus:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --containerd-config-from-file="PATH_TO_CONFIG_FILE"

Knoten in Standardclustern neu erstellen

Wenn Ihr Standardcluster keine automatischen Upgrades verwendet, müssen Sie Ihre Knotenpools manuell neu erstellen, um die neue Konfiguration anzuwenden. Wenn Sie eine manuelle Knotenneuerstellung auslösen möchten, aktualisieren Sie Ihren Cluster auf die bereits verwendete GKE-Version.

gcloud container clusters upgrade CLUSTER_NAME \
    --location=LOCATION \
    --cluster-version=VERSION

Ersetzen Sie VERSION durch die GKE-Patchversion, die der Cluster bereits verwendet.

containerd-Konfigurationsoptionen deaktivieren

privateRegistryAccessConfig deaktivieren

1. Aktualisieren Sie Ihre Konfigurationsdatei, um enabled: false in privateRegistryAccessConfig anzugeben, und löschen Sie alle anderen Felder im Element, wie im folgenden Beispiel:

   privateRegistryAccessConfig:
     enabled: false

2. Wenden Sie aktualisierte Konfiguration auf Ihrem Cluster an. Eine Anleitung finden Sie unter containerd-Konfiguration auf vorhandene Cluster anwenden.

registryHosts deaktivieren

1. Aktualisieren Sie Ihre Konfigurationsdatei, um ein leeres Array im registryHosts-Element anzugeben, wie im folgenden Beispiel:

   registryHosts: []

2. Wenden Sie aktualisierte Konfiguration auf Ihrem Cluster an. Eine Anleitung finden Sie unter containerd-Konfiguration auf vorhandene Cluster anwenden.