※ 本記事は、Greg Verstraeten, Chip Hwangによる”Getting started and best practices with OKE virtual nodes“を翻訳したものです。

2023年6月23日

これまでのブログ投稿では、Oracle Container Engine for Kubernetes(OKE)仮想ノードがサーバーレスのKubernetesエクスペリエンスを提供する方法について説明しました。OKE仮想ノードを使用してKubernetesクラスタでアプリケーションを実行すると、ワーカー・ノードの容量、そのメンテナンス、パッチ適用および修復の管理が省けます。多くのお客様は、インフラストラクチャの運用をスキップし、アプリケーションの構築、実行および簡単なスケーリングに重点を置くというメリットをすでに実現しています。

このブログ投稿では、OKE仮想ノードの使用を開始するための3つの重要なステップを詳しく説明し、仮想ノードを含むKubernetesクラスタを作成するためのワンクリック・メソッドを提供します。

OKE仮想ノードの使用を開始するための3つの主要なステップ

OKE仮想ノードを正常に開始するには、次の重要なステップに従う必要があります。

仮想ノードのIAMポリシー

OKE仮想ノードでは、完全管理型のKubernetesクラスタが提供されます。Oracleは、Kubernetesクラスタのすべてのインフラストラクチャをお客様のために管理します。クラスタにデプロイするアプリケーションのポッドは、独自の仮想クラウド・ネットワーク(VCN)に接続されるため、アプリケーションへのアクセスを制御できます。この目標を達成するには、OKEサービス・テナンシがポッド仮想ネットワーク・インタフェース・カード(VNIC)をVCNのサブネットに接続できるようにし、VCNで定義されたネットワーク・セキュリティ・ルールを関連付ける必要があります。

次の正確なポリシー・ステートメントを使用して、テナンシのルート・コンパートメントにIAMポリシーを作成します。文は、ルート・コンパートメントにそのまま作成する必要があります。OCIDsは更新しないでください。

define tenancy ske as ocid1.tenancy.oc1..aaaaaaaacrvwsphodcje6wfbc3xsixhzcan5zihki6bvc7xkwqds4tqhzbaq
define compartment ske_compartment as ocid1.compartment.oc1..aaaaaaaa2bou6r766wmrh5zt3vhu2rwdya7ahn4dfdtwzowb662cmtdc5fea
endorse any-user to associate compute-container-instances in compartment ske_compartment of tenancy ske with subnets in tenancy where ALL {request.principal.type='virtualnode',request.operation='CreateContainerInstance',request.principal.subnet=2.subnet.id}
endorse any-user to associate compute-container-instances in compartment ske_compartment of tenancy ske with vnics in tenancy where ALL {request.principal.type='virtualnode',request.operation='CreateContainerInstance',request.principal.subnet=2.subnet.id}
endorse any-user to associate compute-container-instances in compartment ske_compartment of tenancy ske with network-security-group in tenancy where ALL {request.principal.type='virtualnode',request.operation='CreateContainerInstance'}

ネットワーキング

タイプ・ロード・バランサのKubernetesサービスは、クラスタ外部のアプリケーションを公開します。セキュリティ・ルールを作成して、エンド・ユーザーからインターネット、ロード・バランサ、ロード・バランサからポッドへのネットワーク・トラフィックを許可する必要があります。これらのセキュリティ・ルールは、ロード・バランサおよびポッドに割り当てられたサブネットのセキュリティ・リストの一部として、またはロード・バランサおよびポッドのVNICに適用されたネットワーク・セキュリティ・グループ(NSG)の一部として作成できます。ネットワーク構成の詳細は、OKEのドキュメントを参照してください。たとえば、サービスがHTTPを介して公開されているアプリケーションでは、次のルールが必要です。:

  • TCP/443 Ingress on the load balancer from the internet
  • TCP/30000-32767 Egress on the load balancer to pods
  • TCP/30000-32767 Ingress on pods from the load balancer

ポッド仕様

OKE仮想ノードを使用してKubernetesクラスタでアプリケーションを実行すると、ワーカー・ノードの容量、そのメンテナンスおよび修復の管理が省けます。多くのお客様は、インフラストラクチャの運用をスキップし、アプリケーションの構築、実行および簡単なスケーリングに重点を置くというメリットをすでに実現しています。オラクルのビジョンは、OKE仮想ノードでサポートされるすべてのKubernetesオブジェクトおよび機能を備えることです。ただし、いくつかのKubernetesオブジェクトおよびポッド仕様はまだサポートされておらず、完全なリストはOKEドキュメントに示されています。すべてのKubernetes機能のサポートの提供に取り組んでいますが、OKE仮想ノードに合わせて一部のデプロイメント・マニフェストを変更する必要がある場合があります。

メトリック・サーバーなどの標準ソフトウェアのデプロイメントを簡略化するために、このGitHubリポジトリにデプロイメント・ファイルを提供します。次のコマンドを使用して、メトリック・サーバーをOKE仮想ノードにデプロイできるようになりました。:

kubectl apply -f https://raw.githubusercontent.com/oracle-devrel/oci-oke-virtual-nodes/main/metrics-server/components.yml

 

ワンクリックで始める

仮想ノードを持つクラスタを作成する手順については、ここで説明されています。これで、仮想ノードを含むクラスタを作成するためのすべてのステップが自動化されました。

1 – 自動デプロイメント

OKEクラスタ用のTerraformスタックを仮想ノード・プールで開発し、デプロイメント・プロセスを自動化しました。このスタックは、Oracle Resource Manager (ORM)またはTerraform CLIを使用して拡張できます。スタックは、推奨されるネットワーク・トポロジ、セキュリティ・ルールおよび最適な仮想ノード配置に準拠する仮想ノード・プールを持つOKEクラスタをデプロイします。また、仮想ノード操作に必要なIAMポリシーをデプロイすることもできます。これらの機能により、スタックにはNGINXイングレス・コントローラ、Kubernetesメトリック・サーバー、Kubernetesダッシュボードなどの補完コンポーネントが含まれ、OKE環境の全体的な機能が強化されます。

プロセスを自動化するには、oke-virtual-node-terraform GitHubリポジトリのreadmeに埋め込まれた「Deploy to Oracle Cloud」ボタンをクリックします。

deploy to Oracle Cloud

 

2 – 単純なアプリケーションのデプロイ

kubectlコマンドでクラスタにアクセスするには、ワークステーションでkubeconfigファイルを構成する必要があります。”oci ce cluster create-kubeconfig”コマンドを使用してkubeconfigファイルを生成します(詳細は、OKEのドキュメントを参照してください)。このコマンドは、前に説明したTerraformスタックの出力として含まれています。

最初のデプロイメントとして、次のコマンドで、Kubernetesサービス・タイプのロード・バランサを含む単純なアプリケーションNginxをデプロイします:

kubectl apply -f https://raw.githubusercontent.com/oracle-devrel/oci-oke-virtual-nodes/main/nginx-svc/nginx.yaml

ポッドとサービスの準備が整ったら、「kubectl get svc nginx」コマンドを使用してサービスに割り当てられた外部IPを取得し、ブラウザにロードします。Nginxのようこそページが表示されます。

Nginx

OKE仮想ノードに関するベスト・プラクティス

次の項では、OKE仮想ノードの最適な使用に関する推奨ベスト・プラクティスを示します。また、OKE仮想ノードの実際的なユース・ケース・シナリオを示すリファレンス・アーキテクチャも提供しています。

仮想ノード数

OKE仮想ノードは、CPUおよびメモリー容量の制約を事実上使用せずに、Kubernetesワーカー・ノードの抽象化を提供します。仮想ノードは、OCIリージョン全体のCPUおよびメモリー容量を使用して、Kubernetesポッドを実行できます。一方、管理対象ノードでは、CPUおよびメモリーをノード・プール・レベルで割り当てます。Kubernetesポッドはこれらのリソースのみを使用するため、アプリケーションの拡大および縮小に合せてノード・プールをスケール・アップおよびスケール・ダウンする必要があります。

ノード・プールに複数の仮想ノードが存在する主な理由は、スケーラビリティではありません。各仮想ノードに多数のポッドを設定できます。現在の最大制限は、仮想ノード当たり1000ポッドです。仮想ノード数を1より大きい値に設定する主な理由は、高可用性です。管理対象ノードと同様に、仮想ノードはOCI可用性ドメインとフォルト・ドメインに属します。仮想ノードでスケジュールされたすべてのポッドは、仮想ノードと同じ可用性ドメインおよびフォルト・ドメインに存在します。OCIリージョンのトポロジおよびトポロジ分散制約に基づいてデプロイメントにノード・アフィニティおよびアンチアフィニティを指定して、ポッドを複数の可用性ドメインまたはフォルト・ドメインに均等に分散できます。

仮想ノード・プールの場合、仮想ノード数を3に設定し、単一可用性ドメイン・リージョンのマルチ可用性ドメイン・リージョンまたはフォルト・ドメイン内の可用性ドメイン間での配置を分散することをお薦めします。デフォルトでは、仮想ノード数は3に設定されるため、ポッドは3つの仮想ノードに分散されるため、可用性ドメインまたはフォルト・ドメインにまたがって分散されます。

ポッド・シェイプ

仮想ノード・プールを作成する場合は、ポッド・シェイプを設定する必要があります。シェイプによって、ポッドの実行に使用する必要があるプロセッサ・タイプが決まります。ポッドに割り当てられるCPUおよびメモリーの量はポッド仕様で指定され、アプリケーションのデプロイ時またはスケーリング時に使用されます。

各ポッドは、選択したポッド・シェイプのメモリーおよびCPU制限まで使用できます。たとえば、Pod.Standard.E4.FlexシェイプではAMD EPYC7J13プロセッサ・タイプが採用され、各ポッドでは最大64 OCPUと1TBのメモリーを使用できます。

CPUおよびメモリー・リクエスト

Kubernetesポッド仕様の一部としてCPUおよびメモリー・リクエストを指定することをお薦めします。OKE仮想ノードでは、ポッドが必要なCPUおよびメモリーを取得するための唯一の方法であるため、この仕様が重要になります。ポッド仕様のCPUおよびメモリー・リクエストを設定するには、このデプロイメントの例を参照してください。

仮想ノード・ネットワーキング

仮想ノードは、VCNネイティブのポッド・ネットワーキングを持つクラスタにのみ含めることができます。

  • 各ポッドは、VCNのサブネットからIPアドレスを取得します。
  • クラスタで使用可能なポッドの数は、サブネット内のIPアドレスの数によって制限されるため、成長のために予測されるポッド数に対応するサブネット範囲を使用することが不可欠です。たとえば、250ポッドが実行されている仮想ノード・プールは、通常の/24ポッド・サブネットを持つことができます。ただし、4000ポッドが実行されている仮想ノード・プールには、/20ポッド・サブネットが必要です。
  • NSGを定義して、ポッドからイングレスおよびエグレスできるトラフィックを制限できます。
  • VCNフロー・ログは、ポッド間のすべてのネットワーク・トラフィックを検査できます。

OKEリソースへのネットワーク・アクセスを承認する場合、全体的なセキュリティを強化し、潜在的なリスクおよび脆弱性を最小限に抑えるには、最小権限の原則に従うことが不可欠です。提供されているネットワーク図は、仮想ノードを含むOKEクラスタ内のKubernetesリソースに対する正確なネットワーク・アクセスの前提条件の概要を示しています。セキュアなネットワーク環境を確保するには、これらのKubernetesワークロード・タイプに関するセキュリティ・ルールを確立することが重要です。

VCN design for OKE Virtual Nodes

ワークロード・アイデンティティ

ポッドでは、オブジェクト・ストレージ・バケットからオブジェクトを取得したり、OCI Vaultからシークレットをフェッチするなど、他のOCIサービスにアクセスする必要がある場合があります。仮想ノードでは、ポッド・レベルの権限のみを割り当てることができます。これは、最小権限の原則に従うため推奨されます。ワークロード・アイデンティティは、OCI IAMロールをポッドに割り当てられたKubernetesサービス・アカウントにリンクすることで、これらの権限を付与できます。

 

詳細情報

OKE仮想ノードの詳細および実践的な経験を得るには、次のリソースを参照してください。: