このページには、切断モードで実行される Anthos の既知の問題と、これらの問題の回避方法や復旧方法が記載されています。
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 Management Center コンソールにアクセスするときのリダイレクト ループ
ID プロバイダを設定し、その ID プロバイダを使用してログインした後、Management Center コンソールへのブラウザからのアクセスでリダイレクト ループが発生している場合は、OIDC の設定が間違っている可能性があります。認証構成のリセットをご覧ください。
通常、これは、ユーザー名のクレームまたはグループのクレームが、リクエストされた OIDC スコープに存在しない場合に発生します。OIDC プロバイダの JWT をチェックして、ID プロバイダの設定時に正しいユーザー名のクレームまたはグループのクレームが使用されていることを確認します。
OIDC を構成する際には、クライアント ID が一意である必要があります
この問題は、OIDC プロバイダで正常に認証された後、リダイレクト ループで発生することがあります。ID プロバイダの構成を調べて、同じクライアント ID を使用している他の ID プロバイダがあるかどうかを確認します。
KUBECONFIG=${ADMIN_KUBECONFIG} kubectl get clientconfig -n kube-public default -oyaml
重複するクライアント ID がある場合は、ID プロバイダに新しいクライアント ID を作成するよう依頼します。
認証トークンの有効期限が切れた後にウェブページを手動で更新する
エラーを示すウェブページが表示されていて、最後のログインから少なくとも 1 時間（OIDC プロバイダの設定によってはそれ以下）経過している場合は、ブラウザーの更新ボタンをクリックして、新しい認証トークンでウェブページをハード リフレッシュします。OIDC プロバイダから再度ログインを求められることがあります。
管理クラスタの作成中にエラーが発生する
kind クラスタ内の kube-proxy Pod が起動しない管理クラスタの作成に関する問題がある場合は、管理ワークステーションで nf_conntrack_max を手動で設定してみてください。次に例を示します。
sudo sysctl -w net.netfilter.nf_conntrack_max=131072