4.3. Serverless 애플리케이션 구성


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

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

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

현재는 리소스,복제본,레이블,주석, nodeSelector 필드에는 기본 구성 설정을 재정의하고 프로브 의 준비 및 활성 필드에도 지원됩니다.

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

  • net-kourier-controller 에 대한 준비 상태 프로브 타임아웃은 10초로 설정되어 있습니다.
  • 배포에 지정된 CPU 및 메모리 리소스 제한이 있습니다.
  • 배포에는 3개의 복제본이 있습니다.
  • example-label: 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
프로브 처리기와 관련된 필드인 exec,grpc,httpGettcpSocket 와 관련된 필드를 제외하고 readiness 및 활성 프로브 덮어쓰기를 사용하여 Kubernetes API에 지정된 배포 컨테이너의 모든 필드를 덮어쓸 수 있습니다.

4.3.2. emptyDir 볼륨

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

4.3.2.1. EmptyDir 확장 구성

kubernetes.podspec-volumes-emptydir 확장은 Knative Serving에서 emptyDir 볼륨을 사용할 수 있는지 여부를 제어합니다. 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에서 사용할 수 있는지 여부를 제어합니다.
  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.4. Init 컨테이너

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

참고

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

4.3.4.1. 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
    ...

4.3.5. 이미지 태그를 다이제스트로 해결

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

4.3.5.1. 태그-다이제스트 확인

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

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 Dedicated에 대한 클러스터 또는 전용 관리자 권한이 있습니다.
  • 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. TLS 인증 구성

TLS( Transport Layer Security )를 사용하여 Knative 트래픽을 암호화하고 인증에 사용할 수 있습니다.

TLS는 Knative Kafka에 지원되는 유일한 트래픽 암호화 방법입니다. Red Hat은 Knative Kafka 리소스에 SASL 및 TLS를 함께 사용하는 것이 좋습니다.

참고

Red Hat OpenShift Service Mesh 통합을 사용하여 내부 TLS를 활성화하려면 다음 절차에 설명된 내부 암호화 대신 mTLS를 사용하여 서비스 메시를 활성화해야 합니다.

4.3.6.1. 내부 트래픽에 TLS 인증 활성화

OpenShift Serverless는 기본적으로 TLS 엣지 종료를 지원하므로 최종 사용자의 HTTPS 트래픽이 암호화됩니다. 그러나 OpenShift 경로 뒤의 내부 트래픽은 일반 데이터를 사용하여 애플리케이션으로 전달됩니다. 내부 트래픽에 대해 TLS를 활성화하면 구성 요소 간에 전송되는 트래픽이 암호화되어 이 트래픽을 더 안전하게 보호할 수 있습니다.

참고

Red Hat OpenShift Service Mesh 통합을 사용하여 내부 TLS를 활성화하려면 다음 절차에 설명된 내부 암호화 대신 mTLS를 사용하여 서비스 메시를 활성화해야 합니다.

중요

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

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Serving이 설치되어 있습니다.
  • OpenShift(oc) CLI를 설치했습니다.

절차

  1. 사양에 internal-encryption: "true" 필드를 포함하는 Knative 서비스를 생성합니다.

    ...
    spec:
      config:
        network:
          internal-encryption: "true"
    ...
  2. knative-serving 네임스페이스에서 활성화기 Pod를 다시 시작하여 인증서를 로드합니다.

    $ oc delete pod -n knative-serving --selector app=activator

4.3.7. 제한적인 네트워크 정책

4.3.7.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.7.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.