ベアメタル版 Anthos クラスタの既知の問題

インストール

コントロール グループ v2 の非互換性

コントロール グループ v2(cgroup v2)は、ベアメタル版 Anthos クラスタ 1.6 と互換性がありません。Kubernetes 1.18 では cgroup v2 はサポートされていません。また、Docker は、20.10 以降は試験運用版のサポートのみを提供しています。systemd はバージョン 247.2-2 では、デフォルトで cgroup v2 に切り替えられました。/sys/fs/cgroup/cgroup.controllers の存在は、システムで cgroup v2 が使用されていることを意味します。

ベアメタル版 Anthos クラスタ 1.6.2 を起動すると、プリフライト チェックにより、クラスタマシンで cgroup v2 が使用されていないことが確認されます。

インストール中の無害なエラー メッセージ

高可用性(HA)クラスタのインストール中に、etcdserver leader change に関するエラーが表示されることがあります。このエラー メッセージは無害なもので、無視してかまいません。

クラスタのインストールに bmctl を使用すると、create-cluster.log の一番最後に Log streamer failed to get BareMetalMachine のログメッセージが表示されます。このエラー メッセージは無害なもので、無視して構いません。

クラスタ作成ログを調査すると、クラスタの登録または Webhook の呼び出しに関する一時的なエラーが見つかる場合があります。インストールではこうした操作を成功するまで再試行するため、これらのエラーは無視しても問題ありません。

プリフライト チェックとサービス アカウント認証情報

管理クラスタまたはハイブリッド クラスタによってトリガーされるインストール(つまり、ユーザー クラスタなど、bmctl で作成されていないクラスタ)では、プリフライト チェックは、Google Cloud Platform サービス アカウントの認証情報や、関連付けられている権限を検証しません。

アプリケーションのデフォルト認証情報と bmctl

bmctl は、クラスタ オペレーションのロケーションの値が global に設定されていないときに、アプリケーションのデフォルト認証情報(ADC)を使用して cluster spec でその値を検証します。

ADC を機能させるには、GOOGLE_APPLICATION_CREDENTIALS 環境変数をサービス アカウント認証情報ファイルに向けるか、gcloud auth application-default login を実行する必要があります。

Docker サービス

クラスタ ノードマシンで、Docker 実行可能ファイルが PATH 環境変数に存在し、Docker サービスが有効になっていない場合は、プリフライト チェックで不合格になり、Docker service is not active が報告されます。このエラーを修正するには、Docker を削除するか、Docker サービスを有効にします。

アップグレードと更新

ベアメタル版 Anthos クラスタ 1.6.x リリースでのアップグレードはできません。

.manifests ディレクトリがない場合、bmctl update cluster は失敗します。

bmctl update cluster を実行する前に .manifests ディレクトリが削除された場合、コマンドは次のようなエラーで失敗します。

Error updating cluster resources.: failed to get CRD file .manifests/1.9.0/cluster-operator/base/crd/bases/baremetal.cluster.gke.io_clusters.yaml: open .manifests/1.9.0/cluster-operator/base/crd/bases/baremetal.cluster.gke.io_clusters.yaml: no such file or directory

最初に bmctl check cluster を実行すると、この問題を修正できます。これにより、.manifests ディレクトリが再作成されます。

この問題は、Anthos clusters on bare metal 1.10 以前に適用され、バージョン 1.11 以降で修正されています。

bmctl update でメンテナンス ブロックが削除されない

bmctl update コマンドでは、クラスタ リソース構成の maintenanceBlocks セクションを削除や変更をすることはできません。メンテナンス モードでノードを削除する手順などの詳細については、ノードをメンテナンス モードにするをご覧ください。

オペレーション

kubeconfig シークレットが上書きされる

bmctl check cluster コマンドをユーザー クラスタで実行すると、ユーザー クラスタ kubeconfig シークレットが管理クラスタ kubeconfig で上書きされます。このファイルを上書きすると、更新やアップグレードなどの標準のクラスタ オペレーションが、影響を受けるユーザー クラスタで失敗します。この問題は、バージョン 1.11.1 以前のベアメタル版 Anthos クラスタに適用されます。

ユーザー クラスタがこの問題の影響を受けているかどうかを判断するには、次のコマンドを実行します。

kubectl --kubeconfig ADMIN_KUBECONFIG get secret -n cluster-USER_CLUSTER_NAME \
    USER_CLUSTER_NAME -kubeconfig  -o json  | jq -r '.data.value'  | base64 -d

以下を置き換えます。

  • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。
  • USER_CLUSTER_NAME: 確認するユーザー クラスタの名前。

出力内のクラスタ名(次のサンプル出力の contexts.context.cluster を参照)が管理クラスタ名である場合は、指定したユーザー クラスタが影響を受けます。

user-cluster-kubeconfig  -o json  | jq -r '.data.value'  | base64 -d
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data:LS0tLS1CRU...UtLS0tLQo=
    server: https://10.200.0.6:443
  name: ci-aed78cdeca81874
contexts:
- context:
    cluster: ci-aed78cdeca81874
    user: ci-aed78cdeca81874-admin
  name: ci-aed78cdeca81874-admin@ci-aed78cdeca81874
current-context: ci-aed78cdeca81874-admin@ci-aed78cdeca81874
kind: Config
preferences: {}
users:
- name: ci-aed78cdeca81874-admin
  user:
    client-certificate-data: LS0tLS1CRU...UtLS0tLQo=
    client-key-data: LS0tLS1CRU...0tLS0tCg==

次の手順で、影響を受けるユーザー クラスタ(USER_CLUSTER_NAME)に機能を復元します。

  1. ユーザー クラスタ kubeconfig ファイルを見つけます。

    Anthos clusters on bare metal は、クラスタの作成時に管理ワークステーションに kubeconfig ファイルを生成します。デフォルトでは、このファイルは bmctl-workspace/USER_CLUSTER_NAME ディレクトリにあります。

  2. この kubeconfig が正しいユーザー クラスタ kubeconfig であることを確認します。

    kubectl get nodes --kubeconfig PATH_TO_GENERATED_FILE

    PATH_TO_GENERATED_FILE は、ユーザー クラスタ kubeconfig ファイルのパスに置き換えます。 レスポンスで、ユーザー クラスタのノードの詳細が返されます。クラスタのマシン名が正しいことを確認します。

  3. 次のコマンドを実行して、管理クラスタ内の壊れた kubeconfig ファイルを削除します。

    kubectl delete secret -n USER_CLUSTER_NAMESPACE USER_CLUSTER_NAME-kubeconfig
  4. 次のコマンドを実行して、正しい kubeconfig シークレットを管理クラスタに保存し直します。

    kubectl create secret generic -n USER_CLUSTER_NAMESPACE USER_CLUSTER_NAME-kubeconfig \
        --from-file=value=PATH_TO_GENERATED_FILE

リセット / 削除

ユーザー クラスタ認証情報

bmctl reset コマンドは、クラスタ構成ファイル中の最上位の認証情報セクションを使用します。ユーザー クラスタの場合、ファイルを手動で更新して、この認証情報セクションを追加する必要があります。

マウント ポイントと fstab

リセットによって、/mnt/anthos-system/mnt/localpv-share/ の下のマウント ポイントがマウント解除されることはありません。また、リセットによって、/etc/fstab の対応するエントリはクリーンアップされません。

Namespace の削除

Namespace を削除すると、新しいリソースをその Namespace に作成されることが妨げれられ、そうしたリソースにはマシンをリセットするジョブも含まれます。ユーザー クラスタを削除する場合は、まず、クラスタ オブジェクトを削除した後、Namespace を削除する必要があります。そうしないと、マシンをリセットするジョブが作成できず、削除プロセスではマシンのクリーンアップ手順が省略されます。

セキュリティ

クラスタ CA / 証明書はアップグレード中にローテーションされます。現在、オンデマンド ローテーション サポートは利用できません。

ベアメタル版 Anthos クラスタは、kubelet 提供の証明書を自動的にローテーションします。各 kubelet ノード エージェントは、証明書の有効期限が近くなると、証明書署名リクエスト(CSR)を送信できます。この CSR は、管理クラスタ内のコントローラで検証し、承認されます。

ネットワーキング

レイヤ 2 負荷分散がバンドルされたクライアント ソース IP

外部トラフィック ポリシーLocal に設定すると、バンドルされたレイヤ 2 負荷分散に No route to host などのルーティング エラーが発生する可能性があります。外部トラフィック ポリシーは、デフォルトで ClusterexternalTrafficPolicy: Cluster)に設定されています。この設定では、Kubernetes がクラスタ全体のトラフィックを処理します。LoadBalancer または NodePort のタイプの Service は、externalTrafficPolicy: Local を使用してクライアントの送信元 IP アドレスを保持できます。ただし、この設定では、Kubernetes はノードローカルのトラフィックのみを処理します。

クライアントの送信元 IP アドレスを保持する場合は、サービス IP に到達できるようにするために、追加の構成が必要になることがあります。構成の詳細については、バンドルされた負荷分散の構成に記載されているクライアントの送信元 IP アドレスの保持をご覧ください。

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_filter0 に戻します。anetd Pod を再起動するには、次のコマンドを使用して anetd Pod を見つけて削除します。新しい anetd Pod が代わりに開始されます。

kubectl get pods -n kube-system
kubectl delete pods -n kube-system ANETD_XYZ

ANETD_XYZ は、anetd Pod の名前で置き換えます。

ブートストラップ(kind)クラスタ IP アドレスとクラスタノードの IP アドレスの重複

192.168.122.0/2410.96.0.0/27 は、ブートストラップ(kind)クラスタで使用されるデフォルトの Pod と Service の CIDR です。それがクラスタ ノード マシンの IP アドレスと重複すると、プリフライト チェックが不合格になります。この競合を回避するには、--bootstrap-cluster-pod-cidr フラグと --bootstrap-cluster-service-cidr フラグを bmctl に渡して別の値を指定します。

異なるクラスタ間での IP アドレスの重複

異なるクラスタ間で重複する IP アドレスを検証するプリフライト チェックはありません。

ベアメタル版 Anthos クラスタの hostport 機能

現在、ContainerPorthostport 機能は、サポートされていません。

OS

CentOS でクラスタの作成またはアップグレードの失敗

2020 年 12 月、CentOS コミュニティと Red Hat は CentOS の開発およびサポートの終了を発表しました。2022 年 1 月 31 日に CentOS 8 はサポート終了(EOL)となりました。EOL の結果として、yum リポジトリが CentOS で機能しなくなり、クラスタの作成とクラスタのアップグレードのオペレーションが失敗するようになりました。これは、CentOS のすべてのサポートされているバージョンに適用され、Anthos clusters on bare metal のすべてのバージョンに影響します。

回避策として、次のコマンドを実行し、CentOS でアーカイブ フィードを使用します。

sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-Linux-*
sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' \
    /etc/yum.repos.d/CentOS-Linux-*

長期的な解決策としては、UbuntuRHEL など、サポートされている別のオペレーティング システムへの移行を検討してください。

オペレーティング システムのエンドポイントの上限

RHEL と CentOS では、クラスタレベルの上限が 100,000 エンドポイントに制限されています。Kubernetes Service2 つのサービスが同一の Pod セットを参照する場合、2 つの別のエンドポイント セットとしてカウントされます。RHEL と CentOS 上の基礎的な nftable 実装には、この制約が存在します。これはベアメタル版 Anthos クラスタの固有の制限ではありません。

構成

コントロール プレーンとロードバランサの仕様

コントロール プレーンとロードバランサのノードプールの仕様は、特別なものです。これらの仕様で、重要なクラスタ リソースが宣言され管理されます。そのリソースの原本が、クラスタ構成ファイルのそれぞれのセクションです。

  • spec.controlPlane.nodePoolSpec
  • spec.LoadBalancer.nodePoolSpec

したがって、トップレベルのコントロール プレーンとロードバランサのノードプール リソースは、直接変更しないでください。代わりに、クラスタ構成ファイル内の関連するセクションを変更してください。

クラスタとノードプール仕様の変更可能なフィールド

現在、クラスタを作成すると、クラスタ構成ファイルの次のクラスタ仕様フィールドとノードプール仕様フィールドのみを更新できます(これが変更可能なフィールドです)。

  • Cluster オブジェクト(kind: Cluster)の場合は、次のフィールドが変更可能です。

    • spec.anthosBareMetalVersion
    • spec.bypassPreflightCheck
    • spec.controlPlane.nodePoolSpec.nodes
    • spec.loadBalancer.nodePoolSpec.nodes
    • spec.maintenanceBlocks
    • spec.nodeAccess.loginUser
  • NodePool オブジェクト(kind: NodePool)の場合は、次のフィールドが変更可能です。

    • spec.nodes

ノードに NotReady ステータスが表示されています

特定の負荷条件下では、ベアメタル 1.6.x ノードの Anthos クラスタは、Pod Lifecycle Event Generator(PLEG)が異常であるため、NotReady ステータスが表示されることがあります。ノードのステータスには次のエントリが含まれます。

PLEG is not healthy: pleg was last seen active XXXmXXXs ago; threshold is 3m0s

この影響を受けるかどうかを確認するにはどうしたらよいですか?

この問題の考えられる原因は、runc バイナリ バージョンです。問題のあるバージョンがインストールされているかどうかを確認するには、SSH を使用していずれかのクラスタマシンに接続し、次のコマンドを実行します。

/usr/bin/runc -v

出力が 1.0.0-rc93 の場合は、問題のあるバージョンがインストールされています。

考えられる回避策

この問題を解決するには、ベアメタル 1.7.0 の Anthos クラスタへのアップグレードをおすすめします。

アップグレードができない場合は、問題となっているノードマシンの containerd.io パッケージを以前のバージョンに戻すことができます。これを行うには、SSH を使用してノードマシンに接続し、次のコマンドを実行します。

Ubuntu

apt install containerd.io=1.4.3-1

CentOS/RHEL

dnf install containerd.io-1.3.9-3.1.el8.