4.3. 서버리스 애플리케이션 구성


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

KnativeServingKnativeEventing 사용자 정의 리소스(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 지원 활성화

절차

  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 컨테이너 사용자의 사용자 권한과 같은 추가 구성이 필요합니다.

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이 클러스터에 설치되어 있습니다.

절차

  1. 보안을 생성합니다.

    명령 예

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

  2. 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이 클러스터에 설치되어 있습니다.

절차

  1. 애플리케이션에 액세스해야 하는 각 Knative 시스템 네임스페이스에 knative.openshift.io/system-namespace=true 레이블을 추가합니다.

    1. knative-serving 네임스페이스에 레이블을 지정합니다.

      $ oc label namespace knative-serving knative.openshift.io/system-namespace=true
    2. knative-serving-ingress 네임스페이스에 레이블을 지정합니다.

      $ oc label namespace knative-serving-ingress knative.openshift.io/system-namespace=true
    3. knative-eventing 네임스페이스에 레이블을 지정합니다.

      $ oc label namespace knative-eventing knative.openshift.io/system-namespace=true
    4. knative-kafka 네임스페이스에 레이블을 지정합니다.

      $ oc label namespace knative-kafka knative.openshift.io/system-namespace=true
  2. 애플리케이션 네임스페이스에 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

    1
    네트워크 정책의 이름을 제공합니다.
    2
    애플리케이션이 존재하는 네임스페이스입니다.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.