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

ベスト・プラクティス: チームごとに個別のコンパートメントを作成します

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

たとえば、Virtual Cloud Network (VCN)やKubernetes Engineに使用されるサブネットなどのネットワーク・リソースはすべてルート・コンパートメントに配置できます。ただし、複数のチームがクラスタを作成することが予想される場合は、各チームのクラスタ・リソース(ルート・コンパートメントの子コンパートメントなど)に個別のコンパートメントを作成することをお薦めします。理由は、クラスタとそのリソースがVCNおよびサブネットと同じコンパートメントに存在する必要がないため、各チームに個別のコンパートメントがあると、クラスタを分離し、セキュアに保つことが簡単かつクリーンになります。

クラスタの作成とデプロイメントのためのネットワーク・リソース構成を参照してください。

ベスト・プラクティス: VCNのサイズを適切に設定

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

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

VCN構成およびCIDRブロックおよびKubernetesエンジン(OKE)を参照してください。

ベスト・プラクティス: ニーズに最も適したポッド・ネットワーキングCNIプラグインを選択します

ポッドネットワーキングの要件を慎重に検討し、ニーズに最も適したポッドネットワーキングCNIプラグインを選択することをお勧めします。

例:

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

ポッド・ネットワーキングおよびCIDRブロックおよびKubernetesエンジン(OKE)を参照してください。

ベスト・プラクティス: アプリケーションの公開時にexternalTrafficPolicyを適切に構成します。

タイプLoadBalancerのKubernetesサービスのネットワーク・ロード・バランサをプロビジョニングする場合は、externalTrafficPolicy設定に最も適した値を慎重に考慮することをお薦めします:

• externalTrafficPolicy: Cluster (クラスタ・モード)

  分散が等しいサービスを実行しているすべてのポッドにトラフィックを常にルーティングし、クライアントIPアドレスを保持しない場合は、クラスタ・モードを指定します。クラスタ・モードでは、Kubernetesは、特定のポート上の任意のワーカー・ノードに送信されたすべてのトラフィックをそのサービスのポッドのいずれかに転送します。

  リクエスト・ルーティングはクラスタ内のポッドの状態に依存しないため、クラスタ・モードでは多くの場合、クラスタ内のバックエンドの解約が少なくなります。任意のリクエストは任意のノードに送信でき、Kubernetesはリクエストを適切な場所に取得します。クラスタ・モードでは、ワーカー・ノード間でネットワーク・ロード・バランサからロード・スパンが適切に行われます。トラフィックがワーカー・ノードに到達すると、ノードは同じ方法で処理されます。ロード・バランサは、クラスタ内のどのノードがそのサービスのポッドを実行しているかを認識しません。ワーカー・ノードのリージョナル・サブネットを選択した場合、ロードはサブネットのリージョンのすべての可用性ドメインのすべてのノードに分散されます。クラスタ・モードでは、関連するポッドが実行されていないノードであっても、クラスタ内のすべてのノードでトラフィックがロード・バランシングされます。

• externalTrafficPolicy: Local (ローカル・モード)

  IPパケットヘッダーで指定されたクライアントIPアドレスで要求を終了する場合は、ローカルモードを指定します。IPパケット・ヘッダーで指定されたクライアントIPアドレスでリクエストが終了した場合にのみ、クライアントIPアドレスを保持するオプションがあります。つまり、externalTrafficPolicy設定がLocalに設定されている場合です。

  ローカルモードでは、クラスタモードで必要な追加のネットワークホップが削除されますが、ネットワークが正しく構成されていない場合、ネットワークトラフィックが不均衡になる可能性があります。ローカル・モードでは、そのサービスの対応するポッドを実行しているノードにイングレス・トラフィックを送信する必要があります。そうしないと、トラフィックは破棄されます。その結果、一部のアプリケーション・ポッドは他のポッドより多くのトラフィックを受信する可能性があります。

詳細は、Terminating Requests at the Receiving NodeおよびPreserving The Client IP Addressを参照してください。

ベスト・プラクティス: オンプレミスのCIDRブロックと、flannel CNIプラグインの使用時に、ポッドとサービスのCIDRブロックが重複しないようにします

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

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

Flannel CNIプラグインを使用すると、クラスタ内のポッド間の通信は、Flannelオーバーレイ・ネットワークにカプセル化されます。チャネル・オーバーレイ・ネットワークは、独自のCIDRブロックを使用して、ポッドおよびワーカー・ノードにIPアドレスをプロビジョニングします。チャネル・オーバーレイ・ネットワークのポッドには、同じクラスタ内の他のポッドからのみアクセスできます。クラスタ外の外部コンピュート・インスタンスは、ポッドに直接アクセスできません。ポッドが、クラスタ内の別のポッドと同じIPアドレスを持つ外部コンピュート・インスタンスにアクセスしようとすると、リクエストが正しくルーティングされず、問題が発生します。

「ポッド・ネットワーク用のFlannel CNIプラグインの使用」を参照してください。

ベスト・プラクティス: リージョナル・サブネットを使用し、ワークロードを分散して高可用性を実現

ワーカー・ノードに対してリージョナル・サブネットを選択して、高可用性を確保し、それらの間でワークロードを分散することをお薦めします。

VCNには、ワーカー・ノード、ロード・バランサおよびKubernetes APIエンドポイントに対して適切な数のサブネットが定義されている必要があります。リージョナル・サブネットを使用してワークロードを分散すると、高可用性が保証され、可用性ドメイン間のフェイルオーバーの実装がより簡単になります。

サブネットの構成を参照してください。

ベスト・プラクティス: トポロジ分散制約を使用して、ポッドの分散方法を制御します。

ポッド・トポロジ分散制約を使用して、可用性ドメインとワーカー・ノード間でポッドを分散する方法を制御することをお薦めします。

たとえば、多数のワーカー・ノードが使用可能で、2つまたは3つのポッドのみが必要な場合、通常、問題が発生した場合に単一障害点のリスクを回避するために、すべてのポッドを同じワーカー・ノードで実行する必要はありません。

ただし、複数の可用性ドメイン内のクライアントにはポッドがますます必要になるため、通常、これらの異なる可用性ドメイン内の複数のワーカー・ノードにポッドを均等に分散する必要があります。このシナリオでは、可用性ドメイン間のネットワーク・トラフィックの送信に関連するレイテンシおよびネットワーク・コストを削減するためにポッドを配布することは、単一障害点を回避することと同様の問題です。各可用性ドメインに同じ数のポッドがあり、問題がある場合はクラスタを自己修復することをお薦めします。

ポッド・トポロジ分散制約を使用すると、高可用性と効率的なリソース使用率の双子の目標を満たすようにクラスタを構成できます。

Kubernetesドキュメントのポッド・トポロジ分散制約を参照してください。

ベスト・プラクティス: ノード数の計画

ノード・サイズ、ポッドのアプリケーション・プロファイルおよび選択したポッド・ネットワーキングCNIプラグインを考慮するクラスタ内のノード数に対して、プランを設定することをお薦めします。

Flannel CNIプラグインを使用する場合、Kubernetes Engineによって作成されたクラスタは、Flannelオーバーレイ・ネットワークからのポッドの/25範囲を予約し、ノード当たり最大110ポッドを許可します。OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインを使用する場合、ワーカー・ノードに選択したシェイプに基づいて、同じノードの範囲が異なる可能性があります。ノードのサイズおよびポッドのアプリケーション・プロファイルに応じて、事前にクラスタ内のノード数を決定します。

ポッド・ネットワークを参照してください。

ベスト・プラクティス: サブネットとセキュリティ・ルールを別々に使用

ネットワーク・リソースの構成時には、個別のサブネットおよびセキュリティ・ルールを使用することをお薦めします。

クラスタを作成およびデプロイするVCNには、少なくとも2つの異なるサブネット(オプションで複数のサブネット)が必要です:

• Kubernetes APIエンドポイント・サブネット
• ワーカー・ノード・サブネット
• 1つのリージョナル、または2つのAD固有のロード・バランサ・サブネット(オプション)
• ポッド・サブネット(OCI VCNネイティブ・ポッド・ネットワークCNIプラグインを使用している場合)
• 要塞サブネット(オプション)

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

サブネットの構成を参照してください。

ベスト・プラクティス: ロード・バランサに個別のサブネットを使用

ロード・バランサがサービスを公開するために、個別のサブネットを作成することをお薦めします。

個別のロード・バランサ・サブネットを作成しない場合、サービスはワーカー・ノード・サブネットのIPアドレスを使用して公開されます。その結果、ワーカー・ノード・サブネット内の割当て済領域が、予期される前に完全に使用され、指定したノード数までクラスタがスケーリングされない可能性があります。

ロード・バランサ・サブネットは、クラスタにデプロイされたアプリケーションへのアクセス方法に応じて、パブリック・サブネットまたはプライベート・サブネットのいずれかになります。アプリケーションがVCN内から内部的にアクセスされる場合は、ロード・バランサ・サブネットにプライベート・サブネットを使用します。アプリケーションがインターネットからアクセスされる場合は、ロード・バランサ・サブネットにパブリック・サブネットを使用します。

Load Balancer Subnet Configurationを参照してください。

ベスト・プラクティス: セキュリティを最大化するためのプライベート・ワーカー・ノード・サブネットの使用

最大限のセキュリティのために、プライベート・サブネットをワーカー・ノード・サブネットとして指定することをお薦めします。

ワーカー・ノード・サブネットは、単一のリージョナル・サブネットまたは複数のAD固有のサブネット(各可用性ドメインに1つずつ)のいずれかです。ワーカー・ノード・サブネットは、パブリック・サブネットまたはプライベート・サブネットのいずれかです。ただし、最大のセキュリティのために、ワーカー・ノード・サブネットはプライベート・サブネットにすることをお薦めします。

「ワーカー・ノード・サブネットの構成」を参照してください。

ベスト・プラクティス: クラスタをVCNネイティブに移行して、Kubernetes APIエンドポイントをVCNに統合

VCNネイティブでないクラスタをVCNネイティブに移行することをお薦めします。

VCNネイティブ・クラスタでは、ワーカー・ノード、ロード・バランサおよびKubernetes APIエンドポイントは、独自のVCNに完全に統合されており、パブリックまたはプライベートとして構成できます。ネットワーク・セキュリティ・グループ(推奨)またはセキュリティ・リストに追加されたセキュリティ・ルールを使用して、Kubernetes APIエンドポイント・サブネットへのアクセスを制御できます。

VCNネイティブ・クラスタによって提供されるセキュリティ制御を利用するには、VCNネイティブではないクラスタを移行して、そのKubernetes APIエンドポイントを独自のVCNに統合します。

VCNネイティブ・クラスタへの移行を参照してください。

ベスト・プラクティス: デフォルトのCoreDNS動作をオーバーライドするConfigMapを作成します

デフォルトのCoreDNS動作をカスタマイズする場合は、独自のConfigMapを作成して適用し、CoreDNS Corefileの設定をオーバーライドすることをお薦めします。

デフォルトのCoreDNS動作をカスタマイズする場合、カスタマイズはクラスタへの内部更新中に定期的に削除されることに注意してください。

「KubernetesクラスタのDNSサーバーの構成」を参照してください。

ベスト・プラクティス: ヘルス・チェックにレディネスおよび稼働率プローブを使用します

Kubernetesの有効性および準備期間プローブを使用して、クラスタ内のコンテナの健全性をチェックし、要件を満たすようにプローブをカスタマイズすることをお薦めします。

大規模な分散システムの管理は、特に問題が発生した場合に複雑になることがあります。Kubernetesヘルス・チェックは、アプリケーション・インスタンスが動作していることを確認する簡単な方法です。カスタム・ヘルス・チェックを作成すると、環境に合わせてヘルス・チェックを調整できます。

特に、コンテナがサービスからトラフィックを受信する候補になる前に、レディネス・プローブとライブ・プローブを使用して、コンテナが正しく実行され機能していることを確認することを強くお薦めします。使用する特定のプローブおよびプローブ・パラメータは、ワークロードによって異なります。プローブを攻撃的すぎることと低速すぎることのバランスをとり、アプリケーションのニーズに合わせてパラメータをチューニングします。

Kubernetesドキュメントの稼働性、準備および起動プローブの構成を参照してください。

ベスト・プラクティス: ロード・バランサおよびネットワーク・ロード・バランサのメトリックを使用してバックエンドをモニターします

メトリックを使用して、タイプがLoadBalancerのKubernetesサービス用にプロビジョニングされたOCIロード・バランサまたはネットワーク・ロード・バランサのヘルスを監視することをお薦めします。

また、バックエンドの可用性が選択したしきい値を下回った場合に警告するようにアラームを設定することをお薦めします。例:

• ロード・バランサのUnhealthyBackendServersメトリックを使用して、バックエンド・セット内の異常なバックエンド・サーバーの数がゼロを上回った場合にアラートを発するアラームを設定します。
• ロード・バランサのBackendTimeoutsメトリックを使用して、すべてのバックエンド・サーバーのタイムアウト数がゼロを上回った場合にアラートを発するアラームを設定します。
• ネットワーク・ロード・バランサのHealthyBackendsメトリックを使用して、Oracleが正常とみなすバックエンドの数が1を下回った場合に警告するアラームを設定します。
• ネットワーク・ロード・バランサのUnhealthyBackendsメトリックを使用して、Oracleで異常とみなされるバックエンドの数がゼロを上回った場合に警告するアラームを設定します。

Load Balancerのメトリック、Network Load Balancerのメトリックおよびアラームの作成を参照してください。

ベスト・プラクティス: ノード・ラベルを使用して、バックエンド・セットにワーカー・ノードのサブセットを含めます

node-label-selector注釈を使用して、必要なアプリケーション・ポッドを持つワーカー・ノードのサブセットのみを指定のロード・バランサまたはネットワーク・ロード・バランサのバックエンド・セットに含めることをお薦めします。異なるロード・バランサおよびネットワーク・ロード・バランサのバックエンド・セットにクラスタのワーカー・ノードのサブセットを含めることで、単一のKubernetesクラスタを複数の論理クラスタ(サービス)として表示できます。

ロード・バランサまたはネットワーク・ロード・バランサのバックエンド・セットに含めるワーカー・ノードにKubenetesラベルをアタッチしたら、そのラベルをLoadBalancerタイプのサービスのマニフェストに指定します:

• ロード・バランサの場合は、注釈oci.oraclecloud.com/node-label-selector:を使用します
• ネットワーク・ロード・バランサの場合は、注釈oci-network-load-balancer.oraclecloud.com/node-label-selector:を使用します

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/node-label-selector: lbset=ServiceA
spec:
  type: LoadBalancer
...

apiVersion: v1
kind: Pod
...
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: lbset
            operator: In
            values:
            - ServiceA
...

バックエンド・セットに含めるワーカー・ノードの選択を参照してください。

ベスト・プラクティス: ノード・プールを作成する前にCalicoをインストールしてください

Calicoを使用してクラスタ・セキュリティを強化する場合は、ノード・プールを作成する前にクラスタにCalicoをインストールすることをお薦めします。

Kubernetesネットワーク・ポリシーを実装することで、クラスタ・セキュリティを強化できます。Kubernetesネットワーク・ポリシーを実装するには、NetworkPolicyリソースをサポートするネットワーク・プロバイダをインストールおよび構成する必要があります。そんな業者の一人がカリコです。

ポッドがすでに実行されている既存のノード・プールがあるクラスタにCalicoをインストールする場合、Calicoのインストールが完了したらポッドを再作成する必要があります。たとえば、kubectl rollout restartコマンドを実行します。(推奨)クラスタにノード・プールを作成する前にCalicoをクラスタにインストールすると、再作成するポッドがないことを確認できます。

オープン・ソースのCalicoの使用のみがサポートされていることに注意してください。Calico Enterpriseの使用はサポートされていません。

例: Calicoのインストールおよびネットワーク・ポリシーの設定を参照してください。