Arbeitslasten in dedizierten Knotenpools isolieren

In diesem Dokument wird beschrieben, wie Sie die Sicherheit und Verwaltung Ihres Kubernetes-Clusters verbessern können, indem Sie Containerarbeitslasten in dedizierten Knotenpools in Google Distributed Cloud (GDC) Air-Gapped isolieren. Durch die Isolierung Ihrer Arbeitslasten haben Sie mehr Kontrolle über Ihre Pods und verringern das Risiko von Angriffen zur Eskalation von Berechtigungen in Ihrem Kubernetes-Cluster. Weitere Informationen zu den Vorteilen und Einschränkungen von dedizierten Knotenpools finden Sie unter Knotenisolation.

Es gibt mehrere Workflows zum Isolieren Ihrer Containerarbeitslasten, darunter die folgenden:

  • Knotenpool markieren und mit Labels versehen: Wenden Sie eine Markierung und ein Label auf einen Knotenpool an, damit Pods nicht in diesem Knotenpool ausgeführt werden, es sei denn, sie sind speziell für die Ausführung dort gekennzeichnet.

  • Toleranz und Knotenaffinitätsregel hinzufügen: Wenden Sie Toleranzen und Regeln auf Ihre Pods an, damit sie nur im dafür vorgesehenen Knotenpool ausgeführt werden.

  • Prüfen, ob die Trennung funktioniert: Vergewissern Sie sich, dass auf Ihren Knotenpools mit Taint nur die Pods ausgeführt werden, die Sie für die Ausführung dort gekennzeichnet haben.

Diese Workflows sind für Zielgruppen wie IT-Administratoren in der Gruppe der Plattformadministratoren gedacht, die für die Verwaltung der Knotenpools eines Kubernetes-Clusters verantwortlich sind, sowie für Anwendungsentwickler in der Gruppe der Anwendungsoperatoren, die für die Verwaltung von Containerarbeitslasten verantwortlich sind. Weitere Informationen finden Sie in der Dokumentation zu Zielgruppen für GDC-Air-Gap-Umgebungen.

Hinweise

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • 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.

  • Bitten Sie bei Bedarf den IAM-Administrator Ihrer Organisation, Ihnen die Rolle „User Cluster Developer“ (user-cluster-developer) zuzuweisen, die nicht an einen Namespace gebunden ist.

Neuen Knotenpool markieren und mit Labels versehen

Wenn Sie einem neuen Knotenpool eine Markierung oder ein Label hinzufügen, erhalten alle Knoten, einschließlich aller später hinzugefügten Knoten, automatisch die angegebenen Markierungen und Labels.

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

  1. Bearbeiten Sie den nodePools-Abschnitt der benutzerdefinierten Cluster-Ressource direkt beim Erstellen des Knotenpools:

    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 Markierungsschlüsselteil des Schlüssel/Wert-Paars, das einem TAINT_EFFECT-Zeitplan zugeordnet ist. Beispiel: workloadType
    • TAINT_VALUE: der Markierungswertteil des Schlüssel/Wert-Paares, das einem TAINT_EFFECT-Zeitplan zugeordnet 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, oder wird nicht für den Knoten geplant, wenn er noch nicht auf dem Knoten ausgeführt wird.
    • 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 Cluster-Ressource 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. Wenn Sie noch keine kubeconfig-Datei für den API-Server in Ihrer Zielzone generiert haben, finden Sie weitere Informationen unter Zonale Management API-Serverressourcen.

Vorhandenen Knotenpool markieren und mit Labels versehen

Wenn Sie einem vorhandenen Knotenpool ein Taint oder Label zuweisen möchten, müssen Sie die Änderungen auf jeden vorhandenen Knoten anwenden. Sie können Knotenpoolkonfigurationen nicht dynamisch aktualisieren.

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

  1. Knoten im dedizierten Knotenpool auflisten:

    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 des dedizierten Knotenpools.

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

  2. Wenden Sie die Taints 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, oder wird nicht für den Knoten geplant, wenn er noch nicht auf dem Knoten ausgeführt wird.
    • 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 Workload-Manifesten 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 für die Ausführung im dedizierten Knotenpool zu konfigurieren:

  1. Fügen Sie der Manifestdatei für die Containerarbeitslast, z. B. einer benutzerdefinierten Deployment-Ressource, die folgenden Abschnitte zum Abschnitt .spec.template.spec hinzu:

      # Several lines of code are omitted here.
        spec:
          template:
            spec:
              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"
            # Several lines of code are omitted here.
    

    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, oder wird nicht für den Knoten geplant, wenn er noch nicht auf dem Knoten ausgeführt wird.
    • LABEL_KEY: der Knotenlabel-Schlü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. Containerarbeitslast aktualisieren:

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

    Ersetzen Sie die folgenden Variablen:

    • NAMESPACE: der Projekt-Namespace Ihrer Containerarbeitslast.
    • 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 angegebenen Pods im Knotenpool mit dem 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 Projekt-Namespace Ihrer Containerarbeitslast.
    • 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