Oracle Cloud Infrastructureドキュメント

ノードとポッドに関する一般的な問題

Container Engine for Kubernetes (OKE)を使用して作成したクラスタ上のノードおよびポッドに関する一般的な問題を識別および修正する方法を確認します。

Container Engine for Kubernetesを使用して作成したクラスタ上のノードおよびポッドでこれらの問題が発生する場合があります。

リソース不足のため、応答しないワーカー・ノードまたはポッド(あるいはその両方)が「保留中」状態でスタックしました

Container Engine for Kubernetesを使用して作成したクラスタ上のノードおよびポッドに関する次の問題が発生する場合があります:

  • 応答しないワーカー・ノード。
  • kubectl get nodeコマンドに応答してステータスがNotReadyと表示されるワーカー・ノード。
  • ポッドが保留状態でスタックし、FailedScheduling due to Insufficient cpuや FailedScheduling due to Insufficient memoryなどのメッセージが表示されています。

これらの問題の原因として、KubernetesおよびOSシステム・デーモンのシステム・リソースが不足している可能性があります。

--kube-reservedおよび--system-reserved kubeletフラグを使用して、Kubernetesシステム・デーモン(kubeletやcontainer runtimeなど)およびOSシステム・デーモン(sshdやsystemdなど)のCPUおよびメモリー・リソースをそれぞれ予約することをお薦めします。例:

  • --kube-reserved=cpu=500m,memory=1Gi
  • --system-reserved=cpu=100m,memory=100Mi

ワーカー・ノードで実行されているポッドは、使用可能なすべてのCPUおよびメモリー・リソースを消費できるため、他の重要なプロセス(KubernetesやOSシステム・デーモンなど)がノードで実行されないようにできます。KubernetesおよびOSシステム・デーモンを実行できない場合、ワーカー・ノードが応答しなくなり、不安定になり、負荷が高くなると予期せずクラッシュする可能性があります。

KubernetesおよびOSシステム・デーモンで必要なリソースをリクエストするポッドを防ぐには、--kube-reservedおよび--system-reserved kubeletフラグをkubelet-extra-argsオプションとしてカスタムcloud-initスクリプトに含めます。詳細および例は、例4: カスタムCloud-initスクリプトを使用したKubernetesおよびOSシステム・デーモンのリソースの予約を参照してください。

--kube-reserved kubeletフラグを使用して、Kubernetesシステム・デーモンで使用するワーカー・ノードのCPUおよびメモリー・リソースの一部を予約する場合は、次の推奨事項を考慮してください:

  • Kubernetesシステム・デーモン用に予約するCPUリソースの量は、次の表に示すように、ワーカー・ノード上のCPUコアの数によって異なります:
    ワーカー・ノード上のCPUコア数 1 2 3 4 5 次より大きい5
    予約する推奨CPU(ミリコア(m) 60 m 70 m 80 m 85 m 90 m ワーカー・ノード上の追加コアごとに2.5m追加
  • Kubernetesシステム・デーモン用に予約するメモリー・リソースの量は、次の表に示すように、ワーカー・ノード上のメモリー量によって異なります。
    ワーカー・ノードのメモリー(GiB) 4 GiB 8 GiB 16 GiB 128 GiB 128以上 GiB
    予約する推奨メモリー(GiB) 1 GiB 1 GiB 2 GiB 9 GiB ワーカー・ノード・メモリーの追加GiBごとに20個のMiBを追加

--system-reserved kubeletフラグを使用して、ノードのCPUおよびメモリー・リソースの一部をOSシステム・デーモンで使用するために予約する場合は、次の推奨事項を考慮してください。

  • OSシステム・デーモン(ノード・シェイプに関係なく)用に予約することをお薦めします。CPUリソースの量は100m (ミリコア)です。
  • OSシステム・デーモン用に予約することをお薦めします(ノード・シェイプに関係なく)メモリー・リソースの量は100Mi (MB)です。

--kube-reservedおよび--system-reserved kubeletフラグに対するCPUおよびメモリーの推奨事項は、実行するワークロードには最適ではない可能性があるため、それに応じて値を変更する必要がある場合があります。また、時間の経過とともに値を調整する必要がある場合もあります。

ワーカー・ノード上のリソース合計と、ワークロードで使用できるノード上のリソースの差異を確認するには、次のコマンドを実行します。

kubectl get node <NODE_NAME> -o=yaml | grep -A 6 -B 7 capacity

出力例:

  allocatable:
    cpu: 15743m
    ephemeral-storage: "34262890849"
    hugepages-1Gi: "0"
    hugepages-2Mi: "0"
    memory: 234972476Ki
    pods: "110"
  capacity:
    cpu: "16"
    ephemeral-storage: 37177616Ki
    hugepages-1Gi: "0"
    hugepages-2Mi: "0"
    memory: 257197372Ki
    pods: "110"

出力例の「容量」と「割り当て可能」のCPUとメモリーの違いには、KubernetesおよびOSシステム・デーモンのCPUとメモリーの予約が含まれます。

ノート

2024年6月から、この項で説明するKubernetesおよびOSシステム・デーモンのCPUおよびメモリー・リソース予約の推奨事項は、サポートされているすべてのKubernetesバージョンのすべてのOKEイメージのデフォルトとして使用されます。推奨事項は、Kubernetesバージョン1.30以降のすべてのプラットフォーム・イメージのデフォルトとしても使用されます。デフォルトは、2024年6月(またはそれ以降)にリリースされたOKEイメージを指定する場合と、クラスタで実行されているKubernetesのバージョンをバージョン1.30 (またはそれ以降)にアップグレードする場合の両方に適用されます。2024年6月(またはそれ以降)にリリースされたOKEイメージを指定する場合、またはクラスタをKubernetesバージョン1.30にアップグレードする場合は、実行するワークロードに適したデフォルトの予約を確認することをお薦めします。

仮想ノード・プールを作成すると、「APIサーバーにアクセスできません」というメッセージが表示されます

Container Engine for Kubernetesを使用して作成したクラスタに仮想ノード・プールを作成する場合、操作の作業リクエストIDの作業リクエスト・ログまたは作業リクエスト・エラーを表示すると、次のメッセージが表示されることがあります:

API Server Unreachable, Check network configuration and ensure network path between Virtual Node and API Server exist

このメッセージは、ネットワーク構成に問題があることを示します。仮想ノード・プール内の仮想ノードがKubernetes APIサーバーと通信できるようにネットワークが正しく構成されていることを再度確認します。適切なネットワーク構成については、Example Network Resource Configuration for Cluster with Virtual Nodesを参照してください。