OKEのベスト・プラクティス

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

クラスタのアップグレード

クラスタは、OKEで現在サポートされているKubernetesのバージョンが常に実行されるようにアップグレードしたままにします。クラスタを表示すると、そのクラスタに対して新しいKubernetesバージョンが使用可能かどうかが示されます。「サポートされているバージョンのKubernetes」および「OKEクラスタの更新」を参照してください。

Kubernetesラベルを使用します。

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

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

リソース・タグ付けを使用します。

リソース・タグ付けを使用して、「Kubernetesエンジン」で作成したKubernetesクラスタで使用される多数のリソース(ワーカー・ノード、VCNs、ロード・バランサ、ブロック・ボリュームなど)を編成します。

テナンシ内の複数のコンパートメントに多数のリソースが分散されている場合、特定の目的で使用されるリソースの追跡が困難な場合があります。また、リソースの集計、レポート、およびリソースに対するバルク・アクションの実行が困難な場合もあります。

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

詳細は、「Oracle Private Cloud Applianceユーザー・ガイド」の「リソース・タグ管理」の章を参照してください。

リソースのリクエストと制限を設定します。

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

そのクラスタ上のリソースが制限されているため、アプリケーションがKubernetesクラスタへのデプロイに失敗することがあります。アプリケーションのデプロイの失敗は、リソース・リクエストおよびリソース制限を正しく設定することで回避できます。

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

詳細は、kubernetes.ioサイトの「ポッドおよびコンテナのResource Management」を参照してください。

テイントと公差を使用して専用ノードを提供します。

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

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

詳細は、kubernetes.ioサイトの「テインツと寛容」を参照してください。

ノード・セレクタおよびアフィニティを使用して、ポッド・スケジューリングを制御します。

特定のノードで実行するようにポッドを制限したり、特定のノードで実行するポッドのプリファレンスを指定したりするには、いくつかの異なるメソッドを使用できます。すべての推奨アプローチでは、ラベル・セレクタを使用してノード選択を指定します。

制約およびプリファレンスが指定されていない場合、kube-schedulerは妥当な配置を行います。ただし、ポッドが実行されるノードを制御する必要がある場合があります。このような状況では、Kubernetesノード・セレクタ、ノード・アフィニティおよびポッド間アフィニティを使用して、ノード上のポッドのスケジューリングを制御することがベスト・プラクティスです。

ノード・セレクタ、ノード・アフィニティおよびポッド間アフィニティを使用すると、kube-schedulerは、ノードのハードウェアに従ってワークロードを論理的に分離できます。

バックアップおよびディザスタ・リカバリにはサードパーティ・ツールを使用します。

バックアップおよびディザスタ・リカバリには、「ベレロ」や「Kubernetesエンジン」などのサード・パーティ・ツールを使用します。

これらのツールと「Kubernetesエンジン」のバックアップ機能とディザスタ・リカバリ機能を組み合せることで、本番環境に対応した、信頼性が高く堅牢でスケーラブルなKubernetesプラットフォームを提供できます。

ネットワークのベスト・プラクティス

チームごとに個別のコンパートメントを作成します。

複数のチームがクラスタを作成することが予想される場合は、チームごとに個別のコンパートメントを作成します。

VCNのサイズを適切に調整します。

Kubernetesクラスタを作成およびデプロイするVCNのサイズ設定時に、将来のクラスタおよびノード・プールのスケーリング要件を考慮できます。

VCNに、クラスタに必要なすべてのリソースにネットワーク・アドレスを割り当てるのに十分な大きさのCIDRブロックがあることを確認: サブネット、Kubernetes APIエンドポイント、ワーカー・ノード、ポッド、ロード・バランサ。

あなたのニーズに最も適したネットワーキングCNIプラグインを選択します。

ネットワーキングの要件を慎重に検討し、あなたのニーズに最も適したネットワーキングCNIプラグインを選択します。

アプリケーションでベース・ネットワーキング要件の使用(VCNからのIPアドレスの使用ではなく)が必要な場合、またはワーカー・ノードごとに高密度ポッドが必要な場合、ベスト・プラクティスは「フランネル・オーバーレイ」 CNIプラグインを使用することです。「フランネル・オーバーレイ・ネットワーク・リソースの作成」を参照してください。
アプリケーションで、ポッドにVCN CIDRからのIPアドレスが必要な場合、または(ポッドが実行されているノードに関係なく)仮想マシンによって提供される一貫したネットワーク・パフォーマンスが、追加のオーバーレイなしで必要な場合、ベスト・プラクティスは「OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグイン」を使用することです。「VCNネイティブ・ポッド・ネットワーキング・リソースの作成」を参照してください。

アプリケーションの公開時にexternalTrafficPolicyを適切に構成します。

タイプがLoadBalancerのKubernetesサービスに対してネットワーク・ロード・バランサをプロビジョニングする場合は、externalTrafficPolicy設定に最も適した値を慎重に検討してください。

ポッドおよびサービスCIDRブロックがオンプレミスのCIDRブロックと重複しないようにし、「フランネル・オーバーレイ」 CNIプラグインを使用する場合。

IPアドレスを持つポッドおよびサービスをプロビジョニングするために「フランネル・オーバーレイ」ネットワークによって使用されるCIDRブロックが、外部コンピュート・インスタンスをIPアドレスでプロビジョニングするために使用されるCIDRブロックと重複している状況を回避します。

Kubernetesクラスタでは、ポッドごとに一意のIPアドレスが必要です。したがって、アドレスはオンプレミスまたは他の接続されたVCNsで使用されているプライベートIPアドレス空間と重複できないため、IPアドレスの計画が必要です。

必要なノードの数を計画します。

ノード・サイズ、ポッドのアプリケーション・プロファイルおよび選択したポッド・ネットワーキングCNIプラグインを考慮するクラスタ内のノード数の計画を作成します。

サブネットとセキュリティ・ルールを別々に使用します。

ネットワーク・リソースを構成するときは、別々のサブネットとセキュリティ・ルールを使用します。クラスタを作成してデプロイするVCNには、少なくとも2つの異なるサブネットがあり、さらに次のものを含めることができます:

Kubernetes APIエンドポイント・サブネット
ワーカー・ノード・サブネット
1つのリージョン別、または2つのAD固有のロード・バランサ・サブネット(オプション)
ポッド・サブネット(「OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグイン」を使用する場合)
バスチョン・サブネット(オプション)

サブネットを組み合せたり、セキュリティ・ルールを組み合せたりすることもできます。ただし、この方法ではセキュリティの管理が難しくなるため、ネットワーク・セキュリティ・グループを使用してクラスタへのアクセスを制御しないかぎり、お薦めしません。

セキュリティに関するベスト・プラクティス

エクスポージャ・レベルを計画します。

Kubernetesエンジンを使用して作成したクラスタのセキュリティ計画を実装する前に、次の質問に回答してください:

クラスタにはどのくらいのインターネット・エクスポージャが必要ですか。
ワークロードをVCNに内部的に、およびインターネットに外部的に公開するには、どのようにしますか。
ワークロードをどのように拡張する予定ですか。
クラスタが消費するOracleサービスのタイプはどれですか。

プライベート・クラスタを作成します。

クラスタがインターネットからの直接アクセスを必要としない場合は、プライベート・クラスタを作成します。プライベート・クラスタでは、Kubernetes APIサーバーおよびワーカー・ノードにはプライベートIPアドレスのみが割り当てられます。

オプションで、アウトバウンド・インターネット・アクセスにNATゲートウェイを使用し、オンプレミス・ネットワークからのアクセスを有効にするDynamic Routing Gateway (DRG)、他のVCNsからのアクセスを許可するローカル・ピアリング・ゲートウェイ(LPG)を使用します。

すべてのアプリケーションをプライベート・サブネットに配置します。

ワーカー・ノードで実行されているアプリケーションがインターネットへの直接アクセスを必要としない場合、ワーカー・ノード・サブネットとワーカー・ロード・バランサ・サブネットの両方がプライベートである必要があります。

ネットワーク・セキュリティ・グループを使用してクラスタ・トラフィックを制限します。

クラスタを作成およびデプロイするVCNのセキュリティ・リストではなく、ネットワーク・セキュリティ・グループ(NSG)にセキュリティ・ルールを定義します。「Oracle Private Cloud Applianceユーザーズ・ガイド」の「ネットワーク」の章の「VCNルールおよびオプションの構成」のネットワーク・セキュリティ・グループによるトラフィックの制御に関する項を参照してください。

一般的なセキュリティのベスト・プラクティス。

セキュリティ・パッチを定期的に適用します。
Kubernetesネットワーク・ポリシーとNSGの組合せを使用します。
NSGは、infrastructure-as-codeツール(Terraformなど)とともに使用します。
シークレットと証明書を定期的にローテーションします。
すべてのアプリケーションを非特権ユーザーとして実行します。
コンテナを不変として扱います。

監査、ロギングおよびモニタリング。

ログを定期的に確認します。
監査ロギングを有効にします。
Kubernetesクラスタ・ベースのロギングを使用します。
クラスタ・コンポーネントの監視。
ネットワーク・トラフィック・メタデータを記録し、定期的に分析します。
小規模でセキュアなコンテナ・イメージを使用します。
資格証明エクスポージャを制限します。

ストレージのベスト・プラクティス

適切なストレージ・タイプを選択します。
ストレージ・クラスを作成して使用し、アプリケーションのニーズを定義します。
永続ストレージのボリュームを作成および使用します。
ストレージ・リソースの消費を制限します。
データを保護およびバックアップします。

アップグレードのベスト・プラクティス

サポートされている最新バージョンのKubernetesを使用します。
テスト環境と本番環境を設定します。
メンテナンスに備えてワーカー・ノードをコードンおよびドレインします。
ワーカー・ノードを不変として処理します。

3 OKEベスト・プラクティス