ネットワーク Operator


Red Hat OpenShift Service on AWS 4

Red Hat OpenShift Service on AWS におけるネットワーク固有の Operator の管理

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、Red Hat OpenShift Service on AWS におけるさまざまなネットワーク関連 Operator のインストール、設定、および管理を説明します。

第1章 AWS Load Balancer Operator

AWS Load Balancer Operator は、Red Hat がサポートする Operator です。ユーザーは、これを SRE が管理する Red Hat OpenShift Service on AWS クラスターに必要に応じてインストールできます。

重要

AWS Load Balancer Operator によって作成されたロードバランサーは、OpenShift ルート には使用できません。OpenShift ルートのレイヤー 7 機能をすべて必要としない個々のサービスまたは Ingress リソースにのみ使用する必要があります。

AWS Load Balancer Operator は、Red Hat OpenShift Service on AWS クラスターで AWS Load Balancer Controller をインストール、管理、および設定するために使用されます。

AWS Load Balancer Controller は、Kubernetes Ingress リソースを作成する際に AWS Application Load Balancers (ALB) をプロビジョニングし、LoadBalancer タイプを使用して Kubernetes Service リソースを作成する際に AWS Network Load Balancers (NLB) をプロビジョニングします。

デフォルトの AWS インツリーロードバランサープロバイダーと比較して、このコントローラーは ALB と NLB 用の詳細なアノテーションを使用して開発されています。高度な使用例としては以下が挙げられます。

  • ネイティブ Kubernetes Ingress オブジェクトと ALB を使用する
  • AWS ウェブアプリケーションファイアウォール (WAF) サービスと ALB を統合する
  • カスタムの NLB ソース IP 範囲を指定する
  • カスタムの NLB 内部 IP アドレスを指定する

1.1. AWS Load Balancer Operator のインストール準備

AWS Load Balancer Operator をインストールする前に、クラスターが要件を満たしていること、および AWS VPC リソースが適切にタグ付けされていることを確認してください。役立つ環境変数を設定するオプションもあります。

1.1.1. クラスターの要件

クラスターは、3 つのパブリックサブネットを持つ既存の VPC を使用して、3 つのアベイラビリティーゾーンにデプロイする必要があります。

重要

これらの要件は、AWS Load Balancer Operator が一部の PrivateLink クラスターに適さない可能性があることを意味します。このようなクラスターには AWS NLB の方が適している可能性があります。

1.1.2. 一時的な環境変数のセットアップ

リソース識別子と設定の詳細を保持するために、一時的な環境変数をセットアップするオプションがあります。一時環境変数を使用すると、AWS Load Balancer Operator のインストールコマンドを実行するプロセスが効率化されます。

特定の値を保存するために環境変数を使用しない場合は、関連するインストールコマンドにそれらの値を手動で入力できます。

前提条件

  • AWS CLI (aws) をインストールしている。
  • OC CLI (oc) がインストールされている。

手順

  1. OpenShift CLI (oc) を使用して、クラスター管理者としてクラスターにログインします。

    $ oc login --token=<token> --server=<cluster_url>
    Copy to Clipboard Toggle word wrap
  2. 環境変数をセットアップするには、次のコマンドを実行します。

    $ export CLUSTER_NAME=$(oc get infrastructure cluster -o=jsonpath="{.status.apiServerURL}" | sed  's|^https://||' | awk -F . '{print $2}')
    $ export REGION=$(oc get infrastructure cluster -o=jsonpath="{.status.platformStatus.aws.region}")
    $ export OIDC_ENDPOINT=$(oc get authentication.config.openshift.io cluster -o jsonpath='{.spec.serviceAccountIssuer}' | sed  's|^https://||')
    $ export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
    $ export SCRATCH="/tmp/${CLUSTER_NAME}/alb-operator"
    $ mkdir -p ${SCRATCH}
    Copy to Clipboard Toggle word wrap

    これらのコマンドは、このターミナルセッションで使用してその値をコマンドラインインターフェイスに渡すことができる環境変数を作成します。

  3. 次のコマンドを実行して、変数値が正しく設定されていることを確認します。

    $ echo "Cluster name: ${CLUSTER_NAME}
    Region: ${REGION}
    OIDC Endpoint: ${OIDC_ENDPOINT}
    AWS Account ID: ${AWS_ACCOUNT_ID}"
    Copy to Clipboard Toggle word wrap

    出力例

    Cluster name: <cluster_id>
    Region: <region>
    OIDC Endpoint: oidc.op1.openshiftapps.com/<oidc_id>
    AWS Account ID: <aws_id>
    Copy to Clipboard Toggle word wrap

次のステップ

  • 環境変数が失われないように、同じターミナルセッションを使用して AWS Load Balancer Operator のインストールを続行します。

1.1.3. AWS VPC とサブネットにタグを付ける

AWS Load Balancer Operator をインストールする前に、AWS VPC リソースにタグを付ける必要があります。

前提条件

  • AWS CLI (aws) をインストールしている。
  • OC CLI (oc) がインストールされている。

手順

  1. オプション: AWS VPC リソースの環境変数をセットアップします。

    $ export VPC_ID=<vpc-id>
    $ export PUBLIC_SUBNET_IDS="<public-subnet-a-id> <public-subnet-b-id> <public-subnet-c-id>"
    $ export PRIVATE_SUBNET_IDS="<private-subnet-a-id> <private-subnet-b-id> <private-subnet-c-id>"
    Copy to Clipboard Toggle word wrap
  2. VPC にタグを付けてクラスターに関連付けます。

    $ aws ec2 create-tags --resources ${VPC_ID} --tags Key=kubernetes.io/cluster/${CLUSTER_NAME},Value=owned --region ${REGION}
    Copy to Clipboard Toggle word wrap
  3. パブリックサブネットにタグを付けて、Elastic Load Balancing ロールによる変更を許可し、プライベートサブネットにタグを付けて、内部 Elastic Load Balancing ロールによる変更を許可します。

    cat <<EOF > "${SCRATCH}/tag-subnets.sh"
    #!/bin/bash
    
    aws ec2 create-tags \
         --resources ${PUBLIC_SUBNET_IDS} \
         --tags Key=kubernetes.io/role/elb,Value='' \
         --region ${REGION}
    
    aws ec2 create-tags \
         --resources ${PRIVATE_SUBNET_IDS} \
         --tags Key=kubernetes.io/role/internal-elb,Value='' \
         --region ${REGION}
    
    EOF
    Copy to Clipboard Toggle word wrap
  4. スクリプトを実行します。

    bash ${SCRATCH}/tag-subnets.sh
    Copy to Clipboard Toggle word wrap

関連情報

1.2. AWS Load Balancer Operator のインストール

OpenShift CLI (oc) を使用して AWS Load Balancer Operator をインストールできます。環境変数を活用するため、環境のセットアップで AWS Load Balancer Operator をインストール した際と同じターミナルセッションを使用します。

手順

  1. AWS Load Balancer Operator 用にクラスター内に新しいプロジェクトを作成します。

    $ oc new-project aws-load-balancer-operator
    Copy to Clipboard Toggle word wrap
  2. AWS Load Balancer Operator 用の AWS IAM ポリシーを作成します。

    1. 適切な IAM ポリシーをダウンロードします。

      $ curl -o ${SCRATCH}/operator-permission-policy.json https://raw.githubusercontent.com/openshift/aws-load-balancer-operator/refs/heads/main/hack/operator-permission-policy.json
      Copy to Clipboard Toggle word wrap
    2. Operator の権限ポリシーを作成します。

      $ aws iam create-policy \
              --policy-name aws-load-balancer-operator-policy \
              --policy-document file://${SCRATCH}/operator-permission-policy.json \
              --region ${REGION}
      Copy to Clipboard Toggle word wrap

      出力内の Operator ポリシー ARN をメモします。このプロセスの残りの部分では、これを $OPERATOR_POLICY_ARN と呼びます。

  3. AWS Load Balancer Operator の AWS IAM ロールを作成します。

    1. Operator ロールの信頼ポリシーを作成します。

      $ cat <<EOF > "${SCRATCH}/operator-trust-policy.json"
      {
       "Version": "2012-10-17",
       "Statement": [
       {
       "Effect": "Allow",
       "Condition": {
         "StringEquals" : {
           "${OIDC_ENDPOINT}:sub": ["system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-operator-controller-manager", "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-controller-cluster"]
         }
       },
       "Principal": {
         "Federated": "arn:aws:iam::${AWS_ACCOUNT_ID}:oidc-provider/${OIDC_ENDPOINT}"
       },
       "Action": "sts:AssumeRoleWithWebIdentity"
       }
       ]
      }
      EOF
      Copy to Clipboard Toggle word wrap
    2. 信頼ポリシーを使用して Operator ロールを作成します。

      $ aws iam create-role --role-name "${CLUSTER_NAME}-alb-operator" \
          --assume-role-policy-document "file://${SCRATCH}/operator-trust-policy.json"
      Copy to Clipboard Toggle word wrap

      出力内の Operator ロール ARN をメモします。このプロセスの残りの部分では、これを $OPERATOR_ROLE_ARN と呼びます。

    3. Operator ロールとポリシーを関連付けます。

      $ aws iam attach-role-policy --role-name "${CLUSTER_NAME}-alb-operator" \
          --policy-arn $OPERATOR_POLICY_ARN
      Copy to Clipboard Toggle word wrap
  4. OperatorGroupSubscription を作成して、AWS Load Balancer Operator をインストールします。

    $ cat <<EOF | oc apply -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: aws-load-balancer-operator
      namespace: aws-load-balancer-operator
    spec:
      targetNamespaces: []
    ---
    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: aws-load-balancer-operator
      namespace: aws-load-balancer-operator
    spec:
      channel: stable-v1
      name: aws-load-balancer-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      config:
        env:
        - name: ROLEARN
          value: "${OPERATOR_ROLE_ARN}"
    EOF
    Copy to Clipboard Toggle word wrap
  5. AWS Load Balancer Controller の AWS IAM ポリシーを作成します。

    1. 適切な IAM ポリシーをダウンロードします。

      $ curl -o ${SCRATCH}/controller-permission-policy.json https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.12.0/docs/install/iam_policy.json
      Copy to Clipboard Toggle word wrap
    2. Controller の権限ポリシーを作成します。

      $ aws iam create-policy \
          --region ${REGION} \
          --policy-name aws-load-balancer-controller-policy \
          --policy-document file://${SCRATCH}/controller-permission-policy.json
      Copy to Clipboard Toggle word wrap

      出力内の Controller ポリシー ARN をメモします。このプロセスの残りの部分では、これを $CONTROLLER_POLICY_ARN と呼びます。

  6. AWS Load Balancer Controller 用の AWS IAM ロールを作成します。

    1. Controller ロールの信頼ポリシーを作成します。

      $ cat <<EOF > ${SCRATCH}/controller-trust-policy.json
      {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::${AWS_ACCOUNT_ID}:oidc-provider/${OIDC_ENDPOINT}"
              },
              "Action": "sts:AssumeRoleWithWebIdentity",
              "Condition": {
                "StringEquals": {
                  "${OIDC_ENDPOINT}:sub": "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-controller-cluster"
                  }
              }
            }
          ]
        }
      EOF
      Copy to Clipboard Toggle word wrap
    2. 信頼ポリシーを使用して Controller ロールを作成します。

      CONTROLLER_ROLE_ARN=$(aws iam create-role --role-name "${CLUSTER_NAME}-albo-controller" \ --assume-role-policy-document "file://${SCRATCH}/controller-trust-policy.json" \ --query Role.Arn --output text) echo ${CONTROLLER_ROLE_ARN}
      Copy to Clipboard Toggle word wrap

      出力内の Controller ロール ARN をメモします。このプロセスの残りの部分では、これを $CONTROLLER_ROLE_ARN と呼びます。

    3. Controller のロールとポリシーを関連付けます。

      $ aws iam attach-role-policy \
          --role-name "${CLUSTER_NAME}-albo-controller" \
          --policy-arn ${CONTROLLER_POLICY_ARN}
      Copy to Clipboard Toggle word wrap
  7. AWS Load Balancer Controller のインスタンスをデプロイします。

    $ cat << EOF | oc apply -f -
    apiVersion: networking.olm.openshift.io/v1
    kind: AWSLoadBalancerController
    metadata:
     name: cluster
    spec:
     credentialsRequestConfig:
       stsIAMRoleARN: ${CONTROLLER_ROLE_ARN}
    EOF
    Copy to Clipboard Toggle word wrap
    注記

    ここでエラーが発生した場合は、少し待ってから再試行してください。エラーが発生するのは、Operator がまだインストールを完了していないためです。

  8. Operator Pod と Controller Pod の両方が実行されていることを確認します。

    $ oc -n aws-load-balancer-operator get pods
    Copy to Clipboard Toggle word wrap

    次のような出力が表示されない場合は、しばらく待ってから再試行してください。

    出力例

    NAME                                                             READY   STATUS    RESTARTS   AGE
    aws-load-balancer-controller-cluster-6ddf658785-pdp5d            1/1     Running   0          99s
    aws-load-balancer-operator-controller-manager-577d9ffcb9-w6zqn   2/2     Running   0          2m4s
    Copy to Clipboard Toggle word wrap

1.3. Operator インストールの検証

基本的なサンプルアプリケーションをデプロイし、Ingress および負荷分散サービスを作成して、AWS Load Balancer Operator と Controller が正しくデプロイされていることを確認します。

手順

  1. プロジェクトを新規作成します。

    $ oc new-project hello-world
    Copy to Clipboard Toggle word wrap
  2. hello-openshift イメージに基づいて新しい hello-world アプリケーションを作成します。

    $ oc new-app -n hello-world --image=docker.io/openshift/hello-openshift
    Copy to Clipboard Toggle word wrap
  3. AWS Application Load Balancer (ALB) が接続するための NodePort サービスを設定します。

    $ cat << EOF | oc apply -f -
    apiVersion: v1
    kind: Service
    metadata:
      name: hello-openshift-nodeport
      namespace: hello-world
    spec:
      ports:
        - port: 80
          targetPort: 8080
          protocol: TCP
      type: NodePort
      selector:
        deployment: hello-openshift
    EOF
    Copy to Clipboard Toggle word wrap
  4. アプリケーション用の AWS ALB をデプロイします。

    $ cat << EOF | oc apply -f -
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: hello-openshift-alb
      namespace: hello-world
      annotations:
        alb.ingress.kubernetes.io/scheme: internet-facing
    spec:
      ingressClassName: alb
      rules:
        - http:
            paths:
              - path: /
                pathType: Exact
                backend:
                  service:
                    name: hello-openshift-nodeport
                    port:
                      number: 80
    EOF
    Copy to Clipboard Toggle word wrap
  5. アプリケーションの AWS ALB エンドポイントへのアクセスをテストします。

    注記

    ALB のプロビジョニングには数分かかります。curl: (6) Could not resolve host というエラーが表示された場合は、待機してから再試行してください。

    $ ALB_INGRESS=$(oc -n hello-world get ingress hello-openshift-alb \
        -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
    $ curl "http://${ALB_INGRESS}"
    Copy to Clipboard Toggle word wrap

    出力例

    Hello OpenShift!
    Copy to Clipboard Toggle word wrap

  6. アプリケーション用の AWS Network Load Balancer (NLB) をデプロイします。

    $ cat << EOF | oc apply -f -
    apiVersion: v1
    kind: Service
    metadata:
      name: hello-openshift-nlb
      namespace: hello-world
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-type: external
        service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: instance
        service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
    spec:
      ports:
        - port: 80
          targetPort: 8080
          protocol: TCP
      type: LoadBalancer
      selector:
        deployment: hello-openshift
    EOF
    Copy to Clipboard Toggle word wrap
  7. アプリケーションの NLB エンドポイントへのアクセスをテストします。

    注記

    NLB のプロビジョニングには数分かかります。curl: (6) Could not resolve host というエラーが表示された場合は、待機してから再試行してください。

    $ NLB=$(oc -n hello-world get service hello-openshift-nlb \
      -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
    $ curl "http://${NLB}"
    Copy to Clipboard Toggle word wrap

    出力例

    Hello OpenShift!
    Copy to Clipboard Toggle word wrap

  8. これで、サンプルアプリケーションと hello-world namespace 内のすべてのリソースを削除できます。

    $ oc delete project hello-world
    Copy to Clipboard Toggle word wrap

1.4. AWS Load Balancer Operator の削除

AWS Load Balancer Operator を使用する必要がなくなった場合は、Operator を削除し、関連するロールとポリシーを削除できます。

手順

  1. Operator のサブスクリプションを削除します。

    $ oc delete subscription aws-load-balancer-operator -n aws-load-balancer-operator
    Copy to Clipboard Toggle word wrap
  2. 関連する AWS IAM ロールをデタッチして削除します。

    $ aws iam detach-role-policy \
      --role-name "<cluster-id>-alb-operator" \
      --policy-arn <operator-policy-arn>
    $ aws iam delete-role \
      --role-name "<cluster-id>-alb-operator"
    Copy to Clipboard Toggle word wrap
  3. AWS IAM ポリシーを削除します。

    $ aws iam delete-policy --policy-arn <operator-policy-arn>
    Copy to Clipboard Toggle word wrap

第2章 Red Hat OpenShift Service on AWS の DNS Operator

Red Hat OpenShift Service on AWS の DNS Operator は、CoreDNS インスタンスをデプロイおよび管理して、クラスター内の Pod に名前解決サービスを提供し、DNS ベースの Kubernetes Service 検出を有効にし、内部の cluster.local 名を解決します。

この Operator は、デフォルトで Red Hat OpenShift Service on AWS クラスターにインストールされています。

2.1. DNS 転送の使用

次の方法で、DNS 転送を使用して /etc/resolv.conf ファイル内のデフォルトの転送設定をオーバーライドできます。

  • すべてのゾーンにネームサーバー (spec.servers) を指定します。転送されるゾーンが Red Hat OpenShift Service on AWS に管理される Ingress ドメインである場合は、アップストリームネームサーバーがドメインに対して認証される必要があります。

    重要

    少なくとも 1 つのゾーンを指定する必要があります。そうしないと、クラスターの機能が失われる可能性があります。

  • アップストリーム DNS サーバーのリスト (spec.upstreamResolvers) を指定します。
  • デフォルトの転送ポリシーを変更します。
注記

デフォルトドメインの DNS 転送設定には、/etc/resolv.conf ファイルおよびアップストリーム DNS サーバーで指定されたデフォルトのサーバーの両方を設定できます。

手順

  • default という名前の DNS Operator オブジェクトを変更します。

    $ oc edit dns.operator/default
    Copy to Clipboard Toggle word wrap

    上記のコマンドを実行すると、Operator が、spec.servers に基づく追加のサーバー設定ブロックを使用して dns-default という名前の config map を作成および更新します。

    重要

    zones パラメーターの値を指定する場合は、イントラネットなどの特定のゾーンにのみ転送してください。少なくとも 1 つのゾーンを指定する必要があります。そうしないと、クラスターの機能が失われる可能性があります。

    クエリーに一致するゾーンがサーバーにない場合には、名前解決はアップストリーム DNS サーバーにフォールバックします。

    DNS 転送の設定

    apiVersion: operator.openshift.io/v1
    kind: DNS
    metadata:
      name: default
    spec:
      cache:
        negativeTTL: 0s
        positiveTTL: 0s
      logLevel: Normal
      nodePlacement: {}
      operatorLogLevel: Normal
      servers:
      - name: example-server 
    1
    
        zones:
        - example.com 
    2
    
        forwardPlugin:
          policy: Random 
    3
    
          upstreams: 
    4
    
          - 1.1.1.1
          - 2.2.2.2:5353
      upstreamResolvers: 
    5
    
        policy: Random 
    6
    
        protocolStrategy: ""  
    7
    
        transportConfig: {}  
    8
    
        upstreams:
        - type: SystemResolvConf 
    9
    
        - type: Network
          address: 1.2.3.4 
    10
    
          port: 53 
    11
    
        status:
          clusterDomain: cluster.local
          clusterIP: x.y.z.10
          conditions:
    ...
    Copy to Clipboard Toggle word wrap

    1
    rfc6335 サービス名の構文に準拠する必要があります。
    2
    rfc1123 サービス名構文のサブドメインの定義に準拠する必要があります。クラスタードメインの cluster.local は、zones フィールドの無効なサブドメインです。
    3
    forwardPlugin にリストされているアップストリームリゾルバーを選択するポリシーを定義します。デフォルト値は Random です。RoundRobin および Sequential の値を使用することもできます。
    4
    forwardPlugin ごとに最大 15 の upstreams が許可されます。
    5
    upstreamResolvers を使用すると、デフォルトの転送ポリシーをオーバーライドし、デフォルトドメインの指定された DNS リゾルバー (アップストリームリゾルバー) に DNS 解決を転送できます。アップストリームリゾルバーを提供しなかった場合、DNS 名のクエリーが /etc/resolv.conf で宣言されたサーバーに送信されます。
    6
    upstreams にリストされているアップストリームサーバーをクエリーのために選択する順序を決定します。RandomRoundRobin、または Sequential のいずれかの値を指定できます。デフォルト値は Sequential です。
    7
    省略すると、デフォルト (通常は元のクライアント要求のプロトコル) が選択されます。TCP に設定すると、クライアント要求が UDP を使用する場合でも、すべてのアップストリーム DNS 要求に対して TCP が必ず使用されます。
    8
    DNS 要求をアップストリームリゾルバーに転送するときに使用するトランスポートタイプ、サーバー名、およびオプションのカスタム CA または CA バンドルを設定するために使用されます。
    9
    2 種類の upstreams (SystemResolvConf または Network) を指定できます。SystemResolvConf で、アップストリームが /etc/resolv.conf を使用するように設定して、NetworkNetworkresolver を定義します。1 つまたは両方を指定できます。
    10
    指定したタイプが Network の場合には、IP アドレスを指定する必要があります。address フィールドは、有効な IPv4 または IPv6 アドレスである必要があります。
    11
    指定したタイプが Network の場合、必要に応じてポートを指定できます。port フィールドには 1 - 65535 の値を指定する必要があります。アップストリームのポートを指定しない場合、デフォルトのポートは 853 です。

第3章 Red Hat OpenShift Service on AWS の Ingress Operator

Ingress Operator は IngressController API を実装し、Red Hat OpenShift Service on AWS クラスターサービスへの外部アクセスを可能にするコンポーネントです。

この Operator は、デフォルトで Red Hat OpenShift Service on AWS クラスターにインストールされています。

3.1. Red Hat OpenShift Service on AWS Ingress Operator

Red Hat OpenShift Service on AWS クラスターを作成すると、クラスターで実行されている Pod とサービスにそれぞれ独自の IP アドレスが割り当てられます。IP アドレスは、近くで実行されている他の Pod やサービスからアクセスできますが、外部クライアントの外部からはアクセスできません。

Ingress Operator を使用すると、ルーティングを処理する 1 つ以上の HAProxy ベースの Ingress Controller をデプロイおよび管理することにより、外部クライアントがサービスにアクセスできるようになります。

Red Hat Site Reliability Engineer (SRE) は、Red Hat OpenShift Service on AWS クラスターの Ingress Operator を管理します。Ingress Operator の設定を変更することはできませんが、デフォルトの Ingress Controller の設定、ステータス、およびログおよび Ingress Operator ステータスを表示できます。

3.2. デフォルト Ingress Controller の表示

Ingress Operator は Red Hat OpenShift Service on AWS のコア機能であり、すぐに有効にできます。

Red Hat OpenShift Service on AWS の新しいインストールにはすべて、default という名前の ingresscontroller があります。これは、追加の Ingress Controller で補足できます。デフォルトの ingresscontroller が削除される場合、Ingress Operator は 1 分以内にこれを自動的に再作成します。

手順

  • デフォルト Ingress Controller を表示します。

    $ oc describe --namespace=openshift-ingress-operator ingresscontroller/default
    Copy to Clipboard Toggle word wrap

3.3. Ingress Operator ステータスの表示

Ingress Operator のステータスを表示し、検査することができます。

手順

  • Ingress Operator ステータスを表示します。

    $ oc describe clusteroperators/ingress
    Copy to Clipboard Toggle word wrap

3.4. Ingress Controller ログの表示

Ingress Controller ログを表示できます。

手順

  • Ingress Controller ログを表示します。

    $ oc logs --namespace=openshift-ingress-operator deployments/ingress-operator -c <container_name>
    Copy to Clipboard Toggle word wrap

3.5. Ingress Controller ステータスの表示

特定の Ingress Controller のステータスを表示できます。

手順

  • Ingress Controller のステータスを表示します。

    $ oc describe --namespace=openshift-ingress-operator ingresscontroller/<name>
    Copy to Clipboard Toggle word wrap

3.6. default Ingress Controller 機能の管理

次の表は、Ingress Operator によって管理される default Ingress Controller のコンポーネントと、Red Hat Site Reliability Engineering (SRE) が Red Hat OpenShift Service on AWS クラスターでこのコンポーネントを管理するかどうかの詳細を示しています。

Expand
表3.1 Ingress Operator の責務チャート
Ingress コンポーネント管理デフォルト設定?

Ingress Controller のスケーリング

SRE

はい

Ingress Operator のスレッド数

SRE

はい

Ingress Controller のアクセスロギング

SRE

はい

Ingress Controller のシャード化

SRE

はい

Ingress Controller ルートの受付ポリシー

SRE

はい

Ingress Controller のワイルドカードルート

SRE

はい

Ingress Controller X-Forwarded ヘッダー

SRE

はい

Ingress Controller ルートの圧縮

SRE

はい

第4章 Red Hat OpenShift Service on AWS の Ingress Node Firewall Operator

Ingress Node Firewall Operator は、Red Hat OpenShift Service on AWS でノードレベルの Ingress トラフィックを管理するための、ステートレスな eBPF ベースのファイアウォールを提供します。

4.1. Ingress Node Firewall Operator

Ingress Node Firewall Operator は、ファイアウォール設定で指定および管理するノードにデーモンセットをデプロイすることにより、ノードレベルで Ingress ファイアウォールルールを提供します。デーモンセットをデプロイするには、IngressNodeFirewallConfig カスタムリソース (CR) を作成します。Operator は IngressNodeFirewallConfig CR を適用して、nodeSelector に一致するすべてのノードで実行される ingress ノードファイアウォールデーモンセット (daemon) を作成します。

IngressNodeFirewall CR の rules を設定し、nodeSelector を使用して値を "true" に設定してクラスターに適用します。

重要

Ingress Node Firewall Operator は、ステートレスファイアウォールルールのみをサポートします。

ネイティブ XDP ドライバーをサポートしないネットワークインターフェイスコントローラー (NIC) は、より低いパフォーマンスで実行されます。

Ingress Node Firewall Operator は、Red Hat OpenShift Service on AWS 4.14 以降で実行する必要があります。

4.2. Ingress Node Firewall Operator のインストール

クラスター管理者は、Red Hat OpenShift Service on AWS CLI または Web コンソールを使用して Ingress Node Firewall Operator をインストールできます。

4.2.1. CLI を使用した Ingress Node Firewall Operator のインストール

クラスター管理者は、CLI を使用して Operator をインストールできます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • 管理者権限を持つアカウントがある。

手順

  1. openshift-ingress-node-firewall namespace を作成するには、次のコマンドを入力します。

    $ cat << EOF| oc create -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      labels:
        pod-security.kubernetes.io/enforce: privileged
        pod-security.kubernetes.io/enforce-version: v1.24
      name: openshift-ingress-node-firewall
    EOF
    Copy to Clipboard Toggle word wrap
  2. OperatorGroup CR を作成するには、以下のコマンドを実行します。

    $ cat << EOF| oc create -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: ingress-node-firewall-operators
      namespace: openshift-ingress-node-firewall
    EOF
    Copy to Clipboard Toggle word wrap
  3. Ingress Node Firewall Operator にサブスクライブします。

    • Ingress Node Firewall Operator の Subscription CR を作成するには、次のコマンドを入力します。

      $ cat << EOF| oc create -f -
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: ingress-node-firewall-sub
        namespace: openshift-ingress-node-firewall
      spec:
        name: ingress-node-firewall
        channel: stable
        source: redhat-operators
        sourceNamespace: openshift-marketplace
      EOF
      Copy to Clipboard Toggle word wrap
  4. Operator がインストールされていることを確認するには、以下のコマンドを入力します。

    $ oc get ip -n openshift-ingress-node-firewall
    Copy to Clipboard Toggle word wrap

    出力例

    NAME            CSV                                         APPROVAL    APPROVED
    install-5cvnz   ingress-node-firewall.4.0-202211122336   Automatic   true
    Copy to Clipboard Toggle word wrap

  5. Operator のバージョンを確認するには、次のコマンドを入力します。

    $ oc get csv -n openshift-ingress-node-firewall
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                        DISPLAY                          VERSION               REPLACES                                    PHASE
    ingress-node-firewall.4.0-202211122336   Ingress Node Firewall Operator   4.0-202211122336   ingress-node-firewall.4.0-202211102047   Succeeded
    Copy to Clipboard Toggle word wrap

4.2.2. Web コンソールを使用した Ingress Node Firewall Operator のインストール

クラスター管理者は、Web コンソールを使用して Operator をインストールできます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • 管理者権限を持つアカウントがある。

手順

  1. Ingress Node Firewall Operator をインストールします。

    1. Red Hat OpenShift Service on AWS Web コンソールで、OperatorOperatorHub をクリックします。
    2. 利用可能な Operator のリストから Ingress Node Firewall Operator を選択し、Install をクリックします。
    3. Install Operator ページの Installed Namespace で、Operator recommended Namespace を選択します。
    4. Install をクリックします。
  2. Ingress Node Firewall Operator が正常にインストールされていることを確認します。

    1. OperatorsInstalled Operators ページに移動します。
    2. Ingress Node Firewall Operatoropenshift-ingress-node-firewall プロジェクトにリストされ、StatusInstallSucceeded であることを確認します。

      注記

      インストール時に、Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。

      Operator の StatusInstallSucceeded でない場合は、次の手順を使用してトラブルシューティングを行います。

      • Operator Subscriptions および Install Plans タブで、Status の下の失敗またはエラーの有無を確認します。
      • WorkloadsPods ページに移動し、openshift-ingress-node-firewall プロジェクトの Pod のログを確認します。
      • YAML ファイルの namespace を確認してください。アノテーションが抜けている場合は、次のコマンドを使用して、アノテーション workload.openshift.io/allowed=management を Operator namespace に追加できます。

        $ oc annotate ns/openshift-ingress-node-firewall workload.openshift.io/allowed=management
        Copy to Clipboard Toggle word wrap
        注記

        単一ノードの OpenShift クラスターの場合、openshift-ingress-node-firewall namespace には workload.openshift.io/allowed=management アノテーションが必要です。

4.3. Ingress Node Firewall Operator のデプロイ

前提条件

  • Ingress Node Firewall Operator がインストールされます。

手順

Ingress Node Firewall Operator をデプロイするには、Operator のデーモンセットをデプロイする IngressNodeFirewallConfig カスタムリソースを作成します。ファイアウォールルールを適用することで、1 つまたは複数の IngressNodeFirewall CRD をノードにデプロイできます。

  1. ingressnodefirewallconfig という名前の openshift-ingress-node-firewall namespace 内に IngressNodeFirewallConfig を作成します。
  2. 次のコマンドを実行して、Ingress Node Firewall Operator ルールをデプロイします。

    $ oc apply -f rule.yaml
    Copy to Clipboard Toggle word wrap

4.3.1. Ingress ノードファイアウォール設定オブジェクト

Ingress Node Firewall 設定オブジェクトのフィールドについて、次の表で説明します。

Expand
表4.1 Ingress ノードファイアウォール設定オブジェクト
フィールド説明

metadata.name

string

CR オブジェクトの名前。ファイアウォールルールオブジェクトの名前は ingressnodefirewallconfig である必要があります。

metadata.namespace

string

Ingress Firewall Operator CR オブジェクトの namespace。IngressNodeFirewallConfig CR は、openshift-ingress-node-firewall namespace 内に作成する必要があります。

spec.nodeSelector

string

指定されたノードラベルを介してノードをターゲットにするために使用されるノード選択制約。以下に例を示します。

spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ""
Copy to Clipboard Toggle word wrap
注記

デーモンセットを開始するには、nodeSelector で使用される 1 つのラベルがノードのラベルと一致する必要があります。たとえば、ノードラベル node-role.kubernetes.io/worker および node-type.kubernetes.io/vm がノードに適用される場合、デーモンセットを開始するには、nodeSelector を使用して少なくとも 1 つのラベルを設定する必要があります。

spec.ebpfProgramManagerMode

boolean

Node Ingress Firewall Operator が eBPF プログラムを管理するために eBPF Manager Operator を使用するかどうかを指定します。この機能はテクノロジープレビュー機能です。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

注記

Operator はまず、すべてのノードでデーモンセットを生成するために、IngressNodeFirewallConfig を使用します。これを作成した後、追加のファイアウォールルールオブジェクトを作成できます。

4.3.2. Ingress Node Firewall Operator の設定例

次の例では、完全な Ingress ノードファイアウォール設定が指定されています。

Ingress ノードファイアウォール設定オブジェクトを作成する方法の例

$ cat << EOF | oc create -f -
apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewallConfig
metadata:
  name: ingressnodefirewallconfig
  namespace: openshift-ingress-node-firewall
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ""
EOF
Copy to Clipboard Toggle word wrap

注記

Operator は CR オブジェクトを消費し、nodeSelector に 一致するすべてのノードに Ingress ノードファイアウォールデーモンセットを作成します。

4.3.3. Ingress ノードファイアウォールルールオブジェクト

Ingress ノードファイアウォールルールオブジェクトのフィールドについて、次の表で説明します。

Expand
表4.2 Ingress ノードファイアウォールルールオブジェクト
フィールド説明

metadata.name

string

CR オブジェクトの名前。

interfaces

array

このオブジェクトのフィールドは、ファイアウォールルールを適用するインターフェイスを指定します。たとえば、-en0-en1 です。

nodeSelector

array

nodeSelector を使用して、ファイアウォールルールを適用するノードを選択できます。名前付き nodeselector ラベルの値を true に設定して、ルールを適用します。

ingress

object

ingress を使用すると、クラスター上のサービスへの外部アクセスを許可するルールを設定できます。

4.3.3.1. Ingress オブジェクトの設定

ingress オブジェクトの値は、次の表で定義されています。

Expand
表4.3 ingress オブジェクト
フィールド説明

sourceCIDRs

array

CIDR ブロックを設定できます。異なるアドレスファミリーから複数の CIDR を設定できます。

注記

異なる CIDR を使用すると、同じ順序ルールを使用できます。CIDR が重複する同じノードおよびインターフェイスに対して複数の IngressNodeFirewall オブジェクトがある場合、order フィールドは最初に適用されるルールを指定します。ルールは昇順で適用されます。

rules

array

Ingress ファイアウォール rules.order オブジェクトは、source.CIDR ごとに 1 から順に並べられ、CIDR ごとに最大 100 のルールがあります。低次ルールが最初に実行されます。

rules.protocolConfig.protocol は次のプロトコルをサポートします: TCP、UDP、SCTP、ICMP、および ICMPv6。ICMP および ICMPv6 ルールは、ICMP および ICMPv6 のタイプまたはコードと照合できます。TCP、UDP、および SCTP ルールは、<start : end-1> 形式を使用して、単一の宛先ポートまたはポートの範囲に対して照合できます。

rules.action を設定してルールの適用を allow するか、deny してルールを禁止します。

注記

Ingress ファイアウォールルールは、無効な設定をブロックする検証 Webhook を使用して検証されます。検証 Webhook は、API サーバーなどの重大なクラスターサービスをブロックすることを防ぎます。

4.3.3.2. Ingress ノードファイアウォールルールオブジェクトの例

次の例では、完全な Ingress ノードファイアウォール設定が指定されています。

Ingress ノードファイアウォールの設定例

apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewall
metadata:
  name: ingressnodefirewall
spec:
  interfaces:
  - eth0
  nodeSelector:
    matchLabels:
      <ingress_firewall_label_name>: <label_value> 
1

  ingress:
  - sourceCIDRs:
       - 172.16.0.0/12
    rules:
    - order: 10
      protocolConfig:
        protocol: ICMP
        icmp:
          icmpType: 8 #ICMP Echo request
      action: Deny
    - order: 20
      protocolConfig:
        protocol: TCP
        tcp:
          ports: "8000-9000"
      action: Deny
  - sourceCIDRs:
       - fc00:f853:ccd:e793::0/64
    rules:
    - order: 10
      protocolConfig:
        protocol: ICMPv6
        icmpv6:
          icmpType: 128 #ICMPV6 Echo request
      action: Deny
Copy to Clipboard Toggle word wrap

1
<label_name> と <label_value> はノード上に存在する必要があり、ingressfirewallconfig CR を実行するノードに適用される nodeselector ラベルと値に一致する必要があります。<label_value> は、true または false です。nodeSelector ラベルを使用すると、ノードのグループを個別にターゲットにして、ingressfirewallconfig CR の使用に異なるルールを適用できます。
4.3.3.3. ゼロトラスト Ingress ノードファイアウォールルールオブジェクトの例

ゼロトラストの Ingress ノードファイアウォールルールは、マルチインターフェイスクラスターに追加のセキュリティーを提供できます。たとえば、ゼロトラストの Ingress ノードファイアウォールルールを使用して、SSH を除く特定のインターフェイス上のすべてのトラフィックをドロップできます。

次の例では、ゼロトラスト Ingress ノードファイアウォールルールセットの完全な設定が指定されています。

重要

次の場合、ユーザーはアプリケーションが使用するすべてのポートを許可リストに追加して、適切な機能を確保する必要があります。

ゼロトラストの Ingress ノードファイアウォールルールの例

apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewall
metadata:
 name: ingressnodefirewall-zero-trust
spec:
 interfaces:
 - eth1 
1

 nodeSelector:
   matchLabels:
     <ingress_firewall_label_name>: <label_value> 
2

 ingress:
 - sourceCIDRs:
      - 0.0.0.0/0 
3

   rules:
   - order: 10
     protocolConfig:
       protocol: TCP
       tcp:
         ports: 22
     action: Allow
   - order: 20
     action: Deny 
4
Copy to Clipboard Toggle word wrap

1
ネットワークインターフェイスクラスター
2
<label_name> と <label_value> は、ingressfirewallconfig CR を適用する特定のノードに適用される nodeSelector ラベルと値に一致する必要があります。
3
0.0.0.0/0 は、任意の CIDR に一致するように設定されています
4
Deny に設定された action
重要

eBPF Manager Operator の統合は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

4.4. Ingress ノードファイアウォール Operator の統合

Ingress Node Firewall は、eBPF プログラムを使用して、主要なファイアウォール機能の一部を実装します。デフォルトでは、これらの eBPF プログラムは、Ingress Node Firewall に固有のメカニズムを使用してカーネルにロードされます。代わりに、これらのプログラムのロードと管理に eBPF Manager Operator を使用するように Ingress Node Firewall Operator を設定できます。

この統合を有効にすると、次の制限が適用されます。

  • XDP が利用できず、TCX が bpfman と互換性がない場合、Ingress Node Firewall Operator は TCX を使用します。
  • Ingress Node Firewall Operator デーモンセットの Pod は、ファイアウォールルールが適用されるまで ContainerCreating 状態のままになります。
  • Ingress Node Firewall Operator デーモンセットの Pod は権限として実行します。

4.5. eBPF Manager Operator を使用するように Ingress ノードファイアウォール Operator の設定

Ingress Node Firewall は、eBPF プログラムを使用して、主要なファイアウォール機能の一部を実装します。デフォルトでは、これらの eBPF プログラムは、Ingress Node Firewall に固有のメカニズムを使用してカーネルにロードされます。

クラスター管理者は、Ingress Node Firewall Operator を設定して、代わりに eBPF Manager Operator を使用してこれらのプログラムをロードおよび管理し、セキュリティーと監視機能を追加できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • 管理者権限を持つアカウントがある。
  • Ingress Node Firewall Operator をインストールしました。
  • eBPF Manager Operator をインストールしている。

手順

  1. ingress-node-firewall-system namespace に次のラベルを適用します。

    $ oc label namespace openshift-ingress-node-firewall \
        pod-security.kubernetes.io/enforce=privileged \
        pod-security.kubernetes.io/warn=privileged --overwrite
    Copy to Clipboard Toggle word wrap
  2. ingressnodefirewallconfig という名前の IngressNodeFirewallConfig オブジェクトを編集し、ebpfProgramManagerMode フィールドを設定します。

    Ingress Node Firewall Operator 設定オブジェクト

    apiVersion: ingressnodefirewall.openshift.io/v1alpha1
    kind: IngressNodeFirewallConfig
    metadata:
      name: ingressnodefirewallconfig
      namespace: openshift-ingress-node-firewall
    spec:
      nodeSelector:
        node-role.kubernetes.io/worker: ""
      ebpfProgramManagerMode: <ebpf_mode>
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    <ebpf_mode>: Ingress Node Firewall Operator が eBPF Manager Operator を使用して eBPF プログラムを管理するかどうかを指定します。true または false のどちらかでなければなりません。設定されていないと、eBPF マネージャーは使用されません。

4.6. Ingress Node Firewall Operator ルールの表示

手順

  1. 次のコマンドを実行して、現在のルールをすべて表示します。

    $ oc get ingressnodefirewall
    Copy to Clipboard Toggle word wrap
  2. 返された <resource> 名のいずれかを選択し、次のコマンドを実行してルールまたは設定を表示します。

    $ oc get <resource> <name> -o yaml
    Copy to Clipboard Toggle word wrap

4.7. Ingress Node Firewall Operator のトラブルシューティング

  • 次のコマンドを実行して、インストールされている Ingress ノードファイアウォールのカスタムリソース定義 (CRD) を一覧表示します。

    $ oc get crds | grep ingressnodefirewall
    Copy to Clipboard Toggle word wrap

    出力例

    NAME               READY   UP-TO-DATE   AVAILABLE   AGE
    ingressnodefirewallconfigs.ingressnodefirewall.openshift.io       2022-08-25T10:03:01Z
    ingressnodefirewallnodestates.ingressnodefirewall.openshift.io    2022-08-25T10:03:00Z
    ingressnodefirewalls.ingressnodefirewall.openshift.io             2022-08-25T10:03:00Z
    Copy to Clipboard Toggle word wrap

  • 次のコマンドを実行して、Ingress Node Firewall Operator の状態を表示します。

    $ oc get pods -n openshift-ingress-node-firewall
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                       READY  STATUS         RESTARTS  AGE
    ingress-node-firewall-controller-manager   2/2    Running        0         5d21h
    ingress-node-firewall-daemon-pqx56         3/3    Running        0         5d21h
    Copy to Clipboard Toggle word wrap

    次のフィールドは、Operator のステータスに関する情報を提供します: READYSTATUSAGE、および RESTARTS。Ingress Node Firewall Operator が割り当てられたノードに設定されたデーモンをデプロイしている場合、STATUS フィールドは Running になります。

  • 次のコマンドを実行して、すべての Ingress ファイアウォールノード Pod のログを収集します。

    $ oc adm must-gather – gather_ingress_node_firewall
    Copy to Clipboard Toggle word wrap

    ログは、/sos_commands/ebpf にある eBPF bpftool 出力を含む sos ノードのレポートで利用できます。これらのレポートには、Ingress ファイアウォール XDP がパケット処理を処理し、統計を更新し、イベントを発行するときに使用または更新されたルックアップテーブルが含まれます。

Legal Notice

Copyright © 2025 Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat