Mise en réseau d'espaces et de conteneurs

Cette rubrique décrit comment personnaliser la mise en réseau d'espace et de conteneur pour les clusters de charge de travail, notamment l'utilisation d'une interface réseau de cluster (CNI, Cluster Network Interface) autre qu'Antrea par défaut et la prise en charge d'adresses IP non NAT routables publiquement pour les clusters de charge de travail sur vSphere avec mise en réseau VMware NSX.

Créer un cluster avec un CNI non défini par défaut

Lorsque vous utilisez la CLI Tanzu pour déployer un cluster de charge de travail, une interface réseau de cluster (CNI) Antrea est automatiquement activée dans le cluster. Vous pouvez également activer une CNI Calico ou votre propre fournisseur de CNI.

Étant donné que les modules autogérés sont gérés par Tanzu Kubernetes Grid, vous n'avez généralement pas besoin de mettre à jour leurs configurations. Cependant, vous pouvez créer un cluster de charge de travail qui utilise une CNI personnalisée, telle que Calico. Les sections suivantes fournissent les étapes de configuration d'une CNI personnalisée telle que Calico.

CNI personnalisée pour les clusters déployés par le cluster de gestion autonome

Les clusters de charge de travail déployés par un cluster de gestion autonome avec une version de Tanzu Kubernetes Grid antérieure à la version 1.2.x, puis mis à niveau vers la version 1.3 continuent d'utiliser Calico comme fournisseur de CNI. Vous ne pouvez pas modifier le fournisseur CNI pour ces clusters.

Vous pouvez modifier la CNI par défaut pour un cluster de charge de travail que vous déployez à partir d'un cluster de gestion autonome en spécifiant la variable CNI dans le fichier de configuration. La variable CNI prend en charge les options suivantes :

(Par défaut) antrea : active Antrea.
calico : active Calico. Reportez-vous à la section CNI Calico. Cette option n'est pas prise en charge sous Windows.
none : Vous permet d’activer un fournisseur de CNI personnalisé. Pour plus d'informations, reportez-vous à la section CNI personnalisée.

Si vous ne définissez pas la variable CNI, Antrea est activé par défaut.

CNI Calico

Pour activer Calico dans un cluster de charge de travail, spécifiez les éléments suivants dans le fichier de configuration :

CNI: calico

Une fois le processus de création du cluster terminé, vous pouvez examiner le cluster comme décrit dans la section Se connecter aux clusters de charge de travail et les examiner.

CNI personnalisée

Pour activer un fournisseur de CNI personnalisé autre que Calico dans un cluster de charge de travail, procédez comme suit :

Spécifiez CNI: none dans le fichier de configuration lorsque vous créez le cluster. Par exemple :
```
CNI: none
```
Le processus de création du cluster échoue tant que vous n'appliquez pas une CNI au cluster. Vous pouvez surveiller le processus de création du cluster dans les journaux de l’API de cluster sur le cluster de gestion. Pour obtenir des instructions sur l'accès aux journaux de l'API du cluster, reportez-vous à la section Journaux et surveillance.
Une fois le cluster initialisé, appliquez votre fournisseur CNI au cluster :
1. Obtenez les informations d'identification admin du cluster. Par exemple :
```
tanzu cluster kubeconfig get my-cluster --admin
```
2. Définissez le contexte de kubectl sur le cluster. Par exemple :
```
kubectl config use-context my-cluster-admin@my-cluster
```
3. Appliquez le fournisseur CNI au cluster :
```
kubectl apply -f PATH-TO-YOUR-CNI-CONFIGURATION/example.yaml
```
Surveillez l'état du cluster à l'aide de la commande tanzu cluster list. Lorsque la création du cluster est terminée, l'état du cluster passe de creating à running. Pour plus d'informations sur l'examen de votre cluster, reportez-vous à la section Se connecter aux clusters de charge de travail et les examiner.

CNI Calico pour les clusters de charge de travail superviseurs ou basés sur une classe à nœud unique

Pour installer calico plutôt que antrea sur un cluster basé sur une classe déployé par un superviseur ou déployé en tant que cluster de charge de travail à nœud unique par un cluster de gestion autonome, vous devez d'abord personnaliser l'objet ClusterBootstrap du cluster comme suit :

Créez un fichier YAML qui contient les objets Kubernetes suivants :

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

Où :

CLUSTER-NAME est le nom du cluster de charge de travail que vous prévoyez de créer.
CLUSTER-NAMESPACE est l'espace de noms du cluster de charge de travail.
TKR-VERSION est la version de Tanzu Kubernetes (TKR) que vous prévoyez d'utiliser pour le cluster de charge de travail. Par exemple :
- v1.23.5+vmware.1-tkg.1 pour un cluster déployé par superviseur ou
- v1.24.10---vmware.1-tiny.1-tkg.1 pour un cluster à nœud unique, comme décrit dans la section Clusters à nœud unique sur vSphere (version d'évaluation technique)

Pour les clusters à nœud unique, supprimez le bloc spec.additionalPackages de la définition ClusterBootstrap. Les clusters à nœud unique ne disposent pas des modules metrics-server, secretgen-controller et pinniped supplémentaires.
Appliquez le fichier en exécutant la commande kubectl apply -f sur le cluster de gestion, qu'il s'agisse d'un superviseur ou d'un cluster de gestion autonome.

Créez un fichier YAML pour l'objet Cluster qui contient la configuration suivante :

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

Où :

CLUSTER-NAME est le nom du cluster de charge de travail que vous prévoyez de créer.
CLUSTER-NAMESPACE est l'espace de noms du cluster de charge de travail.
SERVICES-CIDR est le bloc CIDR des services. Par exemple, 198.51.100.0/12.
PODS-CIDR est le bloc CIDR des espaces. Par exemple, 192.0.2.0/16.
SERVICE-DOMAIN est le nom de domaine de service. Par exemple, cluster.local.
TKR-VERSION est la TKR que vous prévoyez d'utiliser pour le cluster de charge de travail. Par exemple, v1.23.5+vmware.1-tkg.1.
NODE-POOL-NAME est le nom du pool de nœuds pour machineDeployments.
VM-CLASS est le nom de la classe de machine virtuelle que vous souhaitez utiliser pour votre cluster. Par exemple, best-effort-small.
STORAGE-CLASS-NAME est le nom de la classe de stockage que vous souhaitez utiliser pour votre cluster. Par exemple, wcpglobal-storage-profile.

Par exemple :

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

Créez le cluster de charge de travail en transmettant le fichier définition d'objet Cluster que vous avez créé à l'étape ci-dessus à l'option -f de la commande tanzu cluster create.

CNI Calico pour les clusters basés sur TKC déployés par un superviseur

Pour installer calico au lieu d'antrea sur un cluster de charge de travail de type TanzuKubernetesCluster, définissez la variable de configuration CNI dans le fichier de configuration du cluster que vous prévoyez d'utiliser pour créer votre cluster de charge de travail, puis transmettez le fichier à l'option -f de la commande tanzu cluster create. Par exemple, CNI: calico.

Activer plusieurs fournisseurs de CNI

Pour activer plusieurs fournisseurs de CNI sur un cluster de charge de travail, tels que macvlan, ipvlan, SR-IOV ou DPDK, installez le module Multus sur un cluster qui exécute déjà la CNI Antrea ou Calico, puis créez des ressources NetworkAttachmentDefinition supplémentaires pour les CNI. Vous pouvez ensuite créer des espaces dans le cluster qui utilisent différentes interfaces réseau pour différentes plages d'adresses.

Pour obtenir des instructions, reportez-vous à la section Déployer Multus sur des clusters de charge de travail.

Déployer des espaces avec des adresses IP routables non NAT (NSX)

Sur vSphere avec la mise en réseau NSX et l'interface réseau de conteneur (CNI) Antrea, vous pouvez configurer un cluster de charge de travail avec des adresses IP routables pour ses espaces worker, en contournant la traduction d'adresses réseau (NAT) pour les demandes externes depuis et vers les espaces.

Les adresses IP routables sur les espaces vous permettent de :

Suivre les demandes sortantes vers les services partagés communs, car leur adresse IP source est l'adresse IP de l'espace routable, et non une adresse NAT.
Prendre en charge des demandes entrantes authentifiées depuis l'Internet externe directement vers les espaces, en contournant la NAT.

Configurer NSX pour les espaces d'adresses IP routables

Pour configurer NSX pour prendre en charge les adresses IP routables pour les espaces worker :

Accédez à votre serveur NSX et ouvrez l'onglet Mise en réseau (Networking).
Sous Connectivité (Connectivity) > Passerelles de niveau 1 (Tier-1 Gateways), cliquez sur Ajouter une passerelle de niveau 1 (Add Tier-1 Gateway) et configurez une nouvelle passerelle de niveau 1 dédiée aux espaces d'adresses IP routables :
- Nom (Name) : créez un nom pour votre passerelle T1 d'espaces routables.
- Passerelle liée de niveau 0 (Linked Tier-0 Gateway) : sélectionnez la passerelle de niveau 0 que les autres passerelles de niveau 1 pour Tanzu Kubernetes Grid utilisent.
- Cluster Edge (Edge Cluster) : sélectionnez un cluster Edge existant.
- Annonce de route (Route Advertisement) : activez Toutes les routes statiques (All Static Routes), Toutes les adresses IP NAT (All NAT IP’s) et Tous les ports de services et de segments connectés (All Connected Segments & Service Ports).
Cliquez sur Enregistrer (Save) pour enregistrer le filtre.
Sous Connectivité (Connectivity) > Segments, cliquez sur Ajouter un segment (Add Segment) et configurez un nouveau segment NSX, un commutateur logique, pour les nœuds de cluster de charge de travail contenant les espaces routables :
- Nom (Name) : créez un nom pour le segment de réseau pour les nœuds du cluster de charge de travail.
- Connectivité (Connectivity) : sélectionnez la passerelle de niveau 1 que vous venez de créer.
- Zone de transport (Transport Zone) : sélectionnez une zone de transport de superposition, telle que tz-overlay.
- Sous-réseaux (Subnets) : choisissez une plage d'adresses IP pour les nœuds de cluster, par exemple 195.115.4.1/24. Cette plage ne doit pas chevaucher les valeurs de profil DHCP Adresse IP du serveur (Server IP Address).
- Annonce de route (Route Advertisement) : activez Toutes les routes statiques (All Static Routes), Toutes les adresses IP NAT (All NAT IP’s) et Tous les ports de services et de segments connectés (All Connected Segments & Service Ports).
Cliquez sur Enregistrer (Save) pour enregistrer le filtre.

Espaces TKC déployés par un superviseur avec des adresses IP routables

Pour savoir comment déployer un cluster TKC avec des espaces worker disposant d'adresses IP routables non-NAT, reportez-vous à la section Exemple de v1beta1 : Cluster avec réseau d'espaces routables.

Espaces déployés par un cluster de gestion autonome avec des adresses IP routables

Pour utiliser un cluster de gestion autonome afin de déployer un cluster de charge de travail avec des espaces worker disposant d'adresses IP routables sans NAT, procédez comme suit. Le paramètre CLUSTER_CIDR du cluster configure la plage de ses adresses IP routables publiquement.

Créez un fichier de configuration de cluster de charge de travail comme décrit dans la section Créer un fichier de configuration de cluster de charge de travail et comme suit :
- Pour définir le bloc d'adresses IP routables attribuées à des espaces worker, vous pouvez :
  - définir CLUSTER_CIDR dans le fichier de configuration du cluster de charge de travail ou
  - ajouter votre commande tanzu cluster create à l'aide d'un paramètre CLUSTER_CIDR=, comme indiqué à l'étape suivante.
- Définissez NSXT_POD_ROUTING_ENABLED sur "true".
- Définissez NSXT_MANAGER_HOST sur l'adresse IP de votre instance de NSX Manager.
- Définissez NSXT_ROUTER_PATH sur le chemin d'inventaire de la passerelle de niveau 1 récemment ajoutée pour les adresses IP routables. Cette option est accessible à partir de NSX Manager > Connectivité (Connectivity) > Passerelles de niveau 1 (Tier-1 Gateways) en cliquant sur l'icône de menu () à gauche du nom de la passerelle et en cliquant sur Copier le chemin dans le Presse-papiers (Copy Path to Clipboard). Le nom commence par "/infra/tier-1s/
- Définissez d'autres variables de chaîne NSXT_ pour accéder à NSX en suivant le tableau Routage d'espace NSX de la Référence de variable du fichier de configuration. Les espaces peuvent s'authentifier avec NSX de l'une des quatre manières suivantes, en commençant pas l'option la plus sécurisée :
  - Certificat (Certificate) : Définissez NSXT_CLIENT_CERT_KEY_DATA, NSXT_CLIENT_CERT_KEY_DATA et, pour un certificat émis par une autorité de certification, NSXT_ROOT_CA_DATA_B64.
  - Jeton VMware Identity Manager sur VMware Cloud (VMC) : Définissez NSXT_VMC_AUTH_HOST et NSXT_VMC_ACCESS_TOKEN.
  - Nom d'utilisateur/Mot de passe (Username/password) stocké dans un secret Kubernetes : Définissez NSXT_SECRET_NAMESPACE, NSXT_SECRET_NAME, NSXT_USERNAME et NSXT_PASSWORD.
  - Nom d'utilisateur/Mot de passe (Username/password) en texte brut dans le fichier de configuration : Définissez NSXT_USERNAME et NSXT_PASSWORD.

Exécutez la commande tanzu cluster create comme décrit dans la section Créer des clusters de charge de travail. Par exemple :

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

Valider les adresses IP routables

Pour tester les adresses IP routables pour vos espaces de charge de travail :

Déployez un serveur Web sur le cluster de charge de travail routable.
Exécutez kubectl get pods --o wide pour récupérer les valeurs NAME, INTERNAL-IP et EXTERNAL-IP pour vos espaces routables, et vérifiez que les adresses IP répertoriées sont identiques et se trouvent dans la plage CLUSTER_CIDR routable.
Exécutez kubectl get nodes --o wide pour récupérer les valeurs NAME, INTERNAL-IP et EXTERNAL-IP pour les nœuds de cluster de charge de travail, qui contiennent les espaces d'adresses IP routables.
Connectez-vous à un autre nœud de plan de contrôle de cluster de charge de travail :
1. Exécutez kubectl config use-context CLUSTER-CONTEXT pour modifier le contexte sur l'autre cluster.
2. Exécutez kubectl get nodes pour récupérer l'adresse IP du nœud de plan de contrôle du cluster actuel.
3. Exécutez ssh capv@CONTROLPLANE-IP à l'aide de l'adresse IP que vous venez de récupérer.
4. Effectuez un test ping et envoyez des demandes curl à l'adresse IP routable sur laquelle vous avez déployé le serveur Web et confirmez ses réponses.
  - La sortie ping doit répertorier l'adresse IP de l'espace routable du serveur Web en tant qu'adresse source.
Dans un navigateur, connectez-vous à NSX et accédez à la passerelle de niveau 1 que vous avez créée pour les espaces d'adresses IP routables.
Cliquez sur Routes statiques (Static Routes) et vérifiez que les routes suivantes ont été créées dans la plage de CLUSTER_CIDR routable :
1. Route pour les espaces dans le nœud du plan de contrôle du cluster de charge de travail, avec Tronçons suivants (Next Hops) affiché en tant qu'adresse du nœud du plan de contrôle.
2. Route pour les espaces des nœuds worker du cluster de charge de travail, avec Tronçons suivants (Next Hops) affichés en tant qu'adresses des nœuds worker.

Supprimer les adresses IP routables

Après avoir supprimé un cluster de charge de travail qui contient des espaces d'adresses IP routables, vous devrez peut-être libérer les adresses IP routables en les supprimant du routeur de niveau 1 :

Dans NSX Manager, accédez à Connectivité (Connectivity) > Passerelles de niveau 1 (Tier-1 Gateways), puis sélectionnez votre passerelle d'adresse IP routable.
Sous Routes statiques (Static Routes), cliquez sur le nombre de routes pour ouvrir la liste.
Recherchez les routes qui incluent le nom du cluster supprimé et supprimez-les dans l'icône de menu () à gauche du nom de la route.
1. Si une erreur d'autorisations vous empêche de supprimer la route du menu, ce qui peut se produire si la route est créée par un certificat, supprimez la route via l'API :
  1. Dans le menu en regard du nom de la route, sélectionnez Copier le chemin dans le Presse-papiers (Copy Path to Clipboard).
  2. Exécutez 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 où :
    - NSXT_MANAGER_HOST, NSXT_USERNAME et NSXT_PASSWORD correspondent à l'adresse IP et aux informations d'identification de NSX Manager.
    - STATIC_ROUTE_PATH est le chemin que vous venez de copier dans le Presse-papiers. Le nom commence par /infra/tier-1s/ et inclut /static-routes/.

Définir des stratégies réseau pour les CNI

Pour empêcher un cluster de charge de travail d'accéder à l'interface de gestion de VMware vCenter Server, définissez des stratégies réseau appropriées sur les CNI Antrea et Calico. Lorsque vous configurez ces stratégies, seul le trafic provenant du réseau de conteneur est filtré. Les stratégies bloquent le trafic provenant de tous les espaces, à l'exception de ceux de l'interface de stockage de conteneur (CSI) et de l'interface du fournisseur de cloud.

Définir les stratégies réseau du cluster pour Antrea

Définissez les stratégies réseau du cluster pour Antrea via le fichier antrea-policy-csi-cpi.yaml dans le cluster de charge de travail. Pour ce faire :

Dans la CLI Tanzu, basculez vers le contexte du cluster de charge de travail :
```
kubectl config use-context WORKLOAD-CLUSTER-CONTEXT
```

Créez le fichier antrea-policy-csi-cpi.yaml, comme indiqué dans l'exemple suivant :

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

Remarque
Dans le champ cidr:, entrez l'IP CIDR de vCenter Server, par exemple 192.168.1.1/32.

Appliquez le fichier :

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

Définir des stratégies réseau pour Calico

Définissez les stratégies réseau du cluster pour Calico via le fichier gnp.yaml dans le cluster de charge de travail. Pour ce faire :

Téléchargez le fichier binaire de l'utilitaire calicoctl qui correspond à votre système d'exploitation à partir du site Github.

Installez l'utilitaire sur votre système. Par exemple, pour télécharger et installer l'utilitaire sur un système Linux :

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

Dans la CLI Tanzu, basculez vers le contexte du cluster de charge de travail :
```
kubectl config use-context WORKLOAD-CLUSTER-CONTEXT
```

Créez le fichier gnp.yaml, comme indiqué dans l'exemple suivant :

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.

Remarque
Sous les champs notNets: et nets:, entrez l'IP CIDR de vCenter Server, par exemple 192.168.1.1/32.

Appliquez le fichier :
```
./calicoctl apply -f gnp.yaml
```

Pour en savoir plus sur les options de sélection dans Calico, reportez-vous à la section EntityRule dans la documentation de Calico.

Contrôleur d'admission de sécurité de l'espace (version d'évaluation technique)

Pour les espaces de noms dans les clusters exécutant Kubernetes v1.23 et versions ultérieures, TKG prend en charge l'application de stratégies de sécurité de l'espace de type privileged, baseline ou restricted via le contrôleur d'admission de sécurité de l'espace (PSA), comme décrit dans la section Normes de sécurité d'espace de la documentation Kubernetes.

Remarque
Cette fonctionnalité est dans l'état Version d'évaluation technique non pris en charge. Reportez-vous à la section États des fonctionnalités TKG.

Les stratégies de sécurité d'espace (PSP) pour les nœuds sont obsolètes dans TKG v2.1, afin de refléter leur obsolescence dans Kubernetes. Pour savoir comment migrer des PSP vers le contrôleur PSA, reportez-vous à la section Migrer depuis PodSecurityPolicy vers le contrôleur d'admission PodSecurity intégré.

Par défaut, les espaces de noms de cluster Kubernetes v1.24 disposent de modes warn et audit définis sur baseline, ce qui est un paramètre non appliqué. Cela signifie que la migration vers le contrôleur PSA peut générer des avertissements à propos d'espaces enfreignant la stratégie, mais les espaces continueront à s'exécuter.

Certains modules et composants TKG ne sont pas conformes au mode baseline. Il s'agit d'un problème connu. Pour ces modules, la solution la plus rapide consiste à définir les étiquettes audit=privileged et warn=privileged dans les espaces de noms affectés pour supprimer les messages d'audit et les avertissements de violation :

kubectl label --overwrite ns NAMESPACE pod-security.kubernetes.io/audit=privileged
kubectl label --overwrite ns NAMESPACE pod-security.kubernetes.io/warn=privileged

Où NAMESPACE est l'espace de noms pour tout module installé ou autre composant répertorié ci-dessous :

Espace de noms	Module ou composant
`avi-system`	AKO (`load-balancer-and-ingress-service`)
`cert-manager`	Gestionnaire de certificats
`pinniped-concierge`	Pinniped
`sonobuoy`	Sonobuoy
`tanzu-auth`	Service d'authentification (pour le cluster de gestion autonome)
`tanzu-system-ingress`	Contour, Envoy
`tanzu-system-logging`	Fluent Bit
`tanzu-system-monitoring`	Prometheus
`velero`	Restic, Velero
`vmware-system-auth`	Service d'authentification (pour superviseur)

Ces espaces de noms contiennent les composants du module, distincts des espaces de noms choisis par l'utilisateur ou default, dans lesquels les modules eux-mêmes sont installés.