kubectlを使用したイングレス・ゲートウェイの管理

イングレス・ゲートウェイに必要なIAMポリシー

イングレス・ゲートウェイを使用するには、管理者がポリシー(IAM)で必要なアクセス・タイプを付与する必要があります。コンソール、REST API、SDK、CLI、Kubernetes kubectlまたはその他のツールのいずれを使用している場合でも、適切な権限が必要です。

Allow group MeshAdmins to manage mesh-ingress-gateways in compartment sales-app

イングレス・ゲートウェイのKubernetes構成オプションの表示

Kubernetes CLIイングレス・ゲートウェイYAML構成オプションを表示するには、カスタム・リソース定義(CRD)を表示します。次のコマンドを使用します:

kubectl get crd ingressgateways.servicemesh.oci.oracle.com -o yaml

CRDでは、spec:schema:openAPIV3Schema:properties:specの下のYAML構成ファイルで使用されているフィールドが表示されます。CRD出力には、フィールド・タイプ、範囲および制限に関する情報も含まれます。次の項では、YAML構成ファイルの例を示します。

イングレス・ゲートウェイの作成

イングレス・ゲートウェイを作成するには、kubectl applyコマンドを使用します。次に例を示します。

kubectl apply -f ingress-gateway.yaml

リソースは、YAML構成ファイルでmetadata:namespaceフィールドを指定することで、異なるネームスペースで作成できます。デフォルトでは、ネームスペースが指定されていない場合、サービス・メッシュは現在のネームスペースを使用します。YAML構成ファイルのスペック・セクションでメッシュを指定する場合は、メッシュ参照またはメッシュIDを使用できます。

apiVersion: servicemesh.oci.oracle.com/v1beta1
kind: IngressGateway
metadata:
  name: <sample-ingress-gateway>    # Name of Ingress Gateway
  namespace: <sample-namespace>
spec:
  compartmentId: ocid1.compartment.oc1..aaa...
  name: <sample-ig>     # Ingress Gateway name inside the mesh
  description: This Ingress Gateway
  mesh:
    ref:
      name: <sample-mesh>
      namespace: <sample-mesh-namespace>  # Namespace of the referenced CR. If unspecified, defaults to the referencing object's namespace.
  hosts:
    - name: samplehost
      hostnames:
        - samplehost.example.com
        - www.samplehost.example.com
      listeners:
        - port: 8080
          protocol: HTTP
          tls:
            mode: MUTUAL_TLS
            serverCertificate:
              ociTlsCertificate:
                certificateId: ocid1.certificate.oc1..aaa...
            clientValidation:
              trustedCaBundle:
                ociCaBundle:
                  caBundleId: ocid1.caBundle.oc1..aaa...
              subjectAlternateNames:
                - authorized1.client
                - authorized2.client
        - port: 9090
          protocol: HTTP
          tls:
            mode: TLS
            serverCertificate:
              kubeSecretTlsCertificate:
                secretName: sampleCertSecretName
  accessLogging:
    isEnabled: true

apiVersion: servicemesh.oci.oracle.com/v1beta1
kind: IngressGateway
metadata:
  name: <sample-ingress-gateway>    # Name of Ingress Gateway
  namespace: <sample-namespace>
spec:
  compartmentId: ocid1.compartment.oc1..aaa...
  name: <sample-ig>     # Ingress Gateway name inside the mesh
  description: This Ingress Gateway
  mesh:
    id: ocid1.mesh.oc1...aa...
  hosts:
    - name: samplehost
      hostnames:
        - samplehost.example.com
        - www.samplehost.example.com
      listeners:
        - port: 8080
          protocol: HTTP
          tls:
            mode: MUTUAL_TLS
            serverCertificate:
              ociTlsCertificate:
                certificateId: ocid1.certificate.oc1..aaa...
            clientValidation:
              trustedCaBundle:
                ociCaBundle:
                  caBundleId: ocid1.caBundle.oc1..aaa...
              subjectAlternateNames:
                - authorized1.client
                - authorized2.client
        - port: 9090
          protocol: HTTP
          tls:
            mode: TLS
            serverCertificate:
              kubeSecretTlsCertificate:
                secretName: sampleCertSecretName
  accessLogging:
    isEnabled: true

説明:

• <name>イングレス・ゲートウェイの名前。名前は同じサービス・メッシュ内で一意である必要があり、作成後に変更できません。名前は、文字またはアンダースコアで始まり、文字、数字、ハイフンまたはアンダースコアが続く必要があります。長さは1から255文字です。機密情報を入力しないでください。
• <compartmentId>: イングレス・ゲートウェイが属するコンパートメントのOCID。
• <mesh:id:>このインターネット・ゲートウェイが作成されるサービス・メッシュのOCID。
• <hosts>: このゲートウェイがバインドするホスト名とそのリスナー構成の配列。
  • <name>: ホストの使いやすい名前。名前は、メッシュ内のイングレス・ゲートウェイ間で一意である必要があります。この名前は、イングレス・ゲートウェイのルート表リソースで使用して、このホストにルートをアタッチできます。
  • <hostnames>:
    ゲートウェイのコール元が使用するDNSホスト名。ワイルドカード・ホスト名は接頭辞形式でサポートされています。このゲートウェイには最大10個のDNSホスト名を指定します。次の例は、有効なホスト名です: www.example.com, *.example.com, *.com, www.example.com:9080, *.example.com:9080

    注意
    
    メッシュ・リソースでは、15000、15003、15006および9901のサービス・メッシュ予約済ポートを使用しないでください。

    HTTPリスナーを使用するホストの場合、ホスト名はゲートウェイとの通信に使用されるHTTPホスト・ヘッダーと一致する必要があります。不一致が発生した場合、このゲートウェイに接続しているユーザーは404エラーを認識します。HTTPホストヘッダーは、標準ポート80および443に対して example.comという形式を使用します。9080のような非標準ポートの場合、ホスト・ヘッダーはexample.com:9080という形式を使用します。

    リスナーTLS_PASSTHROUGHを持つホストの場合、ホスト名は、ゲートウェイとの通信に使用されるサーバー名指示(SNI)と一致する必要があります。不一致が発生した場合、このゲートウェイに接続しているユーザーはTLSハンドシェイク・エラーを検出します。接頭辞形式のワイルドカードを使用できます。包括ワイルドカード*は使用できません。
• <listeners>:
  • <port>: リスニングするポートを指定します。
  • <protocol>: プロトコルHTTP、TCPまたはTLS_PASSTHROUGHを選択します。TLS_PASSTHROUGHが選択されている場合、プロキシはTLSを管理しません。暗号化されたデータは、TLSを独自に管理するアプリケーションにそのまま渡されます。
  • <tls>:
    • <mode>: 次から選択します:
      • 相互TLS: mTLSトラフィックのみが受け入れられます。メッシュおよび仮想サービス用のSTRICTなどの機能。
      • 許容: 接続はプレーン・テキストまたはTLS/mTLSのいずれかです。リスナーに対してTLSクライアント検証セクションが構成されている場合、mTLSが実行され、ゲートウェイはクライアントの証明書を検証します。TLSクライアントの検証セクションについては、フォームの次のセクションを参照してください。
      • TLS: 一方向TLS認証を許可します。ゲートウェイに接続しているクライアントのみがゲートウェイのアイデンティティを検証します。
      • Disabled: raw TCPトラフィックは受け入れられます。
    • <serviceCertificate>
      • <certificateId>: TLS証明書のOCID。
      • <secretName>: このフィールドにシークレット値を配置します。
    • <clientValidation>:
      • <trustedCaBundle >:
        • <ociCaBundle:caBundleId>: CAバンドルのOCID。
      • <subjectAlternateNames>: ここにドメイン名を入力します。例: example.com, servicemesh.example.com。

イングレス・ゲートウェイの更新

kubectlを使用してイングレス・ゲートウェイを更新するには:

1. 必要に応じて、イングレス・ゲートウェイの既存のYAML構成ファイルを変更します。
2. ファイルを保存します。
3. applyコマンドを再度実行します。

   kubectl apply -f ingress-gateway.yaml

イングレス・ゲートウェイの移動

イングレス・ゲートウェイを別のコンパートメントに移動するには:

1. コンパートメントOCIDを、イングレス・ゲートウェイの既存のYAML構成ファイル内のターゲット・コンパートメントの値に更新します。
2. ファイルを保存します。
3. applyコマンドを再度実行します。

   kubectl apply -f ingress-gateway.yaml

イングレス・ゲートウェイのリストの取得

ネームスペースのイングレス・ゲートウェイのリストを取得するには、次のコマンドを使用します:

kubectl get ingressgateways -n <namespace>

イングレス・ゲートウェイ詳細の取得

ネームスペース内の特定のイングレス・ゲートウェイの詳細を表示するには、次のコマンドを使用します:

kubectl describe ingressgateway <name> -n <namespace>

イングレス・ゲートウェイの削除

ネームスペース内の特定のイングレス・ゲートウェイを削除するには、次のコマンドを使用します:

kubectl delete ingressgateway <name> -n <namespace>