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 に設定されている場合、クラスタを移行できません。
ユーザー クラスタの構成ファイルを更新する
ユーザー クラスタの構成ファイルを次のように変更します。
loadBalancer.kindを"ManualLB"に変更します。loadBalancer.vips.controlPlaneVIPフィールドとloadBalancer.vips.ingressVIPフィールドの値は同じにします。Ingress VIP に送信される HTTP トラフィックに使用する
nodePortを構成します。現在の HTTP
nodePort値を取得します。kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ get svc istio-ingress -n gke-system -oyaml | grep http2 -A 1USER_CLUSTER_KUBECONFIGは、ユーザー クラスタの kubeconfig ファイルのパスに置き換えます。前のコマンドの値を
loadBalancer.manualLB.ingressHTTPNodePortフィールドに追加します。次に例を示します。loadBalancer: manualLB: ingressHTTPNodePort: 30243
Ingress VIP に送信される HTTPS トラフィックに使用される
nodePortを構成します。現在の HTTPS
nodePort値を取得します。kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \ get svc istio-ingress -n gke-system -oyaml | grep https -A 1前のコマンドの値を
loadBalancer.manualLB.ingressHTTPSNodePortフィールドに追加します。次に例を示します。loadBalancer: manualLB: ingressHTTPSNodePort: 30879
Kubernetes API サーバー用の
nodePortを構成します。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: ユーザー クラスタの名前。
前のコマンドの値を
loadBalancer.manualLB.controlPlaneNodePortフィールドに追加します。次に例を示します。loadBalancer: manualLB: controlPlaneNodePort: 30968
Konnectivity サーバーの
nodePortを構成します。Konnectivity サーバーの現在の
nodePort値を取得します。kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ get svc kube-apiserver -n USER_CLUSTER_NAME -oyaml | grep konnectivity-server-port -A 1前のコマンドの値を
loadBalancer.manualLB.konnectivityServerNodePortフィールドに追加します。次に例を示します。loadBalancer: manualLB: konnectivityServerNodePort: 30563
loadBalancer.f5BigIPセクション全体を削除します。
ユーザー クラスタを更新する
次のコマンドを実行してクラスタを移行します。
gkectl update cluster \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config USER_CLUSTER_CONFIG次のように置き換えます。
ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。USER_CLUSTER_CONFIG: ユーザー クラスタの構成ファイルのパス
管理クラスタの構成ファイルを更新する
管理クラスタの構成ファイルを次のように変更します。
loadBalancer.kindを"ManualLB"に変更します。loadBalancer.vips.controlPlaneVIPフィールドの値は同じにします。adminMaster.replicasフィールドの値を確認します。値が 3 の場合、管理クラスタは高可用性（HA）です。値が 1 の場合、管理クラスタは非 HA です。次の手順は、非 HA 管理クラスタにのみ行います。
Kubernetes API サーバーの
nodePortの値を取得します。kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ get svc kube-apiserver -n kube-system -oyaml | grep nodePortADMIN_CLUSTER_KUBECONFIGは、管理クラスタの kubeconfig ファイルへのパスに置き換えます。前のコマンドの値を
loadBalancer.manualLB.controlPlaneNodePortフィールドに追加します。次に例を示します。loadBalancer: manualLB: controlPlaneNodePort: 30968
次のコマンドを実行して、アドオン
nodePortが存在するかどうかを確認します。kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ get deploy monitoring-operator -n kube-system -oyaml | grep admin-ingress-nodeport前のコマンドで値が出力された場合は、その値を
loadBalancer.manualLB.addonsNodePortフィールドに追加します。次に例を示します。loadBalancer: manualLB: addonsNodePort: 31405loadBalancer.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)