Redes de contenedor y pod

En este tema se describe cómo personalizar las redes de pods y contenedores para clústeres de carga de trabajo, incluido el uso de una interfaz de red de clústeres (CNI) distinta a la predeterminada Antrea y admitir direcciones IP sin NAT y enrutables públicamente para clústeres de carga de trabajo en vSphere con redes VMware NSX.

Crear un clúster con una CNI no predeterminada

Cuando se utiliza la CLI de Tanzu para implementar un clúster de carga de trabajo; se habilita automáticamente una interfaz de red (CNI) del clúster de Antrea en el clúster. De forma alternativa, puede habilitar una CNI de Calico o su propio proveedor de CNI.

Puesto que los paquetes administrados automáticamente se administran mediante Tanzu Kubernetes Grid, por lo general no es necesario actualizar sus configuraciones. Sin embargo, es posible que desee crear un clúster de carga de trabajo que utilice una CNI personalizada, como Calico. En las siguientes secciones, se proporcionan los pasos para configurar una CNI personalizada, como Calico.

CNI personalizada para clústeres implementados en el clúster de administración independiente

Los clústeres de carga de trabajo implementados por un clúster de administración independiente con una versión de Tanzu Kubernetes Grid anterior a la 1.2.x y, a continuación, actualizados a la versión 1.3, siguen utilizando Calico como proveedor de CNI. No se puede cambiar el proveedor de CNI para estos clústeres.

Puede cambiar la CNI predeterminada de un clúster de carga de trabajo que va a implementar desde un clúster de administración independiente especificando la variable CNI en el archivo de configuración. La variable de CNI admite las siguientes opciones:

• (predeterminado) antrea: Habilita Antrea.
• calico: Habilita Calico. Consulte CNI de Calico. Esta opción no se admite en Windows.
• none: Permite habilitar un proveedor de CNI personalizada. Consulte CNI personalizada.

Si no establece la variable CNI, de forma predeterminada se habilita Antrea.

CNI de Calico

Para habilitar Calico en un clúster de carga de trabajo, especifique lo siguiente en el archivo de configuración:

CNI: calico

Una vez completado el proceso de creación del clúster, puede examinar el clúster como se describe en Conectar y examinar los clústeres de carga de trabajo.

CNI personalizada

Para habilitar un proveedor de CNI personalizado que no sea Calico en un clúster de carga de trabajo, siga los pasos que se indican a continuación:

1. Especifique CNI: none en el archivo de configuración cuando cree el clúster. Por ejemplo:

   CNI: none
   

   El proceso de creación del clúster no se realizará correctamente hasta que se aplique una CNI al clúster. Puede supervisar el proceso de creación del clúster en los registros de la API del clúster en el clúster de administración. Para obtener instrucciones sobre cómo acceder a los registros de la API del clúster, consulte Registros y supervisión.

2. Después de inicializar el clúster, aplique el proveedor de CNI al clúster:

   1. Obtenga las credenciales admin del clúster. Por ejemplo:

      tanzu cluster kubeconfig get my-cluster --admin
      

   2. Establezca el contexto de kubectl en el clúster. Por ejemplo:

      kubectl config use-context my-cluster-admin@my-cluster
      

   3. Aplique el proveedor de CNI al clúster:

      kubectl apply -f PATH-TO-YOUR-CNI-CONFIGURATION/example.yaml
      

3. Supervise el estado del clúster mediante el comando tanzu cluster list. Cuando se completa la creación del clúster, el estado del clúster cambia de creating a running. Para obtener más información sobre cómo examinar el clúster, consulte Conectar y examinar los clústeres de carga de trabajo.

CNI de Calico para clústeres de carga de trabajo basados en clases de nodo único o supervisor

Para instalar calico en lugar de antrea en un clúster basado en clases implementado por un supervisor o implementado como un clúster de carga de trabajo de nodo único por un clúster de administración independiente, primero debe personalizar el objeto ClusterBootstrap del clúster de la siguiente manera:

1. Cree un archivo YAML que contenga los siguientes objetos Kubernetes:

   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
   

   Donde:

   • CLUSTER-NAME es el nombre del clúster de carga de trabajo que desea crear.
   • CLUSTER-NAMESPACE es el espacio de nombres del clúster de carga de trabajo.

   • TKR-VERSION es la versión de Tanzu Kubernetes (TKr) que desea utilizar para el clúster de carga de trabajo. Por ejemplo:

     • v1.23.5+vmware.1-tkg.1 para un clúster implementado por supervisor o
     • v1.24.10---vmware.1-tiny.1-tkg.1 para un clúster de nodo único como se describe en Clústeres de nodo único en vSphere (vista previa técnica)

2. Para los clústeres de nodo único, elimine el bloque spec.additionalPackages de la definición de ClusterBootstrap. Los clústeres de nodo único no tienen los paquetes adicionales metrics-server, secretgen-controller y pinniped.

3. Aplique el archivo ejecutando el comando kubectl apply -f en el clúster de administración, ya sea supervisor o un clúster de administración independiente.

4. Cree un archivo YAML para el objeto Cluster que contenga la siguiente configuración:

   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
   

   Donde:

   • CLUSTER-NAME es el nombre del clúster de carga de trabajo que desea crear.
   • CLUSTER-NAMESPACE es el espacio de nombres del clúster de carga de trabajo.
   • SERVICES-CIDR es el bloque CIDR para los servicios. Por ejemplo, 198.51.100.0/12.
   • PODS-CIDR es el bloque CIDR para los pods. Por ejemplo, 192.0.2.0/16.
   • SERVICE-DOMAIN es el nombre de dominio del servicio. Por ejemplo, cluster.local.
   • TKR-VERSION es la versión del TKr que desea utilizar para el clúster de carga de trabajo. Por ejemplo, v1.23.5+vmware.1-tkg.1.
   • NODE-POOL-NAME es el nombre del grupo de nodos de machineDeployments.
   • VM-CLASS es el nombre de la clase de máquina virtual que desea utilizar para el clúster. Por ejemplo, best-effort-small.
   • STORAGE-CLASS-NAME es el nombre de la clase de almacenamiento que desea utilizar para el clúster. Por ejemplo, wcpglobal-storage-profile.

   Por ejemplo:

   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
   

5. Cree el clúster de carga de trabajo pasando el archivo de definición del objeto Cluster que creó en el paso anterior a la opción -f del comando tanzu cluster create.

CNI de Calico para clústeres basados en TKC implementados por supervisor

Para instalar calico en lugar de antrea en un clúster de carga de trabajo implementado por el supervisor del tipo TanzuKubernetesCluster, configure la variable de CNI en el archivo de configuración del clúster que planea usar para crear su clúster de carga de trabajo y luego pase el archivo a la opción -f del comando tanzu cluster create. Por ejemplo, CNI: calico.

Habilitar varios proveedores de CNI

Para habilitar varios proveedores de CNI en un clúster de carga de trabajo, como macvlan, ipvlan, SR-IOV o DPDK, instale el paquete Multus en un clúster que ya ejecute Antrea o Calico CNI y cree recursos NetworkAttachmentDefinition adicionales para CNI. A continuación, puede crear nuevos pods en el clúster que utilicen diferentes interfaces de red para diferentes rangos de direcciones.

Para obtener instrucciones, consulte Implementar Multus en clústeres de carga de trabajo.

Implementar pods con direcciones IP enrutables y sin NAT (NSX)

En vSphere con redes de NSX y la interfaz de red de contenedor Antrea (Container Network Interface, CNI), puede configurar clústeres de carga de trabajo con direcciones IP enrutables para sus pods de trabajo, omitiendo la traducción de direcciones de red (NETWORK Address Translation, NAT) para las solicitudes externas de y a los pods.

Las direcciones IP enrutables en los pods permiten:

• Rastrear solicitudes salientes a servicios compartidos comunes, ya que su dirección IP de origen es la dirección IP del pod enrutable, no una dirección NAT.
• Compatibilidad con solicitudes entrantes autenticadas desde la red Internet externa directamente a los pods, omitiendo NAT.

Configurar NSX para pods de IP enrutables

Para configurar NSX que admitan direcciones IP enrutables para pods de trabajo:

1. Desplácese hasta el servidor NSX y abra la pestaña Redes (Networking).

2. En Conectividad (Connectivity) > Puertas de enlace de nivel 1(Tier-1 Gateways), haga clic en Agregar puerta de enlace de nivel 1 y configure una nueva puerta de enlace de nivel 1 dedicada a pods de IP enrutables:

   • Nombre (Name): Cree un nombre para la puerta de enlace T1 de los pods enrutables.
   • Puerta de enlace de nivel 0 (Linked Tier-0 Gateway): Seleccione la puerta de enlace de nivel 0 que utilizarán las otras puertas de enlace de nivel 1 para Tanzu Kubernetes Grid.
   • Clúster de Edge (Edge Cluster): Seleccione un clúster de Edge existente.
   • Anuncio de rutas (Route Advertisement): Habilite Todas las rutas estáticas (All Static Routes), Todos las IP de NAT (All NAT IP’s) y Todos los segmentos conectados y puertos de servicio (All Connected Segments & Service Ports).

   Haga clic en Guardar (Save) para guardar el filtro.

3. En Conectividad (Connectivity) > Segmentos (Segments), haga clic en Agregar segmento (Add Segment) y configure un nuevo segmento de NSX, un conmutador lógico, para los nodos del clúster de carga de trabajo que contengan los pods enrutables:

   • Nombre (Name): Configure un nombre para el segmento de red de los nodos del clúster de carga de trabajo.
   • Conectividad (Connectivity): Seleccione la puerta de enlace de nivel 1 que acaba de crear.
   • Zona de transporte (Transport Zone): Seleccione una zona de transporte superpuesta, como tz-overlay.
   • Subredes (Subnets): Elija un rango de direcciones IP para los nodos del clúster, como 195.115.4.1/24. Este rango no debe superponerse con los valores de Dirección IP del servidor (Server IP Address) del perfil de DHCP.
   • Anuncio de rutas (Route Advertisement): Habilite Todas las rutas estáticas (All Static Routes), Todos las IP de NAT (All NAT IP’s) y Todos los segmentos conectados y puertos de servicio (All Connected Segments & Service Ports).

   Haga clic en Guardar (Save) para guardar el filtro.

Pods de TKC implementados por el supervisor con direcciones IP enrutables

Para obtener información sobre cómo implementar un clúster de TKC con pods de trabajo que tienen direcciones IP enrutables sin NAT, consulte Ejemplo v1beta1. Clúster con red de pods enrutables.

Pods implementados en el clúster de administración independiente con direcciones IP enrutables

Si desea utilizar un clúster de administración independiente para implementar un clúster de carga de trabajo con pods de trabajo que tengan direcciones IP enrutables sin NAT, haga lo siguiente. La opción CLUSTER_CIDR del clúster configura el rango de sus direcciones IP enrutables públicamente.

1. Cree un archivo de configuración de clúster de carga de trabajo como se describe en Crear un archivo de configuración de clúster de carga de trabajo y de la siguiente manera:

   • Para establecer el bloque de direcciones IP enrutables asignadas a los pods de trabajo, puede:
     • Establezca CLUSTER_CIDR en el archivo de configuración del clúster de carga de trabajo o
     • Anteponga el comando tanzu cluster create con una configuración CLUSTER_CIDR=, como se muestra en el siguiente paso.
   • Establezca NSXT_POD_ROUTING_ENABLED en "true".
   • Establezca NSXT_MANAGER_HOST en la dirección IP de NSX Manager.
   • Establezca NSXT_ROUTER_PATH en la ruta de inventario de la puerta de enlace de nivel 1 recién agregada para las direcciones IP enrutables. Obtenga esto de NSX Manager > Conectividad (Connectivity) > Puertas de enlace de nivel 1 (Tier-1 Gateways) haciendo clic en el icono de menú () a la izquierda del nombre de la puerta de enlace y haciendo clic en Copiar ruta de acceso al portapapeles (Copy Path to Clipboard). El nombre comienza con "/infra/tier-1s/
   • Establezca otras variables de cadena NSXT_ para acceder a NSX siguiendo la tabla Enrutamiento de pods de NSX de la Referencia de variable de archivo de la configuración. Los pods pueden autenticarse con NSX de una de estas cuatro formas, con la lista menos segura en último lugar:
     • Certificado (Certificate): Establezca NSXT_ROOT_CA_DATA_B64 NSXT_CLIENT_CERT_KEY_DATA, NSXT_CLIENT_CERT_KEY_DATA y para un certificado emitido por una CA.
     • Token VMware Identity Manager en VMware Cloud (VMC): Establezca NSXT_VMC_AUTH_HOST y NSXT_VMC_ACCESS_TOKEN.
     • Nombre de usuario/contraseña (Username/password) almacenados en un secreto de Kubernetes: Establezca NSXT_SECRET_NAMESPACE, NSXT_SECRET_NAME, NSXT_USERNAME y NSXT_PASSWORD.
     • Nombre de usuario/contraseña (Username/password) como texto sin formato en el archivo de configuración: Establezca NSXT_USERNAME y NSXT_PASSWORD.

2. Ejecute tanzu cluster create como se describe en Crear clústeres de carga de trabajo. Por ejemplo:

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

Validar direcciones IP enrutables

Para probar las direcciones IP enrutables para los pods de carga de trabajo:

1. Implemente un servidor web en el clúster de carga de trabajo enrutable.

2. Ejecute kubectl get pods --o wide para recuperar los valores de NAME, INTERNAL-IP y EXTERNAL-IP para los pods enrutables, y compruebe que las direcciones IP enumeradas sean idénticas y estén dentro del rango de CLUSTER_CIDR enrutables.

3. Ejecute kubectl get nodes --o wide para recuperar NAME, INTERNAL-IP y EXTERNAL-IP para los nodos del clúster de carga de trabajo, que contienen los pods de IP enrutables.

4. Inicie sesión en otro nodo del plano de control del clúster de carga de trabajo:

   1. Ejecute kubectl config use-context CLUSTER-CONTEXT para cambiar el contexto a otro clúster.
   2. Ejecute kubectl get nodes para recuperar la dirección IP del nodo del plano de control del clúster actual.
   3. Ejecute ssh capv@CONTROLPLANE-IP con la dirección IP que acaba de recuperar.
   4. ping y envíe solicitudes curl a la dirección IP enrutable en la que implementó el servidor web y confirme sus respuestas.
      • Los resultados ping deben mostrar la dirección IP del pod enrutable del servidor web como la dirección de origen.

5. Desde un navegador, inicie sesión en NSX y desplácese hasta la puerta de enlace de nivel 1 que creó para los pods de IP enrutables.

6. Haga clic en Rutas estáticas (Static Routes) y confirme que las siguientes rutas se crearon dentro del rango de CLUSTER_CIDR enrutables:

   1. Una ruta para los pods en el nodo de plano de control del clúster de carga de trabajo, con Próximos saltos (Next Hops) que se muestran como la dirección del propio nodo del plano de control.
   2. Una ruta para los pods de los nodos de trabajo del clúster de carga de trabajo, con Próximos saltos (Next Hops) que se muestran como las direcciones de los propios nodos de trabajo.

Eliminar direcciones IP enrutables

Después de eliminar un clúster de carga de trabajo que contiene pods de IP enrutables, es posible que deba liberar las direcciones IP enrutables eliminándolas del enrutador T1:

1. En NSX Manager > Conectividad (Connectivity) > Puertas de enlace de nivel 1 (Tier-1 Gateways), seleccione la puerta de enlace enrutable-IP.

2. En Rutas estáticas (Static Routes), haga clic en el número de rutas para abrir la lista.

3. Busque rutas que incluyan el nombre del clúster eliminado y elimínelas en el icono de menú () a la izquierda del nombre de la ruta.

   1. Si un error de permisos le impide eliminar la ruta del menú, lo que puede suceder si la ruta se crea mediante un certificado, elimine la ruta a través de la API:
      1. En el menú junto al nombre de la ruta, seleccione Copiar ruta de acceso al portapapeles (Copy Path to Clipboard).
      2. Ejecute 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 donde:
         • NSXT_MANAGER_HOST, NSXT_USERNAME y NSXT_PASSWORD son las credenciales y la dirección IP de NSX Manager
         • STATIC_ROUTE_PATH es la ruta que acaba de copiar en el portapapeles. El nombre comienza con /infra/tier-1s/ e incluye /static-routes/.

Establecer directivas de red para las CNI

Para restringir el acceso de un clúster de carga de trabajo a la interfaz de administración de VMware vCenter Server, establezca las directivas de red adecuadas en las CNI de Antrea y Calico. Cuando se configuran estas directivas. solo se filtra el tráfico que se origina en la red de contenedor. Las directivas bloquean el tráfico que se origina en todos los pods, excepto en los pods de la interfaz de almacenamiento de contenedores (CSI) y la interfaz del proveedor de nube (CPI).

Establecer directivas de red de clústeres para Antrea

Establezca las directivas de red de clústeres para Antrea a través del archivo antrea-policy-csi-cpi.yaml en el clúster de carga de trabajo. Para ello:

1. En la CLI de Tanzu, cambie al contexto del clúster de carga de trabajo:

   kubectl config use-context WORKLOAD-CLUSTER-CONTEXT
   

2. Cree el archivo antrea-policy-csi-cpi.yaml, como se muestra en el siguiente ejemplo:

   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

   En el campo cidr:, introduzca el CIDR de IP de vCenter Server, por ejemplo, 192.168.1.1/32.

3. Aplique el archivo:

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

Establecer directivas de red para Calico

Establezca las directivas de red de clúster para Calico a través del archivo gnp.yaml en el clúster de carga de trabajo. Para ello:

1. Descargue el archivo binario de la utilidad calicoctl para su sistema operativo desde la ubicación de Github.

2. Instale la utilidad en su sistema. Por ejemplo, para descargar e instalar la utilidad en un sistema Linux:

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

3. En la CLI de Tanzu, cambie al contexto del clúster de carga de trabajo:

   kubectl config use-context WORKLOAD-CLUSTER-CONTEXT
   

4. Cree el archivo gnp.yaml, como se muestra en el siguiente ejemplo:

   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

   En los campos notNets: y nets:, introduzca el CIDR de IP de vCenter Server, por ejemplo, 192.168.1.1/32."

5. Aplique el archivo:

   ./calicoctl apply -f gnp.yaml
   
   

Para obtener más información sobre las opciones de selector de Calico, consulte EntityRule en la documentación de Calico.

Controlador de admisión de seguridad de pods (vista previa técnica)

Para los espacios de nombres dentro de clústeres que ejecutan Kubernetes v1.23 y versiones posteriores, TKG admite la aplicación de directivas de seguridad de pods de tipo privileged, baseline o restricted a través del controlador de admisión de seguridad de pods (PSA), como se describe en los Estándares de seguridad de pods en la documentación de Kubernetes.

Nota

Esta función se encuentra en el estado de vista previa técnica no compatible; consulte Estados de funciones de TKG.

Las directivas de seguridad de pods (PSP) para los nodos están obsoletas en TKG v2.1, para reflejar su desuso en Kubernetes. Para obtener información sobre cómo migrar pods de PSP al controlador PSA, consulte Migrar de PodSecurityPolicy al controlador de admisión de PodSecurity integrado.

De forma predeterminada, los espacios de nombres del clúster de Kubernetes v1.24 tienen los modos de seguridad de pods warn y audit establecidos en baseline, que es un ajuste sin aplicación. Esto significa que la migración al controlador PSA puede generar advertencias sobre los pods que infringen la directiva, pero los pods seguirán ejecutándose.

Es un problema conocido que algunos componentes y paquetes de TKG no cumplen con el modo baseline; para estos, la solución alternativa más rápida es establecer las etiquetas audit=privileged y warn=privileged en los espacios de nombres afectados para suprimir advertencias y mensajes de auditoría de infracción:

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

Donde NAMESPACE es el espacio de nombres de cualquier paquete instalado u otros componentes que se enumeran a continuación:

Espacio de nombres	Paquete o componente
avi-system	AKO (load-balancer-and-ingress-service)
cert-manager	Administrador de certificados
pinniped-concierge	Pinniped
sonobuoy	Sonobuoy
tanzu-auth	Servicio de autenticación (para clúster de administración independiente)
tanzu-system-ingress	Contour, Envoy
tanzu-system-logging	Fluent Bit
tanzu-system-monitoring	Prometheus
velero	Restic, Velero
vmware-system-auth	Servicio de autenticación (para supervisor)

Estos espacios de nombres contienen los componentes del paquete, a diferencia de los espacios de nombres seleccionados por el usuario o default, donde están instalados los propios paquetes.