このページでは、Anthos clusters on VMware(GKE On-Prem)に管理クラスタを作成する方法について説明します。
ここでは手順全体を詳しく解説します。管理クラスタの作成の概要については、管理クラスタの作成(クイックスタート)をご覧ください。
始める前に
管理ワークステーションへの SSH 接続の確立
管理ワークステーションへの SSH 接続を確立します。
gkeadm
により、管理ワークステーションでコンポーネント アクセス サービス アカウントが有効にされたことを思い出してください。
このトピックの残りの手順はすべて、ホーム ディレクトリの管理ワークステーションで行います。
認証情報の構成ファイル
gkeadm
を使用して管理ワークステーションを作成した際に、credential.yaml
という名前の認証情報構成ファイルに入力しました。このファイルは、vCenter Server のユーザー名とパスワードを保持しています。
管理クラスタの構成ファイル
gkeadm
で管理用ワークステーションを作成した際に、admin-cluster.yaml
という名前の構成ファイルが生成されました。この構成ファイルは、管理クラスタの作成用です。
構成ファイルの入力
bundlePath
このフィールドはあらかじめ入力されています。
vCenter
ほとんどのフィールドには、管理ワークステーションの作成時に指定した値がすでに入力されています。dataDisk
フィールドは例外で、ここで値を入力する必要があります。
network
クラスタノードから IP アドレスを取得する方法を決めます。次のオプションがあります。
DHCP サーバーから。
network.ipMode.type
を"dhcp"
に設定する。指定した静的 IP アドレスのリストから。
network.ipMode.type
を"static"
に設定し、静的 IP アドレスを提供する IP ブロック ファイルを作成します。
network
セクションの残りのフィールドに値を入力します。
DHCP サーバーを使用するか静的 IP アドレスのリストを指定するかにかかわらず、次の要件を満たす十分な数の IP アドレスが必要です。
管理クラスタの 3 つのノードで管理クラスタのコントロール プレーンとアドオンを実行する。
アップグレード時に、管理クラスタ内の追加のノードが一時的に使用される。
作成するユーザー クラスタごとに、管理クラスタの 1 つまたは 3 つのノードでユーザー クラスタのコントロール プレーン コンポーネントを実行する。ユーザー クラスタのコントロール プレーンを高可用性(HA)にする場合は、管理クラスタ内の 3 つのノードでユーザー クラスタ コントロール プレーンを実行する必要があります。それ以外の場合、ユーザー クラスタ コントロール プレーンが必要とする管理クラスタ内のノードは 1 つだけです。
たとえば、HA コントロール プレーンのユーザー クラスタと HA 以外のコントロール プレーンのユーザー クラスタを 1 つずつ作成したとします。この場合、管理クラスタ内の次のノードに 8 つの IP アドレスが必要になります。
- 管理クラスタ コントロール プレーンとアドオンの 3 つのノード
- 1 つの一時ノード
- HA ユーザー クラスタ コントロール プレーンの 3 つのノード
- HA 以外のユーザー クラスタ コントロール プレーンの 1 つのノード
前述のとおり、静的 IP アドレスを使用する場合は、IP ブロック ファイルを指定する必要があります。次に、8 台のホストを含む IP ブロック ファイルの例を示します。
blocks: - netmask: 255.255.252.0 gateway: 172.16.23.254 ips: - ip: 172.16.20.10 hostname: admin-host1 - ip: 172.16.20.11 hostname: admin-host2 - ip: 172.16.20.12 hostname: admin-host3 - ip: 172.16.20.13 hostname: admin-host4 - ip: 172.16.20.14 hostname: admin-host5 - ip: 172.16.20.15 hostname: admin-host6 - ip: 172.16.20.16 hostname: admin-host7 - ip: 172.16.20.17 hostname: admin-host8
loadBalancer
管理クラスタの Kubernetes API サーバー用に VIP を確保します。アドオン サーバーに別の VIP を設定します。loadBalancer.vips.controlPlaneVIP
と loadBalancer.vips.addonsVIP
の値として VIP を指定します。
使用する負荷分散の種類を決めます。次のオプションがあります。
Seesaw によるバンドルされた負荷分散。
loadBalancer.kind
を"Seesaw"
に設定し、loadBalancer.seesaw
セクションに入力します。F5 BIG-IP による統合負荷分散。
loadBalancer.kind
を"F5BigIP"
に設定し、f5BigIP
セクションに入力します。手動負荷分散。
loadBalancer.kind
を"ManualLB"
に設定し、manualLB
セクションに入力します。
antiAffinityGroups
必要に応じて、antiAffinityGroups.enabled
を true
または false
に設定します。
proxy
管理クラスタノードを持つネットワークがプロキシ サーバーの背後にある場合は、proxy
セクションに入力します。
privateRegistry
Anthos clusters on VMware コンポーネントのコンテナ イメージを保持する場所を決定します。次のオプションがあります。
gcr.io。
privateRegistry
セクションには入力しないでください。独自の非公開 Docker レジストリ。
privateRegistry
セクションに入力します。
gcrKeyPath
gcrKeyPath
に、コンポーネント アクセス サービス アカウントの JSON キーファイルのパスを設定します。
stackdriver
stackdriver
セクションに入力します。
cloudAuditLogging
Kubernetes 監査ログを Cloud Audit Logs と統合する場合は、cloudAuditLogging
セクションに入力します。
autoRepair
ノードの自動修復を有効にする場合は、autoRepair.enabled
を true
に設定します。それ以外の場合は、false
に設定します。
構成ファイルの検証
管理クラスタの構成ファイルに入力したら、gkectl check-config
を実行してファイルが有効であることを検証します。
gkectl check-config --config [CONFIG_PATH]
[CONFIG_PATH] は、管理クラスタの構成ファイルのパスです。
コマンドがエラー メッセージを返した場合は、問題を修正してファイルを再度検証します。
時間のかかる検証をスキップする場合は、--fast
フラグを渡します。個別の検証をスキップするには、--skip-validation-xxx
フラグを使用します。check-config
コマンドについて詳しくは、プリフライト チェックの実行をご覧ください。
gkectl prepare
の実行
gkectl prepare
を実行して、vSphere 環境を初期化します。
gkectl prepare --config [CONFIG_PATH]
gkectl prepare
コマンドによって、以下の準備タスクが実行されます。
OS イメージを vSphere にインポートして、VM テンプレートとしてマークします。
非公開 Docker レジストリを使用している場合、このコマンドは Docker コンテナ イメージをレジストリに push します。
必要に応じて、このコマンドを使用して、コンテナ イメージのビルド証明書を検証します。これにより、イメージが Google によって作成、署名されていることと、デプロイの準備ができていることを確認します。
管理クラスタの Seesaw ロードバランサの作成
バンドル型の Seesaw ロードバランサを使用する場合は、このセクションの手順を行います。それ以外の場合は、このセクションをスキップできます。
Seesaw ロードバランサの VM を作成して構成します。
gkectl create loadbalancer --config [CONFIG_PATH]
管理クラスタの作成
管理クラスタを作成します。
gkectl create admin --config [CONFIG_PATH]
ここで、[CONFIG_PATH] は管理クラスタの構成ファイルのパスです。
管理クラスタの kubeconfig ファイルを見つける
gkectl create admin
コマンドで、現在のディレクトリに kubeconfig
という名前の kubeconfig ファイルが作成されます。この kubeconfig ファイルは後で管理クラスタとやり取りする際に必要になります。
kubeconfig ファイルの名前と場所は、必要に応じて変更できます。
管理クラスタが実行されていることを確認する
管理クラスタが実行されていることを確認します。
kubectl get nodes --kubeconfig ADMIN_CLUSTER_KUBECONFIG
ADMIN_CLUSTER_KUBECONFIG は、管理クラスタ kubeconfig ファイルのパスに置き換えます。
出力には、管理クラスタノードが表示されます。 次に例を示します。
gke-admin-master-hdn4z Ready control-plane,master ... gke-admin-node-7f46cc8c47-g7w2c Ready ... gke-admin-node-7f46cc8c47-kwlrs Ready ...
トラブルシューティング
クラスタの作成とアップグレードに対するトラブルシューティングをご覧ください。