このページでは、Anthos clusters on VMware(GKE On-Prem)に管理クラスタを作成する方法について説明します。
ここでは手順全体を詳しく解説します。管理クラスタの作成の概要については、管理クラスタの作成(クイックスタート)をご覧ください。
始める前に
管理ワークステーションへの SSH 接続の確立
管理ワークステーションへの SSH 接続を確立します。
gkeadm
により、管理ワークステーションでコンポーネント アクセス サービス アカウントが有効にされたことを思い出してください。
このトピックの残りの手順はすべて、ホーム ディレクトリの管理ワークステーションで行います。
認証情報の構成ファイル
gkeadm
を使用して管理ワークステーションを作成した際に、credential.yaml
という名前の認証情報構成ファイルに入力しました。このファイルは、vCenter Server のユーザー名とパスワードを保持しています。
管理クラスタの構成ファイル
gkeadm
で管理用ワークステーションを作成した際に、admin-cluster.yaml
という名前の構成ファイルが生成されました。この構成ファイルは、管理クラスタの作成用です。
構成ファイルの入力
name
管理クラスタの名前を指定する場合は、name
フィールドに入力します。
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
に設定します。
adminMaster
adminMaster
セクションに入力するか、必要に応じて削除します。
addonNode
必要に応じて、addonNode.autoResize.enabled
を true
または false
に設定します。
proxy
管理クラスタノードを持つネットワークがプロキシ サーバーの背後にある場合は、proxy
セクションに入力します。
privateRegistry
Anthos clusters on VMware コンポーネントのコンテナ イメージを保持する場所を決定します。次のオプションがあります。
gcr.io。
privateRegistry
セクションには入力しないでください。独自の非公開 Docker レジストリ。
独自の非公開 Docker レジストリを作成するには、次のようにします。
privateRegistry
セクションに入力します。レジストリ証明書が存在しない場合は、
/etc/docker/certs.d/REGISTRY_SERVER_ADDRESS/ca.crt
の必要な場所にコピーします。レジストリ証明書は管理シード構成のprivateRegistry.caCertPath
に設定されています。mkdir -p /etc/docker/certs.d/REGISTRY_SERVER_ADDRESS cp CERTIFICATE_PATH /etc/docker/certs.d/REGISTRY_SERVER_ADDRESS/ca.crt
次のように置き換えます。
REGISTRY_SERVER_ADDRESS
: 非公開レジストリの IP アドレスCERTIFICATE_PATH
: レジストリ証明書へのパス
componentAccessServiceAccountKeyPath
このフィールドはあらかじめ入力されています。
gkeConnect
Google Cloud フリートに管理クラスタを登録する場合は、gkeConnect
セクションに入力します。
stackdriver
クラスタに対して Cloud Logging と Cloud Monitoring を有効にする場合は、stackdriver
セクションに入力します。
cloudAuditLogging
クラスタに対して Cloud Audit Logs を有効にする場合は、cloudAuditLogging
セクションに入力します。
clusterBackup
必要に応じて、clusterBackup.datastore
を true
または false
に設定します。
autoRepair
必要に応じて、autoRepair.enabled
を true
または false
に設定します。
secretsEncryption
Secret の常時暗号化を有効にする場合は、secretsEncryption
セクションに入力します。
構成ファイルの検証
管理クラスタの構成ファイルに入力したら、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 ...
checkpoint.yaml
ファイルの管理
gkectl create admin
コマンドを実行して管理クラスタを作成した場合、管理クラスタのデータディスクと同じデータストア フォルダに checkpoint.yaml
ファイルが作成されています。デフォルトでは、このファイルの名前は DATA_DISK_NAME‑checkpoint.yaml です。DATA_DISK_NAME の長さが 245 文字以上の場合、ファイル名の長さに対する vSphere の上限のために、名前が DATA_DISK_NAME.yaml になります。DATA_DISK_NAME は、データディスクの名前に置き換えます。
このファイルには管理クラスタの状態と認証情報が含まれ、今後のアップグレードに使用されます。管理クラスタ データディスクと同様に、管理クラスタの削除プロセスを行っている場合を除き、このファイルを削除しないでください。
vCenter で VM の暗号化を有効にしている場合、チェックポイント ファイルをアップロードするには、管理クラスタを作成またはアップグレードする前に Cryptographer.Access
権限が必要です。この権限を取得できない場合は、関連するコマンドを実行するときに、隠しフラグ --disable-checkpoint
を指定してチェックポイント ファイルのアップロードを無効にできます。
checkpoint.yaml ファイルは、gkectl upgrade admin
コマンドを実行するか、管理クラスタに影響を与える gkectl update
コマンドを実行すると、自動的に更新されます。
トラブルシューティング
クラスタの作成とアップグレードに対するトラブルシューティングをご覧ください。