Tanzu Kubernetes Grid vous permet d'effectuer diverses opérations de gestion sur votre déploiement NSX Advanced Load Balancer (ALB).
Le certificat du contrôleur Avi expire périodiquement. Dans Tanzu Kubernetes Grid, vous pouvez mettre à jour le certificat du contrôleur Avi lorsqu'il expire. Avant de mettre à jour le certificat dans les clusters, assurez-vous qu'il existe dans le contrôleur Avi.
Pour mettre à jour le certificat du contrôleur Avi :
Dans la CLI Tanzu, exécutez la commande suivante :
kubectl patch secret/avi-controller-ca --context <CLUSTER-CONTEXT> -n tkg-system-networking -p '{"data": {"certificateAuthorityData": "<ca-data>"}}' <"CERTIFICATE-STRING">
Pour mettre à jour les informations d'identification du contrôleur Avi :
Recodez les informations d'identification dans une chaîne codée en base64.
Dans la CLI Tanzu, exécutez la commande suivante :
kubectl edit secret avi-controller-credentials -n tkg-system-networking
Dans votre éditeur de texte par défaut qui s'affiche, mettez à jour les informations d'identification avec les nouvelles informations d'identification codées en base64.
AKODeploymentConfig d'un clusterPour savoir quel objet CR AKODeploymentConfig est utilisé sur le cluster actuel, exécutez la commande suivante sur la CLI Tanzu :
kubectl --context={management cluster kubeconfig context} get cluster --show-labels
Dans la sortie, examinez le champ networking.tkg.tanzu.vmware.com/avi=<AKODeploymentConfig-NAME> pour afficher l'objet AKODeploymentConfig qui a été sélectionné par le cluster.
Dans Tanzu Kubernetes Grid, vous pouvez modifier le fournisseur de haute disponibilité (HA) du plan de contrôle d'un cluster de Kube-VIP à NSX Advanced Load Balancer. Le fournisseur HA du plan de contrôle doit être le même dans un cluster de gestion et dans ses clusters de charge de travail. Si un cluster de gestion a NSX Advanced Load Balancer comme fournisseur HA de plan de contrôle, les nouveaux clusters de charge de travail qu'il crée auront automatiquement le même fournisseur HA.
Vérifiez que :
Ajoutez l'adresse IP virtuelle du plan de contrôle au pool d'adresses IP statiques Avi :
Dans la CLI Tanzu, définissez le contexte de kubectl sur votre cluster de gestion :
kubectl config use-context MY-MGMT-CLUSTER-admin@MY-MGMT-CLUSTER
Où MY-MGMT-CLUSTER est le nom de votre cluster de gestion.
Vérifiez que le cluster dispose d'une annotation de point de terminaison de plan de contrôle :
kubectl annotate --overwrite cluster CLUSTER-NAME -n CLUSTER-NAMESPACE tkg.tanzu.vmware.com/cluster-controlplane-endpoint="VIP"
Où :
CLUSTER-NAME est le nom du cluster.CLUSTER-NAMESPACE est l'espace de noms que vous utilisez pour le cluster.VIP correspond à l'adresse IP virtuelle du point de terminaison du plan de contrôle.(Clusters de gestion uniquement) Dans le secret de l'opérateur AKO, définissez Avi comme fournisseur HA du plan de contrôle :
Récupérez la chaîne de valeurs de configuration à partir du secret de l'opérateur AKO, décodez-le et videz-le dans un fichier YAML :
kubectl get secret CLUSTER_NAME-ako-operator-addon -n tkg-system --template="{{index .data \"values.yaml\" | base64decode}}" > values.yaml
Modifiez le fichier de valeurs de configuration pour définir avi_control_plane_ha_provider sur true :
yq e -i '.akoOperator.config.avi_control_plane_ha_provider=true' values.yaml
Vous trouverez ci-dessous un exemple de fichier modifié de valeurs de configuration :
#@data/values
#@overlay/match-child-defaults missing_ok=True
---
akoOperator:
avi_enable: true
namespace: tkg-system-networking
cluster_name: ha-mc-1
config:
avi_disable_ingress_class: true
avi_ingress_default_ingress_controller: false
avi_ingress_shard_vs_size: ""
avi_ingress_service_type: ""
avi_ingress_node_network_list: '""'
avi_admin_credential_name: avi-controller-credentials
avi_ca_name: avi-controller-ca
avi_controller: 10.161.107.63
avi_username: admin
avi_password: Admin!23
avi_cloud_name: Default-Cloud
avi_service_engine_group: Default-Group
avi_data_network: VM Network
avi_data_network_cidr: 10.161.96.0/19
avi_ca_data_b64: LS0tLS1CRUd[...]BVEUtLS0tLQ==
avi_labels: '""'
avi_disable_static_route_sync: true
avi_cni_plugin: antrea
avi_management_cluster_vip_network_name: VM Network
avi_management_cluster_vip_network_cidr: 10.161.96.0/19
avi_control_plane_endpoint_port: 6443
avi_control_plane_ha_provider: true
```
Recodez le fichier de valeurs de configuration dans une chaîne codée en base64 :
cat values.yaml | base64
Enregistrez la chaîne codée en base64 à partir de la sortie de la commande.
Ouvrez la spécification du secret de l'opérateur AKO dans un éditeur :
kubectl edit secret CLUSTER NAME-ako-operator-addon -n tkg-system
Remplacez le champ data.values.yaml par la nouvelle chaîne de valeurs de configuration codée en base64 que vous avez enregistrée. Enregistrez le fichier.
Avant de continuer, confirmez les deux éléments suivants :
LoadBalancer et avec un nom au format CLUSTER-NAMESPACE-CLUSTER-NAME-control-plane.CLUSTER-NAMESPACE-CLUSTER-NAME-control-plane comme ci-dessus et un code de score Santé (Health) qui n'est ni rouge ni gris.Supprimez les espaces Kube-VIP sur toutes les machines virtuelles du plan de contrôle du cluster :
Établissez une connexion SSH à la machine virtuelle du plan de contrôle :
ssh -i PRIVATE-KEY capv@IP-ADDRESS
Où :
PRIVATE-KEY est la clé privée couplée avec la clé publique, qui est configurée dans le fichier clusterconfig.yaml.IP-ADDRESS est l'adresse IP de la machine virtuelle du plan de contrôle. Cela est répertorié dans vCenter, ou vous pouvez le récupérer en exécutant kubectl get vspheremachine -o yaml.Supprimez le fichier kube-vip.yaml :
rm /etc/kubernetes/manifest/kube-vip.yaml
Terminez la connexion SSH à la machine virtuelle du plan de contrôle :
exit
Attendez quelques minutes et exécutez la commande suivante pour vous assurer que tous les espaces Kube-VIP sont supprimés du système :
kubectl get po -A | grep "kube-vip"
Assurez-vous que la sortie de cette commande n'inclut aucun espace Kube-VIP.
Ouvrez la spécification d'objet KCP (Kubernetes Control Plane) dans un éditeur :
kubectl edit kcp CLUSTER-NAME-control-plane -n CLUSTER-NAMESPACE
Où :
CLUSTER-NAME est le nom du cluster.CLUSTER-NAMESPACE est l'espace de noms que vous utilisez pour le cluster.Dans la spécification d'objet KCP, supprimez l'intégralité du bloc files sous spec.kubeadmConfigSpec et enregistrez le fichier.
Voici un exemple de spécification d'objet KCP après sa mise à jour :
spec:
infrastructureTemplate:
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereMachineTemplate
name: ha-mc-1-control-plane
namespace: tkg-system
kubeadmConfigSpec:
clusterConfiguration:
apiServer:
extraArgs:
cloud-provider: external
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
timeoutForControlPlane: 8m0s
controllerManager:
extraArgs:
cloud-provider: external
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
dns:
imageRepository: projects.registry.vmware.com/tkg
imageTag: v1.8.0_vmware.5
type: CoreDNS
etcd:
local:
dataDir: /var/lib/etcd
extraArgs:
cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
imageRepository: projects.registry.vmware.com/tkg
imageTag: v3.4.13_vmware.15
imageRepository: projects.registry.vmware.com/tkg
networking: {}
scheduler:
extraArgs:
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
initConfiguration:
localAPIEndpoint:
advertiseAddress: ""
bindPort: 0
nodeRegistration:
criSocket: /var/run/containerd/containerd.sock
kubeletExtraArgs:
cloud-provider: external
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
name: '{{ ds.meta_data.hostname }}'
joinConfiguration:
discovery: {}
nodeRegistration:
criSocket: /var/run/containerd/containerd.sock
kubeletExtraArgs:
cloud-provider: external
tls-cipher-suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
name: '{{ ds.meta_data.hostname }}'
preKubeadmCommands:
- hostname "{{ ds.meta_data.hostname }}"
- echo "::1 ipv6-localhost ipv6-loopback" >/etc/hosts
- echo "127.0.0.1 localhost" >>/etc/hosts
- echo "127.0.0.1 {{ ds.meta_data.hostname }}" >>/etc/hosts
- echo "{{ ds.meta_data.hostname }}" >/etc/hostname
useExperimentalRetryJoin: true
users:
- name: capv
sshAuthorizedKeys:
- ssh-rsa AAAAB3NzaC1yc2[...]kx21vUu58cj
sudo: ALL=(ALL) NOPASSWD:ALL
replicas: 1
rolloutStrategy:
rollingUpdate:
maxSurge: 1
type: RollingUpdate
version: v1.23.8+vmware.1
Le système déclenche une mise à niveau continue après la modification de KCP. Attendez la fin de cette mise à niveau. Une nouvelle machine virtuelle de plan de contrôle basée sur AVI est créée et les objets Kubernetes correspondants sont mis à jour pour utiliser la nouvelle machine virtuelle.
AKODeploymentConfig d'un clusterPour savoir quel objet CR AKODeploymentConfig est utilisé sur le cluster actuel, exécutez la commande suivante sur la CLI Tanzu :
kubectl --context={management cluster kubeconfig context} get cluster --show-labels
Dans la sortie, examinez le champ networking.tkg.tanzu.vmware.com/avi=<AKODeploymentConfig-NAME> pour afficher l'objet AKODeploymentConfig qui a été sélectionné par le cluster.
Pendant la configuration NSX Advanced Load Balancer, Tanzu Kubernetes Grid valide l'entrée que vous spécifiez pour les champs de configuration. Les erreurs sont consignées lorsque le système détecte des entrées incorrectes. Si le champ AVI_ENABLE est défini sur true lors du déploiement d'un cluster de gestion, la CLI Tanzu effectue une validation sur l'entrée que vous spécifiez pour les champs suivants :
AVI_CONTROLLERAVI_USERNAMEAVI_PASSWORDAVI_CA_DATA_B64AVI_CLOUD_NAMEAVI_SERVICE_ENGINE_GROUPAVI_DATA_NETWORKAVI_DATA_NETWORK_CIDRAVI_MANAGEMENT_CLUSTER_SERVICE_ENGINE_GROUPAVI_MANAGEMENT_CLUSTER_CONTROL_PLANE_VIP_NETWORK_NAMEAVI_MANAGEMENT_CLUSTER_VIP_NETWORK_NAMEAVI_CONTROL_PLANE_NETWORKAVI_MANAGEMENT_CLUSTER_CONTROL_PLANE_VIP_NETWORK_CIDRAVI_MANAGEMENT_CLUSTER_VIP_NETWORK_CIDRAVI_CONTROL_PLANE_NETWORK_CIDRLorsque vous créez un objet AKODeploymentConfig, Tanzu Kubernetes Grid vérifie si :
AKODeploymentConfig)spec.AdminCredentialRef, spec.CertificateAuthorityRef et spec.Controller disposent de l'entrée correcte pour se connecter au contrôleur AVI.spec.CloudName existe, ou le client AVI qui a été initialisé est utilisé.spec.ServiceEngineGroup existe, ou le client AVI qui a été initialisé est utilisé.spec.ControlPlaneNetwork.Name existe, ou le client AVI qui a été initialisé est utilisé.spec.DataNetwork.Name existe, ou le client AVI qui a été initialisé est utilisé.spec.ControlPlaneNetwork.Name dispose d'un profil IPAM configuré ou n'utilise pas le client AVI qui a été initialisé.spec.ControlPlaneNetwork.CIDR est valide.spec.DataNetwork.CIDR est valide.Lorsque vous mettez à jour un objet AKODeploymentConfig, Tanzu Kubernetes Grid vérifie si spec.ClusterSelector et spec.ControlPlaneNetwork sont inchangés. Vous ne pouvez pas supprimer le fichier install-ako-for-management-cluster AKODeploymentConfig.
