ポッド・ネットワーク用のOCI VCNネイティブ・ポッド・ネットワークCNIプラグインの使用
Kubernetes Engine (OKE)を使用して作成されたクラスタ内のワーカー・ノードでのポッド通信用のOCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインについて確認します。
OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインは、VCNのCIDRブロックからポッドへのIPアドレスを提供します。OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインを使用すると、同じサブネット(または別のサブネット)内の他のリソースが、Kubernetesクラスタ内のポッドと直接通信できます。ポッドIPアドレスは、オンプレミス・ネットワークおよびインターネットから、そのVCNに接続(ピアリング)されている他のVCNから直接ルーティングできます。
ポッドは直接ルーティング可能であるため、「ネイティブ」VCN機能を使用して次のことができます。
- ネットワーク・セキュリティ・グループ(推奨)またはセキュリティ・リストの一部として定義されたセキュリティ・ルールを使用して、ポッドに対するアクセスを制御します。セキュリティ・ルールは、ノード・プールに指定されたポッド・サブネットに接続されているすべてのワーカー・ノードのすべてのポッドに適用されます。ネットワーク・セキュリティ・グループおよびセキュリティ・リストを参照してください。
- トラブルシューティングおよびコンプライアンス監査の目的で、VCNフロー・ログを使用してポッドとの間のトラフィックを確認します。VCNフロー・ログを参照してください。
- ルーティング・ルールおよびルート表で指定されたルーティング・ポリシーに基づいて、受信リクエストをポッドにルーティングします。VCNルート表を参照してください。
OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインを使用する場合、ワーカー・ノードは、ノード・プールに指定された2つのサブネットに接続されます:
- ワーカー・ノード・サブネット:ワーカー・ノード・サブネットは、クラスタ・コントロール・プレーンで実行されているプロセス(kube-apiserver、kube-controller-manager、kube-schedulerなど)と、ワーカー・ノードで実行されているプロセス(kubelet、kube-proxyなど)間の通信をサポートします。ワーカー・ノード・サブネットはプライベートまたはパブリックにでき、リージョナル・サブネット(推奨)にすることも、異なるAD固有のサブネット(リージョン内の各可用性ドメインに1つ)にすることもできます。
- ポッド・サブネット:ポッド・サブネットは、ポッド間の通信と、プライベート・ポッドIPアドレスを使用した個々のポッドへの直接アクセスをサポートします。ポッド・サブネットはプライベートまたはパブリックにでき、リージョン・サブネットである必要があります。ポッド・サブネットにより、ポッドは同じワーカー・ノード上の他のポッド、他のワーカー・ノード上のポッド、OCIサービス(サービス・ゲートウェイ経由)およびインターネット(NATゲートウェイ経由)と通信できます。ノード・プールのワーカー・ノードで実行されているすべてのポッドに対して、単一のポッド・サブネットを指定します。クラスタ内のノード・プールごとに、同じポッド・サブネットを指定することも、異なるポッド・サブネットを指定することもできます。異なるクラスタのノード・プールに同じポッド・サブネットを指定できます。
ワーカー・ノード・サブネットとポッド・サブネットは同じVCNに存在する必要があります。状況によっては、ワーカー・ノード・サブネットとポッド・サブネットが同じサブネットになることがあります(「異なるシェイプでサポートされるVNICおよびポッドの最大数」を参照)。ワーカー・ノード・サブネットとポッド・サブネットが同じサブネットである場合、Oracleでは、ネットワーク・トラフィックをワーカー・ノードおよびポッドにルーティングするために、(セキュリティ・リストではなく)ネットワーク・セキュリティ・グループにセキュリティ・ルールを定義することをお薦めします。ワーカー・ノード・サブネットおよびポッド・サブネットは、Kubernetes APIエンドポイント・サブネットおよびクラスタに定義されているロード・バランサ・サブネットに追加されます。
OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインを使用する場合、各ワーカー・ノードに少なくとも2つのVNICがアタッチされます。最初のVNICはワーカー・ノード・サブネットに接続されます。2番目のVNICはポッド・サブネットに接続されます。デフォルトでは、ワーカー・ノードで実行されているポッドで使用するために、31のIPアドレスがVNICに割り当てられます。IPアドレスの不足を回避するために、ポッドがクラスタに作成される前に、IPアドレスがポッド・サブネットに事前に割り当てられます。
ノード・プールに選択したシェイプで2つ以上のVNICがサポートされている場合、追加のVNICをポッド・サブネットに接続して、さらに多くのポッドをサポートするためのIPアドレスを提供できます。
ノード・プール内の1つのワーカー・ノードで実行するポッドの最大数(最大110)を指定できます。Kubernetesによって110の制限が課されます。1つのワーカー・ノードに31個を超えるポッドが必要な場合は、ノード・プールに指定するシェイプで3つ以上のVNIC (ワーカー・ノード・サブネットに接続するための1つのVNICと、ポッド・サブネットに接続するための2つ以上のVNIC)をサポートする必要があります。「異なるシェイプでサポートされるVNICおよびポッドの最大数」を参照してください。
ポッド・サブネットのアドレス領域を節約する場合は、1つのワーカー・ノードで実行するポッドの最大数を減らして、ポッド・サブネットに事前に割り当てられているIPアドレスの数を減らします。
OCI VCNネイティブ・ポッド・ネットワークCNIプラグインを使用する場合、次の点に注意してください:
- OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインは、仮想ノード・プールと管理対象ノード・プールの両方で使用できます。
- Kubernetes 1.22以降を実行しているクラスタでのみ、OCI VCNネイティブ・ポッド・ネットワークCNIプラグインを使用できます(ポッド・ネットワーク用のOCI VCNネイティブ・ポッド・ネットワークCNIプラグインの使用を参照)。詳細は、ポッド・ネットワーキングを参照してください。
- OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインを使用しており、ワーカー・ノードのベース・イメージとしてOKEイメージを指定する場合は、2022年6月より前にリリースされたOKEイメージを選択しないでください。
- ポッド・ネットワーキングにOCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインを使用すると、サービス・メッシュ製品(Oracle Cloud Infrastructure Service Mesh、Istio、Linkerdなど)がサポートされます。Istioアドオンを除き、現在サポートはOracle Linux 7に制限されています(Oracle Linux 8のサポートが計画されています)。Istioアドオンは、Oracle Linux 7とOracle Linux 8の両方でサポートされています。ワーカー・ノードは、Kubernetes 1.26 (以降)を実行している必要があります。
ワーカー・ノードおよびポッドのセキュリティ・ルール
ポッド・ネットワークにOCI VCNネイティブ・ポッド・ネットワークCNIプラグインを使用する場合は、ポッド・サブネットおよびワーカー・ノード・サブネットに特定のセキュリティ・ルールが必要です。ポッド・サブネットのセキュリティ・ルールを参照してください。
異なるシェイプでサポートされるVNICおよびポッドの最大数
ノード・プール内のワーカー・ノードのVNICの最大数(したがって、ポッドの最大数)は、ノード・プールに選択したシェイプによって異なります。
特定のシェイプのVNICの最大数を確認するには、コンピュート・シェイプを参照してください。
特定のシェイプのノード・プール内のポッドの最大数を計算するには、次の式を使用します:
Maximum number of Pods per node = MIN( (Number of VNICs - 1) * 31 ), 110)
クラスタとその関連リソースが異なるコンパートメントにある場合の追加IAMポリシー
クラスタの関連リソース(ノード・プール、VCN、VCNリソースなど)がクラスタ自体とは異なるコンパートメントにある一般的なシナリオで、OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインを使用するには、IAMポリシーに次のようなポリシー・ステートメントを含める必要があります:
Allow any-user to manage instances in tenancy where all { request.principal.type = 'cluster' }
Allow any-user to use private-ips in tenancy where all { request.principal.type = 'cluster' }
Allow any-user to use network-security-groups in tenancy where all { request.principal.type = 'cluster' }
これらのポリシー・ステートメントが許容しすぎると考えられる場合は、権限を制限して、関連リソースが属するコンパートメントを明示的に指定したり、別のコンパートメントに関連リソースがあるクラスタを明示的に指定したりできます。例:
Allow any-user to manage instances in compartment <compartment-ocid-of-nodepool> where all { request.principal.id = '<cluster-ocid>' }
Allow any-user to use private-ips in compartment <compartment-ocid-of-network-resources> where all { request.principal.id = '<cluster-ocid>' }
Allow any-user to use network-security-groups in compartment <compartment-ocid-of-network-resources> where all { request.principal.id = '<cluster-ocid>' }
ここでは:
<compartment-ocid-of-nodepool>
は、ノードプールおよびコンピュート・インスタンスが属するコンパートメントのOCIDです。<compartment-ocid-of-network-resources>
は、VCNおよびサブネットが属するコンパートメントのOCIDです。
OCI VCNネイティブ・ポッド・ネットワークCNIプラグインの更新
VCNネイティブ・ポッド・ネットワーキングをクラスタのネットワーク・タイプとして指定すると、クラスタとそのノード・プールでは、最初にOCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインの最新バージョンが使用されます。
OCI VCNネイティブ・ポッド・ネットワークCNIプラグインの更新は定期的にリリースされます。Oracleで更新をクラスタに自動的にデプロイするように指定できます(デフォルト)。または、デプロイするバージョンを選択するように指定できます。バージョンを選択する場合、アドオンを最新に保つ責任があります。Configuring Cluster Add-onsを参照してください。
お客様またはOracleがOCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインに更新をデプロイするかどうかに関係なく、更新はワーカー・ノードが次回再起動される場合にのみ適用されます。更新がデプロイされ、適用を待機しているかどうかを確認するには、次のように入力してvcn-native-ip-cni
デーモンセット・ログを調べます:
kubectl logs -n kube-system -l app=vcn-native-ip-cni --prefix | grep "reboot required"
コマンドへの応答を次のように解釈します。
- コマンドに応答して出力がある場合、OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインの更新は、レスポンスに表示されたポッドに関連付けられたワーカー・ノードにデプロイされていますが、更新は適用を待機しています。ワーカー・ノードが次回再起動されると、更新が適用されます。
- コマンドへの応答として出力がない場合、OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインに対する更新は適用を待機していません。