Container Service for Kubernetes:ノードプールのよくある質問

インデックス

ノードの問題を診断およびトラブルシューティングするには、「ノード例外のトラブルシューティング」をご参照ください。

ノードプールでスポットインスタンスを使用する方法

1 つのノードプールに異なる ECS インスタンスタイプを設定できますか？

はい、できます。インスタンスの利用不可や在庫不足によるスケールアウトの失敗を防ぐため、以下の戦略を推奨します。

• 異なるアベイラビリティゾーンにまたがるノードプールに複数の vSwitch を設定する。

• 複数の Elastic Compute Service (ECS) インスタンスタイプを選択するか、vCPU とメモリの仕様に基づいてインスタンス タイプを指定する。
  作成後にノードプールのスケーラビリティレベルを表示できます。
  

サポートされていないインスタンスタイプとノード構成の推奨事項については、「ECS インスタンスタイプの構成に関する推奨事項」をご参照ください。

ノードあたりの Pod の最大数を計算する方法

ノードあたりでサポートされる Pod の最大数は、クラスターが使用するネットワークプラグインによって異なります。詳細な計算方法については、「ノードあたりの最大 Pod 数」をご参照ください。

• Terway：ノードあたりの最大 Pod 数 = Elastic Network Interface (ENI) ベースの最大 Pod 数 + ホストネットワーク Pod 数。

• Flannel：上限は、クラスター作成時に指定された [ノードあたりの Pod 数] によって定義されます。

ACK コンソールの [ノード] ページにあるノードリストで、最大 Pod 数 (Pod クォータ) を確認できます。

ノードが Pod 上限に達した場合に Pod 容量を調整する方法

単一のワーカーノードでサポートされる Pod の最大数は、ネットワークプラグインの種類によって決まり、ほとんどの場合変更できません。

• Terway モード：ノードあたりの最大 Pod 数は、ECS インスタンスが提供する ENI の数に依存します。

• Flannel モード：ノードあたりの最大 Pod 数はクラスター作成時に定義され、一度設定すると変更できません。

クラスター内の Pod 数が上限に達した場合は、ノードプールをスケールアウトしてノードを追加し、クラスター全体の利用可能な Pod 容量を増やすことを推奨します。詳細については、「クラスター内の最大 Pod 数を増やす」をご参照ください。

ノード構成を変更する方法

クラスターの安定性を確保するため、ノードプールの作成後は、特定のパラメーター (特にネットワークと高可用性に関連するもの) は変更不可です。たとえば、ノードが属するコンテナランタイムや Virtual Private Cloud (VPC) を変更することはできません。

変更可能なパラメーターの場合、変更は通常、新しく作成されたノードにのみ適用されます。既存のノードは、[既存ノードの ECS タグを更新] や [既存ノードのラベルとテイントを更新] など、特に指定がない限り影響を受けません。

新しい構成を適用するためのベストプラクティス：
既存のノードに新しい設定を適用するには、次の手順に従います。

1. 目的の構成で新しいノードプールを作成します。

2. 古いノードプールのノードを cordon (スケジューリング無効化) および drain (退避) して、ワークロードを新しいノードに移行します。

3. 移行が完了したら、古いノードプールのインスタンスをリリースします。

どのパラメーターが変更可能で、変更がいつ有効になるかについての詳細については、「ノードプールの編集」をご参照ください。

「[予期されるノード]」機能を無 disabled にできますか？

ノードプールの [スケーリングモード] が [手動] に設定されている場合、[予想インスタンス数] パラメーターは必須であり、無効にすることはできません。

特定のノードを削除またはリリースしたい場合は、「ノードの削除」をご参照ください。特定のノードを追加したい場合は、「既存ノードの追加」をご参照ください。ノードを削除したり、既存ノードを追加したりすると、予想インスタンス数は新しいノード数に自動的に調整されます。手動で変更する必要はありません。

ノードプールで [Expected Nodes] を有効にした場合と無効にした場合の違いは何ですか？

[予想インスタンス数] パラメーターは、ノードプールの意図された容量を定義します。このパラメーターを調整することで、ノードプールをスケールアウトまたはスケールインできます。最新のノードプールのほとんどはこの機能を調整とスケーリングに使用しますが、一部のレガシーノードプールではこの機能が有効になっていない場合があります。

次の表は、この設定に基づいてシステムがさまざまな操作にどのように応答するかを説明しています。

フリーノードをノードプールに追加する方法

ノードプール機能が導入される前のレガシークラスターで作成されたワーカーノードは、フリーノードと見なされます。不要になった場合は、対応する ECS インスタンスをリリースしてください。そうでない場合は、グループ管理と自動化された O&M の恩恵を受けるために、それらをノードプールに移行することを推奨します。

新しいノードプールを作成するか、既存のノードプールを拡張し、クラスターからフリーノードを削除してから、ターゲットのノードプールに追加します。詳細については、「フリーノードをノードプールに追加する」をご参照ください。

ノードプールの OS イメージを変更する方法

必要に応じて OS を切り替えることができます。たとえば、CentOS から Alibaba Cloud Linux に切り替えたり、現在の OS の新しいバージョンにアップグレードしたりできます。続行する前に、「OS イメージのリリースノート」で互換性と使用制限を確認してください。

手順の詳細については、「ノードプールの OS を置き換える」をご参照ください。

特定の ECS インスタンスをリリースする方法

特定の ECS インスタンスをリリースするには、ACK コンソール経由でノードを削除する必要があります。これにより、手動での介入なしに [予想インスタンス数] が自動的かつ正確に更新されます。[予想インスタンス数] を減らすだけではランダムなスケールインがトリガーされ、リリースしたい特定のインスタンスが対象にならない可能性があります。

既存ノードの追加がタイムアウトエラーで失敗した場合の対処方法

1. 接続性の確認：ノードが API サーバーの Classic Load Balancer (CLB) インスタンスにネットワークアクセスできることを確認します。

2. セキュリティグループ：セキュリティグループのルールが必要なトラフィックを許可していることを確認します。既存ノードを追加するための「セキュリティグループの制限」をご参照ください。

3. 一般的なネットワーク：より複雑な問題については、「ネットワーク管理のよくある質問」をご参照ください。

ACK クラスターのワーカーノードのホスト名を変更する方法

次に、以下を実行します。

1. クラスターからノードを削除します。

2. 削除したノードをノードプールに再度追加します。手順については、「ノードの手動追加」をご参照ください。

   ノードは、クラスターに再参加する際に、ノードプールの命名テンプレートに基づいて自動的に名前が変更されます。

GPU ノードのカーネルと NVIDIA ドライバーを手動でアップグレードする方法

1. クラスターへの接続：クラスターの kubeconfig を取得し、kubectl を使用してクラスターに接続します。

2. ノードの cordon (スケジューリング無効化)：ターゲットの GPU ノードに新しい Pod がスケジューリングされないようにします。この例では、ノード cn-beijing.i-2ze19qyi8votgjz***** を使用します。

   kubectl cordon cn-beijing.i-2ze19qyi8votgjz*****
   
   node/cn-beijing.i-2ze19qyi8votgjz***** already cordoned

3. ノードの drain (退避)：既存の Pod を他のノードに退避させます。

   kubectl drain cn-beijing.i-2ze19qyi8votgjz***** --grace-period=120 --ignore-daemonsets=true
   
   node/cn-beijing.i-2ze19qyi8votgjz***** cordoned
   WARNING: Ignoring DaemonSet-managed pods: flexvolume-9scb4, kube-flannel-ds-r2qmh, kube-proxy-worker-l62sf, logtail-ds-f9vbg
   pod/nginx-ingress-controller-78d847fb96-***** evicted

4. 現在の NVIDIA ドライバーのアンインストール：

   説明

   この例ではバージョン 384.111 を使用しています。実際のバージョンに置き換えてください。

   1. GPU ノードにログインし、nvidia-smi コマンドを実行してドライバーのバージョンを確認します。

      sudo nvidia-smi -a | grep 'Driver Version'
      Driver Version                      : 384.111

   2. NVIDIA から対応するインストーラーをダウンロードしてアンインストールを実行します。

      cd /tmp/
      sudo curl -O https://cn.download.nvidia.cn/tesla/384.111/NVIDIA-Linux-x86_64-384.111.run

      説明

      NVIDIA ドライバーをアンインストールするには、インストールパッケージを使用する必要があります。

   3. 現在の NVIDIA ドライバーをアンインストールします。

      sudo chmod u+x NVIDIA-Linux-x86_64-384.111.run
      sudo sh ./NVIDIA-Linux-x86_64-384.111.run --uninstall -a -s -q

5. カーネルのアップグレード。

   必要に応じてカーネルをアップグレードできます。

6. GPU ノードの再起動。

   sudo reboot

7. カーネルヘッダーのインストール：再度 GPU ノードにログインし、対応する kernel-devel をインストールします。

   sudo yum install -y kernel-devel-$(uname -r)

8. 新しい NVIDIA ドライバーのインストール：NVIDIA のウェブサイトにアクセスして、必要な NVIDIA ドライバーをダウンロードしてインストールします。この例ではバージョン 410.79 を使用します。

   # /tmp ディレクトリに移動
   cd /tmp/
   
   # NVIDIA ドライバーインストーラーをダウンロード
   sudo curl -O https://cn.download.nvidia.cn/tesla/410.79/NVIDIA-Linux-x86_64-410.79.run
   
   # インストーラーを実行可能にする
   sudo chmod u+x NVIDIA-Linux-x86_64-410.79.run
   
   # サイレントモードでインストーラーを実行
   sudo sh ./NVIDIA-Linux-x86_64-410.79.run -a -s -q
   
   # GPU をウォームアップ
   sudo nvidia-smi -pm 1 || true
   sudo nvidia-smi -acp 0 || true
   sudo nvidia-smi --auto-boost-default=0 || true
   sudo nvidia-smi --auto-boost-permission=0 || true
   sudo nvidia-modprobe -u -c=0 -m || true

9. 永続化モードの設定：次の GPU ウォームアップ設定が /etc/rc.d/rc.local にあることを確認します。必要に応じて手動で追加してください。

   sudo nvidia-smi -pm 1 || true
   sudo nvidia-smi -acp 0 || true
   sudo nvidia-smi --auto-boost-default=0 || true
   sudo nvidia-smi --auto-boost-permission=0 || true
   sudo nvidia-modprobe -u -c=0 -m || true

10. サービスの再起動：

    sudo service kubelet stop
    sudo service docker restart
    sudo service kubelet start

11. GPU ノードの uncordon (スケジューリング有効化)：

    kubectl uncordon cn-beijing.i-2ze19qyi8votgjz*****
    
    node/cn-beijing.i-2ze19qyi8votgjz***** already uncordoned

12. 確認：nvidia-device-plugin Pod 内で nvidia-smi を実行してバージョンを確認します。

    kubectl exec -n kube-system -t nvidia-device-plugin-cn-beijing.i-2ze19qyi8votgjz***** nvidia-smi
    Thu Jan 17 00:33:27 2019
    +-----------------------------------------------------------------------------+
    | NVIDIA-SMI 410.79       Driver Version: 410.79       CUDA Version: N/A      |
    |-------------------------------+----------------------+----------------------+
    | GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
    | Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
    |===============================+======================+======================|
    |   0  Tesla P100-PCIE...  On   | 00000000:00:09.0 Off |                    0 |
    | N/A   27C    P0    28W / 250W |      0MiB / 16280MiB |      0%      Default |
    +-------------------------------+----------------------+----------------------+
    
    +-----------------------------------------------------------------------------+
    | Processes:                                                       GPU Memory |
    |  GPU       PID   Type   Process name                             Usage      |
    |=============================================================================|
    |  No running processes found                                                 |
    +-----------------------------------------------------------------------------+

    説明

    docker ps コマンドを実行して GPU ノードでコンテナが起動していないことがわかった場合は、「GPU ノードでのコンテナ起動の失敗を修正する」をご参照ください。

GPU ノードでのコンテナ起動の失敗を修正する方法

sudo service kubelet stop
# /bin/systemctl stop kubelet.service にリダイレクトしています
sudo service docker stop
# /bin/systemctl stop docker.service にリダイレクトしています
sudo service docker start
# /bin/systemctl start docker.service にリダイレクトしています
sudo service kubelet start
# /bin/systemctl start kubelet.service にリダイレクトしています

sudo docker ps
# 出力: CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

sudo docker info | grep -i cgroup

Cgroup Driver: cgroupfs

解決策

1. Docker 構成の更新：Cgroup ドライバーを systemd に合わせ、NVIDIA コンテナランタイムがデフォルトとして設定されていることを確認する必要があります。

   1. 既存の構成 (/etc/docker/daemon.json ファイル) をバックアップします。

   2. 修正された構成を適用します：次のコマンドを実行して、/etc/docker/daemon.json を必要な設定で上書きします。

      sudo cat >/etc/docker/daemon.json <<-EOF
      {
          "default-runtime": "nvidia",
          "runtimes": {
              "nvidia": {
                  "path": "/usr/bin/nvidia-container-runtime",
                  "runtimeArgs": []
              }
          },
          "exec-opts": ["native.cgroupdriver=systemd"],
          "log-driver": "json-file",
          "log-opts": {
              "max-size": "100m",
              "max-file": "10"
          },
          "oom-score-adjust": -1000,
          "storage-driver": "overlay2",
          "storage-opts":["overlay2.override_kernel_check=true"],
          "live-restore": true
      }
      EOF

2. 変更を有効にするためにサービスを再起動します。

   sudo service kubelet stop
   # /bin/systemctl stop kubelet.service にリダイレクトしています
   sudo service docker restart
   # /bin/systemctl restart docker.service にリダイレクトしています
   sudo service kubelet start
   # /bin/systemctl start kubelet.service にリダイレクトしています

3. Cgroup ドライバーが正常に systemd に切り替わったことを確認します。

   sudo docker info | grep -i cgroup
   Cgroup Driver: systemd

ノードに障害が発生した場合、再デプロイのために Pod を一括で移行する方法

障害が発生したノードをスケジューリング不可に設定し、それを退避させてアプリケーション Pod を正常なノードに移動させることができます。

1. ACK コンソールにログインします。

2. [ノード] ページで、管理したいノードを見つけます。[操作] 列で、[その他] > [退避] を選択します。この操作により、古いノードがスケジューリング不可に設定され、アプリケーションが古いノードから新しいノードに徐々に移行されます。

3. 障害が発生したノードのトラブルシューティングを行います。トラブルシューティングの詳細については、「ノードの問題のトラブルシューティング」をご参照ください。

複数のゾーンにまたがるノードを持つクラスターで障害が発生した場合、クラスターはどのようにノードの退避ポリシーを決定しますか？

通常、ノードに障害が発生すると、ノードコントローラーは異常なノードから Pod を退避させます。デフォルトの退避率 --node-eviction-rate は 1 秒あたり 0.1 ノードです。これは、10 秒ごとに最大 1 つの Pod がノードから退避されることを意味します。

ただし、複数のゾーンにノードを持つ ACK クラスターで障害が発生した場合、ノードコントローラーはゾーンの健全性とクラスターのサイズに基づいて退避ポリシーを決定します。

ゾーンの健全性状態には 3 つのタイプがあります。

• FullDisruption：ゾーンに正常なノードがなく、少なくとも 1 つの異常なノードがある。

• PartialDisruption：ゾーンに少なくとも 2 つの異常なノードがあり、異常なノードの割合 ((異常なノード数 / (異常なノード数 + 正常なノード数)) として計算) が 0.55 を超える。

• Normal：上記のいずれでもない。

ノードコントローラーの退避率は、3 つのゾーンの健全性状態に基づいて次のように計算されます。

• すべてのゾーンが FullDisruption 状態にある場合、クラスター全体の退避機能は無効になります。

• 一部のゾーンが FullDisruption 状態にある場合、クラスターのサイズに関係なく、退避率は通常の値 (0.1) に設定されます。

• ゾーンが PartialDisruption 状態にある場合、退避率はクラスターのサイズに影響されます。

  • 大規模クラスター (>50 ノード)：退避率は 0.01/s に低下します。

  • 小規模クラスター (≤50 ノード)：ゾーンの退避率は 0 になり、退避は発生しません。

• ゾーンが Normal 状態にある場合、クラスターのサイズに関係なく、退避率は通常の値 (0.1) に設定されます。

詳細については、「退避のレート制限」をご参照ください。

kubelet のディレクトリパスをカスタマイズできますか？

いいえ。kubelet のパスは /var/lib/kubelet に固定されており、ACK でカスタマイズすることはできません。

ACK ノードプールでデータディスクをカスタムディレクトリにマウントできますか？

この機能は現在カナリアリリース中です。この機能を利用するには、してください。

有効にすると、ディスクをフォーマットして特定のパスにマウントできますが、次の制限があります。

• 次の予約済み OS ディレクトリにはマウントしないでください。

  • /

  • /etc

  • /var/run

  • /run

  • /boot

• システムおよびコンテナランタイムが使用する次のディレクトリ、またはそのサブディレクトリにはマウントしないでください。

  • /usr

  • /bin

  • /sbin

  • /lib

  • /lib64

  • /ostree

  • /sysroot

  • /proc

  • /sys

  • /dev

  • /var/lib/kubelet

  • /var/lib/docker

  • /var/lib/containerd

  • /var/lib/container

• 異なるデータディスクのマウントディレクトリは一意でなければなりません。

• マウントディレクトリは / で始まる絶対パスでなければなりません。

• マウントディレクトリには、復帰または改行文字 (C スタイルのエスケープ文字 \r および \n) を含めることはできず、バックスラッシュ (\) で終わることはできません。

ファイル記述子の最大数を変更する方法

ファイル記述子の最大数は、同時に開くことができるファイルの最大数です。Alibaba Cloud Linux および CentOS システムには、2 つのレベルの制限があります。

• システムレベル：すべてのユーザーのプロセスが同時に開くことができるファイルの最大数。

• ユーザーレベル：単一のユーザープロセスが開くことができるファイルの最大数。

コンテナ環境では、コンテナ内の単一プロセスに対するファイル記述子の最大数という別の制限があります。

ノードプールに属していないワーカーノードのコンテナランタイムをアップグレードする方法

ノードプール機能が導入される前に作成されたレガシークラスターには、フリーのワーカーノードが存在する場合があります。これらのノードのコンテナランタイムをアップグレードするには、まずそれらをノードプールに移行する必要があります。

手順：

1. ノードプールの作成：適切なノードプールが存在しない場合は、フリーノードと同じ構成でノードプールを作成します。

2. ノードの削除：ノードの削除プロセス中に、システムはノードをスケジューリング不可に設定し、退避させます。退避に失敗した場合、システムは自動的にノードを cordon (スケジューリング無効化) し、drain (退避) 操作を実行して Pod を退避させます。退避に成功した場合、ノードはクラスターから削除されます。

3. 既存ノードの追加：ターゲットノードを既存のノードプールに追加します。ノードがクラスターに再参加すると、そのコンテナランタイムはノードプールの構成で指定されたランタイムに自動的に更新されます。

   説明

   ノードプール機能自体は無料ですが、基盤となる ECS インスタンスやその他のクラウドリソースに対しては課金されます。詳細については、「クラウドリソース料金」をご参照ください。

コンソールでノードプールのソースが その他のノード と表示される理由

ACK では、コンソール、OpenAPI、または CLI を介してコンピューティングリソースを追加できます (「既存ノードの追加」をご参照ください)。ACK の標準的なライフサイクル管理で認識されないカスタムメソッドでノードを追加した場合、コンソールはそれらを その他のノード グループに分類します。

ACK はこれらのノードをノードプールを通じて管理できないため、自動化された O&M、ライフサイクル管理、保証された技術サポートなどの機能は利用できません。

これらのノードを引き続き使用したい場合は、クラスターアドオンとの互換性を確保し、潜在的なリスクを負う必要があります。これらのリスクには、以下が含まれますが、これらに限定されません。

• バージョンの非互換性：コントロールプレーンまたはシステムコンポーネントのアップグレード中に、これらのノード上の OS および常駐コンポーネントが新しいバージョンと互換性がなくなり、サービス中断のリスクが生じる可能性があります。

• スケジューリングの競合：クラスターがこれらのノードのアベイラビリティゾーンやリソースの残容量を正確に報告できない場合があります。これにより、不適切なワークロードのスケジューリングやパフォーマンスの低下につながる可能性があります。

• データプレーンの不一致：ノード側のコンポーネント/OS とクラスターコントロールプレーン間の互換性が検証されていないため、安定性のリスクがあります。

• O&M の失敗：これらのノードの基盤となる管理チャネルが未検証であるため、ACK コンソールまたは OpenAPI を介して実行されるメンテナンス操作が失敗したり、予期しない結果を生んだりする可能性があります。

クラスターノードが使用する vSwitch のネットワーク ACL を設定する方法

ノードプールの vSwitch にアクセス制御リスト (ACL) が関連付けられている場合、特定の CIDR ブロックを明示的に許可する必要があります。そうしないと、新しいノードがクラスターに参加できなかったり、失敗 または オフライン 状態で表示されたりします。

トラフィックを許可し、ノードを再追加する手順：

1. ネットワーク ACL ルールの設定：インバウンド と アウトバウンド の両方のルールが、次の CIDR ブロックのトラフィックを許可していることを確認します。

   • 100.104.0.0/16：ACK コントロールプレーン管理 CIDR。

   • 100.64.0.0/10：Alibaba Cloud 内部サービス CIDR。

   • 100.100.100.200/32：ECS メタデータサービスアドレス。

   • VPC/vSwitch CIDR：VPC のプライマリおよびセカンダリ CIDR ブロック、またはノードの vSwitch の特定の CIDR。

2. 障害のあるノードの削除：ACL ルールが適用される前に 失敗 または オフライン 状態だったノードを削除します。

3. ノードプールの作成 または 既存のノードプールの拡張：ノードのステータスが Ready に移行した場合、ネットワーク ACL ルールは正しく設定されています。