containerd-Konfiguration in GKE-Knoten anpassen

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.

privateRegistryAccessConfig

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

Diese Option ist in GKE-Version 1.27.3-gke.1700 oder höher für Container-Optimized OS-Knoten-Images und in Version 1.33 oder höher 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, um die Konfiguration der privaten Registry zu aktivieren. Wenn Sie enabled: false festlegen, löschen Sie alle anderen Felder im privateRegistryAccessConfig Element.
  • 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 in Secret Manager. privateRegistryAccessConfig unterstützt nur globale Secrets in secretURI.
  • fqdns: Eine Liste vollständig qualifizierter Domainnamen von privaten 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 Datei „hosts.toml“ von containerd.

Diese Option ist für GKE-Version 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 Registry-Servers (z. B. example.com). Damit wird die Konfigurationsdatei auf dem Knoten benannt. Dies muss ein voll qualifizierter Domainname oder eine IP-Adresse ohne Schema, Port oder Pfad sein.
  • hosts: Eine Liste hostspezifischer Konfigurationen für den server.
  • host: Der Hostname eines Registry-Spiegels (z. B. https://mirror.example.com:8000/1234, 1.2.3.4:80). Dies müssen voll qualifizierte Domainnamen oder IP-Adressen sein. Schema, Port und Pfad werden unterstützt. Das Schema kann nur http oder https sein.
  • capabilities: Eine Liste von Funktionen, die angeben, welche Vorgänge ein Host ausführen kann. Unterstützte Werte:
    • HOST_CAPABILITY_PULL: Stellt die Möglichkeit dar, Manifeste und Blobs per Digest abzurufen.
    • HOST_CAPABILITY_RESOLVE: Stellt die Möglichkeit dar, Manifeste nach Namen abzurufen.
    • HOST_CAPABILITY_PUSH: Stellt die Möglichkeit dar, Blobs und Manifeste zu übertragen.
    Wenn nichts angegeben ist, sind alle Funktionen aktiviert.
  • overridePath: Ein boolescher Wert. Wenn true, gibt an, dass der API-Stammendpunkt des Hosts im URL-Pfad und nicht in der API-Spezifikation definiert ist. Dies kann mit nicht konformen OCI-Registries verwendet werden, 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 ist "180s". Wenn nichts festgelegt ist, wird von containerd standardmäßig "30s" festgelegt. 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 Headerwerten.
  • ca: Eine Liste von Zertifikatkonfigurationen für die Zertifizierungsstelle des Registry-Hosts. Informationen zum Erstellen eines 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 in Secret Manager, das das CA-Zertifikat enthält. Es werden sowohl globale als auch regionale Secrets unterstützt. Die Formate für die jeweiligen Secret-Typen sind:
      • Format für globale Secrets: projects/PROJECT_ID_OR_NUMBER/secrets/SECRET_NAME/versions/VERSION.
      • Format für regionale Secrets: projects/PROJECT_ID_OR_NUMBER/locations/REGION/secrets/SECRET_NAME/versions/VERSION.
  • client: Eine Liste von Clientzertifikat- und Schlüsselpaaren für die Authentifizierung beim Registry-Host. Informationen zum Erstellen eines 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 in Secret Manager, das das Clientzertifikat enthält. Es werden sowohl globale als auch regionale Secrets unterstützt.
    • key: Die Konfiguration des privaten Clientschlüssels.
      • gcpSecretManagerSecretUri: Der URI eines Secrets in Secret Manager, das den Clientschlüssel enthält. Es werden sowohl globale als auch regionale Secrets unterstützt.

writableCgroups

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

Diese Option ist für GKE-Version 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 gcloud container clusters create Befehl 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: Der Name des neuen Knotenpools.
  • CLUSTER_NAME: Der Name 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.

Zugriffsbereiche prüfen

Wenn Ihre Konfigurationsdatei Secrets aus Secret Manager verwendet, muss Ihr Cluster oder Knotenpool den Zugriffsbereich cloud-platform haben. In diesem Abschnitt erfahren Sie, wie Sie Ihre Zugriffsbereiche prüfen und einen vorhandenen Cluster mit einer neuen oder geänderten Laufzeitkonfigurationsdatei 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 Sie Secrets aus Secret Manager verwenden und Ihr Cluster nicht den https://www.googleapis.com/auth/cloud-platform Zugriffsbereich 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 Sie Secrets aus Secret Manager verwenden und Ihr Cluster nicht den https://www.googleapis.com/auth/cloud-platform Zugriffsbereich hat, erstellen Sie einen neuen Knoten pool mit dem cloud-platform Zugriffsbereich 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.