管理クラスタの作成

このページでは、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 に設定します。

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 コマンドを使用します。クラスタの問題を診断するをご覧ください。

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

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

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

    • gkectl の場合、デフォルトのログファイルは /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log で、このファイルは gkectl を実行するローカル ディレクトリの logs/gkectl-$(date).log ファイルにシンボリック リンクされます。
    • gkeadm の場合、デフォルトのログファイルは、gkeadm を実行するローカル ディレクトリの logs/gkeadm-$(date).log です。
  • すべてのログエントリは、ターミナルに出力されていない場合（--alsologtostderr が false の場合）でもログファイルに保存されます。
  • -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]

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

次のステップ

ユーザー クラスタの作成