9장. 통합
9.1. OpenShift Serverless와 Service Mesh 통합
OpenShift Serverless Operator는 Kourier를 Knative의 기본 수신으로 제공합니다. 그러나 Kourier가 활성화되어 있는지 여부에 관계없이 OpenShift Serverless에서 Service Mesh를 사용할 수 있습니다. Kourier disabled와 통합하면 mTLS 기능과 같이 Kourier 인그레스에서 지원하지 않는 추가 네트워킹 및 라우팅 옵션을 구성할 수 있습니다.
OpenShift Serverless는 본 안내서에 명시되어 있는 Red Hat OpenShift Service Mesh 기능만 지원하며 문서화되지 않은 다른 기능은 지원하지 않습니다.
9.1.1. 사전 요구 사항
다음 절차의 예제에서는 도메인
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 설명서를 참조하십시오.
9.1.2. 수신 외부 트래픽을 암호화하기 위한 인증서 생성
기본적으로 Service Mesh mTLS 기능은 사이드카가 있는 수신 게이트웨이와 개별 Pod 간에 Service Mesh 자체의 트래픽만 보호합니다. OpenShift Container Platform 클러스터로 전달될 때 트래픽을 암호화하려면 OpenShift Serverless 및 Service Mesh 통합을 활성화하기 전에 인증서를 생성해야 합니다.
사전 요구 사항
- 클러스터 관리자 액세스 권한이 있는 OpenShift Container Platform 계정에 액세스할 수 있습니다.
- OpenShift Serverless Operator 및 Knative Serving이 설치되어 있습니다.
-
OpenShift CLI(
oc
)를 설치합니다. - 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
절차
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
와일드카드 인증서를 만듭니다.
$ openssl req -nodes -newkey rsa:2048 \ -subj "/CN=*.apps.openshift.example.com/O=Example Inc." \ -keyout wildcard.key \ -out wildcard.csr
와일드카드 인증서를 서명합니다.
$ openssl x509 -req -days 365 -set_serial 0 \ -CA root.crt \ -CAkey root.key \ -in wildcard.csr \ -out wildcard.crt
와일드카드 인증서를 사용하여 시크릿을 생성합니다.
$ oc create -n istio-system secret tls wildcard-certs \ --key=wildcard.key \ --cert=wildcard.crt
이 인증서는 OpenShift Serverless를 Service Mesh와 통합할 때 생성된 게이트웨이에서 선택하여 수신 게이트웨이가 이 인증서와 트래픽을 제공하도록 합니다.
9.1.3. OpenShift Serverless와 Service Mesh 통합
Kourier를 기본 수신으로 사용하지 않고 OpenShift Serverless와 Service Mesh를 통합할 수 있습니다. 이렇게 하려면 다음 절차를 완료하기 전에 Knative Serving 구성 요소를 설치하지 마십시오. 일반 Knative Serving 설치 절차에서는 Knative Serving을 Service Mesh와 통합하기 위해 KnativeServing
CRD(사용자 정의 리소스 정의)를 생성할 때 추가 단계가 필요합니다. 이 절차는 Service Mesh를 기본값으로 통합하고 OpenShift Serverless 설치에만 수신하려는 경우에 유용할 수 있습니다.
사전 요구 사항
- 클러스터 관리자 액세스 권한이 있는 OpenShift Container Platform 계정에 액세스할 수 있습니다.
- 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
Red Hat OpenShift Service Mesh Operator를 설치하고
istio-system
네임스페이스에ServiceMeshControlPlane
리소스를 생성합니다. mTLS 기능을 사용하려면ServiceMeshControlPlane
리소스의spec.security.dataPlane.mtls
필드도true
로 설정해야 합니다.중요Service Mesh에서 OpenShift Serverless 사용은 Red Hat OpenShift Service Mesh 버전 2.0.5 이상에서만 지원됩니다.
- OpenShift Serverless Operator를 설치합니다.
-
OpenShift CLI(
oc
)를 설치합니다.
절차
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
네임스페이스가 포함되어야 합니다.ServiceMeshMemberRoll
리소스를 적용합니다.$ oc apply -f <filename>
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
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>
Gateway
리소스를 적용합니다.$ oc apply -f <filename>
다음
KnativeServing
CRD(사용자 정의 리소스 정의)를 생성하여 Knative Serving을 설치하여 Istio 통합을 활성화합니다.apiVersion: operator.knative.dev/v1beta1 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"
KnativeServing
리소스를 적용합니다.$ oc apply -f <filename>
사이드카 삽입이 활성화되고 패스쓰루(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>
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!
9.1.4. mTLS를 사용하여 서비스 메시를 사용할 때 Knative Serving 지표 활성화
mTLS를 사용하여 서비스 메시를 활성화하면 서비스 메시가 Prometheus가 메트릭을 스크랩하지 못하므로 Knative Serving에 대한 지표가 기본적으로 비활성화됩니다. 이 섹션에서는 서비스 메시 및 mTLS를 사용할 때 Knative Serving 지표를 활성화하는 방법을 보여줍니다.
사전 요구 사항
- 클러스터에 OpenShift Serverless Operator 및 Knative Serving이 설치되어 있습니다.
- mTLS 기능이 활성화된 Red Hat OpenShift Service Mesh를 설치했습니다.
- 클러스터 관리자 액세스 권한이 있는 OpenShift Container Platform 계정에 액세스할 수 있습니다.
-
OpenShift CLI(
oc
)를 설치합니다. - 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
절차
Knative Serving 사용자 정의 리소스(CR)의
observability
사양에서prometheus
를metrics.backend-destination
으로 지정합니다.apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving spec: config: observability: metrics.backend-destination: "prometheus" ...
이 단계에서는 메트릭이 기본적으로 비활성화되지 않습니다.
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: {} ...
다음 사양을 포함하도록
istio-system
네임스페이스에서 기본 서비스 메시 컨트롤 플레인을 수정하고 다시 적용합니다.... spec: proxy: networking: trafficControl: inbound: excludedPorts: - 8444 ...
9.1.5. Kourier가 활성화된 경우 OpenShift Serverless와 Service Mesh 통합
Kourier가 이미 활성화된 경우에도 OpenShift Serverless에서 Service Mesh를 사용할 수 있습니다. 이 절차는 Kourier를 사용하여 Knative Serving을 이미 설치했지만 나중에 서비스 메시 통합을 추가하려는 경우 유용할 수 있습니다.
사전 요구 사항
- 클러스터 관리자 액세스 권한이 있는 OpenShift Container Platform 계정에 액세스할 수 있습니다.
- 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
-
OpenShift CLI(
oc
)를 설치합니다. - 클러스터에 OpenShift Serverless Operator 및 Knative Serving을 설치합니다.
- Red Hat OpenShift Service Mesh를 설치합니다. OpenShift Serverless with Service Mesh and Kourier는 Red Hat OpenShift Service Mesh 버전 1.x 및 2.x에서 모두 사용이 지원되고 있습니다.
절차
Service Mesh와 통합할 네임스페이스를
ServiceMeshMemberRoll
오브젝트에 멤버로 추가합니다.apiVersion: maistra.io/v1 kind: ServiceMeshMemberRoll metadata: name: default namespace: istio-system spec: members: - <namespace> 1 ...
- 1
- Service Mesh와 통합할 네임스페이스 목록입니다.
ServiceMeshMemberRoll
리소스를 적용합니다.$ oc apply -f <filename>
Knative 시스템 Pod에서 Knative 서비스로의 트래픽 흐름을 허용하는 네트워크 정책을 생성합니다.
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: knative.openshift.io/part-of: "openshift-serverless" podSelector: {} policyTypes: - Ingress ...
- 1
- Service Mesh와 통합할 네임스페이스를 추가합니다.
참고knative.openshift.io/part-of: "openshift-serverless"
레이블이 OpenShift Serverless 1.22.0에 추가되었습니다. OpenShift Serverless 1.21.1 이하를 사용하는 경우knative.openshift.io/part-of
레이블을knative-serving
및knative-serving-ingress
네임스페이스에 추가합니다.knative-serving
네임스페이스에 라벨을 추가합니다.$ oc label namespace knative-serving knative.openshift.io/part-of=openshift-serverless
knative-serving-ingress
네임스페이스에 레이블을 추가합니다.$ oc label namespace knative-serving-ingress knative.openshift.io/part-of=openshift-serverless
NetworkPolicy
리소스를 적용합니다.$ oc apply -f <filename>
9.1.6. Service Mesh에 대한 시크릿 필터링을 사용하여 메모리 사용량 개선
기본적으로 Kubernetes 클라이언트-go
라이브러리에 대한 정보자 구현에서는 특정 유형의 모든 리소스를 가져옵니다. 이로 인해 많은 리소스를 사용할 수 있을 때 상당한 오버헤드가 발생하여 메모리 누수로 인해 Knative net-istio
Ingress 컨트롤러가 대규모 클러스터에서 실패할 수 있습니다. 그러나 컨트롤러가 Knative 관련 보안만 가져올 수 있도록 Knative net-istio
수신 컨트롤러에서 필터링 메커니즘을 사용할 수 있습니다. KnativeServing
사용자 정의 리소스(CR)에 주석을 추가하여 이 메커니즘을 활성화할 수 있습니다.
사전 요구 사항
- 클러스터 관리자 액세스 권한이 있는 OpenShift Container Platform 계정에 액세스할 수 있습니다.
- 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
- Red Hat OpenShift Service Mesh를 설치합니다. OpenShift Serverless with Service Mesh는 Red Hat OpenShift Service Mesh 버전 2.0.5 이상에서만 지원됩니다.
- OpenShift Serverless Operator 및 Knative Serving을 설치합니다.
-
OpenShift CLI(
oc
)를 설치합니다.
절차
KnativeServing
CR에serverless.openshift.io/enable-secret-informer-filtering
주석을 추가합니다.KnativeServing CR의 예
apiVersion: operator.knative.dev/v1beta1 kind: KnativeServing metadata: name: knative-serving namespace: knative-serving annotations: serverless.openshift.io/enable-secret-informer-filtering: "true" 1 spec: ingress: istio: enabled: true deployments: - annotations: sidecar.istio.io/inject: "true" sidecar.istio.io/rewriteAppHTTPProbers: "true" name: activator - annotations: sidecar.istio.io/inject: "true" sidecar.istio.io/rewriteAppHTTPProbers: "true" name: autoscaler
- 1
- 이 주석을 추가하면 환경 변수
ENABLE_SECRET_INFORMER_FILTERING_BY_CERT_UID=true
.