10.3. Knative 서비스의 사용자 정의 도메인 구성


Knative 서비스에는 클러스터 구성에 따라 기본 도메인 이름이 자동으로 할당됩니다. 예를 들면 &lt ;service_name>-<namespace>.example.com 입니다. 보유한 사용자 정의 도메인 이름을 Knative 서비스에 매핑하여 Knative 서비스의 도메인을 사용자 지정할 수 있습니다.

서비스에 대한 DomainMapping 리소스를 생성하여 이 작업을 수행할 수 있습니다. 또한 여러 개의 DomainMapping 리소스를 생성하여 여러 도메인에 매핑하고 하위 도메인을 단일 서비스에 매핑할 수도 있습니다.

10.3.1. 사용자 정의 도메인 매핑 생성

보유한 사용자 정의 도메인 이름을 Knative 서비스에 매핑하여 Knative 서비스의 도메인을 사용자 지정할 수 있습니다. 사용자 정의 도메인 이름을 CR(사용자 정의 리소스)에 매핑하려면 Knative 서비스 또는 Knative 경로와 같이 주소 지정 가능 대상 CR에 매핑하는 DomainMapping CR을 생성해야 합니다.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Serving이 클러스터에 설치되어 있습니다.
  • OpenShift CLI(oc)를 설치합니다.
  • 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
  • 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>

10.3.2. Knative CLI를 사용하여 사용자 정의 도메인 매핑 생성

보유한 사용자 정의 도메인 이름을 Knative 서비스에 매핑하여 Knative 서비스의 도메인을 사용자 지정할 수 있습니다. Knative(kn) CLI를 사용하여 Knative 서비스 또는 Knative 경로와 같이 주소 지정 가능 대상 CR에 매핑되는 DomainMapping CR(사용자 정의 리소스)을 생성할 수 있습니다.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Serving이 클러스터에 설치되어 있습니다.
  • Knative 서비스 또는 경로를 생성했으며 CR에 매핑할 사용자 정의 도메인을 제어할 수 있습니다.

    참고

    사용자 정의 도메인에서 OpenShift Container Platform 클러스터의 DNS를 가리켜야 합니다.

  • Knative(kn) CLI가 설치되어 있습니다.
  • 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.

절차

  • 현재 네임스페이스의 CR에 도메인을 매핑합니다.

    $ kn domain create <domain_mapping_name> --ref <target_name>

    명령 예

    $ kn domain create example.com --ref example-service

    --ref 플래그는 도메인 매핑을 위해 주소 지정 가능한 대상 CR을 지정합니다.

    --ref 플래그를 사용할 때 접두사가 지정되어 있지 않은 경우 대상이 현재 네임스페이스의 Knative 서비스라고 가정합니다.

  • 지정된 네임스페이스의 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

10.3.3. TLS 인증서를 사용하여 사용자 정의 도메인으로 서비스 보안

Knative 서비스의 사용자 정의 도메인을 구성한 후 TLS 인증서를 사용하여 매핑된 서비스를 보호할 수 있습니다. 이렇게 하려면 Kubernetes TLS 시크릿을 생성한 다음 생성한 TLS 시크릿을 사용하도록 DomainMapping CR을 업데이트해야 합니다.

참고

Ingress에 net-istio 를 사용하고 security.dataPlane.mtls: true 를 사용하여 SMCP를 통해 mTLS를 활성화하는 경우 Service Mesh는 OpenShift Serverless에 대한 DomainMapping 을 허용하지 않는 *.local 호스트에 대한 DestinationRule 을 배포합니다.

이 문제를 해결하려면 security.dataPlane.mtls: true 를 사용하는 대신 PeerAuthentication 을 배포하여 mTLS를 활성화합니다.

사전 요구 사항

  • Knative 서비스의 사용자 정의 도메인을 구성하고 작동 중인 DomainMapping CR이 있습니다.
  • 인증 기관 공급자 또는 자체 서명 인증서의 TLS 인증서가 있어야 합니다.
  • 인증 기관 공급자 또는 자체 서명된 인증서에서 인증서 파일을 획득했습니다.
  • OpenShift CLI(oc)를 설치합니다.

절차

  1. Kubernetes TLS 시크릿을 생성합니다.

    $ oc create secret tls <tls_secret_name> --cert=<path_to_certificate_file> --key=<path_to_key_file>
  2. Red Hat OpenShift Service Mesh를 OpenShift Serverless 설치의 수신으로 사용하는 경우 다음을 사용하여 Kubernetes TLS 시크릿에 레이블을 지정합니다.

    “networking.internal.knative.dev/certificate-uid": “<value>”

    cert-manager와 같은 타사 시크릿 공급자를 사용하는 경우, Kubernetes TLS 보안에 자동으로 레이블을 지정하도록 시크릿 관리자를 구성할 수 있습니다. cert-manager 사용자는 제공된 보안 템플릿을 사용하여 올바른 레이블이 있는 보안을 자동으로 생성할 수 있습니다. 이 경우 시크릿 필터링은 키를 기반으로만 수행되지만 이 값은 시크릿에 포함된 인증서 ID와 같은 유용한 정보를 제공할 수 있습니다.

    참고

    {cert-manager-operator}는 기술 프리뷰 기능입니다. 자세한 내용은 {cert-manager-operator} 설명서 설치를 참조하십시오.

  3. 생성한 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 플래그를 추가하여 확인을 건너뜁니다.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.