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.
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.
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:
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.
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.
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:
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.
Después de inicializar el clúster, aplique el proveedor de CNI al clúster:
Obtenga las credenciales admin
del clúster. Por ejemplo:
tanzu cluster kubeconfig get my-cluster --admin
Establezca el contexto de kubectl
en el clúster. Por ejemplo:
kubectl config use-context my-cluster-admin@my-cluster
Aplique el proveedor de CNI al clúster:
kubectl apply -f PATH-TO-YOUR-CNI-CONFIGURATION/example.yaml
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.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:
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 ov1.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)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
.
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.
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
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
.
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
.
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.
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:
Para configurar NSX que admitan direcciones IP enrutables para pods de trabajo:
Desplácese hasta el servidor NSX y abra la pestaña Redes (Networking).
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:
Haga clic en Guardar (Save) para guardar el filtro.
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:
tz-overlay
.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.Haga clic en Guardar (Save) para guardar el filtro.
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.
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.
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:
CLUSTER_CIDR
en el archivo de configuración del clúster de carga de trabajo otanzu cluster create
con una configuración CLUSTER_CIDR=
, como se muestra en el siguiente paso.NSXT_POD_ROUTING_ENABLED
en "true"
.NSXT_MANAGER_HOST
en la dirección IP de NSX Manager.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/
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:
NSXT_ROOT_CA_DATA_B64
NSXT_CLIENT_CERT_KEY_DATA
, NSXT_CLIENT_CERT_KEY_DATA
y para un certificado emitido por una CA.NSXT_VMC_AUTH_HOST
y NSXT_VMC_ACCESS_TOKEN
.NSXT_SECRET_NAMESPACE
, NSXT_SECRET_NAME
, NSXT_USERNAME
y NSXT_PASSWORD
.NSXT_USERNAME
y NSXT_PASSWORD
.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...
Para probar las direcciones IP enrutables para los pods de carga de trabajo:
Implemente un servidor web en el clúster de carga de trabajo enrutable.
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.
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.
Inicie sesión en otro nodo del plano de control del clúster de carga de trabajo:
kubectl config use-context CLUSTER-CONTEXT
para cambiar el contexto a otro clúster.kubectl get nodes
para recuperar la dirección IP del nodo del plano de control del clúster actual.ssh capv@CONTROLPLANE-IP
con la dirección IP que acaba de recuperar.ping
y envíe solicitudes curl
a la dirección IP enrutable en la que implementó el servidor web y confirme sus respuestas.
ping
deben mostrar la dirección IP del pod enrutable del servidor web como la dirección de origen.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.
Haga clic en Rutas estáticas (Static Routes) y confirme que las siguientes rutas se crearon dentro del rango de CLUSTER_CIDR
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:
En NSX Manager > Conectividad (Connectivity) > Puertas de enlace de nivel 1 (Tier-1 Gateways), seleccione la puerta de enlace enrutable-IP.
En Rutas estáticas (Static Routes), haga clic en el número de rutas para abrir la lista.
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.
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 ManagerSTATIC_ROUTE_PATH
es la ruta que acaba de copiar en el portapapeles. El nombre comienza con /infra/tier-1s/
e incluye /static-routes/
.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).
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:
En la CLI de Tanzu, cambie al contexto del clúster de carga de trabajo:
kubectl config use-context WORKLOAD-CLUSTER-CONTEXT
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
NotaEn el campo
cidr:
, introduzca el CIDR de IP de vCenter Server, por ejemplo,192.168.1.1/32
.
Aplique el archivo:
kubectl apply -f antrea-policy-csi-cpi.yaml
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:
Descargue el archivo binario de la utilidad calicoctl
para su sistema operativo desde la ubicación de Github.
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
En la CLI de Tanzu, cambie al contexto del clúster de carga de trabajo:
kubectl config use-context WORKLOAD-CLUSTER-CONTEXT
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.
NotaEn los campos
notNets:
ynets:
, introduzca el CIDR de IP de vCenter Server, por ejemplo,192.168.1.1/32
."
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.
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.
NotaEsta 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.