Cloud-Infrastruktur mit kpt verwalten

Last reviewed 2023-03-15 UTC
In dieser Anleitung wird kpt vorgestellt, ein Open-Source-Tool von Google, mit dem Sie mit Kubernetes-Konfigurationen (auch als Manifeste bezeichnet) arbeiten können: Sie können sie verpacken, abrufen, aktualisieren und ändern. kpt ist eine Alternative zu vorlagenbasierten Tools, wenn Sie eine klare Trennung zwischen Konfigurationen und Vorgängen für diese Konfigurationen beibehalten möchten. Mit kpt können Sie Code wiederverwenden und freigeben, der mit Konfigurationen arbeitet, um sie zu ändern oder zu prüfen.

Außerdem wird gezeigt, wie Sie kpt mit anderen Google-Lösungen wie Config Sync und GKE Enterprise Sicherheits-Blueprints kombinieren können. Unabhängig davon, ob Sie Entwickler sind, der mit Kubernetes arbeitet, oder Plattformentwickler, der eine Kubernetes-basierte Plattform verwaltet, können Sie in dieser Anleitung lernen, wie Sie kpt in eigenen Workflows für Kubernetes verwenden. Es wird davon ausgegangen, dass Sie mit Kubernetes und Google Cloud vertraut sind.

Die deklarative Konfiguration der Cloud-Infrastruktur ist eine bewährte Praxis in der IT-Branche. Sie bietet eine leistungsstarke Abstraktion der zugrunde liegenden Systeme. Durch diese Abstraktion müssen Sie keine Konfigurationsdetails und Abhängigkeiten auf niedriger Ebene verwalten. Daher bietet die deklarative Konfiguration einen Vorteil gegenüber imperativen Ansätzen, z. B. Vorgängen, die in grafischen und Befehlszeilen-Schnittstellen ausgeführt werden.

Das Kubernetes-Ressourcenmodell hat dazu beigetragen, deklarative Konfigurationsansätze zum Mainstream zu machen. Da die Kubernetes API vollständig deklarativ ist, teilen Sie nur Kubernetes mit, was Sie möchten, und nicht, wie das erreicht werden soll. Mit der Kubernetes API können Sie die Konfiguration (gewünschte oder reale) von Vorgängen für die Konfiguration trennen, also Objekte hinzufügen, entfernen und ändern. Das heißt, im Kubernetes-Ressourcenmodell besteht die Konfiguration aus Daten und nicht aus Code.

Diese Trennung der Konfiguration von den Vorgängen hat viele Vorteile: Personen und automatisierte Systeme können die Konfiguration verstehen und damit arbeiten; die Software, die die Konfiguration ändert, kann einfach wiederverwendet werden. Dank dieser Trennung können Sie auch eine GitOps-Methode implementieren, wie in der Anleitung Continuous Delivery gemäß GitOps mit Cloud Build definiert.

In dieser Anleitung untersuchen Sie die Trennung der Konfigurationsdeklaration von den Konfigurationsvorgängen mit kpt. In dieser Anleitung werden die folgenden Features von kpt erläutert:

  • Paketverwaltung: Kubernetes-Konfigurationspakete herunterladen und aktualisieren.
  • Funktionen: beliebige Codeteile ausführen, um Ihre Konfigurationen zu ändern oder zu validieren.
  • Funktionspipeline: eine Reihe von Funktionen, die der Paketautor in das Paket aufgenommen hat.
  • Ressourcenverwaltung: Ressourcen, die Ihren Konfigurationen entsprechen, in einem Kubernetes-Cluster anwenden, aktualisieren und löschen.

Ziele

  • Einen Google Kubernetes Engine-Cluster (GKE) erstellen
  • Mit kpt bestehende Kubernetes-Konfigurationen herunterladen
  • kpt-Funktionen verwenden, um die Konfigurationen anzupassen
  • Konfiguration auf den GKE-Cluster anwenden
  • Mit kpt einige vorgelagerte Änderungen für Ihre Konfiguration übernehmen
  • kpt in einem realen Szenario verwenden, um den GKE-Cluster zu härten

Kosten

In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:

  • Google Kubernetes Engine

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Hinweis

  1. Melden Sie sich bei Ihrem Google Cloud-Konto an. Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

  2. Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.

    Zur Projektauswahl

  3. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

  4. Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.

    Zur Projektauswahl

  5. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

  6. Aktivieren Sie Cloud Shell in der Google Cloud Console.

    Cloud Shell aktivieren

    Unten in der Google Cloud Console wird eine Cloud Shell-Sitzung gestartet und eine Eingabeaufforderung angezeigt. Cloud Shell ist eine Shell-Umgebung, in der das Google Cloud CLI bereits installiert ist und Werte für Ihr aktuelles Projekt bereits festgelegt sind. Das Initialisieren der Sitzung kann einige Sekunden dauern.

  7. Konfigurieren Sie Cloud Shell für die Verwendung Ihres Projekts:

    gcloud config set project PROJECT_ID

  8. Aktivieren Sie in Cloud Shell Google Kubernetes Engine und Cloud Source Repositories APIs:

    gcloud services enable container.googleapis.com \
   sourcerepo.googleapis.com

Wenn Sie diese Anleitung abgeschlossen haben, können Sie laufende Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

GKE-Cluster erstellen

In diesem Abschnitt erstellen Sie den GKE-Cluster, in dem Sie später in der Anleitung Konfigurationen bereitstellen.

  1. Erstellen Sie in Cloud Shell einen GKE-Cluster:

    gcloud container clusters create kpt-tutorial \
   --num-nodes=1 --machine-type=n1-standard-4 \
   --zone=us-central1-a --enable-network-policy

  2. Prüfen Sie, ob Sie auf den Cluster zugreifen können. Mit dem folgenden Befehl werden Informationen über die Knoten im Cluster zurückgegeben.

    kubectl get nodes

kpt-Paket anwenden

In diesem Abschnitt verwenden Sie kpt, um eine Reihe von Konfigurationen herunterzuladen, anzupassen und auf den Cluster anzuwenden, den Sie im vorherigen Abschnitt erstellt haben. kpt sollte in Ihrer Cloud Shell-Umgebung installiert sein. Ist dies nicht der Fall, installieren Sie es mit den folgenden Befehlen:

  1. Installieren Sie in Cloud Shell kpt:

    sudo apt update && sudo apt-get install google-cloud-sdk-kpt

  2. Beispielsatz mit Konfigurationen herunterladen. Weitere Informationen finden Sie unter kpt pkg get.

    kpt pkg get https://github.com/GoogleContainerTools/kpt.git/package-examples/wordpress@v0.9

    Mit dem vorherigen Befehl wird das wordpress-Beispielpaket, das im kpt-GitHub-Repository verfügbar ist, unter der mit v0.9 gekennzeichneten Version heruntergeladen.

  3. Sehen Sie sich den Paketinhalt an: kpt pkg tree.

    kpt pkg tree wordpress

    Die Ausgabe sieht so aus:

    Package "wordpress"
├── [Kptfile]  Kptfile wordpress
├── [service.yaml]  Service wordpress
├── deployment
│   ├── [deployment.yaml]  Deployment wordpress
│   └── [volume.yaml]  PersistentVolumeClaim wp-pv-claim
└── Package "mysql"
    ├── [Kptfile]  Kptfile mysql
    ├── [deployment.yaml]  PersistentVolumeClaim mysql-pv-claim
    ├── [deployment.yaml]  Deployment wordpress-mysql
    └── [deployment.yaml]  Service wordpress-mysql

    Das Paket enthält zwei Pakete: das der obersten Ebene wordpress und ein Unterpaket wordpress/mysql. Beide Pakete enthalten die Metadatendatei Kptfile. Kptfile wird nur von kpt selbst verwendet und enthält Daten zur vorgelagerten Quelle, zur Anpassung und Validierung des Pakets.

  4. Aktualisieren Sie das Label des Pakets.

    Der Autor des Pakets hat eine Rendering-Pipeline hinzugefügt, die häufig verwendet wird, um die erwarteten Anpassungen anzugeben.

    less wordpress/Kptfile

    Der Inhalt sollte in etwa so aussehen:

    apiVersion: kpt.dev/v1
kind: Kptfile
metadata:
  name: wordpress
upstream:
  type: git
  git:
    repo: https://github.com/GoogleContainerTools/kpt
    directory: /package-examples/wordpress
    ref: v0.9
  updateStrategy: resource-merge
upstreamLock:
  type: git
  git:
    repo: https://github.com/GoogleContainerTools/kpt
    directory: /package-examples/wordpress
    ref: package-examples/wordpress/v0.9
    commit: b9ea0bca019dafa9f9f91fd428385597c708518c
info:
  emails:
    - kpt-team@google.com
  description: This is an example wordpress package with mysql subpackage.
pipeline:
  mutators:
    - image: gcr.io/kpt-fn/set-labels:v0.1
      configMap:
        app: wordpress
  validators:
    - image: gcr.io/kpt-fn/kubeval:v0.3

    Sie können die Parameter der set-label-Funktion mit Ihrem bevorzugten Editor von app: wordpress in app: my-wordpress ändern.

  5. Bearbeiten Sie die MySQL-Bereitstellung wordpress/mysql/deployment.yaml mit Ihrem bevorzugten Codeeditor, um die MySQL-Version zu ändern. Um die Sicherheit weiter zu erhöhen, ändern Sie die Variable MYSQL_ROOT_PASSWORD in MYSQL_PASSWORD und fügen Sie die folgenden Variablen hinzu:

    • MYSQL_USER
    • MYSQL_RANDOM_ROOT_PASSWORD
    • MYSQL_DATABASE

    Vorher:

    [...]
  containers:
    - name: mysql
      image: mysql:5.6
      ports:
        - name: mysql
          protocol: TCP
          containerPort: 3306
      env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
[...]

    Nachher:

    [...]
  containers:
    - name: mysql
      image: mysql:8.0
      ports:
        - name: mysql
          protocol: TCP
          containerPort: 3306
      env:
        - name: MYSQL_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
        - name: MYSQL_RANDOM_ROOT_PASSWORD
          value: '1'
        - name: MYSQL_USER
          value: wordpress
        - name: MYSQL_DATABASE
          value: wordpress
[...]

  6. Bearbeiten Sie die WordPress-Bereitstellung wordpress/deployment/deployment.yaml mit Ihrem bevorzugten Codeeditor, um die WordPress-Version zu ändern und eine WORDPRESS_DB_USER-Variable hinzuzufügen.

    Vorher:

    [...]
  containers:
    - name: wordpress
      image: wordpress:6.1-apache
      ports:
        - name: wordpress
          protocol: TCP
          containerPort: 80
      env:
        - name: WORDPRESS_DB_HOST
          value: wordpress-mysql
        - name: WORDPRESS_DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
[...]

    Nachher:

    [...]
  containers:
    - name: wordpress
      image: wordpress:4.8-apache
      ports:
        - name: wordpress
          protocol: TCP
          containerPort: 80
      env:
        - name: WORDPRESS_DB_HOST
          value: wordpress-mysql
        - name: WORDPRESS_DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
        - name: WORDPRESS_DB_USER
          value: wordpress
[...]

    Im Gegensatz zu Tools, die nur über Parameter ausgeführt werden, können Sie mit kpt Dateien mit einem Editor bearbeiten und dann die vorgelagerten Updates zusammenführen. Sie können deployment.yaml direkt bearbeiten, ohne einen Patch oder eine Funktion in der Pipeline erstellen zu müssen:

  7. Versehen Sie die Konfiguration über sample-annotation: sample-value mit einer Annotation.

    kpt fn eval wordpress --image gcr.io/kpt-fn/set-annotations:v0.1 \
  -- sample-annotation=sample-value

    Die Ausgabe sollte in etwa so aussehen:

    [RUNNING] "gcr.io/kpt-fn/set-annotations:v0.1"
[PASS] "gcr.io/kpt-fn/set-annotations:v0.1"

    Wenn Sie die neue Annotation sehen möchten, können Sie jeden Konfigurationswert untersuchen. Eine einfache Option ist wordpress/service.yaml.

    In diesem Beispiel haben wir eine Anpassung mit einer Funktion vorgenommen, die der Paketautor nicht geplant hat. kpt kann die deklarative und imperative Funktionsausführung unterstützen, um eine Vielzahl von Szenarien zu ermöglichen.

    Wenn dieses Paket mit Infrastruktur als Code entwickelt wurde, müssen wir die Quelle des Pakets aufrufen und den Code dort bearbeiten.

  8. Führen Sie die Pipeline aus und validieren Sie die Änderungen mit kubeval über kpt.

    kpt fn render wordpress

    Der Paketautor hat einen Validierungsschritt in die Pipeline aufgenommen:

    ...
validators:
    - image: gcr.io/kpt-fn/kubeval:v0.3

    Die erfolgreiche Ausgabe dieser Rendering-Pipeline sieht so aus:

    Package "wordpress/mysql":
[RUNNING] "gcr.io/kpt-fn/set-labels:v0.1"
[PASS] "gcr.io/kpt-fn/set-labels:v0.1" in 1.3s

Package "wordpress":
[RUNNING] "gcr.io/kpt-fn/set-labels:v0.1"
[PASS] "gcr.io/kpt-fn/set-labels:v0.1" in 1.3s
[RUNNING] "gcr.io/kpt-fn/kubeval:v0.3"
[PASS] "gcr.io/kpt-fn/kubeval:v0.3" in 3.7s

Successfully executed 3 function(s) in 2 package(s).

    Dieser Schritt ist ein Beispiel für die Vorteile des Kubernetes-Ressourcenmodells. Da Ihre Konfigurationen in diesem bekannten Modell dargestellt werden, können Sie vorhandene Kubernetes-Tools wie kubeval verwenden.

  9. Untersuchen Sie die Unterschiede zwischen der lokalen Version der Konfigurationen und der vorgelagerten Konfiguration:

    kpt pkg diff wordpress

  10. Initialisieren Sie das Paket für die Bereitstellung:

    kpt live init wordpress

    Mit dem vorherigen Befehl wird ein Inventar der im Paket enthaltenen Konfigurationen erstellt. kpt verwendet das Inventar unter anderem, um Konfigurationen zu bereinigen, wenn Sie diese aus dem Paket entfernen. Weitere Informationen finden Sie unter kpt live.

  11. Erstellen Sie ein Secret mit dem MySQL-Passwort:

    kubectl create secret generic mysql-pass --from-literal=password=foobar

  12. Wenden Sie die Konfigurationen auf Ihren GKE-Cluster an:

    kpt live apply wordpress

    Die Ausgabe sieht so aus:

    installing inventory ResourceGroup CRD.
inventory update started
inventory update finished
apply phase started
service/wordpress apply successful
service/wordpress-mysql apply successful
deployment.apps/wordpress apply successful
deployment.apps/wordpress-mysql apply successful
persistentvolumeclaim/mysql-pv-claim apply successful
persistentvolumeclaim/wp-pv-claim apply successful
apply phase finished
reconcile phase started
service/wordpress reconcile successful
service/wordpress-mysql reconcile successful
deployment.apps/wordpress reconcile pending
deployment.apps/wordpress-mysql reconcile pending
persistentvolumeclaim/mysql-pv-claim reconcile pending
persistentvolumeclaim/wp-pv-claim reconcile pending
persistentvolumeclaim/wp-pv-claim reconcile successful
persistentvolumeclaim/mysql-pv-claim reconcile successful
deployment.apps/wordpress-mysql reconcile successful
deployment.apps/wordpress reconcile successful
reconcile phase finished
inventory update started
inventory update finished
apply result: 6 attempted, 6 successful, 0 skipped, 0 failed
reconcile result: 6 attempted, 6 successful, 0 skipped, 0 failed, 0 timed out

  13. Warten Sie einige Minuten und prüfen Sie dann, ob alles wie erwartet funktioniert:

    kpt live status wordpress

    Die Ausgabe sieht so aus:

    inventory-88521939/deployment.apps/default/wordpress is Current: Deployment is available. Replicas: 1
inventory-88521939/persistentvolumeclaim/default/wp-pv-claim is Current: PVC is Bound
inventory-88521939/service/default/wordpress-mysql is Current: Service is ready
inventory-88521939/persistentvolumeclaim/default/mysql-pv-claim is Current: PVC is Bound
inventory-88521939/deployment.apps/default/wordpress-mysql is Current: Deployment is available. Replicas: 1
inventory-88521939/service/default/wordpress is Current: Service is ready

Lokales Paket aktualisieren

In diesem Abschnitt aktualisieren Sie die lokale Version des Pakets mit einigen Änderungen aus dem vorgelagerten Paket.

  1. Erstellen Sie ein Git-Repository für Ihre Konfigurationen und konfigurieren Sie Ihre E-Mail-Adresse und Ihren Namen. Sie benötigen ein lokales Git-Repository, um das Paket aktualisieren zu können. Ersetzen Sie YOUR_EMAIL durch Ihre E-Mail-Adresse und YOUR_NAME durch Ihren Namen.

    cd wordpress/
git init -b main
git config user.email "YOUR_EMAIL"
git config user.name "YOUR_NAME"

  2. Führen Sie ein Commit Ihrer Konfigurationen durch:

    git add .
git commit -m "First version of Wordpress package"
cd ..

  3. Aktualisieren Sie Ihr lokales Paket. In diesem Schritt rufen Sie die v0.10-Version aus Upstream-Prozessen ab.

    kpt pkg update wordpress@v0.10

  4. Beachten Sie, dass Aktualisierungen aus den Upstream-Prozessen auf Ihr lokales Paket angewendet werden:

    cd wordpress/
git diff

    In diesem Fall wurde das Wordpress-Bereitstellungsvolumen von 3Gi in 4Gi geändert. Sie können auch Ihre eigenen Änderungen sehen.

  5. Wenden Sie Ihre Änderungen an:

    git commit -am "Update to package version v0.10"

  6. Wenden Sie die neue Version des Pakets an:

    kpt live apply .

Ressource und Paket entfernen

Da mit kpt die von kpt erstellten Ressourcen verfolgt werden, kann es Ressourcen aus dem Cluster bereinigen, wenn Sie Ressourcen aus dem Paket löschen. Es kann auch ein Paket vollständig aus dem Cluster entfernen. In diesem Abschnitt entfernen Sie eine Ressource aus dem Paket und entfernen dann das Paket.

  1. Entfernen Sie die Datei service.yaml aus dem Paket:

    git rm service.yaml
git commit -m "Remove service"

  2. Wenden Sie die Änderung an und prüfen Sie, ob kpt den wordpress-Dienst bereinigt hat:

    kpt live apply .
kubectl get svc

  3. Entfernen Sie das restliche Paket aus dem Cluster und prüfen Sie, ob der Cluster leer ist:

    kpt live destroy .
kubectl get deployment

GKE mithilfe von kpt härten

Der Befehl kpt live ist nicht die einzige Möglichkeit, ein Paket auf einen Kubernetes-Cluster anzuwenden. In diesem Abschnitt verwenden Sie kpt mit Config Sync in einem einfachen, aber realistischen Szenario. Mit dem Config Sync-Tool können Sie Ihre Konfiguration zentral, einheitlich und deklarativ für alle Kubernetes-Cluster aus einem Git-Repository verwalten. Config Sync ist als eigenständiges Produkt für GKE verfügbar. GKE Enterprise (wird in dieser Anleitung verwendet) enthält Config Management.

Die GKE Enterprise-Sicherheits-Blueprints bieten eine Reihe vorkonfigurierter Sicherheitseinstellungen für Ihre GKE Enterprise-basierten Arbeitslasten. In diesem Abschnitt verwenden Sie den Blueprint zum Einschränken des Traffics und das zugehörige Verzeichnis im GitHub-Repository. Verwenden Sie kpt, um das default-deny-Paket herunterzuladen. Das Paket verwendet standardmäßig Kubernetes-Netzwerkrichtlinien, um Traffic in Ihrem GKE-Cluster (außer zur DNS-Auflösung) standardmäßig abzulehnen. Führen Sie einen Commit der Konfigurationen für das Git-Repository von Config Sync durch, um die Konfigurationen anzuwenden.

Config Sync installieren

In diesem Abschnitt erstellen Sie das Git-Repository, das Config Sync benötigt, und installieren dann Config Sync auf Ihrem GKE-Cluster.

  1. Verwenden Sie in Cloud Shell Cloud Source Repositories, um ein Git-Repository für Config Sync zu erstellen:

    cd ~
gcloud source repos create config-management

  2. Generieren Sie ein SSH-Schlüsselpaar, um sich im Git-Repository zu authentifizieren:

    cd ~
ssh-keygen -t rsa -b 4096  -N '' \
   -f cloud_source_repositories_key

  3. Erstellen Sie das Kubernetes-Secret, das den privaten SSH-Schlüssel für den Zugriff auf das Git-Repository enthält:

    kubectl create ns config-management-system && \
kubectl create secret generic git-creds \
  --namespace=config-management-system \
  --from-file=ssh=cloud_source_repositories_key

  4. Zeigen Sie den öffentlichen Schlüssel an und kopieren Sie ihn:

    cat cloud_source_repositories_key.pub

  5. Rufen Sie in Cloud Source Repositories

    die Seite SSH-Schlüssel verwalten auf.

  6. Geben Sie im Dialogfeld SSH-Schlüssel registrieren die folgenden Werte ein:

    1. Geben Sie im Feld Schlüsselname den Wert config-management ein.
    2. Fügen Sie den öffentlichen Schlüssel in das Feld Schlüssel ein.
    3. Klicken Sie auf Registrieren.

  7. Klonen Sie das Git-Repository in Cloud Shell:

    gcloud source repos clone config-management
cd config-management
git checkout -b main

  8. Laden Sie das Config Sync-Befehlszeilentool nomos herunter: nomos sollte in Ihrer Cloud Shell-Umgebung installiert werden. Ist dies nicht der Fall, installieren Sie es mit den folgenden Befehlen:

    sudo apt update && sudo apt-get install google-cloud-sdk-nomos

  9. Initialisieren Sie das Config Sync-Repository:

    nomos init
git add .
git commit -m "Config Management directory structure"
git push -u origin main

  10. Stellen Sie den Config Sync Operator-bereit.

    gsutil cp gs://config-management-release/released/latest/config-management-operator.yaml /tmp/config-management-operator.yaml
kubectl apply -f /tmp/config-management-operator.yaml

Config Sync konfigurieren

  1. Erstellen Sie eine benutzerdefinierte ConfigManagement-Ressource, um Config Sync zu konfigurieren:

    PROJECT=$(gcloud config get-value project)
EMAIL=$(gcloud config get-value account)
cat <<EOF > /tmp/config-management.yaml
apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
spec:
  clusterName: kpt-tutorial
  git:
    syncRepo: ssh://${EMAIL}@source.developers.google.com:2022/p/${PROJECT}/r/config-management
    syncBranch: main
    secretType: ssh
EOF
kubectl -n config-management-system \
    apply -f /tmp/config-management.yaml

    Weitere Installationsoptionen finden Sie in der Config Sync-Dokumentation.

  2. Überprüfen Sie in Cloud Shell, ob Config Sync ordnungsgemäß funktioniert:

    nomos status --contexts=$(kubectl config current-context)

    Dieser Befehl gibt den Status SYNCED zurück. Die Initialisierung von Config Sync kann einige Zeit dauern. Wenn der Status nicht aktualisiert wird, warten Sie ein paar Minuten und führen Sie den Befehl noch einmal aus.

GKE Enterprise-Sicherheits-Blueprint verwenden

In diesem Abschnitt verwenden Sie kpt, um das default-deny-Paket des GKE Enterprise-Sicherheits-Blueprints für die Einschränkung des Traffics herunterzuladen. Anschließend wenden Sie mithilfe von Config Sync das Paket nur auf den Namespace default an.

  1. Laden Sie das Paket default-deny herunter:

    cd ~
kpt pkg get https://github.com/GoogleCloudPlatform/anthos-security-blueprints.git/restricting-traffic/default-deny ./

    Sie können sich den Inhalt des Pakets ansehen: Die Datei default-deny/Kptfile enthält die Metadaten des Pakets und die Datei default-deny/default-deny.yaml enthält eine Kubernetes-NetworkPolicy, die die einzige Konfiguration aus diesem Blueprint ist.

  2. Verwenden Sie kpt, um den Inhalt des Pakets in das Config Sync-Repository zu kopieren, und fügen Sie dann Labels hinzu, um ihn anzupassen:

    kpt fn source default-deny/ | \
    kpt fn eval - --image=gcr.io/kpt-fn/set-annotations:v0.1 -- \
    anthos-security-blueprint=restricting-traffic | \
    kpt fn sink ~/config-management/namespaces/default/

    Wie in diesem Beispiel gezeigt, können Sie senkrechte Striche verwenden, um kpt fn-Befehle zu verketten. Durch das Verketten von kpt fn-Befehlen können Sie Konfigurationen lesen, ändern und das Ergebnis schreiben. Sie können beliebig viele kpt fn-Befehle verketten.

  3. Erstellen Sie im Config Sync-Repository die Datei namespace.yaml:

    cat >> ~/config-management/namespaces/default/namespace.yaml <<EOF
apiVersion: v1
kind: Namespace
metadata:
  name: default
EOF

    Der Namespace default ist in Ihrem GKE-Cluster vorhanden, wird aber nicht von Config Sync verwaltet. Wenn Sie in diesem Schritt das Verzeichnis und die Datei erstellen, sorgen Sie damit dafür, dass Config Sync den Namespace verwaltet. Um das Paket auf mehrere Namespaces gleichzeitig anzuwenden, können Sie einen abstrakten Namespace erstellen.

  4. Prüfen Sie, ob die Kubernetes-NetworkPolicies in das Config Management-Repository geschrieben wurden und mit anthos-security-blueprint: restricting-traffic annotiert sind:

    cat config-management/namespaces/default/default-deny.yaml

    Die Ausgabe sieht so aus:

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata: # kpt-merge: /default-deny
  name: default-deny
  annotations:
    internal.kpt.dev/upstream-identifier: 'networking.k8s.io|NetworkPolicy|default|default-deny'
    anthos-security-blueprint: restricting-traffic
spec:
  policyTypes:
  - Ingress
  - Egress
  podSelector: {}
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          k8s-namespace: kube-system
      podSelector:
        matchExpressions:
        - key: k8s-app
          operator: In
          values: ["kube-dns", "node-local-dns"]
    ports:
    - protocol: TCP
      port: 53
    - protocol: UDP
      port: 53

  5. Übernehmen Sie die Änderungen per Commit und übertragen Sie sie per Push:

    cd ~/config-management/
git add namespaces/default/
git commit -m "Default deny"
git push

  6. Prüfen Sie, ob die neue Richtlinie angewendet wird:

    kubectl get networkpolicies

    Wenn die neue Richtlinie nicht vorhanden ist, warten Sie einige Sekunden und führen Sie den Befehl noch einmal aus. Config Sync aktualisiert die Konfigurationen standardmäßig alle 15 Sekunden. Wenn Sie zusätzliche Schritte zur Fehlerbehebung ausführen müssen, führen Sie den folgenden Befehl aus, um Informationen zu möglichen Config Sync-Fehlern abzurufen:

    nomos status --contexts=$(kubectl config current-context)

  7. Rufen Sie zum Testen der neuen Richtlinie eine Shell in einem Pod ab, der im Namespace default ausgeführt wird:

    kubectl -n default run -i --tty --rm test \
        --image=busybox --restart=Never -- sh

  8. Versuchen Sie, 8.8.8.8 zu kontaktieren, und beachten Sie, dass es wie erwartet nicht funktioniert:

    ping -c 3 -W 1 8.8.8.8

    Die Ausgabe sieht so aus:

    PING 8.8.8.8 (8.8.8.8): 56 data bytes

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

  9. Fragen Sie den Kubernetes API-Server ab und beachten Sie, dass es wie erwartet nicht funktioniert:

    wget --timeout=3 https://${KUBERNETES_SERVICE_HOST}

    Die Ausgabe sieht so aus:

    Connecting to 10.3.240.1 (10.3.240.1:443)
wget: download timed out

  10. Beenden Sie den Pod:

    exit

Bereinigen

Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder das Projekt, das die Ressourcen enthält, oder Sie behalten das Projekt und löschen die einzelnen Ressourcen.

Projekt löschen

  1. Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.

    Zur Seite „Ressourcen verwalten“

  2. Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
  3. Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.

Ressourcen löschen

Wenn Sie das in dieser Anleitung verwendete Google Cloud-Projekt beibehalten möchten, können Sie das Git-Repository und den GKE-Cluster löschen. Führen Sie in Cloud Shell die folgenden Befehle aus:

gcloud source repos delete config-management --quiet
gcloud container clusters delete kpt-tutorial \
    --async --quiet --zone=us-central1-a

Nächste Schritte