F5 BIG-IP ロードバランサの構成設定を移行する

1.29: プレビュー
1.28: 利用不可

このドキュメントでは、バージョン 1.29 のクラスタで F5 BIG-IP ロードバランサ統合の構成設定を手動ロード バランシング モードに移行する方法について説明します。クラスタのバージョンが 1.30 以降の場合は、推奨機能へのクラスタの移行を計画するの説明に従って操作することをおすすめします。

手動ロード バランシング モードで F5 BIG-IP を使用すると、F5 ロードバランサや Kubernetes サービスの機能に影響を与えることなく、F5 エージェントを個別にアップグレードできます。手動構成に移行すると、F5 から直接アップデートを取得して、最適なパフォーマンスとセキュリティを確保できます。

この移行は、次の状況で必要になります。

  • Controlplane V2 などの新機能を有効にし、F5 にもアクセスする必要がある。

  • BIG-IP CIS Container Ingress Services(CIS)Controller のバージョン v1.14 以降で提供される機能が必要。

上記の状況に該当しない場合は、F5 BIG-IP ロード バランシングにバンドル構成を引き続き使用できます。

いずれにしても、Google はロードバランサ ソリューションとして F5 を公式にサポートし続けます。

F5 BIG-IP ロードバランサのバージョニング

F5 BIG-IP は、次の 2 つのコントローラで構成されるロードバランサ エージェントの使用をサポートしています。

  • F5 Controller(Pod 接頭辞: load-balancer-f5): LoadBalancer タイプの Kubernetes Service を F5 Common Controller Core Library(CCCL)ConfigMap 形式に調整します。

  • F5 BIG-IP CIS Controller v1.14(Pod 接頭辞: k8s-bigip-ctlr-deployment): ConfigMap を F5 ロードバランサ構成に変換します。

これらのエージェントは、Kubernetes クラスタ内の F5 ロードバランサの構成を合理化します。LoadBalancer タイプの Service を作成すると、コントローラは、トラフィックをクラスタノードに転送するように F5 ロードバランサを自動的に構成します。

ただし、バンドルされたソリューションには次のような制限があります。

  • Service API の表現力に制限があります。BIG-IP コントローラを自由に構成したり、F5 の高度な機能を使用することはできません。F5 は、Service API の優れたサポートをネイティブに提供します。

  • この実装では、以前の CCCL ConfigMap API と 1.x CIS を使用します。ただし、F5 は新しい AS3 ConfigMap API と 2.x CIS を提供しています。

CIS v2.x の F5 アップグレード ガイダンスとの互換性の問題により、Google Distributed Cloud バンドルの CIS コントローラは v1.14 のままです。そのため、セキュリティの脆弱性に対処し、最新機能を柔軟に利用できるように、F5 エージェントをバンドル コンポーネントから個別にインストールできるように移行しています。移行すると、既存のエージェントを中断することなく引き続き使用できます。以前に作成したサービスは引き続き動作します。

新たに作成され、ロード バランシング ソリューションとして F5 を使用する手動ロード バランシング クラスタの場合は、コントローラを自分でインストールする必要があります。同様に、クラスタがバンドルの F5 から移行され、新しいバージョンの CIS Controller を使用する場合は、コントローラを自分でインストールする必要があります。

要件

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

  • 管理クラスタとすべてのユーザー クラスタが、バージョン 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 セクション全体を削除します。

ユーザー クラスタを更新する

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

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 セクション全体を削除します。

管理クラスタを更新する

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

gkectl update admin \
    --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)