バージョン 1.6。 このバージョンは、Anthos バージョン サポート ポリシーに記載のとおり、サポートを終了しています。Anthos clusters on VMware (GKE on-prem) に影響するセキュリティの脆弱性、露出、問題に対する最新のパッチとアップデートを適用するには、サポート対象のバージョンにアップグレードしてください。最新バージョンはこちらで確認できます。

管理クラスタの作成

このページでは、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.controlPlaneVIPloadBalancer.vips.addonsVIP の値として VIP を指定します。

使用する負荷分散の種類を決めます。次のオプションがあります。

  • Seesaw によるバンドルされた負荷分散。loadBalancer.kind"Seesaw" に設定し、loadBalancer.seesaw セクションに入力します。

  • F5 BIG-IP による統合負荷分散。loadBalancer.kind"F5BigIP" に設定し、f5BigIP セクションに入力します。

  • 手動負荷分散。loadBalancer.kind"ManualLB" に設定し、manualLB セクションに入力します。

antiAffinityGroups

必要に応じて、antiAffinityGroups.enabledtrue または 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.enabledtrue に設定します。それ以外の場合は、false に設定します。

adminMaster

管理コントロール プレーン ノードの CPU とメモリを手動で構成する場合は、adminMaster セクションに入力します。

構成ファイルの検証

管理クラスタの構成ファイルに入力したら、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] は、管理クラスタの構成ファイルのパスです。

gkectl create admin コマンドで、現在のディレクトリに kubeconfig という名前の kubeconfig ファイルが作成されます。この kubeconfig ファイルは後で管理クラスタとやり取りする際に必要になります。

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

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

kubectl get nodes --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

ここで、[ADMIN_CLUSTER_KUBECONFIG] は kubeconfig ファイルのパスです。

出力には、管理クラスタノードが表示されます。

トラブルシューティング

gkectl を使用してクラスタの問題を診断する

クラスタの問題を特定し、クラスタの情報を Google と共有するために、gkectl diagnose コマンドを使用します。クラスタの問題を診断するをご覧ください。

デフォルトのロギング動作

gkectlgkeadm では、デフォルトのロギング設定を使用するだけで十分です。

  • デフォルトでは、ログエントリは次のように保存されます。

    • gkectl の場合、デフォルトのログファイルは /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log で、このファイルは gkectl を実行するローカル ディレクトリの logs/gkectl-$(date).log ファイルにシンボリック リンクされます。
    • gkeadm の場合、デフォルトのログファイルは、gkeadm を実行するローカル ディレクトリの logs/gkeadm-$(date).log です。
  • すべてのログエントリは、ターミナルに出力されていない場合(--alsologtostderrfalse の場合)でもログファイルに保存されます。
  • -v5 詳細レベル(デフォルト)は、サポートチームが必要とするログエントリすべてを対象としています。
  • ログファイルには、実行されたコマンドと失敗メッセージも含まれます。

サポートが必要な場合は、サポートチームにログファイルを送信することをおすすめします。

ログファイルにデフォルト以外の場所を指定する

gkectl ログファイルにデフォルト以外の場所を指定するには、--log_file フラグを使用します。指定したログファイルは、ローカル ディレクトリにシンボリック リンクされません。

gkeadm ログファイルにデフォルト以外の場所を指定するには、--log_file フラグを使用します。

管理クラスタで Cluster API ログを見つける

管理コントロール プレーンの起動後に VM が起動しない場合は、管理クラスタの Cluster API コントローラのログを調べてデバッグを試すことができます。

  1. kube-system Namespace で Cluster API コントローラ Pod の名前を確認します。ここで、[ADMIN_CLUSTER_KUBECONFIG] は管理クラスタの kubeconfig ファイルのパスです。

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
  2. Pod のログを開きます。ここで、[POD_NAME] は Pod の名前です。必要に応じて、grep または同様のツールを使用してエラーを検索します。

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager

管理クラスタのコントロール プレーン ノードの kubeconfig を使用した F5 BIG-IP の問題のデバッグ

Anthos clusters on VMware をインストールすると、管理ワークステーションのホーム ディレクトリに internal-cluster-kubeconfig-debug という名前の kubeconfig ファイルが生成されます。この kubeconfig ファイルは、管理コントロール プレーンが実行される管理クラスタのコントロール プレーン ノードを直接参照することを除いて、管理クラスタの kubeconfig と同じです。この internal-cluster-kubeconfig-debug ファイルを使用して、F5 BIG-IP の問題をデバッグできます。

gkectl check-config 検証が失敗: F5 BIG-IP パーティションが見つからない

現象

F5 BIG-IP パーティションが存在している場合でも見つからず、検証に失敗します。

考えられる原因

F5 BIG-IP API に問題があると、検証が失敗することがあります。

解決策

もう一度 gkectl check-config を実行してみてください。

gkectl prepare --validate-attestations が失敗: ビルド証明書を検証できない

現象

オプションの --validate-attestations フラグを指定して gkectl prepare を実行すると、次のエラーが返されます。

could not validate build attestation for gcr.io/gke-on-prem-release/.../...: VIOLATES_POLICY
考えられる原因

影響を受けるイメージの証明書が存在しない可能性があります。

解決策

管理ワークステーションの作成の説明に従って、管理ワークステーションの OVA をもう一度ダウンロードしてデプロイしてみてください。問題が解決しない場合は、Google にお問い合わせください。

ブートストラップ クラスタのログを使用したデバッグ

インストール中、Anthos clusters on VMware により一時的なブートストラップ クラスタが作成されます。インストールが正常に完了した後、Anthos clusters on VMware によってブートストラップ クラスタが削除され、管理クラスタとユーザー クラスタが残されます。通常、このクラスタを操作する理由はありません。

インストール中に問題が発生し、gkectl create cluster--cleanup-external-cluster=false が渡された場合は、ブートストラップ クラスタのログを使用してデバッグすると便利です。Pod を見つけてログを取得できます。

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs [POD_NAME]

詳しくは、トラブルシューティングを参照してください。

次のステップ

ユーザー クラスタの作成