7.8. Ingress 컨트롤러 구성

1. tls.crt 및 tls.key 파일을 사용하여 openshift-ingress 네임스페이스에 사용자 정의 인증서를 포함하는 Secret 리소스를 만듭니다.

   $ 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 네임스페이스에 프로젝트를 생성합니다.

   $ oc project openshift-ingress-operator

2. 구성 맵을 생성하고 적용하여 사용자 정의 프로젝트에 대한 OpenShift 모니터링을 활성화합니다.

   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. 다음 명령을 실행하여 구성 맵을 적용합니다.

      $ 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 네임스페이스에 TriggerAuthentication 오브젝트를 정의합니다.

   1. 다음 명령 을 실행 하여 시크릿이 포함된 변수 보안을 정의합니다.

      $ 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 및 노드에서 지표를 읽는 os-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 가 필요합니다. 다음 단계에서는 이 인수가 필요한 kube-metrics 네임스페이스의 쿼리를 사용합니다.

7. 기본 Ingress 컨트롤러 배포를 대상으로 하는 새 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 컨트롤러입니다.

   2

   선택사항: 최대 복제본 수입니다. 이 필드를 생략하면 기본 최대값은 100개의 복제본으로 설정됩니다.

   3

   클러스터 주소 및 포트입니다.

   4

   Ingress Operator 네임스페이스입니다.

   5

   이 표현식은 배포된 클러스터에 있지만 많은 작업자 노드가 있습니다.

   중요

   네임스페이스 간 쿼리를 사용하는 경우 serverAddress 필드에서 포트 9091를 대상으로 하고 포트 9092가 아니어야 합니다. 이 포트에서 메트릭을 읽으려면 상승된 권한도 있어야 합니다.

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 컨트롤러를 세 개의 복제본으로 확장할 수 있습니다.

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

   1

   다른 양의 복제본이 필요한 경우 replicas 값을 변경합니다.

프로세스

1. 다음 예제와 같이 <name>-ingress-controller.yam 파일에 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

   컨트롤러가 게시한 애플리케이션의 domain을 지정합니다.

   3

   내부 로드 밸런서를 사용하려면 Internal 값을 지정합니다.

2. 다음 명령을 실행하여 이전 단계에서 정의된 Ingress 컨트롤러를 생성합니다.

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

   1

   <name>을 IngressController 오브젝트의 이름으로 변경합니다.

3. 선택 사항: Ingress 컨트롤러가 생성되었는지 확인하려면 다음 명령을 실행합니다.

   $ oc --all-namespaces=true get ingresscontrollers

프로세스

1. 글로벌 액세스를 허용하도록 Ingress 컨트롤러 리소스를 구성합니다.

   참고

   Ingress 컨트롤러를 생성하고 글로벌 액세스 옵션을 지정할 수도 있습니다.

   1. Ingress 컨트롤러 리소스를 구성합니다.

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

   2. YAML 파일을 편집합니다.

      Global에 대한 clientAccess 구성 샘플

        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. 클러스터의 기본 Ingress 컨트롤러를 삭제하고 다시 생성하여 내부용으로 구성합니다.

   $ 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 컨트롤러에 대한 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 컨트롤러 리소스를 편집합니다.

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

2. PROXY 구성을 설정합니다.

   • Ingress 컨트롤러에서 hostNetwork 엔드포인트 게시 전략 유형을 사용하는 경우 spec.endpointPublishingStrategy.hostNetwork.protocol 하위 필드를 PROXY로 설정합니다.

     PROXY에 대한 hostNetwork 구성 샘플

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

   • Ingress 컨트롤러에서 NodePortService 엔드포인트 게시 전략 유형을 사용하는 경우 spec.endpointPublishingStrategy.nodePort.protocol 하위 필드를 PROXY로 설정합니다.

     PROXY에 대한 nodePort 구성 샘플

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

프로세스

1. 사용자 생성 경로에 대한 대체 기본 도메인을 지정하여 appsDomain 필드를 구성합니다.

   1. 수신 클러스터 리소스를 편집합니다.

      $ 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 인프라를 애플리케이션 경로에 사용할 도메인입니다. 기본 접두사인 앱 대신 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 컨트롤러의 httpCompression 필드를 구성합니다.

   1. 다음 명령을 사용하여 IngressController 리소스를 편집합니다.

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

   2. spec 에서 httpCompression policy 필드를 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. openshift-config 네임스페이스에 my-custom-error-code-pages 라는 구성 맵을 생성합니다.

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

   중요

   사용자 정의 오류 코드 응답 페이지에 올바른 형식을 지정하지 않으면 라우터 Pod 중단이 발생합니다. 이 중단을 해결하려면 구성 맵을 삭제하거나 수정하고 영향을 받는 라우터 Pod를 삭제하여 올바른 정보로 다시 생성해야 합니다.

2. 이름별로 my-custom-error-code-pages 구성 맵을 참조하도록 Ingress 컨트롤러를 패치합니다.

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

   Ingress Operator는 my-custom-error-code-pages 구성 맵을 openshift-config 네임스페이스에서 openshift-ingress 네임스페이스로 복사합니다. Operator는 openshift-ingress 네임스페이스에서 <your_ingresscontroller_name>-errorpages 패턴에 따라 구성 맵의 이름을 지정합니다.

3. 복사본을 표시합니다.

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

   출력 예

   NAME                       DATA   AGE
   default-errorpages         2      25s  1

   1

   default Ingress 컨트롤러 CR(사용자 정의 리소스)이 패치되었기 때문에 구성 맵 이름은 default-errorpages입니다.

4. 사용자 정의 오류 응답 페이지가 포함된 구성 맵이 라우터 볼륨에 마운트되는지 확인합니다. 여기서 구성 맵 키는 사용자 정의 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