Arbeitslasten in dedizierten Knotenpools isolieren

Freigegeben Standard

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) mit Air Gap isolieren. Durch das Isolieren Ihrer Arbeitslasten haben Sie mehr Kontrolle über Ihre Pods und verringern das Risiko von Angriffen durch Rechteausweitung in Ihrem Kubernetes-Cluster. Weitere Informationen zu den Vorteilen und Einschränkungen von dedizierten Knotenpools finden Sie unter Übersicht zur 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 aus dem Knotenpool entfernt 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, um zu erzwingen, dass sie nur im angegebenen Knotenpool ausgeführt werden.

• Prüfen, ob die Trennung funktioniert: Bestätigen Sie, dass in Ihren markierten Knotenpools nur die Pods ausgeführt werden, die Sie für die Ausführung dort gekennzeichnet haben.

Diese Workflows richten sich an Zielgruppen wie IT-Administratoren in der Gruppe der Plattformadministratoren, die für die Verwaltung der Knotenpools eines Kubernetes-Clusters verantwortlich sind, und Anwendungsentwickler in der Gruppe der Anwendungsoperatoren, die für die Verwaltung von Containerarbeitslasten verantwortlich sind. Weitere Informationen finden Sie unter Dokumentation zu Zielgruppen für 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 zum Isolieren von Containerarbeitslasten in Ihrem Kubernetes-Cluster erforderlich sind. Die erforderlichen Rollen hängen davon ab, ob Sie in einem organisationsbezogenen freigegebenen Cluster oder einem projektbezogenen Standardcluster arbeiten. Weitere Informationen finden Sie unter Kubernetes-Clusterkonfigurationen.

Rollen für freigegebene Cluster

Wenden Sie sich an Ihren IAM-Administrator der Organisation, um die folgenden Rollen anzufordern, um einen Knotenpool in einem freigegebenen Cluster zu markieren und mit Labels zu versehen:

• Nutzerclusteradministrator (user-cluster-admin): Ressourcen eines freigegebenen Clusters erstellen, löschen, bearbeiten oder ansehen, der auf dem Management API-Server gehostet wird. Diese Rolle bietet Zugriff auf die Knotenpools des freigegebenen Clusters.

• Nutzerclusterentwickler (user-cluster-developer): Einen freigegebenen Cluster erstellen, löschen, bearbeiten oder ansehen. Diese Rolle bietet Zugriff auf die Datenebenen-APIs, die im freigegebenen Cluster gehostet werden.

Diese Rollen sind nicht an einen Namespace gebunden.

Rollen für Standardcluster

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

• Clusteradministrator (cluster-admin): Alle Ressourcen in einem Standardcluster erstellen, löschen, bearbeiten oder ansehen. Diese Rolle bietet Zugriff auf die Datenebenen-APIs, die im Standardcluster gehostet werden und die Ressourcen des Clusters verwalten.

• Clusterentwickler (cluster-developer): Einen Standardcluster erstellen, löschen, bearbeiten oder ansehen. Diese Rolle bietet Zugriff auf die Datenebenen-APIs, die im Standardcluster gehostet werden und den Cluster verwalten.

• Standardclusteradministrator (standard-cluster-admin): Ressourcen eines Standardclusters erstellen, löschen, bearbeiten oder ansehen, der auf dem Management API-Server gehostet wird. Diese Rolle bietet Zugriff auf die Knotenpools des Standardclusters.

Diese Rollen sind an Ihren Projekt-Namespace gebunden.

Umgebung vorbereiten

Wenn Sie Befehle für einen Kubernetes-Cluster mit der 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 in dieser Anleitung KUBERNETES_CLUSTER_KUBECONFIG 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 in dieser Anleitung MANAGEMENT_API_SERVER durch den kubeconfig-Pfad des Management 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 aus einem Knotenpool entfernen, nachdem es angewendet wurde.

Hinweis: Wenn Sie eine Markierung oder ein Label auf einen vorhandenen Knotenpool anwenden 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 markieren und mit Labels versehen.

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

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

   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 mit einem Zeitplan TAINT_EFFECT verknüpft ist. Beispiel: workloadType.
   • TAINT_VALUE: Der Markierungswertteil des Schlüssel/Wert-Paars, das mit einem Zeitplan TAINT_EFFECT verknüpft ist. Beispiel: untrusted.
   • TAINT_EFFECT: Einer der folgenden Effekt werte:
     • NoSchedule: Pods, die diese Markierung nicht tolerieren, werden nicht auf dem Knoten geplant. Vorhandene Pods werden nicht vom Knoten entfernt.
     • PreferNoSchedule: Kubernetes vermeidet es, Pods, die diese Markierung nicht tolerieren, auf dem Knoten zu planen.
     • NoExecute: Der Pod wird vom Knoten entfernt, wenn er bereits auf dem Knoten ausgeführt wird, und wird nicht auf dem 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 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. Sie können Knotenpoolkonfigurationen nicht dynamisch aktualisieren.

Sie können eine Markierung oder ein Label nicht aus einem Knotenpool entfernen, nachdem es angewendet wurde.

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 in der Ausgabe die Knoten-IDs aller Knoten im Knotenpool.

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 Zeitplan verknüpft ist. TAINT_EFFECT. Beispiel: workloadType=untrusted.
   • TAINT_EFFECT: Einer der folgenden Effektwerte:
     • NoSchedule: Pods, die diese Markierung nicht tolerieren, werden nicht auf dem Knoten geplant. Vorhandene Pods werden nicht vom Knoten entfernt.
     • PreferNoSchedule: Kubernetes vermeidet es, Pods, die diese Markierung nicht tolerieren, auf dem Knoten zu planen.
     • NoExecute: Der Pod wird vom Knoten entfernt, wenn er bereits auf dem Knoten ausgeführt wird, und wird nicht auf dem 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: the 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 für die Ausführung im dedizierten Knotenpool zu konfigurieren:

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

   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 nicht auf dem Knoten geplant. Vorhandene Pods werden nicht vom Knoten entfernt.
     • PreferNoSchedule: Kubernetes vermeidet es, Pods, die diese Markierung nicht tolerieren, auf dem Knoten zu planen.
     • NoExecute: Der Pod wird vom Knoten entfernt, wenn er bereits auf dem Knoten ausgeführt wird, und wird nicht auf dem Knoten geplant, wenn er noch nicht auf dem Knoten ausgeführt wird.
   • LABEL_KEY: der Labelschlüssel, den Sie auf Ihren dedizierten Knotenpool angewendet haben.
   • LABEL_VALUE: Der Knotenlabelwert, den Sie auf Ihren dedizierten Knotenpool angewendet haben.

   Die folgende Deployment Ressource fügt beispielsweise eine Toleranz für die workloadType=untrusted:NoExecute Markierung und eine Knotenaffinitätsregel für das workloadType=untrusted Knotenlabel hinzu:

   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 ein beliebiger Namespace sein.
   • 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 markierten Knotenpool 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 ein beliebiger Namespace sein.
  • 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
  

  Bestätigen Sie, dass Ihre Arbeitslasten im dedizierten Knotenpool ausgeführt werden.

Nächste Schritte

• Containerarbeitslasten in GDC
• Hochverfügbare Containeranwendung bereitstellen
• Kubernetes-Arbeitslasten für Hochverfügbarkeit