Migrer la configuration de F5 BIG-IP intégré

Ce document explique comment migrer les paramètres de configuration de votre équilibreur de charge intégré BIG-IP de F5 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 comme suit: lorsqu'un développeur crée un service de type LoadBalancer et spécifie une adresse IP virtuelle (VIP) pour ce service, Google Distributed Cloud configure automatiquement l'adresse IP virtuelle sur l'équilibreur de charge.

Pour activer de nouvelles fonctionnalités 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 de vos fichiers de configuration de 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 ne peut pas être modifié. S'il 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 au champ loadBalancer.manualLB.ingressHTTPNodePort, par exemple:

      loadBalancer:
  manualLB:
    ingressHTTPNodePort: 30243

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

    1. Obtenez la valeur HTTPS nodePort 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

  5. Configurez le paramètre 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 au champ loadBalancer.manualLB.controlPlaneNodePort, par exemple:

      loadBalancer:
  manualLB:
    controlPlaneNodePort: 30968

  6. Configurez le nodePort pour le serveur Konnectivity:

    1. Obtenez la valeur nodePort actuelle du 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

  7. Supprimez l'intégralité de 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, le cluster d'administrateur n'est pas de haute disponibilité.

  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 au 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 l'intégralité de 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 avoir 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 existent toujours, 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 du 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 plus avoir besoin de 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 avec les adresses IP et la valeur nodePort pour le trafic vers les services des nœuds complémentaires:

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

Vous devez appliquer ce mappage pour tous les nœuds du cluster d'administrateur, à la fois les nœuds du plan de contrôle et les nœuds du module complémentaire.

Cluster d'administrateur standard

Trafic du plan de contrôle

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

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

Vous devez appliquer ce mappage pour 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 possédait une valeur pour addonsNodePort, vous devriez obtenir le mappage suivant sur les adresses IP et les valeurs nodePort pour les services exécutés dans des nœuds complémentaires:

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

Vous devez appliquer ce mappage pour 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

Vous trouverez ci-dessous le mappage sur 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

L'exemple suivant illustre le mappage 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)