5.7. 클러스터 로컬 가용성


기본적으로 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 레이블을 사용하려면 기존 서비스를 업데이트해야 합니다.

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

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Serving이 클러스터에 설치되어 있습니다.
  • Knative 서비스가 생성되어 있습니다.

절차

  • 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.7.2. 클러스터 로컬 서비스에 대한 TLS 인증 활성화

클러스터 로컬 서비스의 경우 Kourier 로컬 게이트웨이 kourier-internal 가 사용됩니다. Kourier 로컬 게이트웨이에 대해 TLS 트래픽을 사용하려면 로컬 게이트웨이에서 고유한 서버 인증서를 구성해야 합니다.

사전 요구 사항

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

절차

  1. knative-serving-ingress 네임스페이스에 서버 인증서를 배포합니다.

    $ export san="knative"
    참고

    이러한 인증서가 < app_name>.<namespace>.svc.cluster.local 에 대한 요청을 제공할 수 있도록 주체 대체 이름(SAN) 검증이 필요합니다.

  2. 루트 키 및 인증서를 생성합니다.

    $ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 \
        -subj '/O=Example/CN=Example' \
        -keyout ca.key \
        -out ca.crt
  3. SAN 검증을 사용하는 서버 키를 생성합니다.

    $ openssl req -out tls.csr -newkey rsa:2048 -nodes -keyout tls.key \
      -subj "/CN=Example/O=Example" \
      -addext "subjectAltName = DNS:$san"
  4. 서버 인증서를 생성합니다.

    $ openssl x509 -req -extfile <(printf "subjectAltName=DNS:$san") \
      -days 365 -in tls.csr \
      -CA ca.crt -CAkey ca.key -CAcreateserial -out tls.crt
  5. Kourier 로컬 게이트웨이에 대한 시크릿을 구성합니다.

    1. 이전 단계에서 생성한 인증서에서 knative-serving-ingress 네임스페이스에 보안을 배포합니다.

      $ oc create -n knative-serving-ingress secret tls server-certs \
          --key=tls.key \
          --cert=tls.crt --dry-run=client -o yaml | oc apply -f -
    2. Kourier 게이트웨이에서 생성한 보안을 사용하도록 KnativeServing CR(사용자 정의 리소스) 사양을 업데이트합니다.

      KnativeServing CR의 예

      ...
      spec:
        config:
          kourier:
            cluster-cert-secret: server-certs
      ...

Kourier 컨트롤러는 서비스를 다시 시작하지 않고 인증서를 설정하므로 Pod를 다시 시작할 필요가 없습니다.

클라이언트에서 ca.crt 를 마운트하고 사용하여 포트 443 을 통해 TLS로 Kourier 내부 서비스에 액세스할 수 있습니다.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.