서버리스

OpenShift Container Platform 4.8

OpenShift 서버리스 설치, 사용법, 릴리스 정보

초록

이 문서에서는 OpenShift Container Platform에서 OpenShift 서버리스를 사용하는 방법에 대한 정보를 제공합니다.

1장. OpenShift Serverless 릴리스 정보

OpenShift Serverless 기능 개요는 OpenShift Serverless 정보를 참조하십시오.

참고

OpenShift Serverless는 오픈 소스 Knative 프로젝트를 기반으로 합니다.

최신 Knative 구성 요소 릴리스에 대한 자세한 내용은 Knative 블로그를 참조하십시오.

1.1. API 버전 정보

OpenShift Serverless Operator는 최신 버전을 사용하기 위해 더 이상 사용되지 않는 API를 사용하는 이전 리소스를 자동으로 업그레이드합니다.

예를 들어 v1beta1과 같은 이전 ApiServerSource API 버전을 사용하는 리소스를 클러스터에 생성한 경우 OpenShift Serverless Operator는 사용 가능하고 v1beta1 버전이 더 이상 사용되지 않을 때 API의 v1 버전을 사용하도록 이러한 리소스를 자동으로 업데이트합니다.

더 이상 사용되지 않는 API의 이전 버전은 향후 릴리스에서 제거될 수 있습니다. 더 이상 사용되지 않는 API 버전을 사용해도 리소스가 실패하지 않습니다. 그러나 제거된 API 버전을 사용하려고 하면 리소스가 실패합니다. 문제를 방지하기 위해 최신 버전을 사용하도록 매니페스트가 업데이트되었는지 확인합니다.

1.2. Red Hat OpenShift Serverless 1.19.0 릴리스 정보

1.2.1. 새로운 기능

  • OpenShift Serverless에서 Knative Serving 0.25를 사용합니다.
  • OpenShift Serverless에서 Knative Eventing 0.25를 사용합니다.
  • OpenShift Serverless에서 Kourier 0.25를 사용합니다.
  • OpenShift Serverless에서 Knative kn CLI 0.25를 사용합니다.
  • OpenShift Serverless에서 Knative Kafka 0.25를 사용합니다.
  • kn func CLI 플러그인은 이제 func 0.19를 사용합니다.
  • KafkaBinding API는 OpenShift Serverless 1.19.0에서 더 이상 사용되지 않으며 향후 릴리스에서 제거됩니다.
  • HTTPS 리디렉션이 지원되고 클러스터 또는 각 Knative 서비스에 대해 전역적으로 구성할 수 있습니다.

1.2.2. 해결된 문제

  • 이전 릴리스에서 Kafka 채널 디스패처는 응답하기 전에 로컬 커밋이 성공할 때까지 대기했습니다. 이로 인해 Apache Kafka 노드 오류가 발생하는 경우 이벤트가 손실되었을 수 있습니다. Kafka 채널 디스패처는 응답하기 전에 모든 동기화 내부 복제본이 커밋될 때까지 기다립니다.

1.2.3. 확인된 문제

  • func 버전 0.19에서는 podman을 사용하여 일부 런타임에서 함수를 빌드할 수 없습니다. 다음과 유사한 오류 메시지가 표시될 수 있습니다.

    ERROR: failed to image: error during connect: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.40/info": EOF
    • 이 문제에 대한 다음 해결방법이 있습니다.

      1. 서비스 ExecStart 정의에 --time=0 을 추가하여 podman 서비스를 업데이트합니다.

        서비스 구성 예

        ExecStart=/usr/bin/podman $LOGGING system service --time=0

      2. 다음 명령을 실행하여 podman 서비스를 다시 시작합니다.

        $ systemctl --user daemon-reload
        $ systemctl restart --user podman.socket
    • 또는 TCP를 사용하여 podman API를 노출할 수 있습니다.

      $ podman system service --time=0 tcp:127.0.0.1:5534 &
      export DOCKER_HOST=tcp://127.0.0.1:5534

1.3. Red Hat OpenShift Serverless 1.18.0 릴리스 정보

1.3.1. 새로운 기능

  • OpenShift Serverless에서 Knative Serving 0.24.0을 사용합니다.
  • OpenShift Serverless에서 Knative Eventing 0.24.0을 사용합니다.
  • OpenShift Serverless에서 Kourier 0.24.0을 사용합니다.
  • OpenShift Serverless에서 Knative kn CLI 0.24.0을 사용합니다.
  • OpenShift Serverless에서 Knative Kafka 0.24.7을 사용합니다.
  • kn func CLI 플러그인은 이제 func 0.18.0을 사용합니다.
  • 향후 OpenShift Serverless 1.19.0 릴리스에서는 보안을 강화하기 위해 외부 경로의 URL 체계가 기본적으로 HTTPS로 설정됩니다.

    이 변경 사항을 워크로드에 적용하지 않으려면 1.19.0로 업그레이드하기 전에 다음 YAML을 KnativeServing CR(사용자 정의 리소스)에 추가하여 기본 설정을 덮어쓸 수 있습니다.

    ...
    spec:
      config:
        network:
          defaultExternalScheme: "http"
    ...

    변경 사항을 1.18.0에 이미 적용하려면 다음 YAML을 추가합니다.

    ...
    spec:
      config:
        network:
          defaultExternalScheme: "https"
    ...
  • 향후 OpenShift Serverless 1.19.0 릴리스에서는 Kourier Gateway가 노출되는 기본 서비스 유형은 LoadBalancer 가 아닌 ClusterIP 입니다.

    이 변경 사항을 워크로드에 적용하지 않으려면 1.19.0로 업그레이드하기 전에 다음 YAML을 KnativeServing CR(사용자 정의 리소스)에 추가하여 기본 설정을 덮어쓸 수 있습니다.

    ...
    spec:
      ingress:
        kourier:
          service-type: LoadBalancer
    ...
  • 이제 OpenShift Serverless에서 emptyDir 볼륨을 사용할 수 있습니다. 자세한 내용은 Knative Serving에 대한 OpenShift Serverless 설명서를 참조하십시오.
  • kn func 를 사용하여 함수를 생성할 때 회전 템플릿을 사용할 수 있습니다.

1.3.2. 해결된 문제

  • 이전 1.4 버전의 Camel-K는 OpenShift Serverless 1.17.0과 호환되지 않았습니다. Camel-K의 문제가 수정되었으며 Camel-K 버전 1.4.1은 OpenShift Serverless 1.17.0과 함께 사용할 수 있습니다.
  • 이전 버전에서는 Kafka 채널 또는 새 Kafka 소스에 대한 새 서브스크립션을 생성하는 경우 새로 생성된 서브스크립션 또는 싱크에서 ready 상태를 보고한 후 Kafka 데이터 플레인에서 메시지를 디스패치할 준비가 된 경우 Kafka 데이터 플레인에서 지연이 발생할 수 있었습니다.

    결과적으로 데이터 플레인에서 ready 상태를 보고하지 않은 시간 동안 구독자 또는 싱크로 전송되지 않았을 수 있었습니다.

    OpenShift Serverless 1.18.0에서는 문제가 수정되어 초기 메시지가 더 이상 손실되지 않습니다. 이 문제에 대한 자세한 내용은 Knowledgebase 문서 #6343981 을 참조하십시오.

1.3.3. 확인된 문제

  • Knative kn CLI의 이전 버전에서는 이전 버전의 Knative Serving 및 Knative Eventing API를 사용할 수 있습니다. 예를 들어 kn CLI의 버전 0.23.2는 v1alpha1 API 버전을 사용합니다.

    반면 최신 OpenShift Serverless 릴리스에서는 더 이상 이전 API 버전을 지원하지 않을 수 있습니다. 예를 들어 OpenShift Serverless 1.18.0에서는 더 이상 kafkasources.sources.knative.dev API의 버전 v1alpha1 을 지원하지 않습니다.

    결과적으로 이전 버전의 Knative kn CLI를 최신 OpenShift Serverless와 함께 사용하면 kn 에서 오래된 API를 찾을 수 없기 때문에 오류가 발생할 수 있습니다. 예를 들어 kn CLI 버전 0.23.2는 OpenShift Serverless 1.18.0에서 작동하지 않습니다.

    문제를 방지하려면 OpenShift Serverless 릴리스에 사용할 수 있는 최신 kn CLI 버전을 사용합니다. OpenShift Serverless 1.18.0의 경우 Knative kn CLI 0.24.0을 사용합니다.

1.4. Red Hat OpenShift Serverless 1.17.0 릴리스 정보

1.4.1. 새로운 기능

  • OpenShift Serverless에서 Knative Serving 0.23.0을 사용합니다.
  • OpenShift Serverless에서 Knative Eventing 0.23.0을 사용합니다.
  • OpenShift Serverless에서 Kourier 0.23.0을 사용합니다.
  • OpenShift Serverless에서 Knative kn CLI 0.23.0을 사용합니다.
  • OpenShift Serverless에서 Knative Kafka 0.23.0을 사용합니다.
  • kn func CLI 플러그인은 이제 func 0.17.0을 사용합니다.
  • 향후 OpenShift Serverless 1.19.0 릴리스에서는 보안을 강화하기 위해 외부 경로의 URL 체계가 기본적으로 HTTPS로 설정됩니다.

    이 변경 사항을 워크로드에 적용하지 않으려면 1.19.0로 업그레이드하기 전에 다음 YAML을 KnativeServing CR(사용자 정의 리소스)에 추가하여 기본 설정을 덮어쓸 수 있습니다.

    ...
    spec:
      config:
        network:
          defaultExternalScheme: "http"
    ...
  • mTLS 기능은 이제 GA(일반적으로 사용 가능)로 제공됩니다.
  • kn func를 사용하여 함수를 생성할 때 TypeScript 템플릿을 사용할 수 있습니다.
  • Knative Eventing 0.23.0의 API 버전 변경

    • OpenShift Serverless 버전 1.14.0에서 더 이상 사용되지 않는 KafkaChannel API의 v1alpha1 버전이 제거되었습니다. 구성 맵의 ChannelTemplateSpec 매개변수에 이 이전 버전에 대한 참조가 포함된 경우 올바른 API 버전을 사용하도록 사양의 이 부분을 업데이트해야 합니다.

1.4.2. 확인된 문제

  • 최신 OpenShift Serverless 릴리스에서 이전 버전의 Knative kn CLI를 사용하려는 경우 API를 찾을 수 없으며 오류가 발생합니다.

    예를 들어 Knative Serving 및 Knative Eventing API의 0.23.0 버전을 사용하는 1.17.0 OpenShift Serverless 릴리스와 함께 버전 0.22.0을 사용하는 kn CLI의 1.16.0 릴리스를 사용하는 경우 CLI가 오래된 0.22.0 API 버전을 계속 찾기 때문에 CLI가 작동하지 않습니다.

    문제를 방지하려면 OpenShift Serverless 릴리스에 최신 kn CLI 버전을 사용 중인지 확인합니다.

  • Kafka 채널 지표는 이 릴리스의 해당 웹 콘솔 대시보드에 모니터링되거나 표시되지 않습니다. 이는 Kafka 디스패처 조정 프로세스의 주요 변경 사항 때문입니다.
  • Kafka 채널 또는 새 Kafka 소스에 대한 새 서브스크립션을 생성하는 경우 새로 생성된 서브스크립션 또는 싱크에서 준비 상태를 보고한 후 Kafka 데이터 플레인에서 메시지를 디스패치할 준비가 되는데 지연이 있을 수 있습니다.

    결과적으로 데이터 플레인에서 ready 상태를 보고하지 않는 시간 동안 구독자 또는 싱크로 전송되는 메시지가 표시됩니다.

    이 문제 및 가능한 해결 방법에 대한 자세한 내용은 기술 문서 #6343981을 참조하십시오.

  • Camel-K 1.4 릴리스는 OpenShift Serverless 버전 1.17.0과 호환되지 않습니다. 이는 Camel-K 1.4에서 Knative 버전 0.23.0에서 제거된 API를 사용하기 때문입니다. 현재 이 문제에 대한 해결방법이 없습니다. OpenShift Serverless에서 Camel-K 1.4를 사용해야 하는 경우 OpenShift Serverless 버전 1.17.0으로 업그레이드하지 마십시오.

    참고

    이 문제가 해결되었으며 Camel-K 버전 1.4.1은 OpenShift Serverless 1.17.0과 호환됩니다.

1.5. Red Hat OpenShift Serverless 1.16.0 릴리스 정보

1.5.1. 새로운 기능

  • OpenShift Serverless에서 Knative Serving 0.22.0을 사용합니다.
  • OpenShift Serverless에서 Knative Eventing 0.22.0을 사용합니다.
  • OpenShift Serverless에서 Kourier 0.22.0을 사용합니다.
  • OpenShift Serverless에서 Knative kn CLI 0.22.0을 사용합니다.
  • OpenShift Serverless에서 Knative Kafka 0.22.0을 사용합니다.
  • kn func CLI 플러그인은 이제 func 0.16.0을 사용합니다.
  • kn func emit 명령이 kn 플러그인 함수에 추가되었습니다. 이 명령을 사용하여 이벤트를 보내 로컬에서 배포된 함수를 테스트할 수 있습니다.

1.5.2. 확인된 문제

  • OpenShift Serverless 1.16.0으로 업그레이드하기 전에 OpenShift Container Platform을 버전 4.6.30, 4.7.11 이상으로 업그레이드해야 합니다.
  • AMQ Streams Operator는 OpenShift Serverless Operator를 설치하거나 업그레이드하지 못할 수 있습니다. 이 경우 OLM(Operator Lifecycle Manager)에 의해 다음 오류가 발생합니다.

    WARNING: found multiple channel heads: [amqstreams.v1.7.2 amqstreams.v1.6.2], please check the `replaces`/`skipRange` fields of the operator bundles.

    OpenShift Serverless Operator를 설치하거나 업그레이드하기 전에 AMQ Streams Operator를 설치 제거하여 이 문제를 해결할 수 있습니다. 그런 다음 AMQ Streams Operator를 다시 설치할 수 있습니다.

  • Service Mesh가 mTLS를 사용하여 사용하도록 설정된 경우 Service Mesh가 Prometheus의 메트릭 스크랩을 허용하지 않기 때문에 기본적으로 Knative Serviceing에 대한 메트릭이 사용되지 않도록 설정됩니다. Service Mesh 및 mTLS에 사용하기 위해 Knative Serving 메트릭을 활성화하는 방법은 Serverless 문서의 "Service Mesh with OpenShift Serverless" 섹션을 참조하십시오.
  • Istio 수신이 활성화된 Service Mesh CR을 배포하는 경우 istio-ingressgateway Pod에 다음 경고가 표시될 수 있습니다.

    2021-05-02T12:56:17.700398Z warning envoy config [external/envoy/source/common/config/grpc_subscription_impl.cc:101] gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected: Error adding/updating listener(s) 0.0.0.0_8081: duplicate listener 0.0.0.0_8081 found

    Knative 서비스에 액세스할 수도 없습니다.

    다음 해결 방법을 사용하여 knative-local-gateway 서비스를 다시 생성하여 이 문제를 해결할 수 있습니다.

    1. istio-system 네임스페이스에서 기존 knative-local-gateway 서비스를 삭제합니다.

      $ oc delete services -n istio-system knative-local-gateway
    2. 다음 YAML이 포함된 knative-local-gateway 서비스를 생성하고 적용합니다.

      apiVersion: v1
      kind: Service
      metadata:
       name: knative-local-gateway
       namespace: istio-system
       labels:
         experimental.istio.io/disable-gateway-port-translation: "true"
      spec:
       type: ClusterIP
       selector:
         istio: ingressgateway
       ports:
         - name: http2
           port: 80
           targetPort: 8081
  • 클러스터에 1000개의 Knative 서비스가 있는 경우 Knative Serving 재설치 또는 업그레이드를 수행하면 KnativeServing CR(사용자 정의 리소스)이 Ready 상태가 되면 처음 새 서비스를 생성할 때 지연이 발생합니다.

    3scale-kourier-control 서비스는 새 서비스를 처리하기 전에 기존의 모든 Knative 서비스를 조정하므로 새 서비스가 상태가 Ready로 업데이트되기 전에 IngressNotConfigured 또는 Unknown 상태에서 약 800초를 사용합니다.

  • Kafka 채널 또는 새 Kafka 소스에 대한 새 서브스크립션을 생성하는 경우 새로 생성된 서브스크립션 또는 싱크에서 준비 상태를 보고한 후 Kafka 데이터 플레인에서 메시지를 디스패치할 준비가 되는데 지연이 있을 수 있습니다.

    결과적으로 데이터 플레인에서 ready 상태를 보고하지 않는 시간 동안 구독자 또는 싱크로 전송되는 메시지가 표시됩니다.

    이 문제 및 가능한 해결 방법에 대한 자세한 내용은 기술 문서 #6343981을 참조하십시오.

2장. 검색

2.1. About OpenShift Serverless

OpenShift Serverless는 개발자의 인프라 설정 또는 백엔드 개발 필요성을 줄임으로써 개발에서 프로덕션으로 코드를 전달하는 프로세스를 간소화합니다.

OpenShift Serverless의 개발자는 제공된 Kubernetes 네이티브 API(Knative Serving 및 Eventing)와 친숙한 언어 및 프레임워크를 사용하여 애플리케이션 및 컨테이너 워크로드를 배포할 수 있습니다.

OpenShift Serverless는 엔터프라이즈급 서버리스 플랫폼을 활성화하여 하이브리드 및 다중 클라우드 환경에 이식성 및 일관성을 제공하는 오픈 소스 Knative 프로젝트를 기반으로 합니다.

2.1.1. 지원되는 구성

OpenShift Serverless에 지원되는 일련의 기능, 구성, 통합과 현재 버전 및 이전 버전은 지원되는 구성 페이지에서 확인할 수 있습니다.

2.1.2. Knative Serving

OpenShift Container Platform의 Knative Serving을 사용하면 개발자가 서버리스 아키텍처를 사용하여 클라우드 네이티브 애플리케이션을 작성할 수 있습니다.

Knative Serving은 클라우드 네이티브 애플리케이션 배포 및 관리를 지원합니다. OpenShift Container Platform 클러스터에서 서버리스 워크로드의 동작을 정의 및 제어하는 Kubernetes CRD(사용자 정의 리소스 정의)로 오브젝트 세트를 제공합니다.

개발자는 이러한 CRD를 사용하여 복잡한 사용 사례를 다룰 때 구성 요소로 사용할 수 있는 CR(사용자 정의 리소스) 인스턴스를 생성합니다. 예를 들면 다음과 같습니다.

  • 신속한 서버리스 컨테이너 배포.
  • Pod 자동 스케일링.

2.1.3. Knative Eventing

OpenShift Container Platform에서 Knative Eventing을 사용하면 개발자가 서버리스 애플리케이션에 이벤트 중심 아키텍처를 사용할 수 있습니다.

이벤트 중심 아키텍처는 이벤트 생산자와 이벤트 소비자 간의 분리된 관계 개념을 기반으로 합니다. 이벤트 생산자는 이벤트를 생성하고 이벤트 싱크 또는 소비자가 이벤트를 수신합니다.

Knative Eventing은 표준 HTTP POST 요청을 사용하여 이벤트 프로듀서와 싱크 사이에서 이벤트를 전송하고 수신합니다. 이러한 이벤트는 이벤트를 모든 프로그래밍 언어로 생성, 구문 분석, 전송, 수신할 수 있도록 CloudEvents 사양을 준수합니다.

Knative Eventing에서는 다음 유스 케이스를 지원합니다.

소비자를 생성하지 않고 이벤트 게시
이벤트를 HTTP POST에 브로커로 보내고 바인딩을 사용하여 이벤트를 생성하는 애플리케이션에서 대상 구성을 분리할 수 있습니다.
게시자를 생성하지 않고 이벤트 사용
트리거를 사용하면 이벤트 특성을 기반으로 브로커의 이벤트를 사용할 수 있습니다. 애플리케이션은 이벤트를 HTTP POST로 수신합니다.

2.1.4. 추가 리소스

2.2. OpenShift Serverless Functions 정보

중요

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

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

OpenShift Serverless Functions를 사용하면 개발자가 상태 비저장 이벤트 중심 함수를 OpenShift Container Platform에서 Knative 서비스로 생성하고 배포할 수 있습니다.

kn func CLI는 Knative kn CLI의 플러그인으로 제공됩니다. OpenShift Serverless Function은 KialiF Buildpack API를 사용하여 컨테이너 이미지를 생성합니다. 컨테이너 이미지가 생성되면 kn func CLI를 사용하여 컨테이너 이미지를 클러스터에 Knative 서비스로 배포할 수 있습니다.

2.2.1. 지원되는 런타임

OpenShift Serverless Functions는 다음 런타임에 대한 기본 기능을 생성하는 데 사용할 수 있는 템플릿을 제공합니다.

2.2.2. 다음 단계

2.3. Knative Serving 구성 요소

Service
service.serving.knative.dev CRD를 사용하면 워크로드의 라이프사이클을 자동으로 관리하여 네트워크를 통해 애플리케이션을 배포하고 연결할 수 있습니다. 이 CRD는 사용자 생성 서비스 또는 사용자 정의 리소스가 변경될 때마다 경로, 구성, 새 버전을 생성합니다. Knative의 개발자 상호 작용은 대부분 서비스 수정을 통해 수행됩니다.
버전
revision.serving.knative.dev CRD는 워크로드에 수행된 각 수정의 코드 및 구성에 대한 시점 스냅샷입니다. 버전은 변경할 수 없는 오브젝트이며 필요한 기간에 유지할 수 있습니다.
Route
route.serving.knative.dev CRD는 네트워크 끝점을 하나 이상의 버전에 매핑합니다. 부분 트래픽 및 이름이 지정된 경로를 포함하여 다양한 방법으로 트래픽을 관리할 수 있습니다.
설정
configuration.serving.knative.dev CRD는 배포에 필요한 상태를 유지 관리합니다. 코드와 구성을 명확하게 분리합니다. 구성을 수정하면 새 버전이 생성됩니다.

2.4. Knative Eventing 구성 요소

Knative Eventing에서는 다양한 싱크 유형으로 전달할 수 있도록 다음과 같이 여러 Kubernetes 리소스에서 구현할 수 있는 일반 인터페이스를 정의합니다.

주소 지정 가능 리소스
HTTP를 통해 전달되는 이벤트를 이벤트의 status.address.url 필드에 정의된 주소로 수신 및 승인할 수 있습니다. Kubernetes Service 리소스도 주소 지정 가능 인터페이스의 조건을 충족합니다.
호출 가능한 리소스
HTTP를 통해 전달되는 이벤트를 수신하고 변환하여 HTTP 응답 페이로드에서 0 또는 1개의 새 이벤트를 반환합니다. 반환된 이벤트는 외부 이벤트 소스의 이벤트를 처리하는 것과 동일한 방식으로 추가로 처리할 수 있습니다.

다음을 사용하여 이벤트 소스의 이벤트를 여러 이벤트에 전달할 수 있습니다.

2.5. 이벤트 소스

Knative 이벤트 소스는 클라우드 이벤트를 생성하거나 가져오는 모든 Kubernetes 오브젝트일 수 있으며sink라는 다른 엔드포인트로 해당 이벤트를 릴레이할 수 있습니다. 이벤트에 대응하는 분산 시스템을 개발하는 데 소싱 이벤트가 중요합니다.

OpenShift Container Platform 웹 콘솔의 개발자 화면 및 kn CLI를 사용하거나 YAML 파일을 적용하여 Knative 이벤트 소스를 생성 및 관리할 수 있습니다.

현재 OpenShift Serverless에서는 다음 이벤트 소스 유형을 지원합니다.

API 서버 소스
Kubernetes API 서버 이벤트를 Knative로 가져옵니다. API 서버 소스는 Kubernetes 리소스가 생성, 업데이트 또는 삭제될 때마다 새 이벤트를 전송합니다.
ping 소스
지정된 cron 일정에 고정된 페이로드를 사용하여 이벤트를 생성합니다.
Kafka 소스
Kafka 클러스터를 이벤트 소스로 싱크에 연결합니다.

사용자 지정 이벤트 소스를 생성할 수도 있습니다.

2.6. 채널

채널은 단일 이벤트 전달 및 지속성 계층을 정의하는 사용자 정의 리소스입니다.

채널 워크플로 개요

이벤트 소스 또는 생산자에서 채널로 이벤트를 보낸 후에는 서브스크립션을 통해 이러한 이벤트를 여러 Knative 서비스 또는 기타 싱크로 보낼 수 있습니다.

InMemoryChannelKafkaChannel 채널 구현은 OpenShift Serverless에서 개발을 위해 사용할 수 있습니다.

다음은 InMemoryChannel 유형 채널에 대한 제한 사항입니다.

  • 이벤트 지속성은 제공되지 않습니다. Pod가 다운되면 해당 Pod의 이벤트도 손실됩니다.
  • InMemoryChannel 채널에서는 이벤트에 순서를 지정하지 않으므로 해당 채널에서 두 개의 이벤트를 동시에 수신하는 경우 이벤트를 순서와 관계없이 구독자에게 전달할 수 있습니다.
  • 구독자가 이벤트를 거부하면 기본적으로 재전송을 시도하지 않습니다. Subscription 오브젝트의 delivery 사양을 수정하여 재전송 시도 횟수를 구성할 수 있습니다.

2.6.1. 다음 단계

3장. 설치

3.1. OpenShift Serverless Operator 설치

이 안내서에서는 클러스터 관리자에게 OpenShift Container Platform 클러스터에 OpenShift Serverless Operator를 설치하는 방법을 안내합니다.

참고

OpenShift Serverless는 제한된 네트워크 환경에서 설치할 수 있습니다. 자세한 내용은 제한된 네트워크에서 Operator Lifecycle Manager 사용을 참조하십시오.

3.1.1. OpenShift Serverless 설치를 위해 클러스터 크기 요구 사항 정의

OpenShift Serverless를 설치하고 사용하려면 OpenShift Container Platform 클러스터의 크기를 올바르게 조정해야 합니다.

참고

다음 요구 사항은 OpenShift Container Platform 클러스터의 작업자 머신 풀에만 관련이 있습니다. 컨트롤 플레인 노드는 일반 스케줄링에 사용되지 않으며 요구 사항에서 생략됩니다.

OpenShift Serverless를 실행하는 총 크기 요구 사항은 배포된 애플리케이션에 따라 다릅니다. 기본적으로 각 Pod는 약 400m의 CPU를 요청하므로 최소 요구 사항은 이 값을 기반으로 합니다. 애플리케이션의 실제 CPU 요청을 줄이면 가능한 복제본 수를 늘릴 수 있습니다.

클러스터에 HA(고가용성)를 활성화하면 Knative Serving 컨트롤 플레인을 복제할 때마다 0.5 ~ 1.5코어 및 200MB ~ 2GB의 메모리가 필요합니다.

HA는 기본적으로 일부 Knative Serving 구성 요소에 사용됩니다. OpenShift Serverless의 고가용성 복제본 구성 설명서의 지침에 따라 HA를 비활성화할 수 있습니다.

3.1.2. 머신 세트를 사용하여 클러스터 스케일링

OpenShift Container Platform MachineSet API를 사용하여 클러스터를 원하는 크기로 수동으로 확장할 수 있습니다. 최소 요구 사항은 일반적으로 기본 머신 세트 중 하나를 두 개의 추가 머신으로 확장해야 한다는 것입니다. 머신 세트 수동 스케일링을 참조하십시오.

3.1.3. OpenShift Serverless Operator 설치

다음 절차에서는 OpenShift Container Platform 웹 콘솔을 사용하여 OperatorHub에서 OpenShift Serverless Operator에 설치 및 등록하는 방법을 설명합니다.

중요

최신 Serverless 릴리스로 업그레이드하기 전에 이전에 설치한 커뮤니티 Knative Eventing Operator가 있는 경우 이를 제거해야 합니다. Knative Eventing Operator를 설치하면 OpenShift Serverless Operator를 사용하여 최신 버전의 Knative Eventing을 설치할 수 없습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 OperatorOperatorHub 페이지로 이동합니다.
  2. 스크롤하거나 키워드로 필터링 상자에 키워드 서버리스를 입력하여 OpenShift Serverless Operator를 찾습니다.
  3. Operator에 대한 정보를 검토하고 설치를 클릭합니다.
  4. Operator 설치 페이지에서 다음을 수행합니다.

    1. 설치 모드클러스터의 모든 네임스페이스(기본값)입니다. 이 모드에서는 클러스터의 모든 네임스페이스를 감시하고 사용할 수 있도록 기본 openshift-serverless 네임스페이스에 Operator를 설치합니다.
    2. 설치된 네임스페이스openshift-serverless입니다.
    3. stable 채널을 업데이트 채널로 선택합니다. stable 채널을 사용하면 안정적인 최신 릴리스의 OpenShift Pipelines Operator를 설치할 수 있습니다.
    4. 자동 또는 수동 승인 전략을 선택합니다.
  5. 이 OpenShift Container Platform 클러스터에서 선택한 네임스페이스에서 Operator를 사용할 수 있도록 하려면 설치를 클릭합니다.
  6. 카탈로그Operator 관리 페이지에서 OpenShift Serverless Operator 서브스크립션 설치 및 업그레이드 진행 상황을 모니터링할 수 있습니다.

    1. 수동 승인 전략을 선택한 경우 설치 계획을 검토하고 승인할 때까지 서브스크립션의 업그레이드 상태가 업그레이드 중으로 유지됩니다. 설치 계획 페이지에서 승인한 후 subscription 업그레이드 상태가 최신으로 이동합니다.
    2. 자동 승인 전략을 선택한 경우 업그레이드 상태가 개입 없이 최신 상태로 확인되어야 합니다.

검증

서브스크립션의 업그레이드 상태가 최신인 경우 카탈로그설치된 Operator를 선택하여 OpenShift Serverless Operator가 표시되고 관련 네임스페이스에서 상태가 최종적으로 InstallSucceeded로 표시되는지 확인합니다.

그러지 않은 경우 다음을 수행합니다.

  1. 카탈로그Operator 관리 페이지로 전환한 후 Operator 서브스크립션설치 계획 탭의 상태에 장애나 오류가 있는지 검사합니다.
  2. 워크로드Pod 페이지의 openshift-serverless 프로젝트에서 문제를 보고하는 Pod의 로그를 확인하여 추가로 문제를 해결합니다.

3.1.4. 다음 단계

  • OpenShift Serverless Operator를 설치한 후에는 Knative Serving 구성 요소를 설치할 수 있습니다. Knative Serving 설치 설명서를 참조하십시오.
  • OpenShift Serverless Operator를 설치한 후에는 Knative Eventing 구성 요소를 설치할 수 있습니다. Knative Eventing 설치 설명서를 참조하십시오.

3.2. Knative Serving 설치

OpenShift Serverless Operator를 설치한 후에는 Knative Serving을 설치할 수 있습니다.

이 가이드에서는 기본 설정을 사용하여 Knative Serving을 설치하는 방법에 대한 정보를 제공합니다. 그러나 KnativeServing CRD(사용자 정의 리소스 정의)에서 고급 설정을 추가로 구성할 수 있습니다. KnativeServing CRD의 구성 옵션에 대한 자세한 내용은 Knative Serving 고급 구성 옵션을 참조하십시오.

3.2.1. 사전 요구 사항

  • 클러스터 관리자 액세스 권한이 있는 OpenShift Container Platform 계정에 액세스할 수 있습니다.
  • OpenShift Serverless Operator를 설치했습니다.

3.2.2. 웹 콘솔을 사용하여 Knative Serving 설치

프로세스

  1. OpenShift Container Platform 웹 콘솔의 관리자 화면에서 Operator설치된 Operator로 이동합니다.
  2. 페이지 상단에 있는 프로젝트 드롭다운이 Project: knative-serving으로 설정되어 있는지 확인합니다.
  3. OpenShift Serverless Operator의 제공되는 API 목록에서 Knative Serving을 클릭하여 Knative Serving 탭으로 이동합니다.
  4. Knative Serving 생성을 클릭합니다.
  5. Knative Serving 생성 페이지에서 생성을 클릭하면 기본 설정을 사용하여 Knative Serving을 설치할 수 있습니다.

    제공된 양식을 사용하여 KnativeServing 오브젝트를 편집하거나 YAML을 편집하여 Knative Serving 설치에 대한 설정을 수정할 수도 있습니다.

    • 해당 양식은 KnativeServing 오브젝트 생성을 완전히 제어할 필요가 없는 단순한 구성에 사용하는 것이 좋습니다.
    • KnativeServing 오브젝트 생성을 완전히 제어해야 하는 복잡한 구성의 경우 YAML을 편집하는 것이 좋습니다. Knative Serving 생성 페이지의 오른쪽 상단에 있는 YAML 편집 링크를 클릭하여 YAML에 액세스할 수 있습니다.

      양식을 작성하거나 YAML을 수정한 후 생성을 클릭합니다.

      참고

      KnativeServing 사용자 정의 리소스 정의의 구성 옵션에 대한 자세한 내용은 고급 설치 구성 옵션 설명서를 참조하십시오.

  6. Knative Serving이 설치되면 KnativeServing 오브젝트가 생성되고 Knative Serving 탭으로 자동으로 이동합니다. 리소스 목록에 knative-serving 사용자 정의 리소스가 표시됩니다.

검증

  1. Knative Serving 탭에서 knative-serving 사용자 정의 리소스를 클릭합니다.
  2. 그러면 Knative Serving 개요 페이지로 자동으로 이동합니다.

    설치된 Operator 페이지
  3. 조건 목록을 보려면 아래로 스크롤합니다.
  4. 예제 이미지에 표시된 대로 상태가 True인 조건 목록이 표시되어야 합니다.

    조건
    참고

    Knative Serving 리소스를 생성하는 데 몇 초가 걸릴 수 있습니다. 리소스 탭에서 해당 상태를 확인할 수 있습니다.

  5. 조건이 알 수 없음 또는 False 상태인 경우 몇 분 정도 기다렸다가 리소스가 생성된 것을 확인한 후 다시 확인하십시오.

3.2.3. YAML을 사용하여 Knative Serving 설치

프로세스

  1. serving.yaml이라는 파일을 생성하고 다음 예제 YAML을 이 파일에 복사합니다.

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeServing
    metadata:
        name: knative-serving
        namespace: knative-serving
  2. serving.yaml 파일을 적용합니다.

    $ oc apply -f serving.yaml

검증

  1. 설치가 완료되었는지 확인하려면 다음 명령을 입력합니다.

    $ oc get knativeserving.operator.knative.dev/knative-serving -n knative-serving --template='{{range .status.conditions}}{{printf "%s=%s\n" .type .status}}{{end}}'

    출력 예

    DependenciesInstalled=True
    DeploymentsAvailable=True
    InstallSucceeded=True
    Ready=True

    참고

    Knative Serving 리소스를 생성하는 데 몇 초가 걸릴 수 있습니다.

    조건이 알 수 없음 또는 False 상태인 경우 몇 분 정도 기다렸다가 리소스가 생성된 것을 확인한 후 다시 확인하십시오.

  2. Knative Serving 리소스가 생성되었는지 확인합니다.

    $ oc get pods -n knative-serving

    출력 예

    NAME                                                        READY   STATUS      RESTARTS   AGE
    activator-67ddf8c9d7-p7rm5                                  2/2     Running     0          4m
    activator-67ddf8c9d7-q84fz                                  2/2     Running     0          4m
    autoscaler-5d87bc6dbf-6nqc6                                 2/2     Running     0          3m59s
    autoscaler-5d87bc6dbf-h64rl                                 2/2     Running     0          3m59s
    autoscaler-hpa-77f85f5cc4-lrts7                             2/2     Running     0          3m57s
    autoscaler-hpa-77f85f5cc4-zx7hl                             2/2     Running     0          3m56s
    controller-5cfc7cb8db-nlccl                                 2/2     Running     0          3m50s
    controller-5cfc7cb8db-rmv7r                                 2/2     Running     0          3m18s
    domain-mapping-86d84bb6b4-r746m                             2/2     Running     0          3m58s
    domain-mapping-86d84bb6b4-v7nh8                             2/2     Running     0          3m58s
    domainmapping-webhook-769d679d45-bkcnj                      2/2     Running     0          3m58s
    domainmapping-webhook-769d679d45-fff68                      2/2     Running     0          3m58s
    storage-version-migration-serving-serving-0.26.0--1-6qlkb   0/1     Completed   0          3m56s
    webhook-5fb774f8d8-6bqrt                                    2/2     Running     0          3m57s
    webhook-5fb774f8d8-b8lt5                                    2/2     Running     0          3m57s

  3. 필요한 네트워킹 구성 요소가 자동으로 생성된 knative-serving-ingress 네임스페이스에 설치되었는지 확인합니다.

    $ oc get pods -n knative-serving-ingress

    출력 예

    NAME                                      READY   STATUS    RESTARTS   AGE
    net-kourier-controller-7d4b6c5d95-62mkf   1/1     Running   0          76s
    net-kourier-controller-7d4b6c5d95-qmgm2   1/1     Running   0          76s
    3scale-kourier-gateway-6688b49568-987qz   1/1     Running   0          75s
    3scale-kourier-gateway-6688b49568-b5tnp   1/1     Running   0          75s

3.2.4. Knative Serving 고급 구성 옵션

이 섹션에서는 Knative Serving의 고급 구성 옵션에 대해 설명합니다.

3.2.4.1. 컨트롤러 사용자 정의 인증서

레지스트리에서 자체 서명된 인증서를 사용하는 경우 구성 맵 또는 보안을 생성하여 태그-다이제스트 확인을 사용해야 합니다. 태그-다이제스트 확인을 사용하려면 Knative Serving 컨트롤러에서 컨테이너 레지스트리에 액세스해야 합니다.

다음 예제 KnativeServing 사용자 정의 리소스 구성에서는 knative-serving 네임스페이스의 certs라는 구성 맵의 인증서를 사용합니다. 이 예제에서는 OpenShift Serverless Operator에서 다음을 수행하도록 트리거합니다.

  1. 컨트롤러에 인증서가 포함된 볼륨을 생성하고 마운트합니다.
  2. 필요한 환경 변수를 적절하게 설정합니다.

YAML의 예

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  controller-custom-certs:
    name: config-service-ca
    type: ConfigMap 1

1
지원되는 유형은 ConfigMapSecret입니다.

컨트롤러 사용자 정의 인증서가 지정되지 않은 경우 이 설정은 기본적으로 config-service-ca 구성 맵을 사용합니다.

태그-다이제스트 확인이 활성화되면 OpenShift Serverless Operator에서 레지스트리에 대한 Knative Serving 컨트롤러 액세스 권한을 자동으로 설정합니다.

중요

구성 맵 또는 보안은 Knative Serving CRD(사용자 정의 리소스 정의)와 동일한 네임스페이스에 있어야 합니다.

3.2.4.2. 고가용성

고가용성은 spec.high-availability 필드를 사용하여 구성할 수 있으며 사용자가 Knative Serving 설치 중 복제본 수를 지정하지 않으면 기본적으로 컨트롤러당 복제본 2개로 설정됩니다.

고가용성을 비활성화하려면 이 값을 1로 설정하고 복제본을 추가하려면 더 높은 정수로 설정합니다.

YAML의 예

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  high-availability:
    replicas: 2

3.2.5. 다음 단계

  • OpenShift Serverless에서 클라우드 이벤트 기능을 사용하려면 Knative Eventing 구성 요소를 설치하면 됩니다. Knative Eventing 설치 설명서를 참조하십시오.

3.3. Knative Eventing 설치

OpenShift Serverless Operator를 설치한 후에는 이 가이드에 설명된 절차에 따라 Knative Eventing을 설치할 수 있습니다.

이 가이드에서는 기본 설정을 사용하여 Knative Eventing을 설치하는 방법에 대한 정보를 제공합니다.

3.3.1. 사전 요구 사항

  • 클러스터 관리자 액세스 권한이 있는 OpenShift Container Platform 계정에 액세스할 수 있습니다.
  • OpenShift Serverless Operator를 설치했습니다.

3.3.2. 웹 콘솔을 사용하여 Knative Eventing 설치

프로세스

  1. OpenShift Container Platform 웹 콘솔의 관리자 화면에서 Operator설치된 Operator로 이동합니다.
  2. 페이지 상단에 있는 프로젝트 드롭다운이 Project: knative-eventing으로 설정되어 있는지 확인합니다.
  3. OpenShift Serverless Operator의 제공되는 API 목록에서 Knative Eventing을 클릭하여 Knative Eventing 탭으로 이동합니다.
  4. Knative Eventing 생성을 클릭합니다.
  5. Knative Eventing 생성 페이지에서 제공된 기본 양식을 사용하거나 YAML을 편집하여 KnativeEventing 오브젝트를 구성하도록 선택할 수 있습니다.

    • 해당 양식은 KnativeEventing 오브젝트 생성을 완전히 제어할 필요가 없는 단순한 구성에 사용하는 것이 좋습니다.

      선택 사항입니다. 양식을 사용하여 KnativeEventing 오브젝트를 구성하는 경우 Knative Eventing 배포에 구현하려는 변경을 수행합니다.

  6. 생성을 클릭합니다.

    • KnativeEventing 오브젝트 생성을 완전히 제어해야 하는 복잡한 구성의 경우 YAML을 편집하는 것이 좋습니다. Knative Eventing 생성 페이지의 오른쪽 상단에 있는 YAML 편집 링크를 클릭하여 YAML에 액세스할 수 있습니다.

      선택 사항입니다. YAML을 편집하여 KnativeEventing 오브젝트를 구성하는 경우 YAML에 Knative Eventing 배포에 구현하려는 변경을 수행합니다.

  7. 생성을 클릭합니다.
  8. Knative Eventing이 설치되면 KnativeEventing 오브젝트가 생성되고 Knative Eventing 탭으로 자동으로 이동합니다. 리소스 목록에 knative-eventing 사용자 정의 리소스가 표시됩니다.

검증

  1. Knative Eventing 탭에서 knative-eventing 사용자 정의 리소스를 클릭합니다.
  2. 그러면 Knative Eventing 개요 페이지로 자동으로 이동합니다.

    Knative Eventing 개요 페이지
  3. 조건 목록을 보려면 아래로 스크롤합니다.
  4. 예제 이미지에 표시된 대로 상태가 True인 조건 목록이 표시되어야 합니다.

    조건
    참고

    Knative Eventing 리소스를 생성하는 데 몇 초가 걸릴 수 있습니다. 리소스 탭에서 해당 상태를 확인할 수 있습니다.

  5. 조건이 알 수 없음 또는 False 상태인 경우 몇 분 정도 기다렸다가 리소스가 생성된 것을 확인한 후 다시 확인하십시오.

3.3.3. YAML을 사용하여 Knative Eventing 설치

프로세스

  1. eventing.yaml이라는 파일을 생성합니다.
  2. 다음 샘플 YAML을 eventing.yaml에 복사합니다.

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeEventing
    metadata:
        name: knative-eventing
        namespace: knative-eventing
  3. 선택 사항입니다. Knative Eventing 배포를 위해 구현하려는 YAML을 변경합니다.
  4. 다음을 입력하여 eventing.yaml 파일을 적용합니다.

    $ oc apply -f eventing.yaml

검증

  1. 다음 명령을 입력하고 출력을 관찰하여 설치가 완료되었는지 확인합니다.

    $ oc get knativeeventing.operator.knative.dev/knative-eventing \
      -n knative-eventing \
      --template='{{range .status.conditions}}{{printf "%s=%s\n" .type .status}}{{end}}'

    출력 예

    InstallSucceeded=True
    Ready=True

    참고

    Knative Eventing 리소스를 생성하는 데 몇 초가 걸릴 수 있습니다.

  2. 조건이 알 수 없음 또는 False 상태인 경우 몇 분 정도 기다렸다가 리소스가 생성된 것을 확인한 후 다시 확인하십시오.
  3. 다음을 입력하여 Knative Eventing 리소스가 생성되었는지 확인합니다.

    $ oc get pods -n knative-eventing

    출력 예

    NAME                                   READY   STATUS    RESTARTS   AGE
    broker-controller-58765d9d49-g9zp6     1/1     Running   0          7m21s
    eventing-controller-65fdd66b54-jw7bh   1/1     Running   0          7m31s
    eventing-webhook-57fd74b5bd-kvhlz      1/1     Running   0          7m31s
    imc-controller-5b75d458fc-ptvm2        1/1     Running   0          7m19s
    imc-dispatcher-64f6d5fccb-kkc4c        1/1     Running   0          7m18s

3.4. OpenShift Serverless 제거

이 가이드에서는 OpenShift Serverless Operator 및 기타 OpenShift Serverless 구성 요소를 제거하는 방법을 자세히 설명합니다.

참고

OpenShift Serverless Operator를 제거하려면 먼저 Knative Serving 및 Knative Eventing을 제거해야 합니다.

3.4.1. Knative Serving 설치 제거

Knative Serving을 설치 제거하려면 사용자 정의 리소스를 제거하고 knative-serving 네임스페이스를 삭제해야 합니다.

프로세스

  1. knative-serving 사용자 정의 리소스를 삭제합니다.

    $ oc delete knativeservings.operator.knative.dev knative-serving -n knative-serving
  2. 명령이 완료되고 knative-serving 네임스페이스에서 모든 Pod가 제거되면 네임스페이스를 삭제합니다.

    $ oc delete namespace knative-serving

3.4.2. Knative Eventing 설치 제거

Knative Eventing을 설치 제거하려면 사용자 정의 리소스를 제거하고 knative-eventing 네임스페이스를 삭제해야 합니다.

절차

  1. knative-eventing 사용자 정의 리소스를 삭제합니다.

    $ oc delete knativeeventings.operator.knative.dev knative-eventing -n knative-eventing
  2. 명령이 완료되고 knative-eventing 네임스페이스에서 모든 Pod가 제거된 후 네임스페이스를 삭제합니다.

    $ oc delete namespace knative-eventing

3.4.3. OpenShift Serverless Operator 제거

클러스터에서 Operator 삭제 설명서의 지침에 따라 호스트 클러스터에서 OpenShift Serverless Operator를 제거할 수 있습니다.

3.4.4. OpenShift Serverless 사용자 정의 리소스 정의 삭제

OpenShift Serverless를 설치 제거해도 Operator 및 API CRD(사용자 정의 리소스 정의)는 클러스터에 남아 있습니다. 다음 절차를 사용하여 남아 있는 CRD를 제거할 수 있습니다.

중요

Operator 및 API CRD를 제거하면 Knative 서비스를 포함하여 이를 사용하여 정의한 리소스도 모두 제거됩니다.

사전 요구 사항

  • Knative Serving을 설치 제거하고 OpenShift Serverless Operator를 제거했습니다.

절차

  • 남아 있는 OpenShift Serverless CRD를 삭제하려면 다음 명령을 입력합니다.

    $ oc get crd -oname | grep 'knative.dev' | xargs oc delete

4장. update

이전 버전의 OpenShift Serverless를 설치한 경우 이 가이드의 지침에 따라 최신 버전으로 업데이트할 수 있습니다.

중요

이전에 커뮤니티 Knative Eventing Operator를 설치한 경우 OpenShift Serverless Operator를 사용하여 최신 버전의 Knative Eventing을 설치하기 전에 이 Operator를 제거해야 합니다.

4.1. 서브스크립션 채널 업그레이드

사전 요구 사항

  • 이전 버전의 OpenShift Serverless Operator를 설치하고 설치 프로세스 중 자동 업데이트를 선택했습니다.

    참고

    수동 업데이트를 선택한 경우 이 가이드에 설명된 대로 채널을 업데이트한 후 추가 단계를 완료해야 합니다. 서브스크립션의 업그레이드 상태는 설치 계획을 검토하고 승인할 때까지 업그레이드 중으로 유지됩니다. 설치 계획에 대한 내용은 OpenShift Container Platform Operator 설명서에서 확인할 수 있습니다.

  • OpenShift Container Platform 웹 콘솔에 로그인했습니다.

절차

  1. OpenShift Container Platform 웹 콘솔에서 openshift-operators 네임스페이스를 선택합니다.
  2. Operator설치된 Operator 페이지로 이동합니다.
  3. OpenShift Serverless Operator를 선택합니다.
  4. 서브스크립션채널을 클릭합니다.
  5. 서브스크립션 업데이트 채널 변경 창에서 stable을 선택하고 저장을 클릭합니다.
  6. knative-serving 네임스페이스의 모든 Pod가 업그레이드되고 KnativeServing 사용자 정의 리소스가 최신 버전의 Knative Serving 상태로 보고될 때까지 기다립니다.

검증

업그레이드가 성공했는지 확인하려면 knative-serving 네임스페이스의 Pod 상태 및 KnativeServing 사용자 정의 리소스의 버전을 확인하면 됩니다.

  1. Pod 상태를 확인합니다.

    $ oc get knativeserving.operator.knative.dev knative-serving -n knative-serving -o=jsonpath='{.status.conditions[?(@.type=="Ready")].status}'

    이 명령에서 상태 True를 반환해야 합니다.

  2. KnativeServing 사용자 정의 리소스의 버전을 확인합니다.

    $ oc get knativeserving.operator.knative.dev knative-serving -n knative-serving -o=jsonpath='{.status.version}'

    이 명령에서는 최신 버전의 Knative Serving을 반환해야 합니다. 최신 버전은 OpenShift Serverless Operator 릴리스 노트에서 확인할 수 있습니다.

5장. 개발

5.1. 서버리스 애플리케이션

OpenShift Serverless를 사용하여 서버리스 애플리케이션을 배포하려면 Knative 서비스를 생성해야 합니다. Knative 서비스는 경로 및 구성으로 정의되고 YAML 파일에 포함된 Kubernetes 서비스입니다.

Knative 서비스 YAML의 예

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: hello 1
  namespace: default 2
spec:
  template:
    spec:
      containers:
        - image: docker.io/openshift/hello-openshift 3
          env:
            - name: RESPONSE 4
              value: "Hello Serverless!"

1
애플리케이션 이름입니다.
2
애플리케이션에서 사용하는 네임스페이스입니다.
3
애플리케이션 이미지입니다.
4
샘플 애플리케이션에서 출력한 환경 변수입니다.

5.1.1. 서버리스 애플리케이션 생성

다음 방법 중 하나를 사용하여 서버리스 애플리케이션을 생성합니다.

5.1.1.1. Knative CLI를 사용하여 서버리스 애플리케이션 생성

다음 절차에서는 kn CLI를 사용하여 기본 서버리스 애플리케이션을 생성하는 방법을 설명합니다.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Serving이 클러스터에 설치되어 있습니다.
  • kn CLI를 설치했습니다.

절차

  • Knative 서비스를 생성합니다.

    $ kn service create <service-name> --image <image> --env <key=value>

    명령 예

    $ kn service create event-display \
        --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest

    출력 예

    Creating service 'event-display' in namespace 'default':
    
      0.271s The Route is still working to reflect the latest desired specification.
      0.580s Configuration "event-display" is waiting for a Revision to become ready.
      3.857s ...
      3.861s Ingress has not yet been reconciled.
      4.270s Ready to serve.
    
    Service 'event-display' created with latest revision 'event-display-bxshg-1' and URL:
    http://event-display-default.apps-crc.testing

5.1.1.1.1. Knative 클라이언트 멀티컨테이너 지원

kn container add 명령을 사용하여 YAML 컨테이너 사양을 표준 출력에 출력할 수 있습니다. 이 명령은 다른 표준 kn 플래그와 함께 사용하여 정의를 생성할 수 있으므로 멀티컨테이너 사용 사례에 유용합니다. kn container add 명령은 kn service create 명령과 함께 사용할 수 있는 모든 컨테이너 관련 플래그를 허용합니다. kn container add 명령을 UNIX 파이프(|)를 사용하여 한 번에 여러 컨테이너 정의를 만들어 연결할 수도 있습니다.

5.1.1.1.1.1. 명령 예
  • 이미지의 컨테이너를 추가하고 표준 출력에 출력합니다.

    $ kn container add <container_name> --image <image_uri>

    명령 예

    $ kn container add sidecar --image docker.io/example/sidecar

    출력 예

    containers:
    - image: docker.io/example/sidecar
      name: sidecar
      resources: {}

  • 체인 2개의 kn 컨테이너 추가 명령을 함께 추가한 다음 kn service create 명령에 전달하여 두 개의 컨테이너가 있는 Knative 서비스를 생성합니다.

    $ kn container add <first_container_name> --image <image_uri> | \
    kn container add <second_container_name> --image <image_uri> | \
    kn service create <service_name> --image <image_uri> --extra-containers -

    --extra-containers - kn 이 YAML 파일 대신 파이프 입력을 읽는 특수 케이스를 지정합니다.

    명령 예

    $ kn container add sidecar --image docker.io/example/sidecar:first | \
    kn container add second --image docker.io/example/sidecar:second | \
    kn service create my-service --image docker.io/example/my-app:latest --extra-containers -

    extra -containers 플래그는 YAML 파일의 경로도 허용할 수 있습니다.

    $ kn service create <service_name> --image <image_uri> --extra-containers <filename>

    명령 예

    $ kn service create my-service --image docker.io/example/my-app:latest --extra-containers my-extra-containers.yaml

5.1.1.2. YAML을 사용하여 서버리스 애플리케이션 생성

YAML을 사용하여 서버리스 애플리케이션을 생성하려면 Service 오브젝트를 정의하는 YAML 파일을 생성한 다음 oc apply를 사용하여 적용해야 합니다.

절차

  1. 다음 샘플 코드를 포함하는 YAML 파일을 생성합니다.

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: event-delivery
      namespace: default
    spec:
      template:
        spec:
          containers:
            - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
              env:
                - name: RESPONSE
                  value: "Hello Serverless!"
  2. YAML 파일이 포함된 디렉터리로 이동한 후 YAML 파일을 적용하여 애플리케이션을 배포합니다.

    $ oc apply -f <filename>

서비스가 생성되고 애플리케이션이 배포되면 Knative에서 이 버전의 애플리케이션에 대해 변경할 수 없는 버전을 생성합니다. Knative는 또한 네트워크 프로그래밍을 수행하여 애플리케이션의 경로, 수신, 서비스, 로드 밸런서를 생성하고 트래픽에 따라 비활성 Pod를 포함한 Pod를 자동으로 확장합니다.

5.1.2. Knative CLI를 사용하여 서버리스 애플리케이션 업데이트

서비스를 단계적으로 구축할 때 명령줄에서 대화형 세션에 kn service update 명령을 사용할 수 있습니다. kn service apply 명령과 달리 kn service update 명령을 사용하는 경우 Knative 서비스의 전체 구성이 아닌 업데이트하려는 변경 사항만 지정해야 합니다.

명령 예

  • 새 환경 변수를 추가하여 서비스를 업데이트합니다.

    $ kn service update <service_name> --env <key>=<value>
  • 새 포트를 추가하여 서비스를 업데이트합니다.

    $ kn service update <service_name> --port 80
  • 새 요청 및 제한 매개변수를 추가하여 서비스를 업데이트합니다.

    $ kn service update <service_name> --request cpu=500m --limit memory=1024Mi --limit cpu=1000m
  • latest 태그를 개정 버전에 할당합니다.

    $ kn service update <service_name> --tag <revision_name>=latest
  • 서비스의 최신 READY 버전에 대한 태그를 testing에서 staging으로 업데이트합니다.

    $ kn service update <service_name> --untag testing --tag @latest=staging
  • 트래픽의 10%를 수신하는 버전에 test 태그를 추가하고 나머지 트래픽을 서비스의 최신 READY 버전으로 전송합니다.

    $ kn service update <service_name> --tag <revision_name>=test --traffic test=10,@latest=90

5.1.3. 서비스 선언 적용

kn service apply 명령을 사용하여 Knative 서비스를 선언적으로 구성할 수 있습니다. 서비스가 존재하지 않으면 기존 서비스가 변경된 옵션으로 업데이트됩니다.

kn service apply 명령은 사용자가 일반적으로 단일 명령으로 서비스 상태를 완전히 지정하여 대상 상태를 선언하려는 셸 스크립트 또는 지속적 통합 파이프라인에 특히 유용합니다.

kn service apply를 사용하는 경우 Knative 서비스에 대한 전체 구성을 제공해야 합니다. 이 동작은 업데이트하려는 옵션을 명령에서 지정하기만 하면 되는 kn service update 명령과 다릅니다.

명령 예

  • 서비스를 생성합니다.

    $ kn service apply <service_name> --image <image>
  • 서비스에 환경 변수를 추가합니다.

    $ kn service apply <service_name> --image <image> --env <key>=<value>
  • JSON 또는 YAML 파일에서 서비스 선언을 읽습니다.

    $ kn service apply <service_name> -f <filename>

5.1.4. Knative CLI를 사용하여 서버리스 애플리케이션 설명

kn service describe 명령을 사용하여 Knative 서비스를 설명할 수 있습니다.

명령 예

  • 서비스를 설명합니다.

    $ kn service describe --verbose <service_name>

    --verbose 플래그는 선택 사항이지만 자세한 설명을 제공하기 위해 포함할 수 있습니다. 일반 출력과 자세한 출력의 차이점은 다음 예에 표시됩니다.

    --verbose 플래그를 사용하지 않는 출력 예

    Name:       hello
    Namespace:  default
    Age:        2m
    URL:        http://hello-default.apps.ocp.example.com
    
    Revisions:
      100%  @latest (hello-00001) [1] (2m)
            Image:  docker.io/openshift/hello-openshift (pinned to aaea76)
    
    Conditions:
      OK TYPE                   AGE REASON
      ++ Ready                   1m
      ++ ConfigurationsReady     1m
      ++ RoutesReady             1m

    --verbose 플래그를 사용하는 출력 예

    Name:         hello
    Namespace:    default
    Annotations:  serving.knative.dev/creator=system:admin
                  serving.knative.dev/lastModifier=system:admin
    Age:          3m
    URL:          http://hello-default.apps.ocp.example.com
    Cluster:      http://hello.default.svc.cluster.local
    
    Revisions:
      100%  @latest (hello-00001) [1] (3m)
            Image:  docker.io/openshift/hello-openshift (pinned to aaea76)
            Env:    RESPONSE=Hello Serverless!
    
    Conditions:
      OK TYPE                   AGE REASON
      ++ Ready                   3m
      ++ ConfigurationsReady     3m
      ++ RoutesReady             3m

  • YAML 형식으로 서비스를 설명합니다.

    $ kn service describe <service_name> -o yaml
  • JSON 형식으로 서비스를 설명합니다.

    $ kn service describe <service_name> -o json
  • 서비스 URL만 인쇄합니다.

    $ kn service describe <service_name> -o url

5.1.5. 서버리스 애플리케이션 배포 확인

서버리스 애플리케이션이 성공적으로 배포되었는지 확인하려면 Knative에서 생성한 애플리케이션 URL을 가져와서 해당 URL로 요청을 보낸 후 출력을 관찰해야 합니다.

참고

OpenShift Serverless에서는 HTTP 및 HTTPS URL을 모두 지원하지만 oc get ksvc 출력에서는 항상 http:// 형식을 사용하여 URL을 인쇄합니다.

프로세스

  1. 애플리케이션 URL을 찾습니다.

    $ oc get ksvc <service_name>

    출력 예

    NAME            URL                                        LATESTCREATED         LATESTREADY           READY   REASON
    event-delivery   http://event-delivery-default.example.com   event-delivery-4wsd2   event-delivery-4wsd2   True

  2. 클러스터에 요청한 후 출력을 확인합니다.

    HTTP 요청의 예

    $ curl http://event-delivery-default.example.com

    HTTPS 요청의 예

    $ curl https://event-delivery-default.example.com

    출력 예

    Hello Serverless!

  3. 선택 사항입니다. 인증서 체인에서 자체 서명된 인증서와 관련된 오류가 발생하면 --insecure 플래그를 curl 명령에 추가하여 오류를 무시할 수 있습니다.

    $ curl https://event-delivery-default.example.com --insecure

    출력 예

    Hello Serverless!

    중요

    프로덕션 배포에는 자체 서명된 인증서를 사용해서는 안 됩니다. 이 방법은 테스트 목적으로만 사용됩니다.

  4. 선택 사항입니다. OpenShift Container Platform 클러스터가 CA(인증 기관)에서 서명한 인증서로 구성되어 있지만 아직 시스템에 전역적으로 구성되지 않은 경우 curl 명령으로 이 인증서를 지정할 수 있습니다. 인증서 경로는 --cacert 플래그를 사용하여 curl 명령에 전달할 수 있습니다.

    $ curl https://event-delivery-default.example.com --cacert <file>

    출력 예

    Hello Serverless!

5.1.6. HTTP2 및 gRPC를 사용하여 서버리스 애플리케이션과 상호 작용

OpenShift Serverless에서는 비보안 또는 엣지 종료 경로만 지원합니다.

비보안 또는 엣지 종료 경로에서는 OpenShift Container Platform에서 HTTP2를 지원하지 않습니다. 또한 이러한 경로는 gRPC가 HTTP2에 의해 전송되기 때문에 gRPC를 지원하지 않습니다.

애플리케이션에서 이러한 프로토콜을 사용하는 경우 수신 게이트웨이를 사용하여 애플리케이션을 직접 호출해야 합니다. 이를 위해서는 수신 게이트웨이의 공용 주소와 애플리케이션의 특정 호스트를 찾아야 합니다.

프로세스

  1. 애플리케이션 호스트를 찾습니다. 서버리스 애플리케이션 배포 확인에 있는 지침을 참조하십시오.
  2. 수신 게이트웨이의 공용 주소를 찾습니다.

    $ oc -n knative-serving-ingress get svc kourier

    출력 예

    NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP                                                             PORT(S)                                                                                                                                      AGE
    kourier   LoadBalancer   172.30.51.103   a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com   80:31380/TCP,443:31390/TCP   67m

    공용 주소는 EXTERNAL-IP 필드에 있으며 이 경우 a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com입니다.

  3. HTTP 요청의 호스트 헤더를 애플리케이션의 호스트로 수동으로 설정하되 요청 자체는 수신 게이트웨이의 공개 주소로 지정합니다.

    $ curl -H "Host: hello-default.example.com" a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com

    출력 예

    Hello Serverless!

    수신 게이트웨이에 대한 요청을 직접 지시하는 동안 애플리케이션 호스트에 기관을 설정하여 gRPC 요청을 생성할 수도 있습니다.

    grpc.Dial(
        "a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com:80",
        grpc.WithAuthority("hello-default.example.com:80"),
        grpc.WithInsecure(),
    )
    참고

    위 예제와 같이 각 포트(기본값 80)를 두 호스트 모두에 추가해야 합니다.

5.1.7. 제한적인 네트워크 정책을 사용하여 클러스터에서 Knative 애플리케이션과의 통신 활성화

여러 사용자가 액세스할 수 있는 클러스터를 사용하는 경우 클러스터는 네트워크 정책을 사용하여 네트워크를 통해 서로 통신할 수 있는 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: []

Knative 시스템 Pod에서 애플리케이션에 액세스할 수 있도록 하려면 각 Knative 시스템 네임스페이스에 레이블을 추가한 다음 이 레이블이 있는 다른 네임스페이스의 네임스페이스에 액세스할 수 있는 애플리케이션 네임스페이스에 NetworkPolicy 오브젝트를 생성해야 합니다.

중요

클러스터의 비Knative 서비스에 대한 요청을 거부하는 네트워크 정책은 이러한 서비스에 대한 액세스를 계속 차단합니다. 그러나 Knative 시스템 네임스페이스에서 Knative 애플리케이션으로의 액세스를 허용하면 클러스터의 모든 네임스페이스에서 Knative 애플리케이션에 액세스할 수 있습니다.

클러스터의 모든 네임스페이스에서 Knative 애플리케이션에 대한 액세스를 허용하지 않으려면 Knative 서비스에 JSON 웹 토큰 인증을 사용할 수 있습니다( Knative Serving 문서 참조). Knative 서비스에 대한 JSON 웹 토큰 인증에는 Service Mesh가 필요합니다.

프로세스

  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
    애플리케이션(Knative 서비스)이 존재하는 네임스페이스입니다.

5.1.8. 서비스당 HTTPS 리디렉션

다음 예와 같이 networking.knative.dev/httpOption 주석을 구성하여 서비스의 HTTPS 리디렉션을 활성화하거나 비활성화할 수 있습니다.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example
  namespace: default
  annotations:
    networking.knative.dev/httpOption: "redirected"
spec:
  ...

5.1.9. kn CLI를 오프라인 모드에서 사용

중요

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

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

5.1.9.1. 오프라인 모드 정보

일반적으로 kn service 명령을 실행하면 변경 사항이 즉시 클러스터로 전파됩니다. 그러나 대안으로 오프라인 모드에서 kn service 명령을 실행할 수 있습니다.

  1. 오프라인 모드로 서비스를 생성하면 클러스터에서 변경 사항이 발생하지 않습니다. 대신 로컬 시스템에 서비스 설명자 파일 만들기 만 이루어집니다.
  2. 설명자 파일이 생성되면 수동으로 수정하고 버전 제어 시스템에서 추적할 수 있습니다.
  3. 마지막으로 설명자 파일에서 kn service create -f, kn service apply -f, 또는 oc apply -f 명령을 사용하여 변경 사항을 클러스터에 전파할 수 있습니다.

오프라인 모드에는 여러 방식이 있습니다.

  • 클러스터 변경에 사용하기 전에 설명자 파일을 수동으로 수정할 수 있습니다.
  • 버전 관리 시스템에서 서비스의 설명자 파일을 로컬로 추적할 수 있습니다. 이를 통해 CI(지속적 통합) 파이프라인, 개발 환경 또는 데모와 같이 대상 클러스터 이외의 위치에서 설명자 파일을 재사용할 수 있습니다.
  • 생성된 설명자 파일을 검사하여 Knative 서비스에 대해 확인할 수 있습니다. 특히 결과 서비스가 kn 명령에 전달된 다양한 인수에 영향을 받는 방법을 확인할 수 있습니다.

오프라인 모드는 속도가 빠르고 클러스터에 연결할 필요가 없다는 장점이 있습니다. 그러나 오프라인 모드에서는 서버 측 유효성 검사가 없습니다. 따라서 서비스 이름이 고유하거나 지정된 이미지를 가져올 수 있는지 등을 확인할 수 없습니다.

5.1.9.2. 오프라인 모드를 사용하여 서비스 생성

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Serving이 클러스터에 설치되어 있습니다.
  • kn CLI를 설치했습니다.

절차

  1. 오프라인 모드에서 로컬 Knative 서비스 설명자 파일을 생성합니다.

    $ kn service create event-display \
        --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest \
        --target ./ \
        --namespace test

    출력 예

    Service 'event-display' created in namespace 'test'.

    • --target ./ 플래그는 오프라인 모드를 활성화하고 새 디렉터리 트리를 저장하는 디렉토리로./를 지정합니다.

      기존 디렉터리를 지정하지 않고 --target my-service.yaml과 같은 파일 이름을 사용하면 디렉터리 트리가 생성되지 않습니다. 대신 서비스 설명자 파일 my-service.yaml만 현재 디렉터리에 생성됩니다.

      파일 이름에는. .yaml, .yml, 또는 .json 확장을 사용할 수 있습니다. .json을 선택하면 JSON 형식으로 서비스 설명자 파일을 생성합니다.

    • --namespace test 옵션은 새 서비스를 test 네임스페이스에 배치합니다.

      --namespace를 사용하지 않고 OpenShift Container Platform 클러스터에 로그인한 경우 현재 네임스페이스에 설명자 파일이 생성됩니다. 그렇지 않으면 설명자 파일이 default 네임스페이스에 생성됩니다.

  2. 생성된 디렉터리 구조를 확인합니다.

    $ tree ./

    출력 예

    ./
    └── test
        └── ksvc
            └── event-display.yaml
    
    2 directories, 1 file

    • --target에서 지정된 현재 ./ 디렉터리에는 지정된 네임스페이스를 바탕으로 이름이 지정된 test/ 디렉터리가 포함되어 있습니다.
    • test/ 디렉터리에는 리소스 유형의 이름에 따라 이름이 지정된 ksvc 디렉터리가 포함되어 있습니다.
    • ksvc 디렉터리에는 지정된 서비스 이름에 따라 이름이 지정된 기술자 파일 event-display.yaml이 포함되어 있습니다.
  3. 생성된 서비스 기술자 파일을 확인합니다.

    $ cat test/ksvc/event-display.yaml

    출력 예

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      creationTimestamp: null
      name: event-display
      namespace: test
    spec:
      template:
        metadata:
          annotations:
            client.knative.dev/user-image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
          creationTimestamp: null
        spec:
          containers:
          - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
            name: ""
            resources: {}
    status: {}

  4. 새 서비스에 대한 정보를 나열합니다.

    $ kn service describe event-display --target ./ --namespace test

    출력 예

    Name:       event-display
    Namespace:  test
    Age:
    URL:
    
    Revisions:
    
    Conditions:
      OK TYPE    AGE REASON

    • target ./ 옵션은 네임스페이스 하위 디렉터리를 포함하는 디렉터리 구조의 루트 디렉터리를 지정합니다.

      또는 --target 옵션을 사용하여 YAML 또는 JSON 파일 이름을 직접 지정할 수 있습니다. 허용된 파일 확장자는 .yaml, .yml, .json입니다.

    • --namespace 옵션은 필요한 서비스 기술자 파일을 포함하는 하위 디렉터리를 kn와 통신하는 네임스페이스를 지정합니다.

      --namespace를 사용하지 않고 OpenShift Container Platform 클러스터에 로그인한 경우 kn은 현재 네임스페이스를 바탕으로 이름이 지정된 하위 디렉터리에서 서비스를 검색합니다. 그렇지 않으면 kndefault/ 하위 디렉터리에서 검색합니다.

  5. 서비스 설명자 파일을 사용하여 클러스터에 서비스를 생성합니다.

    $ kn service create -f test/ksvc/event-display.yaml

    출력 예

    Creating service 'event-display' in namespace 'test':
    
      0.058s The Route is still working to reflect the latest desired specification.
      0.098s ...
      0.168s Configuration "event-display" is waiting for a Revision to become ready.
     23.377s ...
     23.419s Ingress has not yet been reconciled.
     23.534s Waiting for load balancer to be ready
     23.723s Ready to serve.
    
    Service 'event-display' created to latest revision 'event-display-00001' is available at URL:
    http://event-display-test.apps.example.com

5.2. 자동 스케일링 정보

Knative Serving에서는 애플리케이션이 들어오는 수요와 일치하도록 자동 확장 또는 자동 스케일링 을 제공합니다. 예를 들어 애플리케이션에 트래픽이 수신되지 않고 0으로 스케일링되는 경우 Knative Serving에서 애플리케이션을 복제본 0으로 축소합니다. 0으로 스케일링을 비활성화하면 애플리케이션이 클러스터의 애플리케이션에 지정된 최소 복제본 수로 축소됩니다. 애플리케이션에 대한 트래픽이 늘어나는 경우 요구에 맞게 복제본을 확장할 수도 있습니다.

Knative Serving에 대한 자동 스케일링을 활성화하려면 애플리케이션에 대한 동시성스케일링 경계 를 구성해야 합니다.

참고

버전 템플릿에 설정된 모든 제한 또는 타겟은 애플리케이션의 단일 인스턴스에 대해 측정됩니다. 예를 들어 target 주석을 50 으로 설정하면 자동 스케일러가 애플리케이션을 스케일링하여 각 버전에서 50개의 요청을 처리하도록 구성합니다.

5.3. 스케일 바운드

바인딩을 스케일링하면 언제든지 애플리케이션을 제공할 수 있는 최소 및 최대 복제본 수가 결정됩니다.

콜드 시작 또는 컴퓨팅 비용을 제어하는 데 도움이 되도록 애플리케이션의 스케일 바인드를 설정할 수 있습니다.

5.3.1. 최소 스케일링 바운드

애플리케이션을 제공할 수 있는 최소 복제본 수는 minScale 주석으로 결정됩니다.

다음 조건이 충족되면 minScale 값은 기본적으로 0 개의 복제본으로 설정됩니다.

  • minScale 주석이 설정되지 않았습니다.
  • 0으로 스케일링할 수 있습니다
  • 클래스 KPA 사용

0으로 스케일링을 활성화하지 않으면 minScale 값은 기본적으로 1 입니다.

minScale 사양이 있는 서비스 사양의 예

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: "0"
...

5.3.1.1. Knative CLI를 사용하여 minScale 주석 설정

kn service 명령을 --min-scale 플래그와 함께 사용하여 서비스에 --min-scale 값을 생성하거나 수정할 수 있습니다.

절차

  • --min-scale 플래그를 사용하여 서비스의 최소 복제본 수를 설정합니다.

    $ kn service create <service_name> --image <image_uri> --min-scale <integer>

    $ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --min-scale 2

5.3.2. 최대 스케일 바운드

애플리케이션을 제공할 수 있는 최대 복제본 수는 maxScale 주석으로 결정됩니다. maxScale 주석을 설정하지 않으면 생성된 복제본 수에 대한 상한이 없습니다.

maxScale 사양이 있는 서비스 사양의 예

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/maxScale: "10"
...

5.3.2.1. Knative CLI를 사용하여 maxScale 주석 설정

kn service 명령을 --max-scale 플래그와 함께 사용하여 서비스에 대한 --max-scale 값을 생성하거나 수정할 수 있습니다.

절차

  • max -scale 플래그를 사용하여 서비스의 최대 복제본 수를 설정합니다.

    $ kn service create <service_name> --image <image_uri> --max-scale <integer>

    명령 예

    $ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --max-scale 10

5.4. 동시성

동시성은 언제든지 각 애플리케이션 복제본에서 처리할 수 있는 동시 요청 수를 결정합니다.

5.4.1. 동시성 제한 및 대상

동시성은 소프트 제한 또는 하드 제한으로 구성할 수 있습니다 :

  • 소프트 제한은 엄격하게 적용된 바인드가 아닌 대상 요청 제한입니다. 예를 들어 트래픽이 급증하는 경우 소프트 제한 대상을 초과할 수 있습니다.
  • 하드 제한은 엄격하게 적용되는 상한 요청 제한입니다. 동시성이 하드 제한에 도달하면 초과된 요청이 버퍼링되며 요청을 실행하는 데 충분한 여유 용량이 있을 때까지 기다려야 합니다.

    중요

    하드 제한 구성을 사용하는 것은 애플리케이션과 함께 명확한 사용 사례가 있는 경우에만 사용하는 것이 좋습니다. 낮은 하드 제한을 지정하면 애플리케이션의 처리량과 대기 시간에 부정적인 영향을 미칠 수 있으며 콜드 시작이 발생할 수 있습니다.

소프트 대상과 하드 제한을 추가하면 자동 확장기에서 동시 요청의 소프트 대상 수를 대상으로 하지만 최대 요청 수에 하드 제한 값의 하드 제한을 적용합니다.

하드 제한 값이 소프트 제한 값보다 작으면 실제로 처리할 수 있는 수보다 더 많은 요청을 대상으로 할 필요가 없으므로 소프트 제한 값이 다운됩니다.

5.4.2. 소프트 동시성 대상 구성

spec에서 autoscaling.knative.dev/target 주석을 설정하거나 올바른 플래그와 함께 kn service 명령을 사용하여 Knative 서비스의 소프트 동시성 대상을 지정할 수 있습니다.

절차

  • 선택 사항: Service 사용자 정의 리소스의 사양에서 Knative 서비스에 대한 autoscaling.knative.dev/target 주석을 설정합니다.

    서비스 사양 예

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: example-service
      namespace: default
    spec:
      template:
        metadata:
          annotations:
            autoscaling.knative.dev/target: "200"

  • 선택 사항: kn service 명령을 사용하여 --concurrency-target 플래그를 지정합니다.

    $ kn service create <service_name> --image <image_uri> --concurrency-target <integer>

    동시성 타겟이 50개 요청인 서비스를 생성하는 명령의 예

    $ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --concurrency-target 50

5.4.3. 하드 동시성 제한 구성

containerConcurrency 사양을 수정하거나 올바른 플래그와 함께 kn service 명령을 사용하여 Knative 서비스에 대한 하드 동시성 제한을 지정할 수 있습니다.

절차

  • 선택 사항: 서비스 사용자 정의 리소스 사양에서 Knative 서비스의 containerConcurrency 사양을 설정합니다.

    서비스 사양 예

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: example-service
      namespace: default
    spec:
      template:
        spec:
          containerConcurrency: 50

    기본값은 0 으로, 한 번에 하나의 서비스 복제본으로 이동할 수 있는 동시 요청 수에 제한이 없음을 의미합니다.

    0 보다 큰 값은 한 번에 하나의 서비스 복제본으로 이동할 수 있는 정확한 요청 수를 지정합니다. 이 예제에서는 하드 동시성 제한을 50개 요청으로 제한할 수 있습니다.

  • 선택 사항: kn service 명령을 사용하여 --concurrency-limit 플래그를 지정합니다.

    $ kn service create <service_name> --image <image_uri> --concurrency-limit <integer>

    동시성 제한이 50개 요청인 서비스를 생성하는 명령의 예

    $ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --concurrency-limit 50

5.4.4. 동시성 대상 사용률

이 값은 자동 스케일러가 실제로 대상으로 하는 동시성 제한의 백분율을 지정합니다. 또한 복제본이 실행되는 hotness 를 지정하여 정의된 하드 제한에 도달하기 전에 자동 스케일러를 확장할 수도 있습니다.

예를 들어 containerConcurrency 주석 값이 10으로 설정되어 targetUtilizationPercentage 값이 70%로 설정된 경우 기존 복제본의 평균 동시 요청 수가 7에 도달하면 자동 스케일러는 새 복제본을 생성합니다. 숫자로 지정된 7~10 요청은 기존 복제본으로 계속 전송되지만 containerConcurrency 주석 제한에 도달한 후 추가 복제본이 필요한 것으로 예상됩니다.

targetUtilizationPercentage 주석을 사용하여 구성된 서비스 예

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/targetUtilizationPercentage: "70"
...

5.5. 트래픽 관리

개정 버전은 Knative 서비스에 수행된 각 수정에 대한 코드 및 구성의 특정 시점 스냅샷입니다. 서비스 구성이 업데이트될 때마다 서비스의 새 버전이 생성됩니다. 개정 버전은 변경할 수 없는 개체이며, 필요하거나 사용하는 동안 유지될 수 있습니다. Knative Serving 버전은 들어오는 트래픽에 따라 자동으로 확장 및 축소할 수 있습니다.

서비스 리소스의 트래픽 사양을 수정하여 Knative 서비스의 다른 버전으로의 traffic 라우팅을 관리할 수 있습니다.

Knative 서비스 아키텍처

5.5.1. 트래픽 라우팅 예

Knative 서비스를 생성할 때 기본 traffic 사양 설정이 없습니다. traffic 사양을 설정하면 수정된 버전 수를 통해 트래픽을 분할하거나 최신 버전으로 트래픽을 보낼 수 있습니다.

5.5.1.1. 여러 버전 간 트래픽 라우팅

다음 예제에서는 traffic 사양의 버전 목록을 확장하여 여러 버전으로 트래픽을 분할하는 방법을 보여줍니다.

이 예에서는 트래픽의 50%를 current 태그가 지정된 버전에 전송하고 트래픽의 50%를 candidate로 태그된 버전에 보냅니다.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
...
  traffic:
  - tag: current
    revisionName: example-service-1
    percent: 50
  - tag: candidate
    revisionName: example-service-2
    percent: 50
  - tag: latest
    latestRevision: true
    percent: 0

5.5.1.2. 최신 버전으로의 트래픽 라우팅

다음 예에서는 traffic의 100%가 서비스의 최신 버전으로 라우팅되는 트래픽 사양을 보여줍니다. status에서 latestRevision의 최신 버전의 이름을 볼 수 있습니다.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
...
  traffic:
  - latestRevision: true
    percent: 100
status:
  ...
  traffic:
  - percent: 100
    revisionName: example-service

5.5.1.3. 현재 버전으로의 트래픽 라우팅

다음 예에서는 traffic의 100%가 current로 태그가 지정된 버전으로 라우팅되고 해당 버전의 이름이 example-service로 지정된 트래픽 사양을 보여줍니다. 트래픽이 라우팅되지 않더라도 latest로 태그된 버전을 사용할 수 있습니다.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
...
  traffic:
  - tag: current
    revisionName: example-service
    percent: 100
  - tag: latest
    latestRevision: true
    percent: 0

5.5.2. OpenShift Container Platform 웹 콘솔을 사용하여 버전 간 트래픽 관리

서버리스 애플리케이션을 생성하면 OpenShift Container Platform 웹 콘솔의 개발자 화면의 토폴로지 보기에 애플리케이션이 표시됩니다. 애플리케이션 버전은 노드에서 나타내며 Knative 서비스는 노드 주변의 사각형으로 표시됩니다.

코드 또는 서비스 구성을 새로 변경하면 지정된 시간에 코드 스냅샷인 새 버전이 생성됩니다. 서비스의 경우 필요에 따라 서비스를 분할하고 다른 버전으로 라우팅하여 서비스 버전 간 트래픽을 관리할 수 있습니다.

절차

토폴로지 보기에서 애플리케이션의 다양한 버전 간 트래픽을 분할하려면 다음을 수행합니다.

  1. Knative 서비스를 클릭하여 측면 패널에서 개요를 확인합니다.
  2. 리소스 탭을 클릭하여 서비스의 버전경로로 구성된 목록을 확인합니다.

    그림 5.1. 서버리스 애플리케이션

    odc 서버리스 앱
  3. 측면 패널 상단에 S 아이콘으로 표시된 서비스를 클릭하여 서비스 세부 정보 개요를 확인합니다.
  4. YAML 탭을 클릭하고 YAML 편집기에서 서비스 구성을 수정한 다음 저장을 클릭합니다. 예를 들면 timeoutseconds를 300에서 301로 변경합니다. 이러한 구성 변경으로 인해 새 버전이 트리거됩니다. 토폴로지 보기에 최신 버전이 표시되고 서비스의 리소스 탭에 두 가지 버전이 표시됩니다.
  5. 리소스 탭에서 트래픽 분산 설정을 클릭하여 트래픽 분산 대화 상자를 확인합니다.

    1. 분할 필드에 두 버전의 분할 트래픽 백분율 부분을 추가합니다.
    2. 두 버전에 대한 사용자 정의 URL을 생성하도록 태그를 추가합니다.
    3. 저장을 클릭하여 토폴로지 보기에서 두 버전을 나타내는 두 노드를 확인합니다.

      그림 5.2. 서버리스 애플리케이션의 버전

      odc 서버리스 버전

5.5.3. Knative CLI를 사용한 트래픽 관리

kn service update 명령을 사용하여 서비스 버전 간에 트래픽을 분할할 수 있습니다.

명령 예

$ kn service update <service_name> --traffic <revision>=<percent>

다음과 같습니다.

  • <service_name>은 트래픽 라우팅을 구성하려는 Knative 서비스의 이름입니다.
  • <revision>은 일정 비율의 트래픽을 수신하도록 구성하려는 버전입니다. 버전 이름 또는 --tag 플래그를 사용하여 버전에 할당한 태그를 지정할 수 있습니다.
  • <percent>는 지정된 버전에 보낼 트래픽의 백분율입니다.

5.5.3.1. 여러 플래그 및 우선 순위

단일 kn service update 명령을 사용하여 모든 트래픽 관련 플래그를 지정할 수 있습니다. kn 은 이러한 플래그의 우선 순위를 정의합니다. 명령을 사용할 때 지정된 플래그의 순서는 고려하지 않습니다.

kn에 의해 평가되는 플래그의 우선순위는 다음과 같습니다.

  1. --untag: 이 플래그가 있는 참조된 모든 버전은 트래픽 블록에서 제거됩니다.
  2. --tag: 버전에는 트래픽 블록에 지정된 대로 태그가 지정됩니다.
  3. --traffic: 참조된 버전에는 트래픽 분할의 일부가 할당됩니다.

    중요

    -traffic 플래그는 한 명령에 여러 번 지정할 수 있으며 모든 플래그의 Percent 값 합계가 100인 경우에만 유효합니다.

버전에 태그를 추가한 다음 설정한 태그에 따라 트래픽을 분할할 수 있습니다.

5.5.3.2. 트래픽 관리 명령 예

다음 명령에서 @latest 태그는 blue가 서비스의 최신 버전으로 확인됨을 의미합니다.

$ kn service update example-service --tag green=revision-0001 --tag blue=@latest

greenblue 태그를 적용한 후 다음 명령을 실행하여 80%의 트래픽은 버전 green으로 전송하고 20%의 트래픽은 버전 blue로 전송하여 example-service라는 서비스에 대한 트래픽을 분할할 수 있습니다.

$ kn service update example-service --traffic green=80 --traffic blue=20

또는 다음 명령을 사용하여 80%의 트래픽을 최신 버전으로, v1 이라는 버전으로 20%를 보낼 수 있습니다.

$ kn service update example-service --traffic @latest=80 --traffic v1=20
참고

명령에는 --traffic 플래그와 함께 식별자 @latest를 한 번만 사용할 수 있습니다.

5.5.3.3. Knative CLI 트래픽 관리 플래그

kn CLI는 서비스에 대한 트래픽 블록상의 트래픽 작업을 kn service update 명령의 일부로 지원합니다.

다음 테이블에는 트래픽 분할 플래그, 값 형식, 플래그에서 수행하는 작업이 요약되어 있습니다. 반복 열은 kn service update 명령에서 특정 플래그 값을 반복할 수 있는지를 나타냅니다.

플래그작업반복

--traffic

RevisionName=Percent

RevisionNamePercent 트래픽 제공

있음

--traffic

Tag=Percent

Tag가 있는 버전에 Percent 트래픽 제공

있음

--traffic

@latest=Percent

최신 준비 버전에 Percent 트래픽 제공

아니요

--tag

RevisionName=Tag

RevisionNameTag 지정

있음

--tag

@latest=Tag

최근 준비된 버전에 Tag 지정

아니요

--untag

Tag

버전에서 Tag 제거

있음

5.5.3.4. 개정버전 사용자 정의 URL

kn service update 명령을 사용하여 서비스에 --tag 플래그를 할당하면 서비스를 업데이트할 때 생성되는 버전에 대한 사용자 정의 URL이 생성됩니다. 사용자 정의 URL은 https://<tag>-<service_name>-<namespace>.<domain>; 또는 http://<tag>-<service_name>-<namespace>.<domain>; 패턴을 따릅니다.

--tag--untag 플래그는 다음 구문을 사용합니다.

  • 하나의 값이 필요합니다.
  • 서비스의 트래픽 블록에 있는 고유한 태그를 나타냅니다.
  • 하나의 명령에서 여러 번 지정할 수 있습니다.
5.5.3.4.1. 예제: 태그를 버전에 할당

다음 예제에서는 latest 태그를 example-revision이라는 버전에 할당합니다.

$ kn service update <service_name> --tag @latest=example-tag
5.5.3.4.2. 예제: 버전에서 태그 제거

--untag 플래그를 사용하여 사용자 정의 URL을 제거하도록 태그를 제거할 수 있습니다.

참고

개정 버전에 해당 태그가 제거되고 트래픽의 0%가 할당되면 개정 버전이 트래픽 블록에서 완전히 제거됩니다.

다음 명령은 example-revision이라는 버전에서 모든 태그를 제거합니다.

$ kn service update <service_name> --untag example-tag

5.5.4. blue-green 배포 전략을 사용하여 트래픽 라우팅 및 관리

blue-green 배포 전략을 사용하여 프로덕션 버전에서 새 버전으로 트래픽을 안전하게 다시 라우팅할 수 있습니다.

절차

  1. 애플리케이션을 Knative 서비스로 생성하고 배포합니다.
  2. 다음 명령의 출력을 확인하여 서비스를 배포할 때 생성된 첫 번째 버전의 이름을 찾습니다.

    $ oc get ksvc <service_name> -o=jsonpath='{.status.latestCreatedRevisionName}'

    명령 예

    $ oc get ksvc example-service -o=jsonpath='{.status.latestCreatedRevisionName}'

    출력 예

    $ example-service-00001

  3. 다음 YAML을 서비스 spec에 추가하여 인바운드 트래픽을 버전으로 전송합니다.

    ...
    spec:
      traffic:
        - revisionName: <first_revision_name>
          percent: 100 # All traffic goes to this revision
    ...
  4. 다음 명령을 실행하여 얻은 URL 출력에서 앱을 볼 수 있는지 확인합니다.

    $ oc get ksvc <service_name>
  5. 서비스의 template 사양에서 하나 이상의 필드를 수정하고 재배포하여 애플리케이션의 두 번째 버전을 배포합니다. 예를 들어 서비스의 image 또는 env 환경 변수를 수정할 수 있습니다. kn CLI를 설치한 경우 서비스 YAML 파일을 적용하거나 kn service update 명령을 사용하여 서비스를 다시 배포할 수 있습니다.
  6. 다음 명령을 실행하여 서비스를 재배포할 때 생성된 두 번째 최신 버전의 이름을 찾습니다.

    $ oc get ksvc <service_name> -o=jsonpath='{.status.latestCreatedRevisionName}'

    이때 서비스의 첫 번째 버전과 두 번째 버전이 모두 배포되고 실행됩니다.

  7. 다른 모든 트래픽을 첫 번째 버전으로 전송하면서 두 번째 버전에 대한 새 테스트 끝점을 생성하도록 기존 서비스를 업데이트합니다.

    테스트 끝점을 사용하여 업데이트된 서비스 사양의 예

    ...
    spec:
      traffic:
        - revisionName: <first_revision_name>
          percent: 100 # All traffic is still being routed to the first revision
        - revisionName: <second_revision_name>
          percent: 0 # No traffic is routed to the second revision
          tag: v2 # A named route
    ...

    YAML 리소스를 다시 적용하여 이 서비스를 재배포하면 애플리케이션의 두 번째 버전이 준비됩니다. 기본 URL의 두 번째 버전으로 라우팅되는 트래픽이 없으며 Knative는 새로 배포된 버전을 테스트하기 위해 v2라는 새 서비스를 생성합니다.

  8. 다음 명령을 실행하여 두 번째 버전에 대한 새 서비스의 URL을 가져옵니다.

    $ oc get ksvc <service_name> --output jsonpath="{.status.traffic[*].url}"

    이 URL을 사용하여 트래픽을 라우팅하기 전에 애플리케이션의 새 버전이 예상대로 작동하는지 확인할 수 있습니다.

  9. 트래픽의 50%가 첫 번째 버전으로 전송되고 50%가 두 번째 버전으로 전송되도록 기존 서비스를 다시 업데이트합니다.

    버전 간에 트래픽을 50/50으로 분할하는 업데이트된 서비스 사양 분할 예

    ...
    spec:
      traffic:
        - revisionName: <first_revision_name>
          percent: 50
        - revisionName: <second_revision_name>
          percent: 50
          tag: v2
    ...

  10. 모든 트래픽을 새 버전의 앱으로 라우팅할 준비가 되면 두 번째 버전으로 트래픽의 100%를 보내도록 서비스를 다시 업데이트합니다.

    두 번째 버전으로 모든 트래픽을 전송하는 업데이트된 서비스 사양의 예

    ...
    spec:
      traffic:
        - revisionName: <first_revision_name>
          percent: 0
        - revisionName: <second_revision_name>
          percent: 100
          tag: v2
    ...

    작은 정보

    버전을 롤백하지 않으려는 경우 첫 번째 버전을 트래픽의 0%로 설정하는 대신 제거할 수 있습니다. 라우팅할 수 없는 버전 오브젝트는 가비지 수집됩니다.

  11. 첫 번째 버전의 URL을 방문하여 이전 버전의 앱으로 더 이상 트래픽이 전송되지 않는지 확인합니다.

5.6. 라우팅

Knative에서는 OpenShift Container Platform TLS 종료를 활용하여 Knative 서비스에 대한 라우팅을 제공합니다. Knative 서비스가 생성되면 해당 서비스에 대해 OpenShift Container Platform 경로가 자동으로 생성됩니다. 이 경로는 OpenShift Serverless Operator에서 관리합니다. OpenShift Container Platform 경로는 OpenShift Container Platform 클러스터와 동일한 도메인을 통해 Knative 서비스를 표시합니다.

OpenShift Container Platform 라우팅에 대한 Operator의 제어를 비활성화하여 대신 TLS 인증서를 직접 사용하도록 Knative 경로를 구성할 수 있습니다.

또한 Knative 경로를 OpenShift Container Platform 경로와 함께 사용하면 트래픽 분할과 같은 세분화된 라우팅 기능을 추가로 제공할 수 있습니다.

5.6.1. OpenShift Container Platform 경로에 대한 레이블 및 주석 사용자 정의

OpenShift Container Platform 경로는 사용자 정의 레이블 및 주석을 사용할 수 있으며 Knative 서비스의 metadata 사양을 수정하여 구성할 수 있습니다. 사용자 정의 레이블 및 주석은 서비스에서 Knative 경로로 전달된 다음 Knative Ingress로 전달되고 마지막으로 OpenShift Container Platform 경로로 전달됩니다.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Serving 구성 요소가 OpenShift Container Platform 클러스터에 설치되어 있습니다.

절차

  1. OpenShift Container Platform 경로에 전달할 레이블 또는 주석이 포함된 Knative 서비스를 생성합니다.

    • YAML을 사용하여 서비스를 생성하려면 다음을 수행합니다.

      YAML을 사용하여 생성한 서비스 예

      apiVersion: serving.knative.dev/v1
      kind: Service
      metadata:
        name: <service_name>
        labels:
          <label_name>: <label_value>
        annotations:
          <annotation_name>: <annotation_value>
      ...

    • kn CLI를 사용하여 서비스를 생성하려면 다음을 입력합니다.

      kn 명령을 사용하여 생성된 서비스 예

      $ kn service create <service_name> \
        --image=<image> \
        --annotation <annotation_name>=<annotation_value> \
        --label <label_value>=<label_value>

  2. 다음 명령의 출력을 확인하여 추가한 주석 또는 레이블을 사용하여 OpenShift Container Platform 경로가 생성되었는지 확인합니다.

    확인을 위한 명령 예

    $ oc get routes.route.openshift.io \
         -l serving.knative.openshift.io/ingressName=<service_name> \ 1
         -l serving.knative.openshift.io/ingressNamespace=<service_namespace> \ 2
         -n knative-serving-ingress -o yaml \
             | grep -e "<label_name>: \"<label_value>\""  -e "<annotation_name>: <annotation_value>" 3

    1
    서비스 이름을 사용합니다.
    2
    서비스가 생성된 네임스페이스를 사용합니다.
    3
    레이블 및 주석 이름과 값의 값을 사용합니다.

5.6.2. Knative 서비스에 대한 OpenShift Container Platform 경로 구성

OpenShift Container Platform에서 TLS 인증서를 사용하도록 Knative 서비스를 구성하려면 OpenShift Serverless Operator의 서비스 경로 자동 생성 기능을 비활성화하고 대신 해당 서비스에 대한 경로를 수동으로 생성해야 합니다.

참고

다음 절차를 완료하면 knative-serving-ingress 네임스페이스의 기본 OpenShift Container Platform 경로가 생성되지 않습니다. 그러나 애플리케이션의 Knative 경로는 이 네임스페이스에 계속 생성됩니다.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Serving 구성 요소가 OpenShift Container Platform 클러스터에 설치되어 있어야 합니다.
참고

다음 절차에서는 예제 명령의 대체 가능한 값을 수정해야 합니다.

절차

  1. serving.knative.openshift.io/disableRoute=true 주석이 포함된 Knative 서비스를 생성합니다.

    중요

    serving.knative.openshift.io/disableRoute=true 주석은 OpenShift Serverless에서 경로를 자동으로 생성하지 않도록 지시합니다. 그러나 서비스는 여전히 URL을 표시하며 Ready 상태에 도달합니다. 이 URL은 URL의 호스트 이름과 동일한 호스트 이름으로 자체 경로를 생성할 때까지 외부에서 작동하지 않습니다.

    1. Knative 서비스 리소스를 생성합니다.

      리소스 예

      apiVersion: serving.knative.dev/v1
      kind: Service
      metadata:
        name: <service_name>
        annotations:
          serving.knative.openshift.io/disableRoute: "true"
      spec:
        template:
          spec:
            containers:
            - image: <image>
      ...

    2. Service 리소스를 적용합니다.

      $ oc apply -f <filename>
    3. 선택 사항입니다. kn service create 명령을 사용하여 Knative 서비스를 생성합니다.

      kn 명령 예제

      $ kn service create <service_name> \
        --image=gcr.io/knative-samples/helloworld-go \
        --annotation serving.knative.openshift.io/disableRoute=true

  2. 서비스에 OpenShift Container Platform 경로가 생성되지 않았는지 확인합니다.

    명령 예

    $ $ oc get routes.route.openshift.io \
      -l serving.knative.openshift.io/ingressName=$KSERVICE_NAME \
      -l serving.knative.openshift.io/ingressNamespace=$KSERVICE_NAMESPACE \
      -n knative-serving-ingress

    다음 출력이 표시됩니다.

    No resources found in knative-serving-ingress namespace.
  3. knative-serving-ingress 네임스페이스에 Route 리소스를 생성합니다.

    apiVersion: route.openshift.io/v1
    kind: Route
    metadata:
      annotations:
        haproxy.router.openshift.io/timeout: 600s 1
      name: <route_name> 2
      namespace: knative-serving-ingress 3
    spec:
      host: <service_host> 4
      port:
        targetPort: http2
      to:
        kind: Service
        name: kourier
        weight: 100
      tls:
        insecureEdgeTerminationPolicy: Allow
        termination: edge 5
        key: |-
          -----BEGIN PRIVATE KEY-----
          [...]
          -----END PRIVATE KEY-----
        certificate: |-
          -----BEGIN CERTIFICATE-----
          [...]
          -----END CERTIFICATE-----
        caCertificate: |-
          -----BEGIN CERTIFICATE-----
          [...]
          -----END CERTIFICATE----
      wildcardPolicy: None
    1
    OpenShift Container Platform 경로에 대한 타임아웃 값입니다. max-revision-timeout-seconds 설정과 동일한 값으로 설정해야 합니다(기본값: 600s).
    2
    OpenShift Container Platform 경로의 이름입니다.
    3
    OpenShift Container Platform 경로의 네임스페이스입니다. knative-serving-ingress여야 합니다.
    4
    외부 액세스를 위한 호스트 이름입니다. 이 값을 <service_name>-<service_namespace>.<domain>으로 설정할 수 있습니다.
    5
    사용할 인증서입니다. 현재는 edge 종료만 지원됩니다.
  4. Route 리소스를 적용합니다.

    $ oc apply -f <filename>

5.6.3. 클러스터 로컬로 클러스터 가용성 설정

기본적으로 Knative 서비스는 공용 IP 주소에 게시됩니다. 공용 IP 주소에 게시된다는 것은 Knative 서비스가 공용 애플리케이션이 되어 공개적으로 액세스할 수 있는 URL이 있음을 의미합니다.

공개적으로 액세스할 수 있는 URL은 클러스터 외부에서 액세스할 수 있습니다. 그러나 개발자는 클러스터 내부에서만 액세스할 수 있는 백엔드 서비스(비공개 서비스)를 빌드해야 할 수 있습니다. 개발자는 클러스터의 개별 서비스에 networking.knative.dev/visibility=cluster-local 레이블을 지정하여 비공개로 설정할 수 있습니다.

중요

OpenShift Serverless 1.15.0 및 최신 버전의 경우 serving.knative.dev/visibility 레이블을 더 이상 사용할 수 없습니다. 대신 networking.knative.dev/visibility 레이블을 사용하려면 기존 서비스를 업데이트해야 합니다.

절차

  • networking.knative.dev/visibility=cluster-local 레블을 추가하여 서비스 가시성을 설정합니다.

    $ oc label ksvc <service_name> networking.knative.dev/visibility=cluster-local

검증

  • 다음 명령을 입력하고 출력을 검토하여 서비스의 URL이 http://<service_name>.<namespace>.svc.cluster.local 형식인지 확인합니다.

    $ oc get ksvc

    출력 예

    NAME            URL                                                                         LATESTCREATED     LATESTREADY       READY   REASON
    hello           http://hello.default.svc.cluster.local                                      hello-tx2g7       hello-tx2g7       True

5.6.4. 추가 리소스

  • 지원되는 OpenShift Container Platform 경로 주석에 대한 자세한 내용은 경로별 주석을 참조하십시오.

5.7. 이벤트 싱크

싱크는 다른 리소스에서 들어오는 이벤트를 수신할 수 있는 주소 지정 가능한 CR(사용자 정의 리소스)입니다. Knative 서비스, 채널 및 브로커는 모두 싱크의 예입니다.

작은 정보

kn을 사용자 지정하여 kn CLI 명령에 대해 --sink 플래그와 함께 사용할 수 있는 CR을 구성할 수 있습니다.

5.7.1. Knative CLI --sink 플래그

Knative(kn) CLI를 사용하여 event-producing 사용자 정의 리소스를 생성하는 경우 --sink 플래그를 사용하여 이벤트가 해당 리소스에서 로 전송되는 싱크를 지정할 수 있습니다.

다음 예제에서는 싱크로 서비스 http://event-display.svc.cluster.local를 사용하는 싱크 바인딩을 생성합니다.

--sink 플래그를 사용하는 명령의 예

$ kn source binding create bind-heartbeat \
  --namespace sinkbinding-example \
  --subject "Job:batch/v1:app=heartbeat-cron" \
  --sink http://event-display.svc.cluster.local \ 1
  --ce-override "sink=bound"

1
http://event-display.svc.cluster.localsvc는 싱크가 Knative 서비스인지 확인합니다. 기타 기본 싱크 접두사에는 channel, 및 broker가 포함됩니다.

5.7.2. 개발자 화면을 사용하여 이벤트 소스를 싱크에 연결

OpenShift Container Platform에서 싱크에 연결할 수 있는 다양한 이벤트 소스 유형을 생성할 수 있습니다.

사전 요구 사항

개발자 화면을 사용하여 이벤트 소스를 싱크에 연결하려면 다음 조건을 충족해야 합니다.

  • OpenShift Serverless Operator, Knative Serving, Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • 싱크를 생성했습니다.
  • 웹 콘솔에 로그인한 후 개발자 화면으로 갑니다.
  • 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.

절차

  1. +추가이벤트 소스로 이동한 다음 생성할 이벤트 소스 유형을 선택하여 모든 유형의 이벤트 소스를 생성합니다.
  2. 이벤트 소스 양식 보기의 싱크 섹션에서 리소스를 선택합니다. 그런 다음 드롭다운을 사용하여 싱크를 선택합니다.
  3. 생성을 클릭합니다.

검증

토폴로지 페이지를 확인하여 이벤트 소스가 생성되었고 싱크에 연결되어 있는지 확인할 수 있습니다.

  1. 개발자 화면에서 토폴로지로 이동합니다.
  2. 이벤트 소스를 표시하고 연결된 싱크를 클릭하여 사이드 패널에서 싱크 세부 정보를 확인합니다.

5.7.3. 트리거를 싱크에 연결

트리거를 싱크로 보내기 전에 브로커의 이벤트가 필터링되도록 트리거를 싱크에 연결할 수 있습니다. 트리거에 연결된 싱크는 Trigger 리소스 사양에서 subscriber로 구성됩니다.

Kafka 싱크에 연결된 트리거의 예

apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: <trigger_name> 1
spec:
...
  subscriber:
    ref:
      apiVersion: eventing.knative.dev/v1alpha1
      kind: KafkaSink
      name: <kafka_sink_name> 2

1
싱크에 연결되어 있는 트리거의 이름입니다.
2
KafkaSink 오브젝트의 이름입니다.

5.8. API 서버 소스 사용

API 서버 소스는 Knative 서비스와 같은 이벤트 싱크를 Kubernetes API 서버에 연결하는 데 사용할 수 있는 이벤트 소스입니다. API 서버 소스는 Kubernetes 이벤트를 조사하고 해당 이벤트를 Knative Eventing 브로커에 전달합니다.

5.8.1. 사전 요구 사항

  • 현재 OpenShift Container Platform 클러스터에 Knative Serving 및 Eventing을 포함한 OpenShift Serverless가 설치되어 있어야 합니다. 해당 요소는 클러스터 관리자가 설치할 수 있습니다.
  • 이벤트 소스에는 이벤트 sink로 사용할 서비스가 필요합니다. 싱크는 이벤트 소스에서 이벤트를 전송하는 서비스 또는 애플리케이션입니다.
  • 이벤트 소스에 대한 서비스 계정, 역할, 역할 바인딩을 생성하거나 업데이트해야 합니다.
참고

다음 절차 중 일부에서는 YAML 파일을 생성해야 합니다.

예제에 사용된 YAML 파일의 이름을 변경하는 경우 해당 CLI 명령도 업데이트해야 합니다.

5.8.2. 이벤트 소스에 대한 서비스 계정, 역할, 역할 바인딩 생성

절차

  1. 이벤트 소스에 대한 서비스 계정, 역할, 역할 바인딩을 YAML 파일로 만듭니다.

    참고

    기존 서비스 계정을 다시 사용하려면 새 리소스를 생성하는 대신 필요한 권한을 포함하도록 기존 ServiceAccount 리소스를 수정할 수 있습니다.

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: events-sa
      namespace: default 1
    
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: event-watcher
      namespace: default 2
    rules:
      - apiGroups:
          - ""
        resources:
          - events
        verbs:
          - get
          - list
          - watch
    
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: k8s-ra-event-watcher
      namespace: default 3
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: event-watcher
    subjects:
      - kind: ServiceAccount
        name: events-sa
        namespace: default 4
    1 2 3 4
    이 네임스페이스를 이벤트 소스 설치를 위해 선택한 네임스페이스로 변경합니다.
  2. YAML 파일을 적용합니다.

    $ oc apply -f <filename>

5.8.3. 개발자 화면을 사용하여 API 서버 소스 이벤트 소스 생성

절차

  1. 개발자 화면에서 +추가이벤트 소스로 이동합니다. 이벤트 소스 페이지가 표시됩니다.
  2. 선택 사항: 이벤트 소스에 대한 공급자가 여러 개인 경우 공급자 목록에서 필요한 공급자를 선택하여 공급자의 사용 가능한 이벤트 소스를 필터링합니다.
  3. ApiServerSource를 선택한 다음 이벤트 소스 생성을 클릭합니다. 이벤트 소스 생성 페이지가 표시됩니다.
  4. 양식 보기 또는 YAML 보기를 사용하여 ApiServerSource 설정을 구성합니다.

    참고

    양식 보기YAML 보기를 전환할 수 있습니다. 다른 보기로 전환해도 데이터는 유지됩니다.

    1. APIVERSION으로 v1을, KINDEvent를 입력합니다.
    2. 생성한 서비스 계정의 서비스 계정 이름을 선택합니다.
    3. 이벤트 소스로 싱크를 선택합니다. 싱크는 채널, 브로커 또는 서비스와 같은 리소스이거나 URI일 수 있습니다.
  5. 생성을 클릭합니다.

검증

  • API 서버 소스를 생성한 후에는 토폴로지 보기에서 싱크된 서비스에 연결된 것을 확인할 수 있습니다.

    ApiServerSource 토폴로지 보기
참고

URI 싱크를 사용하는 경우 URI 싱크URI 편집을 마우스 오른쪽 버튼으로 클릭하여 URI를 수정합니다.

5.8.4. 개발자 화면을 사용하여 API 서버 소스 삭제

절차

  1. 토폴로지 보기로 이동합니다.
  2. API 서버 소스를 마우스 오른쪽 버튼으로 클릭하고 ApiServerSource 삭제를 선택합니다.

    ApiServerSource 삭제

5.8.5. Knative CLI를 사용하여 API 서버 소스 생성

이 섹션에서는 kn 명령을 사용하여 API 서버 소스를 생성하는 데 필요한 단계를 설명합니다.

사전 요구 사항

  • OpenShift Serverless, Knative Serving 및 Eventing 구성 요소, kn CLI가 설치되어 있어야 합니다.

절차

  1. 브로커를 싱크로 사용하는 API 서버 소스를 생성합니다.

    $ kn source apiserver create <event_source_name> --sink broker:<broker_name> --resource "event:v1" --service-account <service_account_name> --mode Resource
  2. API 서버 소스가 올바르게 설정되었는지 확인하려면 수신되는 메시지를 로그로 덤프하는 Knative 서비스를 생성합니다.

    $ kn service create <service_name> --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
  3. 해당 서비스에 default 브로커의 이벤트를 필터링하는 트리거를 생성합니다.

    $ kn trigger create <trigger_name> --sink ksvc:<service_name>
  4. 기본 네임스페이스에서 Pod를 시작하여 이벤트를 생성합니다.

    $ oc create deployment hello-node --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
  5. 생성된 출력을 다음 명령으로 검사하여 컨트롤러가 올바르게 매핑되는지 확인합니다.

    $ kn source apiserver describe <source_name>

    출력 예

    Name:                mysource
    Namespace:           default
    Annotations:         sources.knative.dev/creator=developer, sources.knative.dev/lastModifier=developer
    Age:                 3m
    ServiceAccountName:  events-sa
    Mode:                Resource
    Sink:
      Name:       default
      Namespace:  default
      Kind:       Broker (eventing.knative.dev/v1)
    Resources:
      Kind:        event (v1)
      Controller:  false
    Conditions:
      OK TYPE                     AGE REASON
      ++ Ready                     3m
      ++ Deployed                  3m
      ++ SinkProvided              3m
      ++ SufficientPermissions     3m
      ++ EventTypesProvided        3m

검증

메시지 덤퍼 기능 로그를 확인하면 Kubernetes 이벤트가 Knative로 전송되었는지 확인할 수 있습니다.

  1. Pod를 가져옵니다.

    $ oc get pods
  2. Pod의 메시지 덤퍼 기능 로그를 확인합니다.

    $ oc logs $(oc get pod -o name | grep event-display) -c user-container

    출력 예

    ☁️  cloudevents.Event
    Validation: valid
    Context Attributes,
      specversion: 1.0
      type: dev.knative.apiserver.resource.update
      datacontenttype: application/json
      ...
    Data,
      {
        "apiVersion": "v1",
        "involvedObject": {
          "apiVersion": "v1",
          "fieldPath": "spec.containers{hello-node}",
          "kind": "Pod",
          "name": "hello-node",
          "namespace": "default",
           .....
        },
        "kind": "Event",
        "message": "Started container",
        "metadata": {
          "name": "hello-node.159d7608e3a3572c",
          "namespace": "default",
          ....
        },
        "reason": "Started",
        ...
      }

5.8.5.1. Knative CLI --sink 플래그

Knative(kn) CLI를 사용하여 event-producing 사용자 정의 리소스를 생성하는 경우 --sink 플래그를 사용하여 이벤트가 해당 리소스에서 로 전송되는 싱크를 지정할 수 있습니다.

다음 예제에서는 싱크로 서비스 http://event-display.svc.cluster.local를 사용하는 싱크 바인딩을 생성합니다.

--sink 플래그를 사용하는 명령의 예

$ kn source binding create bind-heartbeat \
  --namespace sinkbinding-example \
  --subject "Job:batch/v1:app=heartbeat-cron" \
  --sink http://event-display.svc.cluster.local \ 1
  --ce-override "sink=bound"

1
http://event-display.svc.cluster.localsvc는 싱크가 Knative 서비스인지 확인합니다. 기타 기본 싱크 접두사에는 channel, 및 broker가 포함됩니다.

5.8.6. Knative CLI를 사용하여 API 서버 소스 삭제

이 섹션에서는 knoc 명령을 사용하여 API 서버 소스, 트리거, 서비스 계정, 클러스터 역할, 클러스터 역할 바인딩을 삭제하는 데 사용되는 단계를 설명합니다.

사전 요구 사항

  • kn CLI가 설치되어 있어야 합니다.

절차

  1. 트리거를 삭제합니다.

    $ kn trigger delete <trigger_name>
  2. 이벤트 소스를 삭제합니다.

    $ kn source apiserver delete <source_name>
  3. 서비스 계정, 클러스터 역할, 클러스터 바인딩을 삭제합니다.

    $ oc delete -f authentication.yaml

5.8.7. YAML 메서드를 사용하여 API 서버 소스 사용

이 가이드에서는 YAML 파일을 사용하여 API 서버 소스를 생성하는 데 필요한 단계를 설명합니다.

사전 요구 사항

  • Knative Serving 및 Eventing을 설치해야 합니다.
  • API 서버 소스 YAML 파일에 정의된 것과 동일한 네임스페이스에 default 브로커를 생성해야 합니다.

절차

  1. API 서버 소스에 대한 서비스 계정, 역할, 역할 바인딩을 생성하거나 업데이트해야 합니다.

    참고

    기존 서비스 계정을 다시 사용하려면 새 리소스를 생성하는 대신 필요한 권한을 포함하도록 기존 ServiceAccount 리소스를 수정할 수 있습니다.

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: events-sa
      namespace: default 1
    
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: event-watcher
      namespace: default 2
    rules:
      - apiGroups:
          - ""
        resources:
          - events
        verbs:
          - get
          - list
          - watch
    
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: k8s-ra-event-watcher
      namespace: default 3
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: event-watcher
    subjects:
      - kind: ServiceAccount
        name: events-sa
        namespace: default 4
    1 2 3 4
    이 네임스페이스를 API 서버 소스 설치를 위해 선택한 네임스페이스로 변경합니다.
  2. YAML 파일을 적용합니다.

    $ oc apply -f <filename>
  3. API 서버 소스를 YAML 파일로 만듭니다.

    apiVersion: sources.knative.dev/v1alpha1
    kind: ApiServerSource
    metadata:
      name: testevents
    spec:
      serviceAccountName: events-sa
      mode: Resource
      resources:
        - apiVersion: v1
          kind: Event
      sink:
        ref:
          apiVersion: eventing.knative.dev/v1
          kind: Broker
          name: default
  4. ApiServerSource YAML 파일을 적용합니다.

    $ oc apply -f <filename>
  5. API 서버 소스가 올바르게 설정되었는지 확인하려면 수신되는 메시지를 로그로 덤프하는 Knative 서비스를 YAML 파일로 생성합니다.

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: event-display
      namespace: default
    spec:
      template:
        spec:
          containers:
            - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
  6. Service YAML 파일을 적용합니다.

    $ oc apply -f <filename>
  7. default 브로커에서 이전 단계에서 생성된 서비스로 이벤트를 필터링하는 YAML 파일로 Trigger 오브젝트를 생성합니다.

    apiVersion: eventing.knative.dev/v1
    kind: Trigger
    metadata:
      name: event-display-trigger
      namespace: default
    spec:
      broker: default
      subscriber:
        ref:
          apiVersion: serving.knative.dev/v1
          kind: Service
          name: event-display
  8. Trigger YAML 파일을 적용합니다.

    $ oc apply -f <filename>
  9. 기본 네임스페이스에서 Pod를 시작하여 이벤트를 생성합니다.

    $ oc create deployment hello-node --image=quay.io/openshift-knative/knative-eventing-sources-event-display
  10. 다음 명령을 입력하고 출력을 검사하여 컨트롤러가 올바르게 매핑되는지 확인합니다.

    $ oc get apiserversource.sources.knative.dev testevents -o yaml

    출력 예

    apiVersion: sources.knative.dev/v1alpha1
    kind: ApiServerSource
    metadata:
      annotations:
      creationTimestamp: "2020-04-07T17:24:54Z"
      generation: 1
      name: testevents
      namespace: default
      resourceVersion: "62868"
      selfLink: /apis/sources.knative.dev/v1alpha1/namespaces/default/apiserversources/testevents2
      uid: 1603d863-bb06-4d1c-b371-f580b4db99fa
    spec:
      mode: Resource
      resources:
      - apiVersion: v1
        controller: false
        controllerSelector:
          apiVersion: ""
          kind: ""
          name: ""
          uid: ""
        kind: Event
        labelSelector: {}
      serviceAccountName: events-sa
      sink:
        ref:
          apiVersion: eventing.knative.dev/v1
          kind: Broker
          name: default

검증

Kubernetes 이벤트가 Knative로 전송되었는지 확인하려면 메시지 덤퍼 기능 로그를 확인하면 됩니다.

  1. 다음 명령을 입력하여 pod를 가져옵니다.

    $ oc get pods
  2. 다음 명령을 입력하여 pod 메시지 덤퍼 기능 로그를 표시합니다.

    $ oc logs $(oc get pod -o name | grep event-display) -c user-container

    출력 예

    ☁️  cloudevents.Event
    Validation: valid
    Context Attributes,
      specversion: 1.0
      type: dev.knative.apiserver.resource.update
      datacontenttype: application/json
      ...
    Data,
      {
        "apiVersion": "v1",
        "involvedObject": {
          "apiVersion": "v1",
          "fieldPath": "spec.containers{hello-node}",
          "kind": "Pod",
          "name": "hello-node",
          "namespace": "default",
           .....
        },
        "kind": "Event",
        "message": "Started container",
        "metadata": {
          "name": "hello-node.159d7608e3a3572c",
          "namespace": "default",
          ....
        },
        "reason": "Started",
        ...
      }

5.8.8. API 서버 소스 삭제

이 섹션에서는 YAML 파일을 삭제하여 API 서버 소스, 트리거, 서비스 계정, 클러스터 역할, 클러스터 역할 바인딩을 삭제하는 방법을 설명합니다.

절차

  1. 트리거를 삭제합니다.

    $ oc delete -f trigger.yaml
  2. 이벤트 소스를 삭제합니다.

    $ oc delete -f k8s-events.yaml
  3. 서비스 계정, 클러스터 역할, 클러스터 바인딩을 삭제합니다.

    $ oc delete -f authentication.yaml

5.9. ping 소스 사용

ping 소스는 이벤트 소비자에게 주기적으로 일정한 페이로드를 전송하는 데 사용됩니다.

ping 소스를 사용하면 타이머와 유사하게 전송 이벤트를 예약할 수 있습니다.

ping 소스 YAML의 예

apiVersion: sources.knative.dev/v1alpha2
kind: PingSource
metadata:
  name: test-ping-source
spec:
  schedule: "*/2 * * * *" 1
  jsonData: '{"message": "Hello world!"}' 2
  sink: 3
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: event-display

1
CRON 표현식을 사용하여 지정한 이벤트 스케줄입니다.
2
JSON으로 인코딩된 데이터 문자열로 표시된 이벤트 메시지 본문입니다.
3
이는 이벤트 소비자에 대한 세부 정보입니다. 이 예제에서는 event-display라는 Knative 서비스를 사용하고 있습니다.

5.9.1. 개발자 화면을 사용하여 ping 소스 생성

OpenShift Container Platform 웹 콘솔에서 기본 ping 소스를 생성하고 확인할 수 있습니다.

사전 요구 사항

개발자 화면을 사용하여 ping 소스를 생성하려면 다음을 확인하십시오.

  • OpenShift Serverless Operator, Knative Serving, Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • 웹 콘솔에 로그인했습니다.
  • 개발자 화면에 있습니다.
  • 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.

절차

  1. ping 소스가 작동하는지 확인하려면 수신 메시지를 서비스 로그에 덤프하는 간단한 Knative 서비스를 생성합니다.

    1. 개발자 화면에서 +추가YAML로 이동합니다.
    2. 예제 YAML을 복사합니다.

      apiVersion: serving.knative.dev/v1
      kind: Service
      metadata:
        name: event-display
      spec:
        template:
          spec:
            containers:
              - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
    3. 생성을 클릭합니다.
  2. 이전 단계에서 생성한 서비스와 동일한 네임스페이스 또는 이벤트를 보낼 다른 싱크에 ping 소스를 생성합니다.

    1. 개발자 화면에서 +추가이벤트 소스로 이동합니다. 이벤트 소스 페이지가 표시됩니다.
    2. 선택 사항: 이벤트 소스에 대한 공급자가 여러 개인 경우 공급자 목록에서 필요한 공급자를 선택하여 공급자의 사용 가능한 이벤트 소스를 필터링합니다.
    3. Ping 소스를 선택한 다음 이벤트 소스 생성을 클릭합니다. 이벤트 소스 생성 페이지가 표시됩니다.

      참고

      양식 보기 또는 YAML 보기를 사용하여 PingSource 설정을 구성하고 보기 간에 전환할 수 있습니다. 다른 보기로 전환해도 데이터는 유지됩니다.

    4. 스케줄 값을 입력합니다. 이 예에서 값은 */2 * * * *이며, 2분마다 메시지를 전송하는 PingSource를 생성합니다.
    5. 선택 사항: 메시지 페이로드인 Data 값을 입력할 수 있습니다.
    6. 싱크를 선택합니다. 리소스 또는 URI일 수 있습니다. 이 예제에서는 이전 단계에서 생성한 event-display 서비스를 리소스 싱크로 사용합니다.
    7. 생성을 클릭합니다.

검증

토폴로지 페이지를 확인하여 ping 소스가 생성되었고 싱크에 연결되어 있는지 확인할 수 있습니다.

  1. 개발자 화면에서 토폴로지로 이동합니다.
  2. ping 소스 및 싱크를 확인합니다.

    토폴로지 보기에서 ping 소스 및 서비스 보기

5.9.2. Knative CLI를 사용하여 ping 소스 생성

다음 절차에서는 kn CLI를 사용하여 기본 ping 소스를 생성하는 방법을 설명합니다.

사전 요구 사항

  • Knative Serving 및 Eventing이 설치되어 있습니다.
  • kn CLI가 설치되어 있습니다.

절차

  1. ping 소스가 작동하는지 확인하려면 수신 메시지를 서비스 로그에 덤프하는 간단한 Knative 서비스를 생성합니다.

    $ kn service create event-display \
        --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
  2. 요청할 각 ping 이벤트 세트에 대해 이벤트 소비자와 동일한 네임스페이스에 ping 소스를 생성합니다.

    $ kn source ping create test-ping-source \
        --schedule "*/2 * * * *" \
        --data '{"message": "Hello world!"}' \
        --sink ksvc:event-display
  3. 다음 명령을 입력하고 출력을 검사하여 컨트롤러가 올바르게 매핑되는지 확인합니다.

    $ kn source ping describe test-ping-source

    출력 예

    Name:         test-ping-source
    Namespace:    default
    Annotations:  sources.knative.dev/creator=developer, sources.knative.dev/lastModifier=developer
    Age:          15s
    Schedule:     */2 * * * *
    Data:         {"message": "Hello world!"}
    
    Sink:
      Name:       event-display
      Namespace:  default
      Resource:   Service (serving.knative.dev/v1)
    
    Conditions:
      OK TYPE                 AGE REASON
      ++ Ready                 8s
      ++ Deployed              8s
      ++ SinkProvided         15s
      ++ ValidSchedule        15s
      ++ EventTypeProvided    15s
      ++ ResourcesCorrect     15s

검증

싱크 Pod의 로그를 보면 Kubernetes 이벤트가 Knative 이벤트 싱크로 전송되었는지 확인할 수 있습니다.

Knative 서비스는 기본적으로 60초 이내에 트래픽이 수신되지 않으면 Pod를 종료합니다. 이 가이드에 표시된 예제에서는 2분마다 메시지를 전송하는 ping 소스를 생성하므로 새로 생성된 Pod에서 각 메시지를 관찰해야 합니다.

  1. 새 Pod가 생성되었는지 확인합니다.

    $ watch oc get pods
  2. Ctrl+C를 사용하여 Pod를 감시한 다음 생성한 Pod의 로그를 확인합니다.

    $ oc logs $(oc get pod -o name | grep event-display) -c user-container

    출력 예

    ☁️  cloudevents.Event
    Validation: valid
    Context Attributes,
      specversion: 1.0
      type: dev.knative.sources.ping
      source: /apis/v1/namespaces/default/pingsources/test-ping-source
      id: 99e4f4f6-08ff-4bff-acf1-47f61ded68c9
      time: 2020-04-07T16:16:00.000601161Z
      datacontenttype: application/json
    Data,
      {
        "message": "Hello world!"
      }

5.9.2.1. Knative CLI --sink 플래그

Knative(kn) CLI를 사용하여 event-producing 사용자 정의 리소스를 생성하는 경우 --sink 플래그를 사용하여 이벤트가 해당 리소스에서 로 전송되는 싱크를 지정할 수 있습니다.

다음 예제에서는 싱크로 서비스 http://event-display.svc.cluster.local를 사용하는 싱크 바인딩을 생성합니다.

--sink 플래그를 사용하는 명령의 예

$ kn source binding create bind-heartbeat \
  --namespace sinkbinding-example \
  --subject "Job:batch/v1:app=heartbeat-cron" \
  --sink http://event-display.svc.cluster.local \ 1
  --ce-override "sink=bound"

1
http://event-display.svc.cluster.localsvc는 싱크가 Knative 서비스인지 확인합니다. 기타 기본 싱크 접두사에는 channel, 및 broker가 포함됩니다.

5.9.3. Knative CLI를 사용하여 ping 소스 삭제

다음 절차에서는 kn CLI를 사용하여 ping 소스를 삭제하는 방법을 설명합니다.

  • ping 소스를 삭제합니다.

    $ kn delete pingsources.sources.knative.dev <ping_source_name>

5.9.4. YAML에서 ping 소스 사용

다음 섹션에서는 YAML 파일을 사용하여 기본 ping 소스를 생성하는 방법을 설명합니다.

사전 요구 사항

  • Knative Serving 및 Eventing이 설치되어 있습니다.
참고

다음 절차에 따라 YAML 파일을 생성해야 합니다.

예제에 사용된 YAML 파일의 이름을 변경하는 경우 해당 CLI 명령도 업데이트해야 합니다.

프로세스

  1. ping 소스가 작동하는지 확인하려면 수신 메시지를 서비스 로그에 덤프하는 간단한 Knative 서비스를 생성합니다.

    1. 예제 YAML을 service.yaml이라는 파일에 복사합니다.

      apiVersion: serving.knative.dev/v1
      kind: Service
      metadata:
        name: event-display
      spec:
        template:
          spec:
            containers:
              - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
    2. 서비스를 생성합니다.

      $ oc apply --filename service.yaml
  2. 요청할 각 ping 이벤트 세트에 대해 이벤트 소비자와 동일한 네임스페이스에 ping 소스를 생성합니다.

    1. 예제 YAML을 ping-source.yaml이라는 파일에 복사합니다.

      apiVersion: sources.knative.dev/v1alpha2
      kind: PingSource
      metadata:
        name: test-ping-source
      spec:
        schedule: "*/2 * * * *"
        jsonData: '{"message": "Hello world!"}'
        sink:
          ref:
            apiVersion: serving.knative.dev/v1
            kind: Service
            name: event-display
    2. ping 소스를 생성합니다.

      $ oc apply --filename ping-source.yaml
  3. 다음 명령을 입력하여 컨트롤러가 올바르게 매핑되는지 확인합니다.

    $ oc get pingsource.sources.knative.dev test-ping-source -oyaml

    출력 예

    apiVersion: sources.knative.dev/v1alpha2
    kind: PingSource
    metadata:
      annotations:
        sources.knative.dev/creator: developer
        sources.knative.dev/lastModifier: developer
      creationTimestamp: "2020-04-07T16:11:14Z"
      generation: 1
      name: test-ping-source
      namespace: default
      resourceVersion: "55257"
      selfLink: /apis/sources.knative.dev/v1alpha2/namespaces/default/pingsources/test-ping-source
      uid: 3d80d50b-f8c7-4c1b-99f7-3ec00e0a8164
    spec:
      jsonData: '{ value: "hello" }'
      schedule: '*/2 * * * *'
      sink:
        ref:
          apiVersion: serving.knative.dev/v1
          kind: Service
          name: event-display
          namespace: default

검증

싱크 Pod의 로그를 보면 Kubernetes 이벤트가 Knative 이벤트 싱크로 전송되었는지 확인할 수 있습니다.

Knative 서비스는 기본적으로 60초 이내에 트래픽이 수신되지 않으면 Pod를 종료합니다. 이 가이드에 표시된 예제에서는 2분마다 메시지를 전송하는 PingSource를 생성하므로 새로 생성된 Pod에서 각 메시지를 관찰해야 합니다.

  1. 새 Pod가 생성되었는지 확인합니다.

    $ watch oc get pods
  2. Ctrl+C를 사용하여 Pod를 감시한 다음 생성한 Pod의 로그를 확인합니다.

    $ oc logs $(oc get pod -o name | grep event-display) -c user-container

    출력 예

    ☁️  cloudevents.Event
    Validation: valid
    Context Attributes,
      specversion: 1.0
      type: dev.knative.sources.ping
      source: /apis/v1/namespaces/default/pingsources/test-ping-source
      id: 042ff529-240e-45ee-b40c-3a908129853e
      time: 2020-04-07T16:22:00.000791674Z
      datacontenttype: application/json
    Data,
      {
        "message": "Hello world!"
      }

5.9.5. YAML을 사용하여 생성한 ping 소스 삭제

다음 절차에서는 YAML을 사용하여 생성한 ping 소스를 삭제하는 방법을 설명합니다.

프로세스

  • ping 소스를 삭제합니다.

    $ oc delete -f <ping_source_yaml_filename>

    명령 예

    $ oc delete -f ping-source.yaml

5.10. Kafka 소스 사용

Apache Kafka 클러스터에서 이벤트를 읽고 이러한 이벤트를 싱크에 전달하는 Knative Kafka 이벤트 소스를 생성할 수 있습니다.

5.10.1. 사전 요구 사항

클러스터에 Knative EventingKnative Kafka를 설치한 후 OpenShift Serverless와 함께 KafkaSource 이벤트 소스를 사용할 수 있습니다.

5.10.2. 웹 콘솔을 사용하여 Kafka 이벤트 소스 생성

OpenShift Container Platform 웹 콘솔에서 Kafka 이벤트 소스를 생성하고 확인할 수 있습니다.

사전 요구 사항

  • OpenShift Serverless Operator, Knative Eventing, KnativeKafka 사용자 정의 리소스가 클러스터에 설치되어 있습니다.
  • 웹 콘솔에 로그인했습니다.
  • 개발자 화면에 있습니다.
  • 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.

프로세스

  1. 추가 페이지로 이동하여 이벤트 소스를 선택합니다.
  2. 이벤트 소스 페이지의 유형 섹션에서 Kafka 소스를 선택합니다.
  3. Kafka 소스 설정을 구성합니다.

    1. 쉼표로 구분된 부트스트랩 서버 목록을 추가합니다.
    2. 쉼표로 구분된 주제 목록을 추가합니다.
    3. 소비자 그룹을 추가합니다.
    4. 생성한 서비스 계정의 서비스 계정 이름을 선택합니다.
    5. 이벤트 소스로 싱크를 선택합니다. 싱크는 채널, 브로커 또는 서비스와 같은 리소스이거나 URI일 수 있습니다.
    6. Kafka 이벤트 소스로 이름을 입력합니다.
  4. 생성을 클릭합니다.

검증

토폴로지 페이지를 확인하여 Kafka 이벤트 소스가 생성되었고 싱크에 연결되어 있는지 확인할 수 있습니다.

  1. 개발자 화면에서 토폴로지로 이동합니다.
  2. Kafka 이벤트 소스 및 싱크를 확인합니다.

    토폴로지 보기에서 Kafka 소스 및 서비스 보기

5.10.3. Knative CLI를 사용하여 Kafka 이벤트 소스 생성

이 섹션에서는 kn 명령을 사용하여 Kafka 이벤트 소스를 생성하는 방법에 대해 설명합니다.

사전 요구 사항

  • OpenShift Serverless Operator, Knative Eventing, Knative Serving, KnativeKafka 사용자 정의 리소스(CR가 클러스터에 설치되어 있습니다.
  • 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
  • 가져오려는 Kafka 메시지를 생성하는 Red Hat AMQ Streams(Kafka) 클러스터에 액세스할 수 있습니다.

프로세스

  1. Kafka 이벤트 소스가 작동하는지 확인하려면 수신 이벤트를 서비스 로그에 덤프하는 Knative 서비스를 생성합니다.

    $ kn service create event-display \
        --image quay.io/openshift-knative/knative-eventing-sources-event-display
  2. KafkaSource CR을 생성합니다.

    $ kn source kafka create <kafka_source_name> \
        --servers <cluster_kafka_bootstrap>.kafka.svc:9092 \
        --topics <topic_name> --consumergroup my-consumer-group \
        --sink event-display
    참고

    이 명령의 자리 표시자 값을 소스 이름, 부트스트랩 서버 및 주제의 값으로 바꿉니다.

    --servers, --topics, --consumergroup 옵션은 Kafka 클러스터에 대한 연결 매개 변수를 지정합니다. --consumergroup 옵션은 선택 사항입니다.

  3. 선택 사항: 생성한 KafkaSource CR에 대한 세부 정보를 확인합니다.

    $ kn source kafka describe <kafka_source_name>

    출력 예

    Name:              example-kafka-source
    Namespace:         kafka
    Age:               1h
    BootstrapServers:  example-cluster-kafka-bootstrap.kafka.svc:9092
    Topics:            example-topic
    ConsumerGroup:     example-consumer-group
    
    Sink:
      Name:       event-display
      Namespace:  default
      Resource:   Service (serving.knative.dev/v1)
    
    Conditions:
      OK TYPE            AGE REASON
      ++ Ready            1h
      ++ Deployed         1h
      ++ SinkProvided     1h

검증 단계

  1. Kafka 인스턴스를 트리거하여 메시지를 항목에 보냅니다.

    $ oc -n kafka run kafka-producer \
        -ti --image=quay.io/strimzi/kafka:latest-kafka-2.7.0 --rm=true \
        --restart=Never -- bin/kafka-console-producer.sh \
        --broker-list <cluster_kafka_bootstrap>:9092 --topic my-topic

    프롬프트에 메시지를 입력합니다. 이 명령은 다음을 가정합니다.

    • Kafka 클러스터는 kafka 네임스페이스에 설치됩니다.
    • my-topic 주제를 사용하도록 KafkaSource 오브젝트가 구성되어 있습니다.
  2. 로그를 보고 메시지가 도착했는지 확인합니다.

    $ oc logs $(oc get pod -o name | grep event-display) -c user-container

    출력 예

    ☁️  cloudevents.Event
    Validation: valid
    Context Attributes,
      specversion: 1.0
      type: dev.knative.kafka.event
      source: /apis/v1/namespaces/default/kafkasources/example-kafka-source#example-topic
      subject: partition:46#0
      id: partition:46/offset:0
      time: 2021-03-10T11:21:49.4Z
    Extensions,
      traceparent: 00-161ff3815727d8755848ec01c866d1cd-7ff3916c44334678-00
    Data,
      Hello!

5.10.3.1. Knative CLI --sink 플래그

Knative(kn) CLI를 사용하여 event-producing 사용자 정의 리소스를 생성하는 경우 --sink 플래그를 사용하여 이벤트가 해당 리소스에서 로 전송되는 싱크를 지정할 수 있습니다.

다음 예제에서는 싱크로 서비스 http://event-display.svc.cluster.local를 사용하는 싱크 바인딩을 생성합니다.

--sink 플래그를 사용하는 명령의 예

$ kn source binding create bind-heartbeat \
  --namespace sinkbinding-example \
  --subject "Job:batch/v1:app=heartbeat-cron" \
  --sink http://event-display.svc.cluster.local \ 1
  --ce-override "sink=bound"

1
http://event-display.svc.cluster.localsvc는 싱크가 Knative 서비스인지 확인합니다. 기타 기본 싱크 접두사에는 channel, 및 broker가 포함됩니다.

5.10.4. YAML을 사용하여 Kafka 이벤트 소스 생성

YAML을 사용하여 Kafka 이벤트 소스를 생성할 수 있습니다.

사전 요구 사항

  • OpenShift Serverless Operator, Knative Eventing, KnativeKafka 사용자 정의 리소스가 클러스터에 설치되어 있습니다.
  • 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.

절차

  1. KafkaSource 오브젝트를 YAML 파일로 생성합니다.

    apiVersion: sources.knative.dev/v1beta1
    kind: KafkaSource
    metadata:
      name: <source_name>
    spec:
      consumerGroup: <group_name> 1
      bootstrapServers:
      - <list_of_bootstrap_servers>
      topics:
      - <list_of_topics> 2
      sink:
      - <list_of_sinks> 3
    1
    소비자 그룹은 동일한 그룹 ID를 사용하고 한 주제의 데이터를 사용하는 소비자 그룹입니다.
    2
    주제에서는 데이터 스토리지의 대상을 제공합니다. 각 주제는 하나 이상의 파티션으로 나뉩니다.
    3
    싱크는 소스에서 이벤트를 보내는 위치를 지정합니다.
    중요

    OpenShift Serverless의 KafkaSource 개체에 대한 API의 v1beta1 버전만 지원됩니다. 이 버전은 더 이상 사용되지 않으므로 이 API의 v1alpha1 버전을 사용하지 마십시오.

    KafkaSource 오브젝트의 예

    apiVersion: sources.knative.dev/v1beta1
    kind: KafkaSource
    metadata:
      name: kafka-source
    spec:
      consumerGroup: knative-group
      bootstrapServers:
      - my-cluster-kafka-bootstrap.kafka:9092
      topics:
      - knative-demo-topic
      sink:
        ref:
          apiVersion: serving.knative.dev/v1
          kind: Service
          name: event-display

  2. KafkaSource YAML 파일을 적용합니다.

    $ oc apply -f <filename>

검증

  • 다음 명령을 입력하여 Kafka 이벤트 소스가 생성되었는지 확인합니다.

    $ oc get pods

    출력 예

    NAME                                    READY     STATUS    RESTARTS   AGE
    kafkasource-kafka-source-5ca0248f-...   1/1       Running   0          13m

5.10.5. 추가 리소스

5.11. 사용자 정의 이벤트 소스

Knative에 포함되지 않은 이벤트 생산자 또는 CloudEvent 형식에 없는 이벤트를 내보내는 생산자에서 이벤트를 수신해야 하는 경우 다음 메서드 중 하나를 사용하여 이 작업을 수행할 수 있습니다.

  • 싱크 바인딩 을 생성하여 PodSpecable 오브젝트를 이벤트 소스로 사용합니다.
  • 컨테이너 소스를 생성하여 컨테이너를 이벤트 소스로 사용합니다.

5.11.1. 싱크 바인딩 사용

SinkBinding 오브젝트는 전달 주소 지정에서 이벤트 프로덕션 분리를 지원합니다. 싱크 바인딩은 이벤트 생산자를 이벤트 소비자 또는 싱크에 연결하는 데 사용됩니다. 이벤트 생산자는 PodSpec 템플릿을 포함하고 이벤트를 생성하는 Kubernetes 리소스입니다. 싱크는 이벤트를 수신할 수 있는 주소 지정 가능한 Kubernetes 오브젝트입니다.

SinkBinding 오브젝트는 싱크의 PodTemplateSpec 에 환경 변수를 삽입하므로 이벤트 대상을 찾기 위해 애플리케이션 코드가 Kubernetes API와 직접 상호 작용할 필요가 없습니다. 이러한 환경 변수는 다음과 같습니다.

K_SINK
해결된 싱크의 URL입니다.
K_CE_OVERRIDES
아웃바운드 이벤트에 대한 재정의를 지정하는 JSON 오브젝트입니다.

5.11.1.1. YAML 메서드로 싱크 바인딩 사용

이 가이드에서는 YAML 파일을 사용하여 싱크 바인딩 인스턴스를 생성하는 데 필요한 단계를 설명합니다.

사전 요구 사항

  • Knative Serving 및 Eventing이 설치되어 있습니다.
참고

다음 절차에 따라 YAML 파일을 생성해야 합니다.

예제에 사용된 YAML 파일의 이름을 변경하는 경우 해당 CLI 명령도 업데이트해야 합니다.

절차

  1. 싱크 바인딩이 올바르게 설정되었는지 확인하려면 Knative 이벤트 표시 서비스를 생성하여 수신되는 메시지를 로그로 덤프합니다.

    1. 다음 샘플 YAML을 service.yaml이라는 파일에 복사합니다.

      apiVersion: serving.knative.dev/v1
      kind: Service
      metadata:
        name: event-display
      spec:
        template:
          spec:
            containers:
              - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
    2. service.yaml 파일을 생성한 후 다음을 입력하여 적용합니다.

      $ oc apply -f service.yaml
  2. 이벤트를 서비스로 보내는 싱크 바인딩 인스턴스를 생성합니다.

    1. sinkbinding.yaml이라는 파일을 생성하고 다음 샘플 코드를 여기에 복사합니다.

      apiVersion: sources.knative.dev/v1alpha1
      kind: SinkBinding
      metadata:
        name: bind-heartbeat
      spec:
        subject:
          apiVersion: batch/v1
          kind: Job 1
          selector:
            matchLabels:
              app: heartbeat-cron
      
        sink:
          ref:
            apiVersion: serving.knative.dev/v1
            kind: Service
            name: event-display
      1
      이 예제에서는 app: Heartbeat-cron 라벨이 있는 모든 작업이 이벤트 싱크에 바인딩됩니다.
    2. sinkbinding.yaml 파일을 생성한 후 다음을 입력하여 적용합니다.

      $ oc apply -f sinkbinding.yaml
  3. CronJob 리소스를 생성합니다.

    1. heartbeats-cronjob.yaml이라는 파일을 생성하고 다음 샘플 코드를 여기에 복사합니다.

      apiVersion: batch/v1
      kind: CronJob
      metadata:
        name: heartbeat-cron
      spec:
        # Run every minute
        schedule: "* * * * *"
        jobTemplate:
          metadata:
            labels:
              app: heartbeat-cron
              bindings.knative.dev/include: "true"
          spec:
            template:
              spec:
                restartPolicy: Never
                containers:
                  - name: single-heartbeat
                    image: quay.io/openshift-knative/heartbeats:latest
                    args:
                      - --period=1
                    env:
                      - name: ONE_SHOT
                        value: "true"
                      - name: POD_NAME
                        valueFrom:
                          fieldRef:
                            fieldPath: metadata.name
                      - name: POD_NAMESPACE
                        valueFrom:
                          fieldRef:
                            fieldPath: metadata.namespace
      중요

      싱크 바인딩을 사용하려면 Knative 리소스에 bindings.knative.dev/include=true 라벨을 수동으로 추가해야 합니다.

      예를 들어 이 라벨을 CronJob 리소스에 추가하려면 Job 리소스 YAML 정의에 다음 행을 추가합니다.

        jobTemplate:
          metadata:
            labels:
              app: heartbeat-cron
              bindings.knative.dev/include: "true"
    2. heartbeats-cronjob.yaml 파일을 생성한 후 다음을 입력하여 적용합니다.

      $ oc apply -f heartbeats-cronjob.yaml
  4. 다음 명령을 입력하고 출력을 검사하여 컨트롤러가 올바르게 매핑되는지 확인합니다.

    $ oc get sinkbindings.sources.knative.dev bind-heartbeat -oyaml

    출력 예

    spec:
      sink:
        ref:
          apiVersion: serving.knative.dev/v1
          kind: Service
          name: event-display
          namespace: default
      subject:
        apiVersion: batch/v1
        kind: Job
        namespace: default
        selector:
          matchLabels:
            app: heartbeat-cron

검증

메시지 덤퍼 기능 로그를 보면 Kubernetes 이벤트가 Knative 이벤트 싱크로 전송되었는지 확인할 수 있습니다.

  1. 명령을 입력합니다.

    $ oc get pods
  2. 명령을 입력합니다.

    $ oc logs $(oc get pod -o name | grep event-display) -c user-container

    출력 예

    ☁️  cloudevents.Event
    Validation: valid
    Context Attributes,
      specversion: 1.0
      type: dev.knative.eventing.samples.heartbeat
      source: https://knative.dev/eventing-contrib/cmd/heartbeats/#event-test/mypod
      id: 2b72d7bf-c38f-4a98-a433-608fbcdd2596
      time: 2019-10-18T15:23:20.809775386Z
      contenttype: application/json
    Extensions,
      beats: true
      heart: yes
      the: 42
    Data,
      {
        "id": 1,
        "label": ""
      }

5.11.1.2. Knative CLI를 사용하여 싱크 바인딩 생성

이 가이드에서는 kn 명령을 사용하여 싱크 바인딩 인스턴스를 생성하는 데 필요한 단계를 설명합니다.

사전 요구 사항

  • Knative Serving 및 Eventing이 설치되어 있습니다.
  • kn CLI가 설치되어 있습니다.
참고

다음 절차에 따라 YAML 파일을 생성해야 합니다.

예제에 사용된 YAML 파일의 이름을 변경하는 경우 해당 CLI 명령도 업데이트해야 합니다.

절차

  1. 싱크 바인딩이 올바르게 설정되었는지 확인하려면 Knative 이벤트 표시 서비스를 생성하여 수신되는 메시지를 로그로 덤프합니다.

    $ kn service create event-display --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
  2. 이벤트를 서비스로 보내는 싱크 바인딩 인스턴스를 생성합니다.

    $ kn source binding create bind-heartbeat --subject Job:batch/v1:app=heartbeat-cron --sink ksvc:event-display
  3. CronJob 사용자 정의 리소스 (CR)를 생성합니다.

    1. heartbeats-cronjob.yaml이라는 파일을 생성하고 다음 샘플 코드를 여기에 복사합니다.

      apiVersion: batch/v1
      kind: CronJob
      metadata:
        name: heartbeat-cron
      spec:
        # Run every minute
        schedule: "* * * * *"
        jobTemplate:
          metadata:
            labels:
              app: heartbeat-cron
              bindings.knative.dev/include: "true"
          spec:
            template:
              spec:
                restartPolicy: Never
                containers:
                  - name: single-heartbeat
                    image: quay.io/openshift-knative/heartbeats:latest
                    args:
                      - --period=1
                    env:
                      - name: ONE_SHOT
                        value: "true"
                      - name: POD_NAME
                        valueFrom:
                          fieldRef:
                            fieldPath: metadata.name
                      - name: POD_NAMESPACE
                        valueFrom:
                          fieldRef:
                            fieldPath: metadata.namespace
      중요

      싱크 바인딩을 사용하려면 Knative CR에 bindings.knative.dev/include=true 라벨을 수동으로 추가해야 합니다.

      예를 들어 이 라벨을 CronJob CR에 추가하려면 Job CR YAML 정의에 다음 행을 추가합니다.

        jobTemplate:
          metadata:
            labels:
              app: heartbeat-cron
              bindings.knative.dev/include: "true"
    2. heartbeats-cronjob.yaml 파일을 생성한 후 다음을 입력하여 적용합니다.

      $ oc apply -f heartbeats-cronjob.yaml
  4. 다음 명령을 입력하고 출력을 검사하여 컨트롤러가 올바르게 매핑되는지 확인합니다.

    $ kn source binding describe bind-heartbeat

    출력 예

    Name:         bind-heartbeat
    Namespace:    demo-2
    Annotations:  sources.knative.dev/creator=minikube-user, sources.knative.dev/lastModifier=minikub ...
    Age:          2m
    Subject:
      Resource:   job (batch/v1)
      Selector:
        app:      heartbeat-cron
    Sink:
      Name:       event-display
      Resource:   Service (serving.knative.dev/v1)
    
    Conditions:
      OK TYPE     AGE REASON
      ++ Ready     2m

검증

메시지 덤퍼 기능 로그를 보면 Kubernetes 이벤트가 Knative 이벤트 싱크로 전송되었는지 확인할 수 있습니다.

  • 다음 명령을 입력하여 메시지 덤퍼 기능 로그를 확인합니다.

    $ oc get pods
    $ oc logs $(oc get pod -o name | grep event-display) -c user-container

    출력 예

    ☁️  cloudevents.Event
    Validation: valid
    Context Attributes,
      specversion: 1.0
      type: dev.knative.eventing.samples.heartbeat
      source: https://knative.dev/eventing-contrib/cmd/heartbeats/#event-test/mypod
      id: 2b72d7bf-c38f-4a98-a433-608fbcdd2596
      time: 2019-10-18T15:23:20.809775386Z
      contenttype: application/json
    Extensions,
      beats: true
      heart: yes
      the: 42
    Data,
      {
        "id": 1,
        "label": ""
      }

5.11.1.2.1. Knative CLI --sink 플래그

Knative(kn) CLI를 사용하여 event-producing 사용자 정의 리소스를 생성하는 경우 --sink 플래그를 사용하여 이벤트가 해당 리소스에서 로 전송되는 싱크를 지정할 수 있습니다.

다음 예제에서는 싱크로 서비스 http://event-display.svc.cluster.local를 사용하는 싱크 바인딩을 생성합니다.

--sink 플래그를 사용하는 명령의 예

$ kn source binding create bind-heartbeat \
  --namespace sinkbinding-example \
  --subject "Job:batch/v1:app=heartbeat-cron" \
  --sink http://event-display.svc.cluster.local \ 1
  --ce-override "sink=bound"

1
http://event-display.svc.cluster.localsvc는 싱크가 Knative 서비스인지 확인합니다. 기타 기본 싱크 접두사에는 channel, 및 broker가 포함됩니다.

5.11.1.3. 웹 콘솔을 사용하여 싱크 바인딩 생성

OpenShift Container Platform 웹 콘솔에서 기본 싱크 바인딩을 생성하고 확인할 수 있습니다.

사전 요구 사항

개발자 화면을 사용하여 싱크 바인딩을 생성하려면 다음 조건을 충족해야 합니다.

  • OpenShift Serverless Operator, Knative Serving, Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • 웹 콘솔에 로그인했습니다.
  • 개발자 화면에 있습니다.
  • 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.

절차

  1. 싱크로 사용할 Knative 서비스를 생성합니다.

    1. 개발자 화면에서 +추가YAML로 이동합니다.
    2. 예제 YAML을 복사합니다.

      apiVersion: serving.knative.dev/v1
      kind: Service
      metadata:
        name: event-display
      spec:
        template:
          spec:
            containers:
              - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
    3. 생성을 클릭합니다.
  2. 이벤트 소스로 사용되고 1분마다 이벤트를 전송하는 CronJob 리소스를 생성합니다.

    1. 개발자 화면에서 +추가YAML로 이동합니다.
    2. 예제 YAML을 복사합니다.

      apiVersion: batch/v1
      kind: CronJob
      metadata:
        name: heartbeat-cron
      spec:
        # Run every minute
        schedule: "*/1 * * * *"
        jobTemplate:
          metadata:
            labels:
              app: heartbeat-cron
              bindings.knative.dev/include: true 1
          spec:
            template:
              spec:
                restartPolicy: Never
                containers:
                  - name: single-heartbeat
                    image: quay.io/openshift-knative/heartbeats
                    args:
                    - --period=1
                    env:
                      - name: ONE_SHOT
                        value: "true"
                      - name: POD_NAME
                        valueFrom:
                          fieldRef:
                            fieldPath: metadata.name
                      - name: POD_NAMESPACE
                        valueFrom:
                          fieldRef:
                            fieldPath: metadata.namespace
      1
      bindings.knative.dev/include: true 라벨을 포함해야 합니다. OpenShift Serverless의 기본 네임스페이스 선택 동작은 포함 모드를 사용합니다.
    3. 생성을 클릭합니다.
  3. 이전 단계에서 생성한 서비스와 동일한 네임스페이스 또는 이벤트를 보낼 다른 싱크 바인딩을 생성합니다.

    1. 개발자 화면에서 +추가이벤트 소스로 이동합니다. 이벤트 소스 페이지가 표시됩니다.
    2. 선택 사항: 이벤트 소스에 대한 공급자가 여러 개인 경우 공급자 목록에서 필요한 공급자를 선택하여 공급자의 사용 가능한 이벤트 소스를 필터링합니다.
    3. 싱크 바인딩을 선택한 다음 이벤트 소스 생성을 클릭합니다. 이벤트 소스 생성 페이지가 표시됩니다.

      참고

      양식 보기 또는 YAML 보기를 사용하여 Sink 바인딩 설정을 구성하고 보기 간에 전환할 수 있습니다. 다른 보기로 전환해도 데이터는 유지됩니다.

    4. apiVersion 필드에 batch/v1을 입력합니다.
    5. 유형 필드에 Job을 입력합니다.

      참고

      CronJob 종류는 OpenShift Serverless 싱크 바인딩에서 직접 지원하지 않으므로 kind 필드에서 cron 작업 오브젝트 자체 대신 cron 작업 오브젝트에서 생성한 Job 오브젝트를 대상으로 해야 합니다.

    6. 싱크를 선택합니다. 리소스 또는 URI일 수 있습니다. 이 예제에서는 이전 단계에서 생성한 event-display 서비스를 리소스 싱크로 사용합니다.
    7. 레이블 일치 섹션에서 다음을 수행합니다.

      1. 이름 필드에 app을 입력합니다.
      2. 필드에 heartbeat-cron을 입력합니다.

        참고

        레이블 선택기는 리소스 이름이 아니라 싱크 바인딩과 함께 cron 작업을 사용할 때 필요합니다. cron 작업에서 생성한 작업에 예측 가능한 이름이 없고 이름에 무작위로 생성된 문자열이 있기 때문입니다. 예: hearthbeat-cron-1cc23f

    8. 생성을 클릭합니다.

검증

토폴로지 페이지 및 Pod 로그를 확인하여 싱크 바인딩, 싱크 및 cron 작업이 생성되었으며 올바르게 작동하는지 확인할 수 있습니다.

  1. 개발자 화면에서 토폴로지로 이동합니다.
  2. 싱크 바인딩, 싱크 및 하트비트 cron 작업을 확인합니다.

    토폴로지 보기에서 싱크 바인딩 및 서비스 보기
  3. 싱크 바인딩이 추가되면 cron 작업에 의해 성공한 작업이 등록되고 있는지 확인합니다. 즉, 싱크 바인딩이 cron 작업에서 생성한 작업을 성공적으로 재구성합니다.
  4. event-display 서비스 pod의 로그를 검색하여 heartbeats cron 작업에서 생성한 이벤트를 확인합니다.

5.11.1.4. 싱크 바인딩 참조

이 주제에서는 SinkBinding 오브젝트의 구성 가능한 매개변수에 대한 참조 정보를 제공합니다.

SinkBinding 오브젝트는 다음 매개변수를 지원합니다.

필드설명필수 또는 선택 사항

apiVersion

API 버전을 지정합니다(예: sources.knative.dev/v1).

필수 항목

kind

이 리소스 오브젝트를 SinkBinding 오브젝트로 식별합니다.

필수 항목

metadata

SinkBinding 오브젝트를 고유하게 식별하는 메타데이터를 지정합니다. 예를 들어 이름.

필수 항목

spec

SinkBinding 오브젝트의 구성 정보를 지정합니다.

필수 항목

spec.sink

싱크로 사용할 URI로 확인되는 오브젝트에 대한 참조입니다.

필수 항목

spec.subject

바인딩 구현을 통해 런타임 계약이 보강되는 리소스를 참조합니다.

필수 항목

spec.ceOverrides

싱크로 전송된 이벤트에 대한 출력 형식 및 수정 사항을 제어하는 재정의를 정의합니다.

선택 사항

5.11.1.4.1. Subject 매개변수

Subject 매개변수는 바인딩 구현을 통해 런타임 계약이 보강되는 리소스를 참조합니다.

Subject 정의에서는 다음 필드를 지원합니다.

필드설명필수 또는 선택 사항

apiVersion

참조의 API 버전입니다.

필수 항목

kind

일종의 참조자.

필수 항목

namespace

참조 항목의 네임스페이스입니다. 생략하면 기본값은 오브젝트의 네임스페이스입니다.

선택 사항

name

참조 항목의 이름입니다.

선택기 를 구성하는 경우 를 사용하지 마십시오.

선택기

참조 항목의 선택기입니다.

이름을 구성하는 경우 를 사용하지 마십시오.

selector.matchExpressions

라벨 선택기 요구 사항 목록입니다.

matchExpressions 또는 matchLabels 중 하나만 사용합니다.

selector.matchExpressions.key

선택기가 적용되는 레이블 키입니다.

matchExpressions를 사용하는 경우 필수 항목입니다.

selector.matchExpressions.operator

값 집합에 대한 키의 관계를 나타냅니다. 유효한 연산자는 In,NotIn,ExistsDoesNotExist 입니다.

matchExpressions를 사용하는 경우 필수 항목입니다.

selector.matchExpressions.values

문자열 값의 배열입니다. operator 매개변수 값이 In 또는 NotIn 인 경우 값 배열은 비어 있지 않아야 합니다. operator 매개변수 값이 Exists 또는 DoesNotExist 인 경우 values 배열이 비어 있어야 합니다. 이 배열은 전략적 병합 패치 중에 교체됩니다.

matchExpressions를 사용하는 경우 필수 항목입니다.

selector.matchLabels

키-값 쌍의 맵입니다. matchLabels 맵의 각 키-값 쌍은 matchLabels .<key>matchExpressions 요소와 동등하며, values 배열에 matchLabels.<value> 만 포함됩니다.

matchExpressions 또는 matchLabels 중 하나만 사용합니다.

5.11.1.4.1.1. subject 매개변수 예

다음 YAML에 따라 기본 네임스페이스에서 mysubject 라는 Deployment 오브젝트가 선택됩니다.

apiVersion: sources.knative.dev/v1
kind: SinkBinding
metadata:
  name: bind-heartbeat
spec:
  subject:
    apiVersion: apps/v1
    kind: Deployment
    namespace: default
    name: mysubject
  ...

다음 YAML의 경우 default 네임스페이스에서 레이블이 working=example 인 모든 Job 오브젝트가 선택됩니다.

apiVersion: sources.knative.dev/v1
kind: SinkBinding
metadata:
  name: bind-heartbeat
spec:
  subject:
    apiVersion: batch/v1
    kind: Job
    namespace: default
    selector:
      matchLabels:
        working: example
  ...

다음 YAML의 경우 default 네임스페이스에 working=example 또는 working= sample 라벨이 있는 모든 Pod 오브젝트가 선택됩니다.

apiVersion: sources.knative.dev/v1
kind: SinkBinding
metadata:
  name: bind-heartbeat
spec:
  subject:
    apiVersion: v1
    kind: Pod
    namespace: default
    selector:
      - matchExpression:
        key: working
        operator: In
        values:
          - example
          - sample
  ...
5.11.1.4.2. CloudEvent 덮어쓰기

ceOverrides 정의는 싱크로 전송된 CloudEvent의 출력 형식 및 수정 사항을 제어하는 덮어쓰기를 제공합니다.

ceOverrides 정의는 다음 필드를 지원합니다.

필드설명필수 또는 선택 사항

extensions

아웃바운드 이벤트에서 추가 또는 재정의되는 속성을 지정합니다. 각 확장 기능 키-값 쌍은 이벤트에 특성 확장으로 독립적으로 설정됩니다.

선택 사항

참고

유효한 CloudEvent 특성 이름만 확장으로 허용됩니다. 확장 기능 재정의 구성에서 사양 정의 속성을 설정할 수 없습니다. 예를 들어 type 특성을 수정할 수 없습니다.

CloudEvent Overrides 예

apiVersion: sources.knative.dev/v1
kind: SinkBinding
metadata:
  name: bind-heartbeat
spec:
  ...
  ceOverrides:
    extensions:
      extra: this is an extra attribute
      additional: 42

그러면 제목에 K_CE_OVERRIDES 환경 변수가 설정됩니다.

출력 예

{ "extensions": { "extra": "this is an extra attribute", "additional": "42" } }

5.11.1.4.3. include 레이블

SinkBinding을 사용하려면 리소스 또는 네임스페이스에 bindings.knative.dev/include: "true" 레이블을 할당해야 합니다. 리소스 정의에 라벨이 포함되지 않은 경우 클러스터 관리자는 다음을 실행하여 네임스페이스에 연결할 수 있습니다.

$ oc label namespace <namespace> bindings.knative.dev/include=true

5.11.2. 컨테이너 소스 사용

컨테이너 소스는 이벤트를 생성하고 이벤트를 싱크로 보내는 컨테이너 이미지를 생성합니다. 이미지 URI를 사용하는 ContainerSource 오브젝트와 컨테이너 이미지를 생성하여 사용자 지정 이벤트 소스를 생성할 수 있습니다.

5.11.2.1. 컨테이너 이미지 생성을 위한 지침

  • 컨테이너 소스 컨트롤러에서 두 개의 환경 변수를 삽입합니다. K_SI 및 K_CE_OVERRIDES. 이러한 변수는 sinkceOverrides 사양에서 확인됩니다.
  • 이벤트 메시지는 K_SINK 환경 변수에 지정된 싱크 URI로 전송됩니다. 이벤트 메시지는 모든 형식이 될 수 있지만 CloudEvent 사양을 사용하는 것이 좋습니다.
5.11.2.1.1. 컨테이너 이미지의 예

다음은 하트비트 컨테이너 이미지의 예입니다.

package main

import (
	"context"
	"encoding/json"
	"flag"
	"fmt"
	"log"
	"os"
	"strconv"
	"time"

	duckv1 "knative.dev/pkg/apis/duck/v1"

	cloudevents "github.com/cloudevents/sdk-go/v2"
	"github.com/kelseyhightower/envconfig"
)

type Heartbeat struct {
	Sequence int    `json:"id"`
	Label    string `json:"label"`
}

var (
	eventSource string
	eventType   string
	sink        string
	label       string
	periodStr   string
)

func init() {
	flag.StringVar(&eventSource, "eventSource", "", "the event-source (CloudEvents)")
	flag.StringVar(&eventType, "eventType", "dev.knative.eventing.samples.heartbeat", "the event-type (CloudEvents)")
	flag.StringVar(&sink, "sink", "", "the host url to heartbeat to")
	flag.StringVar(&label, "label", "", "a special label")
	flag.StringVar(&periodStr, "period", "5", "the number of seconds between heartbeats")
}

type envConfig struct {
	// Sink URL where to send heartbeat cloud events
	Sink string `envconfig:"K_SINK"`

	// CEOverrides are the CloudEvents overrides to be applied to the outbound event.
	CEOverrides string `envconfig:"K_CE_OVERRIDES"`

	// Name of this pod.
	Name string `envconfig:"POD_NAME" required:"true"`

	// Namespace this pod exists in.
	Namespace string `envconfig:"POD_NAMESPACE" required:"true"`

	// Whether to run continuously or exit.
	OneShot bool `envconfig:"ONE_SHOT" default:"false"`
}

func main() {
	flag.Parse()

	var env envConfig
	if err := envconfig.Process("", &env); err != nil {
		log.Printf("[ERROR] Failed to process env var: %s", err)
		os.Exit(1)
	}

	if env.Sink != "" {
		sink = env.Sink
	}

	var ceOverrides *duckv1.CloudEventOverrides
	if len(env.CEOverrides) > 0 {
		overrides := duckv1.CloudEventOverrides{}
		err := json.Unmarshal([]byte(env.CEOverrides), &overrides)
		if err != nil {
			log.Printf("[ERROR] Unparseable CloudEvents overrides %s: %v", env.CEOverrides, err)
			os.Exit(1)
		}
		ceOverrides = &overrides
	}

	p, err := cloudevents.NewHTTP(cloudevents.WithTarget(sink))
	if err != nil {
		log.Fatalf("failed to create http protocol: %s", err.Error())
	}

	c, err := cloudevents.NewClient(p, cloudevents.WithUUIDs(), cloudevents.WithTimeNow())
	if err != nil {
		log.Fatalf("failed to create client: %s", err.Error())
	}

	var period time.Duration
	if p, err := strconv.Atoi(periodStr); err != nil {
		period = time.Duration(5) * time.Second
	} else {
		period = time.Duration(p) * time.Second
	}

	if eventSource == "" {
		eventSource = fmt.Sprintf("https://knative.dev/eventing-contrib/cmd/heartbeats/#%s/%s", env.Namespace, env.Name)
		log.Printf("Heartbeats Source: %s", eventSource)
	}

	if len(label) > 0 && label[0] == '"' {
		label, _ = strconv.Unquote(label)
	}
	hb := &Heartbeat{
		Sequence: 0,
		Label:    label,
	}
	ticker := time.NewTicker(period)
	for {
		hb.Sequence++

		event := cloudevents.NewEvent("1.0")
		event.SetType(eventType)
		event.SetSource(eventSource)
		event.SetExtension("the", 42)
		event.SetExtension("heart", "yes")
		event.SetExtension("beats", true)

		if ceOverrides != nil && ceOverrides.Extensions != nil {
			for n, v := range ceOverrides.Extensions {
				event.SetExtension(n, v)
			}
		}

		if err := event.SetData(cloudevents.ApplicationJSON, hb); err != nil {
			log.Printf("failed to set cloudevents data: %s", err.Error())
		}

		log.Printf("sending cloudevent to %s", sink)
		if res := c.Send(context.Background(), event); !cloudevents.IsACK(res) {
			log.Printf("failed to send cloudevent: %v", res)
		}

		if env.OneShot {
			return
		}

		// Wait for next tick
		<-ticker.C
	}
}

다음은 이전 하트비트 컨테이너 이미지를 참조하는 컨테이너 소스의 예입니다.

apiVersion: sources.knative.dev/v1
kind: ContainerSource
metadata:
  name: test-heartbeats
spec:
  template:
    spec:
      containers:
        # This corresponds to a heartbeats image URI that you have built and published
        - image: gcr.io/knative-releases/knative.dev/eventing/cmd/heartbeats
          name: heartbeats
          args:
            - --period=1
          env:
            - name: POD_NAME
              value: "example-pod"
            - name: POD_NAMESPACE
              value: "event-test"
  sink:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: example-service
...

5.11.2.2. Knative CLI를 사용하여 컨테이너 소스 생성 및 관리

다음 kn 명령을 사용하여 컨테이너 소스를 생성하고 관리할 수 있습니다.

컨테이너 소스 생성

$ kn source container create <container_source_name> --image <image_uri> --sink <sink>

컨테이너 소스 삭제

$ kn source container delete <container_source_name>

컨테이너 소스 설명

$ kn source container describe <container_source_name>

기존 컨테이너 소스 나열

$ kn source container list

YAML 형식으로 기존 컨테이너 소스 나열

$ kn source container list -o yaml

컨테이너 소스 업데이트

이 명령은 기존 컨테이너 소스의 이미지 URI를 업데이트합니다.

$ kn source container update <container_source_name> --image <image_uri>

5.11.2.3. 웹 콘솔을 사용하여 컨테이너 소스 생성

OpenShift Container Platform 웹 콘솔의 개발자 화면을 사용하여 컨테이너 소스를 만들 수 있습니다.

사전 요구 사항

개발자 화면을 사용하여 컨테이너 소스를 생성하려면 다음을 확인하십시오.

  • OpenShift Serverless Operator 및 Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • 웹 콘솔에 로그인했습니다.
  • 개발자 화면에 있습니다.
  • 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.

절차

  1. 개발자 화면에서 +추가이벤트 소스로 이동합니다. 이벤트 소스 페이지가 표시됩니다.
  2. 컨테이너 소스를 선택한 다음 이벤트 소스 생성을 클릭합니다. 이벤트 소스 생성 페이지가 표시됩니다.
  3. 양식 보기 또는 YAML 보기를 사용하여 컨테이너 소스 설정을 구성합니다.

    참고

    양식 보기YAML 보기를 전환할 수 있습니다. 다른 보기로 전환해도 데이터는 유지됩니다.

    1. 이미지 필드에 컨테이너 소스에서 생성한 컨테이너에서 실행할 이미지의 URI를 입력합니다.
    2. 이름 필드에 이미지 이름을 입력합니다.
    3. 선택 사항: 인수 필드에 컨테이너에 전달할 인수를 입력합니다.
    4. 선택 사항: 환경 변수 필드에서 컨테이너에 설정할 환경 변수를 추가합니다.
    5. 싱크 섹션에서 컨테이너 소스의 이벤트가 라우팅되는 싱크를 추가합니다. 양식 보기를 사용하는 경우 다음 옵션 중에서 선택할 수 있습니다.

      1. 리소스에서 채널, 브로커 또는 서비스를 이벤트 소스의 싱크로 사용합니다.
      2. URI를 선택하여 컨테이너 소스의 이벤트가 라우팅되는 위치를 지정합니다.
  4. 컨테이너 소스 구성을 완료한 후 생성을 클릭합니다.

5.11.2.4. 컨테이너 소스 참조

이 주제에서는 ContainerSource 오브젝트의 구성 가능 필드에 대한 참조 정보를 제공합니다.

ContainerSource 오브젝트는 다음 필드를 지원합니다.

필드설명필수 또는 선택 사항

apiVersion

API 버전을 지정합니다(예: sources.knative.dev/v1).

필수 항목

kind

이 리소스 오브젝트를 ContainerSource 오브젝트로 식별합니다.

필수 항목

metadata

ContainerSource 오브젝트를 고유하게 식별하는 메타데이터를 지정합니다. 예를 들어 이름.

필수 항목

spec

ContainerSource 오브젝트에 대한 구성 정보를 지정합니다.

필수 항목

spec.sink

싱크로 사용할 URI로 확인되는 오브젝트에 대한 참조입니다.

필수 항목

spec.template

ContainerSource 오브젝트의 템플릿 사양입니다.

필수 항목

spec.ceOverrides

싱크로 전송된 이벤트에 대한 출력 형식 및 수정 사항을 제어하는 재정의를 정의합니다.

선택 사항

5.11.2.4.1. 템플릿 매개변수 예
apiVersion: sources.knative.dev/v1
kind: ContainerSource
metadata:
  name: test-heartbeats
spec:
  template:
    spec:
      containers:
        - image: quay.io/openshift-knative/heartbeats:latest
          name: heartbeats
          args:
            - --period=1
          env:
            - name: POD_NAME
              value: "mypod"
            - name: POD_NAMESPACE
              value: "event-test"
  ...
5.11.2.4.2. CloudEvent 덮어쓰기

ceOverrides 정의는 싱크로 전송된 CloudEvent의 출력 형식 및 수정 사항을 제어하는 덮어쓰기를 제공합니다.

ceOverrides 정의는 다음 필드를 지원합니다.

필드설명필수 또는 선택 사항

extensions

아웃바운드 이벤트에서 추가 또는 재정의되는 속성을 지정합니다. 각 확장 기능 키-값 쌍은 이벤트에 특성 확장으로 독립적으로 설정됩니다.

선택 사항

참고

유효한 CloudEvent 특성 이름만 확장으로 허용됩니다. 확장 기능 재정의 구성에서 사양 정의 속성을 설정할 수 없습니다. 예를 들어 type 특성을 수정할 수 없습니다.

CloudEvent Overrides 예

apiVersion: sources.knative.dev/v1
kind: ContainerSource
metadata:
  name: test-heartbeats
spec:
  ...
  ceOverrides:
    extensions:
      extra: this is an extra attribute
      additional: 42

그러면 제목에 K_CE_OVERRIDES 환경 변수가 설정됩니다.

출력 예

{ "extensions": { "extra": "this is an extra attribute", "additional": "42" } }

5.12. 채널 생성 및 삭제

개발자는 지원되는 Channel 오브젝트를 인스턴스화하여 채널을 생성할 수 있습니다.

Channel 오브젝트를 생성한 후에는 변경 승인 Webhook에서 기본 채널 구현을 기반으로 Channel 오브젝트에 일련의 spec.channelTemplate 속성을 추가합니다. 예를 들어 InMemoryChannel 기본 구현의 경우 Channel 오브젝트는 다음과 같습니다.

apiVersion: messaging.knative.dev/v1
kind: Channel
metadata:
  name: example-channel
  namespace: default
spec:
  channelTemplate:
    apiVersion: messaging.knative.dev/v1
    kind: InMemoryChannel
참고

spec.channelTemplate 속성은 사용자가 아닌 기본 채널 메커니즘에 의해 설정되기 때문에 생성 후에는 변경할 수 없습니다.

그런 다음 채널 컨트롤러에서 spec.channelTemplate 구성에 따라 지원 채널 인스턴스를 생성합니다.

이 메커니즘을 앞의 예제와 함께 사용하면 일반 지원 채널과 InMemoryChannel 채널이라는 두 개의 오브젝트가 생성됩니다. 다른 기본 채널 구현을 사용하는 경우 InMemoryChannel이 구현에 고유한 채널로 교체됩니다. 예를 들어 Knative Kafka를 사용하면 KafkaChannel 채널이 생성됩니다.

지원 채널은 서브스크립션을 사용자가 생성한 채널 오브젝트에 복사하고 지원 채널의 상태를 반영하도록 사용자가 생성한 채널 오브젝트의 상태를 설정하는 프록시 역할을 합니다.

5.12.1. 개발자 화면을 사용하여 채널 생성

OpenShift Container Platform 웹 콘솔을 사용하여 클러스터 기본 구성으로 채널을 생성할 수 있습니다.

사전 요구 사항

개발자 화면을 사용하여 채널을 생성하려면 다음 조건을 충족해야 합니다.

  • OpenShift Serverless Operator 및 Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • 웹 콘솔에 로그인했습니다.
  • 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.

절차

  1. 개발자 화면에서 +추가채널로 이동합니다.
  2. 유형 드롭다운에서 생성할 Channel 오브젝트 유형을 선택합니다.

    참고

    현재 InMemoryChannel 유형의 Channel 오브젝트만 지원됩니다.

  3. 생성을 클릭합니다.

검증

  • 토폴로지 페이지로 이동하여 채널이 있는지 확인합니다.

    토폴로지 보기에서 채널 보기

5.12.2. Knative CLI를 사용하여 채널 생성

kn CLI를 사용하여 클러스터 기본 구성으로 채널을 생성할 수 있습니다.

사전 요구 사항

kn CLI를 사용하여 채널을 생성하려면 다음을 수행하십시오.

  • OpenShift Serverless Operator 및 Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • kn CLI를 설치했습니다.
  • 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.

절차

  • 채널을 생성합니다.

    $ kn channel create <channel_name> --type <channel_type>

    채널 유형은 선택 사항이지만 지정된 위치는 Group:Version:Kind 형식으로 지정해야 합니다. 예를 들면 InMemoryChannel 오브젝트를 생성할 수 있습니다.

    $ kn channel create mychannel --type messaging.knative.dev:v1:InMemoryChannel

    출력 예

    Channel 'mychannel' created in namespace 'default'.

검증

  • 채널이 존재하는지 확인하려면 기존 채널을 나열하고 출력을 검사합니다.

    $ kn channel list

    출력 예

    kn channel list
    NAME        TYPE              URL                                                     AGE   READY   REASON
    mychannel   InMemoryChannel   http://mychannel-kn-channel.default.svc.cluster.local   93s   True

5.12.3. YAML을 사용하여 기본 구현 채널 생성

클러스터 기본 구성으로 YAML을 사용하여 채널을 생성할 수 있습니다.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.

절차

Channel 오브젝트를 생성하려면 다음을 수행합니다.

  1. YAML 파일을 생성하고 다음 샘플 코드를 여기에 복사합니다.

    apiVersion: messaging.knative.dev/v1
    kind: Channel
    metadata:
      name: example-channel
      namespace: default
  2. YAML 파일을 적용합니다.

    $ oc apply -f <filename>

5.12.4. YAML을 사용하여 Kafka 채널 생성

YAML로 KafkaChannel 오브젝트를 생성하여 Kafka 채널을 생성할 수 있습니다.

사전 요구 사항

  • OpenShift Serverless Operator, Knative Eventing, KnativeKafka 사용자 정의 리소스가 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.

절차

  1. KafkaChannel 오브젝트를 YAML 파일로 생성합니다.

    apiVersion: messaging.knative.dev/v1beta1
    kind: KafkaChannel
    metadata:
      name: example-channel
      namespace: default
    spec:
      numPartitions: 3
      replicationFactor: 1
    중요

    OpenShift Serverless의 KafkaChannel 오브젝트에 대한 API의 v1beta1 버전만 지원됩니다. 이 버전은 더 이상 사용되지 않으므로 이 API의 v1alpha1 버전을 사용하지 마십시오.

  2. KafkaChannel YAML 파일을 적용합니다.

    $ oc apply -f <filename>

5.12.5. Knative CLI를 사용하여 채널 삭제

kn CLI를 사용하여 클러스터 기본 구성으로 채널을 삭제할 수 있습니다.

절차

  • 채널을 삭제합니다.

    $ kn channel delete <channel_name>

5.12.6. 다음 단계

  • 채널을 생성한 후 이벤트 전달을 위해 서브스크립션 생성 및 사용에 대한 정보는 서브스크립션 사용을 참조하십시오.

5.13. 서브스크립션

이벤트 소스 또는 생산자에서 채널로 이벤트를 보낸 후에는 서브스크립션을 통해 이러한 이벤트를 여러 Knative 서비스 또는 기타 싱크로 보낼 수 있습니다.

채널 워크플로 개요

구독자가 이벤트를 거부하면 기본적으로 재전송을 시도하지 않습니다. 개발자는Subscription 오브젝트의 delivery 사양을 수정하여 재전송 시도 횟수를 구성할 수 있습니다.

5.13.1. 서브스크립션 생성

개발자는 이벤트 싱크에서 채널을 구독하고 이벤트를 수신할 수 있는 서브스크립션을 생성할 수 있습니다.

5.13.1.1. 개발자 화면에서 서브스크립션 생성

사전 요구 사항

개발자 화면을 사용하여 서브스크립션을 생성하려면 다음 조건을 충족해야 합니다.

  • OpenShift Serverless Operator, Knative Serving, Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • 웹 콘솔에 로그인했습니다.
  • 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
  • 이벤트 싱크(예: Knative 서비스) 및 채널을 생성했습니다.

절차

  1. 개발자 화면에서 토폴로지 페이지로 이동합니다.
  2. 다음 방법 중 하나를 사용하여 서브스크립션을 생성합니다.

    1. 서브스크립션을 생성할 채널 위로 마우스 커서를 이동하고 화살표를 끕니다. 서브스크립션 추가 옵션이 표시됩니다.

      채널에 대한 서브스크립션 생성
      1. 드롭다운 목록에서 싱크를 구독자로 선택합니다.
      2. 추가를 클릭합니다.
    2. 채널과 동일한 네임스페이스 또는 프로젝트의 토폴로지 보기에서 서비스를 사용할 수 있는 경우, 서브스크립션을 생성할 채널을 클릭하고 화살표를 서비스로 직접 끌어 채널에서 해당 서비스로의 서브스크립션을 즉시 생성합니다.

검증

  • 서브스크립션이 생성되면 토폴로지 보기에 채널을 서비스에 연결하는 선이 표시되어 이를 확인할 수 있습니다.

    토폴로지 보기의 서브스크립션

    서비스를 클릭하면 이벤트 소스, 채널, 서브스크립션을 볼 수 있습니다.

5.13.1.2. Knative CLI를 사용하여 서브스크립션 생성

kn CLI를 사용하여 채널을 싱크에 연결하는 서브스크립션을 생성할 수 있습니다.

사전 요구 사항

kn CLI를 사용하여 서브스크립션을 생성하려면 다음 조건을 충족해야 합니다.

  • OpenShift Serverless Operator 및 Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • kn CLI를 설치했습니다.
  • 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.

절차

  • 싱크를 채널에 연결하는 서브스크립션을 생성합니다.

    $ kn subscription create <subscription_name> \
      --channel <group:version:kind>:<channel_name> \ 1
      --sink <sink_prefix>:<sink_name> \ 2
      --sink-dead-letter <sink_prefix>:<sink_name> 3
    1
    --channel은 처리해야 하는 클라우드 이벤트의 소스를 지정합니다. 채널 이름을 제공해야 합니다. 채널 사용자 정의 리소스에서 지원하는 기본 InMemoryChannel 채널을 사용하지 않는 경우 Channel 이름 앞에 지정된 채널 유형에 대해 <group:version:kind>를 추가해야 합니다. 예를 들어 Kafka 백업 채널의 경우 messaging.knative.dev:v1beta1:KafkaChannel이 됩니다.
    2
    --sink는 이벤트를 전달해야 하는 대상 대상을 지정합니다. 기본적으로 <sink_name>은 서브스크립션과 동일한 네임스페이스에서 이 이름의 Knative 서비스로 해석됩니다. 다음 접두사 중 하나를 사용하여 싱크 유형을 지정할 수 있습니다.
    ksvc
    Knative 서비스입니다.
    channel
    대상으로 사용해야 하는 채널입니다. 여기에서는 기본 채널 유형만 참조할 수 있습니다.
    broker
    Eventing 브로커입니다.
    3
    선택 사항: --sink-dead-letter는 이벤트를 전달하지 못하는 경우 이벤트를 전송해야 하는 싱크를 지정하는 데 사용할 선택적 플래그입니다. 자세한 내용은 OpenShift Serverless Event 제공 설명서를 참조하십시오.

    명령 예

    $ kn subscription create mysubscription --channel mychannel --sink ksvc:event-display

    출력 예

    Subscription 'mysubscription' created in namespace 'default'.

검증

  • 채널이 서브스크립션을 통해 이벤트 싱크 또는 구독자에 연결되어 있는지 확인하려면 기존 서브스크립션을 나열하고 출력을 검사합니다.

    $ kn subscription list

    출력 예

    NAME            CHANNEL             SUBSCRIBER           REPLY   DEAD LETTER SINK   READY   REASON
    mysubscription   Channel:mychannel   ksvc:event-display                              True

5.13.1.3. YAML을 사용하여 서브스크립션 생성

YAML을 사용하여 채널을 싱크에 연결하는 서브스크립션을 생성할 수 있습니다.

절차

  • Subscription 오브젝트를 생성합니다.

    • YAML 파일을 생성하고 다음 샘플 코드를 여기에 복사합니다.

      apiVersion: messaging.knative.dev/v1beta1
      kind: Subscription
      metadata:
        name: my-subscription 1
        namespace: default
      spec:
        channel: 2
          apiVersion: messaging.knative.dev/v1beta1
          kind: Channel
          name: example-channel
        delivery: 3
          deadLetterSink:
            ref:
              apiVersion: serving.knative.dev/v1
              kind: Service
              name: error-handler
        subscriber: 4
          ref:
            apiVersion: serving.knative.dev/v1
            kind: Service
            name: event-display
      1
      서브스크립션 이름입니다.
      2
      서브스크립션이 연결되는 채널의 구성 설정입니다.
      3
      이벤트 전달을 위한 구성 설정입니다. 이 설정은 구독자에게 전달할 수 없는 이벤트에 어떤 일이 발생하는지 스브스크립션에 알립니다. 이 값을 구성하면 사용할 수 없는 이벤트가 deadLetterSink로 전송됩니다. 이벤트가 삭제되고 이벤트 재전송이 시도되지 않으며 시스템에 오류가 기록됩니다. deadLetterSink 값은 대상이어야 합니다.
      4
      구독자에 대한 구성 설정입니다. 채널에서 이벤트가 전달되는 이벤트 싱크입니다.
    • YAML 파일을 적용합니다.

      $ oc apply -f <filename>

5.13.2. 서브스크립션을 사용하여 이벤트 전달 실패 매개변수 구성

개발자는 Subscription 오브젝트의 전달 설정을 수정하여 개별 서브스크립션에 대한 이벤트 delivery 매개 변수를 구성할 수 있습니다.

서브스크립션 YAML의 예

apiVersion: messaging.knative.dev/v1
kind: Subscription
metadata:
  name: <subscription_name>
  namespace: <subscription_namespace>
spec:
  delivery:
    deadLetterSink: 1
      ref:
        apiVersion: serving.knative.dev/v1
        kind: Service
        name: <sink_name>
    backoffDelay: <duration> 2
    backoffPolicy: <policy_type> 3
    retry: <integer> 4

1
dead letter sink를 사용하여 활성화할 구성 설정입니다. 이 설정은 구독자에게 전달할 수 없는 이벤트에 어떤 일이 발생하는지 스브스크립션에 알립니다.

이 값을 구성하면 배달 할 수없는 이벤트가 dead letter sink의 목적지로 전송됩니다. 대상은 Knative 서비스 또는 URI일 수 있습니다.

2
backoffDelay 전달 매개변수를 설정하여 실패 후 이벤트 전달을 재시도하기 전에 시간 지연을 지정할 수 있습니다. backoffDelay 매개변수의 기간은 ISO 8601 형식을 사용하여 지정합니다. 예를 들어 PT1S는 1초 지연을 지정합니다.
3
backoffPolicy 전달 매개 변수를 사용하여 재시도 정책을 지정할 수 있습니다. 정책을 linear 또는 exponential로 지정할 수 있습니다. linear 백오프 정책을 사용할 때 백오프 지연은 재시도 사이에 지정된 시간 간격입니다. exponential 백오프 정책을 사용하는 경우 백오프 지연은 backoffDelay*2^<numberOfRetries>와 동일합니다.
4
이벤트가 dead letter sink로 전송되기 전에 이벤트 전달을 재시도하는 횟수입니다.

5.13.3. Knative CLI를 사용하여 서브스크립션 설명

kn CLI를 사용하여 터미널에서 서브스크립션에 대한 정보를 출력할 수 있습니다.

사전 요구 사항

kn CLI를 사용하여 서브스크립션을 설명하려면 다음 조건을 충족해야 합니다.

  • kn CLI를 설치했습니다.
  • 클러스터에 서브스크립션이 생성되어 있습니다.

절차

  • 서브스크립션을 설명합니다.

    $ kn subscription describe <subscription_name>

    출력 예

    Name:            my-subscription
    Namespace:       default
    Annotations:     messaging.knative.dev/creator=openshift-user, messaging.knative.dev/lastModifier=min ...
    Age:             43s
    Channel:         Channel:my-channel (messaging.knative.dev/v1)
    Subscriber:
      URI:           http://edisplay.default.example.com
    Reply:
      Name:          default
      Resource:      Broker (eventing.knative.dev/v1)
    DeadLetterSink:
      Name:          my-sink
      Resource:      Service (serving.knative.dev/v1)
    
    Conditions:
      OK TYPE                  AGE REASON
      ++ Ready                 43s
      ++ AddedToChannel        43s
      ++ ChannelReady          43s
      ++ ReferencesResolved    43s

5.13.4. Knative CLI를 사용하여 서브스크립션 나열

kn CLI를 사용하여 클러스터의 기존 서브스크립션을 나열할 수 있습니다.

사전 요구 사항

  • kn CLI를 설치했습니다.

절차

  • 클러스터의 서브스크립션을 나열합니다.

    $ kn subscription list

    출력 예

    NAME             CHANNEL             SUBSCRIBER           REPLY   DEAD LETTER SINK   READY   REASON
    mysubscription   Channel:mychannel   ksvc:event-display                              True

5.13.5. Knative CLI를 사용하여 서브스크립션 업데이트

kn CLI를 사용하여 서브스크립션을 업데이트할 수 있습니다.

사전 요구 사항

kn CLI를 사용하여 서브스크립션을 업데이트하려면 다음 조건을 충족해야 합니다.

  • OpenShift Serverless Operator 및 Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • kn CLI를 설치했습니다.
  • OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
  • 서브스크립션이 생성되어 있습니다.

절차

  • 서브스크립션을 업데이트합니다.

    $ kn subscription update <subscription_name> \
      --sink <sink_prefix>:<sink_name> \ 1
      --sink-dead-letter <sink_prefix>:<sink_name> 2
    1
    --sink는 이벤트를 전달해야 하는 업데이트된 대상을 지정합니다. 다음 접두사 중 하나를 사용하여 싱크 유형을 지정할 수 있습니다.
    ksvc
    Knative 서비스입니다.
    channel
    대상으로 사용해야 하는 채널입니다. 여기에서는 기본 채널 유형만 참조할 수 있습니다.
    broker
    Eventing 브로커입니다.
    2
    선택 사항: --sink-dead-letter는 이벤트를 전달하지 못하는 경우 이벤트를 전송해야 하는 싱크를 지정하는 데 사용할 선택적 플래그입니다. 자세한 내용은 OpenShift Serverless Event 제공 설명서를 참조하십시오.

    명령 예

    $ kn subscription update mysubscription --sink ksvc:event-display

5.13.6. Knative CLI를 사용하여 서브스크립션 삭제

kn CLI를 사용하여 서브스크립션을 삭제할 수 있습니다.

절차

  • 서브스크립션을 삭제합니다.

    $ kn subscription delete <subscription_name>

6장. 관리

6.1. OpenShift Serverless 구성

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> 항목이 있으며 구성 맵 데이터에 사용되는 값이 있습니다.

글로벌 구성의 예

KnativeServing 사용자 정의 리소스에서 다음과 같이 config-domain 구성 맵 을 사용하도록 지정할 수 있습니다.

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  config:
    domain: 1
      example.org: |
        selector:
          app: prod
      example.com: ""
1
config-domain 구성 맵을 지정합니다.

여러 구성 맵에 값을 적용할 수 있습니다. 이 예제에서는 config -autoscaler 구성 맵에서 stable- window 를 60s로 설정하고 config-domain 구성 맵 을 지정합니다.

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  config:
    domain: 1
      example.org: |
        selector:
          app: prod
      example.com: ""
    autoscaler: 2
      stable-window: "60s"
1
config-domain 구성 맵을 지정합니다.
2
config -autoscaler 구성 맵에서 stable- window 설정을 지정합니다.

6.2. 채널 기본값 구성

클러스터 관리자 권한이 있는 경우 전체 클러스터 또는 특정 네임스페이스에 대해 채널에 대한 기본 옵션을 설정할 수 있습니다. 이러한 옵션은 구성 맵을 사용하여 수정합니다.

6.2.1. 기본 채널 구현 구성

default-ch-webhook 구성 맵을 사용하여 클러스터 또는 하나 이상의 네임스페이스에 대한 기본 채널 구현을 지정할 수 있습니다.

OpenShift Serverless Operator를 사용하여 변경 사항을 전파하면 default-ch-webhook 구성 맵을 포함하여 knative-eventing 네임스페이스 구성 맵을 변경할 수 있습니다. 이렇게 하려면 KnativeEventing 사용자 정의 리소스를 수정해야 합니다.

사전 요구 사항

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

절차

  • 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.3. OpenShift Serverless와 Service Mesh 통합

OpenShift Serverless에서 Service Mesh를 사용하면 개발자가 추가 네트워킹 및 라우팅 옵션을 구성할 수 있습니다.

OpenShift Serverless Operator는 Kourier를 Knative의 기본 수신으로 제공합니다. 그러나 Kourier가 활성화되어 있는지 여부에 관계없이 OpenShift Serverless에서 Service Mesh를 사용할 수 있습니다. Kourier disabled와 통합하면 Kourier 인그레스에서 지원하지 않는 추가 네트워킹 및 라우팅 옵션을 구성할 수 있습니다.

중요

OpenShift Serverless는 본 안내서에 명시되어 있는 Red Hat OpenShift Service Mesh 기능만 지원하며 문서화되지 않은 다른 기능은 지원하지 않습니다.

6.3.1. 기본적으로 OpenShift Serverless와 Service Mesh를 통합

Kourier 없이 기본적으로 OpenShift Serverless와 Service Mesh를 통합하면 mTLS 기능과 같은 기본 Kourier 수신에서 지원하지 않는 추가 네트워킹 및 라우팅 옵션을 사용할 수 있습니다.

다음 절차의 예제에서는 도메인 example.com을 사용합니다. 이 도메인에 사용되는 예제 인증서는 하위 도메인 인증서에 서명하는 CA(인증 기관)로 사용됩니다.

배포에서 이 절차를 완료하고 확인하려면 널리 신뢰받는 공용 CA에서 서명한 인증서 또는 조직에서 제공하는 CA가 필요합니다. 도메인, 하위 도메인, CA에 따라 예제 명령을 조정해야 합니다.

OpenShift Container Platform 클러스터의 도메인과 일치하도록 와일드카드 인증서를 구성해야 합니다. 예를 들어 OpenShift Container Platform 콘솔 주소가 https://console-openshift-console.apps.openshift.example.com인 경우 도메인이 *.apps.openshift.example.com이 되도록 와일드카드 인증서를 구성해야 합니다. 와일드카드 인증서 구성에 대한 자세한 내용은 수신되는 외부 트래픽을 암호화하기 위한 인증서 생성에 관한 다음의 내용을 참조하십시오.

기본 OpenShift Container Platform 클러스터 도메인의 하위 도메인이 아닌 도메인 이름을 사용하려면 해당 도메인에 대한 도메인 매핑을 설정해야 합니다. 자세한 내용은 사용자 정의 도메인 매핑 생성에 대한 OpenShift Serverless 설명서를 참조하십시오.

6.3.1.1. 수신 외부 트래픽을 암호화하기 위한 인증서 생성

기본적으로 Service Mesh mTLS 기능은 사이드카가 있는 수신 게이트웨이와 개별 Pod 간에 Service Mesh 자체의 트래픽만 보호합니다. OpenShift Container Platform 클러스터로 전달될 때 트래픽을 암호화하려면 OpenShift Serverless 및 Service Mesh 통합을 활성화하기 전에 인증서를 생성해야 합니다.

절차

  1. Knative 서비스의 인증서에 서명할 root 인증서 및 개인 키를 생성합니다.

    $ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 \
        -subj '/O=Example Inc./CN=example.com' \
        -keyout root.key \
        -out root.crt
  2. 와일드카드 인증서를 만듭니다.

    $ openssl req -nodes -newkey rsa:2048 \
        -subj "/CN=*.apps.openshift.example.com/O=Example Inc." \
        -keyout wildcard.key \
        -out wildcard.csr
  3. 와일드카드 인증서를 서명합니다.

    $ openssl x509 -req -days 365 -set_serial 0 \
        -CA root.crt \
        -CAkey root.key \
        -in wildcard.csr \
        -out wildcard.crt
  4. 와일드카드 인증서를 사용하여 시크릿을 생성합니다.

    $ oc create -n istio-system secret tls wildcard-certs \
        --key=wildcard.key \
        --cert=wildcard.crt

    이 인증서는 OpenShift Serverless를 Service Mesh와 통합할 때 생성된 게이트웨이에서 선택하여 수신 게이트웨이가 이 인증서와 트래픽을 제공하도록 합니다.

6.3.1.2. OpenShift Serverless와 Service Mesh 통합

다음 절차를 완료하여 Kourier를 사용하지 않고 OpenShift Serverless와 Service Mesh를 통합할 수 있습니다.

사전 요구 사항

  • OpenShift Serverless Operator가 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • Red Hat OpenShift Service Mesh가 설치되어 있습니다. OpenShift Serverless with Service Mesh는 Red Hat OpenShift Service Mesh 버전 2.0.5 이상에서 사용에서만 지원됩니다.
중요

다음 절차를 완료하기 전에 Knative Serving 구성 요소를 설치하지 마십시오. 관리 가이드의 일반적인 Knative Serving 설치 절차에서는 KnativeServing CRD(사용자 정의 리소스 정의)를 생성하여 Knative Serving을 Service Mesh와 통합할 때 추가 단계가 필요합니다.

절차

  1. istio-system 네임스페이스에서 ServiceMeshControlPlane 오브젝트를 생성합니다. mTLS 기능을 사용하려면 istio-system 네임스페이스에 대해 이 기능을 활성화해야 합니다.
  2. Service Mesh와 통합할 네임스페이스를 ServiceMeshMemberRoll 오브젝트에 멤버로 추가합니다.

    apiVersion: maistra.io/v1
    kind: ServiceMeshMemberRoll
    metadata:
      name: default
      namespace: istio-system
    spec:
      members: 1
        - knative-serving
        - <namespace>
    1
    Service Mesh와 통합할 네임스페이스 목록입니다.
    중요

    이 네임스페이스 목록에 knative-serving 네임스페이스가 포함되어야 합니다.

  3. ServiceMeshMemberRoll 리소스를 적용합니다.

    $ oc apply -f <filename>
  4. Service Mesh가 트래픽을 수락할 수 있도록 필요한 게이트웨이를 생성합니다.

    HTTP를 사용하는 knative-local-gateway 오브젝트의 예

    apiVersion: networking.istio.io/v1alpha3
    kind: Gateway
    metadata:
      name: knative-ingress-gateway
      namespace: knative-serving
    spec:
      selector:
        istio: ingressgateway
      servers:
        - port:
            number: 443
            name: https
            protocol: HTTPS
          hosts:
            - "*"
          tls:
            mode: SIMPLE
            credentialName: <wildcard_certs> 1
    ---
    apiVersion: networking.istio.io/v1alpha3
    kind: Gateway
    metadata:
     name: knative-local-gateway
     namespace: knative-serving
    spec:
     selector:
       istio: ingressgateway
     servers:
       - port:
           number: 8081
           name: http
           protocol: HTTP 2
         hosts:
           - "*"
    ---
    apiVersion: v1
    kind: Service
    metadata:
     name: knative-local-gateway
     namespace: istio-system
     labels:
       experimental.istio.io/disable-gateway-port-translation: "true"
    spec:
     type: ClusterIP
     selector:
       istio: ingressgateway
     ports:
       - name: http2
         port: 80
         targetPort: 8081

    1
    와일드카드 인증서의 이름을 추가합니다.
    2
    knative-local-gateway는 HTTP 트래픽을 제공합니다. HTTP를 사용하면 Service Mesh 외부에서 들어오는 트래픽이 표시되지만 example.default.svc.cluster.local과 같은 내부 호스트 이름을 사용하는 것은 암호화되지 않습니다. 다른 와일드카드 인증서 및 다른 protocol 사양을 사용하는 추가 게이트웨이를 생성하여 이 경로에 대한 암호화를 설정할 수 있습니다.

    HTTPS를 사용하는 knative-local-gateway 오브젝트의 예

    apiVersion: networking.istio.io/v1alpha3
    kind: Gateway
    metadata:
      name: knative-local-gateway
      namespace: knative-serving
    spec:
      selector:
        istio: ingressgateway
      servers:
        - port:
            number: 443
            name: https
            protocol: HTTPS
          hosts:
            - "*"
          tls:
            mode: SIMPLE
            credentialName: <wildcard_certs>

  5. Gateway 리소스를 적용합니다.

    $ oc apply -f <filename>
  6. 다음 KnativeServing CRD(사용자 정의 리소스 정의)를 생성하여 Knative Serving을 설치하여 Istio 통합을 활성화합니다.

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeServing
    metadata:
      name: knative-serving
      namespace: knative-serving
    spec:
      ingress:
        istio:
          enabled: true 1
      deployments: 2
      - name: activator
        annotations:
          "sidecar.istio.io/inject": "true"
          "sidecar.istio.io/rewriteAppHTTPProbers": "true"
      - name: autoscaler
        annotations:
          "sidecar.istio.io/inject": "true"
          "sidecar.istio.io/rewriteAppHTTPProbers": "true"
    1
    Istio 통합을 활성화합니다.
    2
    Knative Serving 데이터 플레인 Pod에 사이드카 삽입을 활성화합니다.
  7. KnativeServing 리소스를 적용합니다.

    $ oc apply -f <filename>
  8. 사이드카 삽입이 활성화되고 패스쓰루(pass-through) 경로를 사용하는 Knative 서비스를 생성합니다.

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: <service_name>
      namespace: <namespace> 1
      annotations:
        serving.knative.openshift.io/enablePassthrough: "true" 2
    spec:
      template:
        metadata:
          annotations:
            sidecar.istio.io/inject: "true" 3
            sidecar.istio.io/rewriteAppHTTPProbers: "true"
        spec:
          containers:
          - image: <image_url>
    1
    Service Mesh 멤버 롤에 포함된 네임스페이스입니다.
    2
    생성한 인증서가 수신 게이트웨이를 통해 직접 제공되도록 Knative Serving에 OpenShift Container Platform 패스스루 지원 경로를 생성하도록 지시합니다.
    3
    Service Mesh 사이드카를 Knative 서비스 Pod에 삽입합니다.
  9. Service 리소스를 적용합니다.

    $ oc apply -f <filename>

검증

  • CA에서 신뢰하는 보안 연결을 사용하여 서버리스 애플리케이션에 액세스합니다.

    $ curl --cacert root.crt <service_url>

    명령 예

    $ curl --cacert root.crt https://hello-default.apps.openshift.example.com

    출력 예

    Hello Openshift!

6.3.1.3. mTLS를 사용하여 서비스 메시를 사용할 때 Knative Serving 지표 활성화

mTLS를 사용하여 서비스 메시를 활성화하면 서비스 메시가 Prometheus가 메트릭을 스크랩하지 못하므로 Knative Serving에 대한 지표가 기본적으로 비활성화됩니다. 이 섹션에서는 서비스 메시 및 mTLS를 사용할 때 Knative Serving 지표를 활성화하는 방법을 보여줍니다.

사전 요구 사항

  • OpenShift Serverless Operator가 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • mTLS 기능이 활성화된 Red Hat OpenShift Service Mesh를 설치했습니다.
  • Knative Serving이 설치되어 있습니다.

절차

  1. Knative Serving 사용자 정의 리소스(CR)의 observability 사양에서 prometheusmetrics.backend-destination으로 지정합니다.

    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeServing
    metadata:
      name: knative-serving
    spec:
      config:
        observability:
          metrics.backend-destination: "prometheus"

    이 단계에서는 메트릭이 기본적으로 비활성화되지 않습니다.

  2. Prometheus 네임스페이스의 트래픽을 허용하려면 다음 네트워크 정책을 적용합니다.

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-from-openshift-monitoring-ns
      namespace: knative-serving
    spec:
      ingress:
      - from:
        - namespaceSelector:
            matchLabels:
              name: "openshift-monitoring"
      podSelector: {}
  3. 다음 사양을 포함하도록 istio-system 네임스페이스에서 기본 서비스 메시 컨트롤 플레인을 수정하고 다시 적용합니다.

    spec:
      proxy:
        networking:
          trafficControl:
            inbound:
              excludedPorts:
              - 8444

6.3.2. Kourier가 활성화된 경우 OpenShift Serverless와 Service Mesh 통합

사전 요구 사항

  • OpenShift Serverless Operator가 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • Red Hat OpenShift Service Mesh가 설치되어 있습니다. OpenShift Serverless with Service Mesh and Kourier는 Red Hat OpenShift Service Mesh 버전 1.x 및 2.x에서 모두 사용이 지원되고 있습니다.
  • Knative Serving이 설치되어 있습니다.

절차

  1. Service Mesh와 통합할 네임스페이스를 ServiceMeshMemberRoll 오브젝트에 멤버로 추가합니다.

    apiVersion: maistra.io/v1
    kind: ServiceMeshMemberRoll
    metadata:
      name: default
      namespace: istio-system
    spec:
      members:
        - <namespace> 1
    1
    Service Mesh와 통합할 네임스페이스 목록입니다.
  2. ServiceMeshMemberRoll 리소스를 적용합니다.

    $ oc apply -f <filename>
  3. Knative 시스템 Pod에서 Knative 서비스로의 트래픽 흐름을 허용하는 네트워크 정책을 생성합니다.

    1. knative-serving 네임스페이스에 serving.knative.openshift.io/system-namespace=true 라벨을 추가합니다.

      $ oc label namespace knative-serving serving.knative.openshift.io/system-namespace=true
    2. knative-serving-ingress 네임스페이스에 serving.knative.openshift.io/system-namespace=true 라벨을 추가합니다.

      $ oc label namespace knative-serving-ingress serving.knative.openshift.io/system-namespace=true
    3. Service Mesh와 통합할 각 네임스페이스에 NetworkPolicy 리소스를 생성합니다.

      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-serving-system-namespace
        namespace: <namespace> 1
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                serving.knative.openshift.io/system-namespace: "true"
        podSelector: {}
        policyTypes:
        - Ingress
      1
      Service Mesh와 통합할 네임스페이스를 추가합니다.
    4. NetworkPolicy 리소스를 적용합니다.

      $ oc apply -f <filename>

6.4. 관리자 화면에서 Eventing 구성 요소 생성

웹 콘솔의 관리자 화면에서 OpenShift Serverless를 사용하여 Knative Eventing 구성 요소를 생성할 수 있습니다.

6.4.1. 관리자 화면을 사용하여 이벤트 소스 생성

클러스터 관리자 권한이 있는 경우 웹 콘솔의 관리자 화면에서 이벤트 소스를 생성할 수 있습니다.

사전 요구 사항

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

절차

  1. OpenShift Container Platform 웹 콘솔의 관리자 화면에서 ServerlessEventing으로 이동합니다.
  2. 생성 목록에서 이벤트 소스를 선택합니다. 그러면 이벤트 소스 페이지로 이동합니다.
  3. 생성할 이벤트 소스 유형을 선택합니다.

지원되는 이벤트 소스 유형에 대한 자세한 내용은 OpenShift Serverless를 사용하여 생성할 수 있는 이벤트 소스를 참조하십시오.

6.4.2. 관리자 화면을 사용하여 브로커 생성

클러스터 관리자 권한이 있는 경우 웹 콘솔의 관리자 화면을 사용하여 브로커를 생성할 수 있습니다.

사전 요구 사항

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

절차

  1. OpenShift Container Platform 웹 콘솔의 관리자 화면에서 ServerlessEventing으로 이동합니다.
  2. 생성 목록에서 브로커를 선택합니다. 그러면 브로커 생성 페이지로 이동합니다.
  3. 선택 사항: 브로커의 YAML 구성을 수정합니다.
  4. 생성을 클릭합니다.

6.4.3. 관리자 화면을 사용하여 트리거 생성

클러스터 관리자 권한이 있고 채널을 생성한 경우 웹 콘솔의 관리자 화면에서 트리거를 생성하여 브로커를 구독자에 연결할 수 있습니다.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • OpenShift Container Platform에 대한 클러스터 관리자 권한이 있습니다.
  • 브로커를 생성했습니다.
  • 구독자로 사용할 Knative 서비스를 생성했습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔의 관리자 화면에서 ServerlessEventing으로 이동합니다.
  2. 브로커 탭에서 트리거를 추가할 브로커의 옵션 메뉴 kebab 를 선택합니다.
  3. 목록에서 트리거 추가를 클릭합니다.
  4. 트리거 추가 대화 상자에서 트리거에 대한 구독자를 선택합니다. 구독자는 브로커에서 이벤트를 수신하는 Knative 서비스입니다.
  5. 추가를 클릭합니다.

6.4.4. 관리자 화면을 사용하여 채널 생성

클러스터 관리자 권한이 있는 경우 웹 콘솔의 관리자 화면을 사용하여 채널을 생성할 수 있습니다.

사전 요구 사항

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

프로세스

  1. OpenShift Container Platform 웹 콘솔의 관리자 화면에서 ServerlessEventing으로 이동합니다.
  2. 생성 목록에서 채널을 선택합니다. 그러면 채널 페이지로 이동합니다.
  3. 유형 드롭다운에서 생성할 Channel 오브젝트 유형을 선택합니다.

    참고

    현재 InMemoryChannel 채널 오브젝트만 기본적으로 지원됩니다. OpenShift Serverless에 Knative Kafka를 설치한 경우 Kafka 채널을 사용할 수 있습니다.

  4. 생성을 클릭합니다.

6.4.5. 관리자 화면을 사용하여 서브스크립션 생성

클러스터 관리자 권한이 있고 채널을 생성한 경우 웹 콘솔의 관리자 화면에서 서브스크립션을 생성하여 브로커를 구독자에 연결할 수 있습니다.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • OpenShift Container Platform에 대한 클러스터 관리자 권한이 있습니다.
  • 채널을 생성했습니다.
  • 구독자로 사용할 Knative 서비스를 생성했습니다.

절차

  1. OpenShift Container Platform 웹 콘솔의 관리자 화면에서 ServerlessEventing으로 이동합니다.
  2. 채널 탭에서 서브스크립션을 추가할 채널의 옵션 메뉴 kebab 를 선택합니다.
  3. 목록에서 서브스크립션 추가를 클릭합니다.
  4. 서브스크립션 추가 대화 상자에서 서브스크립션에 대한 구독자를 선택합니다. 구독자는 채널에서 이벤트를 수신하는 Knative 서비스입니다.
  5. 추가를 클릭합니다.

6.4.6. 추가 리소스

6.5. 관리자 화면에서 Knative Serving 구성 요소 생성

OpenShift Container Platform 클러스터에 대한 클러스터 관리자 권한이 있는 경우 웹 콘솔의 관리자 화면에서 또는 knoc CLI를 사용하여 OpenShift Serverless에서 Knative Serving 구성 요소를 생성할 수 있습니다.

6.5.1. 관리자 화면을 사용하여 서버리스 애플리케이션 생성

사전 요구 사항

관리자 화면을 사용하여 서버리스 애플리케이션을 생성하려면 다음 단계를 완료해야 합니다.

  • OpenShift Serverless Operator 및 Knative Serving이 설치되어 있습니다.
  • 웹 콘솔에 로그인한 후 관리자 화면에 있습니다.

절차

  1. ServerlessServing 페이지로 이동합니다.
  2. 생성 목록에서 서비스를 선택합니다.
  3. YAML 또는 JSON 정의를 수동으로 입력하거나 파일을 편집기로 끌어서 놓습니다.
  4. 생성을 클릭합니다.

6.6. Knative Serving 사용자 정의 리소스 구성

이 가이드에서는 클러스터 관리자가 Knative Serving CR에서 생성된 개발자가 생성한 CR(사용자 정의 리소스)의 설정을 관리하는 방법을 설명합니다.

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

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

현재 replicas,labels,annotationsnodeSelector 필드에 대한 기본 구성 설정을 재정의할 수 있습니다.

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

  • 배포에는 3개의 복제본이 있습니다.
  • 레이블은 example-label: label 로 설정됩니다.
  • example-label: 레이블이 추가되었습니다.
  • 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
    replicas: 3
    labels:
      example-label: label
    annotations:
      example-annotation: annotation
    nodeSelector:
      disktype: hdd

6.6.2. EmptyDir 확장 구성

이 확장 기능은 emptyDir 볼륨을 지정할 수 있는지 여부를 제어합니다.

emptyDir 볼륨을 사용하여 활성화하려면 다음 YAML을 포함하도록 KnativeServing CR(사용자 정의 리소스)을 수정해야 합니다.

...
spec:
  config:
    features:
      "kubernetes.podspec-volumes-emptydir": enabled
...

6.6.3. HTTPS 리디렉션 전역 설정

다음 예와 같이 KnativeServing 사용자 정의 리소스에 대한 httpProtocol 사양을 구성하여 클러스터의 모든 서비스에 대한 HTTPS 리디렉션을 활성화할 수 있습니다.

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

6.6.4. 추가 리소스

6.7. 서버리스 구성 요소 모니터링

OpenShift Container Platform 모니터링 대시보드를 사용하여 OpenShift Serverless 구성 요소에 대한 상태 점검 및 지표를 확인할 수 있습니다.

6.7.1. Knative 구성 요소의 전체 상태 모니터링

OpenShift Container Platform 모니터링 대시보드를 사용하여 Knative의 전반적인 상태를 확인할 수 있습니다.

사전 요구 사항

  • 클러스터 관리자 권한이 있고 OpenShift Container Platform 웹 콘솔의 관리자 화면에 액세스할 수 있습니다.
  • OpenShift Serverless Operator와 Knative Serving 또는 Knative Eventing 구성 요소를 설치했습니다.
  • OpenShift Container Platform 모니터링 스택이 클러스터에 활성화되어 있습니다. OpenShift Serverless Operator를 설치할 때 이 네임스페이스에서 Operator 권장 클러스터 모니터링을 활성화하려면 상자를 선택하여 설치 중에 OpenShift Serverless에 대한 모니터링을 활성화할 수 있습니다.

프로세스

  1. 관리자 화면에서 모니터링대시보드로 이동합니다.
  2. 대시보드 드롭 다운에서 Knative 상태 대시보드를 선택하여 Knative의 전반적인 상태를 확인합니다. Knative 배포가 예상대로 실행 중인 경우 대시보드에 Ready 상태가 표시됩니다.

    Knative 상태 대시보드

    Knative Serving 또는 Knative Eventing이 설치되어 있는 경우 아래로 스크롤하여 이러한 각 구성 요소의 상태를 확인할 수도 있습니다.

6.7.2. Knative Serving 버전 CPU 및 메모리 사용량 모니터링

OpenShift Container Platform 모니터링 대시 보드를 사용하여 Knative Serving 구성 요소에 대한 버전 CPU 및 메모리 사용량 지표를 확인할 수 있습니다.

사전 요구 사항

  • 클러스터 관리자 권한이 있고 OpenShift Container Platform 웹 콘솔의 관리자 화면에 액세스할 수 있습니다.
  • OpenShift Serverless Operator 및 Knative Serving 구성 요소가 설치되어 있어야 합니다.
  • OpenShift Container Platform 모니터링 스택이 클러스터에 활성화되어 있습니다. OpenShift Serverless Operator를 설치할 때 이 네임스페이스에서 Operator 권장 클러스터 모니터링을 활성화하려면 상자를 선택하여 설치 중에 OpenShift Serverless에 대한 모니터링을 활성화할 수 있습니다.

프로세스

  1. 관리자 화면에서 모니터링대시보드로 이동합니다.
  2. 대시보드 드롭다운 목록에서 Knative Serving - 소스 CPU 및 메모리 사용량 대시보드를 선택하여 다음 메트릭을 확인합니다.

    • 총 CPU 사용량 (분당 사용량)
    • 총 메모리 사용량 (바이트 단위)
    • 총 네트워크 I/O (분 단위)
    • 총 네트워크 오류 (분 단위)
  3. 선택 사항: 드롭다운 목록에서 옵션을 선택하여 네임스페이스,구성 또는 버전으로 이 대시보드를 필터링할 수 있습니다.

6.7.3. Knative Eventing 소스 CPU 및 메모리 사용량 모니터링

OpenShift Container Platform 모니터링 대시 보드를 사용하여 Knative Eventing 구성 요소에 대한 소스 CPU 및 메모리 사용량을 확인할 수 있습니다.

사전 요구 사항

  • 클러스터 관리자 권한이 있고 OpenShift Container Platform 웹 콘솔의 관리자 화면에 액세스할 수 있습니다.
  • OpenShift Serverless Operator 및 Knative Eventing 구성요소가 설치되어 있습니다.
  • OpenShift Container Platform 모니터링 스택이 클러스터에 활성화되어 있습니다. OpenShift Serverless Operator를 설치할 때 이 네임스페이스에서 Operator 권장 클러스터 모니터링을 활성화하려면 상자를 선택하여 설치 중에 OpenShift Serverless에 대한 모니터링을 활성화할 수 있습니다.

프로세스

  1. 관리자 화면에서 모니터링대시보드로 이동합니다.
  2. 대시보드 드롭다운 목록에서 Knative Eventing - 소스 CPU 및 메모리 사용량 대시보드를 선택하여 다음 메트릭을 확인합니다.

    • 총 CPU 사용량 (분당 사용량)
    • 총 메모리 사용량 (바이트 단위)
    • 총 네트워크 I/O (분 단위)
    • 총 네트워크 오류 (분 단위)

6.7.4. 모니터링 이벤트 소스

OpenShift Container Platform 모니터링 대시보드를 사용하여 클러스터의 이벤트 소스에 대한 메트릭을 볼 수 있습니다.

사전 요구 사항

  • 클러스터 관리자 권한이 있고 OpenShift Container Platform 웹 콘솔의 관리자 화면에 액세스할 수 있습니다.
  • OpenShift Serverless Operator 및 Knative Eventing 구성요소가 설치되어 있습니다.
  • OpenShift Container Platform 모니터링 스택이 클러스터에 활성화되어 있습니다. OpenShift Serverless Operator를 설치할 때 이 네임스페이스에서 Operator 권장 클러스터 모니터링을 활성화하려면 상자를 선택하여 설치 중에 OpenShift Serverless에 대한 모니터링을 활성화할 수 있습니다.

프로세스

  1. 관리자 화면에서 모니터링대시보드로 이동합니다.
  2. 대시보드 드롭다운 목록에서 Knative Eventing - Sources 대시보드를 선택합니다.
  3. 다음 메트릭을 표시할 수 있습니다.

    1. API 서버 소스의 경우:

      • 이벤트 수 (분당 비율)
      • 성공률 (2xx 이벤트, 분당 부분 비율)
      • 응답 코드 클래스별 이벤트 수(분당 비율)
      • 실패율 (비-2xx 이벤트, 분당 부분 비율)
    2. ping 소스의 경우

      • 이벤트 수 (분당 비율)
      • 성공률 (2xx 이벤트, 분당 부분 비율)
      • 응답 코드 클래스별 이벤트 수(분당 비율)
      • 실패율 (비-2xx 이벤트, 분당 부분 비율)
    3. Kafka 소스의 경우

      • 이벤트 수 (분당 비율)
      • 성공률 (2xx 이벤트, 분당 부분 비율)
      • 응답 코드 클래스별 이벤트 수(분당 비율)
      • 실패율 (비-2xx 이벤트, 분당 부분 비율)

6.7.5. Knative Eventing 브로커 및 트리거 모니터링

OpenShift Container Platform 모니터링 대시보드를 사용하여 클러스터의 브로커 및 트리거에 대한 메트릭을 볼 수 있습니다.

사전 요구 사항

  • 클러스터 관리자 권한이 있고 OpenShift Container Platform 웹 콘솔의 관리자 화면에 액세스할 수 있습니다.
  • OpenShift Serverless Operator 및 Knative Eventing 구성요소가 설치되어 있습니다.
  • OpenShift Container Platform 모니터링 스택이 클러스터에 활성화되어 있습니다. OpenShift Serverless Operator를 설치할 때 이 네임스페이스에서 Operator 권장 클러스터 모니터링을 활성화하려면 상자를 선택하여 설치 중에 OpenShift Serverless에 대한 모니터링을 활성화할 수 있습니다.

절차

  1. 관리자 화면에서 모니터링대시보드로 이동합니다.
  2. 대시보드 드롭다운 목록에서 Knative Eventing - Broker/Trigger 대시보드를 선택합니다.
  3. 다음 메트릭을 표시할 수 있습니다.

    1. 브로커의 경우:

      • 이벤트 수(평균/초, 1m 이상 창)
      • 성공률(2xx 이벤트, 부분 비율, 1m 이상 창)
      • 이벤트 유형별 이벤트 수(평균/초, 1m 이상 창)
      • 응답 코드 클래스별 이벤트 수 (평균/초, 1m 이상 창)
      • 실패율(비-2xx 이벤트, 부분 비율, 1m 이상 창)
      • 이벤트 디스패치 대기 시간 (ms)
    2. 트리거의 경우:

      • 이벤트 수(평균/초, 1m 이상 창)
      • 성공률(2xx 이벤트, 부분 비율, 1m 이상 창)
      • 이벤트 유형별 이벤트 수(평균/초, 1m 이상 창)
      • 응답 코드 클래스별 이벤트 수 (평균/초, 1m 이상 창)
      • 실패율(비-2xx 이벤트, 부분 비율, 1m 이상 창)
      • 이벤트 디스패치 대기 시간 (ms)
      • 이벤트 처리 대기 시간 (ms)

6.7.6. Knative Eventing 채널 모니터링

OpenShift Container Platform 모니터링 대시보드를 사용하여 클러스터의 채널 메트릭을 볼 수 있습니다.

사전 요구 사항

  • 클러스터 관리자 권한이 있고 OpenShift Container Platform 웹 콘솔의 관리자 화면에 액세스할 수 있습니다.
  • OpenShift Serverless Operator, Knative Eventing 구성 요소 및 KnativeKafka 사용자 정의 리소스를 설치했습니다.
  • OpenShift Container Platform 모니터링 스택이 클러스터에 활성화되어 있습니다. OpenShift Serverless Operator를 설치할 때 이 네임스페이스에서 Operator 권장 클러스터 모니터링을 활성화하려면 상자를 선택하여 설치 중에 OpenShift Serverless에 대한 모니터링을 활성화할 수 있습니다.

절차

  1. 관리자 화면에서 모니터링대시보드로 이동합니다.
  2. 대시보드 드롭다운 목록에서 Knative Eventing - 채널 대시보드를 선택합니다.
  3. 다음 메트릭을 표시할 수 있습니다.

    1. 인메모리 채널의 경우:

      • 이벤트 수(평균/초, 1m 이상 창)
      • 성공률(2xx 이벤트, 부분 비율, 1m 이상 창)
      • 응답 코드 클래스별 이벤트 수 (평균/초, 1m 이상 창)
      • 실패율(비-2xx 이벤트, 부분 비율, 1m 이상 창)
      • 이벤트 디스패치 대기 시간 (ms)
    2. Kafka 채널의 경우:

      • 이벤트 수(평균/초, 1m 이상 창)
      • 성공률(2xx 이벤트, 부분 비율, 1m 이상 창)
      • 응답 코드 클래스별 이벤트 수 (평균/초, 1m 이상 창)
      • 실패율(비-2xx 이벤트, 부분 비율, 1m 이상 창)
      • 이벤트 디스패치 대기 시간 (ms)

6.8. 메트릭

클러스터 관리자는 메트릭을 사용하여 OpenShift Serverless 클러스터 구성 요소 및 워크로드를 수행하는 방법을 모니터링할 수 있습니다.

6.8.1. 사전 요구 사항

  • 클러스터 메트릭 활성화에 대한 정보는 메트릭 관리에 대한 OpenShift Container Platform 설명서를 참조하십시오.
  • OpenShift Container Platform에서 Knative 구성 요소의 메트릭을 표시하려면 클러스터 관리자 권한이 필요하며 웹 콘솔 관리자 화면으로 액세스할 수 있어야 합니다.
주의

Service Mesh가 mTLS를 사용하여 사용하도록 설정된 경우 Service Mesh가 Prometheus의 메트릭 스크랩을 허용하지 않기 때문에 기본적으로 Knative Serviceing에 대한 메트릭이 사용되지 않도록 설정됩니다.

이 문제 해결에 대한 자세한 내용은 Integrating Service Mesh with OpenShift Serverless 를 참조하십시오.

6.8.2. 컨트롤러 메트릭

다음 메트릭은 컨트롤러 로직을 구현하는 구성 요소에서 출력됩니다. 이러한 메트릭은 조정 작업 및 조정 요청이 작업 대기열에 추가되는 작업 대기열 동작에 대한 세부 정보를 표시합니다.

메트릭 이름설명유형태그단위

work_queue_depth

작업 대기열의 깊이

게이지

reconciler

정수(단위 없음)

reconcile_count

조정 작업 수

카운터

reconciler, success

정수(단위 없음)

reconcile_latency

조정 작업 대기 시간

히스토그램

reconciler, success

밀리초

workqueue_adds_total

작업 대기열에서 처리하는 총 추가 작업 수

카운터

name

정수(단위 없음)

workqueue_queue_latency_seconds

항목이 요청되기 전에 작업 대기열에 남아 있는 시간

히스토그램

name

workqueue_retries_total

작업 대기열에서 처리한 총 재시도 횟수

카운터

name

정수(단위 없음)

workqueue_work_duration_seconds

작업 대기열에서 처리하는 데 걸리는 시간 및 항목

히스토그램

name

workqueue_unfinished_work_seconds

처리되지 않은 작업 대기열 항목이 진행 중인 시간

히스토그램

name

workqueue_longest_running_processor_seconds

가장 긴 미결 작업 대기열 항목이 진행 중인 시간

히스토그램

name

6.8.3. Webhook 메트릭

Webhook 메트릭은 작업에 대한 유용한 정보를 표시합니다. 예를 들어, 많은 작업이 실패하면 사용자가 생성한 리소스에 문제가 있음을 나타내는 것일 수 있습니다.

메트릭 이름설명유형태그단위

request_count

webhook로 라우팅되는 요청 수입니다.

카운터

admission_allowed, kind_group, kind_kind, kind_version, request_operation, resource_group, resource_namespace, resource_resource, resource_version

정수(단위 없음)

request_latencies

webhook 요청에 대한 응답 시간입니다.

히스토그램

admission_allowed, kind_group, kind_kind, kind_version, request_operation, resource_group, resource_namespace, resource_resource, resource_version

밀리초

6.8.4. Knative Eventing 메트릭

클러스터 관리자는 Knative Eventing 구성 요소에 대한 다음 메트릭을 볼 수 있습니다.

HTTP 코드에서 메트릭을 집계하여 정상적인 이벤트 (2xx) 및 실패한 이벤트(5xx)의 두 가지 범주로 구분할 수 있습니다.

6.8.4.1. 브로커 Ingress 메트릭

다음 메트릭을 사용하여 브로커 Ingress를 디버그하고, 수행 방법을 확인하고, Ingress 구성 요소에서 전달되는 이벤트를 확인할 수 있습니다.

메트릭 이름설명유형태그단위

event_count

브로커가 수신한 이벤트 수.

카운터

broker_name, event_type, namespace_name, response_code, response_code_class, unique_name

정수(단위 없음)

event_dispatch_latencies

이벤트를 채널로 전달하는 데 걸린 시간입니다.

히스토그램

broker_name, event_type, namespace_name, response_code, response_code_class, unique_name

밀리초

6.8.4.2. 브로커 필터 메트릭

다음 메트릭을 사용하여 브로커 필터를 디버그하고, 수행 방법을 확인하고, 필터에서 전달되는 이벤트를 확인할 수 있습니다. 이벤트에서 필터링 작업의 대기 시간을 측정할 수도 있습니다.

메트릭 이름설명유형태그단위

event_count

브로커가 수신한 이벤트 수.

카운터

broker_name, container_name, filter_type, namespace_name, response_code, response_code_class, trigger_name, unique_name

정수(단위 없음)

event_dispatch_latencies

이벤트를 채널로 전달하는 데 걸린 시간입니다.

히스토그램

broker_name, container_name, filter_type, namespace_name, response_code, response_code_class, trigger_name, unique_name

밀리초

event_processing_latencies

트리거 구독자에게 전달되기 전에 이벤트를 처리하는 데 걸리는 시간입니다.

히스토그램

broker_name, container_name, filter_type, namespace_name, trigger_name, unique_name

밀리초

6.8.4.3. InMemoryChannel 디스패처 메트릭

다음 메트릭을 사용하여 InMemoryChannel 채널을 디버그하고, 어떻게 수행하는지, 채널에서 디스패치 중인 이벤트를 확인할 수 있습니다.

메트릭 이름설명유형태그단위

event_count

InMemoryChannel 채널에서 디스패치하는 이벤트 수.

카운터

broker_name, container_name, filter_type, namespace_name, response_code, response_code_class, trigger_name, unique_name

정수(단위 없음)

event_dispatch_latencies

InMemoryChannel 채널에서 이벤트를 디스패치하는 데 걸린 시간.

히스토그램

broker_name, container_name, filter_type, namespace_name, response_code, response_code_class, trigger_name, unique_name

밀리초

6.8.4.4. 이벤트 소스 메트릭

다음 메트릭을 사용하여 이벤트 소스에서 연결된 이벤트 싱크로 이벤트가 전달되었는지 확인할 수 있습니다.

메트릭 이름설명유형태그단위

event_count

이벤트 소스에서 보낸 이벤트 수입니다.

카운터

broker_name, container_name, filter_type, namespace_name, response_code, response_code_class, trigger_name, unique_name

정수(단위 없음)

retry_event_count

처음에 이벤트 소스가 전송되지 못한 후 이벤트 소스에 의해 전송되는 재시도 이벤트 수입니다.

카운터

event_source, event_type, name, namespace_name, resource_group, response_code, response_code_class, response_error, response_timeout

정수(단위 없음)

6.8.5. Knative Serving 메트릭

클러스터 관리자는 Knative Serving 구성 요소에 대한 다음 메트릭을 볼 수 있습니다.

6.8.5.1. 활성화기 메트릭

다음 메트릭을 사용하여 트래픽이 활성화기를 통해 전달될 때 애플리케이션이 응답하는 방식을 파악할 수 있습니다.

메트릭 이름설명유형태그단위

request_concurrency

활성화기 또는 보고 기간에 평균 동시성으로 라우팅되는 동시 요청 수입니다.

게이지

configuration_name, container_name, namespace_name, pod_name, revision_name, service_name

정수(단위 없음)

request_count

활성화기로 라우팅되는 요청 수입니다. 이러한 요청은 활성화기 처리기에서 실행된 요청입니다.

카운터

configuration_name, container_name, namespace_name, pod_name, response_code, response_code_class, revision_name, service_name,

정수(단위 없음)

request_latencies

실행된 라우팅된 요청에 대한 응답 시간(밀리초)입니다.

히스토그램

configuration_name, container_name, namespace_name, pod_name, response_code, response_code_class, revision_name, service_name

밀리초

6.8.5.2. 자동 스케일러 메트릭

자동 스케일러 구성 요소는 각 버전의 자동 스케일러 동작과 관련된 여러 메트릭을 표시합니다. 예를 들어, 자동 스케일러가 서비스에 할당하려는 대상 Pod 수, 안정적인 기간 동안 초당 평균 요청 수 또는 Knative Pod 자동 스케일러(KPA)를 사용하는 경우 자동 스케일러가 패닉 모드인지를 모니터링할 수 있습니다.

메트릭 이름설명유형태그단위

desired_pods

자동 스케일러가 서비스에 할당하려는 Pod 수입니다.

게이지

configuration_name, namespace_name, revision_name, service_name

정수(단위 없음)

excess_burst_capacity

stable 창에서 제공되는 추가 버스트 용량입니다.

게이지

configuration_name, namespace_name, revision_name, service_name

정수(단위 없음)

stable_request_concurrency

stable 창에서 모니터링되는 각 pod의 평균 요청 수입니다.

게이지

configuration_name, namespace_name, revision_name, service_name

정수(단위 없음)

panic_request_concurrency

panic 창에서 모니터링되는 각 Pod의 평균 요청 수입니다.

게이지

configuration_name, namespace_name, revision_name, service_name

정수(단위 없음)

target_concurrency_per_pod

자동 스케일러가 각 pod에 보내려는 동시 요청 수입니다.

게이지

configuration_name, namespace_name, revision_name, service_name

정수(단위 없음)

stable_requests_per_second

stable 창에서 모니터링되는 각 pod의 평균 요청 수(초당)입니다.

게이지

configuration_name, namespace_name, revision_name, service_name

정수(단위 없음)

panic_requests_per_second

panic 창에서 모니터링되는 각 Pod의 평균 요청 수입니다.

게이지

configuration_name, namespace_name, revision_name, service_name

정수(단위 없음)

target_requests_per_second

각 pod에 대해 자동 스케일러가 대상으로 하는 초당 요청 수입니다.

게이지

configuration_name, namespace_name, revision_name, service_name

정수(단위 없음)

panic_mode

자동 스케일러가 패닉 모드이면 이 값은 1이며 자동 스케일러가 패닉 모드가 아닌 경우 0입니다.

게이지

configuration_name, namespace_name, revision_name, service_name

정수(단위 없음)

requested_pods

Kubernetes 클러스터에서 자동 스케일러가 요청한 Pod 수입니다.

게이지

configuration_name, namespace_name, revision_name, service_name

정수(단위 없음)

actual_pods

할당되어 있고 현재 준비 상태인 Pod 수입니다.

게이지

configuration_name, namespace_name, revision_name, service_name

정수(단위 없음)

not_ready_pods

준비되지 않은 상태의 Pod 수입니다.

게이지

configuration_name, namespace_name, revision_name, service_name

정수(단위 없음)

pending_pods

현재 보류 중인 pod 수입니다.

게이지

configuration_name, namespace_name, revision_name, service_name

정수(단위 없음)

terminating_pods

현재 종료 중인 Pod 수입니다.

게이지

configuration_name, namespace_name, revision_name, service_name

정수(단위 없음)

6.8.5.3. Go 런타임 메트릭

각 Knative Serving 컨트롤 플레인 프로세스는 수많은 Go 런타임 메모리 통계(MemStats)를 출력합니다.

참고

각 메트릭의 name 태그는 빈 태그입니다.

메트릭 이름설명유형태그단위

go_alloc

할당된 힙 오브젝트의 바이트 수입니다. 이 메트릭은 heap_alloc과 동일합니다.

게이지

name

정수(단위 없음)

go_total_alloc

힙 오브젝트에 할당된 누적 바이트 수입니다.

게이지

name

정수(단위 없음)

go_sys

운영 체제에서 얻은 총 메모리 바이트 수입니다.

게이지

name

정수(단위 없음)

go_lookups

런타임에서 수행하는 포인터 검색 수입니다.

게이지

name

정수(단위 없음)

go_mallocs

할당된 힙 오브젝트의 누적 개수입니다.

게이지

name

정수(단위 없음)

go_frees

해제된 힙 오브젝트의 누적 개수입니다.

게이지

name

정수(단위 없음)

go_heap_alloc

할당된 힙 오브젝트의 바이트 수입니다.

게이지

name

정수(단위 없음)

go_heap_sys

운영 체제에서 얻은 힙 메모리의 바이트 수입니다.

게이지

name

정수(단위 없음)

go_heap_idle

유휴 상태의 사용되지 않는 범위의 바이트 수입니다.

게이지

name

정수(단위 없음)

go_heap_in_use

현재 사용 중인 범위의 바이트 수입니다.

게이지

name

정수(단위 없음)

go_heap_released

운영 체제로 반환되는 실제 메모리의 바이트 수입니다.

게이지

name

정수(단위 없음)

go_heap_objects

할당된 힙 오브젝트 수입니다.

게이지

name

정수(단위 없음)

go_stack_in_use

현재 사용 중인 스택 범위의 바이트 수입니다.

게이지

name

정수(단위 없음)

go_stack_sys

운영 체제에서 얻은 스택 메모리의 바이트 수입니다.

게이지

name

정수(단위 없음)

go_mspan_in_use

할당된 mspan 구조의 바이트 수입니다.

게이지

name

정수(단위 없음)

go_mspan_sys

mspan 구조의 운영 체제에서 얻은 메모리 바이트 수입니다.

게이지

name

정수(단위 없음)

go_mcache_in_use

할당된 mcache 구조의 바이트 수입니다.

게이지

name

정수(단위 없음)

go_mcache_sys

mcache 구조의 운영 체제에서 얻은 메모리 바이트 수입니다.

게이지

name

정수(단위 없음)

go_bucket_hash_sys

버킷 해시 테이블 프로파일에서의 메모리 바이트 수입니다.

게이지

name

정수(단위 없음)

go_gc_sys

가비지 컬렉션 메타데이터의 메모리 바이트 수입니다.

게이지

name

정수(단위 없음)

go_other_sys

기타, 오프-힙 런타임 할당의 메모리 바이트 수입니다.

게이지

name

정수(단위 없음)

go_next_gc

다음 가비지 컬렉션 사이클의 대상 힙 크기입니다.

게이지

name

정수(단위 없음)

go_last_gc

마지막 가비지 컬렉션이Epoch 또는 Unix 시간으로 완료된 시간입니다.

게이지

name

나노초

go_total_gc_pause_ns

프로그램이 시작된 이후 가비지 컬렉션 stop-the-world 일시 중지의 누적 시간입니다

게이지

name

나노초

go_num_gc

완료된 가비지 컬렉션 사이클 수입니다.

게이지

name

정수(단위 없음)

go_num_forced_gc

가비지 컬렉션 기능을 호출하는 애플리케이션으로 인해 강제된 가비지 컬렉션 사이클의 수입니다.

게이지

name

정수(단위 없음)

go_gc_cpu_fraction

프로그램이 시작된 이후 가비지 컬렉터에서 사용한 프로그램의 사용 가능한 일부 CPU 시간입니다.

게이지

name

정수(단위 없음)

6.9. OpenShift Serverless에서 미터링 사용하기

중요

미터링은 더 이상 사용되지 않는 기능입니다. 더 이상 사용되지 않는 기능은 여전히 OpenShift Container Platform에 포함되어 있으며 계속 지원됩니다. 그러나 이 기능은 향후 릴리스에서 제거될 예정이므로 새로운 배포에는 사용하지 않는 것이 좋습니다.

OpenShift Container Platform에서 더 이상 사용되지 않거나 삭제된 주요 기능의 최신 목록은 OpenShift Container Platform 릴리스 노트에서 더 이상 사용되지 않고 삭제된 기능 섹션을 참조하십시오.

클러스터 관리자는 미터링을 사용하여 OpenShift Serverless 클러스터에서 발생하는 상황을 분석할 수 있습니다.

OpenShift Container Platform의 미터링에 대한 자세한 내용은 미터링 정보를 참조하십시오.

참고

미터링은 현재 IBM Z 및 IBM Power Systems에서 지원되지 않습니다.

6.9.1. 미터링 설치

OpenShift Container Platform에 미터링을 설치하는 방법에 대한 내용은 미터링 설치를 참조하십시오.

6.9.2. Knative Serving 미터링 데이터 소스

다음 ReportDataSources는 OpenShift Container Platform 미터링에 Knative Serving을 사용하는 방법에 대한 예제입니다.

6.9.2.1. Knative Serving의 CPU 사용량에 대한 데이터 소스

이 데이터 소스에서는 보고 기간에 Knative 서비스당 사용된 누적 CPU 시간(초)을 제공합니다.

YAML 파일

apiVersion: metering.openshift.io/v1
kind: ReportDataSource
metadata:
  name: knative-service-cpu-usage
spec:
  prometheusMetricsImporter:
    query: >
      sum
          by(namespace,
             label_serving_knative_dev_service,
             label_serving_knative_dev_revision)
          (
            label_replace(rate(container_cpu_usage_seconds_total{container!="POD",container!="",pod!=""}[1m]), "pod", "$1", "pod", "(.*)")
            *
            on(pod, namespace)
            group_left(label_serving_knative_dev_service, label_serving_knative_dev_revision)
            kube_pod_labels{label_serving_knative_dev_service!=""}
          )

6.9.2.2. Knative Serving의 메모리 사용량에 대한 데이터 소스

이 데이터 소스에서는 보고 기간에 Knative 서비스당 평균 메모리 사용량을 제공합니다.

YAML 파일

apiVersion: metering.openshift.io/v1
kind: ReportDataSource
metadata:
  name: knative-service-memory-usage
spec:
  prometheusMetricsImporter:
    query: >
      sum
          by(namespace,
             label_serving_knative_dev_service,
             label_serving_knative_dev_revision)
          (
            label_replace(container_memory_usage_bytes{container!="POD", container!="",pod!=""}, "pod", "$1", "pod", "(.*)")
            *
            on(pod, namespace)
            group_left(label_serving_knative_dev_service, label_serving_knative_dev_revision)
            kube_pod_labels{label_serving_knative_dev_service!=""}
          )

6.9.2.3. Knative Serving 미터링 데이터 소스 적용

다음 명령을 사용하여 ReportDataSources를 적용할 수 있습니다.

$ oc apply -f <datasource_name>.yaml

$ oc apply -f knative-service-memory-usage.yaml

6.9.3. Knative Serving 미터링 쿼리

다음 ReportQuery 리소스에서는 제공된 DataSources 예제를 참조합니다.

6.9.3.1. Knative Serving의 CPU 사용량 쿼리

YAML 파일

apiVersion: metering.openshift.io/v1
kind: ReportQuery
metadata:
  name: knative-service-cpu-usage
spec:
  inputs:
  - name: ReportingStart
    type: time
  - name: ReportingEnd
    type: time
  - default: knative-service-cpu-usage
    name: KnativeServiceCpuUsageDataSource
    type: ReportDataSource
  columns:
  - name: period_start
    type: timestamp
    unit: date
  - name: period_end
    type: timestamp
    unit: date
  - name: namespace
    type: varchar
    unit: kubernetes_namespace
  - name: service
    type: varchar
  - name: data_start
    type: timestamp
    unit: date
  - name: data_end
    type: timestamp
    unit: date
  - name: service_cpu_seconds
    type: double
    unit: cpu_core_seconds
  query: |
    SELECT
      timestamp '{| default .Report.ReportingStart .Report.Inputs.ReportingStart| prestoTimestamp |}' AS period_start,
      timestamp '{| default .Report.ReportingEnd .Report.Inputs.ReportingEnd | prestoTimestamp |}' AS period_end,
      labels['namespace'] as project,
      labels['label_serving_knative_dev_service'] as service,
      min("timestamp") as data_start,
      max("timestamp") as data_end,
      sum(amount * "timeprecision") AS service_cpu_seconds
    FROM {| dataSourceTableName .Report.Inputs.KnativeServiceCpuUsageDataSource |}
    WHERE "timestamp" >= timestamp '{| default .Report.ReportingStart .Report.Inputs.ReportingStart | prestoTimestamp |}'
    AND "timestamp" < timestamp '{| default .Report.ReportingEnd .Report.Inputs.ReportingEnd | prestoTimestamp |}'
    GROUP BY labels['namespace'],labels['label_serving_knative_dev_service']

6.9.3.2. Knative Serving의 메모리 사용량 쿼리

YAML 파일

apiVersion: metering.openshift.io/v1
kind: ReportQuery
metadata:
  name: knative-service-memory-usage
spec:
  inputs:
  - name: ReportingStart
    type: time
  - name: ReportingEnd
    type: time
  - default: knative-service-memory-usage
    name: KnativeServiceMemoryUsageDataSource
    type: ReportDataSource
  columns:
  - name: period_start
    type: timestamp
    unit: date
  - name: period_end
    type: timestamp
    unit: date
  - name: namespace
    type: varchar
    unit: kubernetes_namespace
  - name: service
    type: varchar
  - name: data_start
    type: timestamp
    unit: date
  - name: data_end
    type: timestamp
    unit: date
  - name: service_usage_memory_byte_seconds
    type: double
    unit: byte_seconds
  query: |
    SELECT
      timestamp '{| default .Report.ReportingStart .Report.Inputs.ReportingStart| prestoTimestamp |}' AS period_start,
      timestamp '{| default .Report.ReportingEnd .Report.Inputs.ReportingEnd | prestoTimestamp |}' AS period_end,
      labels['namespace'] as project,
      labels['label_serving_knative_dev_service'] as service,
      min("timestamp") as data_start,
      max("timestamp") as data_end,
      sum(amount * "timeprecision") AS service_usage_memory_byte_seconds
    FROM {| dataSourceTableName .Report.Inputs.KnativeServiceMemoryUsageDataSource |}
    WHERE "timestamp" >= timestamp '{| default .Report.ReportingStart .Report.Inputs.ReportingStart | prestoTimestamp |}'
    AND "timestamp" < timestamp '{| default .Report.ReportingEnd .Report.Inputs.ReportingEnd | prestoTimestamp |}'
    GROUP BY labels['namespace'],labels['label_serving_knative_dev_service']

6.9.3.3. Knative Serving 미터링을 위한 쿼리 적용

  1. 다음 명령을 입력하여 ReportQuery를 적용합니다.

    $ oc apply -f <query-name>.yaml

    명령 예

    $ oc apply -f knative-service-memory-usage.yaml

6.9.4. Knative Serving에 대한 미터링 보고서

Report 리소스를 생성하여 Knative Serving에 대한 미터링 보고서를 실행할 수 있습니다. 보고서를 실행하기 전에 Report 리소스 내에서 입력 매개변수를 수정하여 보고 기간 시작일 및 종료일을 지정해야 합니다.

YAML 파일

apiVersion: metering.openshift.io/v1
kind: Report
metadata:
  name: knative-service-cpu-usage
spec:
  reportingStart: '2019-06-01T00:00:00Z' 1
  reportingEnd: '2019-06-30T23:59:59Z' 2
  query: knative-service-cpu-usage 3
runImmediately: true

1
ISO 8601 형식의 보고서 시작일입니다.
2
ISO 8601 형식의 보고서 종료일입니다.
3
CPU 사용량 보고서의 경우 knative-service-cpu-usage 또는 메모리 사용량 보고서의 경우 knative-service-memory-usage입니다.

6.9.4.1. 미터링 보고서 실행

  1. 다음 명령을 입력하여 보고서를 실행합니다.

    $ oc apply -f <report-name>.yml
  2. 그러면 다음 명령을 입력하여 보고서를 확인할 수 있습니다.

    $ oc get report

    출력 예

    NAME                        QUERY                       SCHEDULE   RUNNING    FAILED   LAST REPORT TIME       AGE
    knative-service-cpu-usage   knative-service-cpu-usage              Finished            2019-06-30T23:59:59Z   10h

6.10. OpenShift Serverless의 고가용성

고가용성(HA)은 중단이 발생하는 경우 API가 작동하도록 하는 데 도움이 되는 Kubernetes API의 표준 기능입니다. HA 배포에서 활성 컨트롤러가 충돌하거나 삭제되면 현재 사용할 수 없는 컨트롤러에서 서비스 중이던 API를 다른 컨트롤러를 사용하여 대신 처리할 수 있습니다.

OpenShift Serverless의 HA는 Knative Serving 또는 Eventing 컨트롤 플레인을 설치하면 기본적으로 활성화되는 리더 선택을 통해 사용할 수 있습니다.

리더 선택 HA 패턴을 사용하는 경우에는 요구하기 전에 컨트롤러의 인스턴스가 이미 예약되어 클러스터 내에서 실행됩니다. 이러한 컨트롤러 인스턴스는 리더 선택 잠금이라는 공유 리소스를 사용하기 위해 경쟁합니다. 특정 시점에 리더 선택 잠금 리소스에 액세스할 수 있는 컨트롤러의 인스턴스를 리더라고 합니다.

6.10.1. OpenShift Serverless의 고가용성 복제본 구성

HA(고가용성) 기능은 OpenShift Serverless에서 Knative Serving, Knative Eventing 및 Knative Kafka에서 기본적으로 사용할 수 있습니다. 각 구성 요소는 다음과 같습니다.

  • Knative Serving: activator, autoscaler, autoscaler-hpa, controller, webhook, kourier-control, kourier-gateway.
  • Knative Eventing: eventing-controller, eventing-webhook, imc-controller, imc-dispatcher, mt-broker-controller, sugar-controller.
  • Knative Kafka: kafka-ch-controller, kafka-controller-manager, kafka-webhook.

이러한 구성 요소는 기본적으로 두 개의 복제본으로 구성됩니다.

Knative Eventing의 경우 mt-broker-filtermt-broker-ingress 배포는 HA에 의해 확장되지 않습니다. 여러 배포가 필요한 경우 이러한 구성 요소를 수동으로 스케일링합니다.

KnativeServing 사용자 정의 리소스 (CR), KnativeEventing CR 또는 KnativeKafka CR의 spec.high-availability.replicas 구성을 변경하여 구성 요소마다 작성되는 복제본의 수를 변경합니다.

6.10.1.1. Serving의 고가용성 복제본 구성

Knative Serving 구성 요소는 KnativeServing 사용자 지정 리소스의 spec.high-availability.replicas 값을 변경하여 조정할 수 있습니다.

사전 요구 사항

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

프로세스

  1. OpenShift Container Platform 웹 콘솔의 관리자 화면에서 OperatorHub설치된 Operator로 이동합니다.
  2. knative-serving 네임스페이스를 선택합니다.
  3. OpenShift Serverless Operator의 제공되는 API 목록에서 Knative Serving을 클릭하여 Knative Serving 탭으로 이동합니다.
  4. knative-serving을 클릭한 다음 knative-serving 페이지의 YAML 탭으로 이동합니다.

    Knative Serving YAML
  5. KnativeServing CRD의 복제본 수를 변경합니다.

    YAML의 예

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeServing
    metadata:
      name: knative-serving
      namespace: knative-serving
    spec:
      high-availability:
        replicas: 3 1

    1
    복제본 수를 3으로 설정합니다.
    중요

    config 필드에 포함된 YAML은 수정하지 마십시오. 이 필드의 일부 구성 값은 OpenShift Serverless Operator에서 삽입하며 수정 시 배포가 지원되지 않습니다.

    • replicas 값은 모든 HA 컨트롤러의 복제본 수를 설정합니다.
    • 기본 replicas 값은 2입니다.
    • 값을 3 이상으로 변경하여 복제본 수를 늘릴 수 있습니다.

6.10.1.2. Eventing의 고가용성 복제본 구성

KnativeEventing 사용자 정의 리소스에서 spec.high-availability.replicas 값을 수정하여 Knative Eventing 구성 요소를 조정할 수 있습니다.

사전 요구 사항

  • 클러스터 관리자 액세스 권한이 있는 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • OpenShift Serverless Operator 및 Knative Eventing이 클러스터에 설치되어 있습니다.

절차

  1. OpenShift Container Platform 웹 콘솔의 관리자 화면에서 OperatorHub설치된 Operator로 이동합니다.
  2. knative-serving 네임스페이스를 선택합니다.
  3. OpenShift Serverless Operator의 제공되는 API 목록에서 Knative Eventing을 클릭하여 Knative Eventing 탭으로 이동합니다.
  4. knative-eventing을 클릭한 다음 knative-eventing 페이지의 YAML 탭으로 이동합니다.

    Knative Eventing YAML
  5. KnativeEventing CRD의 복제본 수를 수정합니다.

    YAML의 예

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeEventing
    metadata:
      name: knative-eventing
      namespace: knative-eventing
    spec:
      high-availability:
        replicas: 3 1

    1
    복제본 수를 3으로 설정합니다.
    중요

    config 필드에 포함된 YAML은 수정하지 마십시오. 이 필드의 일부 구성 값은 OpenShift Serverless Operator에서 삽입하며 수정 시 배포가 지원되지 않습니다.

    • replicas 값은 모든 HA 컨트롤러의 복제본 수를 설정합니다.
    • 기본 replicas 값은 2입니다.
    • 값을 3 이상으로 변경하여 복제본 수를 늘릴 수 있습니다.

6.10.1.3. Kafka의 고가용성 복제본 구성

KnativeKafka 사용자 정의 리소스에서 spec.high-availability.replicas 값을 수정하여 Knative Kafka 구성 요소를 조정할 수 있습니다.

사전 요구 사항

  • 클러스터 관리자 액세스 권한이 있는 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • OpenShift Serverless Operator 및 Knative Kafka가 클러스터에 설치되어 있습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔의 관리자 화면에서 OperatorHub설치된 Operator로 이동합니다.
  2. knative-serving 네임스페이스를 선택합니다.
  3. OpenShift Serverless Operator의 제공되는 API 목록에서 Knative Kafka를 클릭하여 Knative Kafka 탭으로 이동합니다.
  4. knative-kafka를 클릭한 다음 knative-kafka 페이지의 YAML 탭으로 이동합니다.

    Knative Kafka YAML
  5. KnativeKafka CRD의 복제본 수를 수정합니다.

    YAML의 예

    apiVersion: operator.serverless.openshift.io/v1alpha1
    kind: KnativeKafka
    metadata:
      name: knative-kafka
      namespace: knative-eventing
    spec:
      high-availability:
        replicas: 3 1

    1
    복제본 수를 3으로 설정합니다.
    중요

    config 필드에 포함된 YAML은 수정하지 마십시오. 이 필드의 일부 구성 값은 OpenShift Serverless Operator에서 삽입하며 수정 시 배포가 지원되지 않습니다.

    • replicas 값은 모든 HA 컨트롤러의 복제본 수를 설정합니다.
    • 기본 replicas 값은 2입니다.
    • 값을 3 이상으로 변경하여 복제본 수를 늘릴 수 있습니다.

7장. 모니터

7.1. OpenShift Serverless에서 OpenShift Logging 사용

7.1.1. OpenShift Logging 배포 이해

OpenShift Container Platform 클러스터 관리자는 OpenShift Container Platform 웹 콘솔 또는 CLI에서 OpenShift Logging을 배포하여 OpenShift Elasticsearch Operator 및 Red Hat OpenShift Logging Operator를 설치할 수 있습니다. Operator가 설치되면 ClusterLogging 사용자 정의 리소스(CR)를 생성하여 OpenShift Logging Pod 및 OpenShift Logging을 지원하는 데 필요한 기타 리소스를 예약합니다. Operator는 OpenShift Logging의 배포, 업그레이드 및 유지보수를 담당합니다.

ClusterLogging CR은 로그를 수집, 저장 및 시각화하기 위해 로깅 스택의 모든 구성 요소를 포함하는 전체 OpenShift Logging 환경을 정의합니다. Red Hat OpenShift Logging Operator는 OpenShift Logging CR을 감시하고 그에 따라 로깅 배포를 조정합니다.

관리자와 애플리케이션 개발자는 보기 권한이 있는 프로젝트의 로그를 볼 수 있습니다.

7.1.2. OpenShift Logging 배포 및 구성 정보

OpenShift Logging은 중소 규모의 OpenShift Container Platform 클러스터에 맞게 튜닝된 기본 구성에서 사용하도록 설계되었습니다.

다음 설치 지침에는 OpenShift Logging 인스턴스를 생성하고 OpenShift Logging 환경을 구성하는 데 사용할 수 있는 샘플 ClusterLogging CR(사용자 정의 리소스)이 포함되어 있습니다.

기본 OpenShift 로깅 설치를 사용하려는 경우 샘플 CR을 직접 사용하면 됩니다.

배포를 사용자 정의하려면 필요에 따라 샘플 CR을 변경합니다. 이어지는 내용에서는 OpenShift Logging 인스턴스를 설치할 때 수행하거나 설치 후 수정할 수 있는 구성에 대해 설명합니다. ClusterLogging 사용자 정의 리소스 외부에서 수행할 수 있는 수정을 포함하여 각 구성 요소의 작업에 대한 자세한 내용은 구성 섹션을 참조하십시오.

7.1.2.1. OpenShift Logging 구성 및 튜닝

openshift-logging 프로젝트에 배포된 ClusterLogging 사용자 정의 리소스를 수정하여 OpenShift Logging 환경을 구성할 수 있습니다.

설치 시 또는 설치 후 다음 구성 요소를 수정할 수 있습니다.

메모리 및 CPU
유효한 메모리 및 CPU 값으로 resources 블록을 수정하여 각 구성 요소의 CPU 및 메모리 제한을 모두 조정할 수 있습니다.
spec:
  logStore:
    elasticsearch:
      resources:
        limits:
          cpu:
          memory: 16Gi
        requests:
          cpu: 500m
          memory: 16Gi
      type: "elasticsearch"
  collection:
    logs:
      fluentd:
        resources:
          limits:
            cpu:
            memory:
          requests:
            cpu:
            memory:
        type: "fluentd"
  visualization:
    kibana:
      resources:
        limits:
          cpu:
          memory:
        requests:
          cpu:
          memory:
      type: kibana
Elasticsearch 스토리지
storageClass namesize 매개변수를 사용하여 Elasticsearch 클러스터의 영구 스토리지 클래스 및 크기를 구성할 수 있습니다. Red Hat OpenShift Logging Operator는 이러한 매개변수를 기반으로 Elasticsearch 클러스터의 각 데이터 노드에 대한 PVC(영구 볼륨 클레임)를 생성합니다.
  spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage:
          storageClassName: "gp2"
          size: "200G"

이 예제에서는 클러스터의 각 데이터 노드가 "gp2" 스토리지의 "200G"를 요청하는 PVC에 바인딩되도록 지정합니다. 각 기본 분할은 단일 복제본에서 지원합니다.

참고

storage 블록을 생략하면 임시 스토리지만 포함하는 배포가 생성됩니다.

  spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage: {}
Elasticsearch 복제 정책

Elasticsearch 분할이 클러스터의 여러 데이터 노드에 복제되는 방법을 정의하는 정책을 설정할 수 있습니다.

  • FullRedundancy. 각 인덱스의 분할이 모든 데이터 노드에 완전히 복제됩니다.
  • MultipleRedundancy. 각 인덱스의 분할이 데이터 노드의 1/2에 걸쳐 있습니다.
  • SingleRedundancy. 각 분할의 단일 사본입니다. 두 개 이상의 데이터 노드가 존재하는 한 항상 로그를 사용할 수 있고 복구할 수 있습니다.
  • ZeroRedundancy. 분할 복사본이 없습니다. 노드가 다운되거나 실패하는 경우 로그를 사용할 수 없거나 로그가 손실될 수 있습니다.

7.1.2.2. 수정된 ClusterLogging 사용자 정의 리소스 샘플

다음은 이전에 설명한 옵션을 사용하여 수정한 ClusterLogging 사용자 정의 리소스의 예입니다.

수정된 ClusterLogging 사용자 정의 리소스 샘플

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
  namespace: "openshift-logging"
spec:
  managementState: "Managed"
  logStore:
    type: "elasticsearch"
    retentionPolicy:
      application:
        maxAge: 1d
      infra:
        maxAge: 7d
      audit:
        maxAge: 7d
    elasticsearch:
      nodeCount: 3
      resources:
        limits:
          memory: 32Gi
        requests:
          cpu: 3
          memory: 32Gi
        storage:
          storageClassName: "gp2"
          size: "200G"
      redundancyPolicy: "SingleRedundancy"
  visualization:
    type: "kibana"
    kibana:
      resources:
        limits:
          memory: 1Gi
        requests:
          cpu: 500m
          memory: 1Gi
      replicas: 1
  collection:
    logs:
      type: "fluentd"
      fluentd:
        resources:
          limits:
            memory: 1Gi
          requests:
            cpu: 200m
            memory: 1Gi

7.1.3. OpenShift 로깅을 사용하여 Knative Serving 구성 요소 로그 찾기

절차

  1. Kibana 경로를 가져옵니다.

    $ oc -n openshift-logging get route kibana
  2. 경로의 URL을 사용하여 Kibana 대시보드로 이동한 후 로그인합니다.
  3. 인덱스가 .all로 설정되어 있는지 확인합니다. 인덱스가 .all로 설정되어 있지 않으면 OpenShift Container Platform 시스템 로그만 나열됩니다.
  4. knative-serving 네임스페이스를 사용하여 로그를 필터링합니다. 검색 상자에 kubernetes.namespace_name:knative-serving을 입력하여 결과를 필터링합니다.
참고

Knative Serving에서는 기본적으로 구조화된 로깅을 사용합니다. OpenShift Logging Fluentd 설정을 사용자 정의하여 이러한 로그의 구문 분석을 활성화할 수 있습니다. 이렇게 하면 로그를 더 쉽게 검색할 수 있고 로그 수준에서 필터링하여 문제를 빠르게 확인할 수 있습니다.

7.1.4. OpenShift Logging을 사용하여 Knative Serving으로 배포한 서비스의 로그 찾기

OpenShift Logging을 사용하면 애플리케이션에서 콘솔에 쓰는 로그가 Elasticsearch에 수집됩니다. 다음 절차에서는 Knative Serving을 사용하여 배포한 애플리케이션에 이러한 기능을 적용하는 방법을 간략하게 설명합니다.

프로세스

  1. Kibana 경로를 가져옵니다.

    $ oc -n openshift-logging get route kibana
  2. 경로의 URL을 사용하여 Kibana 대시보드로 이동한 후 로그인합니다.
  3. 인덱스가 .all로 설정되어 있는지 확인합니다. 인덱스가 .all로 설정되어 있지 않으면 OpenShift 시스템 로그만 나열됩니다.
  4. knative-serving 네임스페이스를 사용하여 로그를 필터링합니다. 검색 상자에 서비스 필터를 입력하여 결과를 필터링합니다.

    필터 예제

    kubernetes.namespace_name:default AND kubernetes.labels.serving_knative_dev\/service:{service_name}

    /configuration 또는 /revision을 사용하여 필터링할 수도 있습니다.

  5. 애플리케이션에서 생성한 로그만 표시하려면 kubernetes.container_name:<user_container>를 사용하여 검색 범위를 좁힙니다. 그러지 않으면 큐 프록시의 로그가 표시됩니다.
참고

애플리케이션에서 JSON 기반 구조의 로깅을 사용하면 프로덕션 환경에서 이러한 로그를 빠르게 필터링할 수 있습니다.

7.2. Jaeger를 통한 요청 추적

OpenShift Serverless와 함께 Jaeger를 사용하면 OpenShift Container Platform에서 서버리스 애플리케이션에 분산 추적 기능을 활성화할 수 있습니다.

분산 추적은 애플리케이션을 구성하는 다양한 서비스를 통해 요청 경로를 기록합니다.

이 기능은 분산 트랜잭션의 전체 이벤트 체인을 이해하기 위해 서로 다른 작업 단위에 대한 정보를 함께 연결하는 데 사용됩니다. 작업 단위는 여러 프로세스 또는 호스트에서 실행될 수 있습니다.

개발자는 분산 추적을 사용하여 대규모 아키텍처의 호출 흐름을 시각화할 수 있습니다. 이는 직렬화, 병렬 처리, 대기 시간의 원인을 이해하는 데 유용합니다.

분산 추적에 대한 자세한 내용은 분산 추적 아키텍처분산 추적 설치를 참조하십시오.

7.2.1. OpenShift Serverless에서 사용할 Jaeger 구성

사전 요구 사항

OpenShift Serverless와 함께 사용할 Jaeger를 구성하려면 다음이 필요합니다.

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

프로세스

  1. 다음을 포함하는 Jaeger 사용자 정의 리소스 (CR) 파일을 생성하고 적용합니다.

    Jaeger CR

    apiVersion: jaegertracing.io/v1
    kind: Jaeger
    metadata:
      name: jaeger
      namespace: default

  2. KnativeServing CR을 편집하고 추적에 필요한 YAML 구성을 추가하여 Knative Serving에 대한 추적을 활성화합니다.

    YAML 추적 예

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeServing
    metadata:
      name: knative-serving
      namespace: knative-serving
    spec:
      config:
        tracing:
          sample-rate: "0.1" 1
          backend: zipkin 2
          zipkin-endpoint: http://jaeger-collector.default.svc.cluster.local:9411/api/v2/spans 3
          debug: "false" 4

    1
    sample-rate는 샘플링 가능성을 정의합니다. sample-rate 사용: "0.1" 는 10개의 추적 중 1개가 샘플링됨을 의미합니다.
    2
    backendzipkin으로 설정해야 합니다.
    3
    zipkin-endpointjaeger-collector 서비스 끝점을 가리켜야 합니다. 이 끝점을 가져오려면 Jaeger CR이 적용되는 네임스페이스를 대체합니다.
    4
    디버깅을 false로 설정해야 합니다. debug: "true"를 설정하여 디버그 모드를 활성화하면 모든 범위가 서버에 전송되어 샘플링 단계를 건너뜁니다.

검증

jaeger 경로를 사용하여 Jaeger 웹 콘솔에 액세스하여 추적 데이터를 볼 수 있습니다.

  1. 다음 명령을 입력하여 jaeger 경로의 호스트 이름을 가져옵니다.

    $ oc get route jaeger

    출력 예

    NAME     HOST/PORT                         PATH   SERVICES       PORT    TERMINATION   WILDCARD
    jaeger   jaeger-default.apps.example.com          jaeger-query   <all>   reencrypt     None

  2. 콘솔을 보려면 브라우저에서 끝점 주소를 엽니다.

7.3. 메트릭

지표를 사용하면 개발자가 Knative 서비스 성능을 모니터링할 수 있습니다.

7.3.1. 사전 요구 사항

  • OpenShift Container Platform에서 Knative 구성 요소에 대한 메트릭을 보려면 웹 콘솔 개발자 화면에 액세스해야 합니다.
주의

Service Mesh가 mTLS를 사용하여 사용하도록 설정된 경우 Service Mesh가 Prometheus의 메트릭 스크랩을 허용하지 않기 때문에 기본적으로 Knative Serviceing에 대한 메트릭이 사용되지 않도록 설정됩니다.

이 문제 해결에 대한 자세한 내용은 Integrating Service Mesh with OpenShift Serverless 를 참조하십시오.

7.3.2. 대기열 프록시 메트릭

각 Knative 서비스에는 애플리케이션 컨테이너에 대한 연결을 프록시하는 프록시 컨테이너가 있습니다. 큐 프록시 성능에 대해 여러 메트릭이 보고됩니다.

다음 메트릭을 사용하여 요청이 프록시 측에 대기되었는지 및 애플리케이션에서 요청을 처리할 때의 실제 지연을 측정할 수 있습니다.

메트릭 이름설명유형태그단위

revision_request_count

queue-proxy Pod로 라우팅되는 요청 수입니다.

카운터

configuration_name, container_name, namespace_name, pod_name, response_code, response_code_class, revision_name, service_name

정수(단위 없음)

revision_request_latencies

수정 버전 요청의 응답 시간입니다.

히스토그램

configuration_name, container_name, namespace_name, pod_name, response_code, response_code_class, revision_name, service_name

밀리초

revision_app_request_count

user-container pod로 라우팅되는 요청 수입니다.

카운터

configuration_name, container_name, namespace_name, pod_name, response_code, response_code_class, revision_name, service_name

정수(단위 없음)

revision_app_request_latencies

수정 버전 앱 요청의 응답 시간입니다.

히스토그램

configuration_name, namespace_name, pod_name, response_code, response_code_class, revision_name, service_name

밀리초

revision_queue_depth

servingwaiting 대기열의 현재 항목 수입니다. 무제한 동시 실행이 구성된 경우 이 메트릭은 보고되지 않습니다.

게이지

configuration_name, event-display, container_name, namespace_name, pod_name, response_code_class, revision_name, service_name

정수(단위 없음)

7.4. Knative 서비스 모니터링

OpenShift Container Platform 모니터링 스택을 사용하여 Knative 서비스에 대한 상태 점검 및 메트릭을 기록하고 확인할 수 있습니다. 이 섹션에서는 다음 주제에 대해 설명합니다.

  • 기본적으로 Knative 서비스가 노출하는 메트릭
  • 사용자 정의 메트릭 노출을 구성하는 방법
  • 노출된 메트릭을 스크랩하도록 모니터링 스택을 구성하는 방법
  • 서비스 메트릭 보는 방법
참고

메트릭을 스크랩하는 작업은 스크랩 요청이 활성화를 통과하지 않기 때문에 Knative 서비스의 자동 확장에 영향을 미치지 않습니다. 결과적으로 실행 중인 Pod가 없는 경우 스크랩이 수행되지 않습니다.

추가 리소스

7.4.1. 기본적으로 노출되는 Knative 서비스 메트릭

표 7.1. 포트 9090의 각 Knative 서비스에 대해 기본적으로 노출되는 메트릭

메트릭 이름, 단위 및 유형설명메트릭 태그

queue_requests_per_second

메트릭 단위: 무차원 단위

메트릭 유형: 게이지

큐 프록시에 도달하는 초당 요청 수입니다.

공식: stats.RequestCount / r.reportingPeriodSeconds

stats.RequestCount는 지정된 보고 기간 동안 네트워킹 pkg 통계에서 직접 계산됩니다.

destination_configuration="event-display", destination_namespace="pingsource1", destination_pod="event-display-00001-deployment-6b455479cb-75p6w", destination_revision="event-display-00001"

queue_proxied_operations_per_second

메트릭 단위: 무차원 단위

메트릭 유형: 게이지

초당 프록시된 요청 수입니다.

공식: stats.ProxiedRequestCount / r.reportingPeriodSeconds

stats.ProxiedRequestCount는 지정된 보고 기간 동안 네트워킹 pkg 통계에서 직접 계산됩니다.

 

queue_average_concurrent_requests

메트릭 단위: 무차원 단위

메트릭 유형: 게이지

이 Pod에서 현재 처리 중인 요청 수입니다.

평균 동시성은 다음과 같이 네트워킹 pkg 측에서 계산됩니다.

  • req 변경이 발생하면 변경 사이의 시간이 계산됩니다. 결과에 따라 delta를 초과하는 현재 동시성이 계산되어 현재 계산된 동시성에 추가됩니다. 또한 delta의 합계가 유지됩니다.

    delta를 통한 현재 동시성은 다음과 같이 계산됩니다.

    글로벌(_concurrency ): delta

  • 보고가 완료되면 합계와 현재 계산된 동시성이 재설정됩니다.
  • 평균 동시성을 보고할 때 현재 계산된 동시성은 deltas의 합계로 나뉩니다.
  • 새 요청이 도착하면 글로벌 동시성 카운터가 증가합니다. 요청이 완료되면 카운터가 줄어듭니다.

destination_configuration="event-display", destination_namespace="pingsource1", destination_pod="event-display-00001-deployment-6b455479cb-75p6w", destination_revision="event-display-00001"

queue_average_proxied_concurrent_requests

메트릭 단위: 무차원 단위

메트릭 유형: 게이지

이 Pod에서 현재 처리하는 프록시된 요청 수입니다.

stats.AverageProxiedConcurrency

destination_configuration="event-display", destination_namespace="pingsource1", destination_pod="event-display-00001-deployment-6b455479cb-75p6w", destination_revision="event-display-00001"

process_uptime

메트릭 단위: 초

메트릭 유형: 게이지

프로세스가 작동된 시간(초)입니다.

destination_configuration="event-display", destination_namespace="pingsource1", destination_pod="event-display-00001-deployment-6b455479cb-75p6w", destination_revision="event-display-00001"

표 7.2. 포트 9091의 각 Knative 서비스에 대해 기본적으로 노출되는 메트릭

메트릭 이름, 단위 및 유형설명메트릭 태그

request_count

메트릭 단위: 무차원 단위

메트릭 유형: 카운터

queue-proxy로 라우팅되는 요청 수입니다.

configuration_name="event-display", container_name="queue-proxy", namespace_name="apiserversource1", pod_name="event-display-00001-deployment-658fd4f9cf-qcnr5", response_code="200", response_code_class="2xx", revision_name="event-display-00001", service_name="event-display"

request_latencies

메트릭 단위: 밀리초

메트릭 유형: 히스토그램

응답 시간(밀리초)입니다.

configuration_name="event-display", container_name="queue-proxy", namespace_name="apiserversource1", pod_name="event-display-00001-deployment-658fd4f9cf-qcnr5", response_code="200", response_code_class="2xx", revision_name="event-display-00001", service_name="event-display"

app_request_count

메트릭 단위: 무차원 단위

메트릭 유형: 카운터

user-container로 라우팅되는 요청 수입니다.

configuration_name="event-display", container_name="queue-proxy", namespace_name="apiserversource1", pod_name="event-display-00001-deployment-658fd4f9cf-qcnr5", response_code="200", response_code_class="2xx", revision_name="event-display-00001", service_name="event-display"

app_request_latencies

메트릭 단위: 밀리초

메트릭 유형: 히스토그램

응답 시간(밀리초)입니다.

configuration_name="event-display", container_name="queue-proxy", namespace_name="apiserversource1", pod_name="event-display-00001-deployment-658fd4f9cf-qcnr5", response_code="200", response_code_class="2xx", revision_name="event-display-00001", service_name="event-display"

queue_depth

메트릭 단위: 무차원 단위

메트릭 유형: 게이지

제공 및 대기 대기열의 현재 항목 수 또는 무제한 동시성이 사용되는 경우 보고되지 않습니다. breaker.inFlight 가 사용됩니다.

configuration_name="event-display", container_name="queue-proxy", namespace_name="apiserversource1", pod_name="event-display-00001-deployment-658fd4f9cf-qcnr5", response_code="200", response_code_class="2xx", revision_name="event-display-00001", service_name="event-display"

7.4.2. 사용자 정의 애플리케이션 메트릭이 있는 Knative 서비스

Knative 서비스에서 내보낸 메트릭 집합을 확장할 수 있습니다. 정확한 구현은 애플리케이션 및 사용된 언어에 따라 다릅니다.

다음 목록에서는 처리된 이벤트 사용자 지정 메트릭을 내보내는 샘플 Go 애플리케이션을 구현합니다.

package main

import (
  "fmt"
  "log"
  "net/http"
  "os"

  "github.com/prometheus/client_golang/prometheus" 1
  "github.com/prometheus/client_golang/prometheus/promauto"
  "github.com/prometheus/client_golang/prometheus/promhttp"
)

var (
  opsProcessed = promauto.NewCounter(prometheus.CounterOpts{ 2
     Name: "myapp_processed_ops_total",
     Help: "The total number of processed events",
  })
)


func handler(w http.ResponseWriter, r *http.Request) {
  log.Print("helloworld: received a request")
  target := os.Getenv("TARGET")
  if target == "" {
     target = "World"
  }
  fmt.Fprintf(w, "Hello %s!\n", target)
  opsProcessed.Inc() 3
}

func main() {
  log.Print("helloworld: starting server...")

  port := os.Getenv("PORT")
  if port == "" {
     port = "8080"
  }

  http.HandleFunc("/", handler)

  // Separate server for metrics requests
  go func() { 4
     mux := http.NewServeMux()
     server := &http.Server{
        Addr: fmt.Sprintf(":%s", "9095"),
        Handler: mux,
     }
     mux.Handle("/metrics", promhttp.Handler())
     log.Printf("prometheus: listening on port %s", 9095)
     log.Fatal(server.ListenAndServe())
  }()

   // Use same port as normal requests for metrics
  //http.Handle("/metrics", promhttp.Handler()) 5
  log.Printf("helloworld: listening on port %s", port)
  log.Fatal(http.ListenAndServe(fmt.Sprintf(":%s", port), nil))
}
1
Prometheus 패키지 포함.
2
opsProcessed 메트릭 정의.
3
opsProcessed 메트릭 증가.
4
메트릭 요청에 대해 별도의 서버를 사용하도록 구성.
5
메트릭 및 metrics 하위 경로에 대한 일반 요청과 동일한 포트를 사용하도록 구성.

7.4.3. 사용자 정의 메트릭 스크랩 구성

사용자 정의 메트릭 스크랩은 사용자 워크로드 모니터링을 위해 Prometheus의 인스턴스에서 수행합니다. 사용자 워크로드 모니터링을 활성화하고 애플리케이션을 생성한 후에는 모니터링 스택에서 메트릭을 스크랩하는 방법을 정의하는 구성이 필요합니다.

다음 샘플 구성은 애플리케이션에 대한 ksvc를 정의하고 서비스 모니터를 구성합니다. 정확한 구성은 애플리케이션과 메트릭을 내보내는 방법에 따라 다릅니다.

apiVersion: serving.knative.dev/v1 1
kind: Service
metadata:
  name: helloworld-go
spec:
  template:
    metadata:
      labels:
        app: helloworld-go
      annotations:
    spec:
      containers:
      - image: docker.io/skonto/helloworld-go:metrics
        resources:
          requests:
            cpu: "200m"
        env:
        - name: TARGET
          value: "Go Sample v1"
---
apiVersion: monitoring.coreos.com/v1 2
kind: ServiceMonitor
metadata:
  labels:
  name: helloworld-go-sm
spec:
  endpoints:
  - port: queue-proxy-metrics
    scheme: http
  - port: app-metrics
    scheme: http
  namespaceSelector: {}
  selector:
    matchLabels:
       name:  helloworld-go-sm
---
apiVersion: v1 3
kind: Service
metadata:
  labels:
    name:  helloworld-go-sm
  name:  helloworld-go-sm
spec:
  ports:
  - name: queue-proxy-metrics
    port: 9091
    protocol: TCP
    targetPort: 9091
  - name: app-metrics
    port: 9095
    protocol: TCP
    targetPort: 9095
  selector:
    serving.knative.dev/service: helloworld-go
  type: ClusterIP
1
애플리케이션 사양.
2
스크랩되는 애플리케이션의 메트릭 구성.
3
메트릭을 스크랩하는 방식의 구성.

7.4.4. 서비스의 메트릭 검사

메트릭을 내보내도록 애플리케이션을 구성하고 모니터링 스택을 스크랩하면 웹 콘솔에서 메트릭을 검사할 수 있습니다.

절차

  1. 선택 사항: 메트릭에서 볼 수 있는 애플리케이션에 대한 요청을 실행합니다.

    $ hello_route=$(oc get ksvc helloworld-go -n ns1 -o jsonpath='{.status.url}') && \
        curl $hello_route

    출력 예

    Hello Go Sample v1!

  2. 웹 콘솔에서 모니터링메트릭 인터페이스로 이동합니다.
  3. 입력 필드에 모니터링할 메트릭의 쿼리를 입력합니다. 예를 들면 다음과 같습니다.

    revision_app_request_count{namespace="ns1", job="helloworld-go-sm"}

    다른 예:

    myapp_processed_ops_total{namespace="ns1", job="helloworld-go-sm"}
  4. 시각화된 메트릭을 모니터링합니다.

    서비스의 메트릭 모니터링
    서비스의 메트릭 모니터링

7.4.5. 대시보드에서 서비스의 메트릭 검사

네임스페이스별로 큐 프록시 메트릭을 집계하는 전용 대시보드를 사용하여 메트릭을 검사할 수 있습니다.

절차

  1. 웹 콘솔에서 모니터링메트릭 인터페이스로 이동합니다.
  2. Knative 사용자 서비스(Queue 프록시 메트릭) 대시보드를 선택합니다.
  3. 애플리케이션에 해당하는 네임스페이스,구성개정 버전을 선택합니다.
  4. 시각화된 메트릭을 모니터링합니다.

    대시보드를 사용하여 서비스의 메트릭 모니터링

7.5. 자동 스케일링 대시보드

Knative Serving - Scaling Debugging 대시보드를 사용하여 Knative Serving 자동 스케일링에 대한 세부적이고 시각화된 데이터를 검사할 수 있습니다. 대시보드는 다음과 같은 여러 용도로 유용합니다.

  • 자동 스케일링된 워크로드 문제 해결
  • 자동 스케일링 작동 방식에 대한 이해 개선
  • 애플리케이션이 자동 스케일링된 이유 확인
  • Pod 수와 같은 애플리케이션의 리소스 풋프린트 평가
중요

현재 이 대시보드는 Knative Pod 자동 스케일러(KPA)만 지원합니다. HPA(수평 Pod 자동 스케일러)를 지원하지 않습니다.

이 섹션의 대시보드 데모에서는 autoscale-go 샘플 애플리케이션이 설치된 OpenShift Container Platform 클러스터를 사용합니다. 로드는 hey 부하 생성기를 사용하여 생성됩니다.

샘플 애플리케이션에는 5개의 요청으로 동시성 제한이 있습니다. 제한이 초과되면 Kubernetes에서 Knative에 대한 추가 Pod를 자동 스케일링하여 요청합니다.

추가 리소스

7.5.1. 자동 스케일링 대시보드로 이동

절차

  1. OpenShift Container Platform 웹 UI에서 모니터링 → 대시보드 페이지로 이동합니다.
  2. 대시보드 필드에서 Knative Serving - Scaling Debugging 대시보드를 선택합니다.
  3. Namespace,Configuration, Revision 필드를 사용하여 검사할 워크로드를 지정합니다.

추가 리소스

7.5.2. Pod 정보

Knative Serving - Scaling Debugging 대시보드 상단에는 요청된 포드 수와 다양한 배포 단계에서 포드가 표시됩니다. Revision Pod Counts(Timeline) 그래프는 타임라인에 시각화된 동일한 데이터를 표시합니다. 이 정보는 Pod 할당 문제가 있는지 확인하여 자동 스케일링을 일반적인 평가에 유용할 수 있습니다.

Pod 정보

7.5.3. 관찰된 동시성

Observed Concurrency 그래프는 다음을 포함하여 일련의 동시성 관련 지표의 타임라인을 보여줍니다.

  • 요청 동시성
  • 패닉 동시성
  • 대상 동시성
  • 초과 버스트 용량

ExcessBurstCapacity 는 음수이며 , 기본적으로 버스티 부하가 나타나면 증가합니다. 이는 예비 용량과 구성된 대상 버스트 용량의 차이점과 동일합니다. ExcessBurstCapacity 가 음수이면 PodAutoscaler 컨트롤러에 의해 활성화기가 요청 경로에 스레드로 지정됩니다.

Serverless 자동 스케일링 대시보드에서 동시성 관찰

7.5.4. 스크랩 시간

scrap Time 그래프는 각 버전에 대한 스크랩 타임라인을 보여줍니다. 자동 확장은 서비스 Pod에서 들어오는 메트릭에 따라 스케일링을 결정하므로 스크랩 시간이 길면 워크로드가 변경되면 자동 스케일링이 지연될 수 있습니다.

스크랩 시간

7.5.5. 패닉 모드

Panic Mode 그래프는 Knative 서비스가 버스티 부하에 직면하는 시간의 타임라인을 표시하여 자동 스케일러가 서비스 Pod 번호를 빠르게 조정합니다.

패닉 모드

추가 리소스

7.5.6. 활성화기 메트릭

ActivatorRequest Concurrency (요청 동시성),Request Count by Response Code(마지막분)응답 시간(마지막분) 을 그래프로 표시하며, 요청 경로에서 활성화자가 제거될 때까지 활성화를 수행하는 요청의 타임라인을 표시합니다. 예를 들어 이러한 그래프를 사용하여 응답 수와 반환된 HTTP 코드가 기대치와 일치하는지 평가할 수 있습니다.

Activator: 요청 동시성
Activator: 응답 코드별 요청 개수 (마지막분)
Activator: 응답 시간 (마지막 분)

추가 리소스

7.5.7. 초당 요청 수

초당 다양한 유형의 요청을 시각화하는 추가 Observed RPS 대시보드를 사용할 수 있습니다.

  • stable_requests_per_second
  • panic_requests_per_second
  • target_requests_per_second
관찰된 RPS

Observed RPS 대시보드는 요청 주석이 설정된 경우에만 표시됩니다. 예를 들면 다음과 같습니다.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target: "10"
        autoscaling.knative.dev/metric: "rps"
    spec:
      containers:
        - image: docker.io/openshift/hello-openshift

8장. OpenShift Serverless 지원

8.1. 지원 요청

이 설명서에 설명된 절차를 수행하는 데 어려움이 있는 경우 Red Hat Customer Portal(http://access.redhat.com)을 방문하십시오. 고객 포털에서는 다음을 수행할 수 있습니다.

  • Red Hat 제품 관련 기술 지원 문서의 Red Hat Knowledgebase 검색 또는 찾아보기
  • Red Hat GSS(글로벌 지원 서비스)에 지원 사례 제출
  • 기타 제품 설명서에 대한 액세스

이 가이드를 개선할 수 있는 제안 사항이 있거나 오류를 발견한 경우 http://bugzilla.redhat.com에서 제품설명서 구성 요소에 대해 Bugzilla 보고서를 제출해 주십시오. 콘텐츠를 쉽게 찾을 수 있도록 섹션 번호, 가이드 이름, OpenShift Serverless 버전과 같은 구체적인 세부 사항을 입력하십시오.

8.2. 지원을 위한 진단 정보 수집

지원 사례를 여는 경우 클러스터에 대한 디버깅 정보를 Red Hat 지원에 제공하면 도움이 됩니다.

must-gather 툴을 사용하면 OpenShift Serverless 관련 데이터를 포함하여 OpenShift Container Platform 클러스터에 대한 진단 정보를 수집할 수 있습니다.

즉각 지원을 받을 수 있도록 OpenShift Container Platform 및 OpenShift Serverless 둘 다에 대한 진단 정보를 제공하십시오.

8.2.1. must-gather 툴 정보

oc adm must-gather CLI 명령은 다음과 같이 문제를 디버깅하는 데 필요할 가능성이 높은 클러스터 정보를 수집합니다.

  • 리소스 정의
  • 감사 로그
  • 서비스 로그

--image 인수를 포함하여 명령을 실행하는 경우 이미지를 하나 이상 지정할 수 있습니다. 이미지를 지정하면 툴에서 해당 기능 또는 제품과 관련된 데이터를 수집합니다.

oc adm must-gather를 실행하면 클러스터에 새 Pod가 생성됩니다. 해당 Pod에 대한 데이터가 수집되어 must-gather.local로 시작하는 새 디렉터리에 저장됩니다. 이 디렉터리는 현재 작업 중인 디렉터리에 생성되어 있습니다.

8.2.2. OpenShift Serverless 데이터 수집 정보

oc adm must-gather CLI 명령을 사용하면 OpenShift Serverless와 연관된 기능 및 오브젝트를 포함하여 클러스터에 대한 정보를 수집할 수 있습니다. must-gather로 OpenShift Serverless 데이터를 수집하려면 OpenShift Serverless 이미지 및 설치된 OpenShift Serverless 버전의 이미지 태그를 지정해야 합니다.

절차

  • oc adm must-gather 명령을 사용하여 데이터 수집

    $ oc adm must-gather --image=registry.redhat.io/openshift-serverless-1/svls-must-gather-rhel8:<image_version_tag>

    명령 예

    $ oc adm must-gather --image=registry.redhat.io/openshift-serverless-1/svls-must-gather-rhel8:1.14.0

9장. 보안

9.1. Knative 서비스의 JSON Web Token 인증 설정

OpenShift Serverless 및 Kourier와의 Service Mesh 통합이 클러스터에 설정된 후 Knative 서비스의 JSON Web Token (JWT) 인증을 활성화할 수 있습니다.

9.1.1. Knative 서비스에 사이드카 삽입 사용

sidecar.istio.io/inject="true" 주석을 Knative 서비스에 추가하여 해당 서비스에 대한 사이드카 삽입을 활성화할 수 있습니다.

중요

knative-servingknative-serving-ingress와 같은 시스템 네임스페이스의 Pod에 Kourier가 활성화되어 있는 경우 사이드카를 삽입할 수 없습니다.

이러한 네임스페이스의 Pod에 사이드카를 삽입해야 하는 경우 Service Mesh와 OpenShift Serverless 통합에 대한 OpenShift Serverless 문서를 참조하십시오.

절차

  1. Service 리소스에 sidecar.istio.io/inject="true" 주석을 추가합니다.

    서비스의 예

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      name: <service_name>
    spec:
      template:
        metadata:
          annotations:
            sidecar.istio.io/inject: "true" 1
            sidecar.istio.io/rewriteAppHTTPProbers: "true" 2
    ...

    1
    sidecar.istio.io/inject="true" 주석을 추가합니다.
    2
    Knative 서비스에서 주석 sidecar.istio.io/rewriteAppHTTPProbers: "true"를 OpenShift Serverless 버전 1.14.0으로 설정해야 하며 기본적으로 Knative 서비스의 준비 상태 프로브로 HTTP 프로브를 사용해야 합니다.
  2. Service 리소스 YAML 파일을 적용합니다.

    $ oc apply -f <filename>

9.1.2. Service Mesh 2.x 및 OpenShift Serverless에서 JSON 웹 토큰 인증 사용

절차

  1. ServiceMeshMemberRoll 오브젝트의 멤버인 각 서버리스 애플리케이션 네임스페이스에 RequestAuthentication 리소스를 생성합니다.

    apiVersion: security.istio.io/v1beta1
    kind: RequestAuthentication
    metadata:
      name: jwt-example
      namespace: <namespace>
    spec:
      jwtRules:
      - issuer: testing@secure.istio.io
        jwksUri: https://raw.githubusercontent.com/istio/istio/release-1.8/security/tools/jwt/samples/jwks.json
  2. RequestAuthentication 리소스를 적용합니다.

    $ oc apply -f <filename>
  3. 다음 AuthorizationPolicy 리소스를 생성하여 ServiceMeshMemberRoll 오브젝트의 멤버인 각 서버리스 애플리케이션 네임스페이스의 시스템 Pod에서 RequestAuthenticaton 리소스에 대한 액세스를 허용합니다.

    apiVersion: security.istio.io/v1beta1
    kind: AuthorizationPolicy
    metadata:
      name: allowlist-by-paths
      namespace: <namespace>
    spec:
      action: ALLOW
      rules:
      - to:
        - operation:
            paths:
            - /metrics 1
            - /healthz 2
    1
    시스템 Pod별 지표를 수집하는 애플리케이션의 경로입니다.
    2
    시스템 Pod별로 검색할 애플리케이션의 경로입니다.
  4. AuthorizationPolicy 리소스를 적용합니다.

    $ oc apply -f <filename>
  5. ServiceMeshMemberRoll 오브젝트의 멤버인 각 서버리스 애플리케이션 네임스페이스에서 다음 AuthorizationPolicy 리소스를 생성합니다.

    apiVersion: security.istio.io/v1beta1
    kind: AuthorizationPolicy
    metadata:
      name: require-jwt
      namespace: <namespace>
    spec:
      action: ALLOW
      rules:
      - from:
        - source:
           requestPrincipals: ["testing@secure.istio.io/testing@secure.istio.io"]
  6. AuthorizationPolicy 리소스를 적용합니다.

    $ oc apply -f <filename>

검증

  1. Knative 서비스 URL을 가져오기 위해 curl 요청을 사용하면 해당 요청이 거부됩니다.

    명령 예

    $ curl http://hello-example-1-default.apps.mycluster.example.com/

    출력 예

    RBAC: access denied

  2. 유효한 JWT로 요청을 확인합니다.

    1. 유효한 JWT 토큰을 가져옵니다.

      $ TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.8/security/tools/jwt/samples/demo.jwt -s) && echo "$TOKEN" | cut -d '.' -f2 - | base64 --decode -
    2. curl 요청 헤더에 유효한 토큰을 사용하여 서비스에 액세스합니다.

      $ curl -H "Authorization: Bearer $TOKEN"  http://hello-example-1-default.apps.example.com

      그러면 요청이 허용됩니다.

      출력 예

      Hello OpenShift!

9.1.3. Service Mesh 1.x 및 OpenShift Serverless에서 JSON 웹 토큰 인증 사용

절차

  1. 유효한 JWT(JSON 웹 토큰)가 있는 요청만 허용하는 ServiceMeshMemberRoll 오브젝트의 멤버인 서버리스 애플리케이션 네임스페이스에 정책을 생성합니다.

    중요

    /metrics/healthz 경로는 knative-serving 네임스페이스의 시스템 Pod에서 액세스하므로 excludedPaths에 포함되어야 합니다.

    apiVersion: authentication.istio.io/v1alpha1
    kind: Policy
    metadata:
      name: default
      namespace: <namespace>
    spec:
      origins:
      - jwt:
          issuer: testing@secure.istio.io
          jwksUri: "https://raw.githubusercontent.com/istio/istio/release-1.6/security/tools/jwt/samples/jwks.json"
          triggerRules:
          - excludedPaths:
            - prefix: /metrics 1
            - prefix: /healthz 2
      principalBinding: USE_ORIGIN
    1
    시스템 Pod별 지표를 수집하는 애플리케이션의 경로입니다.
    2
    시스템 Pod별로 검색할 애플리케이션의 경로입니다.
  2. Policy 리소스를 적용합니다.

    $ oc apply -f <filename>

검증

  1. Knative 서비스 URL을 가져오기 위해 curl 요청을 사용하면 해당 요청이 거부됩니다.

    $ curl http://hello-example-default.apps.mycluster.example.com/

    출력 예

    Origin authentication failed.

  2. 유효한 JWT로 요청을 확인합니다.

    1. 유효한 JWT 토큰을 가져옵니다.

      $ TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.6/security/tools/jwt/samples/demo.jwt -s) && echo "$TOKEN" | cut -d '.' -f2 - | base64 --decode -
    2. curl 요청 헤더에 유효한 토큰을 사용하여 서비스에 액세스합니다.

      $ curl http://hello-example-default.apps.mycluster.example.com/ -H "Authorization: Bearer $TOKEN"

      그러면 요청이 허용됩니다.

      출력 예

      Hello OpenShift!

9.2. Knative 서비스의 사용자 정의 도메인 구성

Knative 서비스에는 클러스터 구성에 따라 기본 도메인 이름이 자동으로 할당됩니다. 예를 들면 <service_name>.<namespace>.example.com과 같습니다.

서비스에 대한 DomainMapping 리소스를 생성하여 소유한 사용자 정의 도메인 이름을 Knative 서비스에 매핑하여 Knative 서비스의 도메인을 사용자 지정할 수 있습니다. 또한 여러 개의 DomainMapping 리소스를 생성하여 여러 도메인에 매핑하고 하위 도메인을 단일 서비스에 매핑할 수도 있습니다.

9.2.1. 사용자 정의 도메인 매핑 생성

사용자 정의 도메인 이름을 CR(사용자 정의 리소스)에 매핑하려면 Knative 서비스 또는 Knative 경로와 같이 주소 지정 가능 대상 CR에 매핑하는 DomainMapping CR을 생성해야 합니다.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Serving이 클러스터에 설치되어 있습니다.
  • Knative 서비스를 생성했으며 해당 서비스에 매핑할 사용자 정의 도메인을 제어할 수 있습니다.

    참고

    사용자 정의 도메인에서 OpenShift Container Platform 클러스터의 IP 주소를 참조해야 합니다.

절차

  1. 매핑하려는 대상 CR과 동일한 네임스페이스에 DomainMapping CR을 포함하는 YAML 파일을 생성합니다.

    apiVersion: serving.knative.dev/v1alpha1
    kind: DomainMapping
    metadata:
     name: <domain_name> 1
     namespace: <namespace> 2
    spec:
     ref:
       name: <target_name> 3
       kind: <target_type> 4
       apiVersion: serving.knative.dev/v1
    1
    대상 CR에 매핑할 사용자 정의 도메인 이름입니다.
    2
    DomainMapping CR 및 대상 CR의 네임스페이스입니다.
    3
    사용자 정의 도메인에 매핑할 대상 CR의 이름입니다.
    4
    사용자 지정 도메인에 매핑되는 CR 유형입니다.

    서비스 도메인 매핑 예

    apiVersion: serving.knative.dev/v1alpha1
    kind: DomainMapping
    metadata:
     name: example.com
     namespace: default
    spec:
     ref:
       name: example-service
       kind: Service
       apiVersion: serving.knative.dev/v1

    경로 도메인 매핑 예

    apiVersion: serving.knative.dev/v1alpha1
    kind: DomainMapping
    metadata:
     name: example.com
     namespace: default
    spec:
     ref:
       name: example-route
       kind: Route
       apiVersion: serving.knative.dev/v1

  2. DomainMapping CR을 YAML 파일로 적용합니다.

    $ oc apply -f <filename>

9.2.2. Knative CLI를 사용하여 사용자 정의 도메인 매핑 생성

kn CLI를 사용하여 Knative 서비스 또는 Knative 경로와 같이 주소 지정 대상 CR에 매핑되는 DomainMapping CR(사용자 정의 리소스)을 생성할 수 있습니다.

--ref 플래그는 도메인 매핑을 위해 주소 지정 가능한 대상 CR을 지정합니다.

--ref 플래그를 사용할 때 접두사가 지정되어 있지 않은 경우 대상이 현재 네임스페이스의 Knative 서비스라고 가정합니다. 다음 절차의 예제에서는 Knative 서비스 또는 Knative 경로에 매핑할 접두사를 보여줍니다.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Serving이 클러스터에 설치되어 있습니다.
  • Knative 서비스 또는 경로를 생성했으며 CR에 매핑할 사용자 정의 도메인을 제어할 수 있습니다.

    참고

    사용자 정의 도메인에서 OpenShift Container Platform 클러스터의 DNS를 가리켜야 합니다.

  • kn CLI 툴을 설치했습니다.

절차

  • 현재 네임스페이스의 CR에 도메인을 매핑합니다.

    $ kn domain create <domain_mapping_name> --ref <target_name>

    명령 예

    $ kn domain create example.com --ref example-service

  • 지정된 네임스페이스의 Knative 서비스에 도메인을 매핑합니다.

    $ kn domain create <domain_mapping_name> --ref <ksvc:service_name:service_namespace>

    명령 예

    $ kn domain create example.com --ref ksvc:example-service:example-namespace

  • 도메인을 Knative 경로에 매핑합니다.

    $ kn domain create <domain_mapping_name> --ref <kroute:route_name>

    명령 예

    $ kn domain create example.com --ref kroute:example-route

9.3. 도메인 매핑에 사용자 정의 TLS 인증서 사용

DomainMapping CR(사용자 정의 리소스)과 함께 기존 TLS 인증서를 사용하여 매핑된 서비스를 보호할 수 있습니다.

사전 요구 사항

9.3.1. DomainMapping CR에 사용자 정의 TLS 인증서 추가

DomainMapping CR(사용자 정의 리소스)을 사용하여 기존 TLS 인증서를 추가하여 매핑된 서비스를 보호할 수 있습니다.

사전 요구 사항

  • Knative 서비스의 사용자 정의 도메인을 구성하고 작동 중인 DomainMapping CR이 있습니다.
  • 인증 기관 공급자 또는 자체 서명 인증서의 TLS 인증서가 있어야 합니다.
  • 인증 기관 공급자 또는 자체 서명된 인증서에서 인증서 파일을 획득했습니다.

절차

  1. Kubernetes TLS 시크릿을 생성합니다.

    $ oc create secret tls <tls_secret_name> --cert=<path_to_certificate_file> --key=<path_to_key_file>
  2. 생성한 TLS 시크릿을 사용하도록 DomainMapping CR을 업데이트합니다.

    apiVersion: serving.knative.dev/v1alpha1
    kind: DomainMapping
    metadata:
      name: <domain_name>
      namespace: <namespace>
    spec:
      ref:
        name: <service_name>
        kind: Service
        apiVersion: serving.knative.dev/v1
    # TLS block specifies the secret to be used
      tls:
        secretName: <tls_secret_name>

검증

  1. DomainMapping CR 상태가 True 이고 출력의 URL 열에 체계 https 가 있는 매핑된 도메인이 표시되는지 확인합니다.

    $ oc get domainmapping <domain_name>

    출력 예

    NAME                      URL                               READY   REASON
    example.com               https://example.com               True

  2. 선택 사항: 서비스가 공개적으로 노출되면 다음 명령을 실행하여 사용할 수 있는지 확인합니다.

    $ curl https://<domain_name>

    인증서가 자체 서명된 경우 curl 명령에 -k 플래그를 추가하여 확인을 건너뜁니다.

10장. Knative Eventing

10.1. 브로커

브로커는 트리거와 함께 이벤트를 이벤트 소스에서 이벤트 싱크로 전달하는 데 사용할 수 있습니다.

브로커 이벤트 전달 개요

이벤트는 HTTP POST 요청으로 이벤트 소스에서 브로커로 전송할 수 있습니다.

이벤트가 브로커에 진입하면 트리거를 사용하여 CloudEvent 특성에 따라 필터링하고 이벤트 싱크에 HTTP POST 요청으로 전송할 수 있습니다.

10.1.1. 브로커 생성

OpenShift Serverless에서는 kn CLI를 사용하여 생성할 수 있는 default Knative 브로커를 제공합니다. 트리거에 eventing.knative.dev/injection: enabled 주석을 추가하거나 네임스페이스에 eventing.knative.dev/injection=enabled 라벨을 추가하여 default 브로커를 생성할 수도 있습니다.

10.1.1.1. Knative CLI를 사용하여 브로커 생성

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • kn CLI를 설치했습니다.

절차

  • default 브로커를 생성합니다.

    $ kn broker create default

검증

  1. kn 명령을 사용하여 기존 브로커를 모두 나열합니다.

    $ kn broker list

    출력 예

    NAME      URL                                                                     AGE   CONDITIONS   READY   REASON
    default   http://broker-ingress.knative-eventing.svc.cluster.local/test/default   45s   5 OK / 5     True

  2. 선택 사항: OpenShift Container Platform 웹 콘솔을 사용하는 경우 개발자 화면에서 토폴로지 보기로 이동하여 브로커가 존재하는지 관찰할 수 있습니다.

    웹 콘솔 토폴로지 보기에서 브로커 보기

10.1.1.2. 트리거에 주석을 달아 브로커 생성

Trigger 오브젝트에 eventing.knative.dev/injection: enabled 주석을 추가하여 브로커를 생성할 수 있습니다.

중요

eventing.knative.dev/injection: enabled 주석을 사용하여 브로커를 생성하는 경우 클러스터 관리자 권한이 없어 이 브로커를 삭제할 수 없습니다. 클러스터 관리자가 이 주석을 먼저 제거하기 전에 브로커를 삭제하면 삭제 후 브로커가 다시 생성됩니다.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • oc CLI를 설치했습니다.

절차

  1. eventing.knative.dev/injection: enabled 주석이 있는 Trigger 오브젝트를 YAML 파일로 생성합니다.

    apiVersion: eventing.knative.dev/v1
    kind: Trigger
    metadata:
      annotations:
        eventing.knative.dev/injection: enabled
      name: <trigger_name>
    spec:
      broker: default
      subscriber: 1
        ref:
          apiVersion: serving.knative.dev/v1
          kind: Service
          name: <service_name>
    1
    트리거에서 이벤트를 전송할 대상 이벤트 싱크 또는 구독자에 대한 세부 정보를 지정합니다.
  2. Trigger YAML 파일을 적용합니다.

    $ oc apply -f <filename>

검증

oc CLI를 사용하거나 웹 콘솔의 토폴로지 보기에서 브로커가 생성되었는지 확인할 수 있습니다.

  1. oc 명령을 사용하여 브로커를 가져옵니다.

    $ oc -n <namespace> get broker default

    출력 예

    NAME      READY     REASON    URL                                                                     AGE
    default   True                http://broker-ingress.knative-eventing.svc.cluster.local/test/default   3m56s

  2. 웹 콘솔에서 토폴로지 보기로 이동하여 브로커가 있는지 확인합니다.

    웹 콘솔 토폴로지 보기에서 브로커 보기

10.1.1.3. 네임스페이스에 라벨을 지정하여 브로커 생성

소유하고 있거나 쓰기 권한이 있는 네임스페이스에 라벨을 지정하여 default 브로커를 자동으로 생성할 수 있습니다.

참고

이 메서드를 사용하여 생성한 브로커는 라벨을 제거해도 제거되지 않습니다. 수동으로 삭제해야 합니다.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.

절차

  • eventing.knative.dev/injection=enabled를 사용하여 네임스페이스에 라벨을 지정합니다.

    $ oc label namespace <namespace> eventing.knative.dev/injection=enabled

검증

oc CLI를 사용하거나 웹 콘솔의 토폴로지 보기에서 브로커가 생성되었는지 확인할 수 있습니다.

  1. oc 명령을 사용하여 브로커를 가져옵니다.

    $ oc -n <namespace> get broker <broker_name>

    명령 예

    $ oc -n default get broker default

    출력 예

    NAME      READY     REASON    URL                                                                     AGE
    default   True                http://broker-ingress.knative-eventing.svc.cluster.local/test/default   3m56s

  2. 웹 콘솔에서 토폴로지 보기로 이동하여 브로커가 있는지 확인합니다.

    웹 콘솔 토폴로지 보기에서 브로커 보기

10.1.1.4. 삽입을 통해 생성된 브로커 삭제

네임스페이스 라벨 또는 트리거 주석을 사용하여 삽입을 통해 생성한 브로커는 개발자가 라벨 또는 주석을 제거해도 영구적으로 삭제되지 않습니다. 수동으로 브로커를 삭제해야 합니다.

절차

  1. 네임스페이스에서 eventing.knative.dev/injection=enabled 라벨을 제거합니다.

    $ oc label namespace <namespace> eventing.knative.dev/injection-

    주석을 제거하면 Knative에서 브로커를 삭제한 후 다시 생성하지 않습니다.

  2. 선택한 네임스페이스에서 브로커를 삭제합니다.

    $ oc -n <namespace> delete broker <broker_name>

검증

  • oc 명령을 사용하여 브로커를 가져옵니다.

    $ oc -n <namespace> get broker <broker_name>

    명령 예

    $ oc -n default get broker default

    출력 예

    No resources found.
    Error from server (NotFound): brokers.eventing.knative.dev "default" not found

10.1.2. 브로커 관리

kn CLI에서는 브로커를 나열, 설명, 업데이트, 삭제하는 데 사용할 수 있는 명령을 제공합니다.

10.1.2.1. Knative CLI를 사용하여 기존 브로커 나열

사전 요구 사항

  • OpenShift Serverless Operator, Knative Serving, Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • kn CLI를 설치했습니다.

프로세스

  • 기존 브로커를 모두 나열합니다.

    $ kn broker list

    출력 예

    NAME      URL                                                                     AGE   CONDITIONS   READY   REASON
    default   http://broker-ingress.knative-eventing.svc.cluster.local/test/default   45s   5 OK / 5     True

10.1.2.2. Knative CLI를 사용하여 기존 브로커 설명

사전 요구 사항

  • OpenShift Serverless Operator, Knative Serving, Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • kn CLI를 설치했습니다.

프로세스

  • 기존 브로커를 설명합니다.

    $ kn broker describe <broker_name>

    기본 브로커를 사용하는 명령의 예

    $ kn broker describe default

    출력 예

    Name:         default
    Namespace:    default
    Annotations:  eventing.knative.dev/broker.class=MTChannelBasedBroker, eventing.knative.dev/creato ...
    Age:          22s
    
    Address:
      URL:    http://broker-ingress.knative-eventing.svc.cluster.local/default/default
    
    Conditions:
      OK TYPE                   AGE REASON
      ++ Ready                  22s
      ++ Addressable            22s
      ++ FilterReady            22s
      ++ IngressReady           22s
      ++ TriggerChannelReady    22s

10.2. 트리거를 사용하여 브로커의 이벤트 필터링

트리거를 사용하면 브로커의 이벤트를 필터링하여 이벤트 싱크로 전달할 수 있습니다.

10.2.1. 사전 요구 사항

  • Knative Eventing 및 kn CLI가 설치되어 있습니다.
  • 사용 가능한 브로커에 액세스할 수 있습니다.
  • 사용 가능한 이벤트 소비자(예: Knative 서비스)에 액세스할 수 있습니다.

10.2.2. 개발자 화면을 사용하여 트리거 생성

브로커를 생성한 후에는 웹 콘솔의 개발자 화면에 트리거를 생성할 수 있습니다.

사전 요구 사항

  • OpenShift Serverless Operator, Knative Serving, Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • 웹 콘솔에 로그인했습니다.
  • 개발자 화면에 있습니다.
  • 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
  • 트리거에 연결할 브로커 및 Knative 서비스 또는 기타 이벤트 싱크를 생성했습니다.

프로세스

  1. 개발자 화면에서 토폴로지 페이지로 이동합니다.
  2. 트리거를 생성할 브로커 위로 마우스 커서를 이동한 후 화살표를 끕니다. 트리거 추가 옵션이 표시됩니다.

    브로커에 대한 트리거 생성
  3. 트리거 추가를 클릭합니다.
  4. 드롭다운 목록에서 싱크를 구독자로 선택합니다.
  5. 추가를 클릭합니다.

검증

  • 서브스크립션이 생성되면 토폴로지 보기에 브로커를 서비스에 연결하는 선이 표시됩니다.

    토폴로지 보기의 트리거

10.2.3. 개발자 화면을 사용하여 트리거 삭제

웹 콘솔의 개발자 화면에서 트리거를 삭제할 수 있습니다.

사전 요구 사항

  • 개발자 화면을 사용하여 트리거를 삭제하려면 먼저 웹 콘솔에 로그인해야 합니다.

프로세스

  1. 개발자 화면에서 토폴로지 페이지로 이동합니다.
  2. 삭제할 트리거를 클릭합니다.
  3. 작업 컨텍스트 메뉴에서 트리거 삭제를 선택합니다.

    트리거 삭제

10.2.4. Knative CLI를 사용하여 트리거 생성

kn trigger create 명령을 사용하여 트리거를 생성할 수 있습니다.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • kn CLI를 설치했습니다.

프로세스

  • 트리거를 생성합니다.

    $ kn trigger create <trigger_name> --broker <broker_name> --filter <key=value> --sink <sink_name>

    또는 트리거를 생성하고 브로커 삽입을 사용하여 default 브로커를 동시에 생성할 수 있습니다.

    $ kn trigger create <trigger_name> --inject-broker --filter <key=value> --sink <sink_name>

    기본적으로 트리거는 브로커에 전송된 모든 이벤트를 해당 브로커에 가입된 싱크로 전달합니다. 트리거에 --filter 특성을 사용하면 브로커의 이벤트를 필터링하여 구독자에게 정의된 기준에 따라 일부 이벤트만 제공할 수 있습니다.

10.2.5. Knative CLI를 사용하여 트리거 나열

kn trigger list 명령은 사용 가능한 트리거 목록을 인쇄합니다.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • kn CLI를 설치했습니다.

프로세스

  1. 사용 가능한 트리거 목록을 인쇄합니다.

    $ kn trigger list

    출력 예

    NAME    BROKER    SINK           AGE   CONDITIONS   READY   REASON
    email   default   ksvc:edisplay   4s    5 OK / 5     True
    ping    default   ksvc:edisplay   32s   5 OK / 5     True

  2. 선택 사항: JSON 형식으로 트리거 목록을 인쇄합니다.

    $ kn trigger list -o json

10.2.6. Knative CLI를 사용하여 트리거 설명

kn trigger describe 명령을 사용하여 트리거에 대한 정보를 출력할 수 있습니다.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • kn CLI를 설치했습니다.

프로세스

  • 명령을 입력합니다.

    $ kn trigger describe <trigger_name>

    출력 예

    Name:         ping
    Namespace:    default
    Labels:       eventing.knative.dev/broker=default
    Annotations:  eventing.knative.dev/creator=kube:admin, eventing.knative.dev/lastModifier=kube:admin
    Age:          2m
    Broker:       default
    Filter:
      type:       dev.knative.event
    
    Sink:
      Name:       edisplay
      Namespace:  default
      Resource:   Service (serving.knative.dev/v1)
    
    Conditions:
      OK TYPE                  AGE REASON
      ++ Ready                  2m
      ++ BrokerReady            2m
      ++ DependencyReady        2m
      ++ Subscribed             2m
      ++ SubscriberResolved     2m

10.2.7. Knative CLI를 사용하여 트리거로 이벤트 필터링

다음 트리거 예제에서는 type: dev.knative.samples.helloworld 특성이 있는 이벤트만 이벤트 싱크에 도달합니다.

$ kn trigger create <trigger_name> --broker <broker_name> --filter type=dev.knative.samples.helloworld --sink ksvc:<service_name>

여러 특성을 사용하여 이벤트를 필터링할 수도 있습니다. 다음 예제는 유형, 소스, 확장 특성을 사용하여 이벤트를 필터링하는 방법을 보여줍니다.

$ kn trigger create <trigger_name> --broker <broker_name> --sink ksvc:<service_name> \
--filter type=dev.knative.samples.helloworld \
--filter source=dev.knative.samples/helloworldsource \
--filter myextension=my-extension-value

10.2.8. Knative CLI를 사용하여 트리거 업데이트

kn trigger update 명령을 특정 플래그와 함께 사용하여 트리거의 특성을 업데이트할 수 있습니다.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • kn CLI를 설치했습니다.

절차

  • 태그를 업데이트합니다.

    $ kn trigger update <trigger_name> --filter <key=value> --sink <sink_name> [flags]
    • 트리거를 업데이트하여 수신 이벤트와 정확히 일치하는 이벤트 특성을 필터링할 수 있습니다. 예를 들면 type 특성을 사용합니다.

      $ kn trigger update <trigger_name> --filter type=knative.dev.event
    • 트리거에서 필터 특성을 제거할 수 있습니다. 예를 들어 type 키를 사용하여 필터 특성을 제거할 수 있습니다.

      $ kn trigger update <trigger_name> --filter type-
    • --sink 매개변수를 사용하여 트리거의 이벤트 싱크를 변경할 수 있습니다.

      $ kn trigger update <trigger_name> --sink ksvc:my-event-sink

10.2.9. Knative CLI를 사용하여 트리거 삭제

kn trigger delete 명령을 사용하여 트리거를 삭제할 수 있습니다.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • kn CLI를 설치했습니다.

프로세스

  • 트리거를 삭제합니다.

    $ kn trigger delete <trigger_name>

검증

  1. 기존 트리거를 나열합니다.

    $ kn trigger list
  2. 트리거가 더 이상 존재하지 않는지 확인합니다.

    출력 예

    No triggers found.

10.3. 이벤트 전달

서브스크립션을 통해 이벤트를 전달하지 못하는 경우 Knative Eventing에 대한 이벤트 전달 매개변수를 구성할 수 있습니다. 이벤트 전달 매개변수는 서브스크립션별로 개별적으로 구성됩니다.

10.3.1. Knative Eventing 채널의 이벤트 전달 동작

다양한 Knative Eventing 채널 유형에는 이벤트 전달에 사용되는 자체 동작 패턴이 있습니다. 개발자는 서브스크립션 구성에서 이벤트 전달 매개 변수를 설정하여 채널에서 이벤트 싱크로 전달하지 못한 이벤트를 검색할 수 있습니다. 또한 최종적으로 제공되지 않는 이벤트를 저장할 수 있는 싱크를 제공하려면 서브스크립션에 대해 dead letter sink를 구성해야 합니다. 이를 구성하지 않으면 전달되지 않은 이벤트가 드롭됩니다.

10.3.1.1. Knative Kafka 채널의 이벤트 전달 동작

이벤트가 Kafka 채널 또는 브로커 수신자에게 성공적으로 전달되면 수신자는 202 상태 코드로 응답합니다. 즉, 이벤트가 Kafka 주제 내부에 안전하게 저장되어 손실되지 않습니다. 수신자가 다른 상태 코드로 응답하는 경우 이벤트는 안전하게 저장되지 않으며 이 문제를 해결하기 위해 사용자가 단계를 수행해야 합니다.

10.3.1.2. 전달 실패 상태 코드

이벤트가 전달되지 않으면 채널 또는 브로커 수신자는 다음 상태 코드로 응답할 수 있습니다.

500
이는 이벤트가 성공적으로 전달되지 않았음을 나타내는 일반적인 상태 코드입니다.
404
이 상태 코드는 이벤트가 전달되는 채널 또는 브로커가 없거나 Host 헤더가 잘못되었음을 나타냅니다.
400
이 상태 코드는 수신자에게 전송되는 이벤트가 유효하지 않음을 나타냅니다.

10.3.2. 구성 가능한 매개변수

이벤트 전달을 위해 다음 매개 변수를 구성할 수 있습니다.

dead letter sink
이벤트가 전달되지 않으면 지정된 이벤트 싱크로 전송되도록 deadLetterSink 전달 매개변수를 구성할 수 있습니다.
retries
재시도 전달 매개변수를 정수 값으로 구성하여 이벤트가 dead letter sink로 전송되기 전에 전달을 retry해야 하는 최소 횟수를 설정할 수 있습니다.
back off delay
backoffDelay 전달 매개변수를 설정하여 실패 후 이벤트 전달을 재시도하기 전에 시간 지연을 지정할 수 있습니다. backoffDelay 매개변수의 기간은 ISO 8601 형식을 사용하여 지정합니다.
back off policy
backoffPolicy 전달 매개 변수를 사용하여 재시도 정책을 지정할 수 있습니다. 정책을 linear 또는 exponential로 지정할 수 있습니다. linear 백오프 정책을 사용할 때 백오프 지연은 재시도 사이에 지정된 시간 간격입니다. exponential 백오프 정책을 사용하는 경우 백오프 지연은 backoffDelay*2^<numberOfRetries>와 동일합니다.

10.3.3. 서브스크립션을 사용하여 이벤트 전달 실패 매개변수 구성

개발자는 Subscription 오브젝트의 전달 설정을 수정하여 개별 서브스크립션에 대한 이벤트 delivery 매개 변수를 구성할 수 있습니다.

서브스크립션 YAML의 예

apiVersion: messaging.knative.dev/v1
kind: Subscription
metadata:
  name: <subscription_name>
  namespace: <subscription_namespace>
spec:
  delivery:
    deadLetterSink: 1
      ref:
        apiVersion: serving.knative.dev/v1
        kind: Service
        name: <sink_name>
    backoffDelay: <duration> 2
    backoffPolicy: <policy_type> 3
    retry: <integer> 4

1
dead letter sink를 사용하여 활성화할 구성 설정입니다. 이 설정은 구독자에게 전달할 수 없는 이벤트에 어떤 일이 발생하는지 스브스크립션에 알립니다.

이 값을 구성하면 배달 할 수없는 이벤트가 dead letter sink의 목적지로 전송됩니다. 대상은 Knative 서비스 또는 URI일 수 있습니다.

2
backoffDelay 전달 매개변수를 설정하여 실패 후 이벤트 전달을 재시도하기 전에 시간 지연을 지정할 수 있습니다. backoffDelay 매개변수의 기간은 ISO 8601 형식을 사용하여 지정합니다. 예를 들어 PT1S는 1초 지연을 지정합니다.
3
backoffPolicy 전달 매개 변수를 사용하여 재시도 정책을 지정할 수 있습니다. 정책을 linear 또는 exponential로 지정할 수 있습니다. linear 백오프 정책을 사용할 때 백오프 지연은 재시도 사이에 지정된 시간 간격입니다. exponential 백오프 정책을 사용하는 경우 백오프 지연은 backoffDelay*2^<numberOfRetries>와 동일합니다.
4
이벤트가 dead letter sink로 전송되기 전에 이벤트 전달을 재시도하는 횟수입니다.

10.3.4. 추가 리소스

10.4. Knative Kafka

OpenShift Serverless에서는 KafkaChannel 채널 유형 및 KafkaSource 이벤트 소스를 사용할 수 있습니다. 이를 위해서는 Knative Kafka 구성 요소를 설치하고 OpenShift Serverless와 지원되는 Red Hat AMQ Streams 클러스터 간의 통합을 구성해야 합니다.

참고

Knative Kafka는 현재 IBM Z 및 IBM Power Systems에서 지원되지 않습니다.

10.4.1. 이벤트 전달 및 재시도

이벤트 중심 아키텍처에서 Kafka 구성 요소를 사용하면 이벤트 전달을 위해 "최소한" 보장이 제공됩니다. 즉, 반환 코드 값이 수신될 때까지 작업이 다시 시도됩니다. 그러나 이로 인해 애플리케이션이 손실된 이벤트의 복원력이 향상되지만 중복 이벤트가 전송될 수 있습니다.

Kafka 이벤트 소스의 경우 기본적으로 이벤트 전달을 위해 고정된 횟수가 있습니다. Kafka 채널의 경우 재시도는 Kafka 채널 전달 사양에 구성된 경우에만 수행됩니다.

10.4.2. Knative Kafka 설치

OpenShift Serverless Operator에서는 KnativeKafka 사용자 정의 리소스를 생성하는 데 사용할 수 있는 Knative Kafka API를 제공합니다.

KnativeKafka 사용자 정의 리소스의 예

apiVersion: operator.serverless.openshift.io/v1alpha1
kind: KnativeKafka
metadata:
    name: knative-kafka
    namespace: knative-eventing
spec:
    channel:
        enabled: true 1
        bootstrapServers: <bootstrap_servers> 2
    source:
        enabled: true 3

1
개발자가 클러스터에서 KafkaChannel 채널 유형을 사용할 수 있습니다.
2
AMQ Streams 클러스터에 있는 쉼표로 구분된 부트스트랩 서버 목록입니다.
3
개발자가 클러스터에서 KafkaSource 이벤트 소스 유형을 사용할 수 있습니다.

10.4.2.1. 웹 콘솔을 사용하여 Knative Kafka 구성 요소 설치

클러스터 관리자는 Knative Kafka OpenShift Serverless Operator API에서 제공하는 KnativeKafka 사용자 정의 리소스 정의를 인스턴스화하여 OpenShift Serverless 배포에서 Knative Kafka 기능을 사용하도록 설정할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터에 Knative Eventing을 포함한 OpenShift Serverless를 설치했습니다.
  • Red Hat AMQ Streams 클러스터에 액세스할 수 있습니다.
  • OpenShift Container Platform에 대한 클러스터 관리자 권한이 있습니다.
  • 웹 콘솔에 로그인되어 있습니다.

절차

  1. 관리자 화면에서 Operator설치된 Operator로 이동합니다.
  2. 페이지 상단에 있는 프로젝트 드롭다운이 Project: knative-eventing으로 설정되어 있는지 확인합니다.
  3. OpenShift Serverless Operator의 Provided APIs 목록에서 Knative Kafka를 검색하여 Create Instance를 클릭합니다.
  4. Knative Kafka 생성 페이지에서 KnativeKafka 오브젝트를 구성합니다.

    중요

    클러스터에서 Kafka 채널 또는 Kafka 소스를 사용하려면 사용할 옵션에 대해 Enable 스위치를 true로 전환해야 합니다. 이러한 스위치는 기본적으로 false로 설정됩니다. 또한 Kafka 채널을 사용하려면 Boostrap Server를 지정해야 합니다.

    1. 해당 양식은 KnativeKafka 오브젝트 생성을 완전히 제어할 필요가 없는 단순한 구성에 사용하는 것이 좋습니다.
    2. KnativeKafka 오브젝트 생성을 완전히 제어해야 하는 복잡한 구성의 경우 YAML을 편집하는 것이 좋습니다. Knative Kafka 생성 페이지의 오른쪽 상단에 있는 YAML 편집 링크를 클릭하여 YAML에 액세스할 수 있습니다.
  5. Kafka에 대한 선택적 구성을 완료한 후 생성을 클릭합니다. 그러면 리소스 목록에 knative-kafka가 있는 Knative Kafka 탭으로 자동으로 이동합니다.

검증

  1. Knative Kafka 탭에서 knative-kafka 리소스를 클릭합니다. 그러면 자동으로 Knative Kafka 개요 페이지로 이동합니다.
  2. 리소스에 대한 조건 목록을 확인하고 상태가 True인지 확인합니다.

    조건을 보여주는 Kafka Knative 개요 페이지

    조건 상태가 알 수 없음 또는 False인 경우 몇 분 정도 기다린 후 페이지를 새로 고칩니다.

  3. Knative Kafka 리소스가 생성되었는지 확인합니다.

    $ oc get pods -n knative-eventing

    출력 예

    NAME                                            READY   STATUS    RESTARTS   AGE
    kafka-ch-controller-85f879d577-xcbjh            1/1     Running   0          44s
    kafka-ch-dispatcher-55d76d7db8-ggqjl            1/1     Running   0          44s
    kafka-controller-manager-bc994c465-pt7qd        1/1     Running   0          40s
    kafka-webhook-54646f474f-wr7bb                  1/1     Running   0          42s

10.4.5. Kafka의 인증 구성

프로덕션 환경에서 Kafka 클러스터는 TLS 또는 SASL 인증 방법을 사용하여 보호됩니다. 이 섹션에서는 TLS 또는 SASL을 사용하여 보호된 Red Hat AMQ Streams(Kafka) 클러스터에서 작동하도록 Kafka 채널을 구성하는 방법을 설명합니다.

참고

SASL을 활성화하도록 선택하는 경우 TLS도 활성화하는 것이 좋습니다.

10.4.5.1. TLS 인증 구성

사전 요구 사항

  • Kafka 클러스터 CA 인증서를 .pem 파일로 생성합니다.
  • Kafka 클러스터 클라이언트 인증서 및 키는 .pem 파일입니다.

절차

  1. 선택한 네임스페이스에서 인증서 파일을 시크릿으로 생성합니다.

    $ kubectl create secret -n <namespace> generic <kafka_auth_secret> \
      --from-file=ca.crt=caroot.pem \
      --from-file=user.crt=certificate.pem \
      --from-file=user.key=key.pem
    중요

    키 이름 ca.crt,user.crt, user.key를 사용합니다. 이 값은 변경하지 마십시오.

  2. KnativeKafka 사용자 정의 리소스 편집을 시작합니다.

    $ oc edit knativekafka
  3. 시크릿 및 시크릿의 네임스페이스를 참조합니다.

    apiVersion: operator.serverless.openshift.io/v1alpha1
    kind: KnativeKafka
    metadata:
      namespace: knative-eventing
      name: knative-kafka
    spec:
      channel:
        authSecretName: <kafka_auth_secret>
        authSecretNamespace: <kafka_auth_secret_namespace>
        bootstrapServers: <bootstrap_servers>
        enabled: true
      source:
        enabled: true
    참고

    부트스트랩 서버에서 일치하는 포트를 지정해야 합니다.

    예를 들면 다음과 같습니다.

    apiVersion: operator.serverless.openshift.io/v1alpha1
    kind: KnativeKafka
    metadata:
      namespace: knative-eventing
      name: knative-kafka
    spec:
      channel:
        authSecretName: tls-user
        authSecretNamespace: kafka
        bootstrapServers: eventing-kafka-bootstrap.kafka.svc:9094
        enabled: true
      source:
        enabled: true

추가 리소스

10.4.5.2. SASL 인증 구성

사전 요구 사항

  • Kafka 클러스터의 사용자 이름 및 암호입니다.
  • 사용할 SASL 메커니즘을 선택합니다(예: PLAIN,SCRAM-SHA-256 또는 SCRAM-SHA-512 ).
  • TLS가 활성화된 경우 Kafka 클러스터의 ca.crt 인증서 파일도 필요합니다.
참고

Red Hat은 SASL 외에도 TLS를 활성화하는 것을 권장합니다.

절차

  1. 선택한 네임스페이스에서 인증서 파일을 시크릿으로 생성합니다.

    $ oc create secret --namespace <namespace> generic <kafka_auth_secret> \
      --from-file=ca.crt=caroot.pem \
      --from-literal=password="SecretPassword" \
      --from-literal=saslType="SCRAM-SHA-512" \
      --from-literal=user="my-sasl-user"
    중요

    키 이름 ca.crt,passwordsaslType을 사용합니다. 이 값은 변경하지 마십시오.

  2. KnativeKafka 사용자 정의 리소스 편집을 시작합니다.

    $ oc edit knativekafka
  3. 시크릿 및 시크릿의 네임스페이스를 참조합니다.

    apiVersion: operator.serverless.openshift.io/v1alpha1
    kind: KnativeKafka
    metadata:
      namespace: knative-eventing
      name: knative-kafka
    spec:
      channel:
        authSecretName: <kafka_auth_secret>
        authSecretNamespace: <kafka_auth_secret_namespace>
        bootstrapServers: <bootstrap_servers>
        enabled: true
      source:
        enabled: true
    참고

    부트스트랩 서버에서 일치하는 포트를 지정해야 합니다.

    예를 들면 다음과 같습니다.

    apiVersion: operator.serverless.openshift.io/v1alpha1
    kind: KnativeKafka
    metadata:
      namespace: knative-eventing
      name: knative-kafka
    spec:
      channel:
        authSecretName: scram-user
        authSecretNamespace: kafka
        bootstrapServers: eventing-kafka-bootstrap.kafka.svc:9093
        enabled: true
      source:
        enabled: true

추가 리소스

10.4.5.3. 공용 CA 인증서를 사용하여 SASL 인증 구성

공용 CA 인증서와 함께 SASL을 사용하려면 시크릿을 생성할 때 ca.crt 인수 대신 tls.enabled=true 플래그를 사용해야 합니다. 예를 들면 다음과 같습니다.

$ oc create secret --namespace <namespace> generic <kafka_auth_secret> \
  --from-literal=tls.enabled=true \
  --from-literal=password="SecretPassword" \
  --from-literal=saslType="SCRAM-SHA-512" \
  --from-literal=user="my-sasl-user"

추가 리소스

11장. 함수

11.1. OpenShift Serverless Functions 설정

중요

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

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

OpenShift Serverless에서 함수를 개발하려면 먼저 설정 단계를 완료해야 합니다.

11.1.1. 사전 요구 사항

클러스터에서 OpenShift Serverless Functions을 사용하려면 다음 단계를 완료해야 합니다.

  • OpenShift Serverless가 클러스터에 설치되어 있습니다.
  • oc CLI가 클러스터에 설치되어 있습니다.
  • Knative(kn) CLI가 클러스터에 설치되어 있습니다. kn CLI를 설치하면 함수를 생성하고 관리하는 데 사용할 수 있는 kn func 명령을 사용할 수 있습니다.
  • Docker Container Engine 또는 podman을 설치하고 사용 가능한 이미지 레지스트리에 액세스할 수 있습니다.
  • Quay.io를 이미지 레지스트리로 사용하는 경우 리포지토리가 비공개가 아닌지 확인하거나 pod가 다른 보안 레지스트리의 이미지를 참조하도록 허용하는 OpenShift Container Platform 설명서를 따라야 합니다.
  • OpenShift Container Registry를 사용하는 경우 클러스터 관리자가 레지스트리를 공개해야 합니다.

11.1.2. podman 사용

podman을 사용하는 경우 OpenShift Serverless Functions를 시작하기 전에 다음 명령을 실행해야 합니다.

  1. ${XDG_RUNTIME_DIR}/podman/podman.sock의 UNIX 소켓에서 Docker API를 제공하는 podman 서비스를 시작합니다.

    $ systemctl start --user podman.socket
    참고

    대부분의 시스템에서 이 소켓은 /run/user/$(id -u)/podman/podman.sock에 있습니다.

  2. 기능을 구축하는 데 사용되는 환경 변수를 설정합니다.

    $ export DOCKER_HOST="unix://${XDG_RUNTIME_DIR}/podman/podman.sock"
  3. 자세한 출력을 보려면 -v와 함께 빌드 명령을 실행합니다. 로컬 UNIX 소켓에 대한 연결이 표시됩니다.

    $ kn func build -v

11.1.3. 다음 단계

11.2. 함수 시작하기

중요

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

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

이 가이드에서는 OpenShift Serverless 설치에서 기능을 생성, 빌드 및 배포하는 방법을 설명합니다.

11.2.1. 사전 요구 사항

다음 절차를 완료하려면 먼저 OpenShift Serverless Functions 설정에서 모든 사전 요구 사항 작업을 완료해야 합니다.

11.2.2. 함수 생성

kn CLI를 사용하여 기본 서버리스 기능을 생성할 수 있습니다.

명령줄에서 템플릿을 플래그로 사용하여 경로, 런타임, 템플릿 및 리포지토리를 지정하거나 -c 플래그를 사용하여 터미널에서 대화형 환경을 시작할 수 있습니다.

절차

  • 함수 프로젝트를 생성합니다.

    $ kn func create -r <repository> -l <runtime> -t <template> <path>
    • 지원되는 런타임에는 node,go,python,quarkus, typescript 등이 있습니다.
    • 지원되는 템플릿에는 httpevents가 포함됩니다.

      명령 예

      $ kn func create -l typescript -t events examplefunc

      출력 예

      Project path:  /home/user/demo/examplefunc
      Function name: examplefunc
      Runtime:       typescript
      Template:      events
      Writing events to /home/user/demo/examplefunc

    • 또는 사용자 지정 템플릿이 포함된 리포지토리를 지정할 수도 있습니다.

      명령 예

      $ kn func create -r https://github.com/boson-project/templates/ -l node -t hello-world examplefunc

      출력 예

      Project path:  /home/user/demo/examplefunc
      Function name: examplefunc
      Runtime:       node
      Template:      hello-world
      Writing events to /home/user/demo/examplefunc

11.2.3. 함수 빌드

함수를 실행하려면 kn func build 명령을 사용하여 함수 프로젝트를 빌드해야 합니다. build 명령은 함수 프로젝트 디렉터리에서 func.yaml 파일을 읽고 이미지 이름과 레지스트리를 확인합니다.

func.yaml의 예

name: example-function
namespace: default
runtime: node
image: <image_from_registry>
imageDigest: ""
trigger: http
builder: default
builderMap:
  default: quay.io/boson/faas-nodejs-builder
envs: {}

func.yaml 파일에 이미지 이름과 레지스트리가 설정되지 않은 경우 kn func build 명령을 사용할 때 레지스트리 플래그인 -r을 지정해야 합니다. 그렇지 않으면 함수를 빌드할 때 터미널에 레지스트리 값을 입력하라는 메시지가 표시됩니다. 이미지 이름은 제공한 레지스트리 값을 기반으로 지정됩니다.

-r registry 플래그를 사용하는 명령의 예

$ kn func build [-i <image> -r <registry> -p <path>]

출력 예

Building function image
Function image has been built, image: quay.io/username/example-function:latest

이 명령은 컴퓨터에서 또는 Kubernetes 클러스터에서 로컬로 실행할 수 있는 OCI 컨테이너 이미지를 생성합니다.

registy 프롬프트 사용 예

$ kn func build
A registry for function images is required (e.g. 'quay.io/boson').

Registry for function images: quay.io/username
Building function image
Function image has been built, image: quay.io/username/example-function:latest

이미지 및 레지스트리 값은 func.yaml 파일에 유지되므로 후속 호출을 사용자가 다시 지정할 필요가 없습니다.

11.2.4. 함수 배포

kn func deploy 명령을 사용하여 Knative 서비스로 클러스터에 함수를 배포할 수 있습니다.

대상 함수가 이미 배포된 경우 컨테이너 이미지 레지스트리로 푸시된 새 컨테이너 이미지로 업데이트되고 Knative 서비스가 업데이트됩니다.

사전 요구 사항

  • 배포하려는 함수를 초기화해야 합니다.

절차

  • 함수를 배포합니다.

    $ kn func deploy [-n <namespace> -p <path> -i <image> -r <registry>]

    출력 예

    Function deployed at: http://func.example.com

    • namespace를 지정하지 않으면 함수가 현재 네임스페이스에 배포됩니다.
    • 이 함수는 path를 지정하지 않는 한 현재 디렉터리에서 배포됩니다.
    • Knative 서비스 이름은 프로젝트 이름에서 파생되며 이 명령을 사용하여 변경할 수 없습니다.

11.2.5. OpenShift Container Registry를 사용하여 함수 빌드 및 배포

함수를 빌드하고 배포할 때 결과 컨테이너 이미지는 이미지 레지스트리에 저장됩니다. 일반적으로 이것은 Quay 같은 공용 레지스트리입니다. 그러나 클러스터 관리자가 공개한 경우 통합 OpenShift Container Registry를 대신 사용할 수 있습니다.

절차

  • OpenShift Container Registry 및 -r 매개변수에 지정된 네임스페이스를 사용하여 kn func build 명령 또는 kn func deploy 명령을 실행합니다.

    빌드 명령 예

    $ kn func build -r $(oc get route -n openshift-image-registry)/my-namespace

    배포 명령 예

    $ kn func deploy -r $(oc get route -n openshift-image-registry)/my-namespace

    테스트 이벤트를 내보내기 함수가 성공적으로 배포되었는지 확인할 수 있습니다.

11.2.6. 추가 리소스

11.2.7. 배포된 함수에 테스트 이벤트 내보내기

kn func emit CLI 명령을 사용하여 로컬로 배포되거나 OpenShift Container Platform 클러스터에 배포된 함수에 CloudEvent를 내보낼 수 있습니다. 이 명령은 함수가 작동하고 이벤트를 올바르게 수신할 수 있는지 테스트하는 데 사용할 수 있습니다.

명령 예

$ kn func emit

kn func emit 명령은 기본적으로 로컬 디렉터리에서 실행되며, 이 디렉터리는 함수 프로젝트라고 가정합니다.

11.2.8. 다음 단계

11.3. Node.js 함수 개발

중요

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

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

Node.js 함수 프로젝트를 생성한 후에는 제공된 템플릿 파일을 수정하여 비즈니스 로직을 기능에 추가할 수 있습니다.

11.3.1. 사전 요구 사항

11.3.2. Node.js 함수 템플릿 구조

kn CLI를 사용하여 Node.js 함수를 생성할 때 프로젝트 디렉터리는 추가 func.yaml 구성 파일을 제외하고 일반적인 Node.js 프로젝트처럼 보입니다.

httpevent 트리거 함수 모두 동일한 템플릿 구조를 갖습니다.

템플릿 구조

.
├── func.yaml 1
├── index.js 2
├── package.json 3
├── README.md
└── test 4
    ├── integration.js
    └── unit.js

1
func.yaml 구성 파일은 이미지 이름과 레지스트리를 결정하는 데 사용됩니다.
2
프로젝트에는 단일 함수를 내보내는 index.js 파일이 포함되어야 합니다.
3
템플릿 package.json 파일에 제공된 종속성으로 제한되지 않습니다. 다른 Node.js 프로젝트에서와 마찬가지로 추가 종속 항목을 추가할 수 있습니다.

npm 종속성 추가 예

npm install --save opossum

프로젝트가 배포용으로 빌드되면 이러한 종속 항목은 생성된 런타임 컨테이너 이미지에 포함됩니다.

4
통합 및 테스트 스크립트는 함수 템플릿의 일부로 제공됩니다.

11.3.3. Node.js 함수 호출 정보

kn CLI를 사용하여 함수 프로젝트를 생성할 때 CloudEvents에 응답하는 프로젝트 또는 간단한 HTTP 요청에 응답하는 프로젝트를 생성할 수 있습니다. Knative의 CloudEvents는 HTTP를 통해 POST 요청으로 전송되므로 함수 유형 모두 수신되는 HTTP 이벤트를 수신하고 응답합니다.

Node.js 함수는 간단한 HTTP 요청을 사용하여 호출할 수 있습니다. 들어오는 요청이 수신되면 context 오브젝트를 첫 번째 매개 변수로 사용하여 함수가 호출됩니다.

11.3.3.1. Node.js 컨텍스트 오브젝트

함수는 context 오브젝트를 첫 번째 매개 변수로 제공하여 호출됩니다.

컨텍스트 오브젝트의 예

function handle(context, data)

이 오브젝트는 HTTP 요청 메서드, 요청으로 전송된 쿼리 문자열 또는 헤더, HTTP 버전 및 요청 본문을 포함하여 들어오는 HTTP 요청 정보에 대한 액세스를 제공합니다. CloudEvent가 포함된 들어오는 요청은 context.cloudevent를 사용하여 액세스할 수 있도록 CloudEvent의 들어오는 인스턴스를 컨텍스트 오브젝트에 연결합니다.

11.3.3.1.1. 컨텍스트 오브젝트 메서드

context 오브젝트에는 데이터 값을 수락하고 CloudEvent를 반환하는 단일 메서드 cloudEventResponse()가 있습니다.

Knative 시스템에서 서비스로 배포된 함수가 CloudEvent를 보내는 이벤트 브로커에 의해 호출되는 경우 브로커는 응답을 확인합니다. 응답이 CloudEvent인 경우 브로커가 이 이벤트를 처리합니다.

컨텍스트 오브젝트 메서드 예

// Expects to receive a CloudEvent with customer data
function handle(context, customer) {
  // process the customer
  const processed = handle(customer);
  return context.cloudEventResponse(customer)
    .source('/handle')
    .type('fn.process.customer')
    .response();
}

11.3.3.1.2. CloudEvent 데이터

들어오는 요청이 CloudEvent인 경우 CloudEvent와 관련된 모든 데이터가 이벤트에서 추출되며 두 번째 매개변수로 제공됩니다. 예를 들어 데이터 속성에 다음과 유사한 JSON 문자열이 포함된 CloudEvent가 수신되는 경우 다음과 같이 됩니다.

{
  "customerId": "0123456",
  "productId": "6543210"
}

호출될 때 context 오브젝트 다음에 함수에 대한 두 번째 매개 변수는 customerIdproductId 속성이 있는 JavaScript 오브젝트가 됩니다.

서명 예

function handle(context, data)

이 예제의 data 매개변수는 customerIdproductId 속성을 포함하는 JavaScript 오브젝트입니다.

11.3.4. Node.js 함수 반환 값

함수는 유효한 JavaScript 유형을 반환하거나 반환 값이 없을 수 있습니다. 함수에 반환 값이 지정되지 않고 실패가 표시되지 않으면 호출자는 204 No Content 응답을 받습니다.

또한 함수는 이벤트를 Knative Eventing 시스템으로 푸시하기 위해 CloudEvent 또는 Message 오브젝트를 반환할 수 있습니다. 이 경우 개발자는 CloudEvent 메시징 사양을 이해하고 구현할 필요가 없습니다. 반환된 값의 헤더 및 기타 관련 정보는 추출된 응답으로 전송됩니다.

function handle(context, customer) {
  // process customer and return a new CloudEvent
  return new CloudEvent({
    source: 'customer.processor',
    type: 'customer.processed'
  })
}

11.3.4.1. 헤더 반환

return 오브젝트에 headers 속성을 추가하여 응답 헤더를 설정할 수 있습니다. 이러한 헤더는 추출된 호출에 대한 응답으로 전송됩니다.

응답 헤더의 예

function handle(context, customer) {
  // process customer and return custom headers
  // the response will be '204 No content'
  return { headers: { customerid: customer.id } };
}

11.3.4.2. 상태 코드 반환

statusCode 속성을 return 오브젝트에 추가하여 호출자에게 반환된 상태 코드를 설정할 수 있습니다.

상태 코드 예

function handle(context, customer) {
  // process customer
  if (customer.restricted) {
    return { statusCode: 451 }
  }
}

상태 코드는 함수에서 생성되어 발생하는 오류에 대해 설정할 수 있습니다.

오류 상태 코드의 예

function handle(context, customer) {
  // process customer
  if (customer.restricted) {
    const err = new Error(‘Unavailable for legal reasons’);
    err.statusCode = 451;
    throw err;
  }
}

11.3.5. Node.js 함수 테스트

Node.js 함수는 컴퓨터에서 로컬로 테스트할 수 있습니다. kn func create를 사용하여 함수를 만들 때 생성되는 기본 프로젝트에는 몇 가지 간단한 단위 및 통합 테스트가 포함된 테스트 폴더가 있습니다.

절차

  • 테스트를 실행합니다.

    $ npm test

11.3.6. 다음 단계

11.4. TypeScript 함수 개발

중요

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

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

TypeScript 함수 프로젝트를 생성한 후에는 제공된 템플릿 파일을 수정하여 비즈니스 로직을 기능에 추가할 수 있습니다.

11.4.1. 사전 요구 사항

11.4.2. TypeScript 함수 템플릿 구조

kn CLI를 사용하여 TypeScript 함수를 생성할 때 프로젝트 디렉터리는 추가 func.yaml 구성 파일을 제외하고 일반적인 TypeScript 프로젝트처럼 표시됩니다.

httpevent 트리거 함수 모두 동일한 템플릿 구조를 갖습니다.

템플릿 구조

.
├── func.yaml 1
├── package.json 2
├── package-lock.json
├── README.md
├── src
│   └── index.ts 3
├── test 4
│   ├── integration.ts
│   └── unit.ts
└── tsconfig.json

1
func.yaml 구성 파일은 이미지 이름과 레지스트리를 결정하는 데 사용됩니다.
2
템플릿 package.json 파일에 제공된 종속성으로 제한되지 않습니다. 다른 TypeScript 프로젝트에서와 마찬가지로 종속 항목을 추가할 수 있습니다.

npm 종속성 추가 예

npm install --save opossum

프로젝트가 배포용으로 빌드되면 이러한 종속 항목은 생성된 런타임 컨테이너 이미지에 포함됩니다.

3
프로젝트에는 handle라는 함수를 내보내는 src/index.js 파일이 포함되어야 합니다.
4
통합 및 테스트 스크립트는 함수 템플릿의 일부로 제공됩니다.

11.4.3. TypeScript 함수 호출 정보

kn CLI를 사용하여 함수 프로젝트를 생성할 때 CloudEvents에 응답하는 프로젝트 또는 간단한 HTTP 요청에 응답하는 프로젝트를 생성할 수 있습니다. Knative의 CloudEvents는 HTTP를 통해 POST 요청으로 전송되므로 함수 유형 모두 수신되는 HTTP 이벤트를 수신하고 응답합니다.

간단한 HTTP 요청을 사용하여 TypeScript 함수를 호출할 수 있습니다. 들어오는 요청이 수신되면 context 오브젝트를 첫 번째 매개 변수로 사용하여 함수가 호출됩니다.

11.4.3.1. TypeScript 컨텍스트 오브젝트

함수는 context 오브젝트를 첫 번째 매개 변수로 사용하여 호출됩니다.

컨텍스트 오브젝트의 예

function handle(context:Context): string

이 오브젝트는 HTTP 요청 메서드, 요청으로 전송된 쿼리 문자열 또는 헤더, HTTP 버전 및 요청 본문을 포함하여 들어오는 HTTP 요청 정보에 대한 액세스를 제공합니다. CloudEvent가 포함된 들어오는 요청은 context.cloudevent를 사용하여 액세스할 수 있도록 CloudEvent의 들어오는 인스턴스를 컨텍스트 오브젝트에 연결합니다.

11.4.3.1.1. 컨텍스트 오브젝트 메서드

context 오브젝트에는 데이터 값을 수락하고 CloudEvent를 반환하는 단일 메서드 cloudEventResponse()가 있습니다.

Knative 시스템에서 서비스로 배포된 함수가 CloudEvent를 보내는 이벤트 브로커에 의해 호출되는 경우 브로커는 응답을 확인합니다. 응답이 CloudEvent인 경우 브로커가 이 이벤트를 처리합니다.

컨텍스트 오브젝트 메서드 예

// Expects to receive a CloudEvent with customer data
export function handle(context: Context, cloudevent?: CloudEvent): CloudEvent {
  // process the customer
  const customer = cloudevent.data;
  const processed = processCustomer(customer);
  return context.cloudEventResponse(customer)
    .source('/customer/process')
    .type('customer.processed')
    .response();
}

11.4.3.1.2. 컨텍스트 유형

TypeScript 유형 정의 파일은 함수에 사용하기 위해 다음 유형을 내보냅니다.

내보낸 유형 정의

// Invokable is the expeted Function signature for user functions
export interface Invokable {
    (context: Context, cloudevent?: CloudEvent): any
}

// Logger can be used for structural logging to the console
export interface Logger {
  debug: (msg: any) => void,
  info:  (msg: any) => void,
  warn:  (msg: any) => void,
  error: (msg: any) => void,
  fatal: (msg: any) => void,
  trace: (msg: any) => void,
}

// Context represents the function invocation context, and provides
// access to the event itself as well as raw HTTP objects.
export interface Context {
    log: Logger;
    req: IncomingMessage;
    query?: Record<string, any>;
    body?: Record<string, any>|string;
    method: string;
    headers: IncomingHttpHeaders;
    httpVersion: string;
    httpVersionMajor: number;
    httpVersionMinor: number;
    cloudevent: CloudEvent;
    cloudEventResponse(data: string|object): CloudEventResponse;
}

// CloudEventResponse is a convenience class used to create
// CloudEvents on function returns
export interface CloudEventResponse {
    id(id: string): CloudEventResponse;
    source(source: string): CloudEventResponse;
    type(type: string): CloudEventResponse;
    version(version: string): CloudEventResponse;
    response(): CloudEvent;
}

11.4.3.1.3. CloudEvent 데이터

들어오는 요청이 CloudEvent인 경우 CloudEvent와 관련된 모든 데이터가 이벤트에서 추출되며 두 번째 매개변수로 제공됩니다. 예를 들어 데이터 속성에 다음과 유사한 JSON 문자열이 포함된 CloudEvent가 수신되는 경우 다음과 같이 됩니다.

{
  "customerId": "0123456",
  "productId": "6543210"
}

호출될 때 context 오브젝트 다음에 함수에 대한 두 번째 매개 변수는 customerIdproductId 속성이 있는 JavaScript 오브젝트가 됩니다.

서명 예

function handle(context: Context, cloudevent?: CloudEvent): CloudEvent

이 예제의 cloudevent 매개 변수는 customerIdproductId 속성이 포함된 JavaScript 오브젝트입니다.

11.4.4. TypeScript 함수 반환 값

함수는 유효한 JavaScript 유형을 반환하거나 반환 값이 없을 수 있습니다. 함수에 반환 값이 지정되지 않고 실패가 표시되지 않으면 호출자는 204 No Content 응답을 받습니다.

또한 함수는 이벤트를 Knative Eventing 시스템으로 푸시하기 위해 CloudEvent 또는 Message 오브젝트를 반환할 수 있습니다. 이 경우 개발자는 CloudEvent 메시징 사양을 이해하고 구현할 필요가 없습니다. 반환된 값의 헤더 및 기타 관련 정보는 추출된 응답으로 전송됩니다.

export const handle: Invokable = function (
  context: Context,
  cloudevent?: CloudEvent
): Message {
  // process customer and return a new CloudEvent
  const customer = cloudevent.data;
  return HTTP.binary(
    new CloudEvent({
      source: 'customer.processor',
      type: 'customer.processed'
    })
  );
};

11.4.4.1. 헤더 반환

return 오브젝트에 headers 속성을 추가하여 응답 헤더를 설정할 수 있습니다. 이러한 헤더는 추출된 호출에 대한 응답으로 전송됩니다.

응답 헤더의 예

export function handle(context: Context, cloudevent?: CloudEvent): Record<string, any> {
  // process customer and return custom headers
  const customer = cloudevent.data as Record<string, any>;
  return { headers: { 'customer-id': customer.id } };
}

11.4.4.2. 상태 코드 반환

statusCode 속성을 return 오브젝트에 추가하여 호출자에게 반환된 상태 코드를 설정할 수 있습니다.

상태 코드 예

export function handle(context: Context, cloudevent?: CloudEvent): Record<string, any> {
  // process customer
  const customer = cloudevent.data as Record<string, any>;
  if (customer.restricted) {
    return {
      statusCode: 451
    }
  }
  // business logic, then
  return {
    statusCode: 240
  }
}

상태 코드는 함수에서 생성되어 발생하는 오류에 대해 설정할 수 있습니다.

오류 상태 코드의 예

export function handle(context: Context, cloudevent?: CloudEvent): Record<string, string> {
  // process customer
  const customer = cloudevent.data as Record<string, any>;
  if (customer.restricted) {
    const err = new Error(‘Unavailable for legal reasons’);
    err.statusCode = 451;
    throw err;
  }
}

11.4.5. TypeScript 함수 테스트

TypeScript 함수는 컴퓨터에서 로컬에서 테스트할 수 있습니다. kn func create를 사용하여 함수를 만들 때 생성되는 기본 프로젝트에는 몇 가지 간단한 단위 및 통합 테스트가 포함된 테스트 폴더가 있습니다.

절차

  1. 이전에 테스트를 실행하지 않은 경우 먼저 종속성을 설치합니다.

    $ npm install
  2. 테스트를 실행합니다.

    $ npm test

11.4.6. 다음 단계

11.5. Golang 함수 개발

중요

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

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

Golang 함수 프로젝트를 생성한 후에는 제공된 템플릿 파일을 수정하여 비즈니스 로직을 함수에 추가할 수 있습니다.

11.5.1. 사전 요구 사항

11.5.2. Golang 함수 템플릿 구조

kn CLI를 사용하여 Golang 함수를 생성할 때 프로젝트 디렉터리는 추가 func.yaml 구성 파일을 제외하고 일반적인 Golang 프로젝트와 동일합니다.

Golang 함수에는 몇 가지 제한 사항이 있습니다. 유일한 요구 사항은 프로젝트를 function 모듈에 정의해야 하며, 함수 Handle()을 내보내야 한다는 것입니다.

httpevent 트리거 함수 모두 동일한 템플릿 구조를 갖습니다.

템플릿 구조

fn
├── README.md
├── func.yaml 1
├── go.mod 2
├── go.sum
├── handle.go
└── handle_test.go

1
func.yaml 구성 파일은 이미지 이름과 레지스트리를 결정하는 데 사용됩니다.
2
필요한 모든 종속성을 go.mod 파일에 추가할 수 있으며 여기에는 추가 로컬 Golang 파일이 포함될 수 있습니다. 프로젝트가 배포용으로 빌드되면 이러한 종속성이 결과로 생성된 런타임 컨테이너 이미지에 포함됩니다.

종속성 추가 예

$ go get gopkg.in/yaml.v2@v2.4.0

11.5.3. Golang 함수 호출 정보

Golang 함수는 HTTP 요청 또는 CloudEvent에 의해 트리거되는지 여부에 따라 다양한 방법을 사용하여 호출됩니다.

11.5.3.1. HTTP 요청에 의해 트리거된 함수

들어오는 HTTP 요청이 수신되면 표준 Golang Context를 첫 번째 매개변수로 사용하여 함수를 호출한 다음 두 개의 추가 매개변수를 사용합니다.

표준 Golang 기술을 사용하여 요청에 액세스하고 함수의 적절한 HTTP 응답을 설정할 수 있습니다.

HTTP 응답의 예

func Handle(ctx context.Context, res http.ResponseWriter, req *http.Request) {
  // Read body
  body, err := ioutil.ReadAll(req.Body)
  defer req.Body.Close()
  if err != nil {
	http.Error(res, err.Error(), 500)
	return
  }
  // Process body and function logic
  // ...
}

11.5.3.2. 클라우드 이벤트에서 트리거한 함수

들어오는 클라우드 이벤트가 수신되면 CloudEvents Golang SDK에서 이벤트를 호출하고 Even 유형을 매개 변수로 호출합니다.

지원되는 함수 서명 목록에 표시된 대로 Golang Context를 함수 계약의 선택적 매개변수로 사용할 수 있습니다.

지원되는 함수 서명

Handle()
Handle() error
Handle(context.Context)
Handle(context.Context) error
Handle(cloudevents.Event)
Handle(cloudevents.Event) error
Handle(context.Context, cloudevents.Event)
Handle(context.Context, cloudevents.Event) error
Handle(cloudevents.Event) *cloudevents.Event
Handle(cloudevents.Event) (*cloudevents.Event, error)
Handle(context.Context, cloudevents.Event) *cloudevents.Event
Handle(context.Context, cloudevents.Event) (*cloudevents.Event, error)

11.5.3.2.1. CloudEvent 트리거 예

데이터 속성에 JSON 문자열이 포함된 클라우드 이벤트가 수신됩니다.

{
  "customerId": "0123456",
  "productId": "6543210"
}

이 데이터에 액세스하려면 클라우드 이벤트 데이터에서 속성을 매핑하는 구조를 정의하고 들어오는 이벤트에서 데이터를 검색해야 합니다. 다음 예제에서는 Purchase 구조를 사용합니다.

type Purchase struct {
  CustomerId string `json:"customerId"`
  ProductId  string `json:"productId"`
}
func Handle(ctx context.Context, event cloudevents.Event) (err error) {

  purchase := &Purchase{}
  if err = event.DataAs(purchase); err != nil {
	fmt.Fprintf(os.Stderr, "failed to parse incoming CloudEvent %s\n", err)
	return
  }
  // ...
}

또는 Golang encoding/json 패키지를 사용하여 바이트 배열 형식의 JSON으로 클라우드 이벤트에 직접 액세스할 수 있습니다.

func Handle(ctx context.Context, event cloudevents.Event) {
  bytes, err := json.Marshal(event)
  // ...
}

11.5.4. golang 함수 반환 값

HTTP 트리거 함수는 Golang http.ResponseWriter를 사용하여 직접 응답을 설정할 수 있습니다.

HTTP 응답의 예

func Handle(ctx context.Context, res http.ResponseWriter, req *http.Request) {
  // Set response
  res.Header().Add("Content-Type", "text/plain")
  res.Header().Add("Content-Length", "3")
  res.WriteHeader(200)
  _, err := fmt.Fprintf(res, "OK\n")
  if err != nil {
	fmt.Fprintf(os.Stderr, "error or response write: %v", err)
  }
}

클라우드 이벤트에 의해 트리거한 함수는 이벤트를 Knative Eventing 시스템으로 푸시하기 위해 아무것도 반환하지 않거나 error 또는 CloudEvent를 반환할 수 있습니다. 이 경우 클라우드 이벤트의 고유 ID, 적절한 SourceType을 설정해야 합니다. 데이터는 정의된 구조 또는 map에서 채워질 수 있습니다.

CloudEvent 응답 예

func Handle(ctx context.Context, event cloudevents.Event) (resp *cloudevents.Event, err error) {
  // ...
  response := cloudevents.NewEvent()
  response.SetID("example-uuid-32943bac6fea")
  response.SetSource("purchase/getter")
  response.SetType("purchase")
  // Set the data from Purchase type
  response.SetData(cloudevents.ApplicationJSON, Purchase{
	CustomerId: custId,
	ProductId:  prodId,
  })
  // OR set the data directly from map
  response.SetData(cloudevents.ApplicationJSON, map[string]string{"customerId": custId, "productId": prodId})
  // Validate the response
  resp = &response
  if err = resp.Validate(); err != nil {
	fmt.Printf("invalid event created. %v", err)
  }
  return
}

11.5.5. Golang 함수 테스트

Golang 함수는 컴퓨터에서 로컬로 테스트할 수 있습니다. kn func create를 사용하여 함수를 만들 때 생성되는 기본 프로젝트에는 몇 가지 기본 테스트가 포함된 handle_test.go 파일이 있습니다. 이러한 테스트는 필요에 따라 확장할 수 있습니다.

절차

  • 테스트를 실행합니다.

    $ go test

11.5.6. 다음 단계

11.6. Python 함수 개발

중요

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

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

Python 함수 프로젝트를 생성한 후에는 지정된 템플릿 파일을 수정하여 비즈니스 로직을 함수에 추가할 수 있습니다.

11.6.1. 사전 요구 사항

11.6.2. Python 함수 템플릿 구조

kn CLI를 사용하여 Python 함수를 생성할 때 프로젝트 디렉터리는 일반적인 Python 프로젝트와 유사합니다.

Python 함수는 약간의 제한 사항이 있습니다. 유일한 요구 사항은 프로젝트에 main() 함수와 func.yaml 구성 파일이 포함된 func.py 파일이 포함되어 있다는 것입니다.

개발자는 템플릿 requirements.txt 파일에 제공된 종속성으로 제한되지 않습니다. 추가 종속 항목은 다른 Python 프로젝트에서 추가될 수 있습니다. 프로젝트가 배포용으로 빌드되면 이러한 종속성이 생성된 런타임 컨테이너 이미지에 포함됩니다.

httpevent 트리거 함수 모두 동일한 템플릿 구조를 갖습니다.

템플릿 구조

fn
├── func.py 1
├── func.yaml 2
├── requirements.txt 3
└── test_func.py 4

1
main() 함수를 포함합니다.
2
이미지 이름과 레지스트리를 결정하는 데 사용됩니다.
3
다른 Python 프로젝트에 있는 것처럼 requirements.txt 파일에 기타 종속 항목을 추가할 수 있습니다.
4
함수의 로컬 테스트에 사용할 수 있는 간단한 단위 테스트가 포함되어 있습니다.

11.6.3. Python 함수 호출 정보

Python 함수는 간단한 HTTP 요청으로 호출할 수 있습니다. 들어오는 요청이 수신되면 context 오브젝트를 첫 번째 매개 변수로 사용하여 함수가 호출됩니다. context 오브젝트는 두 개의 속성이 있는 Python 클래스입니다.

  • request 속성은 항상 존재하며 Flask request 오브젝트를 포함합니다.
  • 들어오는 요청이 CloudEvent 오브젝트인 경우 두 번째 속성 cloud_event가 채워집니다.

개발자는 컨텍스트 오브젝트에서 모든 CloudEvent 데이터에 액세스할 수 있습니다.

컨텍스트 오브젝트의 예

def main(context: Context):
    """
    The context parameter contains the Flask request object and any
    CloudEvent received with the request.
    """
    print(f"Method: {context.request.method}")
    print(f"Event data {context.cloud_event.data}")
    # ... business logic here

11.6.4. Python 함수 반환 값

호출 프레임워크가 이러한 값을 Flask 서버에 직접 프록시하므로 함수는 Flask에서 지원하는 모든 값을 반환할 수 있습니다.

def main(context: Context):
    body = { "message": "Howdy!" }
    headers = { "content-type": "application/json" }
    return body, 200, headers

함수는 함수 호출에서 헤더와 응답 코드를 모두 2차 및 3차 응답 값으로 설정할 수 있습니다.

11.6.4.1. CloudEvents 반환

개발자는 @event 데코레이터를 사용하여 응답을 보내기 전에 함수 반환 값을 CloudEvent로 변환해야 함을 호출자에게 알릴 수 있습니다.

@event("event_source"="/my/function", "event_type"="my.type")
def main(context):
    # business logic here
    data = do_something()
    # more data processing
    return data

이 예제에서는 "my.type" 유형과 "/my/function" 소스를 사용하여 CloudEvent를 응답 값으로 보냅니다. CloudEvent data 속성은 반환된 data 변수로 설정됩니다. event_sourceevent_type 데코레이터 속성은 선택 사항입니다.

11.6.5. Python 함수 테스트

컴퓨터에서 Python 함수를 로컬로 테스트할 수 있습니다. 기본 프로젝트에는 기능에 대한 간단한 단위 테스트를 제공하는 test_proxyc.py 파일이 포함되어 있습니다.

참고

Python 함수의 기본 테스트 프레임워크는 unittest입니다. 필요에 따라 다른 테스트 프레임워크를 사용할 수 있습니다.

사전 요구 사항

  • Python 함수 테스트를 로컬에서 실행하려면 필요한 종속 항목을 설치해야 합니다.

    $ pip install -r requirements.txt

절차

  • 종속 항목을 설치한 후 테스트를 실행합니다.

    $ python3 test_func.py

11.6.6. 다음 단계

11.7. Quarkus 함수 개발

중요

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

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

Quarkus 함수 프로젝트를 생성한 후에는 지정된 템플릿 파일을 수정하여 비즈니스 로직을 함수에 추가할 수 있습니다.

11.7.1. 사전 요구 사항

11.7.2. Quarkus 함수 템플릿 구조

kn CLI를 사용하여 Quarkus 함수를 생성할 때 프로젝트 디렉터리는 보통 Maven 프로젝트와 유사합니다.

httpevent 트리거 함수 모두 동일한 템플릿 구조를 갖습니다.

템플릿 구조

.
├── func.yaml 1
├── mvnw
├── mvnw.cmd
├── pom.xml 2
├── README.md
└── src
    ├── main
    │   ├── java
    │   │   └── functions
    │   │       ├── Function.java 3
    │   │       ├── Input.java
    │   │       └── Output.java
    │   └── resources
    │       └── application.properties
    └── test
        └── java
            └── functions 4
                ├── FunctionTest.java
                └── NativeFunctionIT.java

1
이미지 이름과 레지스트리를 결정하는 데 사용됩니다.
2
POM(Project Object Model) 파일에는 종속성에 대한 정보와 같은 프로젝트 구성이 포함되어 있습니다. 이 파일을 수정하여 다른 종속 항목을 추가할 수 있습니다.

추가 종속 항목 예

...
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.11</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.assertj</groupId>
      <artifactId>assertj-core</artifactId>
      <version>3.8.0</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
...

종속성은 첫 번째 컴파일 중에 다운로드됩니다.

3
함수 프로젝트에는 @Funq 주석이 추가된 Java 메서드가 포함되어야 합니다. 이 메서드를 Function.java 클래스에 배치할 수 있습니다.
4
함수의 로컬 테스트에 사용할 수 있는 간단한 테스트 케이스가 포함되어 있습니다.

11.7.3. Quarkus 함수 호출 정보

클라우드 이벤트에 응답하는 Quarkus 프로젝트 또는 간단한 HTTP 요청에 응답하는 Quarkus 프로젝트를 생성할 수 있습니다. Knative의 클라우드 이벤트는 HTTP를 통해 POST 요청으로 전송되므로 두 기능 유형 모두 들어오는 HTTP 요청을 수신하고 응답할 수 있습니다.

들어오는 요청이 수신되면 Quarkus 함수가 허용된 유형의 인스턴스와 함께 호출됩니다.

표 11.1. 함수 호출 옵션

호출 메소드인스턴스에 포함된 데이터 유형데이터 예

HTTP POST 요청

요청 본문에 있는 JSON 오브젝트

{ "customerId": "0123456", "productId": "6543210" }

HTTP GET 요청

쿼리 문자열의 데이터

?customerId=0123456&productId=6543210

CloudEvent

data 속성의 JSON 개체

{ "customerId": "0123456", "productId": "6543210" }

다음 예제에서는 이전 표에 나열된 customerIdproductId 구매 데이터를 수신하고 처리하는 함수를 보여줍니다.

Quarkus 함수의 예

public class Functions {
    @Funq
    public void processPurchase(Purchase purchase) {
        // process the purchase
    }
}

구매 데이터를 포함하는 Purchase JavaBean 클래스는 다음과 같습니다.

클래스 예

public class Purchase {
    private long customerId;
    private long productId;
    // getters and setters
}

11.7.3.1. 호출 예

다음 예제 코드는 withBeans, withCloudEvent, withBinary라는 세 가지 함수를 정의합니다.

예제

import io.quarkus.funqy.Funq;
import io.quarkus.funqy.knative.events.CloudEvent;

public class Input {
    private String message;

    // getters and setters
}

public class Output {
    private String message;

    // getters and setters
}

public class Functions {
    @Funq
    public Output withBeans(Input in) {
        // function body
    }

    @Funq
    public CloudEvent<Output> withCloudEvent(CloudEvent<Input> in) {
        // function body
    }

    @Funq
    public void withBinary(byte[] in) {
        // function body
    }
}

Functions 클래스의 withBeans 함수는 다음을 통해 호출할 수 있습니다.

  • JSON 본문이 있는 HTTP POST 요청:

    $ curl "http://localhost:8080/withBeans" -X POST \
        -H "Content-Type: application/json" \
        -d '{"message": "Hello there."}'
  • 쿼리 매개변수가 있는 HTTP GET 요청:

    $ curl "http://localhost:8080/withBeans?message=Hello%20there." -X GET
  • 바이너리 인코딩의 CloudEvent 오브젝트:

    $ curl "http://localhost:8080/" -X POST \
      -H "Content-Type: application/json" \
      -H "Ce-SpecVersion: 1.0" \
      -H "Ce-Type: withBeans" \
      -H "Ce-Source: cURL" \
      -H "Ce-Id: 42" \
      -d '{"message": "Hello there."}'
  • 구조화된 인코딩의 CloudEvent 오브젝트:

    $ curl http://localhost:8080/ \
        -H "Content-Type: application/cloudevents+json" \
        -d '{ "data": {"message":"Hello there."},
              "datacontenttype": "application/json",
              "id": "42",
              "source": "curl",
              "type": "withBeans",
              "specversion": "1.0"}'

Functions 클래스의 withCloudEvent 함수는 withBeans 함수와 유사하게 CloudEvent 오브젝트를 사용하여 호출할 수 있습니다. 그러나 withBeans와 달리withCloudEvent는 일반 HTTP 요청으로 호출할 수 없습니다.

Functions 클래스의 withBinary 함수는 다음을 통해 호출할 수 있습니다.

  • 바이너리 인코딩의 CloudEvent 오브젝트:

    $ curl "http://localhost:8080/" -X POST \
      -H "Content-Type: application/octet-stream" \
      -H "Ce-SpecVersion: 1.0"\
      -H "Ce-Type: withBinary" \
      -H "Ce-Source: cURL" \
      -H "Ce-Id: 42" \
      --data-binary '@img.jpg'
  • 구조화된 인코딩의 CloudEvent 오브젝트:

    $ curl http://localhost:8080/ \
      -H "Content-Type: application/cloudevents+json" \
      -d "{ \"data_base64\": \"$(base64 --wrap=0 img.jpg)\",
            \"datacontenttype\": \"application/octet-stream\",
            \"id\": \"42\",
            \"source\": \"curl\",
            \"type\": \"withBinary\",
            \"specversion\": \"1.0\"}"

11.7.4. CloudEvent 속성

type 또는 subject와 같은 CloudEvent의 속성을 읽거나 작성해야 하는 경우 CloudEvent<T> 일반 인터페이스와 CloudEventBuilder 빌더를 사용할 수 있습니다. <T> 유형 매개변수는 허용된 유형 중 하나여야 합니다.

다음 예에서 CloudEventBuilder는 구매 처리 성공 또는 실패를 반환하는 데 사용됩니다.

public class Functions {

    private boolean _processPurchase(Purchase purchase) {
        // do stuff
    }

    public CloudEvent<Void> processPurchase(CloudEvent<Purchase> purchaseEvent) {
        System.out.println("subject is: " + purchaseEvent.subject());

        if (!_processPurchase(purchaseEvent.data())) {
            return CloudEventBuilder.create()
                    .type("purchase.error")
                    .build();
        }
        return CloudEventBuilder.create()
                .type("purchase.success")
                .build();
    }
}

11.7.5. Quarkus 함수 반환 값

함수는 다음과 같은 인스턴스를 반환할 수 있습니다.

  • 허용된 유형 목록에서의 모든 유형입니다.
  • <T> 유형 매개변수는 허용된 유형의 모든 유형일 수 있는 Uni<T> 유형입니다.

Uni<T> 유형은 반환된 오브젝트가 수신된 오브젝트와 동일한 형식으로 직렬화되기 때문에 함수가 비동기 API를 호출할 때 유용합니다. 예를 들면 다음과 같습니다.

  • 함수가 HTTP 요청을 수신하면 반환된 오브젝트가 HTTP 응답 본문에 전송됩니다.
  • 함수가 바이너리 인코딩으로 CloudEvent 오브젝트를 수신하는 경우 반환된 오브젝트는 바이너리 인코딩 CloudEvent 오브젝트의 데이터 속성으로 전송됩니다.

다음 예제에서는 구매 목록을 가져오는 함수를 보여줍니다.

명령 예

public class Functions {
    @Funq
    public List<Purchase> getPurchasesByName(String name) {
      // logic to retrieve purchases
    }
}

  • HTTP 요청을 통해 이 함수를 호출하면 응답 본문에서 구매한 목록을 포함하는 HTTP 응답이 생성됩니다.
  • 들어오는 CloudEvent 오브젝트를 통해 이 함수를 호출하면 data 속성에서 구매 목록이 포함된 CloudEvent 응답이 생성됩니다.

11.7.5.1. 허용된 유형

함수의 입력 및 출력 유형은 다음 중 하나일 수 있습니다.

  • void
  • 문자열
  • byte[]
  • 기본 유형 및 래퍼(예: intInteger).
  • JavaBean: 속성이 여기에 나열된 유형인 경우입니다.
  • 이 목록에 있는 유형의 맵, 목록 또는 배열입니다.
  • <T> 유형 매개 변수가 이 목록에 있는 유형인 특수 CloudEvents<T> 유형입니다.

예제

public class Functions {
    public List<Integer> getIds();
    public Purchase[] getPurchasesByName(String name);
    public String getNameById(int id);
    public Map<String,Integer> getNameIdMapping();
    public void processImage(byte[] img);
}

11.7.6. Quarkus 함수 테스트

프로젝트 템플릿에 포함된 Maven 테스트를 실행하여 컴퓨터에서 Quarkus 함수를 로컬에서 테스트할 수 있습니다.

절차

  • Maven 테스트를 실행합니다.

    $ ./mvnw test

11.7.7. 다음 단계

11.8. Knative Eventing에서 함수 사용

중요

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

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

함수는 OpenShift Container Platform 클러스터에 Knative 서비스로 배포되며 Knative Eventing 구성 요소에 싱크로 연결할 수 있습니다.

11.8.1. 개발자 화면을 사용하여 이벤트 소스를 싱크에 연결

OpenShift Container Platform에서 싱크에 연결할 수 있는 다양한 이벤트 소스 유형을 생성할 수 있습니다.

사전 요구 사항

개발자 화면을 사용하여 이벤트 소스를 싱크에 연결하려면 다음 조건을 충족해야 합니다.

  • OpenShift Serverless Operator, Knative Serving, Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • 싱크를 생성했습니다.
  • 웹 콘솔에 로그인한 후 개발자 화면으로 갑니다.
  • 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.

절차

  1. +추가이벤트 소스로 이동한 다음 생성할 이벤트 소스 유형을 선택하여 모든 유형의 이벤트 소스를 생성합니다.
  2. 이벤트 소스 양식 보기의 싱크 섹션에서 리소스를 선택합니다. 그런 다음 드롭다운을 사용하여 싱크를 선택합니다.
  3. 생성을 클릭합니다.

검증

토폴로지 페이지를 확인하여 이벤트 소스가 생성되었고 싱크에 연결되어 있는지 확인할 수 있습니다.

  1. 개발자 화면에서 토폴로지로 이동합니다.
  2. 이벤트 소스를 표시하고 연결된 싱크를 클릭하여 사이드 패널에서 싱크 세부 정보를 확인합니다.

11.9. func.yaml의 함수 프로젝트 구성

func.yaml 파일에는 함수 프로젝트의 구성이 포함되어 있습니다.

일반적으로 이러한 값은 kn func 명령을 실행할 때 사용됩니다. 예를 들어 kn func build 명령을 실행하면 builder 필드의 값이 사용됩니다.

참고

대부분의 경우 명령줄 플래그 또는 환경 변수로 이러한 값을 재정의할 수 있습니다.

11.9.1. func.yaml의 구성 가능한 필드

func.yaml의 대부분의 필드는 함수를 생성, 빌드 및 배포할 때 자동으로 생성됩니다. 그러나 함수 이름 또는 이미지 이름과 같은 사항을 변경하기 위해 수동으로 변경하는 필드도 있습니다.

11.9.1.1. builder

builder 필드는 함수를 빌드할 때 사용할 Buildpack 빌더 이미지를 지정합니다. 대부분의 경우 이 값은 변경할 수 없습니다. 이 값을 변경하려면 builders 필드에 나열된 값을 사용합니다.

11.9.1.2. 빌더

일부 함수 런타임은 여러 방식으로 빌드할 수 있습니다. 예를 들어 Quarkus 함수는 JVM 또는 기본 바이너리로 빌드할 수 있습니다. builders 필드에는 지정된 런타임에 사용할 수 있는 모든 빌더가 포함되어 있습니다.

11.9.1.3. buildEnvs

buildEnvs 필드를 사용하면 기능을 빌드하는 환경에서 사용할 수 있는 환경 변수를 설정할 수 있습니다. envs 를 사용하여 설정된 변수와 달리 buildEnv 를 사용하여 설정한 변수는 기능 런타임 중에 사용할 수 없습니다.

값에서 직접 buildEnv 변수를 설정할 수 있습니다. 다음 예에서 EXAMPLE1 이라는 buildEnv 변수에는 하나의 값이 직접 할당됩니다.

buildEnvs:
- name: EXAMPLE1
  value: one

로컬 환경 변수에서 buildEnv 변수를 설정할 수도 있습니다. 다음 예에서 EXAMPLE2 라는 buildEnv 변수에는 LOCAL_ENV_VAR 로컬 환경 변수 값이 할당됩니다.

buildEnvs:
- name: EXAMPLE1
  value: '{{ env:LOCAL_ENV_VAR }}'

11.9.1.4. envs

envs 필드를 사용하면 런타임 시 사용할 수 있는 환경 변수를 설정할 수 있습니다. 환경 변수를 여러 가지 방법으로 설정할 수 있습니다.

  1. 값을 직접 설정할 수 있습니다.
  2. 로컬 환경 변수에 할당 된 값에서 설정합니다. 자세한 내용은 func.yaml 필드에서 로컬 환경 변수 참조 섹션을 참조하십시오.
  3. 시크릿 또는 구성 맵에 저장된 키-값 쌍에서 설정합니다.
  4. 생성된 환경 변수의 이름으로 사용되는 키를 사용하여 시크릿 또는 구성 맵에 저장된 모든 키-값 쌍을 가져올 수도 있습니다.

이 예제에서는 환경 변수를 설정하는 다양한 방법을 보여줍니다.

name: test
namespace: ""
runtime: go
...
envs:
- name: EXAMPLE1 1
  value: value
- name: EXAMPLE2 2
  value: '{{ env:LOCAL_ENV_VALUE }}'
- name: EXAMPLE3 3
  value: '{{ secret:mysecret:key }}'
- name: EXAMPLE4 4
  value: '{{ configMap:myconfigmap:key }}'
- value: '{{ secret:mysecret2 }}' 5
- value: '{{ configMap:myconfigmap2 }}' 6
1
값에서 직접 설정된 환경 변수.
2
로컬 환경 변수에 할당된 값에서 설정된 환경 변수.
3
시크릿에 저장된 키-값 쌍에서 할당된 환경 변수.
4
구성 맵에 저장된 키-값 쌍에서 할당된 환경 변수.
5
시크릿의 키-값 쌍에서 가져온 환경 변수 세트.
6
구성 맵의 키-값 쌍에서 가져온 환경 변수 세트.

11.9.1.5. volumes

volumes 필드를 사용하면 다음 예와 같이 지정된 경로에서 기능에 액세스할 수 있는 볼륨으로 시크릿 및 구성 맵을 마운트할 수 있습니다.

name: test
namespace: ""
runtime: go
...
volumes:
- secret: mysecret 1
  path: /workspace/secret
- configMap: myconfigmap 2
  path: /workspace/configmap
1
mysecret 시크릿은 /workspace/secret에 있는 볼륨으로 마운트됩니다.
2
myconfigmap 구성 맵은 /workspace/configmap에 있는 볼륨으로 마운트됩니다.

11.9.1.6. options

options 필드를 사용하면 자동 스케일링과 같이 배포된 함수에 대한 Knative Service 속성을 수정할 수 있습니다. 이러한 옵션이 설정되어 있지 않으면 기본 옵션이 사용됩니다.

다음 옵션을 사용할 수 있습니다.

  • scale

    • : 최소 복제본 수입니다. 음수가 아닌 정수여야 합니다. 기본값은 0입니다.
    • max: 최대 복제본 수입니다. 음수가 아닌 정수여야 합니다. 기본값은 0이며 이는 제한이 없음을 의미합니다.
    • 메트릭: Autoscaler에서 조사하는 지표 유형을 정의합니다. 기본값인 concurrency 또는 rps로 설정할 수 있습니다.
    • 대상: 동시에 들어오는 요청 수에 따라 확장할 시기를 권장합니다. target 옵션은 0.01보다 큰 부동 소수점 값을 지정할 수 있습니다. options.resources.limits.concurrency가 설정되지 않는 한 기본값은 100입니다. 이 경우 target은 기본값으로 설정됩니다.
    • 사용: 확장하기 전에 허용된 동시 요청 사용률의 백분율입니다. 1에서 100까지의 부동 소수점 값을 지정할 수 있습니다. 기본값은 70입니다.
  • resources

    • requests

      • cpu: 배포된 기능이 있는 컨테이너에 대한 CPU 리소스 요청입니다.
      • 메모리: 배포된 기능이 있는 컨테이너에 대한 메모리 리소스 요청.
    • limits

      • cpu: 배포된 기능이 있는 컨테이너의 CPU 리소스 제한입니다.
      • 메모리: 배포된 기능이 있는 컨테이너의 메모리 리소스 제한.
      • 동시성: 단일 복제본에서 처리할 동시 요청의 하드 제한. 0보다 크거나 같은 정수 값이 될 수 있습니다. 기본값은 0이며 이는 제한이 없음을 의미합니다.

다음은 scale 옵션 구성의 예입니다.

name: test
namespace: ""
runtime: go
...
options:
  scale:
    min: 0
    max: 10
    metric: concurrency
    target: 75
    utilization: 75
  resources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: 1000m
      memory: 256Mi
      concurrency: 100

11.9.1.7. image

image 필드는 해당 함수의 이미지 이름을 빌드한 후 설정합니다. 이 필드는 필요에 따라 수정할 수 있습니다. 이 경우 다음에 kn func build 또는 kn func deploy를 실행하면 함수 이미지가 새 이름으로 생성됩니다.

11.9.1.8. imageDigest

imageDigest 필드에는 함수가 배포될 때 이미지 매니페스트의 SHA256 해시가 포함됩니다. 이 값은 변경하지 마십시오.

11.9.1.9. labels

labels 필드를 사용하면 배포된 기능에 라벨을 설정할 수 있습니다.

값에서 직접 라벨을 설정할 수 있습니다. 다음 예제에서는 역할 키가 있는 라벨에 backend 값이 직접 할당됩니다.

labels:
- key: role
  value: backend

로컬 환경 변수에서 레이블을 설정할 수도 있습니다. 다음 예제에서는 작성자 키가 있는 라벨에 USER 로컬 환경 변수의 값이 할당됩니다.

labels:
- key: author
  value: '{{ env:USER }}'

11.9.1.10. name

name 필드는 함수의 이름을 정의합니다. 이 값은 배포 시 Knative 서비스의 이름으로 사용됩니다. 이 필드를 변경하여 후속 배포의 함수 이름을 변경할 수 있습니다.

11.9.1.11. namespace

namespace 필드는 함수가 배포되는 네임스페이스를 지정합니다.

11.9.1.12. runtime

runtime 필드는 기능에 대한 언어 런타임(예: python )을 지정합니다.

11.9.2. func.yaml 필드의 로컬 환경 변수 참조

func.yamlenvs 필드에 로컬 환경에서 사용 가능한 환경 변수에 대한 참조를 배치할 수 있습니다. 이는 함수 구성의 API 키와 같은 중요한 정보를 저장하는 것을 방지하는 데 유용합니다.

절차

  • 로컬 환경 변수를 참조하려면 다음 구문을 사용합니다.

    {{ env:ENV_VAR }}

    ENV_VAR을 사용하려는 로컬 환경의 변수 이름으로 바꿉니다.

    예를 들어 로컬 환경에서 사용할 수 있는 API_KEY 변수가 있을 수 있습니다. MY_API_KEY 변수에 해당 값을 할당하면 함수 내에서 직접 사용할 수 있습니다.

    name: test
    namespace: ""
    runtime: go
    ...
    envs:
    - name: MY_API_KEY
      value: '{{ env:API_KEY }}'

추가 리소스

11.10. Serverless 함수에서 시크릿 및 구성 맵에 액세스

클러스터에 배포된 후 기능은 시크릿 및 구성 맵에 저장된 데이터에 액세스할 수 있습니다. 이 데이터는 볼륨으로 마운트하거나 환경 변수에 할당할 수 있습니다. Knative CLI kn func 명령을 사용하거나 함수 구성 파일을 편집하여 수동으로 이 액세스를 대화식으로 구성할 수 있습니다.

중요

시크릿 및 구성 맵에 액세스하려면 함수를 클러스터에 배포해야 합니다. 이 기능은 로컬에서 실행되는 함수에 사용할 수 없습니다.

시크릿 또는 구성 맵 값에 액세스할 수 없는 경우 액세스할 수 없는 값을 지정하는 오류 메시지와 함께 배포가 실패합니다.

11.10.1. 시크릿 및 구성 맵에 대한 함수 액세스의 상호 작용 변경

kn func config 대화형 유틸리티를 사용하여 함수에서 액세스하는 시크릿 및 구성 맵을 관리할 수 있습니다.

절차

  1. 함수 프로젝트에서 다음 명령을 실행합니다.

    $ kn func config

    또는 --path 또는 -p 옵션을 사용하여 함수 프로젝트 디렉터리를 지정할 수 있습니다.

  2. 대화형 인터페이스를 사용하여 필요한 작업을 수행합니다. 예를 들어 유틸리티를 사용하여 구성된 볼륨을 나열하면 다음과 유사한 출력이 생성됩니다.

    $ kn func config
    ? What do you want to configure? Volumes
    ? What operation do you want to perform? List
    Configured Volumes mounts:
    - Secret "mysecret" mounted at path: "/workspace/secret"
    - Secret "mysecret2" mounted at path: "/workspace/secret2"

    이 스키마는 대화형 유틸리티에서 사용할 수 있는 모든 작업과 해당 유틸리티로 이동하는 방법을 보여줍니다.

    kn func config
       ├─> Environment variables
       │               ├─> Add
       │               │    ├─> ConfigMap: Add all key-value pairs from a config map
       │               │    ├─> ConfigMap: Add value from a key in a config map
       │               │    ├─> Secret: Add all key-value pairs from a secret
       │               │    └─> Secret: Add value from a key in a secret
       │               ├─> List: List all configured environment variables
       │               └─> Remove: Remove a configured environment variable
       └─> Volumes
               ├─> Add
               │    ├─> ConfigMap: Mount a config map as a volume
               │    └─> Secret: Mount a secret as a volume
               ├─> List: List all configured volumes
               └─> Remove: Remove a configured volume
  3. 선택 사항: 함수를 배포하여 변경 사항을 적용합니다.

    $ kn func deploy -p test

11.10.2. 특수 명령을 사용하여 시크릿 및 구성 맵에 대한 함수 액세스 수정

kn func config 유틸리티를 실행할 때마다 전체 대화 상자를 탐색하여 이전 섹션에서와 같이 필요한 작업을 선택해야 합니다. 단계를 저장하려면 kn func config 명령 보다 구체적인 양식을 실행하여 특정 작업을 직접 수행합니다.

  • 구성된 환경 변수를 나열하려면 다음을 수행합니다.

    $ kn func config envs [-p <function-project-path>]
  • 함수 구성에 환경 변수를 추가하려면 다음을 수행합니다.

    $ kn func config envs add [-p <function-project-path>]
  • 함수 구성에서 환경 변수를 제거하려면 다음을 수행합니다.

    $ kn func config envs remove [-p <function-project-path>]
  • 구성된 볼륨을 나열하려면 다음을 수행합니다.

    $ kn func config volumes [-p <function-project-path>]
  • 함수 구성에 볼륨을 추가하려면 다음을 수행합니다.

    $ kn func config volumes add [-p <function-project-path>]
  • 함수 구성에서 볼륨을 제거하려면 다음을 수행합니다.

    $ kn func config volumes remove [-p <function-project-path>]

11.10.3. 시크릿 및 구성 맵에 수동으로 함수 액세스 추가

시크릿 및 구성 맵에 액세스하는 구성을 함수에 수동으로 추가할 수 있습니다.

11.10.3.1. 시크릿을 볼륨으로 마운트

  1. 함수에 사용할 func.yaml 파일을 엽니다.
  2. 볼륨으로 마운트하려는 각 시크릿에 대해 volumes 섹션에 다음 YAML을 추가합니다.

    name: test
    namespace: ""
    runtime: go
    ...
    volumes:
    - secret: mysecret
      path: /workspace/secret
    • mysecret을 대상 시크릿의 이름으로 대체합니다.
    • 시크릿을 마운트하려는 경로로 /workspace/secret을 대체합니다.
  3. 설정을 저장합니다.

11.10.3.2. 구성 맵을 볼륨으로 마운트

  1. 함수에 사용할 func.yaml 파일을 엽니다.
  2. 볼륨으로 마운트하려는 각 구성 맵에 대해 volumes 섹션에 다음 YAML을 추가합니다.

    name: test
    namespace: ""
    runtime: go
    ...
    volumes:
    - configMap: myconfigmap
      path: /workspace/configmap
    • myconfigmap을 대상 구성 맵의 이름으로 대체합니다.
    • /workspace/configmap을 구성 맵을 마운트하려는 경로로 바꿉니다.
  3. 설정을 저장합니다.

11.10.3.3. 시크릿에 정의된 키 값에서 환경 변수 설정

  1. 함수에 사용할 func.yaml 파일을 엽니다.
  2. 환경 변수에 할당할 시크릿 키-값 쌍의 각 값에 대해 envs 섹션에 다음 YAML을 추가합니다.

    name: test
    namespace: ""
    runtime: go
    ...
    envs:
    - name: EXAMPLE
      value: '{{ secret:mysecret:key }}'
    • EXAMPLE을 환경 변수 이름으로 대체합니다.
    • mysecret을 대상 시크릿의 이름으로 대체합니다.
    • key를 대상 값에 매핑된 키로 대체합니다.
  3. 설정을 저장합니다.

11.10.3.4. 구성 맵에 정의된 키 값에서 환경 변수 설정

  1. 함수에 사용할 func.yaml 파일을 엽니다.
  2. 환경 변수에 할당할 구성 맵 키-값 쌍의 각 값에 대해 envs 섹션에 다음 YAML을 추가합니다.

    name: test
    namespace: ""
    runtime: go
    ...
    envs:
    - name: EXAMPLE
      value: '{{ configMap:myconfigmap:key }}'
    • EXAMPLE을 환경 변수 이름으로 대체합니다.
    • myconfigmap을 대상 구성 맵의 이름으로 대체합니다.
    • key를 대상 값에 매핑된 키로 대체합니다.
  3. 설정을 저장합니다.

11.10.3.5. 시크릿에 정의된 모든 값에서 환경 변수 설정

  1. 함수에 사용할 func.yaml 파일을 엽니다.
  2. 모든 키-값 쌍을 환경 변수로 가져오려는 모든 시크릿에 다음 YAML을 envs 섹션에 추가합니다.

    name: test
    namespace: ""
    runtime: go
    ...
    envs:
    - value: '{{ secret:mysecret }}' 1
    1
    mysecret을 대상 시크릿의 이름으로 대체합니다.
  3. 설정을 저장합니다.

11.10.3.6. 구성 맵에 정의된 모든 값에서 환경 변수 설정

  1. 함수에 사용할 func.yaml 파일을 엽니다.
  2. 모든 키-값 쌍을 환경 변수로 가져오려는 모든 구성 맵에 대해 envs 섹션에 다음 YAML을 추가합니다.

    name: test
    namespace: ""
    runtime: go
    ...
    envs:
    - value: '{{ configMap:myconfigmap }}' 1
    1
    myconfigmap을 대상 구성 맵의 이름으로 대체합니다.
  3. 파일을 저장합니다.

11.11. 함수에 주석 추가

func.yaml 구성 파일의 annotations 섹션에 Kubernetes 주석을 배포한 Serverless 함수에 추가할 수 있습니다.

중요

함수 주석 기능에는 다음 두 가지 제한 사항이 있습니다.

  • 함수 주석이 클러스터의 해당 Knative 서비스로 전파되면 func.yaml 파일에서 삭제하여 서비스에서 제거할 수 없습니다. 서비스의 YAML 파일을 직접 수정하거나 개발자 콘솔을 사용하여 Knative 서비스에서 주석을 제거할 수 있습니다.
  • Knative에서 설정한 주석(예: autoscaling 주석)을 설정할 수 없습니다.

11.11.1. 함수에 주석 추가

절차

  1. 함수에 사용할 func.yaml 파일을 엽니다.
  2. 추가할 모든 주석에 대해 annotations 섹션에 다음 YAML을 추가합니다.

    name: test
    namespace: ""
    runtime: go
    ...
    annotations:
      <annotation_name>: "<annotation_value>" 1
    1
    <annotation_name>: "<annotation_value>"를 주석으로 바꿉니다.

    예를 들어 Alice에서 함수가 생성되었음을 나타내기 위해 다음 주석을 포함할 수 있습니다.

    name: test
    namespace: ""
    runtime: go
    ...
    annotations:
      author: "alice@example.com"
  3. 설정을 저장합니다.

다음에 함수를 클러스터에 배포할 때 해당 Knative 서비스에 주석이 추가됩니다.

11.12. 함수 개발 참조 가이드

중요

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

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

OpenShift Serverless Functions는 다음 런타임에 대한 기본 기능을 생성하는 데 사용할 수 있는 템플릿을 제공합니다.

이 가이드는 함수를 개발하는 데 사용할 수 있는 참조 정보를 제공합니다.

11.12.1. Node.js 컨텍스트 오브젝트 참조

context 오브젝트에는 함수 개발자가 액세스할 수 있는 여러 속성이 있습니다.

11.12.1.1. log

클러스터 로그에 출력을 작성하는 데 사용할 수 있는 로깅 오브젝트를 제공합니다. 로그는 Pino 로깅 API를 따릅니다.

로그 예

function handle(context) {
  context.log.info(“Processing customer”);
}

kn func emit 명령을 사용하여 이를 호출하여 함수에 액세스할 수 있습니다.

명령 예

$ kn func emit --sink 'http://example.function.com'

출력 예

{"level":30,"time":1604511655265,"pid":3430203,"hostname":"localhost.localdomain","reqId":1,"msg":"Processing customer"}

로그 수준을 fatal,error,warn,info,debug,trace 또는 silent 중 하나로 변경할 수 있습니다. 이렇게 하려면 config 명령을 사용하여 해당 값 중 하나를 환경 변수 FujiNC _LOG_LEVEL에 할당하여 logLevel 값을 변경합니다.

11.12.1.2. query

요청에 대한 쿼리 문자열을 키-값 쌍으로 반환합니다. 이러한 속성은 컨텍스트 오브젝트 자체에서도 확인할 수 있습니다.

예제 쿼리

function handle(context) {
  // Log the 'name' query parameter
  context.log.info(context.query.name);
  // Query parameters are also attached to the context
  context.log.info(context.name);
}

curl 명령을 사용하여 이를 호출하여 함수에 액세스할 수 있습니다.

명령 예

$ curl http://example.com?name=tiger

출력 예

{"level":30,"time":1604511655265,"pid":3430203,"hostname":"localhost.localdomain","reqId":1,"msg":"tiger"}

11.12.1.3. body

필요한 경우 요청 본문을 반환합니다. 요청 본문에 JSON 코드가 포함된 경우 속성을 직접 사용할 수 있도록 구문 분석됩니다.

본문의 예

function handle(context) {
  // log the incoming request body's 'hello' parameter
  context.log.info(context.body.hello);
}

curl 명령을 사용하여 이를 호출하여 함수에 액세스할 수 있습니다.

명령 예

$ kn func emit -d '{"Hello": "world"}'

출력 예

{"level":30,"time":1604511655265,"pid":3430203,"hostname":"localhost.localdomain","reqId":1,"msg":"world"}

11.12.1.4. headers

HTTP 요청 헤더를 오브젝트로 반환합니다.

헤더 예

function handle(context) {
  context.log.info(context.headers["custom-header"]);
}

kn func emit 명령을 사용하여 이를 호출하여 함수에 액세스할 수 있습니다.

명령 예

$ kn func emit --sink 'http://example.function.com'

출력 예

{"level":30,"time":1604511655265,"pid":3430203,"hostname":"localhost.localdomain","reqId":1,"msg":"some-value"}

11.12.1.5. HTTP 요청

method
HTTP 요청 메서드를 문자열로 반환합니다.
httpVersion
HTTP 버전을 문자열로 반환합니다.
httpVersionMajor
HTTP 주요 버전 번호를 문자열로 반환합니다.
httpVersionMinor
HTTP 마이너 버전 번호를 문자열로 반환합니다.

11.12.2. TypeScript 컨텍스트 오브젝트 참조

context 오브젝트에는 함수 개발자가 액세스할 수 있는 여러 속성이 있습니다.

11.12.2.1. log

클러스터 로그에 출력을 작성하는 데 사용할 수 있는 로깅 오브젝트를 제공합니다. 로그는 Pino 로깅 API를 따릅니다.

로그 예

export function handle(context: Context): string {
    // log the incoming request body's 'hello' parameter
    if (context.body) {
      context.log.info((context.body as Record<string, string>).hello);
    } else {
      context.log.info('No data received');
    }
    return 'OK';
}

kn func emit 명령을 사용하여 이를 호출하여 함수에 액세스할 수 있습니다.

명령 예

$ kn func emit --sink 'http://example.function.com'

출력 예

{"level":30,"time":1604511655265,"pid":3430203,"hostname":"localhost.localdomain","reqId":1,"msg":"Processing customer"}

로그 수준을 fatal,error,warn,info,debug,trace 또는 silent 중 하나로 변경할 수 있습니다. 이렇게 하려면 config 명령을 사용하여 해당 값 중 하나를 환경 변수 FujiNC _LOG_LEVEL에 할당하여 logLevel 값을 변경합니다.

11.12.2.2. query

요청에 대한 쿼리 문자열을 키-값 쌍으로 반환합니다. 이러한 속성은 컨텍스트 오브젝트 자체에서도 확인할 수 있습니다.

예제 쿼리

export function handle(context: Context): string {
      // log the 'name' query parameter
    if (context.query) {
      context.log.info((context.query as Record<string, string>).name);
    } else {
      context.log.info('No data received');
    }
    return 'OK';
}

kn func emit 명령을 사용하여 이를 호출하여 함수에 액세스할 수 있습니다.

명령 예

$ kn func emit --sink 'http://example.function.com' --data '{"name": "tiger"}'

출력 예

{"level":30,"time":1604511655265,"pid":3430203,"hostname":"localhost.localdomain","reqId":1,"msg":"tiger"}
{"level":30,"time":1604511655265,"pid":3430203,"hostname":"localhost.localdomain","reqId":1,"msg":"tiger"}

11.12.2.3. body

요청 본문(있는 경우)을 반환합니다. 요청 본문에 JSON 코드가 포함된 경우 속성을 직접 사용할 수 있도록 구문 분석됩니다.

본문의 예

export function handle(context: Context): string {
    // log the incoming request body's 'hello' parameter
    if (context.body) {
      context.log.info((context.body as Record<string, string>).hello);
    } else {
      context.log.info('No data received');
    }
    return 'OK';
}

kn func emit 명령을 사용하여 이를 호출하여 함수에 액세스할 수 있습니다.

명령 예

$ kn func emit --sink 'http://example.function.com' --data '{"hello": "world"}'

출력 예

{"level":30,"time":1604511655265,"pid":3430203,"hostname":"localhost.localdomain","reqId":1,"msg":"world"}

11.12.2.4. headers

HTTP 요청 헤더를 오브젝트로 반환합니다.

헤더 예

export function handle(context: Context): string {
    // log the incoming request body's 'hello' parameter
    if (context.body) {
      context.log.info((context.headers as Record<string, string>)['custom-header']);
    } else {
      context.log.info('No data received');
    }
    return 'OK';
}

curl 명령을 사용하여 이를 호출하여 함수에 액세스할 수 있습니다.

명령 예

$ curl -H'x-custom-header: some-value’' http://example.function.com

출력 예

{"level":30,"time":1604511655265,"pid":3430203,"hostname":"localhost.localdomain","reqId":1,"msg":"some-value"}

11.12.2.5. HTTP 요청

method
HTTP 요청 메서드를 문자열로 반환합니다.
httpVersion
HTTP 버전을 문자열로 반환합니다.
httpVersionMajor
HTTP 주요 버전 번호를 문자열로 반환합니다.
httpVersionMinor
HTTP 마이너 버전 번호를 문자열로 반환합니다.

12장. 통합

12.1. 서버리스 애플리케이션과 함께 NVIDIA GPU 리소스 사용

NVIDIA는 OpenShift Container Platform에서 GPU 리소스의 실험적 사용을 지원합니다. OpenShift Container Platform에서 GPU 리소스를 설정하는 방법에 대한 자세한 내용은 NVIDIA GPU 가속 클러스터의 OpenShift Container Platform을 참조하십시오.

12.1.1. 서비스에 대한 GPU 요구 사항 지정

OpenShift Container Platform 클러스터에 GPU 리소스를 활성화하면 kn CLI를 사용하여 Knative 서비스에 대한 GPU 요구 사항을 지정할 수 있습니다.

참고

IBM Z 및 IBM Power Systems에서는 NVIDIA GPU 리소스를 사용할 수 없습니다.

절차

  1. Knative 서비스를 생성하고 --limit nvidia.com/gpu=1 플래그를 사용하여 GPU 리소스 요구 사항 제한을 1로 설정합니다.

    $ kn service create hello --image <service-image> --limit nvidia.com/gpu=1

    GPU 리소스 요구 사항 제한이 1이면 서비스의 전용 GPU 리소스가 1개임을 나타냅니다. 서비스에서는 GPU 리소스를 공유하지 않습니다. GPU 리소스가 필요한 기타 서비스는 GPU 리소스를 더 이상 사용하지 않을 때까지 기다려야 합니다.

    또한 GPU가 1개로 제한되면 GPU 리소스를 2개 이상 사용하는 애플리케이션이 제한됩니다. 서비스에서 GPU 리소스를 1개 이상 요청하는 경우 GPU 리소스 요구 사항을 충족할 수 있는 노드에 배포됩니다.

  2. 선택 사항: 기존 서비스의 경우 --limit nvidia.com/gpu=3 플래그를 사용하여 GPU 리소스 요구 사항 제한을 3으로 변경할 수 있습니다.

    $ kn service update hello --limit nvidia.com/gpu=3

12.1.2. 추가 리소스

13장. CLI 툴

13.1. Knative CLI 설치

oc CLI의 설치 옵션은 운영 체제에 따라 다를 수 있습니다.

Knative CLI (kn)에는 자체 로그인 메커니즘이 없습니다. 클러스터에 로그인하려면 oc CLI를 설치하고 oc login 명령을 사용해야 합니다.

운영 체제에 oc CLI를 설치하는 방법 및 oc로 로그인하는 방법에 대한 자세한 내용은 OpenShift CLI 시작하기 설명서를 참조하십시오.

OpenShift Serverless는 kn CLI를 사용하여 설치할 수 없습니다. 클러스터 관리자는 OpenShift Serverless Operator 설치 설명서에 설명된 대로 OpenShift Serverless Operator 를 설치하고 Knative 구성 요소를 설정해야 합니다.

중요

최신 OpenShift Serverless 릴리스에서 이전 버전의 Knative kn CLI를 사용하려는 경우 API를 찾을 수 없으며 오류가 발생합니다.

예를 들어 Knative Serving 및 Knative Eventing API의 0.23.0 버전을 사용하는 1.17.0 OpenShift Serverless 릴리스와 함께 버전 0.22.0을 사용하는 kn CLI의 1.16.0 릴리스를 사용하는 경우 CLI가 오래된 0.22.0 API 버전을 계속 찾기 때문에 CLI가 작동하지 않습니다.

문제를 방지하려면 OpenShift Serverless 릴리스에 최신 kn CLI 버전을 사용 중인지 확인합니다.

13.1.1. OpenShift Container Platform 웹 콘솔을 통한 Knative CLI 설치

OpenShift Serverless Operator가 설치되면 OpenShift Container Platform 웹 콘솔의 명령줄 툴 페이지에 Linux (x86_64, amd64, s390x, ppc64le), macOS, Windows용 Knative CLI (kn)를 다운로드할 수 있는 링크가 표시됩니다.

웹 콘솔의 오른쪽 상단에 있는 question circle 아이콘을 클릭하고 드롭다운 메뉴에서 명령줄 툴을 선택하여 명령줄 툴에 액세스할 수 있습니다.

절차

  1. 명령줄 툴 페이지에서 kn CLI를 다운로드합니다.
  2. 아카이브의 압축을 풉니다.

    $ tar -xf <file>
  3. kn 바이너리를 PATH의 디렉터리로 이동합니다.
  4. PATH를 확인하려면 다음을 실행합니다.

    $ echo $PATH
    참고

    RHEL 또는 Fedora를 사용하지 않는 경우 libc가 라이브러리 경로의 디렉터리에 설치되어 있는지 확인합니다. libc를 사용할 수 없는 경우 CLI 명령을 실행할 때 다음과 같은 오류가 표시될 수 있습니다.

    $ kn: No such file or directory

13.1.2. RPM을 사용하여 Linux용 Knative CLI 설치

RHEL(Red Hat Enterprise Linux)의 경우 Red Hat 계정에 활성 OpenShift Container Platform 서브스크립션이 있으면 Knative CLI (kn)을 RPM으로 설치할 수 있습니다.

프로세스

  1. 명령을 입력합니다.

    # subscription-manager register
  2. 명령을 입력합니다.

    # subscription-manager refresh
  3. 명령을 입력합니다.

    # subscription-manager attach --pool=<pool_id> 1
    1
    활성 OpenShift Container Platform 서브스크립션의 풀 ID
  4. 명령을 입력합니다.

    # subscription-manager repos --enable="openshift-serverless-1-for-rhel-8-x86_64-rpms"
  5. 명령을 입력합니다.

    # yum install openshift-serverless-clients

13.1.3. Linux의 Knative CLI 설치

Linux 배포판의 경우 Knative CLI (kn)를 tar.gz 아카이브로 직접 다운로드할 수 있습니다.

프로세스

  1. kn CLI를 다운로드합니다.
  2. 아카이브의 압축을 풉니다.

    $ tar -xf <file>
  3. kn 바이너리를 PATH의 디렉터리로 이동합니다.
  4. PATH를 확인하려면 다음을 실행합니다.

    $ echo $PATH
    참고

    RHEL 또는 Fedora를 사용하지 않는 경우 libc가 라이브러리 경로의 디렉터리에 설치되어 있는지 확인합니다. libc를 사용할 수 없는 경우 CLI 명령을 실행할 때 다음과 같은 오류가 표시될 수 있습니다.

    $ kn: No such file or directory

13.1.4. RPM을 사용하여 IBM Power Systems에 Linux용 Knative CLI 설치

RHEL(Red Hat Enterprise Linux)의 경우 Red Hat 계정에 활성 OpenShift Container Platform 서브스크립션이 있으면 Knative CLI (kn)을 RPM으로 설치할 수 있습니다.

절차

  1. 초기 부팅 프로세스 중에 RHSM(Red Hat Subscription Management) 서비스에 등록합니다.

    # subscription-manager register
  2. RHSM을 새로 고침합니다.

    # subscription-manager refresh
  3. --pool 옵션을 사용하여 서브스크립션 풀의 ID를 지정하여 시스템에 서브스크립션을 연결합니다.

    # subscription-manager attach --pool=<pool_id> 1
    1
    활성 OpenShift Container Platform 서브스크립션의 풀 ID
  4. Red Hat Subscription Manager를 사용하여 리포지터리를 활성화합니다.

    # subscription-manager repos --enable="openshift-serverless-1-for-rhel-8-ppc64le-rpms"
  5. 시스템에 openshift-serverless-clients를 설치합니다.

    # yum install openshift-serverless-clients

13.1.5. IBM Power Systems에 Linux용 Knative CLI 설치

Linux 배포판의 경우 Knative CLI (kn)를 tar.gz 아카이브로 직접 다운로드할 수 있습니다.

절차

  1. kn CLI를 다운로드합니다.
  2. 아카이브의 압축을 풉니다.

    $ tar -xf <file>
  3. kn 바이너리를 PATH의 디렉터리로 이동합니다.
  4. PATH를 확인하려면 다음을 실행합니다.

    $ echo $PATH
    참고

    RHEL을 사용하지 않는 경우 libc가 라이브러리 경로의 디렉터리에 설치되어 있는지 확인합니다.

    libc를 사용할 수 없는 경우 CLI 명령을 실행할 때 다음과 같은 오류가 표시될 수 있습니다.

    $ kn: No such file or directory

13.1.6. RPM을 사용하여 IBM Z 및 LinuxONE에 Linux용 Knative CLI 설치

RHEL(Red Hat Enterprise Linux)의 경우 Red Hat 계정에 활성 OpenShift Container Platform 서브스크립션이 있으면 Knative CLI (kn)을 RPM으로 설치할 수 있습니다.

절차

  1. 초기 부팅 프로세스 중에 RHSM(Red Hat Subscription Management) 서비스에 등록합니다.

    # subscription-manager register
  2. RHSM을 새로 고침합니다.

    # subscription-manager refresh
  3. --pool 옵션을 사용하여 서브스크립션 풀의 ID를 지정하여 시스템에 서브스크립션을 연결합니다.

    # subscription-manager attach --pool=<pool_id> 1
    1
    활성 OpenShift Container Platform 서브스크립션의 풀 ID
  4. Red Hat Subscription Manager를 사용하여 리포지터리를 활성화합니다.

    # subscription-manager repos --enable="openshift-serverless-1-for-rhel-8-s390x-rpms"
  5. 시스템에 openshift-serverless-clients를 설치합니다.

    # yum install openshift-serverless-clients

13.1.7. IBM Z 및 LinuxONE에 Linux용 Knative CLI 설치

Linux 배포판의 경우 Knative CLI (kn)를 tar.gz 아카이브로 직접 다운로드할 수 있습니다.

절차

  1. kn CLI를 다운로드합니다.
  2. 아카이브의 압축을 풉니다.

    $ tar -xf <file>
  3. kn 바이너리를 PATH의 디렉터리로 이동합니다.
  4. PATH를 확인하려면 다음을 실행합니다.

    $ echo $PATH
    참고

    RHEL을 사용하지 않는 경우 libc가 라이브러리 경로의 디렉터리에 설치되어 있는지 확인합니다.

    libc를 사용할 수 없는 경우 CLI 명령을 실행할 때 다음과 같은 오류가 표시될 수 있습니다.

    $ kn: No such file or directory

13.1.8. macOS용 Knative CLI 설치

macOS용 Knative CLI (kn)은 tar.gz 아카이브로 제공됩니다.

절차

  1. kn CLI를 다운로드합니다.
  2. 아카이브의 압축을 해제하고 압축을 풉니다.
  3. kn 바이너리를 PATH의 디렉터리로 이동합니다.
  4. PATH를 확인하려면 터미널 창을 열고 다음을 실행합니다.

    $ echo $PATH

13.1.9. Windows용 Knative CLI 설치

Windows용 Knative CLI (kn)는 zip 아카이브로 제공됩니다.

절차

  1. kn CLI를 다운로드합니다.
  2. ZIP 프로그램으로 아카이브의 압축을 풉니다.
  3. kn 바이너리를 PATH의 디렉터리로 이동합니다.
  4. PATH를 확인하려면 명령 프롬프트를 열고 다음 명령을 실행합니다.

    C:\> path

13.1.10. Knative CLI 사용자 지정

config.yaml 구성 파일을 생성하여 kn CLI 설정을 사용자 지정할 수 있습니다. --config 플래그를 사용하여 이 구성을 지정할 수 있습니다. 지정하지 않으면 기본 위치에서 구성을 가져옵니다. 기본 구성 위치는 XDG Base Directory Specification을 준수하고 Unix 시스템 및 Windows 시스템에 따라 다릅니다.

Unix 시스템의 경우:

  • XDG_CONFIG_HOME 환경 변수가 설정된 경우 kn CLI에서 찾는 기본 구성 위치는 $XDG_CONFIG_HOME/kn입니다.
  • XDG_CONFIG_HOME 환경 변수가 설정되지 않은 경우 kn CLI는 사용자의 홈 디렉터리에서 $HOME/.config/kn/config.yaml에서 구성을 찾습니다.

Windows 시스템의 경우 기본 kn CLI 구성 위치는 %APPDATA%\kn입니다.

설정 파일 예

plugins:
  path-lookup: true 1
  directory: ~/.config/kn/plugins 2
eventing:
  sink-mappings: 3
  - prefix: svc 4
    group: core 5
    version: v1 6
    resource: services 7

1
kn CLI가 PATH 환경 변수에서 플러그인을 찾을지 여부를 지정합니다. 이는 부울 구성 옵션입니다. 기본값은 false입니다.
2
kn CLI에서 플러그인을 검색할 디렉터리를 지정합니다. 기본 경로는 위에 설명된 대로 운영 체제에 따라 다릅니다. 이는 사용자에게 표시되는 모든 디렉터리일 수 있습니다.
3
sink-mappings 사양은 kn CLI 명령과 함께 --sink 플래그를 사용할 때 사용되는 Kubernetes 주소 지정 가능 리소스를 정의합니다.
4
서비스, 채널브로커 에 대한 sink. svc 를 설명하는 데 사용할 접두사는 kn 에 사전 정의된 접두사입니다.
5
Kubernetes 리소스의 API 그룹입니다.
6
Kubernetes 리소스의 버전입니다.
7
Kubernetes 리소스 유형의 복수형 이름입니다. 예: services 또는 brokers

13.1.11. Knative CLI 플러그인

kn CLI는 플러그인 사용을 지원하므로 코어 배포의 일부가 아닌 사용자 지정 명령 및 기타 공유 명령을 추가하여 kn 설치 기능을 확장할 수 있습니다. kn CLI 플러그인은 기본 kn 기능과 동일한 방식으로 사용됩니다.

현재 Red Hat은 kn-source-kafka 플러그인을 지원합니다.

13.2. Knative CLI 고급 설정

kn 또는 플러그인을 사용하여 config.yaml 파일을 구성하는 등 고급 기능을 사용하여 kn CLI를 사용자 지정하고 확장할 수 있습니다.

13.2.1. Knative CLI 사용자 지정

config.yaml 구성 파일을 생성하여 kn CLI 설정을 사용자 지정할 수 있습니다. --config 플래그를 사용하여 이 구성을 지정할 수 있습니다. 지정하지 않으면 기본 위치에서 구성을 가져옵니다. 기본 구성 위치는 XDG Base Directory Specification을 준수하고 Unix 시스템 및 Windows 시스템에 따라 다릅니다.

Unix 시스템의 경우:

  • XDG_CONFIG_HOME 환경 변수가 설정된 경우 kn CLI에서 찾는 기본 구성 위치는 $XDG_CONFIG_HOME/kn입니다.
  • XDG_CONFIG_HOME 환경 변수가 설정되지 않은 경우 kn CLI는 사용자의 홈 디렉터리에서 $HOME/.config/kn/config.yaml에서 구성을 찾습니다.

Windows 시스템의 경우 기본 kn CLI 구성 위치는 %APPDATA%\kn입니다.

설정 파일 예

plugins:
  path-lookup: true 1
  directory: ~/.config/kn/plugins 2
eventing:
  sink-mappings: 3
  - prefix: svc 4
    group: core 5
    version: v1 6
    resource: services 7

1
kn CLI가 PATH 환경 변수에서 플러그인을 찾을지 여부를 지정합니다. 이는 부울 구성 옵션입니다. 기본값은 false입니다.
2
kn CLI에서 플러그인을 검색할 디렉터리를 지정합니다. 기본 경로는 위에 설명된 대로 운영 체제에 따라 다릅니다. 이는 사용자에게 표시되는 모든 디렉터리일 수 있습니다.
3
sink-mappings 사양은 kn CLI 명령과 함께 --sink 플래그를 사용할 때 사용되는 Kubernetes 주소 지정 가능 리소스를 정의합니다.
4
서비스, 채널브로커 에 대한 sink. svc 를 설명하는 데 사용할 접두사는 kn 에 사전 정의된 접두사입니다.
5
Kubernetes 리소스의 API 그룹입니다.
6
Kubernetes 리소스의 버전입니다.
7
Kubernetes 리소스 유형의 복수형 이름입니다. 예: services 또는 brokers

13.2.2. Knative CLI 플러그인

kn CLI는 플러그인 사용을 지원하므로 코어 배포의 일부가 아닌 사용자 지정 명령 및 기타 공유 명령을 추가하여 kn 설치 기능을 확장할 수 있습니다. kn CLI 플러그인은 기본 kn 기능과 동일한 방식으로 사용됩니다.

현재 Red Hat은 kn-source-kafka 플러그인을 지원합니다.

14장. reference

14.1. kn 플래그 참조

14.1.1. Knative CLI --sink 플래그

Knative(kn) CLI를 사용하여 event-producing 사용자 정의 리소스를 생성하는 경우 --sink 플래그를 사용하여 이벤트가 해당 리소스에서 로 전송되는 싱크를 지정할 수 있습니다.

다음 예제에서는 싱크로 서비스 http://event-display.svc.cluster.local를 사용하는 싱크 바인딩을 생성합니다.

--sink 플래그를 사용하는 명령의 예

$ kn source binding create bind-heartbeat \
  --namespace sinkbinding-example \
  --subject "Job:batch/v1:app=heartbeat-cron" \
  --sink http://event-display.svc.cluster.local \ 1
  --ce-override "sink=bound"

1
http://event-display.svc.cluster.localsvc는 싱크가 Knative 서비스인지 확인합니다. 기타 기본 싱크 접두사에는 channel, 및 broker가 포함됩니다.

14.2. Knative Serving CLI 명령

다음 kn CLI 명령을 사용하여 클러스터에서 Knative Serving 작업을 완료할 수 있습니다.

14.2.1. kn service 명령

다음 명령을 사용하여 Knative 서비스를 생성하고 관리할 수 있습니다.

14.2.1.1. Knative CLI를 사용하여 서버리스 애플리케이션 생성

다음 절차에서는 kn CLI를 사용하여 기본 서버리스 애플리케이션을 생성하는 방법을 설명합니다.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Serving이 클러스터에 설치되어 있습니다.
  • kn CLI를 설치했습니다.

절차

  • Knative 서비스를 생성합니다.

    $ kn service create <service-name> --image <image> --env <key=value>

    명령 예

    $ kn service create event-display \
        --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest

    출력 예

    Creating service 'event-display' in namespace 'default':
    
      0.271s The Route is still working to reflect the latest desired specification.
      0.580s Configuration "event-display" is waiting for a Revision to become ready.
      3.857s ...
      3.861s Ingress has not yet been reconciled.
      4.270s Ready to serve.
    
    Service 'event-display' created with latest revision 'event-display-bxshg-1' and URL:
    http://event-display-default.apps-crc.testing

14.2.1.2. Knative CLI를 사용하여 서버리스 애플리케이션 업데이트

서비스를 단계적으로 구축할 때 명령줄에서 대화형 세션에 kn service update 명령을 사용할 수 있습니다. kn service apply 명령과 달리 kn service update 명령을 사용하는 경우 Knative 서비스의 전체 구성이 아닌 업데이트하려는 변경 사항만 지정해야 합니다.

명령 예

  • 새 환경 변수를 추가하여 서비스를 업데이트합니다.

    $ kn service update <service_name> --env <key>=<value>
  • 새 포트를 추가하여 서비스를 업데이트합니다.

    $ kn service update <service_name> --port 80
  • 새 요청 및 제한 매개변수를 추가하여 서비스를 업데이트합니다.

    $ kn service update <service_name> --request cpu=500m --limit memory=1024Mi --limit cpu=1000m
  • latest 태그를 개정 버전에 할당합니다.

    $ kn service update <service_name> --tag <revision_name>=latest
  • 서비스의 최신 READY 버전에 대한 태그를 testing에서 staging으로 업데이트합니다.

    $ kn service update <service_name> --untag testing --tag @latest=staging
  • 트래픽의 10%를 수신하는 버전에 test 태그를 추가하고 나머지 트래픽을 서비스의 최신 READY 버전으로 전송합니다.

    $ kn service update <service_name> --tag <revision_name>=test --traffic test=10,@latest=90

14.2.1.3. 서비스 선언 적용

kn service apply 명령을 사용하여 Knative 서비스를 선언적으로 구성할 수 있습니다. 서비스가 존재하지 않으면 기존 서비스가 변경된 옵션으로 업데이트됩니다.

kn service apply 명령은 사용자가 일반적으로 단일 명령으로 서비스 상태를 완전히 지정하여 대상 상태를 선언하려는 셸 스크립트 또는 지속적 통합 파이프라인에 특히 유용합니다.

kn service apply를 사용하는 경우 Knative 서비스에 대한 전체 구성을 제공해야 합니다. 이 동작은 업데이트하려는 옵션을 명령에서 지정하기만 하면 되는 kn service update 명령과 다릅니다.

명령 예

  • 서비스를 생성합니다.

    $ kn service apply <service_name> --image <image>
  • 서비스에 환경 변수를 추가합니다.

    $ kn service apply <service_name> --image <image> --env <key>=<value>
  • JSON 또는 YAML 파일에서 서비스 선언을 읽습니다.

    $ kn service apply <service_name> -f <filename>

14.2.1.4. Knative CLI를 사용하여 서버리스 애플리케이션 설명

kn service describe 명령을 사용하여 Knative 서비스를 설명할 수 있습니다.

명령 예

  • 서비스를 설명합니다.

    $ kn service describe --verbose <service_name>

    --verbose 플래그는 선택 사항이지만 자세한 설명을 제공하기 위해 포함할 수 있습니다. 일반 출력과 자세한 출력의 차이점은 다음 예에 표시됩니다.

    --verbose 플래그를 사용하지 않는 출력 예

    Name:       hello
    Namespace:  default
    Age:        2m
    URL:        http://hello-default.apps.ocp.example.com
    
    Revisions:
      100%  @latest (hello-00001) [1] (2m)
            Image:  docker.io/openshift/hello-openshift (pinned to aaea76)
    
    Conditions:
      OK TYPE                   AGE REASON
      ++ Ready                   1m
      ++ ConfigurationsReady     1m
      ++ RoutesReady             1m

    --verbose 플래그를 사용하는 출력 예

    Name:         hello
    Namespace:    default
    Annotations:  serving.knative.dev/creator=system:admin
                  serving.knative.dev/lastModifier=system:admin
    Age:          3m
    URL:          http://hello-default.apps.ocp.example.com
    Cluster:      http://hello.default.svc.cluster.local
    
    Revisions:
      100%  @latest (hello-00001) [1] (3m)
            Image:  docker.io/openshift/hello-openshift (pinned to aaea76)
            Env:    RESPONSE=Hello Serverless!
    
    Conditions:
      OK TYPE                   AGE REASON
      ++ Ready                   3m
      ++ ConfigurationsReady     3m
      ++ RoutesReady             3m

  • YAML 형식으로 서비스를 설명합니다.

    $ kn service describe <service_name> -o yaml
  • JSON 형식으로 서비스를 설명합니다.

    $ kn service describe <service_name> -o json
  • 서비스 URL만 인쇄합니다.

    $ kn service describe <service_name> -o url

14.2.2. kn 컨테이너 명령

다음 명령을 사용하여 Knative 서비스 사양에 여러 컨테이너를 생성하고 관리할 수 있습니다.

14.2.2.1. Knative 클라이언트 멀티컨테이너 지원

kn container add 명령을 사용하여 YAML 컨테이너 사양을 표준 출력에 출력할 수 있습니다. 이 명령은 다른 표준 kn 플래그와 함께 사용하여 정의를 생성할 수 있으므로 멀티컨테이너 사용 사례에 유용합니다. kn container add 명령은 kn service create 명령과 함께 사용할 수 있는 모든 컨테이너 관련 플래그를 허용합니다. kn container add 명령을 UNIX 파이프(|)를 사용하여 한 번에 여러 컨테이너 정의를 만들어 연결할 수도 있습니다.

14.2.2.1.1. 명령 예
  • 이미지의 컨테이너를 추가하고 표준 출력에 출력합니다.

    $ kn container add <container_name> --image <image_uri>

    명령 예

    $ kn container add sidecar --image docker.io/example/sidecar

    출력 예

    containers:
    - image: docker.io/example/sidecar
      name: sidecar
      resources: {}

  • 체인 2개의 kn 컨테이너 추가 명령을 함께 추가한 다음 kn service create 명령에 전달하여 두 개의 컨테이너가 있는 Knative 서비스를 생성합니다.

    $ kn container add <first_container_name> --image <image_uri> | \
    kn container add <second_container_name> --image <image_uri> | \
    kn service create <service_name> --image <image_uri> --extra-containers -

    --extra-containers - kn 이 YAML 파일 대신 파이프 입력을 읽는 특수 케이스를 지정합니다.

    명령 예

    $ kn container add sidecar --image docker.io/example/sidecar:first | \
    kn container add second --image docker.io/example/sidecar:second | \
    kn service create my-service --image docker.io/example/my-app:latest --extra-containers -

    extra -containers 플래그는 YAML 파일의 경로도 허용할 수 있습니다.

    $ kn service create <service_name> --image <image_uri> --extra-containers <filename>

    명령 예

    $ kn service create my-service --image docker.io/example/my-app:latest --extra-containers my-extra-containers.yaml

14.2.3. kn domain 명령

다음 명령을 사용하여 도메인 매핑을 생성하고 관리할 수 있습니다.

14.2.3.1. Knative CLI를 사용하여 사용자 정의 도메인 매핑 생성

kn CLI를 사용하여 Knative 서비스 또는 Knative 경로와 같이 주소 지정 대상 CR에 매핑되는 DomainMapping CR(사용자 정의 리소스)을 생성할 수 있습니다.

--ref 플래그는 도메인 매핑을 위해 주소 지정 가능한 대상 CR을 지정합니다.

--ref 플래그를 사용할 때 접두사가 지정되어 있지 않은 경우 대상이 현재 네임스페이스의 Knative 서비스라고 가정합니다. 다음 절차의 예제에서는 Knative 서비스 또는 Knative 경로에 매핑할 접두사를 보여줍니다.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Serving이 클러스터에 설치되어 있습니다.
  • Knative 서비스 또는 경로를 생성했으며 CR에 매핑할 사용자 정의 도메인을 제어할 수 있습니다.

    참고

    사용자 정의 도메인에서 OpenShift Container Platform 클러스터의 DNS를 가리켜야 합니다.

  • kn CLI 툴을 설치했습니다.

절차

  • 현재 네임스페이스의 CR에 도메인을 매핑합니다.

    $ kn domain create <domain_mapping_name> --ref <target_name>

    명령 예

    $ kn domain create example.com --ref example-service

  • 지정된 네임스페이스의 Knative 서비스에 도메인을 매핑합니다.

    $ kn domain create <domain_mapping_name> --ref <ksvc:service_name:service_namespace>

    명령 예

    $ kn domain create example.com --ref ksvc:example-service:example-namespace

  • 도메인을 Knative 경로에 매핑합니다.

    $ kn domain create <domain_mapping_name> --ref <kroute:route_name>

    명령 예

    $ kn domain create example.com --ref kroute:example-route

14.2.3.2. Knative CLI를 사용하여 사용자 정의 도메인 매핑 관리

DomainMapping 사용자 정의 리소스(CR)를 생성한 후에는 kn CLI를 사용하여 기존 CR을 나열, 기존 CR에 대한 정보 확인, CR을 업데이트하거나, CR을 삭제할 수 있습니다.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Serving이 클러스터에 설치되어 있습니다.
  • 하나 이상의 DomainMapping CR을 생성했습니다.
  • kn CLI 툴을 설치했습니다.

절차

  • 기존 DomainMapping CR을 나열합니다.

    $ kn domain list -n <domain_mapping_namespace>
  • 기존 DomainMapping CR 정보를 표시합니다.

    $ kn domain describe <domain_mapping_name>
  • 새 대상을 참조하도록 DomainMapping CR을 업데이트합니다.

    $ kn domain update --ref <target>
  • DomainMapping CR을 삭제합니다.

    $ kn domain delete <domain_mapping_name>

14.3. Knative Eventing CLI 명령

다음 kn CLI 명령을 사용하여 클러스터에서 Knative Eventing 작업을 완료할 수 있습니다.

14.3.1. kn source 명령

다음 명령을 사용하여 Knative 이벤트 소스를 나열, 생성 및 관리할 수 있습니다.

14.3.1.1. Knative CLI를 사용하여 사용 가능한 이벤트 소스 유형 나열

절차

  1. 터미널에서 사용 가능한 이벤트 소스 유형을 나열합니다.

    $ kn source list-types

    출력 예