배포 란?
포드 : Kubernetes에서 가장 작은 스케줄링 객체이 장에서는 포드를 소개합니다. 포드는 Kubernetes에서 생성하거나 배포하는 가장 작은 단위이지만 포드는 상대적으로 수명이 짧은 일회성 엔티티로 설계되었습니다. 포드를 제거 할 수 있습니다 (노드 리소스가 부족한 경우). 클러스터의 노드가 충돌하고 사라집니다. Kubernetes는 포드를 관리하기위한 컨트롤러 (컨트롤러)를 제공합니다. 컨트롤러는 여러 포드를 생성 및 관리하고 복사 관리, 롤링 업그레이드,자가 복구 기능을 제공 할 수 있습니다. 가장 일반적으로 사용되는 것은 배포입니다.
그림 1 배포 
배포에는 하나 이상의 Pod 복사본이 포함될 수 있으며 각 Pod 복사본에는 동일한 역할이 있으므로 시스템은 배포의 여러 Pod 복사본에 대한 요청을 자동으로 배포합니다.
배포는 온라인 배포, 롤링 업그레이드, 복사본 생성 및 온라인 복원 기능을 통합합니다. 배포는 어느 정도까지 무인 온라인을 실현하여 온라인 프로세스의 복잡성과 운영 위험을 크게 줄입니다.
배포 만들기
다음 예시는 nginx : latest 이미지를 사용하여 두 개의 포드를 만드는 nginx라는 배포 부하를 만드는 것입니다. 각 포드는 100m 코어 CPU, 200M 메모리를 차지합니다.
apiVersion: apps/v1 # 注意这里与Pod的区别，Deployment是apps/v1而不是v1
kind: Deployment # 资源类型为Deployment
metadata:
name: nginx # Deployment的名称
spec:
replicas: 2 # Pod的数量，Deployment会确保一直有2个Pod运行
selector: # Label Selector
matchLabels:
app: nginx
template: # Pod的定义，用于创建Pod，也称为Pod template
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx:latest
name: container-0
resources:
limits:
cpu: 100m
memory: 200Mi
requests:
cpu: 100m
memory: 200Mi
imagePullSecrets:
- name: default-secret이 정의에서 배포 이름이 nginx이고 spec.replicas가 포드 수를 정의한다는 것을 알 수 있습니다. 즉,이 배포는 2 개의 포드를 제어합니다. spec.selector는 라벨 선택기입니다. 즉,이 배포는 라벨을 앱으로 선택합니다. = nginx의 Pod; spec.template은 Pod의 정의이며 콘텐츠는 Pod의 정의와 정확히 동일합니다.
위 배포의 정의를 deployment.yaml 파일에 저장하고 kubectl을 사용하여이 배포를 만듭니다.
kubectl get을 사용하여 배포 및 Pod를 확인하면 READY 값이 2/2이고, 처음 2 개는 현재 실행중인 Pod가 2 개 있음을 나타내고, 두 번째 2 개는 2 개 Pod가 예상 됨을 나타내며 , AVAILABLE 이 2이면 2 개 Pod를 사용할 수 있음을 나타냅니다. .
$ kubectl create -f deployment.yaml
deployment.apps/nginx created
$ kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
nginx 2/2 2 2 4m5s배포가 포드를 제어하는 방법
아래와 같이 Pod를 계속 쿼리합니다.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-7f98958cdf-tdmqk 1/1 Running 0 13s
nginx-7f98958cdf-txckx 1/1 Running 0 13s포드를 삭제하면 아래와 같이 새 포드가 즉시 생성되는 것을 확인할 수 있습니다. 앞서 언급 한 배포는 2 개의 포드가 실행되도록합니다. 하나를 삭제하면 배포에서 하나를 다시 생성합니다. , Pod가 실패하거나 다른 문제가있는 경우 Deployment는이 Pod를 자동으로 가져옵니다.
$ kubectl delete pod nginx-7f98958cdf-txckx
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-7f98958cdf-tdmqk 1/1 Running 0 21s
nginx-7f98958cdf-tesqr 1/1 Running 0 21snginx-7f98958cdf-tdmqk 및 nginx-7f98958cdf-tesqr이라는 두 개의 Pod가 있습니다. 여기서 nginx는 배포의 직접 이름이고 -7f98958cdf-tdmqk 및 -7f98958cdf-tesqr은 kubernetes에서 임의로 생성 한 접미사입니다.
두 서 픽스의 첫 번째 부분이 동일하고 둘 다 7f98958cdf임을 알 수 있습니다. 이는 Deployment가 Pod를 직접 제어하지 않기 때문입니다. Deployment는 ReplicaSet라는 컨트롤러를 통해 Pod를 제어합니다. ReplicaSet는 다음 명령어로 쿼리 할 수 있습니다. 그중 rs는 ReplicaSet의 약어입니다.
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-7f98958cdf 2 2 2 1m이 ReplicaSet의 이름은 nginx-7f98958cdf이고 접미사 -7f98958cdf도 무작위로 생성됩니다.
배포가 포드를 제어하는 방식은 그림 2에 나와 있습니다. 배포는 ReplicaSet를 제어하고 ReplicaSet는 포드를 제어합니다.
그림 2 ReplicaSet를 통한 배포 제어 포드
kubectl describe 명령어를 사용하여 배포의 세부 정보를 보면 아래와 같이 ReplicaSet을 볼 수 있습니다. 아래에 표시된 것처럼 NewReplicaSet 라인이 있음을 알 수 있습니다. nginx-7f98958cdf (2/2 복제본 생성) 이벤트의 이벤트는 실제로 ReplicaSet의 인스턴스를 확장합니다. 최대 2 개 실제 사용시에는 ReplicaSet을 직접 작동하지 않을 수 있지만 Deployment가 ReplicaSet를 제어하여 포드를 제어한다는 사실을 알면 문제를 찾는 데 도움이됩니다.
**$ kubectl describe deploy nginx**
Name: nginx
Namespace: default
CreationTimestamp: Sun, 16 Dec 2018 19:21:58 +0800
Labels: app=nginx
...
**NewReplicaSet: nginx-7f98958cdf (2/2 replicas created)**
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 5m deployment-controller Scaled up replica set nginx-7f98958cdf to 2업그레이드
실제 애플리케이션에서 업그레이드는 일반적인 시나리오이며 Deployment는 애플리케이션 업그레이드를 쉽게 지원할 수 있습니다.
배포는 다른 업그레이드 전략을 설정할 수 있으며 다음 두 가지가 있습니다.
- RollingUpdate : 롤링 업데이트, 즉 점진적으로 새 포드를 생성 한 다음 이전 포드를 삭제하는 것이 기본 전략입니다.
- 다시 만들기 : 현재 포드를 교체하고 업그레이드합니다. 즉, 현재 포드를 삭제 한 다음 포드를 다시 만듭니다.
배포 업그레이드는 선언적 일 수 있습니다. 즉, 배포의 YAML 정의 만 수정하면됩니다. 예를 들어 kubectl edit 명령어를 사용하여 위 배포의 이미지를 nginx : alpine으로 수정합니다. 수정이 완료되면 ReplicaSet 및 Pod가 쿼리되고 새 ReplicaSet가 생성되고 Pod도 다시 생성됩니다.
$ kubectl edit deploy nginx
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-6f9f58dffd 2 2 2 1m
nginx-7f98958cdf 0 0 0 48m
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-6f9f58dffd-tdmqk 1/1 Running 0 21s
nginx-6f9f58dffd-tesqr 1/1 Running 0 21s배포는 maxSurge 및 maxUnavailable 매개 변수 두 개를 통해 업그레이드 프로세스 중에 동시에 다시 생성되는 pod의 비율을 제어 할 수 있습니다. 이는 많은 경우에 매우 유용합니다. 구성은 아래와 같습니다.
spec:
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
type: RollingUpdate- maxSurge : Deployment의 spec.replicas와 비교할 때 존재할 수있는 Pod 수입니다. 기본값은 25 %입니다. 예를 들어 spec.replicas가 4 인 경우 업그레이드 프로세스 중, 즉 1 단계에서 업그레이드하는 동안 Pod는 5 개까지만 존재할 수 있습니다. , 실제 업그레이드 프로세스는 숫자로 변환되고 변환은 반올림됩니다. 이 값은 숫자로 직접 설정할 수도 있습니다.
- maxUnavailable : 배포의 spec.replicas와 비교할 때 유효하지 않을 수있는 포드 수, 즉 삭제 비율입니다. 기본값은 25 %입니다. 예를 들어 spec.replicas가 4이면 업그레이드 프로세스 중에 포드가 3 개 이상 존재합니다. 포드를 삭제하는 단계는 1입니다. 동일한 값을 숫자로 설정할 수도 있습니다.
이전 예에서 spec.replicas가 2이므로 maxSurge 및 maxUnavailable이 모두 기본값 인 25 %이면 실제 업그레이드 프로세스 중에 maxSurge는 최대 3 개의 Pod가 존재하도록 허용합니다 (반올림, 2 1.25 = 2.5, 반올림). 3) maxUnavailable은 Pod Unavailable (반올림, 2 0.75 = 1.5, 반올림 2)을 허용하지 않습니다. 즉, 업그레이드 프로세스 중에 항상 2 개의 Pod가 실행 중 상태에 있으며 매번 새 Pod가 생성됩니다. , 포드가 성공적으로 생성 된 후 모든 포드가 새 포드가 될 때까지 이전 포드를 삭제합니다.
롤백
롤백은 롤백이라고도합니다. 즉, 업그레이드에서 문제가 발견되면 응용 프로그램이 이전 버전으로 돌아갑니다. 배포는 이전 버전으로 쉽게 롤백 할 수 있습니다.
예를 들어 위에서 업그레이드 한 이미지의 새 버전에 문제가있는 경우 kubectl rollout undo 명령을 실행하여 롤백 할 수 있습니다.
$ kubectl rollout undo deployment nginx
deployment.apps/nginx rolled backDeployment가 이렇게 쉽게 롤백 될 수있는 이유는 Deployment가 ReplicaSet를 통해 Pod를 제어하기 때문입니다. ReplicaSet는 업그레이드 전에 항상 존재 해 왔기 때문입니다. 배포 롤백은 이전 ReplicaSet를 사용하여 Pod를 다시 생성하는 방식으로 수행됩니다. Deployment에 저장되는 ReplicaSet의 수는 correctionHistoryLimit 매개 변수로 제한 할 수 있으며 기본값은 10입니다.