Private Cluster erstellen

Auf dieser Seite wird erläutert, wie Sie einen privaten Cluster in Google Kubernetes Engine (GKE) erstellen. Die Knoten in einem privaten Cluster haben nur interne IP-Adressen vom Typ RFC 1918. Ihre Arbeitslasten sind dadurch vom öffentlichen Internet isoliert. Weitere Informationen zur Funktionsweise von privaten Clustern finden Sie unter Private Cluster.

Vorbereitung

Machen Sie sich mit den Anforderungen, Beschränkungen und Einschränkungen vertraut, bevor Sie mit dem nächsten Schritt fortfahren.

Bevor Sie beginnen, müssen Sie die folgenden Aufgaben ausgeführt haben:

Richten Sie die Standardeinstellungen für gcloud mithilfe einer der folgenden Methoden ein:

  • Verwenden Sie gcloud init, wenn Sie bei der Festlegung der Standardeinstellungen unterstützt werden möchten.
  • Verwenden Sie gcloud config, um Ihre Projekt-ID, Zone und Region individuell festzulegen.

Gcloud init verwenden

  1. Führen Sie gcloud init aus und folgen Sie der Anleitung:

    gcloud init

    Wenn Sie SSH auf einem Remote-Server verwenden, können Sie mit dem Flag --console-only verhindern, dass der Befehl einen Browser startet:

    gcloud init --console-only
  2. Folgen Sie der Anleitung, um gcloud für die Verwendung Ihres Google Cloud-Kontos zu autorisieren.
  3. Erstellen Sie eine neue Konfiguration oder wählen Sie eine vorhandene Konfiguration aus.
  4. Wählen Sie ein Google Cloud-Projekt aus.
  5. Wählen Sie eine Compute Engine-Standardzone aus.

gcloud config verwenden

  • Geben Sie Ihre standardmäßige Projekt-ID an:
    gcloud config set project project-id
  • Wenn Sie mit zonalen Clustern arbeiten, legen Sie die Standardzone für Compute Engine fest:
    gcloud config set compute/zone compute-zone
  • Wenn Sie mit regionalen Clustern arbeiten, legen Sie die Standardregion für Compute Engine fest:
    gcloud config set compute/region compute-region
  • Aktualisieren Sie gcloud auf die neueste Version:
    gcloud components update

Zugriff auf den Master

In privaten Clustern hat der Master einen privaten und einen öffentlichen Endpunkt. Es gibt drei Konfigurationskombinationen, um den Zugriff auf die Clusterendpunkte zu steuern.

  • Zugriff auf öffentliche Endpunkte ist deaktiviert. Damit wird ein privater Cluster ohne Clientzugriff auf den öffentlichen Endpunkt erstellt.
  • Zugriff auf öffentliche Endpunkte ist aktiviert und autorisierte Masternetzwerke sind aktiviert. Damit wird ein privater Cluster mit beschränktem Zugriff auf den öffentlichen Endpunkt erstellt.
  • Zugriff auf öffentliche Endpunkte ist aktiviert und autorisierte Masternetzwerke sind deaktiviert. Damit wird ein privater Cluster mit unbeschränktem Zugriff auf den öffentlichen Endpunkt erstellt.

Eine Übersicht über die Unterschiede zwischen den oben genannten Konfigurationsoptionen finden Sie unter Zugriff auf Clusterendpunkte.

Privaten Cluster ohne Clientzugriff auf den öffentlichen Endpunkt erstellen

In diesem Abschnitt erstellen Sie einen privaten Cluster mit privaten Knoten und ohne Zugriff auf den öffentlichen Endpunkt.

gcloud

Führen Sie den folgenden Befehl aus:

    gcloud container clusters create private-cluster-0 \
        --create-subnetwork name=my-subnet-0 \
        --enable-master-authorized-networks \
        --enable-ip-alias \
        --enable-private-nodes \
        --enable-private-endpoint \
        --master-ipv4-cidr 172.16.0.32/28 \
        --no-enable-basic-auth \
        --no-issue-client-certificate

Dabei gilt:

  • --enable-master-authorized-networks gibt an, dass der Zugriff auf den öffentlichen Endpunkt auf von Ihnen autorisierte IP-Adressbereiche beschränkt ist.
  • --create-subnetwork name=my-subnet-0 legt fest, dass GKE automatisch ein Subnetz mit dem Namen my-subnet-0 erstellt.
  • --enable-ip-alias sorgt dafür, dass der Cluster VPC-nativ ist.
  • --enable-private-nodes gibt an, dass die Knoten des Clusters keine externen IP-Adressen haben.
  • --master-ipv4-cidr 172.16.0.32/28 legt einen RFC 1918-Bereich für den Master fest. Dies ist eine dauerhafte Einstellung für diesen Cluster.

Console

Führen Sie diese Schritte aus:

  1. Rufen Sie in der Google Cloud Console das GKE-Menü auf.

    Zum GKE-Menü

  2. Klicken Sie auf Cluster erstellen.

  3. Wählen Sie die Vorlage für Standardcluster oder eine für die Arbeitslast geeignete Vorlage aus.

  4. Geben Sie für Name den Wert my-subnet-0 ein.

  5. Klicken Sie unten im Menü auf Verfügbarkeit, Netzwerk, Sicherheit und weitere Funktionen.

  6. Klicken Sie unter VPC nativ auf das Kästchen VPC nativ aktivieren (mit Alias-IP). Übernehmen Sie im Drop-down-Menü Netzwerk die Einstellung default und im Drop-down-Menü Knotensubnetz die Einstellung default. GKE generiert damit ein Subnetz für den Cluster.

  7. Klicken Sie unter Netzwerksicherheit auf das Kästchen Privater Cluster.

  8. Entfernen Sie das Häkchen aus dem Kästchen Mit externer IP-Adresse auf Master zugreifen.

  9. Legen Sie für Master-IP-Bereich den Wert 172.16.0.32/28 fest.

  10. Das Kästchen Autorisierte Masternetzwerke aktivieren wird automatisch ausgewählt.

  11. Entfernen Sie das Häkchen aus dem Kästchen Kubernetes-Dashboard aktivieren.

  12. Entfernen Sie das Häkchen aus dem Kästchen Clientzertifikat ausstellen.

  13. Klicken Sie auf Erstellen.

API

Zum Erstellen eines Clusters mit einem öffentlich erreichbaren Master legen Sie für das Feld enablePrivateEndpoint: true in der Ressource privateClusterConfig einen Wert fest.

Dies sind an diesem Punkt die einzigen IP-Adressen mit Zugriff auf den Clustermaster:

  • Der primäre Bereich von my-subnet-0
  • Der für Pods verwendete sekundäre Bereich

Angenommen, Sie haben im primären Bereich von my-subnet-0 eine VM erstellt. Dann können Sie für diese VM kubectl konfigurieren, um die interne IP-Adresse des Masters zu verwenden.

Wenn Sie auf den Clustermaster außerhalb von my-subnet-0 zugreifen möchten, müssen Sie mindestens einen Adressbereich autorisieren, damit Zugriff auf den privaten Endpunkt möglich ist.

Angenommen, Sie haben eine VM im Standardnetzwerk in der Region Ihres Clusters, aber nicht in my-subnet-0.

Beispiel:

  • my-subnet-0: 10.0.0.0/22
  • Sekundärer Bereich für Pods: 10.52.0.0/14
  • VM-Adresse: 10.128.0.3

Sie können der VM mit folgendem Befehl Zugriff auf den Master gewähren:

    gcloud container clusters update private-cluster-0 \
        --enable-master-authorized-networks \
        --master-authorized-networks 10.128.0.3/32

Privaten Cluster mit beschränktem Zugriff auf den öffentlichen Endpunkt erstellen

Beim Erstellen eines privaten Clusters mit dieser Konfiguration können Sie ein automatisch generiertes Subnetz oder ein benutzerdefiniertes Subnetz auswählen.

Automatisch generiertes Subnetz verwenden

In diesem Abschnitt erstellen Sie einen privaten Cluster mit dem Namen des Orts, an dem GKE automatisch ein Subnetz für Ihre Clusterknoten generiert. Für das Subnetz ist der private Google-Zugriff aktiviert. GKE erstellt im Subnetz automatisch zwei sekundäre Bereiche: einen für Pods und einen für Dienste.

gcloud

Führen Sie den folgenden Befehl aus:

    gcloud container clusters create private-cluster-1 \
        --create-subnetwork name=my-subnet-1 \
        --enable-master-authorized-networks \
        --enable-ip-alias \
        --enable-private-nodes \
        --master-ipv4-cidr 172.16.0.0/28 \
        --no-enable-basic-auth \
        --no-issue-client-certificate

Dabei gilt:

  • --enable-master-authorized-networks gibt an, dass der Zugriff auf den öffentlichen Endpunkt auf von Ihnen autorisierte IP-Adressbereiche beschränkt ist.
  • --create-subnetwork name=my-subnet-1 legt fest, dass GKE automatisch ein Subnetz mit dem Namen my-subnet-1 erstellt.
  • --enable-ip-alias sorgt dafür, dass der Cluster VPC-nativ ist.
  • --enable-private-nodes gibt an, dass die Knoten des Clusters keine externen IP-Adressen haben.
  • --master-ipv4-cidr 172.16.0.0/28 legt einen RFC 1918-Bereich für den Master fest. Dies ist eine dauerhafte Einstellung für diesen Cluster.

Console

Führen Sie diese Schritte aus:

  1. Rufen Sie in der Google Cloud Console das GKE-Menü auf.

    Zum GKE-Menü

  2. Klicken Sie auf Cluster erstellen.

  3. Wählen Sie die Vorlage für Standardcluster oder eine für die Arbeitslast geeignete Vorlage aus.

  4. Geben Sie für Name den Wert my-subnet-1 ein.

  5. Klicken Sie unten im Menü auf Verfügbarkeit, Netzwerk, Sicherheit und weitere Funktionen.

  6. Behalten Sie unter VPC-nativ das Häkchen im Kästchen VPC nativ aktivieren (mit Alias-IP) bei Übernehmen Sie im Drop-down-Menü Netzwerk die Einstellung default und im Drop-down-Menü Knotensubnetz die Einstellung default. GKE generiert damit ein Subnetz für den Cluster.

  7. Klicken Sie unter Netzwerksicherheit auf das Kästchen Privater Cluster.

  8. Wenn Sie einen Master erstellen möchten, auf den von autorisierten externen IP-Bereichen zugegriffen werden kann, lassen Sie das Kästchen Mit externer IP-Adresse auf Master zugreifen ausgewählt.

  9. Legen Sie für Master-IP-Bereich den Wert 172.16.0.0/28 fest.

  10. Behalten Sie das Häkchen im Kästchen Autorisierte Masternetzwerke aktivieren bei.

  11. Entfernen Sie das Häkchen aus dem Kästchen Kubernetes-Dashboard aktivieren.

  12. Entfernen Sie das Häkchen aus dem Kästchen Clientzertifikat ausstellen.

  13. Klicken Sie auf Erstellen.

API

Legen Sie für das Feld privateClusterConfig in der API-Ressource Cluster einen Wert fest:

{
      "name": "private-cluster-1",
      ...
      "ipAllocationPolicy": {
        "createSubnetwork": true,
      },
      ...
        "privateClusterConfig" {
          "enablePrivateNodes": boolean # Creates nodes with internal IP addresses only
          "enablePrivateEndpoint": boolean # false creates a cluster master with a publicly-reachable endpoint
          "masterIpv4CidrBlock": string # CIDR block for the cluster master
          "privateEndpoint": string # Output only
          "publicEndpoint": string # Output only
      }
    }

Dies sind an diesem Punkt die einzigen IP-Adressen mit Zugriff auf den Clustermaster:

  • Der primäre Bereich von my-subnet-1
  • Der für Pods verwendete sekundäre Bereich

Angenommen, Sie haben außerhalb Ihres VPC-Netzwerks eine Gruppe von Computern mit Adressen im Bereich 203.0.113.0/29. Diesen Computern können Sie mit dem folgenden Befehl Zugriff auf den öffentlichen Endpunkt gewähren:

    gcloud container clusters update private-cluster-1 \
        --enable-master-authorized-networks \
        --master-authorized-networks 203.0.113.0/29

Dies sind jetzt die einzigen IP-Adressen mit Zugriff auf den Clustermaster:

  • Der primäre Bereich von my-subnet-1
  • Der für Pods verwendete sekundäre Bereich
  • Von Ihnen autorisierte Adressbereiche, beispielsweise 203.0.113.0/29

Benutzerdefiniertes Subnetz verwenden

In diesem Abschnitt legen Sie einen privaten Cluster mit dem Namen private-cluster-2 an. Sie erstellen das Netzwerk my-net-0 und außerdem das Subnetz my-subnet-2 mit dem primären Bereich 192.168.0.0/20 für Ihre Clusterknoten. Das Subnetz hat zwei sekundäre Adressbereiche: my-pods-1 für die Pod-IP-Adressen und my-services-1 für die Dienst-IP-Adressen.

gcloud

Netzwerk erstellen

Erstellen Sie als Erstes ein Netzwerk für den Cluster. Mit dem folgenden Befehl wird das Netzwerk my-net-0 angelegt:

    gcloud compute networks create my-net-0 \
        --subnet-mode custom

Subnetz und sekundäre Bereiche erstellen

Erstellen Sie als Nächstes das Subnetz my-subnet-2 im Netzwerk my-net-0 mit den sekundären Bereichen my-pods-2 für Pods und my-services-2 für Dienste:

    gcloud compute networks subnets create my-subnet-2 \
        --network my-net-0\
        --region us-central1 \
        --range 192.168.0.0/20 \
        --secondary-range my-pods-2=10.4.0.0/14,my-services-2=10.0.32.0/20 \
        --enable-private-ip-google-access

Privaten Cluster erstellen

Erstellen Sie im nächsten Schritt den privaten Cluster private-cluster-1 mit dem Netzwerk, dem Subnetz und den sekundären Bereichen, die Sie angelegt haben.

    gcloud container clusters create private-cluster-1 \
        --zone us-central1-c \
        --enable-master-authorized-networks \
        --network my-net-0 \
        --subnetwork my-subnet-2 \
        --cluster-secondary-range-name my-pods-2 \
        --services-secondary-range-name my-services-2 \
        --enable-private-nodes \
        --enable-ip-alias \
        --master-ipv4-cidr 172.16.0.16/28 \
        --no-enable-basic-auth \
        --no-issue-client-certificate

Console

Netzwerk, Subnetz und sekundäre Bereiche erstellen

  1. Rufen Sie in der Cloud Console die Seite "VPC-Netzwerke" auf.

    Zur VPC-Netzwerkseite

  2. Klicken Sie auf VPC-Netzwerk erstellen.

  3. Geben Sie my-net-0 unter Name ein.

  4. Achten Sie darauf, dass der Modus für Subnetzerstellung auf Benutzerdefiniert eingestellt ist.

  5. Geben Sie unter Neues Subnetz in Name my-subnet-2 ein.

  6. Wählen Sie im Drop-down-Menü Region die gewünschte Region aus.

  7. Geben Sie 192.168.0.0/20 als IP-Adressbereich ein.

  8. Klicken Sie auf Sekundären IP-Bereich erstellen. Geben Sie für Name des Subnetzbereichs den Wert my-services-1 und für Sekundärer IP-Bereich den Wert 10.0.32.0/20 ein.

  9. Klicken Sie auf IP-Bereich hinzufügen. Geben Sie für Name des Subnetzbereichs den Wert my-pods-1 und für Sekundärer IP-Bereich den Wert 10.4.0.0/14 ein.

  10. Klicken Sie unter Privater Google-Zugriff auf An.

  11. Klicken Sie auf Fertig.

  12. Klicken Sie auf Erstellen.

Privaten Cluster erstellen

Erstellen Sie einen privaten Cluster, der Ihr Subnetz verwendet:

  1. Rufen Sie in der Cloud Console das GKE-Menü auf.

    Zum GKE-Menü

  2. Klicken Sie auf Cluster erstellen.

  3. Wählen Sie die Vorlage für Standardcluster oder eine für die Arbeitslast geeignete Vorlage aus.

  4. Geben Sie für Name den Wert private-cluster-2 ein.

  5. Klicken Sie unten im Menü auf Verfügbarkeit, Netzwerk, Sicherheit und weitere Funktionen.

  6. Behalten Sie unter VPC-nativ das Häkchen im Kästchen VPC nativ aktivieren (mit Alias-IP) bei .

  7. Wählen Sie im Drop-down-Menü Netzwerk die Option my-net-1 aus.

  8. Wählen Sie im Drop-down-Menü Knotensubnetz die Option my-subnet-2 aus.

  9. Entfernen Sie das Häkchen des Kästchens Sekundäre Bereiche automatisch erstellen.

  10. Wählen Sie im Drop-down-Menü Sekundärer Pod-CIDR-Bereich die Option my-pods-1 aus.

  11. Wählen Sie im Drop-down-Menü Sekundärer CIDR-Dienstbereich die Option my-services-1 aus.

  12. Klicken Sie dann unter Netzwerksicherheit das Kästchen für Privater Cluster an.

  13. Legen Sie den Master-IP-Bereich auf 172.16.0.16/28 fest.

  14. Behalten Sie das Häkchen im Kästchen Autorisierte Masternetzwerke aktivieren bei.

  15. Entfernen Sie das Häkchen aus dem Kästchen Kubernetes-Dashboard aktivieren.

  16. Entfernen Sie das Häkchen aus dem Kästchen Clientzertifikat ausstellen.

  17. Klicken Sie auf Erstellen.

Dies sind an diesem Punkt die einzigen IP-Adressen mit Zugriff auf den Clustermaster:

  • Der primäre Bereich von my-subnet-2
  • Der sekundäre Bereich my-pods-1

Angenommen, Sie haben eine Gruppe von Computern außerhalb von my-net-1 mit Adressen im Bereich 203.0.113.0/29. Diesen Computern können Sie mit dem folgenden Befehl Zugriff auf den öffentlichen Endpunkt gewähren:

    gcloud container clusters update private-cluster-1 \
        --enable-master-authorized-networks \
        --master-authorized-networks 203.0.113.0/29

Dies sind an diesem Punkt die einzigen IP-Adressen mit Zugriff auf den Clustermaster:

  • Der primäre Bereich von my-subnet-2
  • Der sekundäre Bereich my-pods-1
  • Von Ihnen autorisierte Adressbereiche, beispielsweise 203.0.113.0/29

Mit Cloud Shell auf einen privaten Cluster zugreifen

Für den privaten Cluster private-cluster-1, den Sie in der vorherigen Übung erstellt haben, sind ein öffentlicher Endpunkt und autorisierte Masternetzwerke aktiviert. Wenn Sie mit Cloud Shell auf den Cluster zugreifen möchten, müssen Sie die öffentliche IP-Adresse von Cloud Shell der Liste der autorisierten Masternetzwerke des Clusters hinzufügen.

Sie gehen dazu so vor:

  1. Ermitteln Sie im Cloud Shell-Befehlszeilenfenster mit dig die externe IP-Adresse von Cloud Shell:

    dig +short myip.opendns.com @resolver1.opendns.com

  2. Fügen Sie die externe Adresse von Cloud Shell der Liste der autorisierten Masternetzwerke Ihres Clusters hinzu:

    gcloud container clusters update private-cluster-1 \
        --zone us-central1-c \
        --enable-master-authorized-networks \
        --master-authorized-networks existing-auth-nets,shell-IP/32

    Dabei gilt:

    • existing-auth-networks ist Ihre bestehende Liste autorisierter Masternetzwerke. Sie finden Ihre autorisierten Masternetzwerke in der Console oder durch Ausführen des folgenden Befehls: gcloud container clusters describe private-cluster-1 --format "flattened(masterAuthorizedNetworksConfig.cidrBlocks[])".
    • shell-IP ist die externe IP-Adresse von Cloud Shell.

  3. Rufen Sie die Anmeldedaten ab, damit Sie kubectl für den Zugriff auf den Cluster verwenden können:

    gcloud container clusters get-credentials private-cluster-1 \
        --zone us-central1-a \
        --project project-id

    project-id ist Ihre Projekt-ID.

Jetzt können Sie mit kubectl in Cloud Shell auf Ihren privaten Cluster zugreifen. Beispiel:

kubectl get nodes

Privaten Cluster mit unbeschränktem Zugriff auf den öffentlichen Endpunkt erstellen

In diesem Abschnitt erstellen Sie einen privaten Cluster, bei dem jede IP-Adresse auf den Master zugreifen kann.

gcloud

Führen Sie den folgenden Befehl aus:

    gcloud container clusters create private-cluster-2 \
        --create-subnetwork name=my-subnet-3 \
        --no-enable-master-authorized-networks \
        --enable-ip-alias \
        --enable-private-nodes \
        --master-ipv4-cidr 172.16.0.32/28 \
        --no-enable-basic-auth \
        --no-issue-client-certificate

Dabei gilt:

  • --no-enable-master-authorized-networks deaktiviert autorisierte Netzwerke für den Cluster.
  • --create-subnetwork name=my-subnet-3 legt fest, dass GKE automatisch ein Subnetz mit dem Namen my-subnet-3 erstellt.
  • --enable-ip-alias sorgt dafür, dass der Cluster VPC-nativ ist.
  • --enable-private-nodes gibt an, dass die Knoten des Clusters keine externen IP-Adressen haben.
  • --master-ipv4-cidr 172.16.0.32/28 legt einen RFC 1918-Bereich für den Master fest. Dies ist eine dauerhafte Einstellung für diesen Cluster.

Console

Führen Sie diese Schritte aus:

  1. Rufen Sie in der Google Cloud Console das GKE-Menü auf.

    Zum GKE-Menü

  2. Klicken Sie auf Cluster erstellen.

  3. Wählen Sie die Vorlage für Standardcluster oder eine für die Arbeitslast geeignete Vorlage aus.

  4. Geben Sie für Name den Wert private-cluster-2 ein.

  5. Klicken Sie unten im Menü auf Verfügbarkeit, Netzwerk, Sicherheit und weitere Funktionen.

  6. Klicken Sie unter VPC nativ auf das Kästchen VPC nativ aktivieren (mit Alias-IP). Übernehmen Sie im Drop-down-Menü Netzwerk die Einstellung default und im Drop-down-Menü Knotensubnetz die Einstellung default. GKE generiert damit ein Subnetz für den Cluster.

  7. Klicken Sie unter Netzwerksicherheit auf das Kästchen Privater Cluster.

  8. Entfernen Sie das Häkchen aus dem Kästchen Mit externer IP-Adresse auf Master zugreifen.

  9. Legen Sie für Master-IP-Bereich den Wert 172.16.0.32/28 fest.

  10. Entfernen Sie das Häkchen aus dem Kästchen Autorisierte Masternetzwerke aktivieren automatisch.

  11. Entfernen Sie das Häkchen aus dem Kästchen Kubernetes-Dashboard aktivieren.

  12. Entfernen Sie das Häkchen aus dem Kästchen Clientzertifikat ausstellen.

  13. Klicken Sie auf Erstellen.

Weitere Konfigurationen privater Cluster

Neben den vorherigen Konfigurationen können private Cluster auch mit den im Folgenden aufgeführten Konfigurationen ausgeführt werden.

Privaten Knoten ausgehenden Internetzugriff gewähren

Wenn Sie privaten Knoten ausgehenden Internetzugriff gewähren möchten, können Sie Cloud NAT verwenden oder Ihr eigenes NAT-Gateway verwalten.

Privaten Cluster in einem freigegebenen VPC-Netzwerk erstellen

Informationen zum Erstellen eines privaten Clusters in einem freigegebenen VPC-Netzwerk finden Sie unter Privaten Cluster in einer freigegebenen VPC erstellen.

Windows Server-Containeranwendung auf einem privaten Cluster bereitstellen

Informationen zum Bereitstellen einer Windows Server-Containeranwendung für einen privaten Cluster finden Sie in der Windows-Knotenpooldokumentation.

Routing zwischen lokaler bzw. Cluster-VPC und Clustermaster

Wenn Sie einen privaten GKE-Cluster mit einem privaten Masterendpunkt erstellen, kann der Clustermaster nicht über das öffentliche Internet aufgerufen werden. Clientseitige Tools wie kubectl müssen jedoch darauf zugreifen können. Um Traffic zwischen dem Clustermaster und Ihrem lokalen Netzwerk zu ermöglichen, müssen Routen zwischen dem lokalen Netzwerk und dem Google-eigenen VPC-Netzwerk vorhanden sein, das den Clustermaster hostet.

Diagramm zum Routing zwischen der lokalen VPC und dem Cluster-Master

Die Google VPC exportiert die Route zum Master-CIDR mithilfe von Cloud VPN oder Cloud Interconnect automatisch an Ihre VPC, die mit Ihrem lokalen Netzwerk verbunden ist. Die Route zu Ihrer lokalen Umgebung muss aber auch von Ihrer VPC in die Google VPC exportiert werden.

Aktivieren Sie zum Freigeben der Routen das Flag --export-custom-routes beim Peering zwischen Ihrer VPC und der Google-eigenen VPC.

  1. Identifizieren Sie das Peering zwischen der VPC für Ihren Cluster und der Google-eigenen VPC:

        gcloud container clusters describe cluster-name

    Die Ausgabe dieses Befehls enthält das Feld privateClusterConfig.peeringName des Clusters. Dies ist der Name des Peering-Vorgangs zwischen Ihrem Cluster und der Google-eigenen VPC. Beispiel:

        privateClusterConfig:
    enablePrivateNodes: true
    masterIpv4CidrBlock: 172.16.1.0/28
    peeringName: gke-1921aee31283146cdde5-9bae-9cf1-peer
    privateEndpoint: 172.16.1.2
    publicEndpoint: 34.68.128.12

  2. Aktivieren Sie --export-custom-routes für das Peering:

        gcloud compute networks peerings update peering --network network \
       --export-custom-routes

    Dabei gilt: peering ist der Wert von privateClusterConfig.peeringName, den Sie im vorherigen Schritt abgerufen haben, und network der Name Ihrer VPC.

    Dieses Flag legt fest, dass network seine Routen der Google-eigenen VPC anbietet, in der sich der Clustermaster befindet. Im nächsten Schritt wird erläutert, wie die Route von Ihrer VPC der Google-eigenen VPC in Ihrer lokalen Umgebung angeboten wird.

  3. Die Route zum Cluster-Master-CIDR muss auch von Ihrer VPC aus in Ihrer lokalen Umgebung angeboten werden. Dafür haben Sie die beiden folgenden Möglichkeiten:

    • Empfohlene Methode: Bieten Sie die Route zum Mastersubnetz als benutzerdefinierte Route über das eBGP von Cloud Router an. Weitere Informationen finden Sie unter Benutzerdefinierte IP-Bereiche anbieten. Diese Methode wird empfohlen, da die beworbenen Routen entfernt werden, wenn das eBGP nicht verfügbar und so der Traffic beeinträchtigt ist.

    • Stellen Sie eine statische Route auf dem lokalen Router oder Edge-Gerät für Google Cloud bereit.

Aktivierung des Exports benutzerdefinierter Routen prüfen

Prüfen Sie mithilfe des folgenden Befehls, ob die Option --export-custom-routes beim Peering zwischen Ihrer VPC und der Google-eigenen VPC aktiviert ist:

    gcloud compute networks peerings list

In der Ausgabe dieses Befehls werden die Peerings Ihres Compute Engine-Netzwerks aufgelistet. Suchen Sie den Peering-Vorgang, dessen Namen Sie im ersten Schritt des obigen Vorgehens ermittelt haben, und achten Sie darauf, dass die Spalte EXPORT_CUSTOM_ROUTES den Wert True und die Spalte STATE den Wert ACTIVE hat.

Export benutzerdefinierter Routen deaktivieren

So deaktivieren Sie den Export benutzerdefinierter Routen aus Ihrer VPC:

    gcloud compute networks peerings update peering --network network --no-export-custom-routes

Dabei gilt:

  • peering ist der Wert von privateClusterConfig.peeringName.
  • network ist der Name Ihrer VPC.

Zum Ermitteln von peeringName gehen Sie wie im oben beschriebenen ersten Schritt vor, um den Export der benutzerdefinierten Route zu aktivieren.

Knoten auf externe IP-Adressen prüfen

Nach dem Erstellen eines privaten Clusters müssen Sie sicherstellen, dass die Knoten des Clusters keine externen IP-Adressen haben.

gcloud

Führen Sie den folgenden Befehl aus, um zu prüfen, ob die Knoten des Clusters externe IP-Adressen haben:

kubectl get nodes --output wide

Die Spalte EXTERNAL-IP der Ausgabe ist leer:

STATUS ... VERSION        EXTERNAL-IP  OS-IMAGE ...
    Ready      v.8.7-gke.1                 Container-Optimized OS from Google
    Ready      v1.8.7-gke.1                Container-Optimized OS from Google
    Ready      v1.8.7-gke.1                Container-Optimized OS from Google

Console

Führen Sie die folgenden Schritte aus, um zu prüfen, ob die Knoten des Clusters externe IP-Adressen haben:

  1. Rufen Sie in der Cloud Console das GKE-Menü auf.

    Zum GKE-Menü

  2. Klicken Sie in der Liste der Cluster auf den gewünschten Cluster.

  3. Klicken Sie unter Knotenpools auf den Namen Ihrer Instanzgruppe. Beispiel: gke-private-cluster-0-default-pool-5c5add1f-grp.

  4. Prüfen Sie in der Instanzliste, ob Ihre Instanzen externe IP-Adressen haben.

Subnetz und sekundäre Adressbereiche des Clusters aufrufen

Nachdem Sie einen privaten Cluster erstellt haben, können Sie die von Ihnen oder von GKE für den Cluster bereitgestellten Subnetze und sekundären Adressbereiche aufrufen.

gcloud

Alle Subnetze auflisten

Listen Sie die im Netzwerk Ihres Clusters enthaltenen Subnetze mit folgendem Befehl auf:

gcloud compute networks subnets list --network network

Dabei ist network das Netzwerk des privaten Clusters. Wenn Sie den Cluster mit einem automatisch erstellten Subnetz angelegt haben, verwenden Sie default.

Suchen Sie in der Ausgabe des Befehls den Namen des Subnetzes des Clusters.

Subnetz des Clusters ansehen

Rufen Sie Informationen zum automatisch erstellten Subnetz ab:

gcloud compute networks subnets describe subnet-name

Dabei ist subnet-name der Name des Subnetzes.

In der Ausgabe werden im ersten Feld ipCidrRange der primäre Adressbereich für Knoten und unter secondaryIpRanges die sekundären Bereiche für Pods und Dienste angezeigt:

...
    ipCidrRange: 10.0.0.0/22
    kind: compute#subnetwork
    name: gke-private-cluster-1-subnet-163e3c97
    ...
    privateIpGoogleAccess: true
    ...
    secondaryIpRanges:
    - ipCidrRange: 10.40.0.0/14
      rangeName: gke-private-cluster-1-pods-163e3c97
    - ipCidrRange: 10.0.16.0/20
      rangeName: gke-private-cluster-1-services-163e3c97
    ...

Console

  1. Rufen Sie in der Cloud Console die Seite "VPC-Netzwerke" auf.

    Zur VPC-Netzwerkseite

  2. Klicken Sie auf den Namen des Subnetzes. Beispiel: gke-private-cluster-0-subnet-163e3c97.

  3. Unter IP-Adressbereich finden Sie den primären Adressbereich Ihres Subnetzes. Dies ist der Bereich, der für Knoten verwendet wird.

  4. Unter Sekundäre IP-Bereiche sind der IP-Adressbereich für Pods und der Bereich für Dienste enthalten.

Endpunkte eines privaten Clusters aufrufen

Sie können die Endpunkte privater Cluster mit dem gcloud-Befehlszeilentool oder mit der Cloud Console aufrufen.

gcloud

Führen Sie den folgenden Befehl aus:

    gcloud container clusters describe cluster-name

Die Ausgabe zeigt die privaten und öffentlichen Endpunkte:

    ...
    privateClusterConfig:
    enablePrivateEndpoint: true
    enablePrivateNodes: true
    masterIpv4CidrBlock: 172.16.0.32/28
    privateEndpoint: 172.16.0.34
    publicEndpoint: 35.239.154.67

Console

Führen Sie diese Schritte aus:

  1. Rufen Sie in der Cloud Console das GKE-Menü auf.

    Zum GKE-Menü

  2. Klicken Sie in der Liste auf den gewünschten Cluster.

  3. Suchen Sie dann auf dem Tab Details unter Cluster nach dem Feld Endpunkt.

Container-Images von einer Image-Registry herunterladen

In einem privaten Cluster kann die Containerlaufzeit Container-Images nur von Container Registry herunterladen, also von keiner anderen Registry für Container-Images im Internet. Das liegt daran, dass die Knoten in einem privaten Cluster keine externen IP-Adressen haben. Daher können sie standardmäßig nicht mit Diensten außerhalb des Google-Netzwerks kommunizieren.

Die Knoten in einem privaten Cluster haben die Möglichkeit, mit Google-Diensten wie Container Registry zu kommunizieren, wenn sie sich in einem Subnetz befinden, für das der private Google-Zugriff aktiviert ist.

Mit den folgenden Befehlen erstellen Sie ein Deployment, mit dem ein Beispiel-Image von einem Container Registry-Repository von Google heruntergeladen wird.

    kubectl run hello-deployment --image gcr.io/google-samples/hello-app:2.0

Firewallregeln für bestimmte Anwendungsfälle hinzufügen

In diesem Abschnitt wird erläutert, wie Sie eine Firewallregel zu einem privaten Cluster hinzufügen. Ihr Clustermaster wird von Firewallregeln standardmäßig so eingeschränkt, dass nur TCP-Verbindungen zu den Knoten auf den Ports 443 (HTTPS) und 10250 (Kubelet) initiiert werden können. Bei einigen Kubernetes-Features müssen eventuell Firewallregeln ergänzt werden, um den Zugriff auf zusätzlichen Ports zuzulassen. In Kubernetes 1.9 und früher greift zum Beispiel kubectl top auf heapster zu. Dafür ist eine Firewallregel erforderlich, die TCP-Verbindungen auf Port 8080 erlaubt. Für das Gewähren eines derartigen Zugriffs können Sie Firewallregeln hinzufügen.

Durch Hinzufügen einer Firewallregel wird Traffic vom Clustermaster zu den folgenden Elementen ermöglicht:

  • Zum angegebenen Port jedes Knotens (hostPort)
  • Zum angegebenen Port jedes Pods, der auf diesen Knoten ausgeführt wird
  • Zum angegebenen Port jedes Dienstes, der auf diesen Knoten ausgeführt wird

Informationen zu Firewallregeln finden Sie in der Dokumentation zu Cloud Load Balancing unter Firewallregeln.

Zum Hinzufügen einer Firewallregel zu einem privaten Cluster müssen Sie den CIDR-Block des Clustermasters und das verwendete Ziel ermitteln. Mit dem ermittelten CIDR-Block können Sie dann die Regel erstellen.

Schritt 1: CIDR-Block des Clustermasters ansehen

Sie benötigen den CIDR-Block des Clustermasters, um eine Firewallregel hinzuzufügen.

gcloud

Führen Sie den folgenden Befehl aus:

    gcloud container clusters describe cluster-name

Dabei ist cluster-name der Name Ihres privaten Clusters.

Notieren Sie sich in der Befehlsausgabe den Wert im Feld masterIpv4CidrBlock.

Console

  1. Rufen Sie in der Cloud Console das GKE-Menü auf.

    Zum GKE-Menü

  2. Wählen Sie den gewünschten Cluster aus.

Notieren Sie sich den Wert im Feld Masteradressbereich auf dem Tab Details unter Cluster.

Schritt 2: Vorhandene Firewallregeln ansehen

Sie müssen das von den vorhandenen Firewallregeln des Clusters verwendete Ziel angeben. In diesem Fall sind es die Zielknoten.

gcloud

Führen Sie den folgenden Befehl aus:

    gcloud compute firewall-rules list \
        --filter 'name~^gke-cluster-name' \
        --format 'table(
            name,
            network,
            direction,
            sourceRanges.list():label=SRC_RANGES,
            allowed[].map().firewall_rule().list():label=ALLOW,
            targetTags.list():label=TARGET_TAGS
        )'

Notieren Sie sich aus der Befehlsausgabe den Wert im Feld Ziele.

Console

Führen Sie diese Schritte aus:

  1. Rufen Sie in der Cloud Console das Menü "Firewallregeln" auf.

    Zum Menü "Firewallregeln"

  2. Geben Sie im Feld Ressourcen filtern den Wert für gke-cluster-name ein.

Notieren Sie sich aus den Ergebnissen den Wert im Feld Ziele.

Schritt 3: Firewallregel hinzufügen

gcloud

Führen Sie den folgenden Befehl aus:

    gcloud compute firewall-rules create firewall-rule-name \
        --action ALLOW \
        --direction INGRESS \
        --source-ranges master-CIDR-block \
        --rules protocol:port \
        --target-tags target

Dabei gilt:

  • firewall-rule-name ist der Name, den Sie für die Firewallregel verwenden.
  • master-CIDR-block ist der zuvor ermittelte CIDR-Block (masterIpv4CidrBlock) des Clustermasters.
  • protocol:port sind der gewünschte Port und das zugehörige Protokoll, also tcp oder udp.
  • Ziel ist der zuvor ermittelte Zielwert (Targets).

Console

Führen Sie diese Schritte aus:

  1. Rufen Sie in der Cloud Console das Menü "Firewallregeln" auf.

    Zum Menü "Firewallregeln"

  2. Klicken Sie auf Firewallregel erstellen.

  3. Geben Sie in das Feld Name den gewünschten Namen für die Firewallregel ein.

  4. Wählen Sie im Drop-down-Menü Netzwerk das entsprechende Netzwerk aus.

  5. Klicken Sie dann unter Traffic-Richtung auf Eingehend.

  6. Klicken Sie anschließend unter Aktion bei Übereinstimmung auf Zulassen.

  7. Wählen Sie im Drop-down-Menü Ziele die Option Angegebene Ziel-Tags aus.

  8. Geben Sie im Feld Ziel-Tags den zuvor notierten Zielwert ein.

  9. Wählen Sie im Drop-down-Menü Quellfilter die Option IP-Bereiche aus.

  10. Geben Sie im Feld Quell-IP-Bereiche den zuvor ermittelten CIDR-Block des Clustermasters ein.

  11. Klicken Sie dann unter Protokolle und Ports auf Angegebene Protokolle und Ports. Klicken Sie anschließend auf das Kästchen des entsprechenden Protokolls (TCP oder UDP) und geben Sie in das Feld den gewünschten Port ein.

  12. Klicken Sie auf Erstellen.

Private Cluster mit VPC Service Controls schützen

Mit VPC Service Controls können Sie Ihre privaten GKE-Cluster zusätzlich schützen.

VPC Service Controls bietet eine zusätzliche Sicherheit für private GKE-Cluster und verringert das Risiko einer Daten-Exfiltration. Mithilfe von VPC Service Controls können Sie Projekte in diejenigen Dienstperimeter einfügen, die Ressourcen und Dienste vor solchen Anfragen schützen, die ihren Ursprung außerhalb des Perimeters haben.

Weitere Informationen zu Dienstperimetern finden Sie auf der Seite Dienstperimeter konfigurieren in der Dokumentation zu VPC Service Controls.

Wenn Sie Container Registry mit Ihrem privaten GKE-Cluster nutzen, sind zusätzliche Schritte erforderlich, um den privaten Cluster mit VPC Service Controls verwenden zu können. Weitere Informationen finden Sie auf der Seite Container Registry für private GKE-Cluster einrichten.

VPC-Peering wiederverwenden

Für private Cluster, die nach dem 15. Januar 2020 erstellt werden, können VPC-Netzwerk-Peering-Verbindungen wiederverwendet werden.

Alle privaten Cluster, die Sie vor dem 15. Januar 2020 erstellt haben, verwenden eine einmalige VPC-Netzwerk-Peering-Verbindung. Jedes VPC-Netzwerk kann ein Peering mit bis zu 25 anderen VPC-Netzwerken ausführen. Für diese Cluster besteht also ein Limit von maximal 25 privaten Clustern pro Netzwerk. Dabei wird davon ausgegangen, dass Peerings nicht für andere Zwecke verwendet werden.

Dieses Feature wird nicht zu früheren Releases zurückportiert. Für die Wiederverwendung des VPC-Netzwerk-Peerings durch ältere private Cluster können Sie Cluster löschen und neu erstellen. Das Upgrade eines Clusters ermöglicht keine Wiederverwendung einer vorhandenen VPC-Netzwerk-Peering-Verbindung.

Jeder Standort kann maximal 75 private Cluster unterstützen, wenn für die Cluster die VPC-Peering-Wiederverwendung aktiviert ist. Zonen und Regionen werden als separate Standorte behandelt. So lassen sich z. B. bis zu 75 private zonale Cluster in us-east1-a und weitere 75 private regionale Cluster in us-east1 erstellen. Dies gilt auch, wenn Sie private Cluster in einem freigegebenen VPC-Netzwerk verwenden. Es sind maximal 25 Verbindungen zu einem einzelnen VPC-Netzwerk möglich. Dies bedeutet, dass Sie nur private Cluster mit 25 separaten Standorten erstellen können.

Es lässt sich prüfen, ob Ihr privater Cluster VPC-Peering-Verbindungen wiederverwendet.

gcloud

    gcloud container clusters describe cluster-name \
    --zone=zone-name \
    --format="value(privateClusterConfig.peeringName)"

Wenn Ihr Cluster VPC-Peering-Verbindungen wiederverwendet, beginnt die Ausgabe mit gke-n. Beispiel: gke-n34a117b968dee3b2221-93c6-40af-peer.

Console

Prüfen Sie die Zeile für das VPC-Peering auf der Seite der Clusterdetails. Wenn Ihr Cluster VPC-Peering-Verbindungen wiederverwendet, beginnt die Ausgabe mit gke-n. Beispiel: gke-n34a117b968dee3b2221-93c6-40af-peer.

Bereinigen

Wenn Sie die Aufgaben auf dieser Seite ausgeführt haben, entfernen Sie die Ressourcen anhand der folgenden Schritte, damit keine unerwünschten Kosten für Ihr Konto entstehen:

Cluster löschen

gcloud

gcloud container clusters delete -q private-cluster-0 private-cluster-1

Console

  1. Rufen Sie in der Cloud Console das GKE-Menü auf.

    Zum GKE-Menü

  2. Wählen Sie jeden Cluster aus.

  3. Klicken Sie auf Löschen.

Netzwerk löschen

gcloud

gcloud compute networks delete net-0

Console

  1. Rufen Sie in der Cloud Console die Seite "VPC-Netzwerke" auf.

    Zur VPC-Netzwerkseite

  2. Klicken Sie unter net-0 in der Liste der Netzwerke auf das Papierkorbsymbol.

  3. Klicken Sie neben jedem Subnetz auf das Papierkorbsymbol.

Anforderungen, Beschränkungen und Einschränkungen

Für private Cluster gelten folgende Anforderungen:

Für private Cluster gelten folgende Beschränkungen:

  • Nicht private Cluster können nicht in private Cluster konvertiert werden.
  • Bei Clustern mit Versionen vor 1.14.4 darf sich der IP-Bereich eines Clustermasters, Knotens, Pods oder Dienstes nicht mit 172.17.0.0/16 überschneiden.
  • Bei Clustern mit Version 1.14.4 oder höher können Sie 172.17.0.0/16 für Ihren Master-IP-Bereich verwenden. Ein Knoten-, Pod- oder Dienst-IP-Bereich darf sich jedoch nicht mit 172.17.0.0/16 überschneiden.
  • Ein privater Cluster funktioniert in folgenden Fällen nicht mehr: – Das VPC-Peering zwischen dem Clustermaster und den Clusterknoten wird gelöscht. – Die Firewallregeln, die eingehenden Traffic vom Clustermaster zu Knoten auf Port 10250 zulassen, werden gelöscht. – Die Standardroute zum Standard-Internetgateway wird gelöscht. Damit ein privater Cluster nach dem Löschen der Standardroute wieder aktiviert werden kann, müssen Sie die eingeschränkte VIP statisch bereitstellen.
  • Einem Projekt können bis zu 50 autorisierte Netzwerke (CIDR-Blöcke auf der weißen Liste) hinzugefügt werden. Weitere Informationen finden Sie unter Einem vorhandenen Cluster ein autorisiertes Netzwerk hinzufügen.

Für private Cluster gelten folgende Beschränkungen:

  • Der RFC 1918-Block für den Clustermaster muss eine Größe von /28 haben.
  • GKE kann Überschneidungen mit dem Adressblock des Clustermasters erkennen, aber keine Überschneidungen in einem freigegebenen VPC-Netzwerk.
  • Knoten in einem privaten Cluster haben keinen ausgehenden Zugriff auf das öffentliche Internet. Sie haben auch nur eingeschränkten Zugriff auf Google APIs und Google-Dienste.
  • Die private IP-Adresse des Masters in einem regionalen Cluster ist nur über Subnetze innerhalb derselben Region oder über lokale Umgebungen, die mit derselben Region verbunden sind, zugänglich.
  • Private Cluster, die vor dem 15. Januar 2020 erstellt wurden, können maximal 25 private Cluster pro Netzwerk haben. Dabei wird davon ausgegangen, dass Peerings nicht für andere Zwecke verwendet werden. Weitere Informationen finden Sie unter VPC-Peering wiederverwenden.

Fehlerbehebung

In den folgenden Abschnitten wird erläutert, wie Sie häufige Probleme im Zusammenhang mit privaten Clustern beheben können.

Cluster überschneidet sich mit aktivem Peer

Symptome
Bei dem Versuch, einen privaten Cluster zu erstellen, wird ein Fehler folgender Art zurückgegeben: Google Compute Engine: An IP range in the peer network overlaps with an IP range in an active peer of the local network.
Mögliche Ursache
Sie haben einen überlappenden Master-CIDR ausgewählt.
Lösung
Löschen Sie den Cluster und erstellen Sie ihn noch einmal mit einem anderen Master-CIDR.

Cluster kann nicht erreicht werden

Symptome
Wenn Sie nach dem Erstellen eines privaten Clusters Befehle vom Typ kubectl ausführen, wird ein Fehler zurückgegeben, beispielsweise Unable to connect to the server: dial tcp [IP_ADDRESS]: connect: connection timed out oder Unable to connect to the server: dial tcp [IP_ADDRESS]: i/o timeout.
Mögliche Ursache
kubectl kann nicht mit dem Clustermaster kommunizieren.
Lösung
Sie müssen dem Cluster autorisierte Netzwerke hinzufügen, um die IP-Adressen des Netzwerks auf die weiße Liste zu setzen.

Cluster kann aufgrund von fehlendem Flag nicht erstellt werden

Symptome
gcloud container clusters create gibt einen Fehler folgender Art zurück: Cannot specify --enable-private-endpoint without --enable-private-nodes.
Mögliche Ursache
Sie haben ein erforderliches Flag nicht angegeben.
Lösung
Prüfen Sie, ob Sie die erforderlichen Flags angegeben haben. Es ist nicht möglich, einen privaten Endpunkt für den Clustermaster zu aktivieren, ohne gleichzeitig private Knoten zu aktivieren.

Cluster kann aufgrund von Master-IPv4-CIDR-Block nicht erstellt werden, der eine Überschneidung verursacht

Symptome
gcloud container clusters create gibt einen Fehler folgender Art zurück: The given master_ipv4_cidr 10.128.0.0/28 overlaps with an existing network 10.128.0.0/20.
Mögliche Ursache
Sie haben einen Master-CIDR-Block angegeben, der sich mit einem vorhandenen Subnetz in Ihrer VPC überschneidet.
Lösung
Geben Sie einen CIDR-Block für --master-ipv4-cidr an, der sich nicht mit einem vorhandenen Subnetz überschneidet.

Subnetz kann nicht erstellt werden

Symptome
Wenn Sie einen privaten Cluster mit einem automatischen Subnetz oder ein benutzerdefiniertes Subnetz erstellen, wird möglicherweise der folgende Fehler zurückgegeben: An IP range in the peer network overlaps with an IP range in one of the active peers of the local network.
Mögliche Ursache
Der von Ihnen angegebene CIDR-Bereich des Masters überschneidet sich mit einem anderen IP-Bereich im Cluster. Dieser Fehler kann auch auftreten, wenn Sie kürzlich einen privaten Cluster gelöscht haben und versuchen, einen neuen privaten Cluster mit dem gleichen Master-CIDR-Bereich zu erstellen.
Lösung
Verwenden Sie einen anderen CIDR-Bereich.

Image kann nicht von öffentlichem Docker Hub heruntergeladen werden

Symptome
Ein Pod, der in Ihrem Cluster ausgeführt wird, zeigt in kubectl describe eine Warnung an, z. B. Failed to pull image: rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers).
Mögliche Ursache
Knoten in einem privaten Cluster haben keinen ausgehenden Zugriff auf das öffentliche Internet. Sie haben eingeschränkten Zugriff auf Google APIs und -Dienste, einschließlich Container Registry.
Lösung
Images können nicht direkt von Docker Hub abgerufen werden. Verwenden Sie stattdessen Images, die in Container Registry gehostet werden. Hinweis: Der Docker Hub-Spiegel von Container Registry ist zwar von einem privaten Cluster aus zugänglich. Sie sollten jedoch nicht ausschließlich darauf zurückgreifen. Da der Spiegel nur ein Cache ist, werden Images regelmäßig entfernt und ein privater Cluster kann nicht auf Docker Hub zurückgreifen.

Weitere Informationen