7.4. 경로 기반 배포 전략 사용
				배포 전략에서는 애플리케이션을 개발하는 방식을 제공합니다. 일부 전략에서는 Deployment 오브젝트를 사용하여 애플리케이션으로 확인되는 모든 경로의 사용자가 표시되는 변경을 수행합니다. 이 섹션에 설명된 것과 같은 기타 고급 전략에서는 Deployment 오브젝트와 함께 라우터 기능을 사용하여 특정 경로에 영향을 미칩니다.
			
가장 일반적인 경로 기반 전략은 Blue-Green 배포를 사용하는 것입니다. 테스트 및 평가를 위해 새 버전(Green 버전)이 제공되지만 사용자는 여전히 안정적인 버전(Blue 버전)을 사용합니다. 사용자는 준비가 되면 Green 버전으로 전환합니다. 문제가 발생하면 Blue 버전으로 다시 전환할 수 있습니다.
또는 두 버전이 동시에 활성화되는 A/B 버전 전략을 사용할 수 있습니다. 이 전략을 사용하면 일부 사용자는 버전 A 를 사용할 수 있으며 다른 사용자는 버전 B 를 사용할 수 있습니다. 이 전략을 사용하여 사용자 인터페이스 변경 또는 기타 기능을 실험하여 사용자 피드백을 받을 수 있습니다. 또한 문제가 제한된 수의 사용자에게 영향을 미치는 프로덕션 컨텍스트에서 적절한 작업을 확인하는 데 사용할 수도 있습니다.
카나리아 배포는 새 버전을 테스트하지만 문제가 발견되면 신속하게 이전 버전으로 대체합니다. 이는 위의 두 전략 모두에서 수행할 수 있습니다.
경로 기반 배포 전략에서는 서비스의 Pod 수를 확장하지 않습니다. 원하는 성능 특성을 유지 관리하려면 배포 구성을 확장해야 할 수 있습니다.
7.4.1. 프록시 shard 및 트래픽 분할
프로덕션 환경에서는 특정 shard에 전달되는 트래픽 분배를 정확하게 제어할 수 있습니다. 많은 수의 인스턴스를 처리할 때는 개별 shard의 상대적 스케일을 사용하여 백분율 기반 트래픽을 구현할 수 있습니다. 이는 수신하는 트래픽을 다른 곳에서 실행되는 별도의 서비스 또는 애플리케이션으로 전달하거나 분할하는 프록시 shard와 잘 결합합니다.
가장 간단한 구성에서 프록시는 변경되지 않은 요청을 전달합니다. 더 복잡한 설정에서는 들어오는 요청을 복제하여 애플리케이션의 로컬 인스턴스와 별도의 클러스터에 보내 결과를 비교할 수 있습니다. 기타 패턴에는 DR 설치 캐시를 준비 상태로 유지하거나 분석을 위해 들어오는 트래픽을 샘플링하는 작업이 포함됩니다.
					모든 TCP(또는 UDP) 프록시는 원하는 shard에서 실행할 수 있습니다. oc scale 명령을 사용하여 프록시 shard에서 요청을 처리하는 상대적 인스턴스 수를 변경합니다. 더 복잡한 트래픽 관리에는 비례 분산 기능을 사용하여 OpenShift Container Platform 라우터를 사용자 정의하는 것이 좋습니다.
				
7.4.2. N-1 호환성
새 코드와 이전 코드가 동시에 포함된 애플리케이션에서는 새 코드에서 작성한 데이터를 이전 버전의 코드에서 읽고 처리(또는 정상적으로 무시)할 수 있도록 주의해야 합니다. 이는 스키마 진화라고도 하며 복잡한 문제에 해당합니다.
디스크, 데이터베이스, 임시 캐시에 저장된 데이터 또는 사용자 브라우저 세션의 일부 등 다양한 형태를 취할 수 있습니다. 대부분의 웹 애플리케이션에서는 롤링 배포를 지원할 수 있지만 이를 처리할 수 있도록 애플리케이션을 테스트하고 설계하는 것이 중요합니다.
일부 애플리케이션의 경우 이전 코드와 새 코드가 나란히 실행되는 기간이 짧기 때문에 버그 또는 일부 실패한 사용자 트랜잭션이 허용됩니다. 다른 애플리케이션의 경우 실패 패턴으로 인해 전체 애플리케이션이 작동하지 않을 수 있습니다.
N-1 호환성을 검증하는 한 가지 방법은 A/B 배포를 사용하는 것입니다. 즉 테스트 환경에서 제어되는 방식으로 이전 코드와 새 코드를 동시에 실행한 후 새 배포로 이동하는 트래픽으로 인해 이전 배포가 실패하지 않는지 확인하는 것입니다.
7.4.3. 정상적인 종료
OpenShift Container Platform 및 Kubernetes는 부하 분산 순환 작업에서 애플리케이션 인스턴스를 제거하기 전에 종료할 시간을 제공합니다. 그러나 애플리케이션은 종료하기 전에 사용자 연결을 명확하게 종료해야 합니다.
					종료 시 OpenShift Container Platform은 컨테이너의 프로세스에 TERM 신호를 보냅니다. 애플리케이션 코드는 SIGTERM을 수신하면 새 연결을 허용하지 않습니다. 이로 인해 로드 밸런서에서 트래픽을 활성 상태의 다른 인스턴스로 라우팅합니다. 그러면 애플리케이션 코드는 열려 있는 모든 연결이 닫힐 때까지 기다리거나 종료되기 전 다음 기회에 개별 연결을 정상적으로 종료합니다.
				
					정상 종료 기간이 만료된 후 종료되지 않은 프로세스에는 KILL 신호가 전송되어 프로세스가 즉시 종료됩니다. Pod 또는 Pod 템플릿의 terminationGracePeriodSeconds 속성은 정상 종료 기간(기본값 30초)을 제어하고 필요에 따라 애플리케이션별로 사용자 지정할 수 있습니다.
				
7.4.4. Blue-Green 배포
Blue-Green 배포에는 두 가지 버전의 애플리케이션을 동시에 실행하고 프로덕션 내 버전(Blue 버전)에서 최신 버전(Green 버전)으로 트래픽을 이동하는 작업이 포함됩니다. 롤링 전략 또는 전환 서비스를 경로에서 사용할 수 있습니다.
대다수의 애플리케이션이 영구 데이터에 의존하기 때문에 N-1 호환성을 지원하는 애플리케이션이 있어야 합니다. 그러면 데이터 계층 복사본을 두 개 생성하여 데이터를 공유하고 데이터베이스, 저장소 또는 디스크 간 실시간 마이그레이션을 구현할 수 있습니다.
새 버전을 테스트하는 데 사용되는 데이터를 떠올려 보십시오. 데이터가 프로덕션 데이터라면 새 버전의 버그로 인해 프로덕션 버전에 장애가 발생할 수 있습니다.
7.4.4.1. Blue-Green 배포 설정
						Blue-Green 배포에서는 두 개의 Deployment 오브젝트를 사용합니다. 둘 다 실행 중이고 프로덕션 중 하나는 경로에서 지정하는 서비스에 따라 달라지며 각 Deployment 오브젝트는 다른 서비스에 노출됩니다.
					
경로는 웹(HTTP 및 HTTPS) 트래픽을 위한 것이므로 이 기술은 웹 애플리케이션에 적합합니다.
새 버전의 새 경로를 생성하고 테스트할 수 있습니다. 준비되었을 때 새 서비스를 가리키도록 프로덕션 경로의 서비스를 변경하면 새(Green) 버전이 활성화됩니다.
필요한 경우 서비스를 이전 버전(Blue)으로 전환하여 롤백할 수 있습니다.
프로세스
- 독립된 애플리케이션 구성 요소 두 개를 생성합니다. - example-blue서비스에서- v1이미지를 실행하는 예제 애플리케이션의 복사본을 생성합니다.- oc new-app openshift/deployment-example:v1 --name=example-blue - $ oc new-app openshift/deployment-example:v1 --name=example-blue- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- example-green서비스에서- v2이미지를 사용하는 두 번째 복사본을 생성합니다.- oc new-app openshift/deployment-example:v2 --name=example-green - $ oc new-app openshift/deployment-example:v2 --name=example-green- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
 
- 이전 서비스를 가리키는 경로를 생성합니다. - oc expose svc/example-blue --name=bluegreen-example - $ oc expose svc/example-blue --name=bluegreen-example- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 
								bluegreen-example-<project>.<router_domain>에서 애플리케이션을 검색하여v1이미지가 표시되는지 확인합니다.
- 경로를 편집하고 서비스 이름을 - example-green으로 변경합니다.- oc patch route/bluegreen-example -p '{"spec":{"to":{"name":"example-green"}}}'- $ oc patch route/bluegreen-example -p '{"spec":{"to":{"name":"example-green"}}}'- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 
								경로가 변경되었는지 확인하려면 v2이미지가 표시될 때까지 브라우저를 새로 고칩니다.
7.4.5. A/B 배포
A/B 배포 전략을 사용하면 프로덕션 환경에서 제한된 방식으로 새 버전의 애플리케이션을 시도할 수 있습니다. 프로덕션 버전에서 대부분의 사용자 요청을 가져오고 제한된 요청만 새 버전으로 이동하도록 지정할 수 있습니다.
각 버전에 대한 요청 분배를 사용자가 제어하므로 테스트를 진행하면서 새 버전에 대한 요청 비율을 늘려 결국 이전 버전의 사용을 중지할 수 있습니다. 각 버전에 대한 요청 부하를 조정할 때 필요한 성능을 제공하기 위해 각 서비스의 Pod 수도 스케일링해야 할 수 있습니다.
소프트웨어 업그레이드 외에도 이 기능을 사용하여 사용자 인터페이스의 버전을 실험할 수 있습니다. 일부 사용자는 이전 버전을 보유하고 있고 일부는 새 버전을 보유하고 있기 때문에 다양한 버전에 대한 사용자의 반응을 평가하여 설계 결정을 알릴 수 있습니다.
이 배포가 효과적이려면 이전 버전과 새 버전이 동시에 실행될 수 있을 정도로 충분히 유사해야 합니다. 버그 수정 릴리즈 및 새 기능이 이전 기능을 방해하지 않는 경우 일반적으로 사용됩니다. 버전이 제대로 작동하려면 N-1 호환성이 필요합니다.
OpenShift Container Platform은 웹 콘솔과 CLI를 통해 N-1 호환성을 지원합니다.
7.4.5.1. A/B 테스트의 부하 분산
사용자는 다양한 서비스를 통해 경로를 설정합니다. 각 서비스는 애플리케이션의 버전을 처리합니다.
						각 서비스에는 weight가 할당되고 각 서비스에 대한 일부 요청에는 service_weight을 sum_of_weights으로 나눈 값이 할당됩니다. 각 서비스의 weight는 서비스 끝점에 분배되므로 끝점 가중치의 합계는 서비스 weight입니다.
					
						이 경로는 최대 4개의 서비스를 제공할 수 있습니다. 서비스 weight는 0~256 사이일 수 있습니다. weight 가 0 이면 서비스는 부하 분산에 참여하지 않지만 기존 영구 연결을 계속 제공합니다. 서비스 weight가 0이 아닌 경우 각 끝점의 최소 weight는 1입니다. 이로 인해 끝점이 많은 서비스는 weight가 의도한 것보다 높을 수 있습니다. 이 경우 Pod 수를 줄이면 예상되는 부하 분산 weight를 얻을 수 있습니다.
					
프로세스
A/B 환경을 설정하려면 다음을 수행합니다.
- 애플리케이션 두 개를 생성하고 서로 다른 이름을 지정합니다. 각각 - Deployment오브젝트를 생성합니다. 두 애플리케이션은 동일한 프로그램의 버전에 해당합니다. 하나는 일반적으로 현재 프로덕션 버전이며 다른 하나는 제안된 새 버전입니다.- 첫 번째 애플리케이션을 생성합니다. 다음 예제에서는 - ab-example-a라는 애플리케이션을 생성합니다.- oc new-app openshift/deployment-example --name=ab-example-a - $ oc new-app openshift/deployment-example --name=ab-example-a- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 두 번째 애플리케이션을 생성합니다. - oc new-app openshift/deployment-example:v2 --name=ab-example-b - $ oc new-app openshift/deployment-example:v2 --name=ab-example-b- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 두 애플리케이션 모두 배포되고 서비스가 생성됩니다. 
 
- 경로를 통해 외부에서 애플리케이션을 사용할 수 있도록 설정합니다. 이 시점에서는 둘 중 하나를 노출할 수 있습니다. 현재 프로덕션 버전을 먼저 노출하고 나중에 경로를 수정하여 새 버전을 추가하는 것이 편리합니다. - oc expose svc/ab-example-a - $ oc expose svc/ab-example-a- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - ab-example-a.<project>.<router_domain>에서 애플리케이션을 검색하여 예상 버전이 표시되는지 확인합니다.
- 경로를 배포할 때 라우터는 서비스에 지정된 - weights에 따라 트래픽을 분산합니다. 이 시점에는 기본값이- weight=1인 단일 서비스가 있으므로 모든 요청이 해당 서비스로 이동합니다. 기타 서비스를- alternateBackends로 추가하고- weights를 조정하면 A/B 설정이 활성화됩니다. 이 작업은- oc set route-backends명령을 실행하거나 경로를 편집하여 수행할 수 있습니다.참고- alternateBackends를 사용하는 경우- roundrobin로드 밸런싱 전략을 사용하여 요청이 가중치를 기반으로 서비스에 예상대로 배포되도록 합니다. 경로 주석을 사용하여 경로에- roundrobin을 설정할 수 있습니다. 경로 주석에 대한 자세한 내용은 추가 리소스 섹션을 참조하십시오.- oc set route-backend를- 0으로 설정하면 서비스가 부하 분산에 참여하지 않지만 기존 영구 연결을 계속 제공합니다.참고- 경로를 변경하면 다양한 서비스에 대한 트래픽 부분만 변경됩니다. 예상되는 부하를 처리하기 위해 Pod 수를 조정하려면 배포를 스케일링해야 할 수 있습니다. - 경로를 편집하려면 다음을 실행합니다. - oc edit route <route_name> - $ oc edit route <route_name>- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 출력 예 - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
7.4.5.1.1. 웹 콘솔을 사용하여 기존 경로의 가중치 관리
프로세스
- 
									네트워킹 경로 페이지로 이동합니다. 
- 
									편집할 경로 옆에 있는 작업 메뉴 
									 를 클릭하고 경로 편집을 선택합니다. 를 클릭하고 경로 편집을 선택합니다.
- 
									YAML 파일을 편집합니다. 다른 대상 참조 오브젝트에 대한 대상의 상대적 가중치를 지정하는 weight값을0에서256사이의 정수가 되도록 업데이트합니다. 값0은 이 백엔드에 대한 요청을 비활성화합니다. 기본값은100입니다. 옵션에 대한 자세한 내용을 보려면oc explain routes.spec.alternateBackends를 실행합니다.
- 저장을 클릭합니다.
7.4.5.1.2. 웹 콘솔을 사용하여 새 경로의 가중치 관리
- 
									네트워킹 경로 페이지로 이동합니다. 
- 경로 생성을 클릭합니다.
- 경로 이름을 입력합니다.
- 서비스를 선택합니다.
- 대체 서비스 추가를 클릭합니다.
- 
									가중치 및 대체 서비스 가중치 값을 입력합니다. 다른 대상과 비교했을 때 상대적 가중치를 나타내는 0에서255사이의 숫자를 입력합니다. 기본값은100입니다.
- 대상 포트를 선택합니다.
- Create를 클릭합니다.
7.4.5.1.3. CLI를 사용하여 가중치 관리
프로세스
- 경로에서 부하를 분산하는 서비스와 해당 가중치를 관리하려면 - oc set route-backends명령을 사용합니다.- oc set route-backends ROUTENAME \ [--zero|--equal] [--adjust] SERVICE=WEIGHT[%] [...] [options]- $ oc set route-backends ROUTENAME \ [--zero|--equal] [--adjust] SERVICE=WEIGHT[%] [...] [options]- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 예를 들어 다음 명령은 - ab-example-a를- weight=198인 기본 서비스로 설정하고- ab-example-b는- weight=2인 첫 번째 대체 서비스로 설정합니다.- oc set route-backends ab-example ab-example-a=198 ab-example-b=2 - $ oc set route-backends ab-example ab-example-a=198 ab-example-b=2- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 즉 99%의 트래픽은 서비스 - ab-example-a로 전송되고 1%는 서비스- ab-example-b로 전송됩니다.- 이 명령에서는 배포를 스케일링하지 않습니다. 요청 부하를 처리할 수 있는 Pod를 충분히 확보하기 위해서는 스케일링해야 할 수 있습니다. 
- 플래그 없이 명령을 실행하여 현재 구성을 확인합니다. - oc set route-backends ab-example - $ oc set route-backends ab-example- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 출력 예 - NAME KIND TO WEIGHT routes/ab-example Service ab-example-a 198 (99%) routes/ab-example Service ab-example-b 2 (1%) - NAME KIND TO WEIGHT routes/ab-example Service ab-example-a 198 (99%) routes/ab-example Service ab-example-b 2 (1%)- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 로드 밸런싱 알고리즘의 기본값을 재정의하려면 알고리즘을 - roundrobin으로 설정하여 경로의 주석을 조정합니다. OpenShift Container Platform의 경로의 경우 기본 로드 밸런싱 알고리즘은- random또는- source값으로 설정됩니다.- 알고리즘을 - roundrobin으로 설정하려면 다음 명령을 실행합니다.- oc annotate routes/<route-name> haproxy.router.openshift.io/balance=roundrobin - $ oc annotate routes/<route-name> haproxy.router.openshift.io/balance=roundrobin- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - TLS(Transport Layer Security) 패스스루 경로의 경우 기본값은 - source입니다. 다른 모든 경로의 경우 기본값은- random입니다.
- 자체 또는 기본 서비스에 대한 개별 서비스의 가중치를 변경하려면 - --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-a=200 ab-example-b=10- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 또는 백분율을 지정하여 서비스 가중치를 변경합니다. - oc set route-backends ab-example --adjust ab-example-b=5% - $ oc set route-backends ab-example --adjust ab-example-b=5%- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 백분율 선언 앞에 - +를 지정하면 현재 설정을 기준으로 가중치를 조정할 수 있습니다. 예를 들면 다음과 같습니다.- oc set route-backends ab-example --adjust ab-example-b=+15% - $ oc set route-backends ab-example --adjust ab-example-b=+15%- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - --equal플래그는 모든 서비스의- weight를- 100으로 설정합니다.- oc set route-backends ab-example --equal - $ oc set route-backends ab-example --equal- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - --zero플래그는 모든 서비스의- weight를- 0으로 설정합니다. 그러면 모든 요청에서 503 오류가 반환됩니다.참고- 일부 라우터에서는 다중 또는 가중치 적용 백엔드를 지원하지 않습니다. 
7.4.5.1.4. 하나의 서비스, 여러 Deployment 오브젝트
프로세스
- 새 애플리케이션을 생성하여 모든 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 new-app openshift/deployment-example --name=ab-example-a --as-deployment-config=true --labels=ab-example=true --env=SUBTITLE\=shardA- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - oc delete svc/ab-example-a - $ oc delete svc/ab-example-a- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 애플리케이션이 배포되고 서비스가 생성됩니다. 이것이 첫 번째 shard입니다. 
- 경로를 통해 애플리케이션을 사용 가능하게 하거나 서비스 IP를 직접 사용합니다. - oc expose deployment ab-example-a --name=ab-example --selector=ab-example\=true - $ oc expose deployment ab-example-a --name=ab-example --selector=ab-example\=true- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - oc expose service ab-example - $ oc expose service ab-example- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 
									ab-example-<project_name>.<router_domain>에서 애플리케이션을 검색하여v1이미지가 표시되는지 확인합니다.
- 첫 번째 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 new-app openshift/deployment-example:v2 \ --name=ab-example-b --labels=ab-example=true \ SUBTITLE="shard B" COLOR="red" --as-deployment-config=true- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - oc delete svc/ab-example-b - $ oc delete svc/ab-example-b- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 이 시점에 두 Pod 세트 모두 경로에 제공됩니다. 그러나 두 브라우저(연결을 열린 상태로 유지하여) 및 라우터(기본적으로 쿠키를 통해)에서 백엔드 서버에 대한 연결을 유지하려고 하기 때문에 두 shard가 반환되지 않을 수 있습니다. - 브라우저를 하나 또는 다른 shard에 강제 적용하려면 다음을 수행합니다. - oc scale명령을 사용하여- ab-example-a의 복제본 수를- 0으로 줄입니다.- oc scale dc/ab-example-a --replicas=0 - $ oc scale dc/ab-example-a --replicas=0- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 브라우저를 새로고침하여 - v2및- shard B(빨간색)를 표시합니다.
- ab-example-a를 복제본 수- 1로,- ab-example-b를- 0으로 스케일링합니다.- oc scale dc/ab-example-a --replicas=1; oc scale dc/ab-example-b --replicas=0 - $ oc scale dc/ab-example-a --replicas=1; oc scale dc/ab-example-b --replicas=0- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 브라우저를 새로고침하여 - v1및- shard A(파란색)를 표시합니다.
 
- 둘 중 하나의 shard에서 배포를 트리거하면 해당 shard의 Pod만 영향을 받습니다. - Deployment오브젝트에서- SUBTITLE환경 변수를 변경하여 배포를 트리거할 수 있습니다.- oc edit dc/ab-example-a - $ oc edit dc/ab-example-a- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 또는 - oc edit dc/ab-example-b - $ oc edit dc/ab-example-b- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow