4.3. 서버리스 애플리케이션 구성
4.3.1. 시스템 배포 구성 덮어쓰기
KnativeServing
및 KnativeEventing
사용자 정의 리소스(CR)의 배포
사양을 수정하여 일부 특정 배포의 기본 구성을 덮어쓸 수 있습니다.
4.3.1.1. Knative Serving 시스템 배포 구성 덮어쓰기
KnativeServing
CR(사용자 정의 리소스)의 deployments 사양을 수정하여 일부 특정 배포
의 기본 구성을 덮어쓸 수 있습니다. 현재는 리소스
,복제본
,레이블
,주석
및 nodeSelector
필드에 대해 기본 구성 설정을 재정의하는 것은 물론 프로브를 위한 준비
상태 및 활성 상태
필드에 대해 지원됩니다.
다음 예에서 KnativeServing
CR은 다음과 같이 Webhook
배포를 덮어씁니다.
-
net-kourier-controller
의준비 상태
프로브 타임아웃이 10초로 설정됩니다. - 배포에 CPU 및 메모리 리소스 제한이 지정되었습니다.
- 배포에는 3개의 복제본이 있습니다.
-
example-label: 레이블
레이블이 추가되었습니다. -
example-annotation: 주석
주석이 추가되었습니다. -
nodeSelector
필드는disktype: hdd
레이블이 있는 노드를 선택하도록 설정됩니다.
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
.
추가 리소스
4.3.2. emptyDir 볼륨
emptyDir
볼륨은 Pod가 생성될 때 생성되는 빈 볼륨이며 임시 작업 디스크 공간을 제공하는 데 사용됩니다. emptyDir
볼륨은 생성된 Pod가 삭제될 때 삭제됩니다.
4.3.2.1. 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 ...
4.3.3. Serving용 영구 볼륨 클레임
일부 서버리스 애플리케이션에는 영구 데이터 스토리지가 필요합니다. 이를 위해 Knative 서비스에 대한 PVC(영구 볼륨 클레임)를 구성할 수 있습니다.
4.3.3.1. 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 컨테이너 사용자의 사용자 권한과 같은 추가 구성이 필요합니다.
4.3.3.2. 추가 리소스
4.3.4. Init 컨테이너
Init 컨테이너 는 Pod의 애플리케이션 컨테이너보다 먼저 실행되는 특수 컨테이너입니다. 일반적으로 애플리케이션의 초기화 논리를 구현하는 데 사용되며, 이 논리는 실행 중인 설정 스크립트 실행 또는 필요한 구성 다운로드를 포함할 수 있습니다. KnativeServing
CR(사용자 정의 리소스)을 수정하여 Knative 서비스에 대한 init 컨테이너 사용을 활성화할 수 있습니다.
Init 컨테이너는 애플리케이션 시작 시간이 길어질 수 있으며, 자주 확장 및 축소할 것으로 예상되는 서버리스 애플리케이션에 주의하여 사용해야 합니다.
4.3.4.1. init 컨테이너 활성화
사전 요구 사항
- 클러스터에 OpenShift Serverless Operator 및 Knative Serving을 설치했습니다.
- 클러스터 관리자 권한이 있어야 합니다.
절차
KnativeServing
CR에kubernetes.podspec-init-containers
플래그를 추가하여 init 컨테이너 사용을 활성화합니다.KnativeServing CR의 예
apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving spec: config: features: kubernetes.podspec-init-containers: enabled ...
4.3.5. 다이제스트로 이미지 태그 확인
Knative Serving 컨트롤러가 컨테이너 레지스트리에 액세스할 수 있는 경우 Knative Serving은 서비스 버전을 생성할 때 이미지 태그를 다이제스트로 확인합니다. 이 문제를 태그-다이제스트 해결 이라고 하며 배포에 일관성을 제공하는 데 도움이 됩니다.
4.3.5.1. Tag-to-digest resolution
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
구성 맵을 클러스터 전체 인증서로 채우고 구성 맵을 컨트롤러에 볼륨으로 마운트합니다.
4.3.5.1.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>
Secret
유형을 사용하도록KnativeServing
CR(사용자 정의 리소스)에서controller-custom-certs
사양을 구성합니다.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
4.3.6. 제한적인 네트워크 정책
4.3.6.1. 제한적인 네트워크 정책이 있는 클러스터
여러 사용자가 액세스할 수 있는 클러스터를 사용하는 경우 클러스터는 네트워크 정책을 사용하여 네트워크를 통해 서로 통신할 수 있는 pod, 서비스 및 네임스페이스를 제어할 수 있습니다. 클러스터에서 제한적인 네트워크 정책을 사용하는 경우 Knative 시스템 Pod가 Knative 애플리케이션에 액세스할 수 없습니다. 예를 들어 네임스페이스에 모든 요청을 거부하는 다음 네트워크 정책이 있는 경우 Knative 시스템 Pod가 Knative 애플리케이션에 액세스할 수 없습니다.
네임스페이스에 대한 모든 요청을 거부하는 NetworkPolicy 오브젝트의 예
kind: NetworkPolicy apiVersion: networking.k8s.io/v1 metadata: name: deny-by-default namespace: example-namespace spec: podSelector: ingress: []
4.3.6.2. 제한적인 네트워크 정책을 사용하여 클러스터에서 Knative 애플리케이션과의 통신 활성화
Knative 시스템 Pod에서 애플리케이션에 액세스할 수 있도록 하려면 각 Knative 시스템 네임스페이스에 레이블을 추가한 다음 이 레이블이 있는 다른 네임스페이스의 네임스페이스에 액세스할 수 있는 애플리케이션 네임스페이스에 NetworkPolicy
오브젝트를 생성해야 합니다.
클러스터의 비Knative 서비스에 대한 요청을 거부하는 네트워크 정책은 이러한 서비스에 대한 액세스를 계속 차단합니다. 그러나 Knative 시스템 네임스페이스에서 Knative 애플리케이션으로의 액세스를 허용하면 클러스터의 모든 네임스페이스에서 Knative 애플리케이션에 액세스할 수 있습니다.
클러스터의 모든 네임스페이스에서 Knative 애플리케이션에 대한 액세스를 허용하지 않으려면 Knative 서비스에 JSON 웹 토큰 인증을 사용할 수 있습니다. Knative 서비스에 대한 JSON 웹 토큰 인증에는 Service Mesh가 필요합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. - OpenShift Serverless Operator 및 Knative Serving이 클러스터에 설치되어 있습니다.
절차
애플리케이션에 액세스해야 하는 각 Knative 시스템 네임스페이스에
knative.openshift.io/system-namespace=true
레이블을 추가합니다.knative-serving
네임스페이스에 레이블을 지정합니다.$ oc label namespace knative-serving knative.openshift.io/system-namespace=true
knative-serving-ingress
네임스페이스에 레이블을 지정합니다.$ oc label namespace knative-serving-ingress knative.openshift.io/system-namespace=true
knative-eventing
네임스페이스에 레이블을 지정합니다.$ oc label namespace knative-eventing knative.openshift.io/system-namespace=true
knative-kafka
네임스페이스에 레이블을 지정합니다.$ oc label namespace knative-kafka knative.openshift.io/system-namespace=true
애플리케이션 네임스페이스에
NetworkPolicy
오브젝트를 생성하여knative.openshift.io/system-namespace
레이블이 있는 네임스페이스에서 액세스를 허용합니다.NetworkPolicy
오브젝트 예apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: <network_policy_name> 1 namespace: <namespace> 2 spec: ingress: - from: - namespaceSelector: matchLabels: knative.openshift.io/system-namespace: "true" podSelector: {} policyTypes: - Ingress