Pod 의 업그레이드 와 스크롤 백
apiVersion: apps/v1beta2 # for versions before 1.8.0 use apps/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.8
ports:
- containerPort: 80$ kubectl create -f nginx-deployment.yaml
deployment "nginx-deployment" created
## ：
$ kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE
nginx-deployment-f95b7b6b8-82hzl 1/1 Running 0 1m 192.168.150.219 10.3.1.16
nginx-deployment-f95b7b6b8-8nlzk 1/1 Running 0 1m 192.168.150.230 10.3.1.16
nginx-deployment-f95b7b6b8-dqksj 1/1 Running 0 1m 192.168.150.207 10.3.1.16스크롤 업데이트 세 가지 방법:
$ kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
$ kubectl edit Deployment ：
.spec.template.spec.containers[0].image nginx:1.8 nginx:1.9.1。
## deployment Pod ， ：
$ kubectl apply -f deployment.yaml3. 업 데 이 트 를 스크롤 한 후 게시 상 태 를 실시 간 으로 관찰:
$ kubectl rollout status deployment/nginx-deployment
Waiting for rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for rollout to finish: 1 old replicas are pending termination...
Waiting for rollout to finish: 1 old replicas are pending termination...
deployment "nginx-deployment" successfully rolled out
kubectl rollout ：
$ kubectl rollout [ history | pause | resume | status | undo ]
## ， 、 、 ， 。현재 실행 중인 Pod 를 확인 합 니 다. 이름 이 업데이트 되 었 습 니 다:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-deployment-6bd4859cdb-4jz8v 1/1 Running 0 9m
nginx-deployment-6bd4859cdb-vggjb 1/1 Running 0 7m
nginx-deployment-6bd4859cdb-zpwj8 1/1 Running 0 7mPod 에서 사용 하 는 미 러 를 보 니 nginx 1.9.1 로 업데이트 되 었 습 니 다.
$ kubectl describe pod nginx-deployment-6bd4859cdb-4jz8v
Name: nginx-deployment-6bd4859cdb-4jz8v
......
Image: nginx:1.9.1
……그럼 Deployment 는 어떻게 Pod 업 데 이 트 를 완 료 했 나 요?kbectl describe deployments / nginx - deployment 명령 을 사용 하여 deployment 의 업데이트 과정 을 관찰 할 수 있 습 니 다.
Normal ScalingReplicaSet 21m deployment-controller Scaled up replica set nginx-deployment-f95b7b6b8 to 3
## create ， deployment rs nginx-deployment-f95b7b6b8 3 。
Normal ScalingReplicaSet 18m deployment-controller Scaled up replica set nginx-deployment-6bd4859cdb to 1
# ， deployment-controller rs nginx-deployment-6bd4859cdb ， 1 。
Normal ScalingReplicaSet 16m deployment-controller Scaled down replica set nginx-deployment-f95b7b6b8 to 2
## 1 rs， rs nginx-deployment-f95b7b6b8 2 ， replicas 3 。
Normal ScalingReplicaSet 16m deployment-controller Scaled up replica set nginx-deployment-6bd4859cdb to 2
## rs nginx-deployment-6bd4859cdb 2 。 4 ， ， ，
Normal ScalingReplicaSet 16m deployment-controller Scaled down replica set nginx-deployment-f95b7b6b8 to 1
## rs nginx-deployment-f95b7b6b8 1 ， 3 。
Normal ScalingReplicaSet 16m deployment-controller Scaled up replica set nginx-deployment-6bd4859cdb to 3
## rs nginx-deployment-6bd4859cdb 3 。 1 ， ， 。
Normal ScalingReplicaSet 16m deployment-controller Scaled down replica set nginx-deployment-f95b7b6b8 to 0
## rs nginx-deployment-f95b7b6b8 0 。
이렇게 해서 업그레이드 과정 에서 새로운 rs 를 만 들 고 낡은 것 을 줄 여 신 구 교 체 를 완성 하고 deployment 가 서비스 가 중단 되 지 않도록 보장 하 며 사본 수량 은 사용자 가 지정 한 수량 (DESIRED) 을 유지 합 니 다.
업데이트 완료 후 rs 의 최종 상태 보기:
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-6bd4859cdb 3 3 3 19m # 3
nginx-deployment-f95b7b6b8 0 0 0 22m # 0전체 업그레이드 과정 에서 시스템 은 최소 두 개의 Pod 를 사용 할 수 있 고 최대 4 개의 pod 를 동시에 실행 할 수 있 습 니 다. (처음에 3 개, 새로 1 개 로 만 들 면 4 개 이지 만 그 다음 에 바로 하 나 를 삭 제 했 습 니 다) 이것 은 Deployment 가 복잡 한 알고리즘 을 통 해 완 성 된 것 입 니 다.Deployment 는 사용 가능 한 Pod 총 수 를 최소 필요 한 던 전 수량 (DESIRED) 에서 1 로 줄 여야 합 니 다. 즉, 최대 1 개 사용 할 수 없 는 maxUnavailable = 1 입 니 다.디 플 로 이 먼 트 는 전체 업데이트 과정 에서 포드 의 총 수량 이 필요 한 던 전 수 를 너무 많이 초과 하지 않도록 확보 해 야 한다. 기본 적 인 상황 에서 디 플 로 이 먼 트 는 포드 의 총 수량 이 필요 한 포드 수 보다 최대 1 개, 즉 최대 1 개의 파도 값, max Surge = 1 을 확보 해 야 한다.kubernets 는 v 1.6 부터 max Unavailable 와 max Surge 의 기본 값 은 1, 1 에서 필요 한 던 전 수의 25%, 25% 로 업 데 이 트 됩 니 다.
설명 정 보 를 통 해 다음 을 볼 수 있 습 니 다.
$ kubectl describe deployment nginx-deployment
.......
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
......Deployment 의 업데이트 정책 에 대해 다음 과 같이 설명 합 니 다.
Deployment 의 정의 에서 spec. strategy 를 통 해 Pod 업데이트 정책 을 지정 할 수 있 습 니 다. 현재 두 가지 정책 을 지원 합 니 다. RollingUpdate (스크롤 업데이트), Recreate (재 구축), 기본 RollingUpdate (스크롤 업데이트).Recreate (재 구축): spec. strategy. type = Recreate 를 설정 합 니 다. deployment 는 Pod 를 업데이트 할 때 실행 중인 Pod 를 모두 죽 이 고 새 Pod 를 만 듭 니 다.RollingUpdate (스크롤 업데이트): spec. strategy. type = RollingUpdate 를 설정 합 니 다. deployment 는 스크롤 업데이트 방식 으로 Pod 를 하나씩 업데이트 하 는 동시에 spec. strategy. rollingUpdate 의 두 매개 변수 (max Unavailable 와 max Surge) 를 설정 하여 스크롤 의 새로운 과정 을 제어 할 수 있 습 니 다.이 두 값 은 정수 일 수도 있 고 백분 수도 있다.예 를 들 어 max Unavailable 가 30% 로 설정 되 었 을 때 오래된 RS 는 스크롤 업데이트 가 시 작 될 때 즉시 던 전 수량 을 필요 한 던 전 총수 의 70% 로 줄 이 고 총수 의 70% 가 정수 가 아니라면 시스템 은 먼저 아래 에서 정리 하 는 방식 으로 절대 치 를 계산한다.한편, max Surge 에 대해 백분율 로 설정 하면 시스템 은 위로 추출 하 는 방식 으로 절대 치 를 계산 합 니 다.이 두 매개 변 수 는 v 1.6 부터 기본 값 은 모두 1 에서 25% 로 바 뀌 었 다.
다 중 업데이트 문제 주의: 여기 서 다 중 업데이트 (Rollover) 가 필요 합 니 다. 만약 에 Deployment 의 지난번 업데이트 가 진행 중 입 니 다. 이때 사용자 가 Deployment 의 업데이트 작업 을 다시 시작 하면 Deployment 는 매번 업 데 이 트 를 위해 RS 를 만 듭 니 다. 매번 에 새로운 RS 가 생 성 될 때마다 Pod 던 전 수 를 하나씩 증가 하고 이전에 확장 하고 있 던 RS 를 확장 하지 않 습 니 다.그리고 이 를 이전 버 전의 RS 목록 에 추가 한 다음 0 으로 축소 하 는 작업 을 시작 합 니 다.
deployment 태그 업데이트 문제 에 주의 하 십시오. 일반적으로 deployment 태그 선택 기 를 업데이트 하 는 것 을 권장 하지 않 습 니 다. 이 로 인해 Deployment 에서 선택 한 Pod 목록 이 변화 하고 다른 컨트롤 러 와 충돌 할 수 있 습 니 다.
탭 선택 기 를 업데이트 해 야 한다 면 다른 문제 가 없 도록 조심 하 세 요.Deployment 선택 기 업데이트 에 대한 주의사항: 1. 선택 기 탭 을 추가 할 때 Deployment 설정 의 Pod 탭 을 동기 화하 여 Pod 에 새 탭 을 추가 해 야 합 니 다. 그렇지 않 으 면 Deployment 업데이트 가 잘못 되 었 습 니 다.탭 선택 기 를 추가 하 는 것 은 뒤로 호 환 되 지 않 습 니 다. 이 는 새로운 탭 선택 기 가 기 존 선택 기 를 사용 하여 만 든 RS 와 Pod 와 일치 하지 않 는 다 는 것 을 의미 합 니 다. 따라서 선택 기 를 추가 하면 모든 기 존 버 전의 RS 와 기 존 RS 로 만 든 Pod 가 고립 된 상태 에 있 고 시스템 에서 자동 으로 삭제 되 지 않 으 며 새로운 RS 에 의 해 제어 되 지 않 으 면 고아 가 됩 니 다.2. 탭 선택 기 를 업데이트 합 니 다. 선택 기 에 있 는 탭 의 키 와 값 을 변경 하 는 것 도 선택 기 탭 추가 와 유사 한 효 과 를 낼 수 있 습 니 다.3. 태그 선택 기 를 삭제 합 니 다. 즉, Deployment 의 태그 선택 기 에서 하나 이상 의 탭 을 삭제 합 니 다. 이 Deployment 의 RS 와 Pod 는 아무런 영향 을 받 지 않 지만 삭 제 된 탭 은 기 존의 Pod 와 RS 에 존재 합 니 다.
deployment 스크롤 백
스크롤 백 동작 을 보 여주 기 위해 위 에 만 든 deploy 미 러 를 수정 하고 잘못된 미 러 로 변경 하여 업그레이드 에 성공 하지 못 한 다음 스크롤 백 을 진행 합 니 다.
$ kubectl set image deployment/nginx-deployment nginx=nginx:1.91
deployment "nginx-deployment" image updated
$ kubectl rollout status deployment nginx-deployment
Waiting for rollout to finish: 1 out of 3 new replicas have been updated...
## ， ctrl+c
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-6bd4859cdb 3 3 3 2h
nginx-deployment-b6d78b976 1 1 0 1m
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
busybox-865b7fdc54-4h64c 1/1 Running 2 5d
nginx-deployment-b6d78b976-5gljq 0/1 ErrImagePull 0 2
#pod deployment 가 스크롤 백 할 수 있 는 이 유 는 배 치 된 기록 과 버 전 번 호 를 유지 할 수 있 기 때 문 입 니 다. 아래 명령 으로 볼 수 있 습 니 다.
과거 버 전 보기:
$ kubectl rollout history deployment nginx-deployment
deployments "nginx-deployment"
REVISION CHANGE-CAUSE
1
2
3
# 3
# CHANGE-CAUSE none， deployment --record ， 。 특정 버 전의 자세 한 정 보 를 보면 -- revision = 을 추가 할 수 있 습 니 다.
$ kubectl rollout history deployment nginx-deployment --revision=3
deployments "nginx-deployment" with revision #3
Pod Template:
Labels: app=nginx
pod-template-hash=628346532
Containers:
nginx:
Image: nginx:1.91
Port: 80/TCP
Environment:
Mounts:
Volumes: 어떤 버 전 으로 되 돌아 가 버 전 번 호 를 추가 하지 않 고 기본적으로 이전 버 전 으로 되 돌아 갑 니 다.
$ kubectl rollout undo deployment nginx-deployment
deployment "nginx-deployment" rolled back스크롤 백 후 이 deploy 의 이벤트 정보 보기:
kubectl describe deployment nginx-deployment
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 10m deployment-controller Scaled up replica set nginx-deployment-b6d78b976 to 1
# rs 1 。
Normal DeploymentRollback 35s deployment-controller Rolled back deployment "nginx-deployment" to revision 2
# 2
Normal ScalingReplicaSet 35s deployment-controller Scaled down replica set nginx-deployment-b6d78b976 to 0
# RS 0
， rs 0 ， pod 。
-- to - version 매개 변 수 를 사용 하여 스크롤 백 된 배치 버 전 번 호 를 지정 합 니 다.
$ kubectl rollout undo deployment nginx-deployment --to-revision=1
deployment "nginx-deployment" rolled back\ # 이제 버 전 1 로 되 돌아 가 는 과정 을 살 펴 보 자:
$kubectl describe deployment nginx-deployment
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal DeploymentRollback 5m deployment-controller Rolled back deployment "nginx-deployment" to revision 1
# 1 。
# ，
Normal ScalingReplicaSet 5m deployment-controller Scaled up replica set nginx-deployment-f95b7b6b8 to 1
# rs nginx-deployment-f95b7b6b8 1
Normal ScalingReplicaSet 5m deployment-controller Scaled down replica set nginx-deployment-6bd4859cdb to 2
# rs 3， 2
Normal ScalingReplicaSet 5m deployment-controller Scaled up replica set nginx-deployment-f95b7b6b8 to 2
# rs nginx-deployment-f95b7b6b8 1 2 。
Normal ScalingReplicaSet 5m deployment-controller Scaled down replica set nginx-deployment-6bd4859cdb to 1
# rs， 1 。
Normal ScalingReplicaSet 5m (x2 over 6h) deployment-controller Scaled up replica set nginx-deployment-f95b7b6b8 to 3
# rs nginx-deployment-f95b7b6b8 3
Normal ScalingReplicaSet 5m deployment-controller Scaled down replica set nginx-deployment-6bd4859cdb to 0
# rs 0 。이렇게, 신 구 교체, 이것저것 줄 여 스크롤 백 을 완성 합 니 다.
복잡 한 수정 을 위해 Deployment 의 배치 작업 을 일시 정지 하고 복구 합 니 다.
Deployment 가 수정 해 야 할 부분 이 많 을 수 있 습 니 다. 매번 수정 할 때마다 업데이트 작업 이 실 행 될 수 있 습 니 다. 잦 은 Deployment 업데이트 작업 이 발생 하지 않도록 Deployment 의 업 데 이 트 를 중단 한 다음 에 Deployment 를 복원 하고 완전한 업데이트 작업 을 한꺼번에 실행 할 수 있 습 니 다.이전에 만 든 Nginx 를 예 로 들 면, 효 과 를 보기 위해 이전에 만 든 nginx - deployment 를 삭제 하고 다시 만 듭 니 다.
$ kubectl create -f nginx-deployment.yaml
deployment "nginx-deployment" created
$ kubectl rollout history deployment nginx-deployment
deployments "nginx-deployment"
REVISION CHANGE-CAUSE
1 일시 정지 전에 기 존 이벤트 보기:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 2m deployment-controller Scaled up replica set nginx-deployment-f95b7b6b8 to 3# kubectl rollout pause Deployment ：
$ kubectl rollout pause deployment nginx-deployment
deployment "nginx-deployment" paused일시 정지 후, set 로 미 러 정 보 를 수정 해도 업데이트 작업 이 일어나 지 않 습 니 다.
$ kubectl set image deployment nginx-deployment nginx=1.9.1
deployment "nginx-deployment" image updated
$ kubectl rollout history deployment nginx-deployment
deployments "nginx-deployment"
REVISION CHANGE-CAUSE
1
# 1 이벤트 가 변경 되 지 않 았 습 니 다. 일시 정지 시 업데이트 작업 이 일어나 지 않 는 다 는 것 을 설명 합 니 다.
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 5m deployment-controller Scaled up replica set nginx-deployment-f95b7b6b8 to 3일시 정지 기간 에 필요 에 따라 임의의 설정 업 데 이 트 를 할 수 있 습 니 다. 예 를 들 어 업데이트 용기 의 자원 제한 을 다시 수정 할 수 있 습 니 다.
$ kubectl set resources deployment nginx-deployment -c=nginx --limits=cpu=200m,memory=500Mi
deployment "nginx-deployment" resource requirements updated수정 후, 마지막 으로 이 Deployment 의 배치 작업 을 복원 합 니 다:
$ kubectl rollout resume deployment nginx-deployment
deployment "nginx-deployment" resumed복구 후 배치 상황 검증:
1. rs 보기, 새로운 rs 가 생 성 되 었 습 니 다:
root@ubuntu15:/data/yaml# kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-6cbfdb4885 1 1 0 28s
nginx-deployment-f95b7b6b8 3 3 3 14m2. Delpoyment 의 이벤트 정 보 를 보면 Deployment 가 업 데 이 트 를 완 료 했 음 을 알 수 있 습 니 다.
kubectl describe deployment nginx-deployment
Events:
Type Reason Age From Message
Normal ScalingReplicaSet 1m deployment-controller Scaled up replica set nginx-deployment-654cd8f467 to 1
Normal ScalingReplicaSet 1m deployment-controller Scaled down replica set nginx-deployment-f95b7b6b8 to 2
Normal ScalingReplicaSet 1m deployment-controller Scaled up replica set nginx-deployment-654cd8f467 to 2일시 정 지 된 Deployment 를 복구 하기 전에 이 Deployment 를 스크롤 백 할 수 없습니다. 즉, 일시 정 지 된 상태 에서 업 그 레이 드 를 업데이트 하지 않 아 도 스크롤 백 하지 않 습 니 다.
다른 관리 대상 의 업데이트:
1. RC 의 스크롤 업그레이드 작업 에 대해 서 는 kbetl rolling - update 명령 을 사용 합 니 다.업그레이드 과정 은 Deployment 와 유사 합 니 다.2. DaemontSet 의 업데이트 정책: 두 가지 업그레이드 정책: Ondelete 와 RollingUpdateOndelete: DaemonSet 의 기본 업그레이드 정책 은 v 1.5 및 이전 버 전의 Kubernetes 와 일치 합 니 다. Ondelete 를 긴 정책 으로 사용 할 때 새로운 DaemonSet 설정 을 만 든 후에 새로운 Pod 는 사용자 가 수 동 으로 이전 버 전의 Pod 를 삭제 할 때 까지 자동 으로 생 성 되 지 않 습 니 다.새 작업 이 실 행 됩 니 다.RollingUpdate: v 1.6 버 전부터 도입 되 었 습 니 다. 이후 버 전 은 기본 정책 입 니 다. RollingUpdate 를 업그레이드 전략 으로 DaemonSet 을 업데이트 할 때 이전 버 전의 Pod 는 자동 으로 죽 이 고 새 버 전의 DaemonSet Pod 를 자동 으로 만 듭 니 다.
3. StatefulSet 의 업데이트 정책 은 v 1.6 버 전부터 시작 되 었 습 니 다. SatefulSet 의 업데이트 전략 에 대해 Deployment 과 DaemonSet 의 업데이트 전략 을 일치 시 키 고 RollingUpdate, Paritioned 와 OnDelete 몇 가지 전략 을 실현 할 것 입 니 다. 목 표 는 StatefulSet 에서 각 Pod 가 질서 있 고 하나하나 새로운 것 을 확보 하 며 업데이트 역 사 를 유지 할 수 있 고 특정한 역사 버 전 으로 돌아 갈 수 있 도록 하 는 것 입 니 다.
DaemonSet 자원 대상 업데이트
DaemonSet 만 들 기:
apiVersion: apps/v1beta2
kind: DaemonSet
metadata:
name: nginx-daemonset
labels:
app: nginx
spec:
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.8
ports:
- containerPort: 80생 성 된 이벤트 정보 보기
$ kubectl describe daemonset nginx-daemonset
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 3m daemon-set Created pod: nginx-daemonset-qpbwp
Normal SuccessfulCreate 3m daemon-set Created pod: nginx-daemonset-z8gb5이 때 만 든 pod 이름 은 다음 과 같 습 니 다.
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-daemonset-4dpmv 1/1 Running 0 17s
nginx-daemonset-99d5k 1/1 Running 0 17sDaemonSet 스크롤 업데이트 기능 은 v 1.6 이상 버 전에 서 만 지 원 됩 니 다.
스크롤 업데이트 실행:
같은 업데이트 정책 을 설정 해 야 합 니 다: DaemonSet 의 스크롤 업데이트 기능 을 사용 하려 면 설정 해 야 합 니 다. .spec. updateStrategy. type 은 RollingUpdate 입 니 다. spec. updateStrategy. rollingUpdate. max Unavailable (기본 값 1) 와. spec. minReady Seconds (기본 값 0) 를 설정 해 야 할 수도 있 습 니 다.
스크롤 업 데 이 트 를 실행 하기 전에 업데이트 정책 을 확인 하고 RollingUpdate 로 설정 되 어 있 는 지 확인 하 십시오.
$ kubectl get daemonset nginx-daemonset -o go-template='{{.spec.updateStrategy.type}}{{"
"}}'
RollingUpdateRollingUpdate 가 아니라면 설정:
# ：nginx-daemonset.yaml
apiVersion: apps/v1beta2
kind: DaemonSet
metadata:
name: nginx-daemonset
labels:
app: nginx
spec:
updateStrategy:
type: RollingUpdate
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.10
ports:
- containerPort: 80업데이트 실행
업데이트 방식 은 deployment 방식 과 같은 세 가지 방식 입 니 다. vim 에서 daemonset 파일 을 수정 하고 미 러 를 1.9.1 로 바 꾼 다음 apply:
$ kubectl apply -f nginx-daemonset.yaml
daemonset "nginx-daemonset" configured업데이트 상태 보기
$ kubectl rollout status daemonset nginx-daemonset
daemon set "nginx-daemonset" successfully rolled out업데이트 과정 보기: 오래된 pod 를 삭제 하고 pod 를 새로 만 듭 니 다.
$ kubectl describe daemonset nginx-daemonset
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
# pod：
Normal SuccessfulCreate 2m daemon-set Created pod: nginx-daemonset-99d5k
Normal SuccessfulCreate 2m daemon-set Created pod: nginx-daemonset-4dpmv
# pod， pod 。
Normal SuccessfulDelete 30s daemon-set Deleted pod: nginx-daemonset-4dpmv
Normal SuccessfulCreate 26s daemon-set Created pod: nginx-daemonset-n2f7m
Normal SuccessfulDelete 24s daemon-set Deleted pod: nginx-daemonset-99d5k
Normal SuccessfulCreate 15s daemon-set Created pod: nginx-daemonset-2bz6q만 든 새 pod 보기:
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-daemonset-2bz6q 1/1 Running 0 5m
nginx-daemonset-n2f7m 1/1 Running 0 5m그 중 pod 의 미 러 를 보 니 1.9.1 로 바 뀌 었 습 니 다.
$ kubectl describe pod nginx-daemonset-2bz6q
Name: nginx-daemonset-2bz6q
Namespace: default
……
Image: nginx:1.9.1
……어떤 경우 에는 DaemonSet 업데이트 가 걸 릴 수 있 습 니 다. 예 를 들 어 어떤 Node 상태 가 NotReady 로 바 뀌 거나 어떤 Node 자원 이 소 진 되 어 분배 할 수 없습니다. Daemont 를 위해 자원 을 비 워 두 면 됩 니 다. 잘못된 미 러 로 바 뀌 었 다 면 다시 정확 한 미 러 로 바 꾼 다음 에 업데이트 해 야 합 니 다.
Daemon Set 의 스크롤 백
스크롤 백 은 Deployment 방식 과 같 습 니 다.
$ kubectl rollout history daemonset
daemonsets ""
REVISION CHANGE-CAUSE
1 ...
2 ...
# ：
$ kubectl rollout history daemonset --revision=1
# ：
kubectl rollout status ds/
# ， ：
daemonset "" successfully rolled out 이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
Kubernetes Pod란?Pod란 Kubernetes 에서 배포할 수 있는 가장 작은 단위이며, 한개 또는 여러개의 container 들의 묶음 이라고 생각하면 된다. 즉 Kubernetes cluster 내에 container를 배포하기 ...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.
좋은 웹페이지 즐겨찾기
