クラスタ管理のベスト・プラクティス

Kubernetes Engine (OKE)で作成したクラスタを管理するためのベストプラクティスをご覧ください。

この項では、クラスタ管理およびKubernetesエンジンのベスト・プラクティスについて説明します。

ベスト・プラクティス: Kubernetesラベルを使用

Kubernetesラベルを使用して、クラスタを構成する多くのKubernetesリソース(サービス、ポッド、コンテナ、ネットワークなど)を編成することをお薦めします。

Kubernetesラベルは、これらのリソースを維持し、クラスタ内で相互にどのように相互作用するかを追跡するのに役立つキーと値のペアです。

たとえば、oci.oraclecloud.com/oke-is-preemptible=true label (Kubernetes Engineはプリエンプティブル・インスタンスでホストされるワーカー・ノードに適用)をKubernetesノード・セレクタおよびノード・アフィニティ/アンチアフィニティとともに使用して、それらのワーカー・ノードでスケジュールされるポッドを制御できます。

KubernetesドキュメントのWell-Known Labels、 Annotations and Taintsを参照してください。

ベスト・プラクティス: OCIリソース・タグ付けの使用

OCIリソース・タグ付けを使用して、Kubernetes Engineで作成するKubernetesクラスタで使用される多くのリソース(ワーカー・ノード、VCN、ロード・バランサ、ブロック・ボリュームなど)を編成することをお薦めします。テナンシ内の複数のコンパートメントに多数のリソースが分散されている場合、特定の目的で使用されるリソースを追跡することは困難です。同様に、リソースの集計、レポート、およびリソースに対するバルク・アクションの実行も困難です。

タグ付けでは、キーと値を定義して、リソースに関連付けることができます。その後、タグを使用すると、ビジネス・ニーズに基づいてリソースを編成してリストできるようになります。

Kubernetesクラスタ関連リソースのタグ付けを参照してください。

ベスト・プラクティス: リソース要求および制限の設定

次を設定することをお薦めします。

リソース・リクエスト: コンテナが使用できるリソースの最小量を指定します。
リソース制限。コンテナが使用できるリソースの最大量を指定します。

Kubernetesクラスタを操作する場合、一般的な課題は、そのクラスタ上のリソースの可用性が制限されているため、アプリケーションがクラスタにデプロイされない場合があることです。失敗の原因は、リソース・リクエストおよびリソース制限が設定されていないことです。

リソース・リクエストおよび制限を設定しない場合、クラスタ内のポッドは、必要以上に多くのリソースの使用を開始できます。ポッドがノード上でより多くのCPUまたはメモリーを消費し始めた場合、kubeスケジューラがノードに新しいポッドを配置できず、ノード自体がクラッシュすることもあります。

Kubernetesドキュメントのリクエストと制限を参照してください。

ベスト・プラクティス: 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にアップグレードする場合は、実行するワークロードに適したデフォルトの予約を確認することをお薦めします。

追加の推奨事項:

本番クラスタに予約変更を適用する前に、非本番環境での予約変更の影響を常にベンチマークしてテストします。
--eviction-hardまたは--eviction-softのkubeletフラグを使用して、メモリーおよびディスク不足の適切なしきい値を設定します。これらのしきい値を設定すると、Kubernetesシステムは、必要なときに重要度の低いポッドを削除することで、システムの安定性を保護できます。詳細は、Kubernetesドキュメントのノード圧力削除を参照してください。
リソースが多すぎると、ノードの使用率が低下する可能性があります。目標は、重要なコンポーネントのリソースの可用性を保証することと、ワークロードのリソース可用性を最大化することの間の適切なバランスを見つけることです。少ないリソース予約から始めてシステム不安定のリスクを冒すのではなく、大きいリソース予約から始めて、観察に基づいて予約サイズを徐々に減らすことをお薦めします。モニタリングおよびアラート・ツールのメトリックを使用して、Kubernetesおよびシステム・コンポーネントによるリソースの使用状況を経時的に監視します。
リソースを予約する場合は、ノード・シェイプとワークロード・タイプの違いを考慮してください。大きいノードでは、小さいノードよりも大きな絶対予約が必要になる場合があります。特定のリソース・ニーズまたは既知のバースト・パターンを持つワークロードでは、より大きなリソース予約または小さいリソース予約が必要になる場合があります。

リソースの予約の詳細は、Kubernetesドキュメントのシステム・デーモンのコンピュート・リソースの予約を参照してください。

ベスト・プラクティス: テイントと許容範囲を使用して専用ノードを提供

リソース集中型のアプリケーションを特定のワーカー・ノードに制限するには、Kubernetesのタイントと許容範囲を使用することをお薦めします。

テイントと許容範囲を使用すると、ノード・リソースを必要とするワークロードに対してノード・リソースを使用できるようにし、ノード上の他のワークロードのスケジューリングを回避できます。

たとえば、Kubernetes Engineを使用してクラスタを作成する場合、GPUシェイプを持つワーカー・ノード、または多数の強力なCPUを持つシェイプを定義できます。これらの適切に指定されたワーカー・ノードは、大規模なデータ処理ワークロードに最適です。ただし、このような特殊なハードウェアは通常、デプロイにコストがかかります。そのため、通常、これらのノードでスケジュールできるワークロードを制限します。適切に指定されたワーカー・ノードでスケジュールできるワークロードを制限するには、ノードに色合いを追加します。たとえば、次のいずれかのコマンドを実行します。

kubectl taint nodes <node-name> special=true:NoSchedule
kubectl taint nodes <node-name> special=true:PreferNoSchedule

適切に指定されたワーカー・ノードに色合いを追加したら、ノードの使用を許可するポッドに対応する許容範囲を追加します。

同様に、oci.oraclecloud.com/oke-is-preemptible=true label (Kubernetes Engineがプリエンプティブル・インスタンスでホストされているワーカー・ノードに適用)をKubernetes許容値とともに使用して、それらのワーカー・ノードでスケジュールされるポッドを制御できます。

KubernetesドキュメントのTaints and Tolerationsを参照してください。

ベスト・プラクティス: ノード・セレクタおよびアフィニティを使用したポッド・スケジューリングの制御

特定のノードで実行するようにポッドを制限したり、特定のノードで実行するポッドのプリファレンスを指定したりするには、いくつかの方法があります。推奨されるアプローチはすべて、選択を容易にするためにラベルセレクタを使用します。多くの場合、kube-schedulerは、そのような制約や好みなしに合理的な配置を自動的に行います。ただし、ポッドが実行されるノードを制御する必要がある場合があります。

このような状況では、Kubernetesノード・セレクタ、ノード・アフィニティおよびポッド間アフィニティを使用して、ノード上のポッドのスケジューリングを制御することをお薦めします。

ノード・セレクタ、ノード・アフィニティおよびポッド間アフィニティを使用すると、kubeスケジューラでノードのハードウェアなどのワークロードを論理的に分離できます。

たとえば、ノードにローカルに接続されたSSDストレージがあることを示すラベルを付けることができます。ポッドを指定するには、ローカルにSSDストレージが接続されたノードでのみ実行するようにし、そのラベルをノード・セレクタとしてポッド仕様に含めます。Kubernetesは、一致するラベルを持つノード上のポッドのみをスケジュールします。

Kubernetesのドキュメントの、ノードへのポッドの割当てを参照してください。

ベスト・プラクティス: バックアップおよびディザスタ・リカバリにサードパーティ・ツールを使用

バックアップおよびディザスタ・リカバリには、Kubernetes Engineでサードパーティ・ツール(Kasten、Rancher、Trilio、Veleroなど)を使用することをお薦めします。

これらのツールとKubernetes Engineのバックアップおよびディザスタ・リカバリ機能を組み合せることで、本番対応の信頼性が高く、堅牢でスケーラブルなKubernetesプラットフォームを実現できます。

たとえば、Kasten by Veeamによるリージョン間のKubernetesディザスタ・リカバリのシンプルなガイドを参照してください。

Oracle Cloud Infrastructureドキュメント