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.

Hinweis :Wenn Sie einem vorhandenen Knotenpool ein Taint oder Label zuweisen möchten, müssen Sie die Änderung manuell auf jeden vorhandenen Knoten anwenden. Markierungen und Labels werden nicht automatisch auf alle Knoten in einem vorhandenen Knotenpool übertragen. Weitere Informationen finden Sie unter Vorhandenen Knotenpool mit Taints und Labels versehen.

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

• Containerarbeitslasten in GDC
• Containeranwendung mit hoher Verfügbarkeit bereitstellen
• Kubernetes-Arbeitslasten für Hochverfügbarkeit