※ 本記事は、Ed Shnekendorf, Ty Stahl, Sherwood Zernによる”Deploying OKE with native pod networking in split-compartment mode“を翻訳したものです。

2023年1月26日

最近、Oracle Container Engine for Kubernetes（OKE）を使用して、管理対象Kubernetesクラスタをデプロイすることを検討しているお客様とともに作業しました。クラスタはネイティブ・ポッド・ネットワーキング（NPN）オプションを使用し、そのリソースが2つのコンパートメントに分散されていました。つまり、クラスタ、ノード・プールおよびインスタンス・リソースが別のコンパートメントにデプロイされている間に、ネットワーク・リソースが1つのコンパートメントにデプロイされました。お客様は、このトポロジをテナンシにデプロイする際に問題が発生し、オラクルにサポートを依頼しました。OKEのドキュメントは包括的で完全なものですが、この特定の一般的なシナリオで適切なすべての部分をまとめるのは困難です。

このブログでは、様々な異なるドキュメント・ソースを、同様の要件を持つ顧客が従うことができるアプローチにまとめています。対象読者は、同様のアプローチを実装しようとしているOracle Cloud Infrastructure（OCI）テナンシ管理者です。詳細なステップは、この顧客の問題を解決し、デプロイメントのブロックを解除するために使用されました。読者は、提供されている規範的なガイダンスを使用してデプロイメントを適切に構成できると考えています。

背景

Oracle Container Engine for Kubernetes（OKE）は、50年以上にわたってOCIワークロードの主要な目的であるマネージド・コンテナ・サービスです。OKEは、マイクロサービスのホスティングや、高可用性で管理された容量でのカスタムまたはパッケージ化されたアプリケーションのデプロイに合せた、Cloud Native Computing Foundation（CNCF）認定Kubernetes環境を提供します。昨年、OKEでは、ネイティブ・ポッド・ネットワーキングを使用してクラスタを作成する機能など、多くの改善が導入されました。この機能により、OKEユーザーはKubernetesポッドを仮想クラウド・ネットワーク（VCN）内で直接ルーティング可能にし、セキュリティ・リスト、ネットワーク・セキュリティ・グループ（NSG）、VCNフロー・ログなどのOCIネットワーキング機能をポッドに直接適用できます。この機能はまた、ネイティブ・コンテナ・ネットワーク・インタフェース（CNI）がデフォルトである競争の激しいクラウド・プラットフォームからOKEに移行するユーザーにとってもメリットがあり、デプロイメントの解除とシフト時に再設計する必要がなくなります。

OCIは、ベスト・プラクティス、ランディング・ゾーン・リファレンス・アーキテクチャの改良と拡張を続け、職務の適切な分離を促進する安全でスケーラブルで管理しやすいテナンシ設計を実現しました。このリファレンス・アーキテクチャは、Center for Internet Security（CIS）によって規定されたクラウド・プロバイダのベンチマークに準拠するように構成されており、ほとんどのお客様にとっての出発点です。ランディング・ゾーンの重要な側面と、ほとんどのお客様に対して表示されることは、ネットワーク・リソースをコンピュート・リソースから別のOCIコンパートメントに分割することです。

このブログで説明するシナリオでは、顧客は個別のネットワークおよびアプリケーション・コンパートメントを持っています。アプリケーション管理者は、ネットワーク管理者によってネットワーク・コンパートメントに事前作成された、VCN、ネットワーク・セキュリティ・グループ、ルーティング表などのネットワーク・リソースを使用しているときに、アプリケーション・コンパートメントにOKEクラスタをデプロイおよび管理する機能が必要です。アプリケーション管理者は追加のネットワーク・リソースを直接作成できませんが、OKEクラスタ自体はポッドのプライベートIPアドレスなど、適切な操作を確保するために必要なリソースを割り当てることができます。

次の図は、テストされた参照設定を視覚的に示しています。:

A graphic depicting the architecture for the solution.

次のステップでは、環境の各部分の設定方法、レビューに関連するドキュメントのページ、および設定の関連するハイライトについて説明します。

ステップ1: コンパートメントの設定

テスト設定では、ネットワークとアプリケーションの2つの子コンパートメントを含むsplit-network-testという共通の親コンパートメントを持つ環境をモデル化しました。この例では、最初のイメージに示されているポリシーはsplit-network-testコンパートメントに配置されましたが、階層内のアプリケーションおよびネットワーク・コンパートメントの上の任意のコンパートメントに存在できます。OCIコンパートメントの作成方法の詳細は、Oracle Cloud Infrastructureコンパートメントの作成を参照してください。

ステップ2: ネットワーク・コンパートメントでのVCN設定

適切に機能するOKEクラスタにはVCNを正しく構成することが不可欠であり、対話のためにOKEにさらされるVCN表面領域の多くが公開されるため、ネイティブ・ポッド・ネットワーキング（NPN）構成には特に不可欠です。すべての詳細は、ネットワーク構成のドキュメントに記載されています。このアーキテクチャの設定では、ネットワーク構成の例が特に役立ちます。FlannelとNPN CNIおよびパブリックまたはプライベートAPIエンドポイントに関連して、4つの順列を説明する4つの参照構成が可能です。この設定では、例3のステップに従い、次の図で視覚化できます。

A graphic depicting the architecture for an NPN CNI with public API subnet (Example 3).

このシナリオで説明されているすべてのルーティング・ルールおよびセキュリティ・リスト・ルールに注意します。これらは、セキュリティ・リストまたはネットワーク・セキュリティ・グループとともに正確に実装する必要があります。bastionサブネットおよびルールはオプションです。この設定では、ポート22のSSHイングレスなどの関連するルールを使用して、パブリック・ロード・バランサ・サブネットをbastionサブネットとして使用しました。

ステップ3: 親コンパートメントのポリシー設定

多くの顧客にとって難しい部分は、適切なポリシーを正しく作成することです。OKEをネットワークおよびアプリケーション・コンパートメントに分割する場合、どのポリシーをどのコンパートメントに適用する必要があるかを理解します。次の設定は、対応するOKEドキュメントの参照とともに動作しました。両方のポリシーは、アプリケーションとネットワーク・コンパートメントの両方に共通する親コンパートメントに配置されました。

NPNリソース・プリンシパル・ポリシー

NPNを使用する場合、クラウド・コントローラ・マネージャ（CCM）がVCNと対話するには、特定のリソース・プリンシパル・ポリシーが必要です。これらのポリシーは、クラスタとそのノード・プールが異なるコンパートメントにある場合の追加IAMポリシーとしてドキュメントに記載されています。クラスタとノード・プールが同じコンパートメントにあるが、ネットワークが異なるコンパートメントにある場合は、これらのポリシーも必要であることがわかりました。

Allow any-user to manage instances in compartment split-network-test where all { request.principal.type = 'cluster' }
Allow any-user to use private-ips in compartment split-network-test where all { request.principal.type = 'cluster' }
Allow any-user to use network-security-groups in compartment split-network-test where all { request.principal.type = 'cluster' }

ポリシー・ステートメントは、ドキュメント内の例のハイブリッドです。特定のコンパートメントに対する権限をロックダウンする強力なコントロールは気に入りましたが、テナンシ全体ではなく、リソース・プリンシパルを個々のクラスタOCIDにロックダウンする必要は感じませんでした。request.principal.idのかわりにrequest.principal.typeを使用しました。特定のOCIDを使用する危険は、クラスタ・フットプリントの変更に応じて常にポリシーを更新する必要があり、ポリシーの更新を忘れると、デバッグが困難な障害が発生する可能性があることです。お客様の環境をデバッグする際に確認されました。

これらのポリシーは、OCIリソース・タイプ（テナンシ内で実行されているクラスタ）が各コンパートメント内の特定のリソースを管理することを許可するという点で固有です。お客様は「Allow any-user…」というプレフィックスを確認して、このポリシーが広く許容されていることを懸念するようになりました。ただし、その権限は、ポリシー句の2番目の部分にある特定の自動リソースのセットに制限されます。

非管理グループ・ポリシー

また、完全な管理者権限やネットワーク・リソースの作成権限を必要とせずに、OKE管理者がクラスタを作成、更新および管理できるようにポリシーを設定する必要もあります。このトピックの完全な処理については、ドキュメントの「クラスタの作成とデプロイメントのためのポリシー構成」の項で説明します。包括的ですが、ドキュメントに含まれないのは、これらのポリシーをsplit-compartmentモデルに適用する方法の明確な例です。

次のポリシー・ステートメントを適用しました。これは、前述のシナリオで成功しました。:

Allow group app-group to read all-resources in compartment app
Allow group app-group to manage cluster-family in compartment app
Allow group app-group to manage instance-family in compartment app
Allow group app-group to manage volume-family in compartment app
Allow group app-group to read all-resources in compartment network
Allow group app-group to use virtual-network-family in compartment network
Allow group app-group to use virtual-network-family in compartment network
Allow group app-group to use network-security-groups in compartment network
Allow group app-group to use vnics in compartment network
Allow group app-group to use subnets in compartment network
Allow group app-group to use private-ips in compartment network
Allow group app-group to use public-ips in compartment network

グループapp-groupにはOKE管理ユーザーが含まれます。このグループには、アプリケーション・コンパートメント内のインスタンス、クラスタおよびボリューム・リソースをコントロールする権限が付与されますが、ネットワーク・コンパートメント内の事前に割り当てられたリソースのみが使用されます。

OCI VaultやFile Storageサービスの使用など、その他のユース・ケースでは、より多くのポリシー・ステートメントが必要になる場合があります。オラクルでは、コンピュート・リソースと永続ボリュームを使用するシンプルな設定でテストしました。

ステップ4: アプリケーション・コンパートメントでのOKEクラスタの作成

ステップ1から3を完了すると、ステップ4が簡単になります。Oracle Cloud ConsoleでOKEクラスタを作成する場合は、カスタム作成フローに従います。

クラスタはアプリケーション・コンパートメントに移動します:

A screenshot of the Create Custom Cluster page with a blue arrow pointing to the compartment field.

2番目のページで、「Change Compartment」リンクを3回クリックしてネットワーク・コンパートメントに切り替え、正しいサブネットを選択します。

パブリック・エンドポイントを含むクラスタを作成する場合、「APIエンドポイントへのパブリックIPアドレスの割当て」セレクタはオプションですが、選択しない場合、クラスタは失敗します。これは、CCMがクラスタを構成するためにパブリック・エンドポイントを検索するためです。クラスタ作成エラーは関連付けが困難です。そのため、APIエンドポイントをパブリック・サブネットに配置する場合は、必ずこのチェックボックスをクリックしてください。

A screenshot of the Network Setup tab with blue arrows pointing to the VCN, Kubernetes service LB subnets, and Kubernetes API endpoint subnet in network and the option to assign a public IP address to the API endpoint.

3番目のページでは、ノード・プールはアプリケーション・コンパートメントに残ります:

A screenshot of the Node Pools tab with a bluw arrow pointing to the compartment field.

配置構成およびポッド通信セクションでは、「Change Compartment」リンクをクリックする必要がありますが、ネットワーク・コンパートメントに切り替えて、ステップ1で作成した適切なサブネットを選択します。

最終レビュー・ページで、クラスタの作成を承認します。数分以内に、ワークロードのデプロイを開始するための完全な機能を持つクラスタがあります。

まとめ

ネイティブ・ポッド・ネットワーキングを含むOKEクラスタをCIS準拠のOracle Cloud Infrastructureランディング・ゾーンにデプロイするのは簡単ではありません。このブログのステップに従って、この本番グレードの構成を起動および実行するときに他のユーザーが直面したいくつかの落とし穴を回避できることを願っています。