6장. 관리

6.1. 글로벌 구성

OpenShift Serverless Operator는 Knative Serving 및 Knative Eventing 사용자 정의 리소스에서 시스템 구성 으로 값 전파를 포함하여 Knative 설치의 글로벌 구성을 관리합니다. 수동으로 적용되는 구성 맵에 대한 업데이트는 Operator에서 덮어씁니다. 그러나 Knative 사용자 정의 리소스를 수정하면 이러한 구성 맵의 값을 설정할 수 있습니다.

Knative에는 config - 접두사로 이름이 지정된 여러 구성 맵이 있습니다. 모든 Knative 구성 맵은 적용되는 사용자 정의 리소스와 동일한 네임스페이스에 생성됩니다. 예를 들어 knative-serving 네임스페이스에 KnativeServing 사용자 정의 리소스가 생성되는 경우 이 네임스페이스에 모든 Knative Serving 구성 맵도 생성됩니다.

Knative 사용자 정의 리소스의 spec.config 에는 config- <name>이라는 각 구성 맵에 대해 하나의 & lt;name> 항목이 있으며 구성 맵 데이터에 사용되는 값이 있습니다.

6.1.1. 기본 채널 구현 구성

default-ch-webhook 구성 맵을 사용하여 Knative Eventing의 기본 채널 구현을 지정할 수 있습니다. 전체 클러스터 또는 하나 이상의 네임스페이스에 기본 채널 구현을 지정할 수 있습니다. 현재 InMemoryChannelKafkaChannel 채널 유형이 지원됩니다.

사전 요구 사항

  • OpenShift Container Platform에 대한 관리자 권한이 있습니다.
  • OpenShift Serverless Operator 및 Knative Eventing을 클러스터에 설치했습니다.
  • Kafka 채널을 기본 채널 구현으로 사용하려면 클러스터에 KnativeKafka CR도 설치해야 합니다.

절차

  • KnativeEventing 사용자 정의 리소스를 수정하여 default-ch-webhook 구성 맵에 대한 구성 세부 정보를 추가합니다.

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeEventing
    metadata:
      name: knative-eventing
      namespace: knative-eventing
    spec:
      config: 1
        default-ch-webhook: 2
          default-ch-config: |
            clusterDefault: 3
              apiVersion: messaging.knative.dev/v1
              kind: InMemoryChannel
              spec:
                delivery:
                  backoffDelay: PT0.5S
                  backoffPolicy: exponential
                  retry: 5
            namespaceDefaults: 4
              my-namespace:
                apiVersion: messaging.knative.dev/v1beta1
                kind: KafkaChannel
                spec:
                  numPartitions: 1
                  replicationFactor: 1
    1
    spec.config에서 수정된 구성을 추가할 구성 맵을 지정할 수 있습니다.
    2
    default-ch-webhook 구성 맵을 사용하여 클러스터 또는 하나 이상의 네임스페이스에 대한 기본 채널 구현을 지정할 수 있습니다.
    3
    클러스터 수준 기본 채널 유형 구성입니다. 이 예제에서 클러스터에 대한 기본 채널 구현은 InMemoryChannel입니다.
    4
    네임스페이스 범위의 기본 채널 유형 구성입니다. 이 예제에서 my-namespace 네임스페이스의 기본 채널 구현은 KafkaChannel입니다.
    중요

    네임스페이스별 기본값을 구성하면 클러스터 수준 설정을 덮어씁니다.

6.1.2. 기본 브로커 지원 채널 구성

채널 기반 브로커를 사용하는 경우 브로커의 기본 지원 채널 유형을 InMemoryChannel 또는 KafkaChannel로 설정할 있습니다.

사전 요구 사항

  • OpenShift Container Platform에 대한 관리자 권한이 있습니다.
  • OpenShift Serverless Operator 및 Knative Eventing을 클러스터에 설치했습니다.
  • OpenShift(oc) CLI를 설치했습니다.
  • Kafka 채널을 기본 지원 채널 유형으로 사용하려면 클러스터에 KnativeKafka CR도 설치해야 합니다.

절차

  1. KnativeEventing CR(사용자 정의 리소스)을 수정하여 config-br-default-channel 구성 맵에 대한 구성 세부 정보를 추가합니다.

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeEventing
    metadata:
      name: knative-eventing
      namespace: knative-eventing
    spec:
      config: 1
        config-br-default-channel:
          channel-template-spec: |
            apiVersion: messaging.knative.dev/v1beta1
            kind: KafkaChannel 2
            spec:
              numPartitions: 6 3
              replicationFactor: 3 4
    1
    spec.config에서 수정된 구성을 추가할 구성 맵을 지정할 수 있습니다.
    2
    기본 지원 채널 유형 구성입니다. 이 예에서 클러스터의 기본 채널 구현은 KafkaChannel 입니다.
    3
    브로커를 지원하는 Kafka 채널의 파티션 수입니다.
    4
    브로커를 지원하는 Kafka 채널의 복제 요소.
  2. 업데이트된 KnativeEventing CR을 적용합니다.

    $ oc apply -f <filename>

6.1.3. 기본 브로커 클래스 구성

config-br-defaults 구성 맵을 사용하여 Knative Eventing의 기본 브로커 클래스 설정을 지정할 수 있습니다. 전체 클러스터 또는 하나 이상의 네임스페이스에 대해 default 브로커 클래스를 지정할 수 있습니다. 현재 MTChannelBasedBrokerKafka 브로커 유형이 지원됩니다.

사전 요구 사항

  • OpenShift Container Platform에 대한 관리자 권한이 있습니다.
  • OpenShift Serverless Operator 및 Knative Eventing을 클러스터에 설치했습니다.
  • Kafka 브로커를 기본 브로커 구현으로 사용하려면 클러스터에 KnativeKafka CR도 설치해야 합니다.

프로세스

  • KnativeEventing 사용자 정의 리소스를 수정하여 config-br-defaults 구성 맵에 대한 구성 세부 정보를 추가합니다.

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeEventing
    metadata:
      name: knative-eventing
      namespace: knative-eventing
    spec:
      defaultBrokerClass: Kafka 1
      config: 2
        config-br-defaults: 3
          default-br-config: |
            clusterDefault: 4
              brokerClass: Kafka
              apiVersion: v1
              kind: ConfigMap
              name: kafka-broker-config 5
              namespace: knative-eventing 6
            namespaceDefaults: 7
              my-namespace:
                brokerClass: MTChannelBasedBroker
                apiVersion: v1
                kind: ConfigMap
                name: config-br-default-channel 8
                namespace: knative-eventing 9
    ...
    1
    Knative Eventing의 기본 브로커 클래스입니다.
    2
    spec.config에서 수정된 구성을 추가할 구성 맵을 지정할 수 있습니다.
    3
    config-br-defaults 구성 맵은 spec.config 설정 또는 브로커 클래스를 지정하지 않는 브로커의 기본 설정을 지정합니다.
    4
    클러스터 전체 기본 브로커 클래스 구성입니다. 이 예에서 클러스터의 기본 브로커 클래스 구현은 Kafka 입니다.
    5
    kafka-broker-config 구성 맵은 Kafka 브로커의 기본 설정을 지정합니다. "추가 리소스" 섹션의 Kafka 브로커 설정 구성을 참조하십시오.
    6
    kafka-broker-config 구성 맵이 존재하는 네임스페이스입니다.
    7
    네임스페이스 범위의 기본 브로커 클래스 구성입니다. 이 예에서 my-namespace 네임스페이스의 기본 브로커 클래스 구현은 MTChannelBasedBroker 입니다. 여러 네임스페이스에 기본 브로커 클래스 구현을 지정할 수 있습니다.
    8
    config-br-default-channel 구성 맵은 브로커의 기본 지원 채널을 지정합니다. "추가 리소스" 섹션의 "기본 브로커 백업 채널 구성"을 참조하십시오.
    9
    config-br-default-channel 구성 맵이 존재하는 네임스페이스입니다.
    중요

    네임스페이스별 기본값을 구성하면 클러스터 수준 설정을 덮어씁니다.

6.1.4. scale-to-zero 활성화

Knative Serving에서는 애플리케이션이 들어오는 수요와 일치하도록 자동 확장 또는 자동 스케일링 을 제공합니다. enable-scale-to-zero 사양을 사용하여 클러스터의 애플리케이션에 대해 전체적으로 스케일 투 0을 활성화하거나 비활성화할 수 있습니다.

사전 요구 사항

  • 클러스터에 OpenShift Serverless Operator 및 Knative Serving이 설치되어 있습니다.
  • 클러스터 관리자 권한이 있어야 합니다.
  • 기본 Knative Pod Autoscaler를 사용하고 있습니다. Kubernetes Horizontal Pod Autoscaler를 사용하는 경우 0으로 스케일링 기능을 사용할 수 없습니다.

절차

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

    KnativeServing CR의 예

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

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

6.1.5. scale-to-zero 유예 기간 구성

Knative Serving은 애플리케이션의 Pod를 0개로 자동 축소합니다. scale-to-zero-grace-period 사양을 사용하여 애플리케이션의 마지막 복제본이 제거되기 전에 Knative에서 0으로 머신 사이가 될 때까지 대기하는 상한 시간 제한을 정의할 수 있습니다.

사전 요구 사항

  • 클러스터에 OpenShift Serverless Operator 및 Knative Serving이 설치되어 있습니다.
  • 클러스터 관리자 권한이 있어야 합니다.
  • 기본 Knative Pod Autoscaler를 사용하고 있습니다. Kubernetes Horizontal Pod Autoscaler를 사용하는 경우 0으로 스케일링 기능을 사용할 수 없습니다.

프로세스

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

    KnativeServing CR의 예

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

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

6.1.6. 시스템 배포 구성 덮어쓰기

KnativeServingKnativeEventing 사용자 정의 리소스(CR)의 배포 사양을 수정하여 일부 특정 배포의 기본 구성을 덮어쓸 수 있습니다.

6.1.6.1. Knative Serving 시스템 배포 구성 덮어쓰기

KnativeServing CR(사용자 정의 리소스)에서 deployment 사양을 수정하여 일부 특정 배포의 기본 구성을 재정의할 수 있습니다. 현재는 리소스,복제본,라벨,주석, nodeSelector 필드에 대해 기본 구성 설정을 재정의할 수 있습니다.

다음 예에서 KnativeServing CR은 다음과 같이 Webhook 배포를 덮어씁니다.

  • 배포에 CPU 및 메모리 리소스 제한이 지정되었습니다.
  • 배포에는 3개의 복제본이 있습니다.
  • example-label: 레이블 레이블이 추가되었습니다.
  • example-annotation: 주석 주석이 추가되었습니다.
  • nodeSelector 필드는 disktype:d 레이블이 있는 노드를 선택하도록 설정됩니다.
참고

KnativeServing CR 라벨 및 주석 설정은 배포 자체와 결과 Pod 모두에 대한 배포 라벨 및 주석을 재정의합니다.

KnativeServing CR 예

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: ks
  namespace: knative-serving
spec:
  high-availability:
    replicas: 2
  deployments:
  - name: webhook
    resources:
    - container: webhook
      requests:
        cpu: 300m
        memory: 60Mi
      limits:
        cpu: 1000m
        memory: 1000Mi
    replicas: 3
    labels:
      example-label: label
    annotations:
      example-annotation: annotation
    nodeSelector:
      disktype: hdd

6.1.6.2. Knative Eventing 시스템 배포 구성 덮어쓰기

KnativeEventing CR(사용자 정의 리소스)에서 deployments 사양을 수정하여 일부 특정 배포에 대한 기본 구성을 덮어쓸 수 있습니다. 현재는 eventing-controller,eventing-webhook, imc-controller 필드에 대해 기본 구성 설정을 재정의할 수 있습니다.

중요

replicas 사양은 HPA(Horizond Pod Autoscaler)를 사용하는 배포의 복제본 수를 재정의할 수 없으며 eventing-webhook 배포에 작동하지 않습니다.

다음 예에서 KnativeEventing CR은 eventing-controller 배포를 재정의하여 다음을 수행합니다.

  • 배포에 CPU 및 메모리 리소스 제한이 지정되었습니다.
  • 배포에는 3개의 복제본이 있습니다.
  • example-label: 레이블 레이블이 추가되었습니다.
  • example-annotation: 주석 주석이 추가되었습니다.
  • nodeSelector 필드는 disktype:d 레이블이 있는 노드를 선택하도록 설정됩니다.

KnativeEventing CR 예

apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  deployments:
  - name: eventing-controller
    resources:
    - container: eventing-controller
      requests:
        cpu: 300m
        memory: 100Mi
      limits:
        cpu: 1000m
        memory: 250Mi
    replicas: 3
    labels:
      example-label: label
    annotations:
      example-annotation: annotation
    nodeSelector:
      disktype: hdd

참고

KnativeEventing CR 레이블 및 주석 설정은 배포 자체와 결과 Pod 모두에 대한 배포의 라벨 및 주석을 재정의합니다.

6.1.7. EmptyDir 확장 구성

emptyDir 볼륨은 Pod가 생성될 때 생성되는 빈 볼륨이며 임시 작업 디스크 공간을 제공하는 데 사용됩니다. emptyDir 볼륨은 삭제할 때 삭제됩니다.

kubernetes.podspec-volumes-emptydir 확장 기능은 emptyDir 볼륨을 Knative Serving과 함께 사용할 수 있는지 여부를 제어합니다. emptyDir 볼륨을 사용하여 활성화하려면 다음 YAML을 포함하도록 KnativeServing CR(사용자 정의 리소스)을 수정해야 합니다.

KnativeServing CR의 예

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    features:
      kubernetes.podspec-volumes-emptydir: enabled
...

6.1.8. HTTPS 리디렉션 전역 설정

HTTPS 리디렉션은 들어오는 HTTP 요청에 대한 리디렉션을 제공합니다. 이러한 리디렉션된 HTTP 요청은 암호화됩니다. KnativeServing CR(사용자 정의 리소스)에 httpProtocol 사양을 구성하여 클러스터의 모든 서비스에 대해 HTTPS 리디렉션을 활성화할 수 있습니다.

HTTPS 리디렉션을 활성화하는 KnativeServing CR의 예

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    network:
      httpProtocol: "redirected"
...

6.1.9. 외부 경로의 URL 스키마 설정

보안을 강화하기 위해 외부 경로의 URL 스키마는 기본적으로 HTTPS로 설정됩니다. 이 스키마는 KnativeServing CR(사용자 정의 리소스) 사양의 default-external-scheme 키로 결정됩니다.

기본 사양

...
spec:
  config:
    network:
      default-external-scheme: "https"
...

default-external-scheme 키를 수정하여 HTTP를 사용하도록 기본 사양을 덮어쓸 수 있습니다.

HTTP 덮어쓰기 사양

...
spec:
  config:
    network:
      default-external-scheme: "http"
...

6.1.10. Kourier Gateway 서비스 유형 설정

Kourier 게이트웨이는 기본적으로 ClusterIP 서비스 유형으로 노출됩니다. 이 서비스 유형은 KnativeServing CR(사용자 정의 리소스)의 서비스 유형 Ingress 사양에 따라 결정됩니다.

기본 사양

...
spec:
  ingress:
    kourier:
      service-type: ClusterIP
...

service-type 사양을 수정하여 로드 밸런서 서비스 유형을 대신 사용하도록 기본 서비스 유형을 덮어쓸 수 있습니다.

LoadBalancer 덮어쓰기 사양

...
spec:
  ingress:
    kourier:
      service-type: LoadBalancer
...

6.1.11. PVC 지원 활성화

일부 서버리스 애플리케이션에는 영구 데이터 스토리지가 필요합니다. 이를 위해 Knative 서비스에 대한 PVC(영구 볼륨 클레임)를 구성할 수 있습니다.

중요

Knative 서비스에 대한 PVC 지원은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 https://access.redhat.com/support/offerings/techpreview/를 참조하십시오.

프로세스

  1. Knative Serving이 PVC를 사용하고 작성할 수 있도록 하려면 다음 YAML을 포함하도록 KnativeServing CR(사용자 정의 리소스)을 수정합니다.

    쓰기 액세스로 PVC 활성화

    ...
    spec:
      config:
        features:
          "kubernetes.podspec-persistent-volume-claim": enabled
          "kubernetes.podspec-persistent-volume-write": enabled
    ...

    • kubernetes.podspec-persistent-volume-claim 확장 기능은 Knative Serving에서 PV(영구 볼륨)를 사용할 수 있는지 여부를 제어합니다.
    • kubernetes.podspec-persistent-volume-write 확장 기능은 쓰기 액세스 권한이 있는 Knative Serving에서 PV를 사용할 수 있는지 여부를 제어합니다.
  2. PV를 클레임하려면 PV 구성을 포함하도록 서비스를 수정합니다. 예를 들어 다음 구성을 사용하는 영구 볼륨 클레임이 있을 수 있습니다.

    참고

    요청 중인 액세스 모드를 지원하는 스토리지 클래스를 사용합니다. 예를 들어 ReadWriteMany 액세스 모드에 ocs-storagecluster-cephfs 클래스를 사용할 수 있습니다.

    PersistentVolumeClaim 구성

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: example-pv-claim
      namespace: my-ns
    spec:
      accessModes:
        - ReadWriteMany
      storageClassName: ocs-storagecluster-cephfs
      resources:
        requests:
          storage: 1Gi

    이 경우 쓰기 액세스 권한이 있는 PV를 요청하려면 서비스를 다음과 같이 수정합니다.

    Knative 서비스 PVC 구성

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      namespace: my-ns
    ...
    spec:
     template:
       spec:
         containers:
             ...
             volumeMounts: 1
               - mountPath: /data
                 name: mydata
                 readOnly: false
         volumes:
           - name: mydata
             persistentVolumeClaim: 2
               claimName: example-pv-claim
               readOnly: false 3

    1
    볼륨 마운트 사양.
    2
    영구 볼륨 클레임 사양.
    3
    읽기 전용 액세스를 활성화하는 플래그입니다.
    참고

    Knative 서비스에서 영구 스토리지를 사용하려면 Knative 컨테이너 사용자에 대한 사용자 권한과 같은 추가 구성이 필요합니다.

6.1.12. init 컨테이너 활성화

Init 컨테이너 는 Pod의 애플리케이션 컨테이너보다 먼저 실행되는 특수 컨테이너입니다. 일반적으로 애플리케이션에 대한 초기화 논리를 구현하는 데 사용됩니다. 이 논리에는 설정 스크립트를 실행하거나 필요한 구성을 다운로드하는 작업이 포함될 수 있습니다. KnativeServing CR(사용자 정의 리소스)을 수정하여 Knative 서비스의 init 컨테이너 사용을 활성화할 수 있습니다.

중요

Knative 서비스의 init 컨테이너는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 https://access.redhat.com/support/offerings/techpreview/를 참조하십시오.

참고

Init 컨테이너는 애플리케이션 시작 시간이 길어질 수 있으며 서버리스 애플리케이션에 주의해서 사용해야 합니다. 이 경우 자주 확장 및 축소할 것으로 예상됩니다.

사전 요구 사항

  • 클러스터에 OpenShift Serverless Operator 및 Knative Serving이 설치되어 있습니다.
  • 클러스터 관리자 권한이 있어야 합니다.

프로세스

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

    KnativeServing CR의 예

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

6.1.13. 태그-다이제스트 해결

Knative Serving 컨트롤러가 컨테이너 레지스트리에 액세스할 수 있는 경우 Knative Serving은 서비스 버전을 생성할 때 이미지 태그를 다이제스트로 확인합니다. 이를 태그-다이제스트 해결 이라고 하며 배포에 일관성을 제공하는 데 도움이 됩니다.

OpenShift Container Platform의 컨테이너 레지스트리에 컨트롤러 액세스 권한을 부여하려면 보안을 생성한 다음 컨트롤러 사용자 정의 인증서를 구성해야 합니다. KnativeServing CR(사용자 정의 리소스)에서 controller-custom-certs 사양을 수정하여 컨트롤러 사용자 정의 인증서를 구성할 수 있습니다. 시크릿은 KnativeServing CR과 동일한 네임스페이스에 있어야 합니다.

secret이 KnativeServing CR에 포함되지 않은 경우 이 설정은 기본적으로 PKI(공개 키 인프라)를 사용합니다. PKI를 사용하는 경우 config-service-sa 구성 맵을 사용하여 클러스터 전체 인증서가 Knative Serving 컨트롤러에 자동으로 삽입됩니다. OpenShift Serverless Operator는 config-service-sa 구성 맵을 클러스터 전체 인증서로 채우고 구성 맵을 컨트롤러에 볼륨으로 마운트합니다.

6.1.13.1. 보안을 사용하여 태그-다이제스트 해결 구성

controller-custom-certs 사양에서 Secret 유형을 사용하는 경우 시크릿은 시크릿 볼륨으로 마운트됩니다. Knative 구성 요소는 보안에 필요한 인증서가 있다고 가정하여 보안을 직접 사용합니다.

사전 요구 사항

  • OpenShift Container Platform에 대한 클러스터 관리자 권한이 있습니다.
  • 클러스터에 OpenShift Serverless Operator 및 Knative Serving이 설치되어 있습니다.

프로세스

  1. 보안을 생성합니다.

    명령 예

    $ oc -n knative-serving create secret generic custom-secret --from-file=<secret_name>.crt=<path_to_certificate>

  2. KnativeServing 사용자 정의 리소스(CR)에서 controller-custom-certs 사양을 구성하여 Secret 유형을 사용합니다.

    KnativeServing CR의 예

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeServing
    metadata:
      name: knative-serving
      namespace: knative-serving
    spec:
      controller-custom-certs:
        name: custom-secret
        type: Secret

6.1.14. 추가 리소스