8.4. 경로 기반 배포 전략 사용

프로세스

1. 네트워킹 경로 페이지로 이동합니다.
2. 편집할 경로 옆에 있는 작업 메뉴 를 클릭하고 경로 편집을 선택합니다.
3. YAML 파일을 편집합니다. 다른 대상 참조 오브젝트에 대한 대상의 상대적 가중치를 지정하는 weight 값을 0에서 256 사이의 정수가 되도록 업데이트합니다. 값 0은 이 백엔드에 대한 요청을 비활성화합니다. 기본값은 100입니다. 옵션에 대한 자세한 내용을 보려면 oc explain routes.spec.alternateBackends를 실행합니다.
4. 저장을 클릭합니다.

1. 네트워킹 경로 페이지로 이동합니다.
2. 경로 생성을 클릭합니다.
3. 경로 이름을 입력합니다.
4. 서비스를 선택합니다.
5. 대체 서비스 추가를 클릭합니다.
6. 가중치 및 대체 서비스 가중치 값을 입력합니다. 다른 대상과 비교했을 때 상대적 가중치를 나타내는 0에서 255 사이의 숫자를 입력합니다. 기본값은 100입니다.
7. 대상 포트를 선택합니다.
8. Create를 클릭합니다.

프로세스

1. 경로에서 부하를 분산하는 서비스와 해당 가중치를 관리하려면 oc set route-backends 명령을 사용합니다.

   $ oc set route-backends ROUTENAME \
       [--zero|--equal] [--adjust] SERVICE=WEIGHT[%] [...] [options]

   예를 들어 다음 명령은 ab-example-a를 weight=198인 기본 서비스로 설정하고 ab-example-b는 weight=2인 첫 번째 대체 서비스로 설정합니다.

   $ oc set route-backends ab-example ab-example-a=198 ab-example-b=2

   즉 99%의 트래픽은 서비스 ab-example-a로 전송되고 1%는 서비스 ab-example-b로 전송됩니다.

   이 명령에서는 배포를 스케일링하지 않습니다. 요청 부하를 처리할 수 있는 Pod를 충분히 확보하기 위해서는 스케일링해야 할 수 있습니다.

2. 플래그 없이 명령을 실행하여 현재 구성을 확인합니다.

   $ oc set route-backends ab-example

   출력 예

   NAME                    KIND     TO           WEIGHT
   routes/ab-example       Service  ab-example-a 198 (99%)
   routes/ab-example       Service  ab-example-b 2   (1%)

3. 자체 또는 기본 서비스에 대한 개별 서비스의 가중치를 변경하려면 --adjust 플래그를 사용합니다. 백분율을 지정하면 기본 또는 첫 번째 대체(기본을 지정하는 경우)를 기준으로 서비스가 조정됩니다. 다른 백엔드가 있는 경우 해당 가중치는 변경된 값에 비례하여 유지됩니다.

   다음 예제에서는 ab-example-a 및 ab-example-b 서비스의 가중치를 변경합니다.

   $ oc set route-backends ab-example --adjust ab-example-a=200 ab-example-b=10

   또는 백분율을 지정하여 서비스 가중치를 변경합니다.

   $ oc set route-backends ab-example --adjust ab-example-b=5%

   백분율 선언 앞에 +를 지정하면 현재 설정을 기준으로 가중치를 조정할 수 있습니다. 예를 들면 다음과 같습니다.

   $ oc set route-backends ab-example --adjust ab-example-b=+15%

   --equal 플래그는 모든 서비스의 weight를 100으로 설정합니다.

   $ oc set route-backends ab-example --equal

   --zero 플래그는 모든 서비스의 weight를 0으로 설정합니다. 그러면 모든 요청에서 503 오류가 반환됩니다.

   참고

   일부 라우터에서는 다중 또는 가중치 적용 백엔드를 지원하지 않습니다.

절차

1. 새 애플리케이션을 생성하여 모든 shard에 공통된 라벨 ab-example=true를 추가합니다.

   $ oc new-app openshift/deployment-example --name=ab-example-a --as-deployment-config=true --labels=ab-example=true --env=SUBTITLE\=shardA
   $ oc delete svc/ab-example-a

   애플리케이션이 배포되고 서비스가 생성됩니다. 이것이 첫 번째 shard입니다.

2. 경로를 통해 애플리케이션을 사용 가능하게 하거나 서비스 IP를 직접 사용합니다.

   $ oc expose deployment ab-example-a --name=ab-example --selector=ab-example\=true
   $ oc expose service ab-example

3. ab-example-<project_name>.<router_domain>에서 애플리케이션을 검색하여 v1 이미지가 표시되는지 확인합니다.

4. 첫 번째 shard와 동일한 소스 이미지 및 라벨을 기반으로 하지만 태그 버전이 다르고 환경 변수가 고유한 두 번째 shard를 생성합니다.

   $ oc new-app openshift/deployment-example:v2 \
       --name=ab-example-b --labels=ab-example=true \
       SUBTITLE="shard B" COLOR="red" --as-deployment-config=true
   $ oc delete svc/ab-example-b

5. 이 시점에 두 Pod 세트 모두 경로에 제공됩니다. 그러나 두 브라우저(연결을 열린 상태로 유지하여) 및 라우터(기본적으로 쿠키를 통해)에서 백엔드 서버에 대한 연결을 유지하려고 하기 때문에 두 shard가 반환되지 않을 수 있습니다.

   브라우저를 하나 또는 다른 shard에 강제 적용하려면 다음을 수행합니다.

   1. oc scale 명령을 사용하여 ab-example-a의 복제본 수를 0으로 줄입니다.

      $ oc scale dc/ab-example-a --replicas=0

      브라우저를 새로고침하여 v2 및 shard B(빨간색)를 표시합니다.

   2. ab-example-a를 복제본 수 1로, ab-example-b를 0으로 스케일링합니다.

      $ oc scale dc/ab-example-a --replicas=1; oc scale dc/ab-example-b --replicas=0

      브라우저를 새로고침하여 v1 및 shard A(파란색)를 표시합니다.

6. 둘 중 하나의 shard에서 배포를 트리거하면 해당 shard의 Pod만 영향을 받습니다. Deployment 오브젝트에서 SUBTITLE 환경 변수를 변경하여 배포를 트리거할 수 있습니다.

   $ oc edit dc/ab-example-a

   또는

   $ oc edit dc/ab-example-b