Arbeitslasten in dedizierten Knotenpools isolieren

Mit dedizierten Knotenpools in Google Distributed Cloud (GDC) mit Air Gap können Sie Containerarbeitslasten isolieren, um die Sicherheit von Kubernetes-Clustern zu erhöhen und die Pod-Platzierung zu steuern. Diese Trennung trägt dazu bei, das Risiko von Angriffen zur Rechteausweitung zu verringern. Wenn Sie dedizierte Pools einrichten möchten, wenden Sie Markierungen und Labels an, gleichen sie mit Arbeitslasttoleranzen und Knotenaffinitätsregeln ab und prüfen die Planung.

Dieses Dokument richtet sich an IT-Administratoren in der Plattformadministratorgruppe, die Kubernetes-Cluster verwalten, und an Entwickler in der Gruppe der Anwendungsoperatoren, die Container ausführen. Weitere Informationen finden Sie unter Knotenisolation – Übersicht und Zielgruppen für die Dokumentation zu GDC mit Air Gap.

Hinweis

Zum Ausführen der Aufgaben in diesem Dokument müssen Sie die erforderlichen Berechtigungen anfordern und Ihre Umgebung vorbereiten.

IAM-Rollen anfordern

Sie benötigen bestimmte Rollen, um die Berechtigungen zu erhalten, die Sie zum Isolieren von Containerarbeitslasten in Ihrem Kubernetes-Cluster benötigen. Welche Rollen Sie benötigen, hängt davon ab, ob Sie in einem freigegebenen Cluster auf Organisationsebene oder in einem Standardcluster auf Projektebene arbeiten. Weitere Informationen finden Sie unter Kubernetes-Clusterkonfigurationen.

Freigegebene Clusterrollen

Wenden Sie sich an Ihren IAM-Admin der Organisation, um die folgenden Rollen anzufordern, damit Sie einen Knotenpool in einem freigegebenen Cluster mit Markierungen und Labels versehen können:

  • Nutzercluster-Administrator (user-cluster-admin): Erstellen, Löschen, Bearbeiten oder Aufrufen der Ressourcen eines freigegebenen Clusters, der auf dem Verwaltungs-API-Server gehostet wird. Diese Rolle bietet Zugriff auf die Knotenpools des freigegebenen Clusters.

  • User Cluster Developer (user-cluster-developer): Erstellen, Löschen, Bearbeiten oder Ansehen eines freigegebenen Clusters. Diese Rolle bietet Zugriff auf die APIs der Datenebene, die im freigegebenen Cluster gehostet werden.

Diese Rollen sind nicht an einen Namespace gebunden.

Standardclusterrollen

Wenden Sie sich an Ihren IAM-Projektadministrator, um die folgenden Rollen anzufordern, um einen Knotenpool in einem Standardcluster mit Markierungen und Labels zu versehen:

  • Clusteradministrator (cluster-admin): Erstellen, Löschen, Bearbeiten oder Aufrufen aller Ressourcen in einem Standardcluster. Diese Rolle bietet Zugriff auf die APIs der Datenebene, die im Standardcluster gehostet werden und die Ressourcen des Clusters steuern.

  • Cluster-Entwickler (cluster-developer): Standardcluster erstellen, löschen, bearbeiten oder ansehen. Diese Rolle bietet Zugriff auf die APIs der Datenebene, die im Standardcluster gehostet werden und den Cluster steuern.

  • Standardcluster-Administrator (standard-cluster-admin): Erstellen, Löschen, Bearbeiten oder Aufrufen der Ressourcen eines Standardclusters, der auf dem Management API-Server gehostet wird. Diese Rolle gewährt Zugriff auf die Knotenpools des Standardclusters.

Diese Rollen sind an Ihren Projekt-Namespace gebunden.

Umgebung vorbereiten

Wenn Sie Befehle für einen Kubernetes-Cluster über die API ausführen möchten, benötigen Sie die folgenden Ressourcen:

  • Melden Sie sich an und generieren Sie die kubeconfig-Datei für den Kubernetes-Cluster.

  • Ersetzen Sie KUBERNETES_CLUSTER_KUBECONFIG in dieser Anleitung durch den kubeconfig-Pfad des Kubernetes-Clusters.

  • Melden Sie sich an und generieren Sie die kubeconfig-Datei für den Management API-Server.

  • Ersetzen Sie MANAGEMENT_API_SERVER in dieser Anleitung durch den kubeconfig-Pfad des Verwaltungs-API-Servers.

  • Wählen Sie einen bestimmten Namen für die Knotenmarkierung und das Knotenlabel aus, das Sie für die dedizierten Knotenpools verwenden möchten. Beispiel: workloadType=untrusted.

Neuen Knotenpool markieren und mit Labels versehen

Wenn Sie eine Markierung oder ein Label auf einen neuen Knotenpool anwenden, erhalten alle Knoten, einschließlich aller später hinzugefügten Knoten, automatisch die angegebenen Markierungen und Labels. Sie können eine Markierung oder ein Label nicht mehr aus einem Knotenpool entfernen, nachdem sie angewendet wurden.

Führen Sie die folgenden Schritte aus, um einem neuen Knotenpool eine Markierung und ein Label hinzuzufügen:

  1. Bearbeiten Sie den Abschnitt nodePools der benutzerdefinierten Ressource Cluster direkt, wenn Sie den Knotenpool erstellen:

    nodePools:
  # Several lines of code are omitted here.
  - machineTypeName: n2-standard-2-gdc
    name: nodepool-1
    nodeCount: 3
    taints:
    - key: "TAINT_KEY"
      value: "TAINT_VALUE"
      effect: "TAINT_EFFECT"
    labels:
      LABEL_KEY: LABEL_VALUE

    Ersetzen Sie Folgendes:

    • TAINT_KEY: der Schlüsselteil der Markierung des Schlüssel/Wert-Paars, das mit einem TAINT_EFFECT-Zeitplan verknüpft ist. Beispiel: workloadType
    • TAINT_VALUE: der Markierungswertteil des Schlüssel/Wert-Paars, das mit einem TAINT_EFFECT-Zeitplan verknüpft ist. Beispiel: untrusted
    • TAINT_EFFECT: einer der folgenden Effektwerte:
      • NoSchedule: Pods, die diese Markierung nicht tolerieren, werden für den Knoten nicht geplant. Auf dem Knoten vorhandene Pods werden nicht entfernt.
      • PreferNoSchedule: Kubernetes plant für den Knoten keine Pods, die diese Markierung nicht tolerieren.
      • NoExecute: Der Pod wird aus dem Knoten entfernt, wenn er bereits auf dem Knoten ausgeführt wird. Wird er noch nicht auf dem Knoten ausgeführt, wird er nicht für den Knoten geplant.
    • LABEL_KEY: LABEL_VALUE: Die Schlüssel/Wert-Paare für die Knotenlabels, die den Selektoren entsprechen, die Sie in Ihren Arbeitslastmanifesten angeben.

  2. Wenden Sie die Ressource Cluster an, um den neuen Knotenpool zu erstellen:

    kubectl apply -f cluster.yaml --kubeconfig MANAGEMENT_API_SERVER

    Ersetzen Sie MANAGEMENT_API_SERVER durch den kubeconfig-Pfad des zonalen API-Servers, auf dem der Kubernetes-Cluster gehostet wird.

Vorhandenen Knotenpool markieren und mit Labels versehen

Wenn Sie eine Markierung oder ein Label auf einen vorhandenen Knotenpool anwenden möchten, müssen Sie die Änderungen auf jeden vorhandenen Knoten anwenden. Knotenpoolkonfigurationen können nicht dynamisch aktualisiert werden.

Sie können eine Markierung oder ein Label nicht mehr aus einem Knotenpool entfernen, nachdem sie angewendet wurden.

Führen Sie die folgenden Schritte aus, um einem vorhandenen Knotenpool eine Markierung und ein Label hinzuzufügen:

  1. Listen Sie die Knoten im dedizierten Knotenpool auf:

    kubectl get node --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG \
    -l baremetal.cluster.gke.io/node-pool=NODE_POOL_NAME

    Ersetzen Sie die folgenden Variablen:

    • KUBERNETES_CLUSTER_KUBECONFIG: der kubeconfig-Pfad für den Kubernetes-Cluster.
    • NODE_POOL_NAME: der Name Ihres dedizierten Knotenpools.

    Notieren Sie sich die Knoten-ID aller Knoten im Knotenpool aus der Ausgabe.

  2. Wenden Sie die Markierungen auf jeden Knoten im Knotenpool an:

    kubectl taint nodes NODE_ID \
    TAINT_KEY=TAINT_VALUE:TAINT_EFFECT \
    --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG

    Ersetzen Sie die folgenden Variablen:

    • NODE_ID: die ID des Worker-Knotens im dedizierten Knotenpool.
    • TAINT_KEY=TAINT_VALUE: ein Schlüssel/Wert-Paar, das mit einem TAINT_EFFECT-Zeitplan verknüpft ist. Beispiel: workloadType=untrusted.
    • TAINT_EFFECT: einer der folgenden Effektwerte:
      • NoSchedule: Pods, die diese Markierung nicht tolerieren, werden für den Knoten nicht geplant. Auf dem Knoten vorhandene Pods werden nicht entfernt.
      • PreferNoSchedule: Kubernetes plant für den Knoten keine Pods, die diese Markierung nicht tolerieren.
      • NoExecute: Der Pod wird aus dem Knoten entfernt, wenn er bereits auf dem Knoten ausgeführt wird. Wird er noch nicht auf dem Knoten ausgeführt, wird er nicht für den Knoten geplant.
    • KUBERNETES_CLUSTER_KUBECONFIG: der kubeconfig-Pfad für den Kubernetes-Cluster.

  3. Wenden Sie für jeden Knoten im Knotenpool die Labels an, die den Selektoren entsprechen, die Sie in Ihren Containerarbeitslasten definieren:

    kubectl label NODE_ID \
    LABEL_KEY:LABEL_VALUE \
    --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG

    Ersetzen Sie die folgenden Variablen:

    • NODE_ID: die ID des Worker-Knotens im dedizierten Knotenpool.
    • LABEL_KEY:LABEL_VALUE: die Schlüssel/Wert-Paare für die Knotenlabels, die den Selektoren entsprechen, die Sie in Ihren Arbeitslastmanifesten angeben.
    • KUBERNETES_CLUSTER_KUBECONFIG: der kubeconfig-Pfad für den Kubernetes-Cluster.

Toleranz und Knotenaffinitätsregel hinzufügen

Nachdem Sie den dedizierten Knotenpool markiert haben, können keine Arbeitslasten darin geplant werden, es sei denn, sie haben eine Toleranz, die der hinzugefügten Markierung entspricht. Fügen Sie der Spezifikation Ihrer Arbeitslasten die Toleranz hinzu, damit diese Pods im markierten Knotenpool geplant werden können.

Wenn Sie den dedizierten Knotenpool mit einem Label versehen haben, können Sie auch eine Knotenaffinitätsregel hinzufügen, um GDC anzuweisen, Ihre Arbeitslasten nur in diesem Knotenpool zu planen.

Führen Sie die folgenden Schritte aus, um Ihre Containerarbeitslast so zu konfigurieren, dass sie im dedizierten Knotenpool ausgeführt wird:

  1. Fügen Sie dem Abschnitt .spec.template.spec der Manifestdatei Ihrer Containerarbeitslast, z. B. einer benutzerdefinierten Ressource vom Typ Deployment, die folgenden Abschnitte hinzu:

    tolerations:
- key: TAINT_KEY
  operator: Equal
  value: TAINT_VALUE
  effect: TAINT_EFFECT
affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: LABEL_KEY
          operator: In
          values:
          - "LABEL_VALUE"

    Ersetzen Sie Folgendes:

    • TAINT_KEY: der Markierungsschlüssel, den Sie auf Ihren dedizierten Knotenpool angewendet haben.
    • TAINT_VALUE: der Markierungswert, den Sie auf Ihren dedizierten Knotenpool angewendet haben.
    • TAINT_EFFECT: einer der folgenden Effektwerte:
      • NoSchedule: Pods, die diese Markierung nicht tolerieren, werden für den Knoten nicht geplant. Auf dem Knoten vorhandene Pods werden nicht entfernt.
      • PreferNoSchedule: Kubernetes plant für den Knoten keine Pods, die diese Markierung nicht tolerieren.
      • NoExecute: Der Pod wird aus dem Knoten entfernt, wenn er bereits auf dem Knoten ausgeführt wird. Wird er noch nicht auf dem Knoten ausgeführt, wird er nicht für den Knoten geplant.
    • LABEL_KEY: der Knotenlabelschlüssel, den Sie auf Ihren dedizierten Knotenpool angewendet haben.
    • LABEL_VALUE: der Knotenlabelwert, den Sie auf Ihren dedizierten Knotenpool angewendet haben.

    Mit der folgenden Deployment-Ressource wird beispielsweise eine Toleranz für die Markierung workloadType=untrusted:NoExecute und eine Knotenaffinitätsregel für das Knotenlabel workloadType=untrusted hinzugefügt:

    kind: Deployment
apiVersion: apps/v1
metadata:
  name: my-app
  namespace: default
  labels:
    app: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      tolerations:
      - key: workloadType
        operator: Equal
        value: untrusted
        effect: NoExecute
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: workloadType
                operator: In
                values:
                - "untrusted"
      containers:
      - name: my-app
        image: harbor-1.org-1.zone1.google.gdc.test/harborproject/my-app
        ports:
        - containerPort: 80
      imagePullSecrets:
      - name: SECRET

  2. Aktualisieren Sie Ihre Containerarbeitslast:

    kubectl apply -f deployment.yaml -n NAMESPACE \
    --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG

    Ersetzen Sie die folgenden Variablen:

    • NAMESPACE: der Namespace Ihrer Containerarbeitslast. Bei freigegebenen Clustern muss dies ein Projekt-Namespace sein. Bei Standardclustern kann es sich um einen beliebigen Namespace handeln.
    • KUBERNETES_CLUSTER_KUBECONFIG: der kubeconfig-Pfad für den Kubernetes-Cluster.

GDC erstellt die betroffenen Pods neu. Die Knotenaffinitätsregel erzwingt die Pods für den von Ihnen erstellten dedizierten Knotenpool. Die Toleranz erlaubt es, nur diese Pods auf den Knoten zu platzieren.

Prüfen, ob die Trennung funktioniert

Prüfen Sie, ob die von Ihnen festgelegten Pods im Knotenpool mit Label ausgeführt werden.

  • Listen Sie die Pods im angegebenen Namespace auf:

    kubectl get pods -o=wide -n NAMESPACE \
    --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG

    Ersetzen Sie die folgenden Variablen:

    • NAMESPACE: der Namespace Ihrer Containerarbeitslast. Bei freigegebenen Clustern muss dies ein Projekt-Namespace sein. Bei Standardclustern kann es sich um einen beliebigen Namespace handeln.
    • KUBERNETES_CLUSTER_KUBECONFIG: der kubeconfig-Pfad für den Kubernetes-Cluster.

    Die Ausgabe sieht dann ungefähr so aus:

    pod/kube-abc-12tyuj
pod/kube-abc-39oplef
pod/kube-abc-95rzkap

    Prüfen Sie, ob Ihre Arbeitslasten im dedizierten Knotenpool ausgeführt werden.

Nächste Schritte