9장. 통합


9.1. OpenShift Serverless와 Service Mesh 통합

OpenShift Serverless Operator는 Kourier를 Knative의 기본 수신으로 제공합니다. 그러나 Kourier가 활성화되어 있는지 여부에 관계없이 OpenShift Serverless에서 Service Mesh를 사용할 수 있습니다. Kourier disabled와 통합하면 mTLS 기능과 같이 Kourier 인그레스에서 지원하지 않는 추가 네트워킹 및 라우팅 옵션을 구성할 수 있습니다.

중요

OpenShift Serverless는 본 안내서에 명시되어 있는 Red Hat OpenShift Service Mesh 기능만 지원하며 문서화되지 않은 다른 기능은 지원하지 않습니다.

9.1.1. 사전 요구 사항

  • 다음 절차의 예제에서는 도메인 example.com을 사용합니다. 이 도메인에 사용되는 예제 인증서는 하위 도메인 인증서에 서명하는 CA(인증 기관)로 사용됩니다.

    배포에서 이 절차를 완료하고 확인하려면 널리 신뢰받는 공용 CA에서 서명한 인증서 또는 조직에서 제공하는 CA가 필요합니다. 도메인, 하위 도메인, CA에 따라 예제 명령을 조정해야 합니다.

  • OpenShift Container Platform 클러스터의 도메인과 일치하도록 와일드카드 인증서를 구성해야 합니다. 예를 들어 OpenShift Container Platform 콘솔 주소가 https://console-openshift-console.apps.openshift.example.com인 경우 도메인이 *.apps.openshift.example.com이 되도록 와일드카드 인증서를 구성해야 합니다. 와일드카드 인증서 구성에 대한 자세한 내용은 수신되는 외부 트래픽을 암호화하기 위한 인증서 생성에 관한 다음의 내용을 참조하십시오.
  • 기본 OpenShift Container Platform 클러스터 도메인의 하위 도메인이 아닌 도메인 이름을 사용하려면 해당 도메인에 대한 도메인 매핑을 설정해야 합니다. 자세한 내용은 사용자 정의 도메인 매핑 생성에 대한 OpenShift Serverless 설명서를 참조하십시오.

9.1.2. 수신 외부 트래픽을 암호화하기 위한 인증서 생성

기본적으로 Service Mesh mTLS 기능은 사이드카가 있는 수신 게이트웨이와 개별 Pod 간에 Service Mesh 자체의 트래픽만 보호합니다. OpenShift Container Platform 클러스터로 전달될 때 트래픽을 암호화하려면 OpenShift Serverless 및 Service Mesh 통합을 활성화하기 전에 인증서를 생성해야 합니다.

사전 요구 사항

  • 클러스터 관리자 액세스 권한이 있는 OpenShift Container Platform 계정에 액세스할 수 있습니다.
  • OpenShift Serverless Operator 및 Knative Serving이 설치되어 있습니다.
  • OpenShift CLI(oc)를 설치합니다.
  • 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.

절차

  1. Knative 서비스의 인증서에 서명할 root 인증서 및 개인 키를 생성합니다.

    $ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 \
        -subj '/O=Example Inc./CN=example.com' \
        -keyout root.key \
        -out root.crt
  2. 와일드카드 인증서를 만듭니다.

    $ openssl req -nodes -newkey rsa:2048 \
        -subj "/CN=*.apps.openshift.example.com/O=Example Inc." \
        -keyout wildcard.key \
        -out wildcard.csr
  3. 와일드카드 인증서를 서명합니다.

    $ openssl x509 -req -days 365 -set_serial 0 \
        -CA root.crt \
        -CAkey root.key \
        -in wildcard.csr \
        -out wildcard.crt
  4. 와일드카드 인증서를 사용하여 시크릿을 생성합니다.

    $ oc create -n istio-system secret tls wildcard-certs \
        --key=wildcard.key \
        --cert=wildcard.crt

    이 인증서는 OpenShift Serverless를 Service Mesh와 통합할 때 생성된 게이트웨이에서 선택하여 수신 게이트웨이가 이 인증서와 트래픽을 제공하도록 합니다.

9.1.3. OpenShift Serverless와 Service Mesh 통합

Kourier를 기본 수신으로 사용하지 않고 OpenShift Serverless와 Service Mesh를 통합할 수 있습니다. 이렇게 하려면 다음 절차를 완료하기 전에 Knative Serving 구성 요소를 설치하지 마십시오. 일반 Knative Serving 설치 절차에서는 Knative Serving을 Service Mesh와 통합하기 위해 KnativeServing CRD(사용자 정의 리소스 정의)를 생성할 때 추가 단계가 필요합니다. 이 절차는 Service Mesh를 기본값으로 통합하고 OpenShift Serverless 설치에만 수신하려는 경우에 유용할 수 있습니다.

사전 요구 사항

  • 클러스터 관리자 액세스 권한이 있는 OpenShift Container Platform 계정에 액세스할 수 있습니다.
  • 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
  • Red Hat OpenShift Service Mesh Operator를 설치하고 istio-system 네임스페이스에 ServiceMeshControlPlane 리소스를 생성합니다. mTLS 기능을 사용하려면 ServiceMeshControlPlane 리소스의 spec.security.dataPlane.mtls 필드도 true 로 설정해야 합니다.

    중요

    Service Mesh에서 OpenShift Serverless 사용은 Red Hat OpenShift Service Mesh 버전 2.0.5 이상에서만 지원됩니다.

  • OpenShift Serverless Operator를 설치합니다.
  • OpenShift CLI(oc)를 설치합니다.

절차

  1. Service Mesh와 통합할 네임스페이스를 ServiceMeshMemberRoll 오브젝트에 멤버로 추가합니다.

    apiVersion: maistra.io/v1
    kind: ServiceMeshMemberRoll
    metadata:
      name: default
      namespace: istio-system
    spec:
      members: 1
        - knative-serving
        - <namespace>
    1
    Service Mesh와 통합할 네임스페이스 목록입니다.
    중요

    이 네임스페이스 목록에 knative-serving 네임스페이스가 포함되어야 합니다.

  2. ServiceMeshMemberRoll 리소스를 적용합니다.

    $ oc apply -f <filename>
  3. Service Mesh가 트래픽을 수락할 수 있도록 필요한 게이트웨이를 생성합니다.

    HTTP를 사용하는 knative-local-gateway 오브젝트의 예

    apiVersion: networking.istio.io/v1alpha3
    kind: Gateway
    metadata:
      name: knative-ingress-gateway
      namespace: knative-serving
    spec:
      selector:
        istio: ingressgateway
      servers:
        - port:
            number: 443
            name: https
            protocol: HTTPS
          hosts:
            - "*"
          tls:
            mode: SIMPLE
            credentialName: <wildcard_certs> 1
    ---
    apiVersion: networking.istio.io/v1alpha3
    kind: Gateway
    metadata:
     name: knative-local-gateway
     namespace: knative-serving
    spec:
     selector:
       istio: ingressgateway
     servers:
       - port:
           number: 8081
           name: http
           protocol: HTTP 2
         hosts:
           - "*"
    ---
    apiVersion: v1
    kind: Service
    metadata:
     name: knative-local-gateway
     namespace: istio-system
     labels:
       experimental.istio.io/disable-gateway-port-translation: "true"
    spec:
     type: ClusterIP
     selector:
       istio: ingressgateway
     ports:
       - name: http2
         port: 80
         targetPort: 8081

    1
    와일드카드 인증서가 포함된 시크릿 이름을 추가합니다.
    2
    knative-local-gateway는 HTTP 트래픽을 제공합니다. HTTP를 사용하면 Service Mesh 외부에서 들어오는 트래픽이 표시되지만 example.default.svc.cluster.local과 같은 내부 호스트 이름을 사용하는 것은 암호화되지 않습니다. 다른 와일드카드 인증서 및 다른 protocol 사양을 사용하는 추가 게이트웨이를 생성하여 이 경로에 대한 암호화를 설정할 수 있습니다.

    HTTPS를 사용하는 knative-local-gateway 오브젝트의 예

    apiVersion: networking.istio.io/v1alpha3
    kind: Gateway
    metadata:
      name: knative-local-gateway
      namespace: knative-serving
    spec:
      selector:
        istio: ingressgateway
      servers:
        - port:
            number: 443
            name: https
            protocol: HTTPS
          hosts:
            - "*"
          tls:
            mode: SIMPLE
            credentialName: <wildcard_certs>

  4. Gateway 리소스를 적용합니다.

    $ oc apply -f <filename>
  5. 다음 KnativeServing CRD(사용자 정의 리소스 정의)를 생성하여 Knative Serving을 설치하여 Istio 통합을 활성화합니다.

    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeServing
    metadata:
      name: knative-serving
      namespace: knative-serving
    spec:
      ingress:
        istio:
          enabled: true 1
      deployments: 2
      - name: activator
        annotations:
          "sidecar.istio.io/inject": "true"
          "sidecar.istio.io/rewriteAppHTTPProbers": "true"
      - name: autoscaler
        annotations:
          "sidecar.istio.io/inject": "true"
          "sidecar.istio.io/rewriteAppHTTPProbers": "true"
    1
    Istio 통합을 활성화합니다.
    2
    Knative Serving 데이터 플레인 Pod에 사이드카 삽입을 활성화합니다.
  6. KnativeServing 리소스를 적용합니다.

    $ oc apply -f <filename>
  7. 사이드카 삽입이 활성화되고 패스쓰루(pass-through) 경로를 사용하는 Knative 서비스를 생성합니다.

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: <service_name>
      namespace: <namespace> 1
      annotations:
        serving.knative.openshift.io/enablePassthrough: "true" 2
    spec:
      template:
        metadata:
          annotations:
            sidecar.istio.io/inject: "true" 3
            sidecar.istio.io/rewriteAppHTTPProbers: "true"
        spec:
          containers:
          - image: <image_url>
    1
    Service Mesh 멤버 롤에 포함된 네임스페이스입니다.
    2
    생성한 인증서가 수신 게이트웨이를 통해 직접 제공되도록 Knative Serving에 OpenShift Container Platform 패스스루 지원 경로를 생성하도록 지시합니다.
    3
    Service Mesh 사이드카를 Knative 서비스 Pod에 삽입합니다.
  8. Service 리소스를 적용합니다.

    $ oc apply -f <filename>

검증

  • CA에서 신뢰하는 보안 연결을 사용하여 서버리스 애플리케이션에 액세스합니다.

    $ curl --cacert root.crt <service_url>

    명령 예

    $ curl --cacert root.crt https://hello-default.apps.openshift.example.com

    출력 예

    Hello Openshift!

9.1.4. mTLS와 함께 서비스 메시를 사용할 때 Knative Serving 메트릭 활성화

Service Mesh가 mTLS를 사용하여 활성화된 경우 Service Mesh가 Prometheus가 메트릭을 스크랩하지 못하도록 하므로 기본적으로 Knative Serving에 대한 메트릭이 비활성화됩니다. 이 섹션에서는 서비스 메시 및 mTLS를 사용할 때 Knative Serving 지표를 활성화하는 방법을 보여줍니다.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Serving이 클러스터에 설치되어 있습니다.
  • mTLS 기능이 활성화된 Red Hat OpenShift Service Mesh를 설치했습니다.
  • 클러스터 관리자 액세스 권한이 있는 OpenShift Container Platform 계정에 액세스할 수 있습니다.
  • OpenShift CLI(oc)를 설치합니다.
  • 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.

절차

  1. Knative Serving 사용자 정의 리소스(CR)의 observability 사양에서 prometheusmetrics.backend-destination으로 지정합니다.

    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeServing
    metadata:
      name: knative-serving
    spec:
      config:
        observability:
          metrics.backend-destination: "prometheus"
    ...

    이 단계에서는 메트릭이 기본적으로 비활성화되지 않습니다.

  2. Prometheus 네임스페이스의 트래픽을 허용하려면 다음 네트워크 정책을 적용합니다.

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-from-openshift-monitoring-ns
      namespace: knative-serving
    spec:
      ingress:
      - from:
        - namespaceSelector:
            matchLabels:
              name: "openshift-monitoring"
      podSelector: {}
    ...
  3. 다음 사양을 포함하도록 istio-system 네임스페이스에서 기본 서비스 메시 컨트롤 플레인을 수정하고 다시 적용합니다.

    ...
    spec:
      proxy:
        networking:
          trafficControl:
            inbound:
              excludedPorts:
              - 8444
    ...

9.1.5. Kourier가 활성화된 경우 OpenShift Serverless와 Service Mesh 통합

Kourier가 이미 활성화된 경우에도 OpenShift Serverless에서 Service Mesh를 사용할 수 있습니다. 이 절차는 Kourier를 사용하여 Knative Serving을 이미 설치했지만 나중에 서비스 메시 통합을 추가하려는 경우 유용할 수 있습니다.

사전 요구 사항

  • 클러스터 관리자 액세스 권한이 있는 OpenShift Container Platform 계정에 액세스할 수 있습니다.
  • 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터에 OpenShift Serverless Operator 및 Knative Serving을 설치합니다.
  • Red Hat OpenShift Service Mesh를 설치합니다. OpenShift Serverless with Service Mesh and Kourier는 Red Hat OpenShift Service Mesh 버전 1.x 및 2.x에서 모두 사용이 지원되고 있습니다.

절차

  1. Service Mesh와 통합할 네임스페이스를 ServiceMeshMemberRoll 오브젝트에 멤버로 추가합니다.

    apiVersion: maistra.io/v1
    kind: ServiceMeshMemberRoll
    metadata:
      name: default
      namespace: istio-system
    spec:
      members:
        - <namespace> 1
    ...
    1
    Service Mesh와 통합할 네임스페이스 목록입니다.
  2. ServiceMeshMemberRoll 리소스를 적용합니다.

    $ oc apply -f <filename>
  3. Knative 시스템 Pod에서 Knative 서비스로의 트래픽 흐름을 허용하는 네트워크 정책을 생성합니다.

    1. Service Mesh와 통합할 각 네임스페이스에 NetworkPolicy 리소스를 생성합니다.

      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-serving-system-namespace
        namespace: <namespace> 1
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                knative.openshift.io/part-of: "openshift-serverless"
        podSelector: {}
        policyTypes:
        - Ingress
      ...
      1
      Service Mesh와 통합할 네임스페이스를 추가합니다.
      참고

      knative.openshift.io/part-of: "openshift-serverless" 레이블이 OpenShift Serverless 1.22.0에 추가되었습니다. OpenShift Serverless 1.21.1 이하를 사용하는 경우 knative.openshift.io/part-of 레이블을 knative-servingknative-serving-ingress 네임스페이스에 추가합니다.

      knative-serving 네임스페이스에 라벨을 추가합니다.

      $ oc label namespace knative-serving knative.openshift.io/part-of=openshift-serverless

      knative-serving-ingress 네임스페이스에 레이블을 추가합니다.

      $ oc label namespace knative-serving-ingress knative.openshift.io/part-of=openshift-serverless
    2. NetworkPolicy 리소스를 적용합니다.

      $ oc apply -f <filename>

9.1.6. Service Mesh에 대한 시크릿 필터링을 사용하여 메모리 사용량 개선

기본적으로 Kubernetes 클라이언트-go 라이브러리에 대한 정보자 구현에서는 특정 유형의 모든 리소스를 가져옵니다. 이로 인해 많은 리소스를 사용할 수 있을 때 상당한 오버헤드가 발생하여 메모리 누수로 인해 Knative net-istio Ingress 컨트롤러가 대규모 클러스터에서 실패할 수 있습니다. 그러나 컨트롤러가 Knative 관련 보안만 가져올 수 있도록 Knative net-istio 수신 컨트롤러에서 필터링 메커니즘을 사용할 수 있습니다. KnativeServing 사용자 정의 리소스(CR)에 주석을 추가하여 이 메커니즘을 활성화할 수 있습니다.

사전 요구 사항

  • 클러스터 관리자 액세스 권한이 있는 OpenShift Container Platform 계정에 액세스할 수 있습니다.
  • 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
  • Red Hat OpenShift Service Mesh를 설치합니다. OpenShift Serverless with Service Mesh는 Red Hat OpenShift Service Mesh 버전 2.0.5 이상에서만 지원됩니다.
  • OpenShift Serverless Operator 및 Knative Serving을 설치합니다.
  • OpenShift CLI(oc)를 설치합니다.

절차

  • KnativeServing CR에 serverless.openshift.io/enable-secret-informer-filtering 주석을 추가합니다.

    KnativeServing CR의 예

    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeServing
    metadata:
      name: knative-serving
      namespace: knative-serving
      annotations:
        serverless.openshift.io/enable-secret-informer-filtering: "true" 1
    spec:
      ingress:
        istio:
          enabled: true
      deployments:
        - annotations:
            sidecar.istio.io/inject: "true"
            sidecar.istio.io/rewriteAppHTTPProbers: "true"
          name: activator
        - annotations:
            sidecar.istio.io/inject: "true"
            sidecar.istio.io/rewriteAppHTTPProbers: "true"
          name: autoscaler

    1
    이 주석을 추가하면 환경 변수 ENABLE_SECRET_INFORMER_FILTERING_BY_CERT_UID=true.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.