7.8. Ingress Controller の設定

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. OpenShift CLI (oc) がインストールされている。
2. cluster-admin ロールを持つユーザーとして OpenShift Container Platform クラスターにアクセスできる。
3. Custom Metrics Autoscaler Operator がインストールされている。

手順

1. 以下のコマンドを実行して、openshift-ingress-operator namespace にプロジェクトを作成します。

   $ oc project openshift-ingress-operator

2. ConfigMap を作成し、適用してユーザー定義プロジェクトのモニタリングを有効にします。

   1. 新規 ConfigMap オブジェクト cluster-monitoring-config.yaml を作成します。

      cluster-monitoring-config.yaml

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: cluster-monitoring-config
        namespace: openshift-monitoring
      data:
        config.yaml: |
          enableUserWorkload: true 1

      1

      true に設定すると、enableUserWorkload パラメーターはクラスター内のユーザー定義プロジェクトのモニタリングを有効にします。

   2. 以下のコマンドを実行して ConfigMap を適用します。

      $ oc apply -f cluster-monitoring-config.yaml

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

   $ oc create serviceaccount thanos && oc describe serviceaccount thanos

   出力例

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

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

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

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

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

      $ oc process TOKEN="$secret" -f - <<EOF | oc apply -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

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

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

      thanos-metrics-reader.yaml

      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: thanos-metrics-reader
      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

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

   $ oc adm policy 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 からのクエリーを使用します。

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

   ScaledObject 定義の例

   apiVersion: keda.sh/v1alpha1
   kind: ScaledObject
   metadata:
     name: ingress-scaler
   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://<example-cluster>: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

   クラスターアドレスおよびポート。

   4

   Ingress Operator namespace。

   5

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

   重要

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

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

   $ 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 で GCP について有効にされていることを示しています。

手順

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 への apps Domain の設定例

      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 という名前の ConfigMap を作成します。

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

   重要

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

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

   $ 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 ConfigMap をコピーします。Operator は、openshift-ingress namespace のパターン <your_ingresscontroller_name>-errorpages に従って ConfigMap に名前を付けます。

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

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

   出力例

   NAME                       DATA   AGE
   default-errorpages         2      25s  1

   1

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

4. カスタムエラー応答ページを含む ConfigMap がルーターボリュームにマウントされることを確認します。ConfigMap キーは、カスタム 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