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

構成

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

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

  • spec.controlPlane.nodePoolSpec
  • spec.loadBalancer.nodePoolSpec

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

インストール

マルチ NIC、containerd、HTTP プロキシを使用していると、クラスタの作成に失敗する

次の条件の組み合わせがある場合、クラスタの作成が失敗します。

  • クラスタが、コンテナ ランタイムとして containerd を使用するように構成されている（クラスタ構成ファイルで nodeConfig.containerRuntime が containerd に設定されている。これはベアメタル版 Anthos クラスタ バージョン 1.9 のデフォルトである）。

  • クラスタが、Pod 用に複数のネットワーク インターフェース（マルチ NIC）を提供するように構成されている（クラスタ構成ファイルで clusterNetwork.multipleNetworkInterfaces が true に設定されている）。

  • クラスタが、プロシキを使用するように構成されている（spec.proxy.url はクラスタ構成ファイルで指定されます）。クラスタの作成に失敗しても、この設定はクラスタを作成しようとするときに伝搬されます。このプロキシ設定は、HTTPS_PROXY 環境変数として、または containerd 構成（/etc/systemd/system/containerd.service.d/09-proxy.conf）で確認できます。

この問題の回避方法として、すべてのノードマシンで NO_PROXY 環境変数にサービス CIDR（clusterNetwork.services.cidrBlocks）を追加します。

指定されていない containerRuntime はデフォルトでは containerd にならない

Anthos clusters on bare metal のリリース 1.9.0 では、生成されたクラスタ構成ファイルの containerRuntime デフォルトが docker から containerd に更新されました。containerRuntime フィールドが設定されていないか、クラスタ構成ファイルから削除されている場合、クラスタの作成時に containerRuntime は docker に設定されます。containerRuntime の値は、明示的に docker に設定されていない限り、デフォルトで containerd にする必要があります。この問題は、リリース 1.9.0 と 1.9.1 にのみ適用されます。

クラスタで使用しているコンテナ ランタイムを確認するには、クラスタ情報を取得するの手順を行います。cluster.spec.nodeConfig セクションの containerRuntime の値を確認してください。

コンテナのランタイムを変更する唯一の方法は、クラスタをアップグレードすることです。詳細については、コンテナ ランタイムを変更するをご覧ください。

この問題は、ベアメタル版 Anthos クラスタのリリース 1.9.2 で修正されています。

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

コントロール グループ v2（cgroup v2）は、ベアメタル版 Anthos クラスタ 1.9 で正式にサポートされていません。/sys/fs/cgroup/cgroup.controllers がある場合は、cgroup v2 がシステムで使用されていることを意味します。

プリフライト チェックにより、クラスタマシンで cgroup v2 が使用されていないことが確認されます。

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

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

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

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

プリフライト チェックと権限が拒否されました

インストール中に、/bin/sh: /tmp/disks_check.sh: Permission denied に関するエラーが表示されることがあります。このエラー メッセージは、noexec オプションを付けて /tmp がマウントされていることが原因で出力されます。bmctl が機能するためには、/tmp のマウント ポイントから noexec オプションを削除する必要があります。

アプリケーションのデフォルト認証情報と 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 サービスを有効にします。

vSphere へのインストール

vSphere VM にベアメタル版 Anthos クラスタをインストールする場合は、tx-udp_tnl-segmentation フラグと tx-udp_tnl-csum-segmentation フラグをオフに設定する必要があります。これらのフラグは、vSphere ドライバ VMXNET3 によるハードウェア セグメンテーション オフロードに関連しており、ベアメタル版 Anthos クラスタの GENEVE トンネルでは機能しません。

各ノードで次のコマンドを実行して、これらのフラグの現在の値を確認します。ethtool -k NET_INTFC |grep segm ... tx-udp_tnl-segmentation: on tx-udp_tnl-csum-segmentation: on ... NET_INTFC を、ノードの IP アドレスに関連付けられたネットワーク インターフェースに置き換えます。

RHEL 8.4 では、ethtool でこれらのフラグがオフではない場合でもオフと表示されることがあります。これらのフラグを明示的にオフに設定するには、次のコマンドを使用して、フラグをオンにしてからオフにします。

ethtool -K ens192 tx-udp_tnl-segmentation on
ethtool -K ens192 tx-udp_tnl-csum-segmentation on

ethtool -K ens192 tx-udp_tnl-segmentation off
ethtool -K ens192 tx-udp_tnl-csum-segmentation off

このフラグの変更はリブート時に保持されません。起動スクリプトを構成することで、システムの起動時にこれらのフラグを明示的に設定します。

アップグレードと更新

.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 は、前のバージョンのユーザー クラスタを作成、更新、リセットすることはできません

管理クラスタのバージョンにかかわらず、bmctl CLI はマイナー バージョンのユーザー クラスタを作成、更新、リセットできません。たとえば、管理クラスタのバージョンが 1.N.X であっても、バージョン 1.N-1.Y のユーザークラスタをリセットするのに 1.N.X の bmctl を使用できません。

この問題の影響を受けると、bmctl の使用時に次のようなログが表示されます。

[2022-06-02 05:36:03-0500] error judging if the cluster is managing itself:
error to parse the target cluster: error parsing cluster config: 1 error
occurred:
    * cluster version 1.8.1 is not supported in bmctl version 1.9.5, only
cluster version 1.9.5 is supported

この問題を回避するには、kubectl を使用して、管理クラスタ内のユーザー クラスタのカスタム リソースを作成、編集、削除します。

ユーザー クラスタのアップグレード機能は影響を受けません。

error during manifests operations でアップグレード進まない

場合によっては、クラスタのアップグレードが完了せず、bmctl CLI が応答しなくなる可能性があります。この問題は、リソースが正しく更新されていないことが原因の可能性があります。この問題の影響を受けるかどうかを判断するには、次の手順を行います。

  1. anthos-cluster-operator ログを調べて、次のエントリのようなエラーを探します。

    controllers/Cluster "msg"="error during manifests operations" "error"="1 error occurred:
...
{RESOURCE_NAME} is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update

    こうしたエントリは、リソースが誤って更新された場合の症状です。ここで、{RESOURCE_NAME} は問題リソースの名前です。

  2. ログにこれらのエラーがある場合は、kubectl edit を使用して、ログ メッセージに含まれているリソースから kubectl.kubernetes.io/last-applied-configuration アノテーションを削除します。

  3. 変更を保存してリソースに適用します。

  4. クラスタのアップグレードをもう一度行ってください。

メンテナンス モードでバージョン 1.8 クラスタのアップグレードが失敗する

以前いずれかのノードマシンがメンテナンス モードになったことがある場合、バージョン 1.8.x クラスタをバージョン 1.9.x にアップグレードしようとすると失敗します。これは、これらのノードに残っているアノテーションによるものです。

この問題の影響を受けているかどうかを判断するには、次の手順を行います。

  1. 次のコマンドを実行して、アップグレードするクラスタのバージョンを取得します。

    kubectl --kubeconfig ADMIN_KUBECONFIG get cluster CLUSTER_NAME  \
    -n CLUSTER_NAMESPACE --output=jsonpath="{.spec.anthosBareMetalVersion}"

    1.8 マイナー リリース（1.8.3 など）のバージョン値が返される場合は、続行します。それ以外の場合、この問題は該当しません。

  2. 次のコマンドを実行して、以前にメンテナンス モードにしたノードがクラスタにあるかどうかを確認します。

    kubectl --kubeconfig ADMIN_KUBECONFIG get BareMetalMachines -n CLUSTER_NAMESPACE  \
    --output=jsonpath="{.items[*].metadata.annotations}"

    返されたアノテーションに baremetal.cluster.gke.io/maintenance-mode-duration が含まれている場合、この既知の問題の影響を受けています。

クラスタのアップグレードのブロックを解除するには、影響を受ける各ノードマシンで次のコマンドを実行して、baremetal.cluster.gke.io/maintenance-mode-duration アノテーションを削除します。

kubectl --kubeconfig ADMIN_KUBECONFIG  annotate BareMetalMachine -n CLUSTER_NAMESPACE \
    NODE_MACHINE_NAME baremetal.cluster.gke.io/maintenance-mode-duration-

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

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

ユーザー クラスタのパッチ アップグレードの制限

管理クラスタによって管理されるユーザー クラスタは、ベアメタル版 Anthos クラスタのバージョン以下で、かつマイナー リリースの違いが 1 以内でなければなりません。たとえば、バージョン 1.9.0（anthosBareMetalVersion: 1.9.0）の管理クラスタでは、バージョン 1.8.4 のユーザー クラスタを管理できます。

管理クラスタが使用しているリリース バージョンの後に新しいセキュリティ パッチがリリースされた場合は、アップグレードの制限により、ユーザー クラスタをそのパッチにアップグレードできません。たとえば、管理クラスタが 2021 年 6 月 2 日リリースのバージョン 1.7.2 の場合、ユーザー クラスタをバージョン 1.6.4 にアップグレードすることはできません。これは 2021 年 8 月 13 日にリリースされているためです。

ノードが到達不能になると、ノードのドレインを開始できません

ベアメタル版 Anthos クラスタから Node にアクセスできない場合、Node のドレイン プロセスは開始されません。たとえば、クラスタのアップグレード プロセス中に 1 つの Node がオフラインになると、アップグレードが停止する可能性があります。めったに発生することではありません。この問題が発生する可能性を最小限に抑えるには、アップグレードを開始する前に Node が正常に動作していることを確認してください。

オペレーション

root 以外のログインを使用するとクラスタのバックアップが失敗する

nodeAccess.loginUser が root 以外のユーザー名に設定されている場合、bmctl backup cluster コマンドは失敗します。

この問題は、Anthos clusters on bare metal の 1.9.x、1.10.0、1.10.1 に適用され、バージョン 1.10.2 以降で修正されています。

メンテナンス モード手順を使用しない場合、ノードが閉鎖解除される

ノードで手動で kubectl cordon を使用する場合、Anthos clusters on bare metal は、期待される状態を調整する準備ができるまで、ノードの閉鎖を解除することがあります。Anthos clusters on bare metal バージョン 1.12.0 以前の場合は、メンテナンス モードを使用してノードを閉鎖してドレインします。バージョン 1.12.1（anthosBareMetalVersion: 1.12.1）以降では、kubectl cordon を使用しても、Anthos clusters on bare metal が予期せずノードを閉鎖解除しません。

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

root 以外のログイン ユーザーとしてスナップショットを取得する

コンテナ ランタイムとして containerd を使用する場合、root 以外のユーザーとしてスナップショットを実行するには、ユーザーの PATH に /usr/local/bin が存在する必要があります。それ以外の場合は、crictl: command not found エラーで失敗します。

root ユーザーとしてログインしていない場合は、sudo を使用してスナップショット コマンドを実行します。sudo の PATH はルート プロファイルと異なる場合があり、/usr/local/bin を含んでいないことがあります。

このエラーは、/etc/sudoers の secure_path に /usr/local/bin を追加して修正できます。あるいは、別の /bin ディレクトリに crictl のシンボリック リンクを作成します。

Anthos VM ランタイム

Pod を再起動すると、Pod 上の VM は IP アドレスを変更するか、IP アドレスが完全に失われます。VM の IP アドレスが変更されても、Kubernetes サービスとして公開されている VM アプリケーションのネットワーク到達性に影響はありません。IP アドレスが失われた場合、VM から dhclient を実行して VM の IP アドレスを取得する必要があります。

ロギングとモニタリング

ネットワーク停止後にログが見つからない

クラスタがネットワークの停止から回復すると、新しいログが Cloud Logging に表示されないことがあります。また、stackdriver-log-forwarder のログに、次のような複数のメッセージが記録されることがあります。

re-schedule retry=0x7fef2acbd8d0 239 in the next 51 seconds

ログ転送を再度有効にするには、stackdriver-log-forwarder Pod を再起動します。停止してから 4.5 時間以内にログ フォワーダーが再起動されると、バッファリングされたログが Cloud Logging に転送されます。4.5 時間以上経過したログは破棄されます。

指標エクスポートの断続的な中断

リリース 1.9.x と 1.10.x のベアメタル版 Anthos クラスタでは、一部のノードで通常の指標の継続的なエクスポートが中断されたり、指標が欠落したりすることがあります。この問題がクラスタに影響する場合は、少なくとも次の指標でデータのギャップが見られる可能性があります。

  • kubernetes.io/anthos/container_memory_working_set_bytes
  • kubernetes.io/anthos/container_cpu_usage_seconds_total
  • kubernetes.io/anthos/container_network_receive_bytes_total

この問題を解決するには、クラスタをバージョン 1.10.3 以降にアップグレードしてください。

アップグレードできない場合は、回避策として次の手順を行ってください。

  1. stackdriver リソースを編集用に開きます。

    kubectl -n kube-system edit stackdriver stackdriver

  2. gke-metrics-agent の CPU リクエストを 10m から 50m に引き上げるには、stackdriver マニフェストに次の resourceAttrOverride セクションを追加します。

    spec:
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi

    編集したリソースは、次のようになります。

    spec:
  anthosDistribution: baremetal
  clusterLocation: us-west1-a
  clusterName: my-cluster
  enableStackdriverForApplications: true
  gcpServiceAccountSecretName: ...
  optimizedMetrics: true
  portable: true
  projectID: my-project-191923
  proxyConfigSecretName: ...
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      limits:
        cpu: 100m
        memory: 4608Mi
      requests:
        cpu: 50m
        memory: 200Mi

  3. 変更を保存し、テキスト エディタを終了します。

  4. 変更が有効になっていることを確認するには、次のコマンドを実行します。

    kubectl -n kube-system get daemonset gke-metrics-agent -o yaml | grep "cpu: 50m"

    変更が有効になっている場合は、このコマンドで cpu: 50m が検出されます。

  5. 変更が元の状態に戻ることを回避するには、stackdriver-operator をスケールダウンします。

    kubectl -n kube-system scale deploy stackdriver-operator --replicas=0

  6. gke-metrics-agent-conf を編集用に開きます。

    kubectl -n kube-system edit configmap gke-metrics-agent-conf

  7. 構成を編集して、probe_interval: 0.1s のインスタンスをすべて probe_interval: 13s に変更します。

     183     processors:
 184       disk_buffer/metrics:
 185         backend_endpoint: https://monitoring.googleapis.com:443
 186         buffer_dir: /metrics-data/nsq-metrics-metrics
 187         probe_interval: 13s
 188         retention_size_mib: 6144
 189       disk_buffer/self:
 190         backend_endpoint: https://monitoring.googleapis.com:443
 191         buffer_dir: /metrics-data/nsq-metrics-self
 192         probe_interval: 13s
 193         retention_size_mib: 200
 194       disk_buffer/uptime:
 195         backend_endpoint: https://monitoring.googleapis.com:443
 196         buffer_dir: /metrics-data/nsq-metrics-uptime
 197         probe_interval: 13s
 198         retention_size_mib: 200

  8. 変更を保存し、テキスト エディタを終了します。

  9. gke-metrics-agent のデーモンセットを再起動します。

    kubectl -n kube-system rollout restart daemonset gke-metrics-agent

セキュリティ

コンテナが、containerd と SELinux を使用して Dockerfile で定義された VOLUME に書き込むことができない

コンテナ ランタイムとして containerd を使用し、オペレーティング システムで SELinux が有効になっている場合、アプリケーション Dockerfile で定義された VOLUME が書き込みできない可能性があります。たとえば、次の Dockerfile でビルドされたコンテナは、/tmp フォルダへの書き込みはできません。

FROM ubuntu:20.04
RUN chmod -R 777 /tmp
VOLUME /tmp

この問題の影響を受けるかどうかを確認するには、問題のあるコンテナをホストするノードで次のコマンドを実行します。

ausearch -m avc

この問題の影響を受けると、次のような denied エラーが表示されます。

time->Mon Apr  4 21:01:32 2022 type=PROCTITLE msg=audit(1649106092.768:10979):
proctitle="bash" type=SYSCALL msg=audit(1649106092.768:10979): arch=c000003e
syscall=257 success=no exit=-13 a0=ffffff9c a1=55eeba72b320 a2=241 a3=1b6
items=0 ppid=75712 pid=76042 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="bash" exe="/usr/bin/bash"
subj=system_u:system_r:container_t:s0:c701,c935 key=(null) type=AVC
msg=audit(1649106092.768:10979): avc:  denied {
write } for  pid=76042 comm="bash"
name="ad9bc6cf14bfca03d7bb8de23c725a86cb9f50945664cb338dfe6ac19ed0036c"
dev="sda2" ino=369501097 scontext=system_u:system_r:container_t:s0:c701,c935
tcontext=system_u:object_r:container_ro_file_t:s0 tclass=dir permissive=0

この問題を回避するには、次のいずれかの変更を行います。

  • SELinux を無効にします。
  • Dockerfile 内で Volume 機能を使用しないでください。

クラスタ CA のローテーション（プレビュー機能）

クラスタ CA / 証明書はアップグレード中にローテーションされます。オンデマンド ローテーション サポートはプレビュー機能です。

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

クラスタでユーザー クラスタの認証局（CA）のローテーションを実行すると、すべてのユーザー認証フローが失敗します。これは、認証フローで使用される ClientConfig カスタム リソースが CA のローテーション中に新しい CA データで更新されないために発生します。クラスタでクラスタ CA のローテーションを実行した場合は、kube-public Namespace の default ClientConfig の certificateAuthorityData フィールドに古いクラスタ CA が含まれているかどうかを確認します。

この問題を手動で解決するには、現在のクラスタ CA で certificateAuthorityData フィールドを更新します。

Pod の作成中の SELinux エラー

SELinux により、コンテナ ランタイムが tmpfs マウントでラベルを設定できない場合、Pod の作成に失敗することがあります。この失敗はまれですが、SELinux が Enforcing モードで、一部のカーネルにある場合に発生することがあります。

SELinux が Pod 作成の失敗の原因であることを確認するには、次のコマンドを使用して kubelet ログにエラーがあるかどうかを確認します。

journalctl -u kubelet

SELinux によって Pod の作成が失敗すると、コマンドのレスポンスに次のようなエラーが含まれます。

error setting label on mount source '/var/lib/kubelet/pods/
6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x':
failed to set file label on /var/lib/kubelet/pods/
6d9466f7-d818-4658-b27c-3474bfd48c79/volumes/kubernetes.io~secret/localpv-token-bpw5x:
permission denied

この問題が SELinux の強制適用に関連していることを確認するには、次のコマンドを実行します。

ausearch -m avc

このコマンドは、監査ログでアクセス ベクトル キャッシュ（AVC）権限エラーを検索します。次のサンプル レスポンスの avc: denied は、Pod の作成エラーが SELinux の適用に関連していることを確認します。

type=AVC msg=audit(1627410995.808:9534): avc:  denied  { associate } for
pid=20660 comm="dockerd" name="/" dev="tmpfs" ino=186492
scontext=system_u:object_r:container_file_t:s0:c61,c201
tcontext=system_u:object_r:locale_t:s0 tclass=filesystem permissive=0

SELinux でのこの Pod 作成の問題の根本的な原因は、次の Linux イメージにあるカーネル バグです。

  • 8.3 より前の Red Hat Enterprise Linux（RHEL）リリース
  • 8.3 より前の CentOS リリース

マシンを再起動すると、問題からの回復に役立ちます。

Pod 作成エラーの発生を防止するには、カーネルのバグを修正した RHEL 8.3 以降または CentOS 8.3 以降を使用してください。

ネットワーキング

複数のデフォルト ゲートウェイで外部エンドポイントへの接続が切断される

ノードに複数のデフォルト ゲートウェイを使用すると、Pod 内から google.com などの外部エンドポイントへの接続が中断される可能性があります。

この問題の影響を受けるかどうかを確認するには、ノードで次のコマンドを実行します。

ip route show

レスポンスに default の複数のインスタンスがある場合は、影響を受けていることを示しています。

この問題を回避するには、Kubernetes ノード IP に使用されるデフォルトのゲートウェイ インターフェースがリストの先頭にあることを確認します。

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

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

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

firewalld の変更で Cilium iptable ポリシー チェーンが消去される

CentOS または Red Had Enterprise Linux（RHEL）で firewalld を有効にしてベアメタル版 Anthos クラスタを実行している場合は、firewalld を変更すると、ホスト ネットワーク上の Cilium iptables チェーンが削除される場合があります。この iptables チェーンは、起動時に anetd Pod によって追加されます。Cilium の iptables チェーンが失なわれると、Node 上の Pod は、Node 外部のネットワーク接続を失います。

iptables チェーンが削除される firewalld の変更には、次に挙げるものがありますが、これに限定されません。

  • systemctl を使用した firewalld の再起動
  • コマンドライン クライアント（firewall-cmd --reload）を使用した firewalld の再読み込み

この接続の問題は、Node で anetd を再起動することにより解決できます。anetd は、次のコマンドを使用して anetd Pod を見つけて削除することで再起動します。

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

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

egressSourceIP アドレスの重複

下り（外向き）NAT ゲートウェイ機能のプレビューを使用する場合、別の EgressNATPolicy オブジェクトに対してすでに使用されている egressSourceIP アドレスを指定するトラフィック選択ルールを設定できます。これにより、下り（外向き）トラフィック ルーティングの競合が発生する可能性があります。開発チームと連携し、EgressNATPolicy カスタム リソースで egressSourceIP アドレスを指定する前に、使用可能なフローティング IP アドレスを決定します。

I/O タイムアウトとリバースパス フィルタリングによる Pod 接続の失敗

ベアメタル版 Anthos クラスタは、ソース検証（net.ipv4.conf.all.rp_filter=0）を無効にするために、ノード上でリバースパス フィルタリングを構成します。rp_filter 設定が 1 または 2 に変更されると、ノード外の通信タイムアウトにより Pod は失敗します。

この問題は、Kubernetes Service の IP アドレスとの通信で接続エラーが発生していることを示しています。表示されるエラーの種類の例を次に示します。

  • 特定のノードのすべての Pod が Service の IP アドレスと通信できない場合、istiod Pod によって次のようなエラーが報告されることがあります。

     {"severity":"Error","timestamp":"2021-11-12T17:19:28.907001378Z",
    "message":"watch error in cluster Kubernetes: failed to list *v1.Node:
    Get \"https://172.26.0.1:443/api/v1/nodes?resourceVersion=5  34239\":
    dial tcp 172.26.0.1:443: i/o timeout"}

  • すべてのノードで実行される localpv デーモンセットの場合、ログに次のようなタイムアウトが示される場合があります。

     I1112 17:24:33.191654       1 main.go:128] Could not get node information
(remaining retries: 2): Get
https://172.26.0.1:443/api/v1/nodes/NODE_NAME:
dial tcp 172.26.0.1:443: i/o timeout

リバースパス フィルタリングは、IPv4 構成フォルダ（net/ipv4/conf/all）内の rp_filter ファイルで設定されています。sysctl コマンドは、ネットワーク セキュリティ構成ファイル（/etc/sysctl.d/60-gce-network-security.conf など）にリバースパス フィルタリング設定を格納します。sysctl コマンドは、リバースパス フィルタリング設定をオーバーライドできます。

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 の名前で置き換えます。

net.ipv4.conf.all.rp_filter を手動で設定するには、次のコマンドを実行します。

sysctl -w net.ipv4.conf.all.rp_filter = 0

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

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

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

更新中に異なるクラスタ間で重複する IP アドレスの検証は行われません。その検証は、クラスタ / ノードプールの作成時にのみ行われます。

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-*

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

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

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

リセット / 削除

Namespace の削除

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

containerd サービス

bmctl reset コマンドで、containerd 構成ファイルやバイナリが削除されません。containerd systemd サービスは、起動されたまま実行し続けます。このコマンドでは、ノードにスケジュールされた Pod を実行するコンテナを削除します。