Kubernetes 배포

Kubernetes 배포를 사용해야하는 이유

다른 기사에서는 Kubernetes ReplicaSet에 대해 설명 했습니다. 그러나 ReplicaSets 에는 한 가지 큰 단점이 있습니다. ReplicaSet에서 관리 하는 포드 를 선택하면 해당 포드 템플릿을 변경할 수 없습니다. 예를 들어 ReplicaJ를 사용하여 NodeJS가 실행중인 4 개의 포드를 배포하고 NodeJS 이미지를 최신 버전으로 변경하려는 경우 ReplicaSet을 삭제하고 다시 작성해야합니다. 포드를 다시 시작하면 이미지를 사용할 수 있고 포드가 다시 실행될 때까지 다운 타임이 발생합니다.

배포 리소스는 ReplicaSet을 사용하여 포드를 관리합니다. 그러나 제어 된 방식으로 업데이트를 처리합니다. 배포 컨트롤러 및 패턴에 대해 자세히 알아 보겠습니다 .

첫 배포

Kubernetes Deployments가 수행 할 수있는 작업에 대한 간단한 데모를 보도록하겠습니다. 다음 배포 정의는 Apache를 호스팅 된 응용 프로그램으로 사용하여 4 개의 포드를 배포합니다.

apiVersion: apps/v1 kind: Deployment metadata: name: apache-deployment labels: role: webserver spec: replicas: 4 selector: matchLabels: role: webserver template: metadata: labels: role: webserver spec: containers: - name: frontend image: httpd ports: - containerPort: 80

부

위의 내용을 파일로 저장하십시오. 이 예에서는 파일 이름을 apache_deployment.yaml로 지정했습니다. 다음 명령을 실행하여 클러스터에 정의를 적용하십시오.

kubectl apply -f apache_deployment.yaml --record

부

명령 끝에서 --record 플래그를 사용하십시오. 필수는 아니지만이 방법을 따라야합니다. --record 플래그는 배치를 발행 한 명령을 목록에 저장합니다. 이 기사의 뒷부분에서이 정보를 저장 한 가치가 있습니다. 몇 초 안에 kubectl get pods를 실행하여 포드 상태를 확인할 수 있습니다. 세 개의 포드가 실행중인 것을 볼 수 있습니다.

배포 정의

해당 포드를 불러오는 데 사용한 정의 파일을 살펴 보겠습니다.

• 파일은 Deployment API 객체를 허용하는 apiVersion으로 시작합니다. 현재는 app / v1입니다.
• 그런 다음 리소스 유형이 배포입니다.
• 메타 데이터에서이 배포의 이름과 레이블을 정의합니다.
• spec 필드는 유지 관리하기 위해이 배포가 필요한 포드 수를 정의합니다. 또한 컨트롤러가 대상 포드를 획득하기 위해 사용하는 선택 기준도 포함합니다. matchLabels 필드는 role = webserver라고 표시된 포드를 대상으로합니다.
• 사양 필드에는 포드를 만들거나 다시 만드는 데 사용되는 포드 템플릿도 있습니다.
• spec.template.metadata는 새 포드가 가질 레이블을 정의합니다.
• spec.template.spec 부분은 실제 컨테이너 정의 (컨테이너 필드 소유)를 갖습니다. 이 예에서는 컨테이너 이름과 수신 대기하는 포트 (HTTP 80)를 정의합니다.

가동 중지 시간없이 업데이트 수행 (배포 롤링 업데이트)

지금까지 배포에서 수행 한 모든 작업은 일반적인 ReplicaSet과 다르지 않습니다. 배포의 진정한 장점은 응용 프로그램 중단없이 포드 템플릿 을 업데이트 할 수 있다는 것 입니다.

Apache 서버 버전 2.4 테스트를 마치고 프로덕션 환경에서 사용할 수 있다고 가정합니다. 현재 포드는 이전 Apache 버전 2.0을 사용하고 있습니다. 다음 명령은 새 이미지를 사용하도록 배포 포드 템플릿을 변경합니다.

kubectl set image deployment apache-deployment apache=httpd:2.4

부

위의 명령은 apache라는 컨테이너의 이미지 태그를 변경하여 2 대신 httpd 태그 2.4 이미지를 사용하도록 변경합니다.이를 수행하는 다른 방법은 다음과 같은 명령을 사용하여 배치 구성 YAML을 직접 편집하는 것입니다.

kubectl edit deployment apache-deployment

부

그런 다음 포드 템플릿 부분까지 아래로 스크롤하여 httpd 이미지 태그를 변경하십시오. 구성을 저장하면 배포에서 포드를 하나씩 업데이트하기 시작합니다. 다음 명령을 실행하여이 조작의 실제 진행 상황을 볼 수 있습니다.

kubectl rollout status deployment apache-deployment

부

모든 포드가 새 컨테이너 이미지를 사용할 때까지 출력에 업데이트 진행률이 표시됩니다.

업데이트를 롤링하는 방법을 결정할 때 Kubernetes Deployments에서 사용하는 알고리즘은 포드의 25 % 이상을 계속 실행하는 것입니다. 따라서 충분한 수의 새로운 포드가 없으면 오래된 포드를 죽이지 않습니다. 같은 의미에서 충분한 포드가 더 이상 실행되지 않을 때까지 새 포드를 만들지 않습니다. 이 알고리즘을 통해 업데이트 중에 응용 프로그램을 항상 사용할 수 있습니다.

다음 명령을 사용하여 배포에서 사용중인 업데이트 전략을 결정할 수 있습니다.

kubectl describe deployments | grep Strategy

부

출력은 다음과 같습니다.

StrategyType: RollingUpdateRollingUpdateStrategy: 25% max unavailable, 25% max surge

부

여기서 grep을 사용하여 명령의 출력을 필터링하여 포드를 업데이트하는 방법을 알 수있었습니다. 필터를 제거하면 배포 단계에 대한 유용한 정보를 찾을 수 있습니다. 보자 :

Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 28m deployment-controller Scaled up replica set apache-deployment-6bdd4b58db to 4 Normal ScalingReplicaSet 4m38s deployment-controller Scaled up replica set apache-deployment-67fd555f74 to 1 Normal ScalingReplicaSet 4m38s deployment-controller Scaled down replica set apache-deployment-6bdd4b58db to 3 Normal ScalingReplicaSet 4m38s deployment-controller Scaled up replica set apache-deployment-67fd555f74 to 2 Normal ScalingReplicaSet 4m34s deployment-controller Scaled down replica set apache-deployment-6bdd4b58db to 2 Normal ScalingReplicaSet 4m34s deployment-controller Scaled up replica set apache-deployment-67fd555f74 to 3 Normal ScalingReplicaSet 4m33s deployment-controller Scaled down replica set apache-deployment-6bdd4b58db to 1 Normal ScalingReplicaSet 4m33s deployment-controller Scaled up replica set apache-deployment-67fd555f74 to 4 Normal ScalingReplicaSet 4m32s deployment-controller Scaled down replica set apache-deployment-6bdd4b58db to 0

부

명령 출력의 끝에서이를 찾아야합니다. 배포에서 처음 4 개의 포드로 ReplicaSet을 생성 한 방법을 보여줍니다. 그런 다음 하나의 포드로 새로운 ReplicaSet을 사용했습니다. 그 후 즉시 이전 ReplicaSet의 포드 중 하나를 종료합니다. 보시다시피 이전 ReplicaSet에서 포드를 죽이고 모든 포드를 교체 할 때까지 새 포드를 확장합니다.

kubectl get rs를 실행하여 두 개의 ReplicaSet이 생성되었는지 다시 확인하십시오. 출력은 다음과 유사해야합니다.

NAME DESIRED CURRENT READY AGE apache-deployment-67fd555f74 4 4 4 19m apache-deployment-6bdd4b58db 0 0 0 43m

부

이전 ReplicaSet에는 포드가없고 새 Replica에는 4 개의 포드가 모두 있습니다.

Kubernetes 배포 전략 개요

롤링 업데이트

지속적 업데이트 전략을 사용하려면 정의 파일에 매개 변수를 지정할 필요가 없습니다. 그러나 Kubernetes 가 기존 포드를 새로운 포드로 전환 하는 방법을 세부적으로 조정할 수 있습니다. 예를 들어 Kubernetes는 자동으로 포드의 75 % 이상을 사용할 수 있도록 결정합니다. 즉, 포드 중 25 % 만 업데이트됩니다 (예 : 업데이트 프로세스 중에 4 개 중 하나가 다운 될 수 있음). 이 동작을 무시하려면 다음과 같이 .spec.strategy.type을 추가하십시오.

spec: strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 50%

부

maxUnavailable 매개 변수를 50 %로 설정하면 업데이트 중에 Kubernetes가 실행중인 포드의 절반을 줄이려고합니다. 이 숫자는 백분율 또는 정수일 수 있습니다.

업데이트 재 작성

재생성 전략은 모든 기존 포드를 즉시 중단 한 다음 새 포드를 시작합니다. 이로 인해 다운 타임이 발생합니다. 그러나 때로는 필요합니다. 예를 들어, 응용 프로그램에서 심각한 보안 결함이 발견되면 즉시 새로운 패치 이미지로 전환해야합니다. 이전의 취약한 버전을 사용하기 위해 고객이 필요하지 않으므로 비즈니스 평판에 부정적인 영향을 줄 수 있습니다. 응용 프로그램이 잠시 중단 되더라도 여기에서 재 작성 배치 전략이 필요합니다. 업데이트가 완료 될 때까지 친숙한 "유지 관리 중"메시지를 표시 할 수 있습니다.

엔지니어가 사용해야 할 다른 유형의 배포 전략이 있습니다. 이 글을 쓰는 시점에 Kubernetes Deployment는 지속적 업데이트 및 재생성 전략 만 지원합니다. 그러나 서비스와 같은 다른 컨트롤러의 도움으로 다음과 같은보다 복잡한 시나리오를 달성 할 수 있습니다.

• Blue / Green 배포 : 최신 버전 (녹색)과 실행 중 (파란색)의 두 가지 버전의 응용 프로그램이 있습니다. 녹색 배포가 준비되면 Pod Selector를 통해 새 포드를 선택하도록 서비스를 구성 할 수 있습니다. 모든 것이 문제없이 진행되면 파란색 버전을 최신 버전으로 업데이트하여 준비 환경으로 사용할 수도 있습니다.
• 카나리아 출시: 옛날에 사용했던 석탄 광부 안전 기술의 이름을 따서 명명되었습니다. 그들은 카나리아 조류가 들어있는 새장을 가져 와서 발견되지 않은 광산의 입구에 놓았습니다. 조류가 죽으면 독성 일산화탄소 배출이 있음을 나타냅니다. 그렇지 않으면, 광부는 가기에 좋았다. 소프트웨어 릴리스에서 카나리아 유형은 사용자의 하위 집합을 새로운 버전의 응용 프로그램으로 보내고 피드백을 테스트합니다. 대부분의 사용자는 여전히 이전 안정 버전을 사용하고 있습니다. 문제가 발견되지 않으면 완전히 출시 될 때까지 점점 더 많은 사용자가 새 버전으로 연결됩니다. Kubernetes에서는 복제본 수가 적은 (카나리아 인스턴스) 다른 배포를 만들어이 작업을 수행 할 수 있습니다. 테스트 결과에 따라 배포를 확장하거나 완전히 종료 할 수 있습니다.

다른 업데이트가 진행중인 동안 배포 업데이트 (롤러 업데이트)

배포 컨트롤러가 포드 템플릿 (예 : 업데이트)의 변경 사항을 감지하자마자 새 ReplicaSet을 만들고 포드를 모두 이동할 때까지 해당 새 ReplicaSet에 포드를 롤아웃하기 시작합니다. 그러나 기존 업데이트가 아직 진행중인 동안 새 업데이트를 발행 할 수도 있습니다. 예를 들어 봅시다.

10 개의 애플리케이션 포드를 버전 1.1 (이미지 myapp : 1.1)로 업데이트한다고 가정하십시오. 또한 업데이트가 진행되는 동안 QA 팀은 버전 1.12의 테스트를 마치고 배포 준비가 완료되었음을 알려줍니다. 따라서 실행중인 업데이트를 중단하고 최신 버전 (image myapp : 1.2)으로 넘어갑니다. 배후에서 배포는 새로운 ReplicaSet을 사용하고 있었고 새 배포 요청을 감지했을 때 이미 myapp : 1.1 이미지를 사용하도록 3 개의 포드를 이동했습니다. 즉시 다른 ReplicaSet을 생성하고 이동 한 3 개의 포드를 종료 한 다음 myapp : 1.2를 사용하여 포드로 최신 ReplicaSet을 확장합니다. 즉, 전체 10 개의 포드가 myapp : 1.1 로의 업그레이드가 완료 될 때까지 기다리지 않고 myapp : 1.2로 마이그레이션을 시작합니다. 대신 기존 작업을 중단하고 새 작업을 즉시 시작합니다.

배포 취소 (일명 롤백)

Kubernetes 배포를 통해 업데이트를 롤백 할 수 있습니다. 변경을 취소하려는 경우 많은 시나리오가 있습니다. 고객이 품질 보증 단계에서 발견되지 않은 버그에 대해 불만을 제기했다고해서 버그가 수정 될 때까지 애플리케이션을 이전 버전으로 되돌려 야한다고 가정 해 보겠습니다. 예를 들어 웹 계층에 Apache 대신 Nginx를 사용하기로 결정했다고 가정 해 보겠습니다. 변경하기 위해 다음 명령을 발행했습니다.

kubectl set image deployment apache-deployment frontend=nginx:1.7.9 --record

부

잠시 후, 모든 포드는 Nginx를 웹 서버로 사용하고있었습니다. 그런 다음 응용 프로그램에 성능 문제가 있으며 클라이언트가 불만을 제기하기 시작했습니다. Apache를 다시 사용하도록 포드를 구성해야합니다. 이 롤백 프로세스에는 가동 중지 시간이 없어야합니다.

Kubernetes 배포 컨트롤러는 만들어진 모든 배포 (구성 가능한 한도까지)를 추적합니다. Kubernetes는 포드 템플릿의 변경 사항 만 고려하여 기록을 유지합니다. 예를 들어, 변경중인 포드 수를 늘리거나 줄이면 레코드로 계산되지 않습니다.

우리의 예로 돌아갑니다. 배포를 이전 배포로 롤백하려면 먼저 마지막 변경 사항을 나열해야합니다. 다음 명령은 배포 기록을 출력합니다.

kubectl rollout history deployment apache-deployment

부

다음과 같은 결과가 나타납니다.

REVISION CHANGE-CAUSE 1 kubectl apply --filename=apache_deployment.yaml --record=true 2 kubectl set image deployment apache-deployment frontend=nginx:1.7.9 --record=true

부

변경 원인에는 발행 및 변경을 유발 한 명령이 포함됩니다. --record 플래그를 사용하지 않은 경우이 필드는 None과 같습니다.

최신 배치를 롤백하고 이전 상태로 돌아가려면 다음 명령을 실행하십시오.

kubectl rollout undo deployment apache-deployment

부

Kubernetes Deployment는 포드를 Nginx로 업그레이드 할 때 사용한 프로세스와 유사한 프로세스를 시작합니다. 잠시 후 모든 포드가 Apache를 다시 실행합니다.

때로는 특정 배포로 롤백 할 수도 있습니다. Nginx로 변경하기 전에 httpd image 2.4에서 2.4.39로 업그레이드했다고 가정 해 봅시다. httpd : 2.4 사용으로 되돌리려 고합니다. 그것은 다시 두 번의 배치입니다. --to-revision 플래그를 사용하여 배포를 롤백 할 정확한 개정 번호를 지정할 수 있습니다. 예를 들면 다음과 같습니다.

kubectl rollout undo deployment apache-deployment --to-revision=1

부

확장 및 자동 확장 배포

배포는 내부적으로 복제 세트를 사용하여 포드를 관리하기 때문에 확장 또는 축소를 지원합니다. 아파치 배포가 4 개 대신 6 개의 포드를 실행하도록 확장 해 보겠습니다.

kubectl scale deployment apache-deployment --replicas=6

부

kubectl get pods를 사용하여 pod를 확인하면 Deployment에서 두 개의 pod가 더 생성됩니다.

당신은 또한 사용할 수있는 수평 포드 자동 확장 (HPA)를 자동으로 높이거나 노드에서 CPU 부하에 따라 배포 포드의 수를 감소. 다음 명령

kubectl autoscale deployment apache-deployment --min=6 --max=10 --cpu-percent=70

부

노드의 CPU로드 양에 따라 배포에서 포드를 추가하거나 종료합니다. 포드의 평균 CPU로드는 70 %입니다. 로드가 증가함에 따라 배포는 10 개까지 더 많은 포드를 생성합니다. 부하가 적을 경우 배치가 6 개 이상인 경우 추가 포드를 종료합니다. 배포에서 자동 확장에 사용하는 알고리즘에 대한 자세한 내용은 여기를 참조하십시오 .

k8s 클러스터를 지속적으로 최적화하는 방법 알아보기

TL; DR

• Kubernetes Deployment는 가장 강력한 컨트롤러 중 하나입니다. 지정된 수의 포드를 유지 관리 할뿐만 아니라 해당 포드에 대한 업데이트로 인해 다운 타임이 발생하지 않도록합니다.
• 배후에서 배치는 복제 세트를 사용하여 포드를 관리합니다.
• Kubernetes Deployments는 이미 진행중인 배포 업데이트를 중단하고 배포 컨트롤러가 응용 프로그램 중단없이 즉시 새 업데이트를 시작하도록 지시 할 수있는 롤오버 업데이트를 지원합니다.
• Kubernetes는 최근 배포 목록을 유지 관리합니다. 이 목록을 사용하여 업데이트를 롤백 할 수 있습니다. 개정 번호를 지정하여 이동할 특정 배포를 선택할 수도 있습니다.
• 배포를 사용하여 관리중인 포드 수를 늘리거나 줄일 수 있습니다. 최대 및 최소 개수의 포드를 만들거나 종료하여 CPU로드에 응답하도록 구성 할 수도 있습니다.