Rete di pod e container

Questo argomento descrive come personalizzare la rete di pod e container per i cluster del carico di lavoro, inclusi l'utilizzo di una CNI (Cluster Network Interface) diversa da quella predefinita Antrea e il supporto di indirizzi IP senza NAT instradabili pubblicamente per i cluster del carico di lavoro in vSphere con la rete VMware NSX.

Creazione di un cluster con una CNI non predefinita

Quando si utilizza la CLI di Tanzu per distribuire un cluster del carico di lavoro, nel cluster viene abilitata automaticamente una CNI (Cluster Network Interface) Antrea. In alternativa, è possibile abilitare una CNI Calico o il proprio provider di CNI.

Poiché i pacchetti gestiti automaticamente sono gestiti da Tanzu Kubernetes Grid, non è in genere necessario aggiornarne le configurazioni. Tuttavia, può essere necessario creare un cluster del carico di lavoro che utilizzi una CNI personalizzata, ad esempio Calico. Nelle sezioni seguenti vengono descritti i passaggi per configurare una CNI personalizzata come Calico.

CNI personalizzata per cluster distribuiti da un cluster di gestione autonomo

I cluster del carico di lavoro distribuiti da un cluster di gestione autonomo con una versione di Tanzu Kubernetes Grid precedente alla 1.2.x e quindi aggiornati alla versione 1.3 continuano a utilizzare Calico come provider CNI. Non è possibile modificare il provider CNI per questi cluster.

È possibile modificare l'interfaccia CNI predefinita per un cluster del carico di lavoro che si sta distribuendo da un cluster di gestione autonomo specificando la variabile CNI nel file di configurazione. La variabile CNI supporta le opzioni seguenti:

(Predefinita) antrea: abilita Antrea.
calico: abilita Calico. Vedere CNI di Calico. Questa opzione non è supportata in Windows.
none: consente di abilitare un provider CNI personalizzato. Vedere CNI personalizzata.

Se non si imposta la variabile CNI, l'opzione Antrea viene abilitata per impostazione predefinita.

CNI di Calico

Per abilitare Calico in un cluster del carico di lavoro, specificare quanto segue nel file di configurazione:

CNI: calico

Al termine del processo di creazione del cluster, è possibile controllare il cluster come descritto in Connessione e controllo dei cluster del carico di lavoro.

CNI personalizzata

Per abilitare un provider CNI personalizzato diverso da Calico in un cluster del carico di lavoro, eseguire i passaggi seguenti:

Specificare CNI: none nel file di configurazione quando si crea il cluster. Ad esempio:
```
CNI: none
```
Il processo di creazione del cluster non riuscirà finché non si applica una CNI al cluster. È possibile monitorare il processo di creazione del cluster nei registri di Cluster API nel cluster di gestione. Per istruzioni su come accedere ai registri di Cluster API, vedere Registri e monitoraggio.
Dopo aver inizializzato il cluster, applicare il provider CNI al cluster:
1. Recuperare le credenziali admin del cluster. Ad esempio:
```
tanzu cluster kubeconfig get my-cluster --admin
```
2. Impostare il contesto di kubectl sul cluster. Ad esempio:
```
kubectl config use-context my-cluster-admin@my-cluster
```
3. Applicare il provider della CNI al cluster:
```
kubectl apply -f PATH-TO-YOUR-CNI-CONFIGURATION/example.yaml
```
Monitorare lo stato del cluster utilizzando il comando tanzu cluster list. Al termine della creazione del cluster, lo stato del cluster passa da creating a running. Per ulteriori informazioni su come controllare il cluster, vedere Connessione e controllo dei cluster del carico di lavoro.

CNI di Calico per cluster del carico di lavoro basati sulla classe supervisore o a nodo singolo

Per installare calico anziché antrea in un cluster basato su classi distribuito da un supervisore o distribuito come cluster di carichi di lavoro a nodo singolo da un cluster di gestione autonomo, è necessario personalizzare l'oggetto ClusterBootstrap del cluster come segue:

Creare un file YAML contenente gli oggetti Kubernetes seguenti:

apiVersion: cni.tanzu.vmware.com/v1alpha1
kind: CalicoConfig
metadata:
name: CLUSTER-NAME
namespace: CLUSTER-NAMESPACE
spec:
calico:
  config:
    vethMTU: 0
---
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: ClusterBootstrap
metadata:
annotations:
  tkg.tanzu.vmware.com/add-missing-fields-from-tkr: TKR-VERSION
name: CLUSTER-NAME
namespace: CLUSTER-NAMESPACE
spec:
additionalPackages: # Customize additional packages
- refName: metrics-server*
- refName: secretgen-controller*
- refName: pinniped*
cni:
  refName: calico*
  valuesFrom:
    providerRef:
      apiGroup: cni.tanzu.vmware.com
      kind: CalicoConfig
      name: CLUSTER-NAME

In cui:

CLUSTER-NAME è il nome del cluster del carico di lavoro che si intende creare.
CLUSTER-NAMESPACE è lo spazio dei nomi del cluster del carico di lavoro.
TKR-VERSION è la versione di Tanzu Kubernetes (TKr) che si intende utilizzare per il cluster del carico di lavoro. Ad esempio:
- v1.23.5+vmware.1-tkg.1 per un cluster distribuito dal supervisore o
- v1.25.7---vmware.1-tiny.1-tkg.1 per un cluster con un nodo singolo, come descritto in Cluster a nodo singolo su vSphere (anteprima tecnica)

Per i cluster a nodo singolo, eliminare il blocco spec.additionalPackages dalla definizione ClusterBootstrap. I cluster a nodo singolo non dispongono dei pacchetti aggiuntivi metrics-server, secretgen-controller e pinniped.
Applicare il file eseguendo il comando kubectl apply -f rispetto al cluster di gestione, che si tratti di un supervisore o di un cluster di gestione autonomo.

Creare un file YAML per l'oggetto Cluster con la seguente configurazione:

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
name: CLUSTER-NAME
namespace: CLUSTER-NAMESPACE
spec:
clusterNetwork:
  services:
    cidrBlocks: ["SERVICES-CIDR"]
  pods:
    cidrBlocks: ["PODS-CIDR"]
  serviceDomain: "SERVICE-DOMAIN"
topology:
  class: tanzukubernetescluster
  version: TKR-VERSION
  controlPlane:
    replicas: 1
  workers:
    machineDeployments:
      - class: node-pool
        name: NODE-POOL-NAME
        replicas: 1
  variables:
    - name: vmClass
      value: VM-CLASS
    # Default storageClass for control plane and node pool
    - name: storageClass
      value: STORAGE-CLASS-NAME

In cui:

CLUSTER-NAME è il nome del cluster del carico di lavoro che si intende creare.
CLUSTER-NAMESPACE è lo spazio dei nomi del cluster del carico di lavoro.
SERVICES-CIDR è il blocco CIDR per i servizi. Ad esempio, 198.51.100.0/12.
PODS-CIDR è il blocco CIDR per i pod. Ad esempio, 192.0.2.0/16.
SERVICE-DOMAIN è il nome del dominio del servizio. Ad esempio, cluster.local.
TKR-VERSION è la versione del TKr che si intende utilizzare per il cluster del carico di lavoro. Ad esempio, v1.23.5+vmware.1-tkg.1.
NODE-POOL-NAME è il nome del pool di nodi per machineDeployments.
VM-CLASS è il nome della classe di macchina virtuale che si desidera utilizzare per il cluster. Ad esempio, best-effort-small.
STORAGE-CLASS-NAME è il nome della classe di storage che si desidera utilizzare per il cluster. Ad esempio, wcpglobal-storage-profile.

Ad esempio:

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
name: my-workload-cluster
namespace: my-workload-cluster-namespace
spec:
clusterNetwork:
 services:
   cidrBlocks: ["198.51.100.0/12"]
 pods:
   cidrBlocks: ["192.0.2.0/16"]
 serviceDomain: "cluster.local"
topology:
 class: tanzukubernetescluster
 version: v1.23.5+vmware.1-tkg.1
 controlPlane:
   replicas: 1
 workers:
   machineDeployments:
     - class: node-pool
       name: my-node-pool
       replicas: 1
 variables:
   - name: vmClass
     value: best-effort-small
   # Default storageClass for control plane and node pool
   - name: storageClass
     value: wcpglobal-storage-profile

Creare il cluster del carico di lavoro passando il file di definizione dell'oggetto Cluster creato nel passaggio precedente all'opzione -f del comando tanzu cluster create.

CNI di Calico per i cluster basati su TKC distribuiti da un supervisore

Per installare calico anziché antrea in un cluster del carico di lavoro distribuito da un supervisore di tipo TanzuKubernetesCluster, impostare la variabile di configurazione CNI nel file di configurazione del cluster che si intende utilizzare per creare il cluster del carico di lavoro e quindi passare il file all'opzione -f del comando tanzu cluster create. Ad esempio, CNI: calico.

Abilitazione di più provider CNI

Per abilitare più provider CNI in un cluster del carico di lavoro, ad esempio macvlan, ipvlan, SR-IOV o DPDK, installare il pacchetto Multus in un cluster in cui è già in esecuzione la CNI Antrea o Calico e creare ulteriori risorse NetworkAttachmentDefinition per le CNI. È quindi possibile creare nel cluster nuovi pod che utilizzino interfacce di rete diverse per intervalli di indirizzi diversi.

Per indicazioni vedere Distribuzione di Multus nei cluster del carico di lavoro.

Distribuzione di pod con indirizzi IP senza NAT (NSX) instradabili

In vSphere con rete NSX e Container Network Interface (CNI) Antrea, è possibile configurare un cluster del carico di lavoro con indirizzi IP instradabili per i pod di worker, ignorando NAT (Network Address Translation) per le richieste esterne da e verso i pod.

Gli indirizzi IP instradabili nei pod consentono di:

Tenere traccia delle richieste in uscita verso i servizi condivisi comuni, perché il loro indirizzo IP di origine è l'indirizzo IP del pod instradabile, non un indirizzo NAT.
Supportare le richieste in entrata autenticate da Internet esterno direttamente nei pod, ignorando NAT.

Configurazione di NSX per pod con IP instradabili

Per configurare NSX in modo che supporti indirizzi IP instradabili per i pod worker:

Passare al server NSX e aprire la scheda Rete (Networking).
In Connettività > Gateway di livello 1, fare clic su Aggiungi gateway di livello 1 e configurare un nuovo gateway di livello 1 dedicato ai pod con IP instradabili:
- Nome: creare un nome per il gateway di livello 1 dei pod instradabili.
- Gateway di livello 0 collegato: selezionare il gateway di livello 0 che gli altri gateway di livello 1 per Tanzu Kubernetes Grid utilizzano.
- Cluster Edge: selezionare un cluster Edge esistente.
- Annuncio della route: Abilitare Tutte le route statiche, Tutti gli IP NAT e Tutte le porte dei servizi e i segmenti connessi.
Fare clic su Salva per salvare il gateway.
In Connettività > Segmenti, fare clic su Aggiungi segmento e configurare un nuovo segmento NSX, un commutatore logico, per i nodi del cluster del carico di lavoro che contengono i pod instradabili:
- Nome: creare un nome per il segmento di rete per i nodi del cluster del carico di lavoro.
- Connettività: selezionare il gateway di livello 1 appena creato.
- Zona di trasporto: selezionare una zona di trasporto overlay, ad esempio tz-overlay.
- Subnet: scegliere un intervallo di indirizzi IP per i nodi del cluster, ad esempio 195.115.4.1/24. Questo intervallo non deve sovrapporsi ai valori del profilo DHCP Indirizzo IP server.
- Annuncio della route: Abilitare Tutte le route statiche, Tutti gli IP NAT e Tutte le porte dei servizi e i segmenti connessi.
Fare clic su Salva per salvare il gateway.

Pod TKC distribuiti da un supervisore con indirizzi IP instradabili

Per informazioni su come distribuire un cluster TKC con pod di worker che dispongono di indirizzi IP instradabili senza NAT, vedere Esempio v1beta1 : Cluster con rete di pod instradabili.

Pod distribuiti da cluster di gestione autonomo con indirizzi IP instradabili

Per utilizzare un cluster di gestione autonomo per distribuire un cluster del carico di lavoro con pod worker che dispongono di indirizzi IP instradabili senza NAT, eseguire i passaggi seguenti. L'impostazione di CLUSTER_CIDR del cluster configura l'intervallo degli indirizzi IP instradabili pubblicamente.

Creare un file di configurazione del cluster del carico di lavoro come descritto in Creazione di un file di configurazione di un cluster del carico di lavoro e in base alle indicazioni seguenti:
- Per impostare il blocco degli indirizzi IP instradabili assegnati ai pod di worker, è possibile:
  - Impostare CLUSTER_CIDR nel file di configurazione del cluster del carico di lavoro o
  - Anteporre il comando tanzu cluster create con un'impostazione CLUSTER_CIDR=, come illustrato nel passaggio seguente.
- Impostare NSXT_POD_ROUTING_ENABLED su "true".
- Impostare NSXT_MANAGER_HOST sull'indirizzo IP di NSX Manager.
- Impostare NSXT_ROUTER_PATH sul percorso dell'inventario del gateway di livello 1 appena aggiunto per gli IP instradabili. A tale scopo, in NSX Manager > Connettività > Gateway di livello 1, fare clic sull'icona del menu () a sinistra del nome del gateway e fare clic su Copia percorso negli appunti. Il nome inizia con "/infra/tier-1s/
- Impostare le altre variabili della stringa NSXT_ per accedere a NSX seguendo la tabella Routing del pod NSX in Informazioni di riferimento sulle variabili del file di configurazione. I pod possono eseguire l'autenticazione in NSX in uno dei quattro modi seguenti (il meno sicuro è indicato per ultimo):
  - Certificato: impostare NSXT_CLIENT_CERT_KEY_DATA, NSXT_CLIENT_CERT_KEY_DATA e, per un certificato emesso da un'autorità di certificazione, NSXT_ROOT_CA_DATA_B64.
  - Token di VMware Identity Manager in VMware Cloud (VMC): impostare NSXT_VMC_AUTH_HOST e NSXT_VMC_ACCESS_TOKEN.
  - Nome utente/password archiviati in un segreto Kubernetes: impostare NSXT_SECRET_NAMESPACE, NSXT_SECRET_NAME, NSXT_USERNAME e NSXT_PASSWORD.
  - Nome utente/password come testo normale nel file di configurazione: impostare NSXT_USERNAME e NSXT_PASSWORD.

Eseguire tanzu cluster create come descritto in Creazione di cluster del carico di lavoro. Ad esempio:

$ CLUSTER_CIDR=100.96.0.0/11 tanzu cluster create my-routable-work-cluster -f my-routable-work-cluster-config.yaml
Validating configuration...
Creating workload cluster 'my-routable-work-cluster'...
Waiting for cluster to be initialized...
Waiting for cluster nodes to be available...

Convalida degli IP instradabili

Per testare gli indirizzi IP instradabili per i pod del carico di lavoro:

Distribuire un server Web nel cluster del carico di lavoro instradabile.
Eseguire kubectl get pods --o wide per recuperare i valori NAME, INTERNAL-IP e EXTERNAL-IP per i pod instradabili e verificare che gli indirizzi IP elencati siano identici e siano compresi nell'intervallo CLUSTER_CIDR instradabile.
Eseguire kubectl get nodes --o wide per recuperare i valori NAME, INTERNAL-IP e EXTERNAL-IP per i nodi del cluster del carico di lavoro che contengono i pod con IP instradabili.
Accedere al nodo del piano di controllo di un cluster del carico di lavoro diverso:
1. Eseguire kubectl config use-context CLUSTER-CONTEXT per modificare il contesto nel cluster diverso.
2. Eseguire kubectl get nodes per recuperare l'indirizzo IP del nodo del piano di controllo del cluster corrente.
3. Eseguire ssh capv@CONTROLPLANE-IP utilizzando l'indirizzo IP appena recuperato.
4. Eseguire il ping delle richieste curl e inviarle all'indirizzo IP instradabile in cui è stato distribuito il server Web e verificare le risposte.
  - L'output del ping indica l'IP del pod instradabile del server Web come indirizzo di origine.
Da un browser, accedere a NSX e passare al gateway di livello 1 creato per i pod con IP instradabili.
Fare clic su Route statiche e verificare che le route seguenti siano state create nell'intervallo CLUSTER_CIDR instradabile:
1. Una route per i pod nel nodo del piano di controllo del cluster del carico di lavoro, con Hop successivi indicati come indirizzo del nodo del piano di controllo stesso.
2. Una route per i pod nei nodi worker del cluster del carico di lavoro, con Hop successivi indicati come indirizzi dei nodi worker stessi.

Eliminazione di IP instradabili

Dopo aver eliminato un cluster del carico di lavoro che contiene pod con IP instradabili, potrebbe essere necessario liberare gli indirizzi IP instradabili eliminandoli dal router di livello 1:

In NSX Manager > Connettività > Gateway di livello 1 selezionare il gateway con IP instradabili.
In Route statiche fare clic sul numero di route per aprire l'elenco.
Cercare le route che includono il nome del cluster eliminato ed eliminarle tutte dall'icona del menu () a sinistra del nome della route.
1. Se un errore relativo alle autorizzazioni impedisce l'eliminazione della route dal menu, cosa che può verificarsi se la route è stata creata da un certificato, eliminare la route tramite l'API:
  1. Dal menu accanto al nome della route, selezionare Copia percorso negli appunti.
  2. Eseguire curl -i -k -u 'NSXT_USERNAME:NSXT_PASSWORD' -H 'Content-Type: application/json' -H 'X-Allow-Overwrite: true' -X DELETE https://NSXT_MANAGER_HOST/policy/api/v1/STATIC-ROUTE-PATH in cui:
    - NSXT_MANAGER_HOST, NSXT_USERNAME e NSXT_PASSWORD sono l'indirizzo IP e le credenziali di NSX Manager
    - STATIC_ROUTE_PATH è il percorso appena copiato negli appunti. Il nome inizia con /infra/tier-1s/ e include /static-routes/.

Impostazione dei criteri di rete per le CNI

Per impedire a un cluster del carico di lavoro di accedere all'interfaccia di gestione di VMware vCenter Server, impostare criteri di rete appropriati nelle CNI Antrea e Calico. Quando si configurano questi criteri, viene filtrato solo il traffico proveniente dalla rete del container. I criteri bloccano il traffico proveniente da tutti i pod ad eccezione di quelli dei pod CSI (Container Storage Interface) e CPI (Cloud Provider Interface).

Impostazione dei criteri di rete del cluster per Antrea

Impostare i criteri di rete del cluster per Antrea tramite il file antrea-policy-csi-cpi.yaml nel cluster del carico di lavoro. A tale scopo:

Nella CLI di Tanzu, passare al contesto del cluster del carico di lavoro:
```
kubectl config use-context WORKLOAD-CLUSTER-CONTEXT
```

Creare un file antrea-policy-csi-cpi.yaml come illustrato nell'esempio seguente:

apiVersion: crd.antrea.tanzu.vmware.com/v1alpha1
kind: TierEntitlement
metadata:
  name: edit-system-tiers
spec:
  permission: edit
  tiers:
  - emergency
  - securityops
  - networkops
  - platform
# application and baseline Tiers are not restricted
---
apiVersion: crd.antrea.tanzu.vmware.com/v1alpha1
kind: TierEntitlementBinding
metadata:
  name: admin-edit-system-tiers
spec:
  # Allow only admin to attach Antrea ClusterNetworkPolicy and NetworkPolicy to system Tiers
  subjects:
  - kind: User
    name: admin
  tierEntitlement: edit-system-tiers
---
apiVersion: crd.antrea.io/v1alpha3
kind: ClusterGroup
metadata:
  name: vc-ip
spec:
  ipBlocks:
  - cidr: VC_IP_CIDR # Enter the IP CIDR of vCenter Server, for example 192.168.1.1/3.
---
apiVersion: crd.antrea.io/v1alpha3
kind: ClusterGroup
metadata:
  name: csi-cpi-pods
spec:
  namespaceSelector:
    matchLabels:
      kubernetes.io/metadata.name: kube-system
    podSelector:
      matchExpressions:
      - key: k8s-app
        operator: In
        values: [vsphere-cloud-controller-manager]
---
apiVersion: crd.antrea.io/v1alpha1
kind: ClusterNetworkPolicy
metadata:
  name: allow-csi-cpi-egress-vc
spec:
  priority: 5
  tier: emergency
  appliedTo:
  - group: csi-cpi-pods
  egress:
  - action: Pass
    to:
    - group: vc-ip
---
apiVersion: crd.antrea.io/v1alpha1
kind: ClusterNetworkPolicy
metadata:
  name: drop-egress-vc
spec:
  priority: 10
  tier: emergency
  appliedTo:
  - namespaceSelector: {}  # Selects all Namespaces in the cluster
  egress:
  - action: Drop
    to:
    - group: vc-ip

Nota
Nel campo cidr: immettere il CIDR IP del vCenter Server, ad esempio 192.168.1.1/32.

Applicare il file:

kubectl apply -f antrea-policy-csi-cpi.yaml

Impostazione dei criteri di rete per Calico

Impostare i criteri di rete del cluster per Calico tramite il file gnp.yaml nel cluster del carico di lavoro. A tale scopo:

Scaricare il file binario dell'utilità calicoctl per il sistema operativo dalla posizione Github.

Installare l'utilità nel sistema. Ad esempio, per scaricare e installare l'utilità in un sistema Linux:

wget https://github.com/projectcalico/calico/releases/download/CALICO-VERSION/calicoctl-linux-amd64
mv calicoctl-linux-amd64 calicoctl
chmod +x calicoctl

Nella CLI di Tanzu, passare al contesto del cluster del carico di lavoro:
```
kubectl config use-context WORKLOAD-CLUSTER-CONTEXT
```

Creare un file gnp.yaml come illustrato nell'esempio seguente:

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
name: vcenter-egress-deny-all
spec:
order: 1000
types:
  - Egress
egress:
  - action: Allow
    destination:
      notNets:
      -  VC_IP_CIDR # Enter the IP CIDR of vCenter Server, for example 192.168.1.1/32.

---
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
name: vcenter-egress-allow-csi-cpi
spec:
order: 0
types:
  - Egress
egress:
  - action: Allow
    source:
      selector: app == 'vsphere-csi-node' || app == 'vsphere-csi-controller' || k8s-app == 'vsphere-cloud-controller-manager'
    destination:
      nets:
      - VC_IP_CIDR # Enter the IP CIDR of vCenter Server, for example 192.168.1.1/32.

Nota
Nei campi notNets: e nets: immettere il CIDR IP di vCenter Server, ad esempio 192.168.1.1/32.

Applicare il file:
```
./calicoctl apply -f gnp.yaml
```

Per ulteriori informazioni sulle opzioni del selettore in Calico, vedere EntityRule nella documentazione di Calico.

Controller di accettazione di sicurezza del pod (Anteprima tecnica)

Per gli spazi dei nomi all'interno di cluster che eseguono Kubernetes v1.23 e versioni successive, TKG supporta l'applicazione di criteri di sicurezza pod di tipo privileged, baseline o restricted tramite il controller di ammissione di sicurezza pod (PSA), come descritto in Standard di sicurezza pod nella documentazione di Kubernetes.

I criteri di sicurezza pod (PSP) per i nodi sono stati deprecati in TKG v2.1 perché sono stati deprecati anche in Kubernetes. Per informazioni su come eseguire la migrazione dei pod dai PSP al controller PSA, vedere Migrazione da PodSecurityPolicy al controller di ammissione PodSecurity integrato.

Per impostazione predefinita, le modalità di sicurezza pod del cluster Kubernetes v1.24 warn e audit sono impostate su baseline, che è un'impostazione che non forza l'applicazione. Ciò significa che la migrazione al controller PSA può generare avvisi relativi a pod che violano il criterio, ma i pod resteranno in esecuzione.