ネットワーク

1. tls.crt および tls.key ファイルを使用して、カスタム証明書を含む Secret リソースを openshift-ingress namespace に作成します。

   $ oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key

2. IngressController CR を、新規証明書シークレットを参照するように更新します。

   $ oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \
     --patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'

3. 更新が正常に行われていることを確認します。

   $ echo Q |\
     openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null |\
     openssl x509 -noout -subject -issuer -enddate

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

   <domain>

   クラスターのベースドメイン名を指定します。

   出力例

   subject=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = *.apps.example.com
   issuer=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = example.com
   notAfter=May 10 08:32:45 2022 GM

   ヒント

   または、以下の YAML を適用してカスタムのデフォルト証明書を設定できます。

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: default
     namespace: openshift-ingress-operator
   spec:
     defaultCertificate:
       name: custom-certs-default

   証明書シークレットの名前は、CR を更新するために使用された値に一致する必要があります。

手順

1. 以下のコマンドを実行して、Thanos で認証するためのサービスアカウントを作成します。

   $ oc create -n openshift-ingress-operator serviceaccount thanos && oc describe -n openshift-ingress-operator serviceaccount thanos

   出力例

   Name:                thanos
   Namespace:           openshift-ingress-operator
   Labels:              <none>
   Annotations:         <none>
   Image pull secrets:  thanos-dockercfg-kfvf2
   Mountable secrets:   thanos-dockercfg-kfvf2
   Tokens:              thanos-token-c422q
   Events:              <none>

2. 次のコマンドを使用して、サービスアカウントシークレットトークンを手動で作成します。

   $ oc apply -f - <<EOF
   apiVersion: v1
   kind: Secret
   metadata:
     name: thanos-token
     namespace: openshift-ingress-operator
     annotations:
       kubernetes.io/service-account.name: thanos
   type: kubernetes.io/service-account-token
   EOF

3. サービスアカウントのトークンを使用して、openshift-ingress-operator namespace 内で TriggerAuthentication オブジェクトを定義します。

   1. 次のコマンドを実行して、シークレットを含む secret 変数を定義します。

      $ secret=$(oc get secret -n openshift-ingress-operator | grep thanos-token | head -n 1 | awk '{ print $1 }')

   2. TriggerAuthentication オブジェクトを作成し、secret 変数の値を TOKEN パラメーターに渡します。

      $ oc process TOKEN="$secret" -f - <<EOF | oc apply -n openshift-ingress-operator -f -
      apiVersion: template.openshift.io/v1
      kind: Template
      parameters:
      - name: TOKEN
      objects:
      - apiVersion: keda.sh/v1alpha1
        kind: TriggerAuthentication
        metadata:
          name: keda-trigger-auth-prometheus
        spec:
          secretTargetRef:
          - parameter: bearerToken
            name: \${TOKEN}
            key: token
          - parameter: ca
            name: \${TOKEN}
            key: ca.crt
      EOF

4. Thanos からメトリクスを読み取るためのロールを作成して適用します。

   1. Pod およびノードからメトリクスを読み取る新規ロール thanos-metrics-reader.yaml を作成します。

      thanos-metrics-reader.yaml

      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: thanos-metrics-reader
        namespace: openshift-ingress-operator
      rules:
      - apiGroups:
        - ""
        resources:
        - pods
        - nodes
        verbs:
        - get
      - apiGroups:
        - metrics.k8s.io
        resources:
        - pods
        - nodes
        verbs:
        - get
        - list
        - watch
      - apiGroups:
        - ""
        resources:
        - namespaces
        verbs:
        - get

   2. 以下のコマンドを実行して新規ロールを適用します。

      $ oc apply -f thanos-metrics-reader.yaml

5. 以下のコマンドを入力して、新しいロールをサービスアカウントに追加します。

   $ oc adm policy -n openshift-ingress-operator add-role-to-user thanos-metrics-reader -z thanos --role-namespace=openshift-ingress-operator

   $ oc adm policy -n openshift-ingress-operator add-cluster-role-to-user cluster-monitoring-view -z thanos

   注記

   引数 add-cluster-role-to-user は、namespace 間のクエリーを使用する場合にのみ必要になります。以下の手順では、この引数を必要とする kube-metrics namespace からのクエリーを使用します。

6. デフォルトの Ingress Controller デプロイメントをターゲットにする新しい ScaledObject YAML ファイル ingress-autoscaler.yaml を作成します。

   ScaledObject 定義の例

   apiVersion: keda.sh/v1alpha1
   kind: ScaledObject
   metadata:
     name: ingress-scaler
     namespace: openshift-ingress-operator
   spec:
     scaleTargetRef: 

   1

   
       apiVersion: operator.openshift.io/v1
       kind: IngressController
       name: default
       envSourceContainerName: ingress-operator
     minReplicaCount: 1
     maxReplicaCount: 20 

   2

   
     cooldownPeriod: 1
     pollingInterval: 1
     triggers:
     - type: prometheus
       metricType: AverageValue
       metadata:
         serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9091 

   3

   
         namespace: openshift-ingress-operator 

   4

   
         metricName: 'kube-node-role'
         threshold: '1'
         query: 'sum(kube_node_role{role="worker",service="kube-state-metrics"})' 

   5

   
         authModes: "bearer"
       authenticationRef:
         name: keda-trigger-auth-prometheus

   1

   対象とするカスタムリソース。この場合、Ingress Controller。

   2

   オプション: レプリカの最大数。このフィールドを省略すると、デフォルトの最大値は 100 レプリカに設定されます。

   3

   openshift-monitoring namespace の Thanos サービスエンドポイント。

   4

   Ingress Operator namespace。

   5

   この式は、デプロイされたクラスターに存在するワーカーノードの数に対して評価されます。

   重要

   namespace 間クエリーを使用している場合は、serverAddress フィールドのポート 9092 ではなくポート 9091 をターゲットにする必要があります。また、このポートからメトリクスを読み取るには、昇格した権限が必要です。

7. 以下のコマンドを実行してカスタムリソース定義を適用します。

   $ oc apply -f ingress-autoscaler.yaml

手順

1. デフォルト IngressController の現在の利用可能なレプリカ数を表示します。

   $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'

   出力例

   2

2. oc patch コマンドを使用して、デフォルトの IngressController を必要なレプリカ数にスケーリングします。以下の例では、デフォルトの IngressController を 3 つのレプリカにスケーリングしています。

   $ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=merge

   出力例

   ingresscontroller.operator.openshift.io/default patched

3. デフォルトの IngressController が指定したレプリカ数にスケーリングされていることを確認します。

   $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'

   出力例

   3

   ヒント

   または、以下の YAML を適用して Ingress Controller を 3 つのレプリカにスケーリングすることもできます。

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     name: default
     namespace: openshift-ingress-operator
   spec:
     replicas: 3               

   1

   1

   異なる数のレプリカが必要な場合は replicas 値を変更します。

手順

1. 以下の例のように、<name>-ingress-controller.yaml という名前のファイルに IngressController カスタムリソース (CR) を作成します。

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     namespace: openshift-ingress-operator
     name: <name> 

   1

   
   spec:
     domain: <domain> 

   2

   
     endpointPublishingStrategy:
       type: LoadBalancerService
       loadBalancer:
         scope: Internal 

   3

   1

   <name> を IngressController オブジェクトの名前に置き換えます。

   2

   コントローラーによって公開されるアプリケーションの ドメイン を指定します。

   3

   内部ロードバランサーを使用するために Internal の値を指定します。

2. 以下のコマンドを実行して、直前の手順で定義された Ingress Controller を作成します。

   $ oc create -f <name>-ingress-controller.yaml 

   1

   1

   <name> を IngressController オブジェクトの名前に置き換えます。

3. オプション: 以下のコマンドを実行して Ingress Controller が作成されていることを確認します。

   $ oc --all-namespaces=true get ingresscontrollers

手順

1. グローバルアクセスを許可するように Ingress Controller リソースを設定します。

   注記

   Ingress Controller を作成し、グローバルアクセスのオプションを指定することもできます。

   1. Ingress Controller リソースを設定します。

      $ oc -n openshift-ingress-operator edit ingresscontroller/default

   2. YAML ファイルを編集します。

      サンプル clientAccess 設定を Global に設定します。

        spec:
          endpointPublishingStrategy:
            loadBalancer:
              providerParameters:
                gcp:
                  clientAccess: Global 

      1

      
                type: GCP
              scope: Internal
            type: LoadBalancerService

      1

      gcp.clientAccess を Global に設定します。

   3. 変更を適用するためにファイルを保存します。

2. 以下のコマンドを実行して、サービスがグローバルアクセスを許可することを確認します。

   $ oc -n openshift-ingress edit svc/router-default -o yaml

   この出力では、グローバルアクセスがアノテーション networking.gke.io/internal-load-balancer-allow-global-access を使用して Google Cloud に対して有効にされていることを示しています。

手順

1. 削除や再作成を実行して、クラスターを内部に配置するように default Ingress Controller を設定します。

   $ oc replace --force --wait --filename - <<EOF
   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     namespace: openshift-ingress-operator
     name: default
   spec:
     endpointPublishingStrategy:
       type: LoadBalancerService
       loadBalancer:
         scope: Internal
   EOF

手順

1. ワイルドカードポリシーを設定します。

   1. 以下のコマンドを使用して IngressController リソースを編集します。

      $ oc edit IngressController

   2. spec の下で、wildcardPolicy フィールドを WildcardsDisallowed または WildcardsAllowed に設定します。

      spec:
        routeAdmission:
          wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed

手順

1. Ingress Controller 用に HTTPHeaders フィールドを設定します。

   1. 以下のコマンドを使用して IngressController リソースを編集します。

      $ oc edit IngressController

   2. spec の下で、HTTPHeaders ポリシーフィールドを Append、Replace、IfNone、または Never に設定します。

      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        httpHeaders:
          forwardedHeaderPolicy: Append

手順

1. Ingress Controller リソースを編集します。

   $ oc -n openshift-ingress-operator edit ingresscontroller/default

2. PROXY 設定を設定します。

   • Ingress Controller が hostNetwork エンドポイント公開ストラテジータイプを使用する場合は、spec.endpointPublishingStrategy.nodePort.protocol サブフィールドを PROXY に設定します。

     PROXY への hostNetwork の設定例

       spec:
         endpointPublishingStrategy:
           hostNetwork:
             protocol: PROXY
           type: HostNetwork

   • Ingress Controller が NodePortService エンドポイント公開ストラテジータイプを使用する場合は、spec.endpointPublishingStrategy.nodePort.protocol サブフィールドを PROXY に設定します。

     PROXY へのサンプル nodePort 設定

       spec:
         endpointPublishingStrategy:
           nodePort:
             protocol: PROXY
           type: NodePortService

手順

1. ユーザーが作成するルートに代替のデフォルトドメインを指定して appsDomain フィールドを設定します。

   1. Ingress cluster リソースを編集します。

      $ oc edit ingresses.config/cluster -o yaml

   2. YAML ファイルを編集します。

      test.example.com への appsDomain の設定例

      apiVersion: config.openshift.io/v1
      kind: Ingress
      metadata:
        name: cluster
      spec:
        domain: apps.example.com            

      1

      
        appsDomain: <test.example.com>      

      2

      1

      デフォルトドメインを指定します。インストール後にデフォルトドメインを変更することはできません。

      2

      オプション: アプリケーションルートに使用する OpenShift Container Platform インフラストラクチャーのドメイン。デフォルトの接頭辞である apps の代わりに、test のような別の接頭辞を使用できます。

2. ルートを公開し、ルートドメインの変更を確認して、既存のルートに、appsDomain フィールドで指定したドメイン名が含まれていることを確認します。

   注記

   ルートを公開する前に openshift-apiserver がローリング更新を終了するのを待機します。

   1. ルートを公開します。

      $ oc expose service hello-openshift
      route.route.openshift.io/hello-openshift exposed

      出力例:

      $ oc get routes
      NAME              HOST/PORT                                   PATH   SERVICES          PORT       TERMINATION   WILDCARD
      hello-openshift   hello_openshift-<my_project>.test.example.com
      hello-openshift   8080-tcp                 None

手順

1. Ingress Controller の httpCompression フィールドを設定します。

   1. 以下のコマンドを使用して IngressController リソースを編集します。

      $ oc edit -n openshift-ingress-operator ingresscontrollers/default

   2. spec で、httpCompression ポリシーフィールドを mimeTypes に設定し、圧縮を適用する必要がある MIME タイプのリストを指定します。

      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        httpCompression:
          mimeTypes:
          - "text/html"
          - "text/css; charset=utf-8"
          - "application/json"
         ...

手順

1. 次のコマンドを実行して、ルーター Pod 名を取得します。

   $ oc get pods -n openshift-ingress

   出力例

   NAME                              READY   STATUS    RESTARTS   AGE
   router-default-76bfffb66c-46qwp   1/1     Running   0          11h

2. ルーター Pod が /var/lib/haproxy/conf/metrics-auth/statsUsername および /var/lib/haproxy/conf/metrics-auth/statsPassword ファイルに保存しているルーターのユーザー名およびパスワードを取得します。

   1. 次のコマンドを実行して、ユーザー名を取得します。

      $ oc rsh <router_pod_name> cat metrics-auth/statsUsername

   2. 次のコマンドを実行して、パスワードを取得します。

      $ oc rsh <router_pod_name> cat metrics-auth/statsPassword

3. 次のコマンドを実行して、ルーター IP およびメトリクス証明書を取得します。

   $ oc describe pod <router_pod>

4. つぎのコマンドを実行して、Prometheus 形式で未加工の統計情報を取得します。

   $ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics

5. 次のコマンドを実行して、安全にメトリクスにアクセスします。

   $ curl -u user:password https://<router_IP>:<stats_port>/metrics -k

6. 次のコマンドを実行して、デフォルトの stats ポート (1936) にアクセスします。

   $ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics

   例7.1 出力例

   ...
   # HELP haproxy_backend_connections_total Total number of connections.
   # TYPE haproxy_backend_connections_total gauge
   haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route"} 0
   haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route-alt"} 0
   haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route01"} 0
   ...
   # HELP haproxy_exporter_server_threshold Number of servers tracked and the current threshold value.
   # TYPE haproxy_exporter_server_threshold gauge
   haproxy_exporter_server_threshold{type="current"} 11
   haproxy_exporter_server_threshold{type="limit"} 500
   ...
   # HELP haproxy_frontend_bytes_in_total Current total of incoming bytes.
   # TYPE haproxy_frontend_bytes_in_total gauge
   haproxy_frontend_bytes_in_total{frontend="fe_no_sni"} 0
   haproxy_frontend_bytes_in_total{frontend="fe_sni"} 0
   haproxy_frontend_bytes_in_total{frontend="public"} 119070
   ...
   # HELP haproxy_server_bytes_in_total Current total of incoming bytes.
   # TYPE haproxy_server_bytes_in_total gauge
   haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_no_sni",service=""} 0
   haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_sni",service=""} 0
   haproxy_server_bytes_in_total{namespace="default",pod="docker-registry-5-nk5fz",route="docker-registry",server="10.130.0.89:5000",service="docker-registry"} 0
   haproxy_server_bytes_in_total{namespace="default",pod="hello-rc-vkjqx",route="hello-route",server="10.130.0.90:8080",service="hello-svc-1"} 0
   ...

7. ブラウザーで以下の URL を入力して、stats ウィンドウを起動します。

   http://<user>:<password>@<router_IP>:<stats_port>

8. オプション: ブラウザーに次の URL を入力して、CSV 形式で統計情報を取得します。

   http://<user>:<password>@<router_ip>:1936/metrics;csv

手順

1. openshift-config に my-custom-error-code-pages という名前の config map を作成します。

   $ oc -n openshift-config create configmap my-custom-error-code-pages \
   --from-file=error-page-503.http \
   --from-file=error-page-404.http

   重要

   カスタムエラーコードの応答ページに適した形式を指定しない場合は、ルーター Pod が停止します。この停止を解決するには、config map を削除するか、修正し、影響を受けるルーター Pod を削除して、正しい情報で再作成できるようにします。

2. Ingress Controller にパッチを適用し、名前を指定して my-custom-error-code-pages config map を参照します。

   $ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"httpErrorCodePages":{"name":"my-custom-error-code-pages"}}}' --type=merge

   Ingress Operator は、openshift-config namespace から openshift-ingress namespace に my-custom-error-code-pages config map をコピーします。Operator は、openshift-ingress namespace のパターン <your_ingresscontroller_name>-errorpages に従って config map に名前を付けます。

3. コピーを表示します。

   $ oc get cm default-errorpages -n openshift-ingress

   出力例

   NAME                       DATA   AGE
   default-errorpages         2      25s  

   1

   1

   default の Ingress Controller カスタムリソース (CR) にパッチが適用されているため、config map 名の例は default-errorpages です。

4. カスタムエラー応答ページを含む config map がルーターボリュームにマウントされることを確認します。config map キーは、カスタム HTTP エラーコード応答を持つファイル名です。

   • 503 カスタム HTTP カスタムエラーコード応答の場合:

     $ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-503.http

   • 404 カスタム HTTP カスタムエラーコード応答の場合:

     $ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-404.http

1. テストプロジェクトおよびアプリケーションを作成します。

    $ oc new-project test-ingress

   $ oc new-app django-psql-example

2. 503 カスタム http エラーコード応答の場合:

   1. アプリケーションのすべての Pod を停止します。

   2. 以下の curl コマンドを実行するか、ブラウザーでルートのホスト名にアクセスします。

      $ curl -vk <route_hostname>

3. 404 カスタム http エラーコード応答の場合:

   1. 存在しないルートまたは正しくないルートにアクセスします。

   2. 以下の curl コマンドを実行するか、ブラウザーでルートのホスト名にアクセスします。

      $ curl -vk <route_hostname>

4. errorfile 属性が haproxy.config ファイルで適切にあるかどうかを確認します。

   $ oc -n openshift-ingress rsh <router> cat /var/lib/haproxy/conf/haproxy.config | grep errorfile

手順

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

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

3. Ingress Node Firewall Operator にサブスクライブします。

   1. 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

4. Operator がインストールされていることを確認するには、以下のコマンドを入力します。

   $ oc get ip -n openshift-ingress-node-firewall

   出力例

   NAME            CSV                                         APPROVAL    APPROVED
   install-5cvnz   ingress-node-firewall.4.12.0-202211122336   Automatic   true

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

   $ oc get csv -n openshift-ingress-node-firewall

   出力例

   NAME                                        DISPLAY                          VERSION               REPLACES                                    PHASE
   ingress-node-firewall.4.12.0-202211122336   Ingress Node Firewall Operator   4.12.0-202211122336   ingress-node-firewall.4.12.0-202211102047   Succeeded

手順

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

   1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
   2. 利用可能な Operator のリストから Ingress Node Firewall Operator を選択し、Install をクリックします。
   3. Install Operator ページの Installed Namespace で、Operator recommended Namespace を選択します。
   4. Install をクリックします。

2. Ingress Node Firewall Operator が正常にインストールされていることを確認します。

   1. Operators → Installed Operators ページに移動します。

   2. Ingress Node Firewall Operator が openshift-ingress-node-firewall プロジェクトにリストされ、Status が InstallSucceeded であることを確認します。

      注記

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

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

      • Operator Subscriptions および Install Plans タブで、Status の下の失敗またはエラーの有無を確認します。
      • Workloads → Pods ページに移動し、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

        注記

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