2024年7月23日

【Google Cloud】第3回:GKE on VMwareを構築してみた~構築編後半~


Content
本記事は、以下記事シリーズの第3回です。

【Google Cloud】第1回:GKE on VMwareを構築してみた~概要編~
【Google Cloud】第2回:GKE on VMwareを構築してみた~構築編前半~
【Google Cloud】第3回:GKE on VMwareを構築してみた~構築編後半~ ★本記事

第2回では、GKE on VMware構築の前半の手順についてご説明しました。
本記事は公式ドキュメントを参考に、後半にあたる管理クラスタ・ユーザークラスタ作成、デプロイまでの構築手順を説明します。

前提

GKE on VMwareにおける管理クラスタは、ユーザクラスタを集中管理するクラスタです。ユーザークラスタを作成、管理、ライフサイクル管理を行います。
ユーザークラスタはワークロードを実行する実際のクラスタで、アプリケーションが稼働します。
コンポーネントについては【Google Cloud】第1回:GKE on VMwareを構築してみた~概要編~ をご覧ください。

管理クラスタとユーザークラスタを構築する前に、本手順の前提条件は以下です。

※なお、使用するコマンド、ファイルの大文字で記載している箇所につきましては、各自の設定に置き換えてください。

管理クラスタ作成

管理クラスタを作成していきます。
コマンドは管理ワークステーションで実行してください。

 

1.管理クラスタ構成ファイルを作成する

管理ワークステーションでadmin-cluster.yamlを作成し、必要な情報を記載します。
yamlファイルの記載内容の詳細についてはこちら

yamlファイルを表示する▼
apiVersion: "v1"
kind: "AdminCluster"
name: "ADMIN_CLUSTER_NAME" ##管理クラスタ名
bundlePath: "/var/lib/gke/bundles/gke-onprem-vsphere-1.25.0-gke.651-full.tgz" ##GKE on VMware バンドルファイルのパス
vCenter:
address: "ADDRESS" ##vCenter ServerのIPアドレスまたはホスト名
datacenter: "DATA_CENTER" ##vSphereデータセンターの相対パス
cluster: "VSPHERE_CLUSTER" ##管理クラスタVMを実行するESXiホストを表すvSphereクラスタの相対パス
resourcePool: "Cluster/Resources" ##管理クラスタVMのvCenterリソースプール
datastore: "DATASTORE" ##管理クラスタのvSphereデータストアの名前
caCertPath: "CA_CERT_PATH" ##vCenter ServerのCA証明書のパス
credentials:
fileRef:
path: "CREDENTIAL_PATH" ##vCenterユーザーアカウントのユーザー名とパスワードを保持する認証情報構成ファイルのパス
entry: "vCenter" ##vCenterユーザーアカウントのユーザー名とパスワードを保持する認証情報構成ファイルにある認証情報ブロックの名前
network:
hostConfig:
dnsServers:
- "DNS_SERVER_IP" ##VMのDNSサーバーのアドレス
ntpServers:
- "NTP_SERVER_IP" ##VMが使用する時刻サーバーのアドレス
ipMode:
type: "dhcp" ##"dhcp"か"static"を指定
serviceCIDR: "SERVICE_CIDR" ##クラスタ内のServiceに使用されるIPアドレスの範囲(CIDR 形式)
podCIDR: "POD_CIDR" ##クラスタ内のPodに使用されるIPアドレスの範囲(CIDR 形式)
vCenter:
networkName: "NETWORK" ##クラスタノードのvSphereネットワークの名前
controlPlaneIPBlock:
netmask: "NETMASK" ##コントロールプレーンノードを持つネットワークのネットマスク
gateway: "DEFAULT_GATEWAY_IP" ##コントロールプレーンノードのデフォルトゲートウェイのIPアドレス
ips: ##コントロール プレーン ノードに割り当てるIPアドレスとオプションのホスト名を持つ3つのオブジェクトの配列
- ip: "ADMIN_CONTROL_PLANE_NODE_IP_1"
hostname: "ADMIN_CONTROLPLANE_HOSTNAME_1"
- ip: "ADMIN_CONTROL_PLANE_NODE_IP_2"
hostname: "ADMIN_CONTROLPLANE_HOSTNAME_2"
- ip: "ADMIN_CONTROL_PLANE_NODE_IP_3"
hostname: "ADMIN_CONTROLPLANE_HOSTNAME_3"
loadBalancer:
vips:
controlPlaneVIP: "ADMIN_CONTROL_PLANE_VIP" ##管理クラスタのKubernetes APIサーバー用にロードバランサで構成するために選択したIPアドレス
kind: "MetalLB" ##"ManualLB"、"F5BigIP"、"MetalLB"のいずれかを指定
antiAffinityGroups:
enabled: false ##DRS ルールの作成を有効にする(true) or しない(false)
adminMaster:
cpus: 3   ##管理クラスタ内の各コントロールプレーンノードのvCPU 数
memoryMB: 5120  ##管理クラスタ内の各コントロールプレーンノードのメモリ容量(メビバイト)
replicas: 3 ##管理クラスタ内のコントロールプレーンノードの数
componentAccessServiceAccountKeyPath: "COMPONENT_ACCESS_SA_KEY" ##コンポーネントアクセスサービスアカウントのJSONキーファイルのパス
gkeConnect:
projectID: "PROJECT_ID" ##GoogleCloudプロジェクトのID
registerServiceAccountKeyPath: "CONNECT_REGISTER_SA_KEY" ##接続登録サービスアカウントのJSON鍵ファイルのパス
stackdriver:
projectID: "PROJECT_ID"    ##GoogleCloudプロジェクトのID
clusterLocation: "REGION" ##ログを保存する Google Cloud リージョン
enableVPC: false ##クラスタのネットワークが VPC によって管理されている(true) or されていない(false)
serviceAccountKeyPath: "LOG_MON_SA_KEY" ##ロギングモニタリングサービスアカウントのJSON鍵ファイルのパス
disableVsphereResourceMetrics: false   ##trueに設定するとvSphereからの指標の収集が無効
cloudAuditLogging:
projectID: "PROJECT_ID" ##GoogleCloudプロジェクトのID
clusterLocation: "REGION" ##監査ログを保存するGoogle Cloudのリージョン
serviceAccountKeyPath: "AUDIT_LOG_SA_KEY" ##監査ログ サービスアカウントのJSON鍵ファイルのパス
autoRepair:
enabled: true ##ノードの自動修復を有効にする場合はtrue

 

2.管理クラスタ構成ファイルを検証する

作成したadmin-cluster.yamlが有効かどうかを、以下のコマンドを実行して確認します。

gkectl check-config --config admin-cluster.yaml

失敗していると「Exit with error」のエラーメッセージが返ってきます。

 

3.OS イメージを vSphere にインポートする

以下のコマンドを実行し、ノードのOSイメージをvSphereにインポートします。

gkectl prepare --config admin-cluster.yaml --skip-validation-all

 

4.管理クラスタを作成

作成したadmin-cluster.yamlを基に、以下のコマンドを実行して管理クラスタを作成します。

gkectl create admin --config admin-cluster.yaml

※管理クラスタの作成が完了するまで、45分程度かかりました。

 

5.管理クラスタの kubeconfig ファイルを見つける

管理クラスタの作成が完了すると、「kubeconfig」と言う名前のファイルが作成されます。
ls コマンドで管理クラスタのkubeconfigファイルが作成されているか確認してください。

 

6.管理クラスタが実行されていることを確認する

以下のコマンドで、管理クラスタが実行されていることを確認します。

kubectl get nodes --kubeconfig kubeconfig

以下のような結果が返され、管理クラスタノードのステータスが確認ができます。

 

7.RBAC 認証を有効にする

GCPコンソール画面で、クラスタの詳細をGoogle ID を使用して確認できるようにしたい場合は、以下のコマンドを実行します。

gcloud container fleet memberships generate-gateway-rbac \
--membership=minimal-installation-admin-cluster \
--role=clusterrole/cluster-admin \
--users='GOOGLE_ACCOUNT_EMAIL' \
--project=PROJECT_ID \
--kubeconfig=kubeconfig \
--context=minimal-installation-admin-cluster \
--apply

 

GCPコンソール画面の「クラスタ」ページで、作成した管理クラスタが確認できます。

!!注意!!
管理コンソール画面を確認すると管理クラスタのステータスがエラーと表示されましたが、以下を確認し、今回の検証範囲では問題ないと判断したのでこのまま次へと進みます。

  1. Cloud Loggingにエラーログ(警告以上)が表示されてない
  2. クラスタの「詳細」を見ると、ステータスが正常になっている
  3. 「クラスタ画面」からステータスがエラーでフィルタリングしても表示されない
  4. 管理クラスタの詳細を見れる「gcloud container vmware admin-clusters describe」コマンドで確認しても正常だった

ユーザークラスタ作成

ユーザークラスタを作成していきます。

コマンドは管理ワークステーションで実行してください。

 

1.ユーザー クラスタの IP ブロック ファイルを作成する

管理ワークステーションでuser-ipblock.yamlを作成し、必要な情報を記載します。

yamlファイルの記載内容の詳細についてはこちら

yamlファイルを表示する▼
blocks:
- netmask: "NETMASK" ##ホストのサブネットマスク
gateway: "DEFAULT_GATEWAY_IP" ##ホストのデフォルトゲートウェイのアドレス
ips: ##個別のIPアドレスまたはIPアドレスのCIDRブロック
- ip: "USER_NODE_IP_1"
hostname: "USER_NODE_HOSTNAME_1"
- ip: "USER_NODE_IP_2"
hostname: "USER_NODE_HOSTNAME_2"
- ip: "USER_NODE_IP_3"
hostname: "USERR_NODE_HOSTNAME_3"
- ip: "USER_NODE_IP_4"
hostname: "USER_NODE_HOSTNAME_4"

 

2.ユーザー クラスタ構成ファイルを作成する

管理ワークステーションでuser-cluster.yaml を作成し、必要な情報を記載します。

yamlファイルの記載内容の詳細についてはこちら

yamlファイルを表示する▼
apiVersion: v1
kind: UserCluster
name: "USER_CLUSTER_NAME" ##ユーザークラスタ名
gkeOnPremVersion: "1.28.0-gke.651" ##ユーザー クラスタの GKE on VMware のバージョン
enableControlplaneV2: true ##Controlplane V2が有効になっているユーザー クラスタを作成する場合はtrue
network:
hostConfig:
dnsServers:
- "DNS_SERVER_IP" ##VM の DNS サーバーのアドレス
ntpServers:
- "NTP_SERVER_IP" ##VM が使用する時刻サーバーのアドレス
ipMode:
type: "static" ##"dhcp"か"static"を指定
ipBlockFilePath: "user-ipblock.yaml" ##クラスタの IP ブロック ファイルのへのパス
serviceCIDR: "SERVICE_CIDR" ##クラスタ内の Service に使用される IP アドレスの範囲(CIDR 形式)
podCIDR: "POD_CIDR" ##クラスタ内の Pod に使用される IP アドレスの範囲(CIDR 形式)
controlPlaneIPBlock:
netmask: "NETMASK" ##コントロールプレーンノードを持つネットワークのネットマスク
gateway: "DEFAULT_GATEWAY_IP" ##コントロールプレーンノードのデフォルトゲートウェイの IP アドレス
ips:
- ip: "USER_CONTROL_PLANE_NODE_IP"
hostname: "USER_CONTROLPLANE_HOSTNAME"
loadBalancer:
vips:
controlPlaneVIP: "USER_CONTROL_PLANE_VIP" ##ユーザー クラスタのKubernetes APIサーバー用にロードバランサ上に構成することを選択した IP アドレス
ingressVIP: "USER_INGRESS_VIP" ##上り(内向き)プロキシのロードバランサを構成するために選択した IP アドレス
kind: "MetalLB" ##"ManualLB"、"F5BigIP"、"Seesaw"、"MetalLB" のいずれかを指定
metalLB:
addressPools:
- name: "ADDRESS_POOL_NAME" ##アドレスプールに付ける名前
addresses: ##アドレスの範囲
- "USER_INGRESS_VIP/32"
- "SERVICE_VIP_1/32"
- "SERVICE_VIP_2/32"
enableDataplaneV2: true ##Dataplane V2 を有効にする場合はtrue
nodePools:
- name: "uc-node-pool" ##ノードプールに付ける名前
cpus: 4 ##プール内の各ノードの vCPU 数
memoryMB: 8192 ##プール内の各ノードのメモリ容量(MiB)
replicas: 3 ##プール内のノード数
enableLoadBalancer: true ##プール内のノードで MetalLB スピーカーを実行できるようにする場合はtrue
antiAffinityGroups:
enabled: false ##DRS ルールの作成を有効にする(true) or しない(false)
gkeConnect:
projectID: "PROJECT_ID" ##GoogleCloudプロジェクトのID
registerServiceAccountKeyPath: "CONNECT_REGISTER_SA_KEY" ##接続登録サービス アカウントの JSON 鍵ファイルのパス
stackdriver:
projectID: "PROJECT_ID" ##GoogleCloudプロジェクトのID
clusterLocation: "REGION" ##ログを保存する Google Cloud リージョン
enableVPC: false ##クラスタのネットワークが VPC によって管理されている(true) or されていない(false)
serviceAccountKeyPath: "LOG_MON_SA_KEY" ##ロギングモニタリングサービスアカウントのJSON鍵ファイルのパス
disableVsphereResourceMetrics: false ##trueに設定するとvSphereからの指標の収集が無効
autoRepair:
enabled: true ##ノードの自動修復を有効にする場合はtrue

【備考】ワーカーノードは最低3個必要でした。

 

3.ユーザークラスタ構成ファイルを検証する

作成したuser-cluster.yamlを基に、以下のコマンドを実行してユーザークラスタを作成します。

gkectl check-config --kubeconfig kubeconfig --config user-cluster.yaml

管理クラスタの時と同様に、失敗していると「Exit with error」のエラーメッセージが返ってきます。

 

4.ユーザークラスタを作成を実行

作成したuser-cluster.yamlを基に、以下のコマンドを実行してユーザークラスタを作成します。

gkectl create cluster --kubeconfig kubeconfig --config user-cluster.yaml

※ユーザークラスタの作成が完了するまで、30分程度かかりました。

 

5.ユーザークラスタの kubeconfig ファイルを見つける

ユーザークラスタの作成が完了すると、「(ユーザークラスタ名)-kubeconfig」と言う名前のファイルが作成されます。

ls コマンドでユーザークラスタのkubeconfigファイルが作成されているか確認してください。

 

6.ユーザー クラスタが実行されていることを確認する

以下のコマンドで、ユーザークラスタが実行されていることを確認します。

kubectl get nodes --kubeconfig USER_CLUSTER_NAME-kubeconfig

管理クラスタの時と同様に、以下のような結果が返され、ユーザークラスタノードのステータスが確認ができます。

 

7.RBAC 認証を有効にする

GCPコンソール画面で、クラスタの詳細をGoogle ID を使用して確認できるようにしたい場合は、以下のコマンドを実行します。

gcloud container fleet memberships generate-gateway-rbac \
--membership=USER_CLUSTER_NAME \
--role=clusterrole/cluster-admin \
--users=GOOGLE_ACCOUNT_EMAIL \
--project=PROJECT_ID \
--kubeconfig=minimal-installation-user-cluster-kubeconfig \
--context=minimal-installation-user-cluster \
--apply

 

GCPコンソール画面の「クラスタ」ページを見てみると、新たにユーザークラスタが作成されていることが確認できます。

デプロイ

作成したユーザークラスタに、コンテナをデプロイしていきます。
GCPコンソール画面からコンテナをデプロイできるので、今回はそちらで実施していきます。
ユーザークラスタにログインした状態で、以下の手順を実行します。

 

1.GCPコンソール画面の「クラスタ」→「デプロイ」をクリック

 

2.「Deployment の作成」を入力する

「①コンテナ」にて「既存のコンテナ イメージ」を選択し、「イメージパス」に以下を入力します。

us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0

(Hello,Worldアプリのコンテナイメージのパスです。)

「②構成」にて以下を入力します。

  • Deployment 名:任意の名前を入力
  • 値:Deployment名を入力
  • クラスタ:ユーザークラスタを選択

※ユーザークラスタにログインしていないとユーザークラスタを選択することができません。

「③構成」にて、「Deployment を新しいサービスとして公開する」にチェックを入れ、以下を入力します。

  • ポート1:80
  • ターゲット ポート1:8080
  • プロトコル1:TCP
  • サービスタイプ:ロードバランサ

入力が完了したら「デプロイ」をクリックし、数分待機します。

 

3.デプロイしたアプリにアクセス

「Deployment の詳細」ページにて、ロードバランサのIPアドレスが表示されているので、そちらにアクセスします。

Hello,Worldアプリが表示されています。

まとめ

本記事では、管理クラスタとユーザクラスタの作成、コンテナのデプロイ手順を説明しました。
yamlファイルさえ準備できれば、実際のオンプレにKubernetesを構築するよりも簡単に構築することができました。

本記事シリーズが、GKE on VMwareについて知りたい方、これから構築したいという方の参考に少しでもなれば幸いです。
【Google Cloud】第1回:GKE on VMwareを構築してみた~概要編~
【Google Cloud】第2回:GKE on VMwareを構築してみた~構築編前半~
【Google Cloud】第3回:GKE on VMwareを構築してみた~構築編後半~ ★本記事

2024年7月23日 【Google Cloud】第3回:GKE on VMwareを構築してみた~構築編後半~

Category Google Cloud

ご意見・ご相談・料金のお見積もりなど、
お気軽にお問い合わせください。

お問い合わせはこちら