4.4. 트래픽 분할

4.4.1. 트래픽 분할 개요

Knative 애플리케이션에서 트래픽 분할을 생성하여 트래픽을 관리할 수 있습니다. 트래픽 분할은 Knative 서비스에서 관리하는 경로의 일부로 구성됩니다.

Knative 애플리케이션의 트래픽 관리

경로를 구성하면 요청을 다양한 버전의 서비스로 전송할 수 있습니다. 이 라우팅은 Service 오브젝트의 트래픽 사양에 따라 결정됩니다.

트래픽 사양 선언은 하나 이상의 버전으로 구성되며, 각각 전체 트래픽의 일부를 처리합니다. 각 버전으로 라우팅되는 트래픽의 백분율은 최대 100%를 추가해야 합니다. 이는 Knative 검증에 의해 확인됩니다.

트래픽 사양에 지정된 버전은 수정되거나 이름이 지정된 버전이거나 "latest" 버전을 가리킬 수 있으며, 이는 서비스의 모든 버전 목록의 헤드를 추적할 수 있습니다. 새 버전이 생성되는 경우 "latest" 버전은 업데이트하는 부동 참조 유형입니다. 각 버전에는 해당 버전의 추가 액세스 URL을 생성하는 태그가 연결될 수 있습니다.

트래픽 사양은 다음을 통해 수정할 수 있습니다.

  • Service 오브젝트의 YAML을 직접 편집합니다.
  • Knative(kn) CLI --traffic 플래그 사용.
  • OpenShift Container Platform 웹 콘솔 사용.

Knative 서비스를 생성할 때 기본 traffic 사양 설정이 없습니다.

4.4.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

다음 예에서는 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

다음 예제에서는 traffic 사양의 버전 목록을 확장하여 여러 버전으로 트래픽을 분할하는 방법을 보여줍니다. 이 예제에서는 50%의 트래픽을 현재 태그된 버전으로, 후보로 태그된 버전에 대한 트래픽의 50%를 보냅니다. 트래픽이 라우팅되지 않더라도 latest로 태그된 버전을 사용할 수 있습니다.

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

4.4.3. Knative CLI를 사용하여 트래픽 분할

Knative(kn) CLI를 사용하여 트래픽 분할을 생성하면 YAML 파일을 직접 수정하는 것보다 더 간소화되고 직관적인 사용자 인터페이스를 제공합니다. kn service update 명령을 사용하여 서비스 버전 간에 트래픽을 분할할 수 있습니다.

4.4.3.1. Knative CLI를 사용하여 트래픽 분할 생성

사전 요구 사항

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

절차

  • 표준 kn service update 명령과 함께 --traffic 태그를 사용하여 서비스 버전 및 라우팅할 트래픽의 백분율을 지정합니다.

    명령 예

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

    다음과 같습니다.

    • <service_name>은 트래픽 라우팅을 구성하려는 Knative 서비스의 이름입니다.
    • <revision>은 일정 비율의 트래픽을 수신하도록 구성하려는 버전입니다. 버전 이름 또는 --tag 플래그를 사용하여 버전에 할당한 태그를 지정할 수 있습니다.
    • < percentage>는 지정된 버전으로 보낼 트래픽의 백분율입니다.
  • 선택 사항: --traffic 플래그는 한 명령에 여러 번 지정할 수 있습니다. 예를 들어 @latest 로 태그된 리버전과 stable 이라는 버전이 있는 경우 다음과 같이 각 버전으로 분할하려는 트래픽 백분율을 지정할 수 있습니다.

    명령 예

    $ kn service update example-service --traffic @latest=20,stable=80

    버전이 여러 개 있고 마지막 버전으로 분할되어야 하는 트래픽 비율을 지정하지 않으면 --traffic 플래그는 이 값을 자동으로 계산할 수 있습니다. 예를 들어 이름이 . example 인 세 번째 버전이 있고 다음 명령을 사용합니다.

    명령 예

    $ kn service update example-service --traffic @latest=10,stable=60

    트래픽의 나머지 30%는 지정되지 않은 경우에도 예제 버전으로 분할됩니다.

4.4.4. 트래픽 분할을 위한 CLI 플래그

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

4.4.4.1. Knative CLI 트래픽 분할 플래그

다음 테이블에는 트래픽 분할 플래그, 값 형식, 플래그에서 수행하는 작업이 요약되어 있습니다. 반복 열은 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 제거

있음

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

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

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

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

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

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

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

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

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

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

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

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

참고

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

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

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

4.4.5. 버전 간 트래픽 분할

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

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

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

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Serving이 클러스터에 설치되어 있습니다.
  • OpenShift Container Platform 웹 콘솔에 로그인했습니다.

절차

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

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

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

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

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

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

      odc 서버리스 버전

4.4.6. Blue-Green 전략을 사용하여 트래픽 재실행

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

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

사전 요구 사항

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

절차

  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 환경 변수를 수정할 수 있습니다. 서비스 YAML 파일을 적용하거나 Knative(kn) CLI를 설치한 경우 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을 방문하여 이전 버전의 앱으로 더 이상 트래픽이 전송되지 않는지 확인합니다.