以下のセクションでは、GKE On-Prem の使用中に発生する可能性のある問題とその解決方法について説明します。
始める前に
問題のトラブルシューティングを開始する前に、以下のセクションをご確認ください。
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 コントローラのログを調べてデバッグを試すことができます。
kube-systemNamespace で Cluster API コントローラ Pod の名前を確認します。ここで、[ADMIN_CLUSTER_KUBECONFIG] は管理クラスタの kubeconfig ファイルのパスです。kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
Pod のログを開きます。ここで、[POD_NAME] は Pod の名前です。必要に応じて、
grepまたは同様のツールを使用してエラーを検索します。kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager
インストール
管理クラスタのコントロール プレーン ノードの kubeconfig を使用した F5 BIG-IP の問題のデバッグ
GKE On-Prem をインストールすると、管理ワークステーションのホーム ディレクトリに kubeconfig ファイルが生成されます（internal-cluster-kubeconfig-debug という名前）。この 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 にお問い合わせください。
ブートストラップ クラスタのログを使用したデバッグ
インストール時、GKE On-Prem により一時的なブートストラップ クラスタが作成されます。インストールが正常に完了した後、GKE On-Prem によってブートストラップ クラスタが削除され、管理クラスタとユーザー クラスタが残されます。通常、このクラスタを操作する理由はありません。
インストール中に問題が発生し、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]
Anthos 用の認証プラグイン
gcloud anthos auth CLI を最新の状態に保つ
gcloud anthos auth インストールのコンポーネントが、最新バージョン リリースの修正により最新の状態となっていることを確認することで、よくある問題の多くを回避できます。
gcloud anthos auth コマンドには gcloud コア コンポーネントに対するロジックと、個別にパッケージ化された anthos-auth コンポーネントがあるため、検証が必要な部分は 2 つあります。
-
gcloudコア コンポーネント。-
gcloudコア コンポーネントを更新するには、以下を実行します。gcloud components update
-
次のコマンドを実行して、
gcloudインストールが古くないこと、出力された日付が過去 12 日以内であることを確認します。gcloud version
-
-
anthos-authコンポーネント。-
anthos-authコンポーネントを更新するには、以下を実行します。gcloud components install anthos-auth
-
次のコマンドを実行して、
anthos-authインストールが古くないこと、リリースがバージョン v1.1.3 以降であることを確認します。gcloud anthos auth version
-
gcloud の apt-get インストール
gcloud インストールが apt-get を介して管理されているかどうかを確認するには、gcloud
components update コマンドを実行して次のエラーを確認します。
$ gcloud components update ERROR: (gcloud.components.update) You cannot perform this action because the gcloud CLI component manager is disabled for this installation. You can run the following command to achieve the same result for this installation: ...
問題: このインストールでは gcloud CLI コンポーネント マネージャーが無効になっているため、この操作を実行できません。
apt-get を介して管理されるインストールでは、上述の gcloud components コマンドは直接機能せず、上述の類似したエラー メッセージが表示されます。ただし、gcloud components update コマンドと gcloud components install anthos-auth コマンドを実行すると、インストールの更新を実行できる特定の apt-get コマンドが出力されます。
gkectl create-login-config の実行エラー
問題 1:
- 現象
gkectl create-login-configを実行すると、次のエラーが発生します。Error getting clientconfig using [user_cluster_kubeconfig]
- 考えられる原因
このエラーは、
gkectl create-login-configに渡された kubeconfig ファイルがユーザー クラスタ用ではないか、ClientConfig CRD がクラスタの作成中に起動しなかったことを意味します。- 解決策
次のコマンドを実行して、ClientConfig CRD がクラスタに存在するかどうかを確認します。
kubectl --kubeconfig [user_cluster_kubeconfig] get clientconfig default -n kube-public
問題 2:
- 現象
gkectl create-login-configを実行すると、次のエラーが発生します。error merging with file [merge_file] because [merge_file] contains a cluster with the same name as the one read from [kubeconfig]. Please write to a new output file
- 考えられる原因
各ログイン構成ファイルには一意のクラスタ名を指定する必要があります。このエラーが表示される場合、ログイン構成データを書き込むファイルの名前に、宛先ファイルに存在するクラスタ名が含まれています。
- 解決策
新しい
--outputファイルに書き込みます。次の点にご注意ください。--outputが指定されていない場合、ログイン構成データは、デフォルトで現在のディレクトリにあるkubectl-anthos-config.yamlというファイルに書き込まれます。--outputがすでに存在する場合、このコマンドは新しいログイン構成を--outputにマージしようとします。
gcloud anthos auth
login の実行エラー
問題 1:
- 現象
認証プラグインと生成されたログイン構成 YAML ファイルを使用して
loginを実行すると失敗します。- 考えられる原因
OIDC 構成の詳細にエラーがある可能性があります。
- 解決策
管理者に依頼して OIDC クライアントの登録を確認します。
問題 2:
- 現象
プロキシが HTTPS トラフィック用に構成されている場合、
gcloud anthos auth loginコマンドを実行するとエラー メッセージにproxyconnect tcpが表示されます。表示されるメッセージ タイプの例はproxyconnect tcp: tls: first record does not look like a TLS handshakeです。- 考えられる原因
https_proxyまたはHTTPS_PROXY環境変数の構成にエラーがある可能性があります。環境変数にhttps://が指定されている場合は、SOCK5 などの他のプロトコルを使用して HTTPS 接続を処理するようにプロキシが構成されると、GoLang HTTP クライアント ライブラリが失敗する可能性があります。- 解決策
https://接頭辞を省略するようにhttps_proxy環境変数とHTTPS_PROXY環境変数を変更します。Windows で、システム環境変数を変更します。たとえば、https_proxy環境変数の値をhttps://webproxy.example.com:8000からwebproxy.example.com:8000に変更します。
gcloud anthos auth login によって生成された kubeconfig を使用してクラスタにアクセスできない
- 現象
Unauthorized エラー
gcloud anthos auth loginで生成された kubeconfig を使用してクラスタにアクセスする際に Unauthorized エラーが発生した場合は、apiserver でユーザーを認証できないことを意味します。- 考えられる原因
- 適切な RBAC が指定されていないか、RBAC が正しくありません。また、クラスタの OIDC 構成にエラーがある可能性もあります。
- 解決策
- 問題を解決するには、次の方法をお試しください。
kubeconfig から
id-tokenを解析します。ログイン コマンドで生成された kubeconfig ファイルで、
id-tokenをコピーします。kind: Config … users: - name: … user: auth-provider: config: id-token: [id-token] …手順に沿って jwt-cli をインストールし、次のコマンドを実行します。
jwt [id-token]
OIDC 構成の検証
クラスタの作成に使用された
config.yamlのoidcセクションには、groupとusernameというフィールドがあります。これらのフィールドは、apiserver の--oidc-group-claimフラグと--oidc-username-claimフラグの設定に使用されます。apiserver にトークンが渡されると、その group-claim と username-claim を検索し、対応するグループまたはユーザーに適切な権限があることを確認します。config.yamlのoidcセクションのgroupとuserに設定されたクレームがid-tokenに存在することを確認します。適用されている RBAC を確認します。
username-claim で指定されたユーザー、または前の手順で group-claim にリストされたグループのいずれかに、適切な権限を持つ RBAC があることを確認します。RBAC 内のユーザーまたはグループの名前には、
usernameprefixまたはgroupprefixという接頭辞が付いています。この接頭辞はconfig.yamlのoidcセクションに指定されています。usernameprefixが空白で、usernameがemail以外の値の場合、接頭辞はデフォルトのissuerurl#になります。ユーザー名の接頭辞を無効にするには、usernameprefixを-に設定する必要があります。ユーザーとグループの接頭辞の詳細については、oidc 仕様の入力をご覧ください。
現在、Kubernetes API サーバーはエスケープ文字としてバックスラッシュを使用します。このため、ユーザーまたはグループの名前に
\\が含まれていると、API サーバーはid_tokenを解析するときに 1 つの\として読み取ります。このユーザーまたはグループに適用される RBAC にはバックスラッシュを 1 つだけ含める必要があります。そうしないと、Unauthorizedエラーが発生することがあります。例:
config.yaml:oidc: issuerurl: … username: "unique_name" usernameprefix: "-" group: "group" groupprefix: "oidc:" ...id_token:{ ... "email": "cluster-developer@example.com", "unique_name": "EXAMPLE\\cluster-developer", "group": [ "Domain Users", "EXAMPLE\\developers" ], ... }次の RBAC によって、このユーザーにクラスタ管理者権限が付与されます（名前フィールドでダブル スラッシュではなく単一スラッシュが使用されている点に注意してください）。
Group RBAC:apiVersion: kind: metadata: name: example-binding subjects: - kind: Group name: "oidc:EXAMPLE\developers" apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.ioUser RBAC:apiVersion: kind: metadata: name: example-binding subjects: - kind: User name: "EXAMPLE\cluster-developer" apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.ioAPI サーバーのログを確認する
id-tokenを渡したときに、kube apiserver で構成された OIDC プラグインが正常に起動していないと、API サーバーから Unauthorized エラーが返されます。API サーバーで OIDC プラグインに問題があったかどうかを確認するには、次のコマンドを実行します。kubectl --kubeconfig=[admin_cluster_kubeconfig] logs statefulset/kube-apiserver -n [user_cluster_name]
- 現象
サーバーに接続できない: Get {DISCOVERY_ENDPOINT}: x509: 証明書に署名した認証局が不明
- 考えられる原因
kubeconfig の更新トークンが期限切れです。
- 解決策
loginコマンドをもう一度実行します。
Google Cloud コンソールのログイン
Google Cloud コンソールでログインしようとしたときに、発生する可能性がある一般的なエラーは次のとおりです。
ログイン時に「URL が見つかりません」というエラー メッセージが表示される
- 現象
Google Cloud コンソールから GKE On-prem ID プロバイダにアクセスできません。
- 考えられる原因
Google Cloud コンソールから GKE On-prem ID プロバイダにアクセスできません。
- 解決策
問題を解決するには、次の方法をお試しください。
-
useHTTPProxyをtrueに設定する公共のインターネット経由で IDP に到達できない場合は、OIDC HTTP プロキシを有効にして Google Cloud コンソール経由でログインする必要があります。
config.yamlのoidcセクションで、usehttpproxyをtrueに設定します。すでにクラスタを作成済みで、プロキシを有効にする場合は、ClientConfig CRD を直接編集できます。$ kubectl edit clientconfig default -n kube-publicを実行してuseHTTPProxyをtrueに変更します。 useHTTPProxyがすでにtrueに設定されているHTTP プロキシが有効になっていてもこのエラーが表示される場合は、プロキシの起動に問題があった可能性があります。プロキシのログを取得するには、
$ kubectl logs deployment/clientconfig-operator -n kube-systemを実行します。IDP に既知の CA がある場合でも、HTTP プロキシを開始するには、config.yamlのoidcセクションにcapathフィールドを指定する必要があります。同意を求める IDP プロンプト
認可サーバーから同意を求めるプロンプトが表示されたときに、追加パラメータ
prompt=consentを指定しないと、このエラーが発生することがあります。$ kubectl edit clientconfig default -n kube-publicを実行してprompt=consentをextraparamsに追加し、再度ログインを試みます。RBAC 構成に誤りがある
まだ行っていない場合は、Anthos 用認証プラグインを使用して認証を試みます。プラグインでログイン認可エラーが表示された場合は、トラブルシューティング手順に従ってプラグインの問題を解決して、Google Cloud コンソールから再度ログインしてみてください。
ログアウトしてからログインし直す
たとえば、ストレージ サービスの一部の設定が変更された場合は、明示的にログアウトする必要があります。クラスタの詳細ページに移動し、[ログアウト] をクリックして、再度ログインします。
管理ワークステーション
opensslで管理ワークステーション OVA を検証できない- 現象
管理ワークステーションの OVA ファイルに対して
openssl dgstを実行してもVerified OKが返されない- 考えられる原因
OVA ファイルに問題があるため、正常な検証ができません。
- 解決策
管理ワークステーション OVA をダウンロードするの説明に従って、管理ワークステーションの OVA をもう一度ダウンロードしてデプロイしてみてください。問題が解決しない場合は、Google にお問い合わせください。
Connect
ユーザー クラスタを登録できない
ユーザー クラスタの登録で問題が発生した場合は、Google にお問い合わせください。
アルファ版の登録解除中に作成されたクラスタ
Connect のドキュメントでユーザー クラスタの登録をご覧ください。
ストレージ
Volume を接続できない
現象
gkectl diagnose clusterの出力が次のようになります。Checking cluster object...PASS Checking machine objects...PASS Checking control plane pods...PASS Checking gke-connect pods...PASS Checking kube-system pods...PASS Checking gke-system pods...PASS Checking storage...FAIL PersistentVolume pvc-776459c3-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-776459c3-d350-11e9-9db8-e297f465bc84.vmdk" IS attached to machine "gsl-test-user-9b46dbf9b-9wdj7" but IS NOT listed in the Node.Status 1 storage errors1 つ以上の Pod が
ContainerCreating状態で停止し、次のような警告が表示されます。Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedAttachVolume 6s (x6 over 31s) attachdetach-controller AttachVolume.Attach failed for volume "pvc-776459c3-d350-11e9-9db8-e297f465bc84" : Failed to add disk 'scsi0:6'.
考えられる原因
仮想ディスクが誤った仮想マシンにアタッチされている場合は、Kubernetes 1.12 の問題 #32727 が原因であることが考えられます。
解決策
仮想ディスクが誤った仮想マシンにアタッチされている場合は、手動での切断が必要になる場合があります。
- ノードをドレインします。ノードを安全にドレインするをご覧ください。たとえば、
kubectl drainコマンドに--ignore-daemonsetsと--delete-local-dataフラグを指定できます。 - VM の電源を切ります。
- vCenter で VM のハードウェア構成を編集し、Volume を削除します。
- VM の電源を入れます。
- ノードの閉鎖を解除します。
Volume が失われる
現象
gkectl diagnose clusterの出力が次のようになります。Checking cluster object...PASS Checking machine objects...PASS Checking control plane pods...PASS Checking gke-connect pods...PASS Checking kube-system pods...PASS Checking gke-system pods...PASS Checking storage...FAIL PersistentVolume pvc-52161704-d350-11e9-9db8-e297f465bc84: virtual disk "[datastore_nfs] kubevols/kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk" IS NOT found 1 storage errors1 つ以上の Pod が
ContainerCreating状態で停止し、次のような警告が表示されます。Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedAttachVolume 71s (x28 over 42m) attachdetach-controller AttachVolume.Attach failed for volume "pvc-52161704-d350-11e9-9db8-e297f465bc84" : File []/vmfs/volumes/43416d29-03095e58/kubevols/ kubernetes-dynamic-pvc-52161704-d350-11e9-9db8-e297f465bc84.vmdk was not found
考えられる原因
VMDK ファイルに関して「見つかりません」というエラーが表示される場合は、仮想ディスクが完全に削除されている可能性があります。これは、仮想ディスクまたはアタッチしている仮想マシンを手動で削除した場合に発生します。この問題を回避するには、ユーザー クラスタのサイズ変更とクラスタのアップグレードの説明に従って仮想マシンを管理します。
解決策
仮想ディスクが完全に削除されている場合は、関連する Kubernetes リソースを手動でクリーンアップする必要があります。
kubectl delete pvc [PVC_NAME].を実行して、PV を参照している PVC を削除します。kubectl delete pod [POD_NAME].を実行して、PVC を参照している Pod を削除します。- 手順 2 を繰り返します（Kubernetes の問題 74374 をご覧ください）。
vSphere CSI Volume の接続解除に失敗する
現象
ContainerCreatingフェーズで Pod が停止し、FailedAttachVolumeの警告が表示された場合は、別のノードにおける接続解除時の障害の発生が原因であることが考えられます。次のコマンドを実行して、CSI の切断エラーを見つけます。
kubectl get volumeattachments -o=custom-columns=NAME:metadata.name,DETACH_ERROR:status.detachError.message
出力は次のようになります。
NAME DETACH_ERROR csi-0e80d9be14dc09a49e1997cc17fc69dd8ce58254bd48d0d8e26a554d930a91e5 rpc error: code = Internal desc = QueryVolume failed for volumeID: "57549b5d-0ad3-48a9-aeca-42e64a773469". ServerFaultCode: NoPermission csi-164d56e3286e954befdf0f5a82d59031dbfd50709c927a0e6ccf21d1fa60192d
csi-8d9c3d0439f413fa9e176c63f5cc92bd67a33a1b76919d42c20347d52c57435c csi-e40d65005bc64c45735e91d7f7e54b2481a2bd41f5df7cc219a2c03608e8e7a8 考えられる原因
CNS > Searchable権限が vSphere ユーザーに付与されていません。解決策
CNS > Searchable権限を vCenter ユーザー アカウントに追加します。接続解除オペレーションは、成功するまで自動的に再試行されます。アップグレード
アップグレード中のダウンタイムについて
リソース 説明 管理クラスタ 管理クラスタが停止しても、ユーザー クラスタのコントロール プレーンとワークロードは、ダウンタイムの原因となった障害の影響を受けない限り引き続き実行されます。
ユーザー クラスタのコントロール プレーン 通常、ユーザー クラスタ コントロール プレーンには目立ったダウンタイムはありません。ただし、Kubernetes API サーバーへの長時間実行の接続が切断され、再確立する必要がある場合があります。この場合、API 呼び出し元は、接続が確立するまで再試行する必要があります。最悪のケースでは、アップグレード中に最大 1 分間のダウンタイムが発生することがあります。
ユーザー クラスタノード アップグレードでユーザー クラスタ ノードの変更が必要な場合、GKE On-Prem はノードをローリング方式で再作成し、これらのノードで実行されている Pod を再スケジュールします。ワークロードへの影響を防ぐには、適切な PodDisruptionBudgets とアンチ アフィニティ ルールを構成します。
管理クラスタのアップグレード前に証明書の更新が必要になる場合がある
管理クラスタのアップグレード プロセスを開始する前に、管理クラスタの証明書が現在有効であることを確認し、有効でない場合は更新する必要があります。
管理クラスタの証明書の更新プロセス
開始する前に、管理ワークステーションに OpenSSL がインストールされていることを確認してください。
KUBECONFIG変数を設定します。KUBECONFIG=ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG
ABSOLUTE_PATH_ADMIN_CLUSTER_KUBECONFIG は、管理クラスタの kubeconfig ファイルの絶対パスに置き換えます。
管理マスターノードの IP アドレスと SSH 認証鍵を取得します。
kubectl --kubeconfig "${KUBECONFIG}" get secrets -n kube-system sshkeys \ -o jsonpath='{.data.vsphere_tmp}' | base64 -d > \ ~/.ssh/admin-cluster.key && chmod 600 ~/.ssh/admin-cluster.key export MASTER_NODE_IP=$(kubectl --kubeconfig "${KUBECONFIG}" get nodes -o \ jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \ --selector='node-role.kubernetes.io/master')証明書が期限切れでないかを確認します。
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" \ "sudo kubeadm alpha certs check-expiration"証明書が期限切れの場合は、管理クラスタをアップグレードする前に証明書を更新する必要があります。
古い証明書をバックアップします。
これは省略可能ですが、推奨される手順です。
# ssh into admin master ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" # on admin master sudo tar -czvf backup.tar.gz /etc/kubernetes logout # on worker node sudo scp -i ~/.ssh/admin-cluster.key \ ubuntu@"${MASTER_NODE_IP}":/home/ubuntu/backup.tar.gz .kubeadm を使用して証明書を更新します。
# ssh into admin master ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}" # on admin master sudo kubeadm alpha certs renew all管理マスターノードを再起動します。
# on admin master cd /etc/kubernetes sudo mkdir tempdir sudo mv manifests/*.yaml tempdir/ sleep 5 echo "remove pods" # ensure kubelet detect those change remove those pods # wait until the result of this command is empty sudo docker ps | grep kube-apiserver # ensure kubelet start those pods again echo "start pods again" sudo mv tempdir/*.yaml manifests/ sleep 30 # ensure kubelet start those pods again # should show some results sudo docker ps | grep -e kube-apiserver -e kube-controller-manager -e kube-scheduler -e etcd # clean up sudo rm -rf tempdir logout
管理証明書が期限切れになった場合は管理クラスタの kubeconfig ファイルも期限切れになるため、有効期限が切れる前にこのファイルをバックアップする必要があります。
管理クラスタの kubeconfig ファイルをバックアップします。
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
"sudo cat /etc/kubernetes/admin.conf" > new_admin.conf vi "${KUBECONFIG}"kubeconfig の
client-certificate-dataとclient-key-dataを作成したnew_admin.confファイルのclient-certificate-dataとclient-key-dataに置き換えます。
更新された証明書を検証し、kube-apiserver の証明書を検証します。
証明書の有効期限を確認します。
ssh -i ~/.ssh/admin-cluster.key ubuntu@"${MASTER_NODE_IP}"
"sudo kubeadm alpha certs check-expiration"kube-apiserver の証明書を確認します。
# Get the IP address of kube-apiserver cat $KUBECONFIG | grep server # Get the current kube-apiserver certificate openssl s_client -showcerts -connect
:
| sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'
> current-kube-apiserver.crt # check expiration date of this cert openssl x509 -in current-kube-apiserver.crt -noout -enddate
ユーザー クラスタのサイズ変更
ユーザー クラスタのサイズ変更に失敗する
- 現象
ユーザー クラスタのサイズ変更操作が失敗します。
- 考えられる原因
サイズ変更操作が失敗する原因はいくつかあります。
- 解決策
サイズ変更が失敗する場合は、次の手順に従います。
クラスタの MachineDeployment ステータスをチェックして、イベントやエラー メッセージがあるかどうかを確認します。
kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME]
新しく作成したマシンにエラーがあるかどうかを確認します。
kubectl describe machine [MACHINE_NAME]
エラー: 「アドレスを割り振ることができません」
- 現象
ユーザー クラスタのサイズを変更すると、
kubectl describe machine [MACHINE_NAME]が次のエラーを表示します。Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning Failed 9s (x13 over 56s) machineipam-controller ipam: no addresses can be allocated
- 考えられる原因
ユーザー クラスタで使用可能な IP アドレスが不足しています。
- 解決策
クラスタに追加の IP アドレスを割り振ります。次に、影響を受けたマシンを削除します。
kubectl delete machine [MACHINE_NAME]
クラスタが正しく構成されている場合は、IP アドレスを使用して代替マシンが作成されます。
十分な数の IP アドレスが割り振られているが、クラスタにマシンを登録できない
- 現象
ネットワークには十分なアドレスが割り振られていますが、ユーザー クラスタへのマシンの登録が失敗します。
- 考えられる原因
IP が競合している可能性があります。対象の IP が別のマシンまたはロードバランサによって使用されている場合があります。
- 解決策
登録に失敗するマシンの IP アドレスが使用されていないことを確認します。競合がある場合は、環境内の競合を解消する必要があります。
vSphere
govcを使用したデバッグvSphere に固有の問題が発生した場合、
govcを使用してトラブルシューティングを行うことができます。たとえば、vCenter ユーザー アカウントの権限とアクセスを簡単に確認し、vSphere ログを収集できます。vCenter 証明書の変更
vCenter サーバーを評価モードまたはデフォルト設定モードで実行し、TLS 証明書が生成されている場合、その証明書は後で変更されることがあります。証明書が変更された場合は、実行中のクラスタに新しい証明書を通知する必要があります。
新しい vCenter 証明書を取得し、ファイルに保存します。
true | openssl s_client -connect [VCENTER_IP_ADDRESS]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem
クラスタごとに、各クラスタの vSphere と vCenter の証明書を含む ConfigMap を削除し、新しい証明書を含む新しい ConfigMap を作成します。例:
kubectl --kubeconfig kubeconfig delete configmap vsphere-ca-certificate -n kube-system
kubectl --kubeconfig kubeconfig delete configmap vsphere-ca-certificate -n user-cluster1
kubectl --kubeconfig kubeconfig create configmap -n user-cluster1 --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem -o yaml | kubectl --kubeconfig kubeconfig apply -f -
kubectl --kubeconfig kubeconfig create configmap -n kube-system --dry-run vsphere-ca-certificate --from-file=ca.crt=vcenter.pem -o yaml | kubectl --kubeconfig kubeconfig apply -f -
各クラスタの Clusterapi-Controllers Pod を削除します。Pod が再起動すると、新しい証明書の使用が開始されます。例:
kubectl --kubeconfig kubeconfig -n kube-system get pods
kubectl --kubeconfig kubeconfig -n kube-system delete pod clusterapi-controllers-...
その他
Terraform の vSphere プロバイダのセッション数の上限
GKE On-Prem は Terraform の vSphere プロバイダを使用して、vSphere 環境で VM を起動します。プロバイダのセッション数は最大 1,000 です。現在の実装では、使用後にアクティブなセッションが終了しません。実行中のセッションが多すぎると、503 エラーが発生する可能性があります。
セッションは 300 秒後に自動的に終了します。
- 現象
実行中のセッションが多すぎると、次のエラーが発生します。
Error connecting to CIS REST endpoint: Login failed: body: {"type":"com.vmware.vapi.std.errors.service_unavailable","value": {"messages":[{"args":["1000","1000"],"default_message":"Sessions count is limited to 1000. Existing sessions are 1000.", "id":"com.vmware.vapi.endpoint.failedToLoginMaxSessionCountReached"}]}}, status: 503 Service Unavailable- 考えられる原因
環境内で実行されている Terraform プロバイダのセッションが多すぎます。
- 解決策
現時点で、これは意図したとおりに機能しています。セッションは 300 秒後に自動的に終了します。詳細については、GitHub の問題 #618 をご覧ください。
Docker 用のプロキシの使用:
oauth2: cannot fetch token- 現象
プロキシの使用中に次のエラーが発生します。
oauth2: cannot fetch token: Post https://oauth2.googleapis.com/token: proxyconnect tcp: tls: oversized record received with length 20527
- 考えられる原因
HTTP ではなく HTTPS プロキシを指定した可能性があります。
- 解決策
Docker の構成で、プロキシ アドレスを
https://ではなくhttp://に変更します。
ライセンスが有効であることを確認する
特に試用版ライセンスを使用している場合は、ライセンスが有効であることを確認してください。F5、ESXi ホスト、または vCenter ライセンスの有効期限が切れた場合、予期しないエラーが発生することがあります。
-