Oracle Cloud Infrastructureドキュメント

OCIネイティブ・イングレス・コントローラをクラスタ・アドオンとしてデプロイするための前提条件

OCIネイティブ・イングレス・コントローラをクラスタ・アドオンとしてデプロイして、受信トラフィックをロード・バランシングし、Kubernetesクラスタ内のワーカー・ノードで実行されているサービス・ポッドにルーティングする前に、何をする必要があるかを確認します。

OCIネイティブ・イングレス・コントローラをクラスタ・アドオンとしてデプロイする前に:

  • ネットワーク・タイプとしてVCNネイティブ・ポッド・ネットワーキングまたはフラッシュ・オーバーレイのいずれかを持つ新しいクラスタを作成するか、既存のクラスタを識別します。クラスタは、拡張クラスタまたは基本クラスタです。クラスタでKubernetesバージョン1.28以降が実行されている必要があります。クラスタの作成を参照してください。
  • ロード・バランサのサブネットとの間のインバウンドおよびアウトバウンド・トラフィックを許可するように、ロード・バランサ・セキュリティ・ルールを構成します。Load Balancer Subnet Configurationを参照してください。
  • インスタンス・プリンシパル、ユーザー・プリンシパルまたはワークロード・アイデンティティ・プリンシパルを設定して、OCIネイティブ・イングレス・コントローラが他のOracle Cloud Infrastructureサービスおよびリソースにアクセスできるようにします。OCIサービスおよびリソースへのアクセスを有効にするためのInstance Principal、User PrincipalまたはWorkload Identity Principalの設定を参照してください。
  • OCIネイティブ・イングレス・コントローラがリソースにアクセスできるように、インスタンス・プリンシパル、ユーザー・プリンシパルまたはワークロード・アイデンティティ・プリンシパルに権限を付与します。OCIネイティブ・イングレス・コントローラ・クラスタ・アドオンへの権限の付与を参照してください。
  • cert-managerをインストールして、ポッド・レディネス・ゲート機能をサポートするWebフック・サーバーに必要なTLS証明書を生成および管理します。Installing cert-managerを参照してください。

OCIサービスおよびリソースへのアクセスを有効にするためのInstance Principal、User PrincipalまたはWorkload Identity Principalの設定

ロード・バランサを作成し、受信トラフィックをルーティングするために、OCIネイティブ・イングレス・コントローラは、スタンドアロン・プログラムとしてインストールされているか、クラスタ・アドオンとしてインストールされているかにかかわらず、他のOracle Cloud Infrastructureサービス・リソース(Load Balancerサービスおよび証明書サービスを含む)に対してアクションを実行します。OCIサービス・リソースでこれらのアクションを実行するために、OCIネイティブ・イングレス・コントローラ・ポッドは、認可されたアクター(またはプリンシパル)の資格証明を使用します。現在、OCIネイティブ・イングレス・コントローラがOCIサービス・リソースに対してアクションを実行できるように、次のタイプのプリンシパルを設定できます:

ノート:

  • OCIネイティブ・イングレス・コントローラがOCIサービスおよびリソースにアクセスできるようにするインスタンス・プリンシパルの使用は、仮想ノードを持つクラスタではサポートされていません。
  • OCIネイティブ・イングレス・コントローラがOCIサービスおよびリソースにアクセスできるようにするワークロード・アイデンティティ・プリンシパルの使用は、拡張クラスタでサポートされていますが、基本クラスタではサポートされていません。

インスタンス・プリンシパルを使用したOCIサービスおよびリソースへのアクセスの有効化

OCIネイティブ・イングレス・コントローラがOCIサービス・リソースに対してアクションを実行できるように、インスタンス・プリンシパルを設定できます。管理対象ノードではインスタンス・プリンシパルのみを使用できます。

インスタンス・プリンシパルを設定するには:

  1. 新しい動的グループを作成して、クラスタのワーカー・ノードをホストするコンピュート・インスタンスを含めます:
    1. ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」をクリックします。「アイデンティティ」で、「ドメイン」をクリックします。「アイデンティティ・ドメイン」で、「動的グループ」をクリックします。

    2. コンピュート・インスタンスが属するコンパートメントを選択します。

    3. 動的グループを作成するにはの手順に従って、動的グループに名前を付けます(たとえば、acme-oke-native-ingress-controller-dyn-grp)。

    4. コンパートメント内のコンピュート・インスタンスを含むルールを次の形式で入力します:
      ALL {instance.compartment.id = '<compartment-ocid>'}

      <compartment-ocid>は、クラスタ・ノード・プールが作成されるコンパートメントのOCIDです。

      例:

      ALL {instance.compartment.id = 'ocid1.compartment.oc1..aaaaaaaa23______smwa'}
    5. 「動的グループの作成」をクリックします。

OCIネイティブ・イングレス・コントローラをデプロイする前に、次のことを行います:

ユーザー・プリンシパルを使用したOCIサービスおよびリソースへのアクセスの有効化

OCIネイティブ・イングレス・コントローラがOCIサービス・リソースに対してアクションを実行できるように、ユーザー・プリンシパルを設定できます。

ユーザー・プリンシパルを設定するには:

  1. 適切なユーザーがまだ存在しない場合は、IAMでユーザーを作成します(ユーザーを作成するにはを参照)。
  2. 適切なグループがまだ存在しない場合は、IAMにグループを作成します(グループを作成するにはを参照)。
  3. ユーザーをグループに追加します(「ユーザーのグループへの追加手順」を参照)。

  4. 次の項目を取得します:

  5. コンソールでキー・ペアから公開キーをアップロードします。公開キーのアップロード方法を参照してください。
  6. 次の形式で、資格証明情報を含む.yamlファイルとして構成ファイルを作成します。
    auth:
  region: <region-identifier>
  passphrase: <passphrase>
  user: <user-ocid>
  fingerprint: <fingerprint>
  tenancy: <tenancy-ocid>
    ここでは:
    • region: <region-identifier>は、クラスタが存在するリージョンです。例: us-ashburn-1
    • passphrase: <passphrase>は、キーが暗号化されている場合に使用するパスフレーズを指定します。
    • user: <user-ocid>は、OCIネイティブ・イングレス・コントローラが使用するユーザーのOCIDです。
    • fingerprint: <fingerprint>は、公開キーの指紋です。
    • tenancy: <tenancy-ocid>は、クラスタを含むテナンシのOCIDです。

    例:

    auth:
  region: us-ashburn-1
  passphrase: examplepass
  user: ocid1.user.oc1..aaaaaaaa_example
  fingerprint: 67:d9:74:4b:21:example
  tenancy: ocid1.tenancy.oc1..aaaaaaaa_example
  7. 次のように入力して、クラスタにKubernetesシークレット・リソースを作成します:
    
kubectl create secret generic <secret-name> \
--from-file=config=<config-file>.yaml \
--from-file=private-key=<private-key-file-path>.pem \
--namespace <namespace>
    ここでは:
    • <secret-name>は、作成するシークレットの名前を指定します。たとえば、oci-config
    • --from-file=config=<config-file>.yamlは、以前に作成した資格証明情報を含む.yamlファイルの名前とパスを指定します。例: user-auth-config.yaml
    • --from-file=private-key=./oci/oci_api_key.pemは、ダウンロードした秘密キー・ファイルの名前とパスを指定します。たとえば、./oci/oci_api_key.pemです。
    • --namespace <namespace>は、OCIネイティブ・イングレス・コントローラを含むネームスペースを指定します

    例:

    
kubectl create secret generic oci-config \
--from-file=config=user-auth-config.yaml \
--from-file=private-key=./oci/oci_api_key.pem \
--namespace acme-namespace

OCIネイティブ・イングレス・コントローラをデプロイする前に、次のことを行います:

ワークロード・アイデンティティ・プリンシパルを使用したOCIサービスおよびリソースへのアクセスの有効化

OCIネイティブ・イングレス・コントローラがOCIサービス・リソースに対してアクションを実行できるように、ワークロード・アイデンティティ・プリンシパルを設定できます。ワークロード・アイデンティティ・プリンシパルは、拡張クラスタでのみ使用できます。

ワークロード・アイデンティティ・プリンシパルを設定するには:

  1. クラスタのOCIDを取得します(たとえば、コンソールの「クラスタの詳細」タブを使用します)。

OCIネイティブ・イングレス・コントローラをデプロイする前に、次のことを行います:

OCIネイティブ・イングレス・コントローラ・クラスタ・アドオンへの権限の付与

OCIネイティブ・イングレス・コントローラには、他のOracle Cloud Infrastructureサービス(Load Balancerサービスや証明書サービスなど)によって作成されたリソースにアクセスする権限が必要です。OCIネイティブ・イングレス・コントローラをスタンドアロン・プログラムとしてインストールするか、クラスタ・アドオンとしてインストールするかに関係なく、付与する権限は同じです。また、OCIネイティブ・イングレス・コントローラのインスタンス・プリンシパル、ユーザー・プリンシパルまたはワークロード・アイデンティティ・プリンシパルを設定したかどうかに関係なく、権限は同じです。ただし、これらの権限を付与する方法は、設定したプリンシパルのタイプによって異なります。

OCIネイティブ・イングレス・コントローラの権限を設定するには、OCIサービスおよびリソースにアクセスするためのポリシー・ステートメントを使用して、グループ(ユーザー・プリンシパルの場合)、動的グループ(インスタンス・プリンシパルの場合)、またはワークロード(ワークロード・アイデンティティ・プリンシパルの場合)のポリシーを作成します:

  1. ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」をクリックします。「アイデンティティ」で、「ポリシー」をクリックします。
  2. ポリシーを作成するにはの説明に従って、ポリシーに名前を付けます(たとえば、acme-oke-native-ingress-controller-policy)。

  3. インスタンス・プリンシパルまたはユーザー・プリンシパルを使用している場合は、OCIネイティブ・イングレス・コントローラで使用されるOCIサービスおよびリソースへのアクセスを許可するポリシー・ステートメントを次の形式で入力します:

    Allow <group|dynamic-group> <subject-name> to <verb> <resource> in <location>

    ここでは:

    • <group|dynamic-group>は、group (ユーザー・プリンシパルの場合)またはdynamic-group (インスタンス・プリンシパルの場合)のいずれかです。
    • <subject-name>は、グループの名前(ユーザー・プリンシパルの場合)または動的グループの名前(インスタンス・プリンシパルの場合)のいずれかです。たとえば、acme-oke-nat-ing-cont-dyn-grpです。グループまたは動的グループがデフォルトのアイデンティティ・ドメインにない場合は、<group|dynamic-group> '<identity-domain-name>'/'<group-name|dynamic-group-name>'の形式で、グループまたは動的グループ名の前にアイデンティティ・ドメイン名を入力します。group id <group-ocid>またはdynamic-group id <dynamic-group-ocid>の形式で、そのOCIDを使用してグループまたは動的グループを指定することもできます。
    • <verb> <resource>は次のいずれかです(これらはすべて、個別のポリシー・ステートメントで必要です)。
      • manage load-balancers
      • use virtual-network-family
      • manage cabundles
      • manage cabundle-associations
      • manage leaf-certificates
      • read leaf-certificate-bundles
      • manage certificate-associations
      • read certificate-authorities
      • manage certificate-authority-associations
      • read certificate-authority-bundles
      • read public-ips
      • manage floating-ips
      • manage waf-family
      • read cluster-family
      • use tag-namespaces (OCIネイティブ・イングレス・コントローラで定義済タグをロード・バランサに適用する場合にのみ必要です。ロード・バランサへの定義済タグの適用を参照してください)
    • <location>は次のいずれかです。
      • tenancy: OCIネイティブ・イングレス・コントローラがテナンシ全体のリソースにアクセスできるようにする場合。
      • compartment <compartment-name>: OCIネイティブ・イングレス・コントローラに、compartment <compartment-name>として指定した名前のコンパートメント内のリソースへのアクセスのみを許可する場合。

    例:

    Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage load-balancers in compartment acme-oke-cluster-compartment

    ポリシー・ステートメントの完全なリストの構文は次のとおりです。

    Allow <group|dynamic-group> <subject-name> to manage load-balancers in <location>   
Allow <group|dynamic-group> <subject-name> to use virtual-network-family in <location>
Allow <group|dynamic-group> <subject-name> to manage cabundles in <location>
Allow <group|dynamic-group> <subject-name> to manage cabundle-associations in <location>
Allow <group|dynamic-group> <subject-name> to manage leaf-certificates in <location>
Allow <group|dynamic-group> <subject-name> to read leaf-certificate-bundles in <location>
Allow <group|dynamic-group> <subject-name> to manage certificate-associations in <location>
Allow <group|dynamic-group> <subject-name> to read certificate-authorities in <location>
Allow <group|dynamic-group> <subject-name> to manage certificate-authority-associations in <location>
Allow <group|dynamic-group> <subject-name> to read certificate-authority-bundles in <location>
Allow <group|dynamic-group> <subject-name> to read public-ips in <location>
Allow <group|dynamic-group> <subject-name> to manage floating-ips in <location>
Allow <group|dynamic-group> <subject-name> to manage waf-family in <location>
Allow <group|dynamic-group> <subject-name> to read cluster-family in <location>
Allow <group|dynamic-group> <subject-name> to use tag-namespaces in <location>

    ポリシー・ステートメントの完全なリストの例:

    Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage load-balancers in compartment acme-oke-cluster-compartment   
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to use virtual-network-family in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage cabundles in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage cabundle-associations in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage leaf-certificates in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read leaf-certificate-bundles in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage certificate-associations in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read certificate-authorities in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage certificate-authority-associations in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read certificate-authority-bundles in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read public-ips in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage floating-ips in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage waf-family in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read cluster-family in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to use tag-namespaces in compartment acme-oke-cluster-compartment
  4. ワークロード・アイデンティティ・プリンシパルを使用している場合は、OCIネイティブ・イングレス・コントローラで使用されるOCIサービスおよびリソースへのアクセスを許可するポリシー・ステートメントを次の形式で入力します:
    Allow any-user to <verb> <resource> in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}

    ここでは:

    • <verb> <resource>は次のいずれかです(これらはすべて、個別のポリシー・ステートメントで必要です)。
      • manage load-balancers
      • use virtual-network-family
      • manage cabundles
      • manage cabundle-associations
      • manage leaf-certificates
      • read leaf-certificate-bundles
      • manage certificate-associations
      • read certificate-authorities
      • manage certificate-authority-associations
      • read certificate-authority-bundles
      • read public-ips
      • manage floating-ips
      • manage waf-family
      • read cluster-family
      • use tag-namespaces (OCIネイティブ・イングレス・コントローラで定義済タグをロード・バランサに適用する場合にのみ必要です。ロード・バランサへの定義済タグの適用を参照してください)
    • <location>は次のいずれかです。
      • tenancy: OCIネイティブ・イングレス・コントローラがテナンシ全体のリソースにアクセスできるようにする場合。
      • compartment <compartment-name>: OCIネイティブ・イングレス・コントローラに、compartment <compartment-name>として指定した名前のコンパートメント内のリソースへのアクセスのみを許可する場合。
    • request.principal.namespace = 'native-ingress-controller-system'は、インストール時にOCIネイティブ・イングレス・コントローラ用に作成されたネームスペースの名前です。
    • request.principal.service_account = 'oci-native-ingress-controller'は、インストール時にOCIネイティブ・イングレス・コントローラ用に作成されたサービス・アカウントの名前です。
    • <cluster-ocid>は、以前に取得したクラスタのOCIDです。

    例:

    Allow any-user to manage load-balancers in tenancy where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = 'ocid1.cluster.oc1.iad.aaaaaaaa______ska'}

    ポリシー・ステートメントの完全なリストの構文は次のとおりです。

    Allow any-user to manage load-balancers in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to use virtual-network-family in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage cabundles in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage cabundle-associations in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage leaf-certificates in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to read leaf-certificate-bundles in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage certificate-associations in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to read certificate-authorities in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage certificate-authority-associations in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to read certificate-authority-bundles in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to read public-ips in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage floating-ips in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage waf-family in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to read cluster-family in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to use tag-namespaces in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}

cert-managerのインストール

OCIネイティブ・イングレス・コントローラは、スタンドアロン・プログラムとしてインストールされるか、クラスタ・アドオンとしてインストールされるかに関係なく、Webフックを使用してポッド準備ゲートをポッド仕様に注入します。セキュリティを確保するには、Webフック・サーバーをHTTPSモードで実行する必要があります。このモードでは、証明書とキーのペアが必要です。OCIネイティブ・イングレス・コントローラは、証明書マネージャ(cert-managerとも呼ばれる)を使用してWebフック・サーバーの証明書とキーを生成および管理するため、ポッド・レディネス・ゲートを使用するには、クラスタにcert-managerをインストールする必要があります。

OCIネイティブ・イングレス・コントローラをスタンドアロン・プログラムとしてインストールするか、クラスタ・アドオンとしてインストールするかに関係なく、次の2つの方法でcert-managerをインストールおよび実行できます。

  • 次のように入力して、cert-managerをオープンソース製品としてインストールおよび実行できます。

    kubectl apply -f https://github.com/jetstack/cert-manager/releases/latest/download/cert-manager.yaml

  • cert-managerはクラスタ・アドオンとしてインストールおよび実行できます。cert-managerをクラスタ・アドオンとしてインストールする方法の詳細は、「クラスタ・アドオンのインストール」を参照してください。

cert-managerの詳細は、cert-manager.ioのドキュメントを参照してください。

cert-managerを、オープン・ソース製品またはクラスタ・アドオンとしてまだインストールしていない場合、クラスタ・アドオンとしてOCIネイティブ・イングレス・コントローラのインストールは失敗します。