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.
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.
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 :
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.
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.
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 :
Obtenez les informations d'identification admin
du cluster. Par exemple :
tanzu cluster kubeconfig get my-cluster --admin
Définissez le contexte de kubectl
sur le cluster. Par exemple :
kubectl config use-context my-cluster-admin@my-cluster
Appliquez le fournisseur CNI au cluster :
kubectl apply -f PATH-TO-YOUR-CNI-CONFIGURATION/example.yaml
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.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 ouv1.25.7---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
.
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
.
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.
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 :
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 :
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 :
tz-overlay
.195.115.4.1/24
. Cette plage ne doit pas chevaucher les valeurs de profil DHCP Adresse IP du serveur (Server IP Address).Cliquez sur Enregistrer (Save) pour enregistrer le filtre.
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.
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 :
CLUSTER_CIDR
dans le fichier de configuration du cluster de charge de travail outanzu cluster create
à l'aide d'un paramètre CLUSTER_CIDR=
, comme indiqué à l'étape suivante.NSXT_POD_ROUTING_ENABLED
sur "true"
.NSXT_MANAGER_HOST
sur l'adresse IP de votre instance de NSX Manager.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/
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 :
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
.NSXT_VMC_AUTH_HOST
et NSXT_VMC_ACCESS_TOKEN
.NSXT_SECRET_NAMESPACE
, NSXT_SECRET_NAME
, NSXT_USERNAME
et NSXT_PASSWORD
.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...
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 :
kubectl config use-context CLUSTER-CONTEXT
pour modifier le contexte sur l'autre cluster.kubectl get nodes
pour récupérer l'adresse IP du nœud de plan de contrôle du cluster actuel.ssh capv@CONTROLPLANE-IP
à l'aide de l'adresse IP que vous venez de récupérer.ping
et envoyez des demandes curl
à l'adresse IP routable sur laquelle vous avez déployé le serveur Web et confirmez ses réponses.
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 :
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.
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/
.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é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
RemarqueDans le champ
cidr:
, entrez l'IP CIDR de vCenter Server, par exemple192.168.1.1/32
.
Appliquez le fichier :
kubectl apply -f antrea-policy-csi-cpi.yaml
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.
RemarqueSous les champs
notNets:
etnets:
, entrez l'IP CIDR de vCenter Server, par exemple192.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.
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.
Les stratégies de sécurité d'espace (PSP) pour les nœuds ont été déconseillées 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.