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의 기본 채널 구현을 지정할 수 있습니다. 전체 클러스터 또는 하나 이상의 네임스페이스에 기본 채널 구현을 지정할 수 있습니다. 현재 InMemoryChannel
및 KafkaChannel
채널 유형이 지원됩니다.
사전 요구 사항
- OpenShift Container Platform에 대한 관리자 권한이 있습니다.
- OpenShift Serverless Operator 및 Knative Eventing을 클러스터에 설치했습니다.
-
Kafka 채널을 기본 채널 구현으로 사용하려면 클러스터에
KnativeKafka
CR도 설치해야 합니다.
절차
KnativeEventing
사용자 정의 리소스를 수정하여default-ch-webhook
구성 맵에 대한 구성 세부 정보를 추가합니다.apiVersion: operator.knative.dev/v1beta1 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
중요네임스페이스별 기본값을 구성하면 클러스터 수준 설정을 덮어씁니다.
6.1.2. 기본 브로커 지원 채널 구성
채널 기반 브로커를 사용하는 경우 브로커의 기본 지원 채널 유형을 InMemoryChannel 또는 KafkaChannel로 설정할 수
있습니다
.
사전 요구 사항
- OpenShift Container Platform에 대한 관리자 권한이 있습니다.
- OpenShift Serverless Operator 및 Knative Eventing을 클러스터에 설치했습니다.
-
OpenShift(
oc
) CLI를 설치했습니다. -
Kafka 채널을 기본 지원 채널 유형으로 사용하려면 클러스터에
KnativeKafka
CR도 설치해야 합니다.
절차
KnativeEventing
CR(사용자 정의 리소스)을 수정하여config-br-default-channel
구성 맵에 대한 구성 세부 정보를 추가합니다.apiVersion: operator.knative.dev/v1beta1 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
업데이트된
KnativeEventing
CR을 적용합니다.$ oc apply -f <filename>
6.1.3. 기본 브로커 클래스 구성
config-br-defaults
구성 맵을 사용하여 Knative Eventing의 기본 브로커 클래스 설정을 지정할 수 있습니다. 전체 클러스터 또는 하나 이상의 네임스페이스에 대해 default 브로커 클래스를 지정할 수 있습니다. 현재 MTChannelBasedBroker
및 Kafka
브로커 유형이 지원됩니다.
사전 요구 사항
- OpenShift Container Platform에 대한 관리자 권한이 있습니다.
- OpenShift Serverless Operator 및 Knative Eventing을 클러스터에 설치했습니다.
-
Kafka 브로커를 기본 브로커 구현으로 사용하려면 클러스터에
KnativeKafka
CR도 설치해야 합니다.
절차
KnativeEventing
사용자 정의 리소스를 수정하여config-br-defaults
구성 맵에 대한 구성 세부 정보를 추가합니다.apiVersion: operator.knative.dev/v1beta1 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/v1beta1 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/v1beta1 kind: KnativeServing metadata: name: knative-serving spec: config: autoscaler: scale-to-zero-grace-period: "30s" 1
- 1
- 유예 기간(초)입니다. 기본값은 30초입니다.
6.1.6. 시스템 배포 구성 덮어쓰기
KnativeServing
및 KnativeEventing
사용자 정의 리소스(CR)의 배포
사양을 수정하여 일부 특정 배포의 기본 구성을 덮어쓸 수 있습니다.
6.1.6.1. Knative Serving 시스템 배포 구성 덮어쓰기
KnativeServing
CR(사용자 정의 리소스)에서 deployment 사양을 수정하여 일부 특정 배포의
기본 구성을 재정의할 수 있습니다. 현재는 리소스
,복제본
,레이블
,주석
및 nodeSelector
필드에 대해 기본 구성 설정을 재정의하는 것은 물론 프로브를 위한 준비
상태 및 활성 상태
필드에 대해 지원됩니다.
다음 예에서 KnativeServing
CR은 다음과 같이 Webhook
배포를 덮어씁니다.
-
net-kourier-controller
의준비 상태
프로브 타임아웃이 10초로 설정됩니다. - 배포에 CPU 및 메모리 리소스 제한이 지정되었습니다.
- 배포에는 3개의 복제본이 있습니다.
-
example-label: 레이블
레이블이 추가되었습니다. -
example-annotation: 주석
주석이 추가되었습니다. -
nodeSelector
필드는disktype:d 레이블이
있는 노드를 선택하도록 설정됩니다.
KnativeServing
CR 라벨 및 주석 설정은 배포 자체와 결과 Pod 모두에 대한 배포 라벨 및 주석을 재정의합니다.
KnativeServing CR 예
apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
name: ks
namespace: knative-serving
spec:
high-availability:
replicas: 2
deployments:
- name: net-kourier-controller
readinessProbes: 1
- container: controller
timeoutSeconds: 10
- 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
- 1
준비
상태 및 활성 상태 프로브
덮어쓰기를 사용하여 프로브에 지정된 대로 Kubernetes API에 지정된 대로 배포 컨테이너에 있는 프로브의 모든 필드를 재정의할 수 있습니다. 그러나 프로브 처리기와 관련된 필드인exec
,grpc
,httpGet
,tcpSocket
.
추가 리소스
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
배포를 재정의하여 다음을 수행합니다.
-
readiness
프로브 시간 초과eventing-controller
가 10초로 설정됩니다. - 배포에 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
readinessProbes: 1
- container: controller
timeoutSeconds: 10
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
- 1
준비
상태 및 활성 상태 프로브
덮어쓰기를 사용하여 프로브에 지정된 대로 Kubernetes API에 지정된 대로 배포 컨테이너에 있는 프로브의 모든 필드를 재정의할 수 있습니다. 그러나 프로브 처리기와 관련된 필드인exec
,grpc
,httpGet
,tcpSocket
.
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/v1beta1 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/v1beta1 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 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를 사용할 수 있는지 여부를 제어합니다.
-
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
참고Knative 서비스에서 영구 스토리지를 사용하려면 Knative 컨테이너 사용자에 대한 사용자 권한과 같은 추가 구성이 필요합니다.
6.1.12. init 컨테이너 활성화
Init 컨테이너 는 Pod의 애플리케이션 컨테이너보다 먼저 실행되는 특수 컨테이너입니다. 일반적으로 애플리케이션에 대한 초기화 논리를 구현하는 데 사용됩니다. 이 논리에는 설정 스크립트를 실행하거나 필요한 구성을 다운로드하는 작업이 포함될 수 있습니다. KnativeServing
CR(사용자 정의 리소스)을 수정하여 Knative 서비스의 init 컨테이너 사용을 활성화할 수 있습니다.
Init 컨테이너는 애플리케이션 시작 시간이 길어질 수 있으며 서버리스 애플리케이션에 주의해서 사용해야 합니다. 이 경우 자주 확장 및 축소할 것으로 예상됩니다.
사전 요구 사항
- 클러스터에 OpenShift Serverless Operator 및 Knative Serving이 설치되어 있습니다.
- 클러스터 관리자 권한이 있어야 합니다.
프로세스
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 ...
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이 설치되어 있습니다.
프로세스
보안을 생성합니다.
명령 예
$ oc -n knative-serving create secret generic custom-secret --from-file=<secret_name>.crt=<path_to_certificate>
KnativeServing
사용자 정의 리소스(CR)에서controller-custom-certs
사양을 구성하여Secret
유형을 사용합니다.KnativeServing CR의 예
apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving spec: controller-custom-certs: name: custom-secret type: Secret