ポッド・ネットワーク用のOCI VCNネイティブ・ポッド・ネットワークCNIプラグインの使用

Kubernetes Engine (OKE)を使用して作成されたクラスタ内のワーカー・ノードでのポッド通信用のOCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインについてご確認ください。

OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインは、VCNのCIDRブロックからポッドへのIPアドレスを提供します。OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインを使用すると、同じサブネット(または別のサブネット)内の他のリソースが、Kubernetesクラスタ内のポッドと直接通信できます。Pod IP addresses are directly routable from other VCNs connected (peered) to that VCN, and from on-premise networks.

ポッドは直接ルーティング可能であるため、「ネイティブ」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.27.10 (以降)を実行している場合、自己管理ノードとともにOCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインを使用できます。詳細は、「自己管理ノードの使用」を参照してください。
Kubernetes 1.22以降を実行しているクラスタでのみ、OCI VCNネイティブ・ポッド・ネットワークCNIプラグインを使用できます(ポッド・ネットワーク用のOCI VCNネイティブ・ポッド・ネットワークCNIプラグインの使用を参照)。詳細は、ポッド・ネットワーキングを参照してください。
OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインを使用しており、ワーカー・ノードのベース・イメージとしてOKEイメージを指定する場合は、2022年6月より前にリリースされたOKEイメージを選択しないでください。
OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインを使用しており、オンプレミス・ネットワークからポッドにトラフィックをルーティングする場合、ポッドが再作成された場合、ポッドのIPアドレスは永続的ではないことに注意してください。たとえば、Nginxポッドの初期IPアドレスは10.0.0.5ですが、ポッドを削除して再作成すると、ポッドのIPアドレスが異なる場合があります(10.0.0.8など)。
ポッド・ネットワーキングにOCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインを使用する場合、サービス・メッシュ製品(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)

IPv6アドレスを使用してリソースにアクセスするための追加のIAMポリシー

クラスタの関連リソース(Kubernetes APIエンドポイント、ロード・バランサ、ワーカー・ノードなど)にIPv6アドレスがあるOCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインを使用するには、IAMポリシーに次のようなポリシー・ステートメントを含めます:

Allow any-user to use ipv6s in compartment <compartment-ocid-of-network-resources> where all { request.principal.id = '<cluster-ocid>' }

クラスタとその関連リソースが異なるコンパートメントにある場合の追加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プラグインの更新は定期的にリリースされます。

バージョン2.3.0より前のOCI VCNネイティブ・ポッド・ネットワーキングCNIプラグイン・バージョン(2025年8月)では、Oracleで更新をクラスタに自動的にデプロイするように指定できます。または、デプロイするバージョンを選択するように指定できます。バージョンを選択する場合(バージョンがバージョン2.3.0より前)、あなたはアドオンを最新に保つ責任があります。OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインでは、RollingUpdate更新戦略が使用されるため、既存のCNIプラグイン・ポッドは自動的に終了され、新しいCNIプラグイン・バージョンを実行する新しいポッドが作成されます(RollingUpdate更新戦略の詳細は、KubernetesドキュメントのDaemonSet更新戦略を参照してください)。更新は、ワーカー・ノードが次に再起動されたときに適用されます。

OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグイン・バージョン2.3.0 (2025年8月)以降のバージョンでは、CNIプラグインの更新はクラスタに自動的にデプロイされません。OCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインではOnDelete更新戦略が使用されるため、CNIプラグインはCNIプラグイン・ポッドを明示的に削除することによってのみ更新できます(OnDelete更新戦略の詳細は、KubernetesドキュメントのDaemonSet更新戦略を参照してください)。このアプローチにより、クラスタ更新中のCNIプラグイン・ポッドの予期しない再起動を回避できます。バージョン2.3.0では、CNIプラグイン・ポッドの削除を制限する検証入学ポリシーも導入されています。バージョン2.3.0以降を使用しているときにCNIプラグインを新しいバージョンに更新するには、次のいずれかの方法を採用します。

(推奨)クラスタに新しいノードをプロビジョニングします:クラスタに新しいノードをプロビジョニングすると、最新のCNIプラグイン・バージョンを実行しているCNIプラグイン・ポッドが自動的に受信されます。オプションで、古いバージョンを実行しているCNIプラグイン・ポッドを使用してノードをドレインおよび削除できます。
クラスタ内の既存のノードの更新:既存のCNIプラグイン・ポッドを削除することで、既存のノードのCNIプラグイン・バージョンを更新できます。CNIプラグイン・ポッドの削除を制限する検証入学ポリシーを削除し、既存のCNIプラグイン・ポッドを削除してから、ポリシーをリストアする必要があります。DaemonsetControllerは、最新のCNIプラグイン・バージョンを実行しているCNIプラグイン・ポッドを再作成します。これらのステップに従います。
1. 次のように入力して、更新する既存のノードのCNIプラグイン・ポッドを識別します:
```
kubectl get pods -n kube-system -l app=vcn-native-ip-cni
```
2. 次のようにCNIプラグイン・ポッドを削除できるように、検証入学ポリシーを削除します:
  1. 次のコマンドを入力して、検証入学ポリシーおよび検証入学ポリシー・バインディングをvap-policy.yamlおよびvap-binding.yamlとして保存し、後でリストアできるようにします:
```
kubectl get validatingadmissionpolicy npn-pod-deletion-deny-policy -o yaml > vap-policy.yaml
```
```
kubectl get validatingadmissionpolicyBinding npn-pod-deletion-deny-policy-binding -o yaml > vap-binding.yaml
```
  2. 次のコマンドを入力して、検証中の入学ポリシーおよび検証中の入学ポリシー・バインディングを削除します。
```
kubectl delete validatingadmissionpolicy npn-pod-deletion-deny-policy
```
```
kubectl delete validatingadmissionpolicyBinding npn-pod-deletion-deny-policy-binding
```
3. ポッドごとに次のコマンドを入力して、前に特定したCNIプラグイン・ポッドを削除します。
```
kubectl delete pod <cni-pod-name> -n kube-system
```
4. 次のコマンドを入力して、前に作成したvap-policy.yamlおよびvap-binding.yamlファイルを使用して、以前に削除した検証アドミッション・ポリシーおよびポリシー・バインディングをリストアします。
```
kubectl apply -f vap-policy.yaml
```
```
kubectl apply -f vap-binding.yaml
```

更新がデプロイされ、適用を待機しているかどうかを判断するには、次のように入力してvcn-native-ip-cniデーモンセット・ログを調べます。

kubectl logs -n kube-system -l app=vcn-native-ip-cni --prefix | grep "reboot required"

コマンドへの応答を次のように解釈します。