Container Service for Kubernetes:ノードとノードプールの FAQ

目次

ノードの問題の診断とトラブルシューティング、および一般的な問題と解決策については、「ノードの問題のトラブルシューティング」をご参照ください。

ノードプールでスポットインスタンスを使用するにはどうすればよいですか？

単一のノードプールに複数の ECS インスタンスタイプを設定できますか？

はい、できます。ノードプールに複数の vSwitch を設定し、異なるゾーンにまたがる複数の ECS インスタンスタイプを選択できます。また、vCPU やメモリなどのディメンションに基づいてインスタンスタイプを設定することもできます。これにより、利用できないインスタンスタイプや在庫不足によるノードのスケールアウトの失敗を防ぐことができます。コンソールの弾力性スコアの推奨に基づいてインスタンスタイプを追加できます。また、作成後にノードプールの弾力性スコアを表示することもできます。

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

ノード上の Pod の最大数はどのように計算されますか？

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

• Terway: 単一ノードがサポートできる Pod の最大数は、コンテナーネットワークを使用する Pod の最大数とホストネットワークを使用する Pod の数を足したものです。

• Flannel: ノード上の Pod の最大数は、クラスターの作成時に [ノード Pod 数] に設定した値です。

コンソールの [ノード] ページのノードリストで、Pod の最大数である [合計 Pod クォータ] を表示できます。

ノード上の Pod の最大数は変更できません。Pod の最大数に達した場合、ノードプールをスケールアウトして利用可能な Pod の数を増やすことができます。詳細については、「ノードで利用可能な Pod 数の調整」をご参照ください。

Pod の最大数に達した場合、利用可能な Pod の数を増やすにはどうすればよいですか？

ワーカーノード上の Pod の最大数はネットワークプラグインによって異なり、ほとんどの場合調整できません。Terway モードでは、ノード上の Pod の最大数は、Elastic Compute Service (ECS) インスタンスによって提供される Elastic Network Interface (ENI) の数に依存します。Flannel モードでは、ノード上の Pod の最大数は、クラスターの作成時に指定したクラスター構成に依存します。上限はクラスターの作成後に変更することはできません。クラスター内の Pod の数が上限に達した場合は、クラスター内のノードプールをスケールアウトして、クラスター内の Pod の数を増やすことをお勧めします。

詳細については、「ノードで利用可能な Pod 数の調整」をご参照ください。

ノード構成を変更するにはどうすればよいですか？

• サービスの安定性を確保するため、一部の設定項目は作成後に変更できません。これは特に、ノードの可用性とネットワークに関連する構成に当てはまります。たとえば、コンテナーランタイムやノードが属する VPC は変更できません。

• 変更可能な設定項目については、ノードプール構成の更新は新しいノードにのみ適用されます。ノードプール内の既存ノードの構成は、[既存ノードの ECS タグを同期] や [既存ノードのラベルとテイントを同期] などの特定のシナリオを除き、変更されません。

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

新しい構成でノードを実行するには、目的の構成で新しいノードプールを作成します。次に、古いノードプール内のノードをスケジュール不可に設定し、ドレインします。すべてのサービスが新しいノードに移行された後、古いノードをリリースできます。詳細については、「ノードをドレインしてそのスケジューリングステータスを管理する」をご参照ください。

予想インスタンス数機能を無効にできますか？

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

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

予想インスタンス数が有効なノードプールとそうでないノードプールの違いは何ですか？

予想インスタンス数は、ノードプールが維持するように設定されているノードの数です。予想インスタンス数を調整することで、ノードプールをスケールアウトまたはスケールインできます。ただし、一部の古いノードプールでは、予想インスタンス数が設定されていなかったため、この機能が有効になっていません。

ノードの削除や ECS インスタンスのリリースなどの操作の動作は、予想インスタンス数機能が有効になっているノードプールとそうでないノードプールとで異なります。次の表に違いを示します。

管理されていないノードをノードプールに追加するにはどうすればよいですか？

ノードプール機能がリリースされる前に作成されたクラスターには、フリーノードが存在します。フリーノードが不要になった場合は、ノードのデプロイに使用されている Elastic Compute Service (ECS) インスタンスをリリースできます。フリーノードを保持したい場合は、ノードプールに追加することをお勧めします。これにより、ノードをグループで管理できます。

ノードプールを作成してスケールアウトし、管理されていないノードを削除してから、それらをノードプールに追加できます。詳細については、「管理されていないノードをノードプールに移行する」をご参照ください。

ノードプールの OS イメージを置き換えるにはどうすればよいですか？

必要に応じてオペレーティングシステムを切り替えることができます。たとえば、サポート終了 (EOL) に達したオペレーティングシステムをサポートされているものに置き換えることができます。続行する前に、「OS イメージのリリースノート」を参照して、サポートされている OS タイプ、最新の OS イメージバージョン、および一部のオペレーティングシステムの制限について学習してください。

オペレーティングシステムを置き換える際の考慮事項と具体的な手順の詳細については、「オペレーティングシステムの置き換え」をご参照ください。

特定の ECS インスタンスをリリースするにはどうすればよいですか？

特定の ECS インスタンスをリリースするには、ノードを削除する必要があります。ECS インスタンスがリリースされた後、予想インスタンス数は自動的に新しいノード数に調整されます。手動で変更する必要はありません。予想インスタンス数を変更しても、特定の ECS インスタンスはリリースされません。

既存のノードを追加した後にタイムアウトエラーが発生した場合はどうすればよいですか？

ノードが CLB ネットワーク経由で API Server に接続できるかどうかを確認します。まず、セキュリティグループが要件を満たしているかどうかを確認します。既存のノードを追加するときのセキュリティグループの制限の詳細については、上記の「制限」セクションをご参照ください。その他のネットワーク接続の問題については、「ネットワーク管理の FAQ」をご参照ください。

ACK クラスター内のワーカーノードのホスト名を変更するにはどうすればよいですか？

1. ノードを削除します。詳細については、「ノードの削除」をご参照ください。

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

   ノードが追加されると、ノードプールのノード命名規則に従って名前が付けられます。

既存のクラスターの GPU ノードでカーネルを手動でアップグレードするにはどうすればよいですか？

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

2. GPU ノードをスケジュール不可に設定します。この例では、ノード cn-beijing.i-2ze19qyi8votgjz12345 を使用します。

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

3. ドライバーをアップグレードする GPU ノードをドレインします。

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

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

   説明

   このステップでは、ドライバーバージョン 384.111 をアンインストールします。お使いのドライバーバージョンが 384.111 でない場合は、NVIDIA の公式 Web サイトから対応するドライバーインストールパッケージをダウンロードし、このステップで 384.111 を実際のバージョンに置き換えてください。

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

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

   2. NVIDIA ドライバーのインストールパッケージをダウンロードします。

      sudo 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 の公式 Web サイトにアクセスして、必要な NVIDIA ドライバーをダウンロードしてインストールします。この例では、バージョン 410.79 を使用します。

   sudo cd /tmp/
   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. /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. kubelet と Docker を再起動します。

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

11. GPU ノードを再度スケジュール可能に設定します。

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

12. GPU ノードのデバイスプラグイン Pod でバージョンを確認します。

    kubectl exec -n kube-system -t nvidia-device-plugin-cn-beijing.i-2ze19qyi8votgjz12345 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
Redirecting to /bin/systemctl stop kubelet.service
sudo service docker stop
Redirecting to /bin/systemctl stop docker.service
sudo service docker start
Redirecting to /bin/systemctl start docker.service
sudo service kubelet start
Redirecting to /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. /etc/docker/daemon.json ファイルをバックアップします。次に、次のコマンドを実行して /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. 次のコマンドを実行して、Docker と kubelet を再起動します。

   sudo service kubelet stop
   Redirecting to /bin/systemctl stop kubelet.service
   sudo service docker restart
   Redirecting to /bin/systemctl restart docker.service
   sudo service kubelet start
   Redirecting to /bin/systemctl start kubelet.service

3. 次のコマンドを実行して、Docker の Cgroup ドライバーが systemd であることを確認します。

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

ノードに障害が発生した場合、その Pod を一括で他のノードに移動して再デプロイするにはどうすればよいですか？

障害が発生したノードをスケジュール不可に設定し、ドレインすることができます。これにより、障害が発生したノードから新しいノードにアプリケーション Pod が徐々に移行されます。

1. Container Service for Kubernetes (ACK) コンソールにログインします。[ノード] ページで、管理するノードを見つけます。[アクション] 列で、[その他] > [ノードのドレイン] を選択します。この操作により、古いノードがスケジュール不可に設定され、アプリケーションが古いノードから新しいノードに徐々に移行されます。

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

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

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

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

ゾーン障害には 3 つのタイプがあります。

• FullDisruption: ゾーンに正常なノードがなく、少なくとも 1 つの異常なノードがあります。

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

• Normal: FullDisruption と PartialDisruption 以外のすべてのケース。

このシナリオでは、クラスターはサイズによって分類されます。

• 大規模クラスター: 50 を超えるノードを持つクラスター。

• 小規模クラスター: 50 以下のノードを持つクラスター。

ノードコントローラーのエビクションレートは、3 つの障害タイプに基づいて次のように計算されます。

• すべてのゾーンが FullDisruption 状態にある場合、システム内のすべてのゾーンでエビクション機能が無効になります。

• すべてのゾーンが FullDisruption 状態にあるわけではない場合、エビクションレートは次のように決定されます。

  • ゾーンが FullDisruption 状態にある場合、クラスターのサイズに関係なく、エビクションレートは通常の値 (0.1) に設定されます。

  • ゾーンが PartialDisruption 状態にある場合、エビクションレートはクラスターのサイズの影響を受けます。大規模クラスターでは、ゾーンのエビクションレートは 0.01 です。小規模クラスターでは、ゾーンのエビクションレートは 0 であり、エビクションは発生しません。

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

詳細については、「エビクションのレート制限」をご参照ください。

ACK クラスターの kubelet ディレクトリパスは何ですか？ カスタマイズできますか？

ACK は kubelet パスのカスタマイズをサポートしていません。デフォルトのパスは /var/lib/kubelet です。このパスは変更しないでください。

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 つのレベルのファイルハンドル制限があります。

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

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

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

ノードのシステムレベルのファイルハンドルの最大数を変更する

考慮事項と手順の詳細については、「ノードプールの OS パラメーターのカスタマイズ」をご参照ください。

ノード上の単一プロセスのファイルハンドルの最大数を変更する

1. ノードにログインし、/etc/security/limits.conf ファイルを表示します。

   cat /etc/security/limits.conf

   次のパラメーターを使用して、ノード上の単一プロセスのファイルハンドルの最大数を設定できます。

   ...
   root soft nofile 65535
   root hard nofile 65535
   * soft nofile 65535
   * hard nofile 65535

2. sed コマンドを実行して、ファイルハンドルの最大数を変更します。65535 が推奨値です。

   sed -i "s/nofile.[0-9]*$/nofile 65535/g" /etc/security/limits.conf

3. 再度ノードにログインし、次のコマンドを実行して変更が有効かどうかを確認します。

   返された値が設定した値と同じであれば、変更は成功です。

   # ulimit -n
   65535

コンテナーのファイルハンドルの最大数を変更する

1. ノードにログインし、次のコマンドを実行して構成ファイルを表示します。

   • containerd ノード: cat /etc/systemd/system/containerd.service

   • Docker ノード: cat /etc/systemd/system/docker.service

   コンテナー内の単一プロセスのファイルハンドルの最大数は、次のパラメーターによって設定されます。

   ...
   LimitNOFILE=1048576   ******単一プロセスのファイルハンドルの最大数
   LimitNPROC=1048576    ******プロセスの最大数
   ...

2. 次のコマンドを実行して、パラメーター値を変更します。1048576 は、ファイルハンドルの最大数の推奨値です。

   • containerd ノード:

      sed -i "s/LimitNOFILE=[0-9a-Z]*$/LimitNOFILE=65536/g" /etc/systemd/system/containerd.service;sed -i "s/LimitNPROC=[0-9a-Z]*$/LimitNPROC=65537/g" /etc/systemd/system/containerd.service && systemctl daemon-reload && systemctl restart containerd

   • Docker ノード:

     sed -i "s/LimitNOFILE=[0-9a-Z]*$/LimitNOFILE=1048576/g" /etc/systemd/system/docker.service;sed -i "s/LimitNPROC=[0-9a-Z]*$/LimitNPROC=1048576/g" /etc/systemd/system/docker.service && systemctl daemon-reload && systemctl restart docker

3. 次のコマンドを実行して、コンテナー内の単一プロセスのファイルハンドルの最大数を表示します。

   返された値が設定した値と同じであれば、変更は成功です。

   • containerd ノード:

     # cat /proc/`pidof containerd`/limits | grep files
     Max open files            1048576              1048576              files

   • Docker ノード:

     # cat /proc/`pidof dockerd`/limits | grep files
     Max open files            1048576              1048576              files

どのノードプールにも属していないワーカーノードのコンテナーランタイムをアップグレードするにはどうすればよいですか？

ACK ノードプール機能がリリースされる前に作成された古いクラスターには、管理されていないワーカーノードが含まれている場合があります。ノードのコンテナーランタイムをアップグレードするには、ノードをノードプールに追加して管理する必要があります。

次の手順に従ってください。

1. ノードプールを作成する: クラスターにノードプールがない場合は、管理されていないノードと同じ構成でノードプールを作成します。

2. ノードを削除する: ノードの削除プロセス中に、システムはノードをスケジュール不可に設定し、ドレインします。ドレインに失敗した場合、システムはノードの削除を停止します。ドレインに成功した場合、ノードはクラスターから削除されます。

3. 既存のノードを追加する: ターゲットノードを既存のノードプールに追加します。ゼロノードのノードプールを作成し、そこにターゲットノードを追加することもできます。ノードが追加されると、そのコンテナーランタイムは自動的にノードプールのものと一致するように変更されます。

   説明

   ノードプールは無料ですが、ECS インスタンスなどの使用するクラウドリソースに対しては課金されます。詳細については、「クラウドリソース料金」をご参照ください。

コンソールでノードが属するノードプールのソースとして「その他のノード」が表示されるのはなぜですか？

ACK は、コンソール、OpenAPI、コマンドラインインターフェイス (CLI) の使用など、クラスターに計算リソースを追加するための複数の方法を提供します。詳細については、「既存ノードの追加」をご参照ください。他の方法を使用してクラスターにノードを追加した場合、ACK はノードのソースを識別できません。[ノード] ページのノードリストには、このタイプのノードのノードプールとして [その他のノード] が表示されます。ACK はこれらのノードをノードプール経由で管理できず、ノードのライフサイクル管理、自動 O&M、技術サポートなどの機能を提供できません。

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

• バージョンの互換性: クラスターのコントロールプレーンとシステムコンポーネントがアップグレードされると、ノード上の既存のオペレーティングシステムとコンポーネントが新しいバージョンと互換性がない場合があります。これにより、サービス例外が発生する可能性があります。

• ワークロードスケジューリングの互換性: ゾーンや残りのリソースなど、報告されるノードオブジェクトの状態の正確性は保証されません。上位レイヤーのワークロードのスケジューリング構成が正しく適用されるかどうかを評価することはできません。これにより、可用性とパフォーマンスが低下する可能性があります。

• データプレーンの互換性: ノード側のコンポーネントとオペレーティングシステム、およびクラスターのコントロールプレーンとシステムコンポーネント間の互換性は評価されていません。これにより、互換性のリスクが生じる可能性があります。

• O&M 操作の互換性: コンソールまたは OpenAPI を使用してデータプレーンノードの O&M 操作を実行すると、ノードの O&M チャネルと実行環境が評価されていないため、操作が失敗したり、異常な結果が生じたりする可能性があります。