Questa pagina è stata tradotta dall'API Cloud Translation.

Isolare i carichi di lavoro in pool di nodi dedicati

Questo documento spiega come migliorare la sicurezza e la gestione del tuo cluster Kubernetes isolando i carichi di lavoro dei container all'interno di node pool dedicati in Google Distributed Cloud (GDC) air-gapped. L'isolamento dei workload ti offre un maggiore controllo sui pod e riduce il rischio di attacchi di escalation dei privilegi nel tuo cluster Kubernetes. Per ulteriori informazioni sui vantaggi e sulle limitazioni dei node pool dedicati, consulta Panoramica dell'isolamento dei nodi.

Esistono diversi flussi di lavoro per isolare i carichi di lavoro dei container, tra cui:

Applica taint ed etichetta a un node pool: applica un taint e un'etichetta a un pool di nodi in modo che i pod vengano respinti dal pool di nodi, a meno che non siano etichettati in modo specifico per l'esecuzione in quel node pool.
Aggiungi una tolleranza e una regola di affinità nodo: applica tolleranze e regole ai pod per forzarne l'esecuzione solo sul pool di nodi designato.
Verifica che la separazione funzioni: conferma che i pool di nodi contaminati eseguano solo i pod che hai etichettato per l'esecuzione.

Questi flussi di lavoro sono destinati a utenti come gli amministratori IT all'interno del gruppo di amministratori della piattaforma, responsabili della gestione dei node pool di un cluster Kubernetes, e agli sviluppatori di applicazioni all'interno del gruppo di operatori delle applicazioni, responsabili della gestione dei workload dei container. Per ulteriori informazioni, consulta Segmenti di pubblico per la documentazione air-gapped di GDC.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

Scegli un nome specifico per il taint del nodo e l'etichetta del nodo che vuoi utilizzare per i node pool dedicati. Ad esempio, workloadType=untrusted.
Se necessario, chiedi all'amministratore IAM dell'organizzazione di concederti il ruolo User Cluster Developer (user-cluster-developer), che non è associato a uno spazio dei nomi.

Contaminare ed etichettare un nuovo pool di nodi

Quando applichi un taint o un'etichetta a un nuovo pool di nodi, tutti i nodi, inclusi quelli aggiunti in un secondo momento, riceveranno automaticamente i taint e le etichette specificati.

Per aggiungere un'incompatibilità e un'etichetta a un nuovo pool di nodi:

Modifica la sezione nodePools della risorsa personalizzata Cluster direttamente durante la creazione del node pool:
```
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
```
Sostituisci quanto segue:
- TAINT_KEY: la parte relativa alla chiave della taint della coppia chiave-valore associata a una pianificazione TAINT_EFFECT. Ad esempio: workloadType.
- TAINT_VALUE: la parte del valore di contaminazione della coppia chiave-valore associata a una pianificazione TAINT_EFFECT. Ad esempio: untrusted.
- TAINT_EFFECT: uno dei seguenti valori di effetto:
  - NoSchedule: i pod che non tollerano questa incompatibilità non vengono pianificati sul nodo; i pod esistenti non vengono rimossi dal nodo.
  - PreferNoSchedule: Kubernetes evita di pianificare pod che non tollerano questa incompatibilità sul nodo.
  - NoExecute: il pod viene rimosso dal nodo se è già in esecuzione sul nodo, mentre non viene pianificato sul nodo se non è ancora in esecuzione sul nodo stesso.
- LABEL_KEY: LABEL_VALUE: le coppie chiave-valore per le etichette dei nodi, che corrispondono ai selettori specificati nei manifest dei workload.
Applica la risorsa Cluster per creare il nuovo pool di nodi:
```
kubectl apply -f cluster.yaml --kubeconfig MANAGEMENT_API_SERVER
```
Sostituisci MANAGEMENT_API_SERVER con il percorso kubeconfig del server API zonale in cui è ospitato il cluster Kubernetes. Se non hai ancora generato un file kubeconfig per il server API nella zona di destinazione, consulta Risorse del server API di gestione zonale per ulteriori informazioni.

Applica taint ed etichette a un pool di nodi esistente

Per applicare un taint o un'etichetta a un pool di nodi esistente, devi applicare le modifiche a ogni nodo esistente. Non puoi aggiornare dinamicamente le configurazioni pool di nodi.

Per aggiungere un taint e un'etichetta a un pool di nodi esistente, completa i seguenti passaggi:

Elenca i nodi nel pool di nodi dedicato:
```
kubectl get node --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG \
    -l baremetal.cluster.gke.io/node-pool=NODE_POOL_NAME
```
Sostituisci le seguenti variabili:
- KUBERNETES_CLUSTER_KUBECONFIG: il percorso kubeconfig per il cluster Kubernetes.
- NODE_POOL_NAME: il nome del tuo pool di nodi dedicato.
Prendi nota di ogni ID nodo di tutti i nodi nel pool di nodi dall'output.
Per ogni nodo nel pool di nodi, applica le incompatibilità:
```
kubectl taint nodes NODE_ID \
    TAINT_KEY=TAINT_VALUE:TAINT_EFFECT \
    --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG
```
Sostituisci le seguenti variabili:
- NODE_ID: l'ID del nodo di lavoro nel pool di nodi dedicato.
- TAINT_KEY=TAINT_VALUE: una coppia chiave-valore associata a una pianificazione TAINT_EFFECT. Ad esempio workloadType=untrusted.
- TAINT_EFFECT: uno dei seguenti valori dell'effetto:
  - NoSchedule: i pod che non tollerano questa incompatibilità non vengono pianificati sul nodo; i pod esistenti non vengono rimossi dal nodo.
  - PreferNoSchedule: Kubernetes evita di pianificare pod che non tollerano questa incompatibilità sul nodo.
  - NoExecute: il pod viene rimosso dal nodo se è già in esecuzione sul nodo, mentre non viene pianificato sul nodo se non è ancora in esecuzione sul nodo stesso.
- KUBERNETES_CLUSTER_KUBECONFIG: il percorso kubeconfig per il cluster Kubernetes.
Per ogni nodo nel pool di nodi, applica le etichette corrispondenti ai selettori che definirai nei workload dei container:
```
kubectl label NODE_ID \
    LABEL_KEY:LABEL_VALUE \
    --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG
```
Sostituisci le seguenti variabili:
- NODE_ID: l'ID del nodo di lavoro nel pool di nodi dedicato.
- LABEL_KEY:LABEL_VALUE: le coppie chiave-valore per le etichette dei nodi, che corrispondono ai selettori che specifichi nei manifest dei workload.
- KUBERNETES_CLUSTER_KUBECONFIG: il percorso kubeconfig per il cluster Kubernetes.

Aggiungi una tolleranza e una regola di affinità dei nodi

Dopo aver applicato l'incompatibilità al pool di nodi dedicato, nessun workload può essere pianificato al suo interno, a meno che non abbia una tolleranza corrispondente all'incompatibilità che hai aggiunto. Aggiungi la tolleranza alla specifica dei tuoi workload per consentire la pianificazione di questi pod nelpool di nodil con incompatibilità.

Se hai etichettato il pool di nodi dedicato, puoi anche aggiungere una regola di affinità dei nodi per indicare a GDC di pianificare i carichi di lavoro solo su quel pool di nodi.

Per configurare il workload del container in modo che venga eseguito nel pool di nodi dedicato, completa i seguenti passaggi:

Aggiungi le seguenti sezioni alla sezione .spec.template.spec del file manifest del carico di lavoro del container, ad esempio una risorsa personalizzata Deployment:

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

Sostituisci quanto segue:

TAINT_KEY: la chiave di taint che hai applicato al tuo pool di nodi dedicato.
TAINT_VALUE: il valore di taint che hai applicato al pool di nodi dedicato.
TAINT_EFFECT: uno dei seguenti valori di effetto:
- NoSchedule: i pod che non tollerano questa incompatibilità non vengono pianificati sul nodo; i pod esistenti non vengono rimossi dal nodo.
- PreferNoSchedule: Kubernetes evita di pianificare pod che non tollerano questa incompatibilità sul nodo.
- NoExecute: il pod viene rimosso dal nodo se è già in esecuzione sul nodo, mentre non viene pianificato sul nodo se non è ancora in esecuzione sul nodo stesso.
LABEL_KEY: la chiave dell'etichetta del nodo che hai applicato al tuo pool di nodi dedicato.
LABEL_VALUE: il valore dell'etichetta del nodo che hai applicato al tuo pool di nodi dedicato.

Ad esempio, la seguente risorsa Deployment aggiunge una tolleranza per il taint workloadType=untrusted:NoExecute e una regola di affinità dei nodi per l'etichetta del nodo workloadType=untrusted:

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

Aggiorna il carico di lavoro del container:
```
kubectl apply -f deployment.yaml -n NAMESPACE \
    --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG
```
Sostituisci le seguenti variabili:
- NAMESPACE: lo spazio dei nomi del progetto del workload del container.
- KUBERNETES_CLUSTER_KUBECONFIG: il percorso kubeconfig per il cluster Kubernetes.

GDC ricrea i pod interessati. La regola di affinità dei nodi forza i pod nel pool di nodi dedicato che hai creato. La tolleranza consente di posizionare solo questi pod sui nodi.

Verificare che la separazione funzioni

Verifica che i pod che hai designato siano in esecuzione sul pool di nodi etichettato.

Elenca i pod nello spazio dei nomi specificato:
```
kubectl get pods -o=wide -n NAMESPACE \
    --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG
```
Sostituisci le seguenti variabili:
- NAMESPACE: lo spazio dei nomi del progetto del workload del container.
- KUBERNETES_CLUSTER_KUBECONFIG: il percorso kubeconfig per il cluster Kubernetes.
L'output è simile al seguente:
```
pod/kube-abc-12tyuj
pod/kube-abc-39oplef
pod/kube-abc-95rzkap
```
Verifica che i tuoi workload siano in esecuzione nel pool di nodi dedicato.