서빙

사전 요구 사항

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

프로세스

• Knative 서비스를 생성합니다.

  $ kn service create <service-name> --image <image> --tag <tag-value>

  Copy to Clipboard Toggle word wrap

  다음과 같습니다.

  • --image 는 애플리케이션의 이미지 URI입니다.

  • --tag 는 서비스와 함께 생성된 초기 버전에 태그를 추가하는 데 사용할 수 있는 선택적 플래그입니다.

    명령 예

    $ kn service create showcase \
        --image quay.io/openshift-knative/showcase

    Copy to Clipboard Toggle word wrap

    출력 예

    Creating service 'showcase' in namespace 'default':
    
      0.271s The Route is still working to reflect the latest desired specification.
      0.580s Configuration "showcase" is waiting for a Revision to become ready.
      3.857s ...
      3.861s Ingress has not yet been reconciled.
      4.270s Ready to serve.
    
    Service 'showcase' created with latest revision 'showcase-00001' and URL:
    http://showcase-default.apps-crc.testing

    Copy to Clipboard Toggle word wrap

사전 요구 사항

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

사전 요구 사항

• OpenShift Serverless Operator 및 Knative Serving이 클러스터에 설치되어 있습니다.
• Knative(kn) CLI가 설치되어 있습니다.

사전 요구 사항

• OpenShift Serverless Operator 및 Knative Serving이 클러스터에 설치되어 있습니다.
• oc CLI를 설치했습니다.
• Knative 서비스를 생성했습니다.

사전 요구 사항

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

• 170 Knative 서비스
• Knative 서비스당 1-2 버전
• 89 테스트 시나리오는 주로 컨트롤 플레인 테스트에 중점을 두고 있습니다.
• 48 Knative 서비스가 삭제되고 다시 생성되는 시나리오
• 41 안정적인 시나리오: 요청이 느리지만 지속적으로 시스템으로 전송됨

프로세스

• KnativeServing 사용자 정의 리소스(CR)를 사용하여 최소 워크로드에 대해 Knative Serving 을 구성할 수 있습니다.

  KnativeServing CR의 최소 워크로드 구성

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
    namespace: knative-serving
  spec:
    high-availability:
      replicas: 1 

  1

  
    workloads:
      - name: activator
        replicas: 2 

  2

  
        resources:
          - container: activator
            requests:
              cpu: 250m 

  3

  
              memory: 60Mi 

  4

  
            limits:
              cpu: 1000m
              memory: 600Mi
      - name: controller
        replicas: 1 

  5

  
        resources:
          - container: controller
            requests:
              cpu: 10m
              memory: 100Mi
            limits: 

  6

  
              cpu: 200m
              memory: 300Mi
      - name: webhook
        replicas: 2
        resources:
          - container: webhook
            requests:
              cpu: 100m 

  7

  
              memory: 60Mi
            limits:
              cpu: 200m
              memory: 200Mi
    podDisruptionBudgets: 

  8

  
      - name: activator-pdb
        minAvailable: 1
      - name: webhook-pdb
        minAvailable: 1

  Copy to Clipboard Toggle word wrap

  1

  이 값을 1 로 설정하면 모든 시스템 구성 요소가 하나의 복제본으로 확장됩니다.

  2

  다운타임을 방지하려면 활성기를 항상 최소 2 개의 인스턴스로 스케일링해야 합니다.

  3

  HorizontalPodAutoscaler 는 이를 확장 및 축소하기 위한 참조로 사용하므로 활성화기 CPU 요청을 250m 미만으로 설정해야 합니다.

  4

  이전 표의 유휴 값으로 메모리 요청을 조정합니다. 또한 예상 로드에 따라 메모리 제한을 조정합니다(최고의 값을 찾으려면 사용자 지정 테스트가 필요할 수 있음).

  5

  하나의 Webhook와 하나의 컨트롤러가 최소 워크로드 시나리오에 충분합니다.

  6

  이러한 제한은 최소 워크로드 시나리오에는 충분하지만 구체적인 워크로드에 따라 조정이 필요할 수 있습니다.

  7

  HorizontalPodAutoscaler는 이를 확장 및 축소하기 위한 참조로 사용하므로 Webhook CPU 요청을 100m 미만으로 설정하지 않아야 합니다.

  8

  노드 유지보수 중 문제를 방지하기 위해 PodDistruptionBudgets 를 복제본 보다 낮은 값으로 조정합니다.

• 모든 데이터 플레인 구성 요소는 높은 요청 및 페이로드 시나리오에서 CPU 사용량이 크게 증가하므로 CPU 요청 및 제한을 테스트해야 하며 잠재적으로 증가할 수 있습니다.
• 또한 활성화 구성 요소에 더 많은 요청 페이로드를 버퍼링해야 하는 경우 더 많은 메모리가 필요할 수 있으므로 메모리 요청 및 제한도 늘려야 할 수 있습니다.
• 하나의 activator Pod는 대기 시간을 늘리기 전에 초당 약 2500 건의 요청을 처리할 수 있으며 어느 시점에서 오류가 발생합니다.
• 1개의 3scale-kourier-gateway 또는 istio-ingressgateway Pod는 대기 시간을 늘리기 전에 초당 약 2500개의 요청을 처리할 수 있으며 어느 시점에서 오류가 발생할 수도 있습니다.
• 각 데이터 플레인 구성 요소는 초당 2500개의 요청을 처리하기 위해 최대 1개의 CPU vCPU를 사용합니다. 이는 Knative 서비스 백엔드의 페이로드 크기 및 응답 시간에 따라 달라집니다.

프로세스

• 설치를 미세 조정하려면 자체 테스트 결과와 결합된 이전 결과를 사용하여 KnativeServing 사용자 정의 리소스를 구성합니다.

  KnativeServing CR의 높은 워크로드 구성

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
    namespace: knative-serving
  spec:
    high-availability:
      replicas: 2 

  1

  
    workloads:
      - name: component-name 

  2

  
        replicas: 2 

  3

  
        resources:
          - container: container-name
            requests:
              cpu: 

  4

  
              memory:
            limits:
              cpu:
              memory:
    podDisruptionBudgets: 

  5

  
      - name: name-of-pod-disruption-budget
        minAvailable: 1

  Copy to Clipboard Toggle word wrap

  1

  이 매개변수를 최소 2 개로 설정하여 모든 구성 요소의 인스턴스가 항상 두 개 이상 실행되고 있는지 확인합니다. 워크로드를 사용하여 특정 구성 요소의 복제본을 덮어쓸 수도 있습니다.

  2

  워크로드 목록을 사용하여 특정 구성 요소를 구성합니다. 구성 요소의 배포 이름을 사용하고 replicas 필드를 설정합니다.

  3

  HPA(수평 Pod 자동 스케일러)를 사용하는 activator,webhook, 3scale-kourier-gateway 구성 요소의 경우 replicas 필드는 최소 복제본 수를 설정합니다. 실제 복제본 수는 HPA에서 수행하는 CPU 로드 및 스케일링에 따라 다릅니다.

  4

  이전 결과 및 자체 테스트 결과를 고려하여 최소한 유휴 사용량에 따라 요청된 CPU 및 메모리를 설정합니다.

  5

  노드 유지보수 중 문제를 방지하려면 PodDistruptionBudgets 를 복제본 보다 낮은 값으로 조정합니다. 기본 minAvailable 은 1 로 설정되어 있으므로 필요한 복제본을 늘리는 경우 minAvailable 도 늘려야 합니다.

• min-scale 주석이 설정되지 않음
• 0으로 스케일링이 활성화됨
• KPA 클래스 사용

프로세스

• 선택 사항: Service 사용자 정의 리소스의 사양에서 Knative 서비스에 대한 autoscaling.knative.dev/target 주석을 설정합니다.

  서비스 사양의 예

  apiVersion: serving.knative.dev/v1
  kind: Service
  metadata:
    name: showcase
    namespace: default
  spec:
    template:
      metadata:
        annotations:
          autoscaling.knative.dev/target: "200"

  Copy to Clipboard Toggle word wrap

• 선택 사항: kn service 명령을 사용하여 --concurrency-target 플래그를 지정합니다.

  $ kn service create <service_name> --image <image_uri> --concurrency-target <integer>

  Copy to Clipboard Toggle word wrap

  동시성 대상이 50개의 요청으로 서비스를 생성하는 명령 예

  $ kn service create showcase --image quay.io/openshift-knative/showcase --concurrency-target 50

  Copy to Clipboard Toggle word wrap

프로세스

• 선택 사항: Service 사용자 정의 리소스의 사양에 Knative 서비스의 containerConcurrency 사양을 설정합니다.

  서비스 사양의 예

  apiVersion: serving.knative.dev/v1
  kind: Service
  metadata:
    name: showcase
    namespace: default
  spec:
    template:
      spec:
        containerConcurrency: 50

  Copy to Clipboard Toggle word wrap

  기본값은 0 이며, 이는 한 번에 하나의 서비스 복제본으로 전달될 수 있는 동시 요청 수에 제한이 없음을 의미합니다.

  0 보다 큰 값은 한 번에 하나의 서비스 복제본으로 전달될 수 있는 정확한 요청 수를 지정합니다. 이 예제에서는 하드 동시성 제한을 50개의 요청을 활성화합니다.

• 선택 사항: kn service 명령을 사용하여 --concurrency-limit 플래그를 지정합니다.

  $ kn service create <service_name> --image <image_uri> --concurrency-limit <integer>

  Copy to Clipboard Toggle word wrap

  동시성 제한이 50개의 요청으로 서비스를 생성하는 명령 예

  $ kn service create showcase --image quay.io/openshift-knative/showcase --concurrency-limit 50

  Copy to Clipboard Toggle word wrap

사전 요구 사항

• 클러스터에 OpenShift Serverless Operator 및 Knative Serving이 설치되어 있습니다.
• OpenShift Container Platform에 대한 클러스터 관리자 권한이 있거나 AWS 또는 OpenShift Dedicated의 Red Hat OpenShift Service에 대한 클러스터 또는 전용 관리자 권한이 있습니다.
• 기본 Knative Pod Autoscaler를 사용하고 있습니다. Kubernetes Horizontal Pod Autoscaler를 사용하는 경우 0으로 스케일링 기능을 사용할 수 없습니다.

프로세스

• KnativeServing 사용자 정의 리소스(CR)에서 enable-scale-to-zero 사양을 수정합니다.

  KnativeServing CR의 예

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
  spec:
    config:
      autoscaler:
        enable-scale-to-zero: "false" 

  1

  Copy to Clipboard Toggle word wrap

  1

  enable-scale-to-zero 사양은 "true" 또는 "false" 일 수 있습니다. true로 설정하면 scale-to-zero가 활성화됩니다. false로 설정하면 애플리케이션이 구성된 최소 스케일 바운드 로 축소됩니다. 기본값은 "true" 입니다.

사전 요구 사항

• 클러스터에 OpenShift Serverless Operator 및 Knative Serving이 설치되어 있습니다.
• OpenShift Container Platform에 대한 클러스터 관리자 권한이 있거나 AWS 또는 OpenShift Dedicated의 Red Hat OpenShift Service에 대한 클러스터 또는 전용 관리자 권한이 있습니다.
• 기본 Knative Pod Autoscaler를 사용하고 있습니다. Kubernetes Horizontal Pod Autoscaler를 사용하는 경우 scale-to-zero 기능을 사용할 수 없습니다.

프로세스

• KnativeServing CR(사용자 정의 리소스)에서 scale-to-zero-grace-period 사양을 수정합니다.

  KnativeServing CR의 예

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
  spec:
    config:
      autoscaler:
        scale-to-zero-grace-period: "30s" 

  1

  Copy to Clipboard Toggle word wrap

  1

  유예 기간(초)입니다. 기본값은 30초입니다.

사전 요구 사항

• 클러스터에 OpenShift Serverless Operator 및 Knative Serving이 설치되어 있습니다.
• OpenShift Container Platform에 대한 클러스터 관리자 권한이 있거나 AWS 또는 OpenShift Dedicated의 Red Hat OpenShift Service에 대한 클러스터 또는 전용 관리자 권한이 있습니다.

프로세스

• kubernetes.podspec-init-containers 플래그를 KnativeServing CR에 추가하여 init 컨테이너 사용을 활성화합니다.

  KnativeServing CR의 예

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
  spec:
    config:
      features:
        kubernetes.podspec-init-containers: enabled
  ...

  Copy to Clipboard Toggle word wrap

• 서비스 이미지는 크기 때문에 가져오는 데 시간이 오래 걸립니다.
• 초기 캐시 priming으로 인해 서비스가 준비 되기까지 시간이 오래 걸립니다.
• 클러스터는 자동 스케일링을 사용하여 새 Pod에 리소스를 할당합니다.

프로세스

• 배포 구성을 수정하여 서비스에 대한 시작 프로브를 정의합니다. 다음 예제에서는 두 개의 컨테이너가 있는 구성을 보여줍니다.

  정의된 별 프로브의 예

  apiVersion: serving.knative.dev/v1
  kind: Service
  # ...
  spec:
    template:
      spec:
         containers:
          - name: first-container
            image: <image>
            ports:
              - containerPort: 8080
            # ...
            startupProbe: 

  1

  
            httpGet:
              port: 8080
              path: "/"
          - name: second-container
            image: <image>
            # ...
            startupProbe: 

  2

  
            httpGet:
              port: 8081
              path: "/"

  Copy to Clipboard Toggle word wrap

  1

  첫 번째 컨테이너 의 시작 프로브입니다.

  2

  두 번째 컨테이너 의 시작 프로브입니다.

• initialDelaySeconds
• failureThreshold
• periodSeconds
• timeoutSeconds

프로세스

• 진행률 데드라인 설정을 구성하려면 배포 구성에서 주석을 사용합니다.

  60초로 설정된 진행 상황 기한 예

  apiVersion: serving.knative.dev/v1
  kind: Service
  ...
  spec:
    template:
      metadata:
         annotations:
              serving.knative.dev/progress-deadline: "60s"
      spec:
          containers:
              - image: ghcr.io/knative/helloworld-go:latest

  Copy to Clipboard Toggle word wrap

프로세스

• KnativeServing CR에서 태그 resoution을 건너뛸 레지스트리 목록으로 registriesSkippingTag Rery 설정을 수정합니다.

  구성된 태그 확인 건너뛰기 예

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
  spec:
    config:
      deployment:
        registriesSkippingTagResolving: "registry.example.com, another.registry.com"

  Copy to Clipboard Toggle word wrap

프로세스

• KnativeServing CR에서 runtime-class-name 설정을 구성합니다.

  구성된 runtime-class-name 설정의 예

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
  spec:
    config:
      deployment:
        runtime-class-name: |
          kata: {}
          gvisor:
            selector:
              my-label: selector

  Copy to Clipboard Toggle word wrap

• 서비스 이미지는 크기 때문에 가져오는 데 시간이 오래 걸립니다.
• 초기 캐시 priming으로 인해 서비스가 준비 되기까지 시간이 오래 걸립니다.
• 클러스터는 자동 스케일링을 사용하여 새 Pod에 리소스를 할당합니다.

프로세스

• 현재 Envoy 부트스트랩 구성을 가져오려면 다음 명령을 실행합니다.

  명령 예

  $ oc get cm kourier-bootstrap -n knative-serving-ingress -o yaml

  Copy to Clipboard Toggle word wrap

  예를 들어 기본 구성을 사용하면 example 명령은 다음 발췌가 포함된 출력을 생성합니다.

  출력 예

  Name:         kourier-bootstrap
  Namespace:    knative-serving-ingress
  Labels:       app.kubernetes.io/component=net-kourier
                app.kubernetes.io/name=knative-serving
                app.kubernetes.io/version=release-v1.10
                networking.knative.dev/ingress-provider=kourier
                serving.knative.openshift.io/ownerName=knative-serving
                serving.knative.openshift.io/ownerNamespace=knative-serving
  Annotations:  manifestival: new

  Copy to Clipboard Toggle word wrap

  데이터 출력 예

  dynamic_resources:
    ads_config:
      transport_api_version: V3
      api_type: GRPC
      rate_limit_settings: {}
      grpc_services:
      - envoy_grpc: {cluster_name: xds_cluster}
    cds_config:
      resource_api_version: V3
      ads: {}
    lds_config:
      resource_api_version: V3
      ads: {}
  node:
    cluster: kourier-knative
    id: 3scale-kourier-gateway
  static_resources:
    listeners:
      - name: stats_listener
        address:
          socket_address:
            address: 0.0.0.0
            port_value: 9000
        filter_chains:
          - filters:
              - name: envoy.filters.network.http_connection_manager
                typed_config:
                  "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                  stat_prefix: stats_server
                  http_filters:
                    - name: envoy.filters.http.router
                      typed_config:
                        "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
                  route_config:
                    virtual_hosts:
                      - name: admin_interface
                        domains:
                          - "*"
                        routes:
                          - match:
                              safe_regex:
                                regex: '/(certs|stats(/prometheus)?|server_info|clusters|listeners|ready)?'
                              headers:
                                - name: ':method'
                                  string_match:
                                    exact: GET
                            route:
                              cluster: service_stats
    clusters:
      - name: service_stats
        connect_timeout: 0.250s
        type: static
        load_assignment:
          cluster_name: service_stats
          endpoints:
            lb_endpoints:
              endpoint:
                address:
                  pipe:
                    path: /tmp/envoy.admin
      - name: xds_cluster
        # This keepalive is recommended by envoy docs.
        # https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol
        typed_extension_protocol_options:
          envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
            "@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
            explicit_http_config:
              http2_protocol_options:
                connection_keepalive:
                  interval: 30s
                  timeout: 5s
        connect_timeout: 1s
        load_assignment:
          cluster_name: xds_cluster
          endpoints:
            lb_endpoints:
              endpoint:
                address:
                  socket_address:
                    address: "net-kourier-controller.knative-serving-ingress.svc.cluster.local."
                    port_value: 18000
        type: STRICT_DNS
  admin:
    access_log:
    - name: envoy.access_loggers.stdout
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.access_loggers.stream.v3.StdoutAccessLog
    address:
      pipe:
        path: /tmp/envoy.admin
  layered_runtime:
    layers:
      - name: static-layer
        static_layer:
          envoy.reloadable_features.override_request_timeout_by_gateway_timeout: false

  Copy to Clipboard Toggle word wrap

  BinaryData 출력 예

  Events:  <none>

  Copy to Clipboard Toggle word wrap

사전 요구 사항

• OpenShift Serverless Operator 및 Knative Serving이 설치되어 있습니다.
• OpenShift Container Platform에 대한 클러스터 관리자 권한이 있거나 AWS 또는 OpenShift Dedicated의 Red Hat OpenShift Service에 대한 클러스터 또는 전용 관리자 권한이 있습니다.

프로세스

• KnativeServing CR(사용자 정의 리소스)에서 spec.ingress.kourier.bootstrap-configmap 필드를 변경하여 사용자 정의 부트스트랩 구성 맵을 지정합니다.

  KnativeServing CR의 예

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
    namespace: knative-serving
  spec:
    config:
      network:
        ingress-class: kourier.ingress.networking.knative.dev
    ingress:
      kourier:
        bootstrap-configmap: my-configmap
        enabled: true
  # ...

  Copy to Clipboard Toggle word wrap

사전 요구 사항

• OpenShift Serverless Operator 및 Knative Serving이 설치되어 있습니다.
• OpenShift Container Platform에 대한 클러스터 관리자 권한이 있거나 AWS 또는 OpenShift Dedicated의 Red Hat OpenShift Service에 대한 클러스터 또는 전용 관리자 권한이 있습니다.

사전 요구 사항

• OpenShift CLI(oc)를 설치합니다.
• OpenShift Serverless Operator 및 Knative Serving이 클러스터에 설치되어 있습니다.

사전 요구 사항

• OpenShift Serverless Operator 및 Knative Serving이 설치되어 있습니다.
• OpenShift Container Platform에 대한 클러스터 관리자 권한 또는 AWS 또는 OpenShift Dedicated의 Red Hat OpenShift Service에 대한 클러스터 관리자 권한이 있습니다.

프로세스

• 버전 시간 초과를 구성하는 적절한 방법을 선택합니다.

  • 버전 시간 초과를 전역적으로 구성하려면 KnativeServing 사용자 정의 리소스(CR)에서 revision-timeout-seconds 필드를 설정합니다.

    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeServing
    metadata:
      name: knative-serving
      namespace: knative-serving
    spec:
      config:
        defaults:
          revision-timeout-seconds: "300"

    Copy to Clipboard Toggle word wrap

  • 서비스 정의에서 timeoutSeconds 필드를 설정하여 버전당 시간 제한을 구성하려면 다음을 수행합니다.

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      namespace: my-ns
    spec:
      template:
        spec:
          timeoutSeconds: 300
          containers:
          - image: ghcr.io/knative/helloworld-go:latest

    Copy to Clipboard Toggle word wrap

사전 요구 사항

• OpenShift Serverless Operator 및 Knative Serving이 설치되어 있습니다.
• OpenShift Container Platform에 대한 클러스터 관리자 권한 또는 AWS 또는 OpenShift Dedicated의 Red Hat OpenShift Service에 대한 클러스터 관리자 권한이 있습니다.

프로세스

• 최대 버전 시간 제한을 구성하려면 KnativeServing CR(사용자 정의 리소스)에서 max-revision-timeout-seconds 필드를 설정합니다.

  If this value is increased, the activator `terminationGracePeriodSeconds` should also be increased to prevent in-flight requests being disrupted.

  Copy to Clipboard Toggle word wrap

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
    namespace: knative-serving
  spec:
    config:
      defaults:
        max-revision-timeout-seconds: "600"

  Copy to Clipboard Toggle word wrap

• envoy 프록시를 기반으로 합니다.
• 단순하고 가벼움이 있습니다.
• Serverless에서 기능 집합을 제공하는 데 필요한 기본 라우팅 기능을 제공합니다.
• 기본 관찰 기능 및 메트릭을 지원합니다.
• Knative 서비스 라우팅의 기본 TLS 종료를 지원합니다.
• 제한된 구성 및 확장 옵션만 제공합니다.

• 모든 연결 간의 기본 mTLS
• 서버리스 구성 요소는 서비스 메시의 일부입니다.
• 추가 관찰 기능 및 메트릭
• 인증 및 인증 지원
• Red Hat OpenShift Service Mesh에서 지원하는 사용자 정의 규칙 및 구성

• OpenShift 라우터에서 전달하는 클러스터 외부 경로 (예: myapp-namespace.example.com )
• 클러스터 도메인을 포함하는 클러스터 로컬 경로 (예: myapp.namespace.svc.cluster.local ) 이 도메인은 Knative 또는 기타 사용자 워크로드에서 Knative 서비스를 호출하는 데 사용할 수 있습니다.

• serve 모드에서 요청은 Knative 서비스의 Queue-Proxy 사이드카 컨테이너로 직접 이동합니다.
• 프록시 모드에서 요청은 먼저 knative-serving 네임스페이스의 Activator 구성 요소를 통과합니다.

• CN(Certificate Common Name) 또는 SAN(Subject Alternative Name)에는 Knative 서비스의 클러스터 로컬 도메인(예: myapp.namespace.svc.cluster.local,myapp.namespace.svc,myapp.namespace )이 포함되어 있습니다.
• ingress-controller 구성 요소의 cluster-local 끝점은 SNI를 사용하여 인증서를 선택합니다.
• 인증서를 생성하려면 Knative에서 cert-manager 를 사용합니다. 이 에서는 기능이 작동하도록 설치하고 구성해야 합니다. 자세한 내용은 cert-manager Operator for Red Hat OpenShift 에서 참조하십시오.

• OpenShift Serverless에서 인증서를 가져오려면 cert-manager 를 설치하고 구성해야 합니다.
• 특정 SAN은 각 연결을 확인하는 데 사용됩니다. 각 구성 요소는 인증서에 서명한 CA를 신뢰해야 합니다. 이 요구 사항을 충족하기 위해 OpenShift Serverless 시스템 구성 요소는 CA 번들을 사용하고 신뢰합니다. 클러스터 관리자가 CA 번들을 제공해야 합니다.

• 클러스터 로컬 암호화의 경우 발급자는 다음 클러스터 로컬 도메인 유형의 인증서에 서명할 수 있어야 합니다.

  • myapp.<namespace>
  • myapp.<namespace>.svc
  • myapp.<namespace>.svc.cluster.local

  일반적으로 CA는 클러스터 내에 없으므로 ACME(Automated Certificate Management Environment) 프로토콜(DNS01/HTTP01)을 사용하여 확인할 수 없습니다. cert-manager CA 발행자와 같은 이러한 인증서를 생성할 수 있는 발급자를 사용할 수 있습니다.

• 시스템 내부 암호화의 경우 발행자는 다음 SAN(Subject Alternative Names)을 사용하여 인증서에 서명할 수 있어야 합니다.

  • kn-routing
  • kn-user-<namespace > 형식의 이름입니다. 여기서 < namespace >는 Knative 서비스가 생성되는 네임스페이스입니다.
  • data-plane.knative.dev

  Knative에는 내부 구성 요소 간 연결을 확인하려면 이러한 SAN이 필요합니다. ACME 프로토콜(DNS01/HTTP01)을 사용할 수 없으므로 이러한 인증서를 생성할 수 있는 발행자를 구성해야 합니다(예: cert-manager CA 발행자).

• 빌드 시 컨테이너 이미지에 CA 번들 추가 이렇게 하면 CA가 회전할 때 모든 애플리케이션을 다시 빌드하고 재배포해야 하므로 CA 교체가 어려워집니다.
• 시크릿 또는 ConfigMap과 같은 파일 시스템에 CA 번들을 마운트하고 애플리케이션에서 TLS 연결을 확인하는 데 사용합니다.
• 환경 변수에서 CA 번들을 읽고 애플리케이션이 TLS 연결을 확인하는 데 사용하는지 확인합니다.
• Kubernetes API를 사용하여 시크릿 또는 ConfigMap에서 CA 번들에 액세스하고 애플리케이션에서 TLS 연결을 확인하는 데 사용하는지 확인합니다.