このドキュメントでは、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 に設定されている場合、クラスタを移行できません。
ユーザー クラスタ構成ファイルを更新する
ユーザー クラスタ構成ファイルを次のように変更します。
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 1
USER_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 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
: ユーザー クラスタ構成ファイルのパス
管理クラスタ構成ファイルを更新する
管理クラスタ構成ファイルを次のように変更します。
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 nodePort
ADMIN_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: 31405
loadBalancer.f5BigIP
セクション全体を削除します。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
)