クラスタの作成とアップグレードのトラブルシューティング

このページでは、Anthos clusters on VMware（GKE On-Prem）内でクラスタの作成、アップグレード、サイズ変更に関する問題を調査する方法について説明します。

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

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

• gkectl の場合、デフォルトのログファイルは /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log で、このファイルは gkectl を実行するローカル ディレクトリの logs/gkectl-$(date).log ファイルにシンボリック リンクされます。

• gkeadm の場合、デフォルトのログファイルは、gkeadm を実行するローカル ディレクトリの logs/gkeadm-$(date).log です。

• デフォルトの -v5 詳細レベルは、サポートチームが必要とするログエントリすべてを対象としています。

• ログファイルには、実行されたコマンドとエラー メッセージが含まれます。

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

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

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

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

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

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

1. Cluster API コントローラ Pod の名前を見つけます。

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
       get pods | grep clusterapi-controllers
   

2. vsphere-controller-manager からのログを表示します。まず、Pod を指定しますが、コンテナは指定しません。

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
       logs POD_NAME
   

   出力には、コンテナを指定する必要があることが示され、Pod 内のコンテナの名前が示されます。例:

   ... a container name must be specified ...,
   choose one of: [clusterapi-controller-manager vsphere-controller-manager rbac-proxy]
   

   コンテナを選んで、そのログを表示します。

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
       logs POD_NAME --container CONTAINER_NAME
   

govc を使用して vSphere に関する問題を解決する

govc を使用すると、vSphere に関する問題を調査できます。たとえば、vCenter ユーザー アカウントの権限とアクセスを確認し、vSphere のログを収集できます。

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

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

--cleanup-external-cliuster=false を gkectl create cluster に渡した場合、ブートストラップ クラスタは削除されず、ブートストラップ クラスタのログを使用してインストールの問題をデバッグできます。

1. kube-system 名前空間で実行されている Pod の名前を確認します。

   kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system
   

2. Pod のログを表示します。

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

vCenter 証明書の変更

vCenter サーバーを評価モードまたはデフォルト設定モードで実行し、TLS 証明書が生成されている場合、その証明書は後で変更されることがあります。証明書が変更された場合は、実行中のクラスタに新しい証明書を通知する必要があります。

1. 新しい vCenter 証明書を取得して解凍します。

   curl -k -o certs.zip https://VCENTER_IP_ADDRESS/certs/download.zip
   unzip certs.zip
   

   -k フラグを使用すると、不明な証明書が許可されます。これは、vCenter へのアクセスに関する証明書の問題を回避するためのものです。

2. Linux 証明書を vcenter-ca.pem という名前のファイルに保存します。

   cat certs/lin/*.0 > vcenter-ca.pem
   

3. 管理クラスタ構成ファイルで、vCenter.caCertPath を新しい vcenter-ca.pem ファイルのパスに設定します。

4. 管理クラスタのコントロール プレーン ノードに接続するには SSH を使用します。

   ノードで、/etc/vsphere/certificate/ca.crt の内容を vcenter.pem の内容に置き換えます。

   SSH 接続を終了します。

5. vcenter-ca-certificate ConfigMap を削除します。kube-system の名前空間に 1 つ、各ユーザー クラスタの名前空間に 1 つずつあります。次に例を示します。

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG delete configmap vsphere-ca-certificate \
       --namespace kube-system
   ...
   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG delete configmap vsphere-ca-certificate \
       --namespace user-cluster1
   

6. 新しい証明書で新しい ConfigMap を作成します。次に例を示します。

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG create configmap \
       --namespace kube-system --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem \
       --output yaml  | kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG apply -f -
   ...
   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG create configmap \
       --namespace user-cluster1 --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem \
       --output yaml  | kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG apply -f -
   

7. 管理コントロール プレーンで、静的 Pod を含むコンテナを再起動します。

   • 管理マスター VM に SSH 接続します。
   • docker restart を実行します。

8. 次に、管理 create-config Secret にある CA 証明書データを更新します。

   • Secret を取得し、出力から data.cfg の値をデコードします。
     

     kubectl get secret create-config -n kube-system -o jsonpath={.data.cfg} | base64 -d > admin-create-config.yaml

     `
   • admincluster.spec.cluster.vsphere.cacertdata の値を新しい vCenter CA 証明書と比較します。
   • 2 つの値が異なる場合は、admin create-config Secret を編集して新しい CA 証明書を追加する必要があります。admin-create-config.yaml ファイルで、base-64 デコードの結果をコピーし、admincluster.spec.cluster.vsphere.cacertdata の値を新しい vCenter CA 証明書に置き換えます。
   • 前の手順の値をエンコードします。cat admin-create-config.yaml | base64 -w0 > admin-create-config.b64
   • create-config Secret を編集し、data.cfg の値をエンコードされた値に置き換えます。
     

     kubectl --kubeconfig ADMIN_KUBECONFIG edit secrets -n kube-system create-config

9. 次に、ユーザー クラスタの create-config Secret の CA 証明書データを更新します。

   create-config Secret を編集し、data.cfg 値を前の手順で作成した base64 エンコード値に置き換えます。次に例を示します。

   kubectl --kubeconfig ADMIN_KUBECONFIG edit secrets -n user-cluster-1 create-config
   

10. ユーザー クラスタ内の次の Pod を削除します。

    • clusterapi-controllers
    • kube-controller-manager
    • kube-apiserver
    • vsphere-csi-controller
    • vsphere-metrics-exporter

    Pod の名前を取得するには、次のコマンドを実行します。

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep clusterapi
    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep kube-controller-manager
    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep kube-apiserver
    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep vsphere-csi-controller
    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --all-namespaces | grep vsphere-metrics-exporter
    

11. 前のステップで検出した Pod を削除します。

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace NAMESPACE \
        delete pod POD_NAME
    

Pod が再起動すると、新しい証明書を使用します。

内部 kubeconfig ファイルを使用して F5 BIG-IP の問題をデバッグする

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

ユーザー クラスタのサイズ変更に失敗する

ユーザー クラスタのサイズ変更が失敗した場合:

1. MachineDeployments とマシンの名前を確認します。

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machinedeployments --all-namespaces
   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces
   

2. ログを表示する MachineDeployment を記述します。

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machinedeployment MACHINE_DEPLOYMENT_NAME
   

3. 新しく作成したマシンでエラーを確認します。

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME
   

クラスタのサイズ変更にアドレスを割り振ることができない

この問題は、ユーザー クラスタのサイズを変更するのに十分な IP アドレスが使用できない場合に発生します。

kubectl describe machine を実行すると、次のエラーが表示されます。

Events:
Type     Reason  Age                From                    Message
----     ------  ----               ----                    -------
Warning  Failed  9s (x13 over 56s)  machineipam-controller  ipam: no addresses can be allocated

この問題を解決するには、クラスタに追加の IP アドレスを割り振ります。次に、影響を受けたマシンを削除します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete machine MACHINE_NAME

Anthos clusters on VMware によって、新しいマシンが作成され、新しく使用可能になった IP アドレスのいずれかが割り当てられます。

十分な数の IP アドレスが割り振られているが、クラスタにマシンを登録できない

この問題は、IP アドレスの競合が存在する場合に発生する可能性があります。たとえば、マシンに指定した IP アドレスがロードバランサで使用されている場合が該当します。

この問題を解決するには、クラスタ IP ブロック ファイルを更新して、マシンのアドレスがクラスタ構成ファイル、またはSeesaw IP ブロック ファイルで指定されたアドレスと競合しないようにします。

管理クラスタの作成またはアップグレードが失敗すると、自動的にスナップショットが作成される

管理クラスタの作成やアップグレードをしようとして、そのオペレーションが失敗した場合、Anthos clusters on VMware では、ブートストラップ クラスタ（管理クラスタの作成やアップグレードに使用される一時的なクラスタ）の外部スナップショットが取得されます。このブートストラップ クラスタのスナップショットは、管理クラスタで gkectl diagnose snapshot コマンドを実行すると実行されるスナップショットと似ていますが、自動的にトリガーされる点が異なります。このブートストラップ クラスタのスナップショットには、管理クラスタの作成やアップグレード プロセスに関する重要なデバッグ情報が含まれています。必要な場合は、Google Cloud サポートにこのスナップショットを提供できます。

アップグレード プロセスが停止する

Anthos clusters on VMware はアップグレード時に、バックグラウンドで Kubernetes drain コマンドを使用します。この drain 手順は、minAvailable: 1 を使用して作成された PodDisruptionBudget（PDB）を持つ唯一のレプリカを含む Deployment によってブロックされます。

その場合は PDB を保存して、クラスタから削除してからアップグレードを試してください。アップグレードが完了したら、PDB を再度追加できます。