Migrer les paramètres de configuration de votre équilibreur de charge F5 BIG-IP

1.30 : Disponibilité générale
1.29 : Aperçu
1.28 : Non disponible

Ce document explique comment migrer les paramètres de configuration de l'intégration de votre équilibreur de charge F5 BIG-IP vers le mode d'équilibrage de charge manuel. L'utilisation de F5 BIG-IP en mode d'équilibrage de charge manuel vous permet de mettre à niveau vos agents F5 indépendamment, sans affecter le fonctionnement de votre équilibreur de charge F5 ni vos services Kubernetes. Si vous passez à la configuration manuelle, vous pourrez obtenir des mises à jour directement auprès de l'équilibreur de charge F5 pour garantir des performances et une sécurité optimales.

Cette migration est nécessaire dans les cas suivants :

Vous souhaitez activer de nouvelles fonctionnalités telles que Controlplane V2 et vous avez également besoin d'accéder à F5.
Vous avez besoin des fonctionnalités fournies par une version du contrôleur BIG-IP Container Ingress Services (CIS) supérieure à la version 1.14.

Si les circonstances précédentes ne s'appliquent pas à votre cas, vous pouvez continuer à utiliser la configuration groupée pour l'équilibrage de charge F5 BIG-IP.

Dans tous les cas, nous continuons à assurer officiellement la compatibilité F5 comme solution d'équilibrage de charge.

Compatibilité des versions de l'équilibreur de charge F5 BIG-IP

Nous acceptons l'utilisation de F5 BIG-IP avec des agents d'équilibrage de charge, qui se composent des deux contrôleurs suivants :

Contrôleur F5 (préfixe de pod : load-balancer-f5) : consolide les services Kubernetes de type LoadBalancer dans le format ConfigMap de la bibliothèque principale de contrôleur commun (CCCL) F5.
Contrôleur de F5 BIG-IP CIS v1.14 (préfixe de pod : k8s-bigip-ctlr-deployment) : traduit les ConfigMaps en configurations d'équilibrage de charge F5.

Ces agents simplifient la configuration des équilibreurs de charge F5 dans votre cluster Kubernetes. En créant un service de type LoadBalancer, les contrôleurs configurent automatiquement l'équilibreur de charge F5 pour rediriger le trafic vers les nœuds de votre cluster.

Toutefois, la solution groupée présente les limites suivantes :

L'expressivité de l'API Service est limitée. Vous ne pouvez pas configurer le contrôleur BIG-IP comme vous le souhaitez ni utiliser les fonctionnalités F5 avancées. F5 offre déjà une meilleure compatibilité avec l'API Service de manière native.
L'implémentation utilise l'ancienne API ConfigMap CCCL et la version 1.x de CIS. Toutefois, F5 fournit désormais la nouvelle API AS3 ConfigMap et la version 2.x de CIS.

Le contrôleur CIS du bundle Google Distributed Cloud est resté à la version 1.14 en raison de problèmes de compatibilité avec les directives de mise à niveau de F5 pour la version 2.x de CIS. Par conséquent, pour vous permettre de corriger les failles de sécurité et d'accéder aux dernières fonctionnalités, nous procédons à la transition des agents F5, qui passent de composants regroupés à des installations indépendantes. Si vous effectuez une migration, vous pouvez continuer à utiliser les agents existants sans interruption, et vos services précédemment créés restent opérationnels.

Pour les clusters d'équilibrage de charge manuel nouvellement créés avec F5 comme solution d'équilibrage de charge, vous devez installer vous-même les contrôleurs. De même, si votre cluster a été migré depuis F5 regroupé et que vous souhaitez utiliser une version plus récente du contrôleur CIS, vous devez installer vous-même les contrôleurs.

Conditions requises

Voici les conditions requises pour la migration :

Le cluster d'administrateur et tous les clusters d'utilisateurs doivent être à la version 1.29 ou ultérieure.
Vous devez utiliser des adresses IP statiques pour les nœuds de votre cluster d'administrateur et de votre cluster d'utilisateur. Le type d'adressage IP est défini dans le champ network.ipMode.type et est immuable. Si ce champ est défini sur DHCP, vous ne pouvez pas migrer les clusters.

Mettre à jour le fichier de configuration du cluster utilisateur

Apportez les modifications suivantes au fichier de configuration du cluster utilisateur :

Remplacez loadBalancer.kind par "ManualLB".
Conservez les mêmes valeurs pour les champs loadBalancer.vips.controlPlaneVIP et loadBalancer.vips.ingressVIP.
Configurez le nodePort utilisé pour le trafic HTTP envoyé à l'adresse IP virtuelle d'entrée.
1. Obtenez la valeur HTTP nodePort actuelle :
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get svc istio-ingress -n gke-system -oyaml | grep http2 -A 1
```
  Remplacez USER_CLUSTER_KUBECONFIG par le chemin d'accès du fichier kubeconfig de votre cluster d'utilisateur.
2. Ajoutez la valeur de la commande précédente au champ loadBalancer.manualLB.ingressHTTPNodePort, par exemple :
```
loadBalancer:
  manualLB:
    ingressHTTPNodePort: 30243
```
Configurez le nodePort utilisé pour le trafic HTTPS envoyé à l'adresse IP virtuelle d'entrée :
1. Obtenez la valeur nodePort HTTPS actuelle :
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get svc istio-ingress -n gke-system -oyaml | grep https -A 1
```
2. Ajoutez la valeur de la commande précédente au champ loadBalancer.manualLB.ingressHTTPSNodePort, par exemple :
```
loadBalancer:
  manualLB:
    ingressHTTPSNodePort: 30879
```
Configurez nodePort pour le serveur d'API Kubernetes :
1. Obtenez la valeur nodePort actuelle pour le serveur d'API Kubernetes :
```
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    get svc kube-apiserver -n USER_CLUSTER_NAME -oyaml | grep kube-apiserver-port -A 1
```
  Remplacez les éléments suivants :
  - Remplacez ADMIN_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'administrateur.
  - USER_CLUSTER_NAME : nom du cluster d'utilisateur.
2. Ajoutez la valeur de la commande précédente au champ loadBalancer.manualLB.controlPlaneNodePort, par exemple :
```
loadBalancer:
  manualLB:
    controlPlaneNodePort: 30968
```
Configurez nodePort pour le serveur Konnectivity :
1. Obtenez la valeur nodePort actuelle pour le serveur Konnectivity :
```
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    get svc kube-apiserver -n USER_CLUSTER_NAME -oyaml | grep konnectivity-server-port -A 1
```
2. Ajoutez la valeur de la commande précédente au champ loadBalancer.manualLB.konnectivityServerNodePort, par exemple :
```
loadBalancer:
  manualLB:
    konnectivityServerNodePort: 30563
```
Supprimez l'intégralité de la section loadBalancer.f5BigIP.

Mettre à jour le cluster d'utilisateur

Exécutez la commande suivante pour migrer le cluster :

gkectl update cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

Remplacez les éléments suivants :

ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
USER_CLUSTER_CONFIG : chemin d'accès au fichier de configuration du cluster d'utilisateur

Mettre à jour le fichier de configuration du cluster d'administrateur

Apportez les modifications suivantes au fichier de configuration du cluster d'administrateur :

Remplacez loadBalancer.kind par "ManualLB".
Conservez la même valeur pour le champ loadBalancer.vips.controlPlaneVIP.
Vérifiez la valeur du champ adminMaster.replicas. Si la valeur est 3, le cluster d'administrateur dispose d'une disponibilité élevée. Si la valeur est 1, le cluster d'administrateur ne dispose pas d'une disponibilité élevée.
Suivez les étapes ci-dessous uniquement pour les clusters d'administrateur standards :
1. Obtenez la valeur de nodePort pour le serveur d'API Kubernetes :
```
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    get svc kube-apiserver -n kube-system -oyaml | grep nodePort
```
  Remplacez ADMIN_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'administrateur.
2. Ajoutez la valeur de la commande précédente au champ loadBalancer.manualLB.controlPlaneNodePort, par exemple :
```
loadBalancer:
  manualLB:
    controlPlaneNodePort: 30968
```
Exécutez la commande suivante pour voir s'il existe un nodePort complémentaire :
```
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    get deploy monitoring-operator -n kube-system -oyaml | grep admin-ingress-nodeport
```
Si la commande précédente renvoie une valeur, ajoutez-la au champ loadBalancer.manualLB.addonsNodePort, par exemple :
```
loadBalancer:
  manualLB:
    addonsNodePort: 31405
```
Supprimez l'intégralité de la section loadBalancer.f5BigIP.

Mettre à jour le cluster d'administrateur

Mettez à jour le cluster avec la commande suivante :

gkectl update admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG

Remplacez les éléments suivants :

ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
ADMIN_CLUSTER_CONFIG : chemin d'accès au fichier de configuration du cluster d'administrateur

Vérifier que les anciennes ressources F5 existent toujours

Une fois que vous avez mis à jour vos clusters pour utiliser l'équilibrage de charge manuel, le trafic vers vos clusters n'est pas interrompu, car les ressources F5 existantes sont toujours là, comme vous pouvez le voir en exécutant la commande suivante :

kubectl --kubeconfig CLUSTER_KUBECONFIG \
  api-resources --verbs=list -o name   | xargs -n 1 kubectl --kubeconfig CLUSTER_KUBECONFIG get --show-kind --ignore-not-found --selector=onprem.cluster.gke.io/legacy-f5-resource=true -A

Remplacez CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'administrateur ou du cluster d'utilisateur.

Le résultat ressemble à ce qui suit :

Cluster d'administrateur :

Warning: v1 ComponentStatus is deprecated in v1.19+
NAMESPACE     NAME                        TYPE     DATA   AGE
kube-system   secret/bigip-login-xt697x   Opaque   4      13h
NAMESPACE     NAME                              SECRETS   AGE
kube-system   serviceaccount/bigip-ctlr         0         13h
kube-system   serviceaccount/load-balancer-f5   0         13h
NAMESPACE     NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/k8s-bigip-ctlr-deployment   1/1     1            1           13h
kube-system   deployment.apps/load-balancer-f5            1/1     1            1           13h
NAME                                                                                ROLE                                       AGE
clusterrolebinding.rbac.authorization.k8s.io/bigip-ctlr-clusterrole-binding         ClusterRole/bigip-ctlr-clusterrole         13h
clusterrolebinding.rbac.authorization.k8s.io/load-balancer-f5-clusterrole-binding   ClusterRole/load-balancer-f5-clusterrole   13h
NAME                                                                 CREATED AT
clusterrole.rbac.authorization.k8s.io/bigip-ctlr-clusterrole         2024-03-25T04:37:34Z
clusterrole.rbac.authorization.k8s.io/load-balancer-f5-clusterrole   2024-03-25T04:37:34Z

Cluster d'utilisateur :

Warning: v1 ComponentStatus is deprecated in v1.19+
NAMESPACE     NAME                        TYPE     DATA   AGE
kube-system   secret/bigip-login-sspwrd   Opaque   4      14h
NAMESPACE     NAME                              SECRETS   AGE
kube-system   serviceaccount/bigip-ctlr         0         14h
kube-system   serviceaccount/load-balancer-f5   0         14h
NAMESPACE     NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/k8s-bigip-ctlr-deployment   1/1     1            1           14h
kube-system   deployment.apps/load-balancer-f5            1/1     1            1           14h
NAME                                                                                ROLE                                       AGE
clusterrolebinding.rbac.authorization.k8s.io/bigip-ctlr-clusterrole-binding         ClusterRole/bigip-ctlr-clusterrole         14h
clusterrolebinding.rbac.authorization.k8s.io/load-balancer-f5-clusterrole-binding   ClusterRole/load-balancer-f5-clusterrole   14h
NAME                                                                 CREATED AT
clusterrole.rbac.authorization.k8s.io/bigip-ctlr-clusterrole         2024-03-25T05:16:40Z
clusterrole.rbac.authorization.k8s.io/load-balancer-f5-clusterrole   2024-03-25T05:16:41Z

Vérifier votre équilibreur de charge

Après la migration, vous ne devriez pas avoir à modifier les paramètres de votre équilibreur de charge, car vous avez conservé les mêmes adresses IP virtuelles et valeurs nodePort. Les tableaux suivants décrivent les mappages des adresses IP des nœuds aux adresses IP virtuelles : nodePort.

Cluster d'administrateur à haute disponibilité

Trafic vers les nœuds du plan de contrôle

Google Distributed Cloud gère automatiquement l'équilibrage de charge du trafic du plan de contrôle pour les clusters d'administrateur à disponibilité élevée. Bien que vous n'ayez pas besoin de configurer un mappage dans l'équilibreur de charge, vous devez spécifier une adresse IP dans le champ loadBalancer.vips.controlPlaneVIP.

Trafic vers les services dans les nœuds complémentaires

Si votre cluster d'administrateur avait une valeur pour addonsNodePort, vous devriez voir un mappage des adresses IP et de la valeur nodePort pour le trafic vers les services dans les nœuds complémentaires :

(addonsVIP:8443) -> (NODE_IP_ADDRESSES:addonsNodePort)

Vous devez disposer de ce mappage pour tous les nœuds du cluster d'administrateur, y compris les nœuds du plan de contrôle et les nœuds complémentaires.

Cluster d'administrateur standard

Trafic du plan de contrôle

L'exemple suivant montre le mappage vers l'adresse IP et la valeur nodePort pour le nœud du plan de contrôle :

(controlPlaneVIP:443) -> (NODE_IP_ADDRESSES:controlPlaneNodePort)

Vous devez disposer de ce mappage pour tous les nœuds du cluster d'administrateur, y compris les nœuds du plan de contrôle et les nœuds complémentaires.

Trafic vers les services dans les nœuds complémentaires

Si votre cluster d'administrateur avait une valeur pour addonsNodePort, vous devriez avoir le mappage suivant pour les adresses IP et les valeurs nodePort des services exécutés dans des nœuds complémentaires :

(addonsVIP:8443) -> (NODE_IP_ADDRESSES:addonsNodePort)

Vous devez disposer de ce mappage pour tous les nœuds du cluster d'administrateur, y compris les nœuds du plan de contrôle et les nœuds complémentaires.

Cluster d'utilisateur

Trafic du plan de contrôle

Voici le mappage des adresses IP et des valeurs nodePort pour le trafic du plan de contrôle :

(controlPlaneVIP:443) -> (NODE_IP_ADDRESSES:controlPlaneNodePort)
(controlPlaneVIP:8132) -> (NODE_IP_ADDRESSES:konnectivityServerNodePort)

Vous devez disposer de ce mappage pour tous les nœuds du cluster d'administrateur, y compris les nœuds du plan de contrôle du cluster d'administrateur et du cluster d'utilisateur.

Trafic du plan de données

Voici le mappage des adresses IP et des valeurs nodePort pour le trafic du plan de données :

(ingressVIP:80) -> (NODE_IP_ADDRESSES:ingressHTTPNodePort)
(ingressVIP:443) -> (NODE_IP_ADDRESSES:ingressHTTPSNodePort)