このページでは、Anthos のプライベート モードに関する既知の問題とともに、これらの問題を回避する方法または復旧する方法を記載します。
管理クラスタの作成は、引き続き waiting for node update jobs で行われます。
通常、管理クラスタの作成には約 30 分かかります。クラスタが「ノード更新ジョブの待機」フェーズで長時間先に進まない場合は、Ctrl + C でプロセスを終了できます。このフェーズは、インストールの最後のステップです。プロセスを終了しても、インストールには影響しません。
ユーザー クラスタの作成が停止したままの状態になる
ユーザー クラスタの作成には、通常 10～30 分ほど要します。クラスタが処理中のまま進まない場合は、次のコマンドを使用してクラスタの作成状況を確認できます。
kubectl get pods -n cluster-USER_CLUSTER --kubeconfig=ADMIN_KUBECONFIG
kubectl get Cluster -n cluster-USER_CLUSTER -o yaml --kubeconfig=ADMIN_KUBECONFIG
複数のコントロール プレーン ノードを持つ管理クラスタのアップグレードが先に進まない
管理クラスタのアップグレードは、コントロール プレーン ノードのアップグレードで先に進まなくなる場合があります。upgrade コマンドが「Waiting for upgrade to complete... Upgrading <control plane node IP>」から動かなくなります。
この問題は、次のすべての条件を満たして構成された場合に限り管理クラスタに影響します。
構成された限定公開レジストリは、プライベート認証局によって署名された証明書を使用します。
管理クラスタが、複数のコントロール プレーン ノードで構成されている。たとえば、高可用性を目的として構成されている場合などです。
コントロール プレーン ノードに
dockerがインストールされている。
この問題は、構成の誤りにより、間違った場所にあるレジストリ認証局ファイルが取得される際に発生します。この問題を回避するには、各ノードに認証局ファイルを手動で配布する必要があります。たとえば、管理ワークステーションから次のスクリプトを実行します。
#!/bin/bash
# Docker login to generate the $HOME/.docker/config.json file
docker login REGISTRY_HOST
# List the IP addresses for all the control plane nodes, separated by whitespace.
IPs=( NODE_IPS_SEPARATED_BY_SPACE )
for ip in "${IPs[@]}"; do
# Copy the docker config over to the nodes.
scp $HOME/.docker/config.json USER_NAME@${ip}:docker-config.json
# Fix the image pull credentials issue
ssh USER_NAME@${ip} "sudo mkdir -p /root/.docker && sudo cp docker-config.json /root/.docker/config.json"
# Fix the cert issue, only needed for private registry with self-signed certs.
ssh USER_NAME@${ip} "sudo mkdir -p /etc/docker/certs.d && sudo cp -r /etc/containerd/certs.d/REGISTRY_HOST /etc/docker/certs.d/"
done
USER_NAME と REGISTRY_HOST は、管理クラスタ構成ファイルに構成されている値に置き換えます。
プライベート IP アクセスに対する 400 認可エラー
Open ID Connect（OIDC）認証の設定後、Management Center へのアクセスに引き続き IP アドレスを使用すると、認証ページにリダイレクトされ、プライベート IP アクセスの認可に関するエラーが表示されます。例:
プラットフォームへのアクセスに IP アドレスではなく構成されたドメイン名を使用すると、actl platform management-center describe を実行してアドレス全体を取得できます。リダイレクト コールバックには、ドメインが必須です。ドメインはプライベート アドレスを指すことができます。
初期のプラットフォーム管理者の作成で 500 HTTP エラー レスポンス
OIDC プロファイルをクラスタに適用する際に、プロファイルのユーザー名またはグループ プレフィックスに「/」文字が含まれている場合は、[送信] をクリックすると、500 HTTP 失敗レスポンスが返される場合があります。
この問題を解決するには、プロファイルを削除し、ユーザー名とグループ プレフィックスに「/」を付けずに新しいプロファイルを作成して、新しいプロファイルをクラスタに適用してみます。
RBAC: アクセス拒否
プラットフォーム管理者アカウントでのログイン後に RBAC: access denied メッセージが表示されている場合は、OIDC 設定にエラーが含まれている可能性があります。認証構成のリセットをご覧ください。
レジストリ ミラー構成が使用された場合にプライベート レジストリからイメージを使用する
レジストリ ミラー構成を使用してクラスタを設定している場合は、プライベート レジストリからのイメージを直接使用する際にイメージパスをメモしておきます。
たとえば、管理クラスタが、次のミラー構成ファイルを使用して作成されるとします。
registryMirrors:
- endpoint: https://10.200.0.2/v2/library
イメージは、docker push 10.200.0.2/library/test-image:test-tag によって非公開レジストリにアップロードされます。Deployment や Pod を作成するときに、イメージ 10.200.0.2/library/test-image:test-tag をそのまま使用することはできません。これは、ノードの containerd 構成ファイル（/etc/containerd/config.toml）が、10.200.0.2/library からのすべてのイメージの pull をミラーリングするように構成されているためです。それで、containerd は 10.200.0.2/library/library/test-image:test-tag からイメージを pull しようとします。この問題を回避するには、次の手順のいずれかを試してください。
- エンドポイント
docker push 10.200.0.2/library/library/test-image:test-tagの配下にイメージを push する - イメージパス
10.200.0.2/test-image:test-tagを使用する
OIDC が設定されている場合に、管理センターを 0.8 から 0.9 にアップグレードできない
OIDC が設定されている場合、管理センターを 0.8 から 0.9 にアップグレードすると、次のエラー メッセージで失敗します。
level=fatal msg="Unable to initialize options: unable to resolve management center cluster: The given \"management center\" cluster \"admin-admin@admin\" does not appear to be a valid management center cluster. Did you choose the right cluster?\nunable to list DomainIDPMapping objects: the server could not find the requested resource"
この問題を回避するには、DomainIDPMapping CRD を使用してファイルを作成します。
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
annotations:
controller-gen.kubebuilder.io/version: v0.4.0
creationTimestamp: null
name: domainidpmappings.managementcenter.anthos.cloud.google.com
spec:
group: managementcenter.anthos.cloud.google.com
names:
kind: DomainIDPMapping
listKind: DomainIDPMappingList
plural: domainidpmappings
singular: domainidpmapping
scope: Cluster
versions:
- name: v1alpha1
schema:
openAPIV3Schema:
description: DomainIDPMapping is the Schema for the domainidpmappings API
properties:
apiVersion:
description: 'APIVersion defines the versioned schema of this representation
of an object. Servers should convert recognized schemas to the latest
internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
type: string
kind:
description: 'Kind is a string value representing the REST resource this
object represents. Servers may infer this from the endpoint the client
submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
type: string
metadata:
type: object
spec:
description: DomainIDPMappingSpec is the struct that contains the mapping
from the domain to the authentication method name specified in the AIS
ClientConfig.
properties:
authMethodName:
description: AuthMethodName is the name of the authentication method
configured in the AIS ClientConfig.
type: string
domainName:
description: DomainName is the domain used to serve the Anthos web
endpoints. The domain should not include the protocol such as http
or https. Wild cards are not supported in the domain name.
type: string
required:
- authMethodName
- domainName
type: object
type: object
served: true
storage: true
status:
acceptedNames:
kind: ""
plural: ""
conditions: []
storedVersions: []
CRD を適用します。
kubectl --kubeconfig=ADMIN_KUBECONFIG apply -f domainIDPMappingCRD.yaml
EnvoyFilter Namespace と oauth2-proxy Namespace を削除します。
kubectl --kubeconfig=ADMIN_KUBECONFIG delete envoyfilter istio-ingressgateway -n istio-system
kubectl --kubeconfig=ADMIN_KUBECONFIG delete namespace oauth2-proxy
接頭辞 anthos-log-forwarder を持つ Pod のイメージの pull でエラーが発生する
クラスタのインストール時に --private-registry が有効にされていると、anthos-log-forwarder パス内の initContainer が使用するイメージパスは、--private-registry で指定されたパスで上書きされません。これは管理クラスタでのみ発生します。
たとえば、管理クラスタで次のエラーが発生する場合です。
kubectl -n kube-system get pods --selector=app=anthos-log-forwarder
anthos-log-forwarder-2n96b 0/1 Init:ErrImagePull 0 16s
anthos-log-forwarder-8fxm8 0/1 Init:ErrImagePull 0 16s
anthos-log-forwarder-bh7rb 0/1 Init:ImagePullBackOff 0 16s
この問題の影響を受けるのは、--private-registry が設定された管理クラスタに限られます。この問題は、次のリリースで修正される予定です。
Pod の接続障害とリバースパス フィルタリング
Anthos プライベート モードは、ソースの検証を無効にするために、ノードでリバースパス フィルタリングを構成します（net.ipv4.conf.all.rp_filter=0）。rp_filter 設定を 1 または 2 に変更すると、ノード外の通信タイムアウトのために Pod は失敗します。
リバースパス フィルタリングは、IPv4 構成フォルダ（net/ipv4/conf/all）内の rp_filter ファイルで設定されています。この値は、sysctl（/etc/sysctl.d/60-gce-network-security.conf などのネットワーク セキュリティ構成ファイル内でリバースパス フィルタリング設定を格納する）によってオーバーライドされる場合もあります。
Pod の接続を復元するには、net.ipv4.conf.all.rp_filter を手動で 0 に戻すか、anetd Pod を再起動して net.ipv4.conf.all.rp_filter を 0 に戻します。anetd Pod を再起動するには、次のコマンドを使用して anetd Pod を見つけて削除します。新しい anetd Pod が代わりに開始されます。
kubectl get pods -n kube-system
kubectl delete pods -n kube-system ANETD_XYZ
ANETD_XYZ は、anetd Pod の名前で置き換えます。
アップグレード後に、[マシン] ページにマシンが表示されない
anthos-cluster-operator Pod を再起動します。
kubectl --kubeconfig ADMIN_KUBECONFIG delete pods -l control-plane=anthos-cluster-operator -n kube-system
アップグレード後にユーザー クラスタを編集できない
anthos-cluster-operator Pod を再起動します。
kubectl --kubeconfig ADMIN_KUBECONFIG delete pods -l control-plane=anthos-cluster-operator -n kube-system