Migrer la configuration pour l'intégration F5 BIG-IP

Preview

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Ce document explique comment migrer les paramètres de configuration de votre équilibreur de charge intégré F5 BIG-IP vers le mode d'équilibrage de charge manuel.

Compatibilité avec l'équilibreur de charge F5 BIG-IP

Auparavant, vous pouviez configurer Google Distributed Cloud pour l'intégrer à F5 BIG-IP de la manière suivante: lorsqu'un développeur crée un service de type LoadBalancer et spécifie une adresse IP virtuelle (VIP) pour le service, Google Distributed Cloud configure automatiquement l'adresse IP virtuelle sur l'équilibreur de charge.

Pour activer des fonctionnalités nouvelles et avancées, telles que Controlplane V2, nous vous recommandons de mettre à jour la configuration. Vous pouvez continuer à utiliser votre équilibreur de charge F5 BIG-IP, mais vous devez modifier les paramètres dans les fichiers de configuration de votre cluster pour utiliser l'équilibrage de charge manuel.

Conditions requises

Voici les conditions requises pour la migration:

• Le cluster d'administrateur et tous les clusters d'utilisateur doivent être de version 1.29 ou ultérieure.

• Vous devez utiliser des adresses IP statiques pour vos nœuds de cluster d'administrateur et 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 d'utilisateur

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

1. Remplacez loadBalancer.kind par "ManualLB".

2. Conservez les mêmes valeurs pour les champs loadBalancer.vips.controlPlaneVIP et loadBalancer.vips.ingressVIP.

3. Configurez le paramètre 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 au fichier kubeconfig du cluster d'utilisateur.

   2. Ajoutez la valeur de la commande précédente dans le champ loadBalancer.manualLB.ingressHTTPNodePort, par exemple:

      loadBalancer:
        manualLB:
          ingressHTTPNodePort: 30243

4. Configurez le paramètre nodePort utilisé pour le trafic HTTPS envoyé à l'adresse IP virtuelle d'entrée:

   1. Obtenez la valeur HTTPS actuelle nodePort:

      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 dans le champ loadBalancer.manualLB.ingressHTTPSNodePort, par exemple:

      loadBalancer:
        manualLB:
          ingressHTTPSNodePort: 30879

5. 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 :

      • ADMIN_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster admin.

      • USER_CLUSTER_NAME: nom du cluster d'utilisateur.

   2. Ajoutez la valeur de la commande précédente dans le champ loadBalancer.manualLB.controlPlaneNodePort, par exemple:

      loadBalancer:
        manualLB:
          controlPlaneNodePort: 30968

6. 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 dans le champ loadBalancer.manualLB.konnectivityServerNodePort, par exemple:

      loadBalancer:
        manualLB:
          konnectivityServerNodePort: 30563

7. Supprimez toute la section loadBalancer.f5BigIP.

8. Exécutez gkectl diagnose cluster et corrigez les problèmes détectés par la commande.

   gkectl diagnose cluster \
       --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
       --cluster-name=USER_CLUSTER_NAME

Mettez à 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:

1. Remplacez loadBalancer.kind par "ManualLB".

2. Conservez la même valeur pour le champ loadBalancer.vips.controlPlaneVIP.

3. Vérifiez la valeur du champ adminMaster.replicas. Si la valeur est 3, le cluster d'administrateur est disponibilité élevée. Si la valeur est 1, cela signifie que le cluster d'administrateur est standard.

4. Procédez comme suit 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 dans le champ loadBalancer.manualLB.controlPlaneNodePort, par exemple:

      loadBalancer:
        manualLB:
          controlPlaneNodePort: 30968

5. Exécutez la commande suivante pour voir s'il existe un module complémentaire nodePort:

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       get deploy monitoring-operator -n kube-system -oyaml | grep admin-ingress-nodeport

   Si la commande précédente génère une valeur, ajoutez-la au champ loadBalancer.manualLB.addonsNodePort, par exemple:

   loadBalancer:
     manualLB:
       addonsNodePort: 31405

6. Supprimez toute la section loadBalancer.f5BigIP.

7. Exécutez gkectl diagnose cluster et corrigez les problèmes détectés par la commande.

   gkectl diagnose cluster \
       --kubeconfig=ADMIN_CLUSTER_KUBECONFIG

Mettez à jour le cluster d'administrateur :

Mettez à jour le cluster avec la commande suivante :

gkectl update cluster \
    --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

Après la mise à jour de vos clusters pour qu'ils utilisent l'équilibrage de charge manuel, le trafic vers vos clusters n'est pas interrompu, car les ressources F5 existantes existent toujours, comme vous pouvez le constater 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 du cluster d'administrateur ou par le fichier kubeconfig 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 virtuelles aux adresses IP des nœuds: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 haute disponibilité. Bien qu'il ne soit pas nécessaire 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 du module complémentaire

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

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

Ce mappage doit s'appliquer à tous les nœuds du cluster d'administrateur, à la fois les nœuds du plan de contrôle et les nœuds des modules complémentaires.

Cluster d'administrateur standard

Trafic du plan de contrôle

Voici le mappage avec l'adresse IP et la valeur nodePort pour le nœud du plan de contrôle:

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

Ce mappage doit s'appliquer à tous les nœuds du cluster d'administrateur, à la fois le nœud du plan de contrôle et les nœuds du module complémentaire.

Trafic vers les services dans les nœuds du module complémentaire

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

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

Ce mappage doit s'appliquer à tous les nœuds du cluster d'administrateur, à la fois le nœud du plan de contrôle et les nœuds du module complémentaire.

Cluster d'utilisateur

Trafic du plan de contrôle

Le tableau suivant montre le mappage avec les adresses IP et les valeurs nodePort pour le trafic du plan de contrôle:

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

Ce mappage doit s'appliquer à tous les nœuds du cluster admin, à la fois le cluster d'administrateur et les nœuds du plan de contrôle du cluster d'utilisateur.

Trafic du plan de données

Vous trouverez ci-dessous la mise en correspondance avec les adresses IP et les valeurs nodePort pour le trafic du plan de données:

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

Remarque :La vérification de l'état de ingressVIP échouera tant que vous n'aurez pas configuré au moins une entrée.