2024年7月23日 【Google Cloud】第3回:GKE on VMwareを構築してみた~構築編後半~ Anthos GKE Google Cloud VMware 検索する Popular tags 生成AI(Generative AI) Looker Studio BigQuery AlloyDB Google Workspace 事例紹介 Cloud SQL Category Google Cloud Author Google Cloud研究開発チーム SHARE 目次 前提 管理クラスタ作成 ユーザークラスタ作成 デプロイ まとめ 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を構築してみた~概要編~ をご覧ください。 管理クラスタとユーザークラスタを構築する前に、本手順の前提条件は以下です。 「【Google Cloud】第2回:GKE on VMwareを構築してみた~構築編前半~」の構築が完了していること。 管理ワークステーションにSSH接続していること。 ※なお、使用するコマンド、ファイルの大文字で記載している箇所につきましては、各自の設定に置き換えてください。 管理クラスタ作成 管理クラスタを作成していきます。 コマンドは管理ワークステーションで実行してください。 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コンソール画面の「クラスタ」ページで、作成した管理クラスタが確認できます。 !!注意!! 管理コンソール画面を確認すると管理クラスタのステータスがエラーと表示されましたが、以下を確認し、今回の検証範囲では問題ないと判断したのでこのまま次へと進みます。 Cloud Loggingにエラーログ(警告以上)が表示されてない クラスタの「詳細」を見ると、ステータスが正常になっている 「クラスタ画面」からステータスがエラーでフィルタリングしても表示されない 管理クラスタの詳細を見れる「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を構築してみた~構築編後半~ ★本記事 関連コンテンツ 頂きましたご意見につきましては、今後のより良い商品開発・サービス改善に活かしていきたいと考えております。 よくわかった 実際につかってみたい よくわからなかった これからの時代はハイブリッドクラウドだ Author Google Cloud研究開発チーム 株式会社システムサポート(STS)のGoogle Cloud研究開発チームです。 実際に技術検証した事例を中心に記事発信していきます。 Anthos GKE Google Cloud VMware 2024年7月23日 【Google Cloud】第3回:GKE on VMwareを構築してみた~構築編後半~ Category Google Cloud 前の記事を読む 【Google Cloud】第2回:GKE on VMwareを構築してみた~構築編前半~ 次の記事を読む Google Cloud Next Tokyo ’24:登壇のお知らせ(DX成功事例) Recommendation オススメ記事 2023年9月5日 Google Cloud 【Google Cloud】Looker Studio × Looker Studio Pro × Looker を徹底比較!機能・選び方を解説 2023年8月24日 Google Cloud 【Google Cloud】Migrate for Anthos and GKEでVMを移行してみた(1:概要編) 2022年10月10日 Google Cloud 【Google Cloud】AlloyDB と Cloud SQL を徹底比較してみた!!(第1回:AlloyDB の概要、性能検証編) BigQuery ML ワークショップ開催のお知らせ 生成AI導入支援パッケージ Discovery AI導入支援パッケージ Google Cloud ホワイトペーパー 新着記事 2024年9月2日 4koma 【4コマ漫画】SEひつじは定時退社の夢を見る ~ダウングレード~ 2024年8月29日 Google Cloud 【Google Cloud】Cloud NGFW Standard を試してみた 2024年8月29日 Google Cloud 【Google Cloud】Cloud Storage FUSE Read Cache を試してみた HOME Google Cloud 【Google Cloud】第3回:GKE on VMwareを構築してみた~構築編後半~ ご意見・ご相談・料金のお見積もりなど、お気軽にお問い合わせください。 お問い合わせはこちら HOME Categories お知らせ イベント・セミナー Google Cloud Google Workspace モバイル インフラ 技術開発 ブログ 4koma Tags 生成AI(Generative AI) Looker Studio BigQuery AlloyDB Google Workspace 事例紹介 Cloud SQL STSエンジニアリングマガジン 「サイタル」