統合型 F5 BIG-IP の構成を移行する

このドキュメントでは、F5 BIG-IP 統合ロードバランサの構成設定を手動負荷分散モードに移行する方法について説明します。

F5 BIG-IP ロードバランサのサポート

これまでは、次のような方法で Google Distributed Cloud を F5 BIG-IP と統合するように構成できました。デベロッパーが LoadBalancer タイプのサービスを作成し、そのサービスの仮想 IP アドレス（VIP）を指定すると、Google Distributed Cloud によって自動的にロードバランサで VIP が構成されます。

コントロール プレーン V2 などの新しい機能や高度な機能を有効にするには、構成を更新することをおすすめします。F5 BIG-IP ロードバランサは引き続き使用できますが、手動負荷分散を使用するようにクラスタ構成ファイルの設定を変更する必要があります。

要件

移行の要件は次のとおりです。

  • 管理クラスタとすべてのユーザー クラスタが、バージョン 1.29 以降である必要があります。

  • 管理クラスタノードとユーザー クラスタノードには、静的 IP アドレスを使用する必要があります。IP アドレス指定タイプは network.ipMode.type フィールドで設定され、不変です。このフィールドが DHCP に設定されている場合、クラスタを移行できません。

ユーザー クラスタ構成ファイルを更新する

ユーザー クラスタ構成ファイルを次のように変更します。

  1. loadBalancer.kind を "ManualLB" に変更します。

  2. loadBalancer.vips.controlPlaneVIP フィールドと loadBalancer.vips.ingressVIP フィールドは同じ値のままにします。

  3. Ingress VIP に送信される HTTP トラフィックに使用される nodePort を構成します。

    1. 現在の HTTP nodePort 値を取得します。

      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get svc istio-ingress -n gke-system -oyaml | grep http2 -A 1

      USER_CLUSTER_KUBECONFIG は、ユーザー クラスタ kubeconfig ファイルのパスに置き換えます。

    2. 前のコマンドで取得した値を loadBalancer.manualLB.ingressHTTPNodePort フィールドに追加します。次に例を示します。

      loadBalancer:
  manualLB:
    ingressHTTPNodePort: 30243

  4. Ingress VIP に送信される HTTPS トラフィックに使用される nodePort を構成します。

    1. 現在の HTTPS nodePort 値を取得します。

      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get svc istio-ingress -n gke-system -oyaml | grep https -A 1

    2. 前のコマンドで取得した値を loadBalancer.manualLB.ingressHTTPSNodePort フィールドに追加します。次に例を示します。

      loadBalancer:
  manualLB:
    ingressHTTPSNodePort: 30879

  5. Kubernetes API サーバーの nodePort を構成します。

    1. Kubernetes API サーバーの現在の nodePort 値を取得します。

      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    get svc kube-apiserver -n USER_CLUSTER_NAME -oyaml | grep kube-apiserver-port -A 1

      次のように置き換えます。

      • ADMIN_CLUSTER_KUBECONFIG は、管理クラスタの kubeconfig ファイルのパスに置き換えます。

      • USER_CLUSTER_NAME: ユーザー クラスタの名前。

    2. 前のコマンドで取得した値を loadBalancer.manualLB.controlPlaneNodePort フィールドに追加します。次に例を示します。

      loadBalancer:
  manualLB:
    controlPlaneNodePort: 30968

  6. Konnectivity サーバーの nodePort を構成します。

    1. Konnectivity サーバーの現在の nodePort 値を取得します。

      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    get svc kube-apiserver -n USER_CLUSTER_NAME -oyaml | grep konnectivity-server-port -A 1

    2. 前のコマンドで取得した値を loadBalancer.manualLB.konnectivityServerNodePort フィールドに追加します。次に例を示します。

      loadBalancer:
  manualLB:
    konnectivityServerNodePort: 30563

  7. loadBalancer.f5BigIP セクション全体を削除します。

  8. gkectl diagnose cluster を実行し、コマンドで検出された問題を修正します。

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

ユーザー クラスタを更新します。

次のコマンドを実行してクラスタを移行します。

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

次のように置き換えます。

  • ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。

  • USER_CLUSTER_CONFIG: ユーザー クラスタ構成ファイルのパス

管理クラスタ構成ファイルを更新する

管理クラスタ構成ファイルを次のように変更します。

  1. loadBalancer.kind を "ManualLB" に変更します。

  2. loadBalancer.vips.controlPlaneVIP フィールドは同じ値のままにします。

  3. adminMaster.replicas フィールドの値を確認します。値が 3 の場合、管理クラスタは高可用性（HA）です。値が 1 の場合、管理クラスタは非 HA です。

  4. 次の手順は、非 HA 管理クラスタに対してのみ行います。

    1. Kubernetes API サーバーの nodePort の値を取得します。

      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    get svc kube-apiserver -n kube-system -oyaml | grep nodePort

      ADMIN_CLUSTER_KUBECONFIG は、管理クラスタの kubeconfig ファイルのパスに置き換えます。

    2. 前のコマンドで取得した値を loadBalancer.manualLB.controlPlaneNodePort フィールドに追加します。次に例を示します。

      loadBalancer:
  manualLB:
    controlPlaneNodePort: 30968

  5. 次のコマンドを実行して、アドオン nodePort があるかどうかを確認します。

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

    上記のコマンドで値を出力する場合は、loadBalancer.manualLB.addonsNodePort フィールドに追加します。次に例を示します。

    loadBalancer:
  manualLB:
    addonsNodePort: 31405

  6. loadBalancer.f5BigIP セクション全体を削除します。

  7. gkectl diagnose cluster を実行し、コマンドで検出された問題を修正します。

    gkectl diagnose cluster \
    --kubeconfig=ADMIN_CLUSTER_KUBECONFIG

管理クラスタを更新します。

次のコマンドを実行してクラスタを更新します。

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

次のように置き換えます。

  • ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。

  • ADMIN_CLUSTER_CONFIG: 管理クラスタ構成ファイルのパス

以前の F5 リソースがまだ存在することを確認する

手動負荷分散を使用するようにクラスタを更新した後も、次のコマンドを実行するとわかるように、既存の F5 リソースがまだ存在するため、クラスタへのトラフィックは中断されません。

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

CLUSTER_KUBECONFIG は、管理クラスタまたはユーザー クラスタの kubeconfig ファイルのパスに置き換えます。

想定される出力は次のようになります。

管理クラスタ

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

ユーザー クラスタ

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

ロードバランサを確認する

移行後は、同じ VIP と nodePort 値を保持しているため、ロードバランサの設定を変更する必要はありません。次の表に、VIP からノード IP アドレスへのマッピングを示します。nodePort

HA 管理クラスタ

コントロール プレーン ノードへのトラフィック

Google Distributed Cloud は、HA 管理クラスタのコントロール プレーン トラフィックのロード バランシングを自動的に処理します。ロードバランサでマッピングを構成する必要はありませんが、loadBalancer.vips.controlPlaneVIP フィールドに IP アドレスを指定する必要があります。

アドオンノード内のサービスへのトラフィック

管理クラスタに addonsNodePort の値がある場合、アドオンノードのサービスへのトラフィックの IP アドレスと nodePort 値へのマッピングが表示されます。

  • （addonsVIP:8443）->（NODE_IP_ADDRESSES:addonsNodePort）

管理クラスタ内のすべてのノード（コントロール プレーン ノードとアドオンノードの両方）でこのマッピングが必要です。

非 HA 管理クラスタ

コントロール プレーン トラフィック

以下に、コントロール プレーン ノードの IP アドレスと nodePort 値へのマッピングを示します。

  • （controlPlaneVIP:443）->（NODE_IP_ADDRESSES:controlPlaneNodePort）

管理クラスタ内のすべてのノード（コントロール プレーン ノードとアドオンノードの両方）でこのマッピングが必要です。

アドオンノード内のサービスへのトラフィック

管理クラスタに addonsNodePort の値がある場合、アドオンノードで実行されているサービスの IP アドレスと nodePort 値には、次のマッピングが必要です。

  • （addonsVIP:8443）->（NODE_IP_ADDRESSES:addonsNodePort）

管理クラスタ内のすべてのノード（コントロール プレーン ノードとアドオンノードの両方）でこのマッピングが必要です。

ユーザー クラスタ

コントロール プレーン トラフィック

以下に、コントロール プレーン トラフィックの IP アドレスと nodePort 値へのマッピングを示します。

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

管理クラスタ内のすべてのノード（管理クラスタとユーザー クラスタ コントロール プレーン ノードの両方）でこのマッピングが必要です。

データプレーン トラフィック

以下に、データプレーン トラフィックの IP アドレスと nodePort 値へのマッピングを示します。

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