통합

프로세스

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와 통합할 때 생성된 게이트웨이에서 선택하여 수신 게이트웨이가 이 인증서와 트래픽을 제공하도록 합니다.

프로세스

1. Knative Serving 사용자 정의 리소스(CR)의 observability 사양에서 prometheus를 metrics.backend-destination으로 지정합니다.

   apiVersion: operator.knative.dev/v1beta1
   kind: KnativeServing
   metadata:
     name: knative-serving
     namespace: knative-serving
   spec:
     config:
       observability:
         metrics.backend-destination: "prometheus"
   ...

   이 단계에서는 메트릭이 기본적으로 비활성화되지 않습니다.

   참고

   manageNetworkPolicy: false 를 사용하여 ServiceMeshControlPlane 을 구성할 때 KnativeEventing에서 주석을 사용하여 적절한 이벤트 전달을 보장해야 합니다.

   동일한 메커니즘이 Knative Eventing에 사용됩니다. Knative Eventing에 대한 메트릭을 활성화하려면 다음과 같이 Knative Eventing CR(사용자 정의 리소스)의 관찰 가능성 사양에 prometheus 를 metrics.backend-destination 으로 지정해야 합니다.

   apiVersion: operator.knative.dev/v1beta1
   kind: KnativeEventing
   metadata:
     name: knative-eventing
     namespace: knative-eventing
   spec:
     config:
       observability:
         metrics.backend-destination: "prometheus"
   ...

2. 다음 사양을 포함하도록 istio-system 네임스페이스에서 기본 서비스 메시 컨트롤 플레인을 수정하고 다시 적용합니다.

   ...
   spec:
     proxy:
       networking:
         trafficControl:
           inbound:
             excludedPorts:
             - 8444
   ...

프로세스

1. 테넌트의 모든 Red Hat OpenShift Serverless 프로젝트가 멤버와 동일한 ServiceMeshMemberRoll 오브젝트에 포함되어 있는지 확인합니다.

   apiVersion: maistra.io/v1
   kind: ServiceMeshMemberRoll
   metadata:
    name: default
    namespace: istio-system
   spec:
    members:
      - knative-serving    # static value, needs to be here, see setup page
      - knative-eventing   # static value, needs to be here, see setup page
      - team-alpha-1       # example OpenShift project that belongs to the team-alpha tenant
      - team-alpha-2       # example OpenShift project that belongs th the team-alpha tenant
      - team-bravo-1       # example OpenShift project that belongs to the team-bravo tenant
      - team-bravo-2       # example OpenShift project that belongs th the team-bravo tenant

   메시에 속하는 모든 프로젝트는 strict 모드에서 mTLS를 적용해야 합니다. 이렇게 하면 Istio가 클라이언트-인증서가 있는 연결만 수락하고 Service Mesh 사이드카가 AuthorizationPolicy 오브젝트를 사용하여 원본을 검증할 수 있습니다.

2. knative-serving 및 knative-eventing 네임스페이스에서 AuthorizationPolicy 오브젝트를 사용하여 구성을 생성합니다.

   knative-default-authz-policies.yaml 구성 파일의 예

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: deny-all-by-default
     namespace: knative-eventing
   spec: { }
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: deny-all-by-default
     namespace: knative-serving
   spec: { }
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allow-mt-channel-based-broker-ingress-to-imc-dispatcher
     namespace: knative-eventing
   spec:
     action: ALLOW
     selector:
       matchLabels:
         app.kubernetes.io/component: "imc-dispatcher"
     rules:
       - from:
           - source:
               namespaces: [ "knative-eventing" ]
               principals: [ "cluster.local/ns/knative-eventing/sa/mt-broker-ingress" ]
         to:
           - operation:
               methods: [ "POST" ]
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allow-mt-channel-based-broker-ingress-to-kafka-channel
     namespace: knative-eventing
   spec:
     action: ALLOW
     selector:
       matchLabels:
         app.kubernetes.io/component: "kafka-channel-receiver"
     rules:
       - from:
           - source:
               namespaces: [ "knative-eventing" ]
               principals: [ "cluster.local/ns/knative-eventing/sa/mt-broker-ingress" ]
         to:
           - operation:
               methods: [ "POST" ]
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allow-kafka-channel-to-mt-channel-based-broker-filter
     namespace: knative-eventing
   spec:
     action: ALLOW
     selector:
       matchLabels:
         app.kubernetes.io/component: "broker-filter"
     rules:
       - from:
           - source:
               namespaces: [ "knative-eventing" ]
               principals: [ "cluster.local/ns/knative-eventing/sa/knative-kafka-channel-data-plane" ]
         to:
           - operation:
               methods: [ "POST" ]
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allow-imc-to-mt-channel-based-broker-filter
     namespace: knative-eventing
   spec:
     action: ALLOW
     selector:
       matchLabels:
         app.kubernetes.io/component: "broker-filter"
     rules:
       - from:
           - source:
               namespaces: [ "knative-eventing" ]
               principals: [ "cluster.local/ns/knative-eventing/sa/imc-dispatcher" ]
         to:
           - operation:
               methods: [ "POST" ]
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allow-probe-kafka-broker-receiver
     namespace: knative-eventing
   spec:
     action: ALLOW
     selector:
       matchLabels:
         app.kubernetes.io/component: "kafka-broker-receiver"
     rules:
       - from:
           - source:
               namespaces: [ "knative-eventing" ]
               principals: [ "cluster.local/ns/knative-eventing/sa/kafka-controller" ]
         to:
           - operation:
               methods: [ "GET" ]
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allow-probe-kafka-sink-receiver
     namespace: knative-eventing
   spec:
     action: ALLOW
     selector:
       matchLabels:
         app.kubernetes.io/component: "kafka-sink-receiver"
     rules:
       - from:
           - source:
               namespaces: [ "knative-eventing" ]
               principals: [ "cluster.local/ns/knative-eventing/sa/kafka-controller" ]
         to:
           - operation:
               methods: [ "GET" ]
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allow-probe-kafka-channel-receiver
     namespace: knative-eventing
   spec:
     action: ALLOW
     selector:
       matchLabels:
         app.kubernetes.io/component: "kafka-channel-receiver"
     rules:
       - from:
           - source:
               namespaces: [ "knative-eventing" ]
               principals: [ "cluster.local/ns/knative-eventing/sa/kafka-controller" ]
         to:
           - operation:
               methods: [ "GET" ]
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allow-traffic-to-activator
     namespace: knative-serving
   spec:
     selector:
       matchLabels:
         app: activator
     action: ALLOW
     rules:
       - from:
           - source:
               namespaces: [ "knative-serving", "istio-system" ]
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allow-traffic-to-autoscaler
     namespace: knative-serving
   spec:
     selector:
       matchLabels:
         app: autoscaler
     action: ALLOW
     rules:
       - from:
           - source:
               namespaces: [ "knative-serving" ]

   이러한 정책은 Serverless 시스템 구성 요소 간 네트워크 통신에 대한 액세스 규칙을 제한합니다. 특히 다음 규칙을 적용합니다.

   • knative-serving 및 knative-eventing 네임스페이스에서 명시적으로 허용되지 않은 모든 트래픽을 거부합니다.
   • istio-system 및 knative-serving 네임스페이스의 트래픽을 활성화하도록 허용
   • knative-serving 네임스페이스의 트래픽을 자동 스케일러로 허용
   • knative-eventing 네임스페이스에서 Apache Kafka 구성 요소에 대한 상태 프로브 허용
   • knative-eventing 네임스페이스에서 채널 기반 브로커에 대한 내부 트래픽 허용

3. 권한 부여 정책 구성을 적용합니다.

   $ oc apply -f knative-default-authz-policies.yaml

4. 서로 통신할 수 있는 OpenShift 프로젝트를 정의합니다. 이 통신을 위해 테넌트의 모든 OpenShift 프로젝트에는 다음이 필요합니다.

   • 테넌트의 프로젝트로 들어오는 트래픽을 직접 제한하는 하나의 AuthorizationPolicy 오브젝트
   • knative-serving 프로젝트에서 실행되는 Serverless의 활성화 구성 요소를 사용하여 들어오는 트래픽을 제한하는 AuthorizationPolicy 오브젝트
   • Kubernetes가 Knative 서비스에서 PreStopHooks 를 호출할 수 있도록 하는 하나의 AuthorizationPolicy 오브젝트

   이러한 정책을 수동으로 생성하는 대신 helm 유틸리티를 설치하고 각 테넌트에 필요한 리소스를 생성합니다.

   helm 유틸리티 설치

   $ helm repo add openshift-helm-charts https://charts.openshift.io/

   팀 알파에 대한 구성 예 생성

   $ helm template openshift-helm-charts/redhat-knative-istio-authz --version 1.34.0 --set "name=team-alpha" --set "namespaces={team-alpha-1,team-alpha-2}" > team-alpha.yaml

   팀 bravo의 구성 예 생성

   $ helm template openshift-helm-charts/redhat-knative-istio-authz --version 1.31.0 --set "name=team-bravo" --set "namespaces={team-bravo-1,team-bravo-2}" > team-bravo.yaml

5. 권한 부여 정책 구성을 적용합니다.

   $ oc apply -f team-alpha.yaml team-bravo.yaml

프로세스

1. 두 테넌트의 네임스페이스에 Knative 서비스를 배포합니다.

   team-alpha의 명령 예

   $ kn service create test-webapp -n team-alpha-1 \
       --annotation-service serving.knative.openshift.io/enablePassthrough=true \
       --annotation-revision sidecar.istio.io/inject=true \
       --env RESPONSE="Hello Serverless" \
       --image docker.io/openshift/hello-openshift

   team-bravo의 명령 예

   $ kn service create test-webapp -n team-bravo-1 \
       --annotation-service serving.knative.openshift.io/enablePassthrough=true \
       --annotation-revision sidecar.istio.io/inject=true \
       --env RESPONSE="Hello Serverless" \
       --image docker.io/openshift/hello-openshift

   또는 다음 YAML 구성을 사용합니다.

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: test-webapp
     namespace: team-alpha-1
     annotations:
       serving.knative.openshift.io/enablePassthrough: "true"
   spec:
     template:
       metadata:
         annotations:
           sidecar.istio.io/inject: 'true'
       spec:
         containers:
           - image: docker.io/openshift/hello-openshift
             env:
               - name: RESPONSE
                 value: "Hello Serverless!"
   ---
   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: test-webapp
     namespace: team-bravo-1
     annotations:
       serving.knative.openshift.io/enablePassthrough: "true"
   spec:
     template:
       metadata:
         annotations:
           sidecar.istio.io/inject: 'true'
       spec:
         containers:
           - image: docker.io/openshift/hello-openshift
             env:
               - name: RESPONSE
                 value: "Hello Serverless!"

2. 연결을 테스트하기 위해 curl 포드를 배포합니다.

   $ cat <<EOF | oc apply -f -
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: curl
     namespace: team-alpha-1
     labels:
       app: curl
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: curl
     template:
       metadata:
         labels:
           app: curl
         annotations:
           sidecar.istio.io/inject: 'true'
       spec:
         containers:
         - name: curl
           image: curlimages/curl
           command:
           - sleep
           - "3600"
   EOF

3. curl 명령을 사용하여 구성을 확인합니다.

   다음을 수행할 수 있는 클러스터 로컬 도메인을 통해 team-alpha-1 → team-alpha-1 을 테스트합니다.

   명령 예

   $ oc exec deployment/curl -n team-alpha-1 -it -- curl -v http://test-webapp.team-alpha-1:80

   출력 예

   HTTP/1.1 200 OK
   content-length: 18
   content-type: text/plain; charset=utf-8
   date: Wed, 26 Jul 2023 12:49:59 GMT
   server: envoy
   x-envoy-upstream-service-time: 9
   
   Hello Serverless!

   허용되는 외부 도메인을 통해 team-alpha-1 을 team-alpha-1 연결을 테스트합니다.

   명령 예

   $ EXTERNAL_URL=$(oc get ksvc -n team-alpha-1 test-webapp -o custom-columns=:.status.url --no-headers) && \
   oc exec deployment/curl -n team-alpha-1 -it -- curl -ik $EXTERNAL_URL

   출력 예

   HTTP/2 200
   content-length: 18
   content-type: text/plain; charset=utf-8
   date: Wed, 26 Jul 2023 12:55:30 GMT
   server: istio-envoy
   x-envoy-upstream-service-time: 3629
   
   Hello Serverless!

   클러스터의 로컬 도메인을 통해 team-alpha-1 을 team-bravo-1 연결을 테스트합니다. 이 연결은 허용되지 않습니다.

   명령 예

   $ oc exec deployment/curl -n team-alpha-1 -it -- curl -v http://test-webapp.team-bravo-1:80

   출력 예

   * processing: http://test-webapp.team-bravo-1:80
   *   Trying 172.30.73.216:80...
   * Connected to test-webapp.team-bravo-1 (172.30.73.216) port 80
   > GET / HTTP/1.1
   > Host: test-webapp.team-bravo-1
   > User-Agent: curl/8.2.0
   > Accept: */*
   >
   < HTTP/1.1 403 Forbidden
   < content-length: 19
   < content-type: text/plain
   < date: Wed, 26 Jul 2023 12:55:49 GMT
   < server: envoy
   < x-envoy-upstream-service-time: 6
   <
   * Connection #0 to host test-webapp.team-bravo-1 left intact
   RBAC: access denied

   허용되는 외부 도메인을 통해 team-alpha-1 을 team-bravo-1 연결을 테스트합니다.

   명령 예

   $ EXTERNAL_URL=$(oc get ksvc -n team-bravo-1 test-webapp -o custom-columns=:.status.url --no-headers) && \
   oc exec deployment/curl -n team-alpha-1 -it -- curl -ik $EXTERNAL_URL

   출력 예

   HTTP/2 200
   content-length: 18
   content-type: text/plain; charset=utf-8
   date: Wed, 26 Jul 2023 12:56:22 GMT
   server: istio-envoy
   x-envoy-upstream-service-time: 2856
   
   Hello Serverless!

4. 확인을 위해 생성된 리소스를 삭제합니다.

   $ oc delete deployment/curl -n team-alpha-1 && \
   oc delete ksvc/test-webapp -n team-alpha-1 && \
   oc delete ksvc/test-webapp -n team-bravo-1

프로세스

1. OpenShift Container Platform 웹 콘솔 개발자 화면에서 +추가 로 이동하여 Git에서 가져오기 옵션을 선택합니다.

   

2. Git에서 가져오기 대화 상자에서 다음을 수행하여 프로젝트 메타데이터를 지정합니다.

   • Git 리포지토리 URL을 지정합니다.
   • 필요한 경우 컨텍스트 디렉터리를 지정합니다. 이는 애플리케이션 소스 코드의 루트가 포함된 리포지토리 내부의 하위 디렉터리입니다.
   • 선택 사항: 애플리케이션 이름을 지정합니다. 기본적으로 리포지토리 이름이 사용됩니다.
   • Serverless Deployment 리소스 유형을 선택합니다.
   • 파이프라인 추가 확인란을 선택합니다. 파이프라인은 소스 코드를 기반으로 자동으로 선택되며 해당 시각화는 스키마에 표시됩니다.

   • 기타 관련 설정을 지정합니다.

     
3. 생성 을 클릭하여 서비스를 생성합니다.

4. 서비스 생성이 시작되면 토폴로지 화면으로 이동합니다. 여기서 서비스와 관련 트리거가 시각화되고 해당 트리거와 상호 작용할 수 있습니다.

   

5. 선택 사항: 파이프라인이 생성되고 파이프라인 페이지로 이동하여 서비스가 빌드되고 배포되었는지 확인합니다.

   

6. 파이프라인의 세부 정보를 보려면 파이프라인 페이지에서 파이프라인을 클릭합니다.

   

7. 현재 파이프라인 실행에 대한 세부 정보를 보려면 파이프라인 페이지에서 실행 이름을 클릭합니다.

   

프로세스

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