ReplicaSet 스케일링
9216 단어 kubectlkubernetes
소개
ReplicaSet은 설정을 변경하여 복제본 수를 변경할 수 있습니다.
이번에는 그 동작을 확인했습니다.
두 가지 방법이 있습니다.
1. kubectl scale 명령으로 변경
2. 매니페스트를 다시 작성하고 kubectl apply 명령으로 반영
kubectl scale 명령으로 변경
초기 상태를 확인합니다.
$ kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
sample-pod3-rzmhb 2/2 Running 0 38s 192.168.79.91 k8s-worker01 <none> <none>
sample-pod3-tjsdm 2/2 Running 0 38s 192.168.69.220 k8s-worker02 <none> <none>
sample-pod3-zmjkj 2/2 Running 0 38s 192.168.79.83 k8s-worker01 <none> <none>
$ kubectl get rs -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
sample-pod3 3 3 3 47s nginx,redis nginx:latest,redis:latest app=nginx-redis
복제본을 3 -> 5로 확장합니다.
$ kubectl scale replicaset --replicas=5 sample-pod3
replicaset.apps/sample-pod3 scaled
$ kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
sample-pod3-bv9x8 2/2 Running 0 68s 192.168.79.87 k8s-worker01 <none> <none>
sample-pod3-rzmhb 2/2 Running 0 2m42s 192.168.79.91 k8s-worker01 <none> <none>
sample-pod3-tjsdm 2/2 Running 0 2m42s 192.168.69.220 k8s-worker02 <none> <none>
sample-pod3-vg2g8 2/2 Running 0 68s 192.168.69.223 k8s-worker02 <none> <none>
sample-pod3-zmjkj 2/2 Running 0 2m42s 192.168.79.83 k8s-worker01 <none> <none>
$ kubectl get rs -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
sample-pod3 5 5 5 2m37s nginx,redis nginx:latest,redis:latest app=nginx-redis
복제본이 증가했습니다.
포드 삭제시 동작
여기서 의도적으로 포드를 삭제하여 셀프 힐링 기능이 작동하는지 확인해 보겠습니다.
$ kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
sample-pod3-bv9x8 2/2 Running 0 68s 192.168.79.87 k8s-worker01 <none> <none>
sample-pod3-rzmhb 2/2 Running 0 2m42s 192.168.79.91 k8s-worker01 <none> <none>
sample-pod3-tjsdm 2/2 Running 0 2m42s 192.168.69.220 k8s-worker02 <none> <none>
sample-pod3-vg2g8 2/2 Running 0 68s 192.168.69.223 k8s-worker02 <none> <none>
sample-pod3-zmjkj 2/2 Running 0 2m42s 192.168.79.83 k8s-worker01 <none> <none>
$ kubectl delete pod sample-pod3-rzmhb
pod "sample-pod3-rzmhb" deleted
$ kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
sample-pod3-bv9x8 2/2 Running 0 2m41s 192.168.79.87 k8s-worker01 <none> <none>
sample-pod3-dgh4k 2/2 Running 0 9s 192.168.69.219 k8s-worker02 <none> <none>
sample-pod3-tjsdm 2/2 Running 0 4m15s 192.168.69.220 k8s-worker02 <none> <none>
sample-pod3-vg2g8 2/2 Running 0 2m41s 192.168.69.223 k8s-worker02 <none> <none>
sample-pod3-zmjkj 2/2 Running 0 4m15s 192.168.79.83 k8s-worker01 <none> <none>
이해하기 어렵지만 두 번째 줄인 "sample-pod3-rzmhb"를 삭제하면 "sample-pod3-dgh4k"가 새로 배포됩니다.
이렇게 하면 kubectl scale 명령으로 설정한 복제본 수가 Master 서버 설명서에도 반영되는지 확인할 수 있습니다.
또한 kubectl describe 명령을 사용하여 Pod의 배포 기록을 확인합니다.
$ kubectl describe rs sample-pod3
Name: sample-pod3
・・・
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 4m47s replicaset-controller Created pod: sample-pod3-rzmhb <-- 最初のデプロイ
Normal SuccessfulCreate 4m47s replicaset-controller Created pod: sample-pod3-tjsdm <-- 最初のデプロイ
Normal SuccessfulCreate 4m47s replicaset-controller Created pod: sample-pod3-zmjkj <-- 最初のデプロイ
Normal SuccessfulCreate 3m13s replicaset-controller Created pod: sample-pod3-vg2g8 <-- kubectl scaleでの追加
Normal SuccessfulCreate 3m13s replicaset-controller Created pod: sample-pod3-bv9x8 <-- kubectl scaleでの追加
Normal SuccessfulCreate 41s replicaset-controller Created pod: sample-pod3-dgh4k <-- セルフヒーリング機能による追加
ReplicaSet 삭제
kubectl scale 명령으로 확장하면 당연히 yaml 파일이 업데이트되지 않습니다.
kubectl scale 명령으로 스케일 한 후 변경하지 않은 yaml 파일로 삭제할 수 있는지 확인해 보았습니다.
sampleReplicaSet.yamlapiVersion: apps/v1
kind: ReplicaSet
metadata:
name: sample-pod3
spec:
replicas: 3 <-- レプリカの数は「3」
selector:
matchLabels:
app: nginx-redis
template:
metadata:
labels:
app: nginx-redis
spec:
containers:
- name: nginx
image: nginx:latest
- name: redis
image: redis:latest
$ kubectl get rs -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
sample-pod3 5 5 5 4m35s nginx,redis nginx:latest,redis:latest app=nginx-redis
yaml 파일의 복제본 수는 "3"이고 실제 복제본 수는 "5"입니다.
삭제해 봅니다.
$ kubectl delete -f sampleReplicaSet.yaml
replicaset.apps "sample-pod3" deleted
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
sample-pod3-bv9x8 0/2 Terminating 0 17m
sample-pod3-dgh4k 0/2 Terminating 0 14m
sample-pod3-tjsdm 0/2 Terminating 0 18m
sample-pod3-vg2g8 0/2 Terminating 0 17m
sample-pod3-zmjkj 0/2 Terminating 0 18m
$ kubectl get rs
No resources found in default namespace.
삭제되었습니다.
매니페스트를 다시 작성하고 kubectl apply 명령으로 반영
초기 상태를 확인합니다.
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
sample-pod3-67b24 2/2 Running 0 35s
sample-pod3-fk967 2/2 Running 0 35s
sample-pod3-ssn7z 2/2 Running 0 35s
yaml 파일의 replicas 값을 변경하고 적용합니다.
$ kubectl apply -f sampleReplicaSet.yaml
replicaset.apps/sample-pod3 configured
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
sample-pod3 5 5 5 97s
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
sample-pod3-67b24 2/2 Running 0 99s
sample-pod3-fk967 2/2 Running 0 99s
sample-pod3-mp6cs 2/2 Running 0 15s
sample-pod3-ssn7z 2/2 Running 0 99s
sample-pod3-w559b 2/2 Running 0 15s
이것뿐입니다.
요약
ReplicaSet의 스케일링 동작을 확인할 수 있습니다.
kubectl scale 명령으로의 스케일링은, 지금까지의 인프라 운용(한 번 설정하면 별로 바꾸지 않는다)에 익숙해져 있는 분이라고 익숙해지기 쉬울지도 모릅니다. (나도 그렇습니다)
그러나 Kubernetes로 실현되는 마이크로 아키텍처는 환경을 자주 변경합니다. 따라서 수동으로 변경하는 것은 그리 현실적이지 않으며 실제로는 Git 리포지토리에서 코드를 관리하고 변경이 커밋되면 자동으로 적용하는 CI/CD 파이프 라인을 구축 할 수 있습니다. 많습니다.
그 때문에, 검증등으로 CI/CD의 파이프라인을 만들 때까지도 없는 환경에서도, 매니페스트를 재작성해 apply 하는 방법에 익숙해 두는 것이 좋을 것입니다.
Reference
이 문제에 관하여(ReplicaSet 스케일링), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다
https://qiita.com/dingtianhongjie/items/97532d38abfa16fa1855
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
초기 상태를 확인합니다.
$ kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
sample-pod3-rzmhb 2/2 Running 0 38s 192.168.79.91 k8s-worker01 <none> <none>
sample-pod3-tjsdm 2/2 Running 0 38s 192.168.69.220 k8s-worker02 <none> <none>
sample-pod3-zmjkj 2/2 Running 0 38s 192.168.79.83 k8s-worker01 <none> <none>
$ kubectl get rs -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
sample-pod3 3 3 3 47s nginx,redis nginx:latest,redis:latest app=nginx-redis
복제본을 3 -> 5로 확장합니다.
$ kubectl scale replicaset --replicas=5 sample-pod3
replicaset.apps/sample-pod3 scaled
$ kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
sample-pod3-bv9x8 2/2 Running 0 68s 192.168.79.87 k8s-worker01 <none> <none>
sample-pod3-rzmhb 2/2 Running 0 2m42s 192.168.79.91 k8s-worker01 <none> <none>
sample-pod3-tjsdm 2/2 Running 0 2m42s 192.168.69.220 k8s-worker02 <none> <none>
sample-pod3-vg2g8 2/2 Running 0 68s 192.168.69.223 k8s-worker02 <none> <none>
sample-pod3-zmjkj 2/2 Running 0 2m42s 192.168.79.83 k8s-worker01 <none> <none>
$ kubectl get rs -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
sample-pod3 5 5 5 2m37s nginx,redis nginx:latest,redis:latest app=nginx-redis
복제본이 증가했습니다.
포드 삭제시 동작
여기서 의도적으로 포드를 삭제하여 셀프 힐링 기능이 작동하는지 확인해 보겠습니다.
$ kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
sample-pod3-bv9x8 2/2 Running 0 68s 192.168.79.87 k8s-worker01 <none> <none>
sample-pod3-rzmhb 2/2 Running 0 2m42s 192.168.79.91 k8s-worker01 <none> <none>
sample-pod3-tjsdm 2/2 Running 0 2m42s 192.168.69.220 k8s-worker02 <none> <none>
sample-pod3-vg2g8 2/2 Running 0 68s 192.168.69.223 k8s-worker02 <none> <none>
sample-pod3-zmjkj 2/2 Running 0 2m42s 192.168.79.83 k8s-worker01 <none> <none>
$ kubectl delete pod sample-pod3-rzmhb
pod "sample-pod3-rzmhb" deleted
$ kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
sample-pod3-bv9x8 2/2 Running 0 2m41s 192.168.79.87 k8s-worker01 <none> <none>
sample-pod3-dgh4k 2/2 Running 0 9s 192.168.69.219 k8s-worker02 <none> <none>
sample-pod3-tjsdm 2/2 Running 0 4m15s 192.168.69.220 k8s-worker02 <none> <none>
sample-pod3-vg2g8 2/2 Running 0 2m41s 192.168.69.223 k8s-worker02 <none> <none>
sample-pod3-zmjkj 2/2 Running 0 4m15s 192.168.79.83 k8s-worker01 <none> <none>
이해하기 어렵지만 두 번째 줄인 "sample-pod3-rzmhb"를 삭제하면 "sample-pod3-dgh4k"가 새로 배포됩니다.
이렇게 하면 kubectl scale 명령으로 설정한 복제본 수가 Master 서버 설명서에도 반영되는지 확인할 수 있습니다.
또한 kubectl describe 명령을 사용하여 Pod의 배포 기록을 확인합니다.
$ kubectl describe rs sample-pod3
Name: sample-pod3
・・・
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 4m47s replicaset-controller Created pod: sample-pod3-rzmhb <-- 最初のデプロイ
Normal SuccessfulCreate 4m47s replicaset-controller Created pod: sample-pod3-tjsdm <-- 最初のデプロイ
Normal SuccessfulCreate 4m47s replicaset-controller Created pod: sample-pod3-zmjkj <-- 最初のデプロイ
Normal SuccessfulCreate 3m13s replicaset-controller Created pod: sample-pod3-vg2g8 <-- kubectl scaleでの追加
Normal SuccessfulCreate 3m13s replicaset-controller Created pod: sample-pod3-bv9x8 <-- kubectl scaleでの追加
Normal SuccessfulCreate 41s replicaset-controller Created pod: sample-pod3-dgh4k <-- セルフヒーリング機能による追加
ReplicaSet 삭제
kubectl scale 명령으로 확장하면 당연히 yaml 파일이 업데이트되지 않습니다.
kubectl scale 명령으로 스케일 한 후 변경하지 않은 yaml 파일로 삭제할 수 있는지 확인해 보았습니다.
sampleReplicaSet.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: sample-pod3
spec:
replicas: 3 <-- レプリカの数は「3」
selector:
matchLabels:
app: nginx-redis
template:
metadata:
labels:
app: nginx-redis
spec:
containers:
- name: nginx
image: nginx:latest
- name: redis
image: redis:latest
$ kubectl get rs -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
sample-pod3 5 5 5 4m35s nginx,redis nginx:latest,redis:latest app=nginx-redis
yaml 파일의 복제본 수는 "3"이고 실제 복제본 수는 "5"입니다.
삭제해 봅니다.
$ kubectl delete -f sampleReplicaSet.yaml
replicaset.apps "sample-pod3" deleted
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
sample-pod3-bv9x8 0/2 Terminating 0 17m
sample-pod3-dgh4k 0/2 Terminating 0 14m
sample-pod3-tjsdm 0/2 Terminating 0 18m
sample-pod3-vg2g8 0/2 Terminating 0 17m
sample-pod3-zmjkj 0/2 Terminating 0 18m
$ kubectl get rs
No resources found in default namespace.
삭제되었습니다.
매니페스트를 다시 작성하고 kubectl apply 명령으로 반영
초기 상태를 확인합니다.
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
sample-pod3-67b24 2/2 Running 0 35s
sample-pod3-fk967 2/2 Running 0 35s
sample-pod3-ssn7z 2/2 Running 0 35s
yaml 파일의 replicas 값을 변경하고 적용합니다.
$ kubectl apply -f sampleReplicaSet.yaml
replicaset.apps/sample-pod3 configured
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
sample-pod3 5 5 5 97s
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
sample-pod3-67b24 2/2 Running 0 99s
sample-pod3-fk967 2/2 Running 0 99s
sample-pod3-mp6cs 2/2 Running 0 15s
sample-pod3-ssn7z 2/2 Running 0 99s
sample-pod3-w559b 2/2 Running 0 15s
이것뿐입니다.
요약
ReplicaSet의 스케일링 동작을 확인할 수 있습니다.
kubectl scale 명령으로의 스케일링은, 지금까지의 인프라 운용(한 번 설정하면 별로 바꾸지 않는다)에 익숙해져 있는 분이라고 익숙해지기 쉬울지도 모릅니다. (나도 그렇습니다)
그러나 Kubernetes로 실현되는 마이크로 아키텍처는 환경을 자주 변경합니다. 따라서 수동으로 변경하는 것은 그리 현실적이지 않으며 실제로는 Git 리포지토리에서 코드를 관리하고 변경이 커밋되면 자동으로 적용하는 CI/CD 파이프 라인을 구축 할 수 있습니다. 많습니다.
그 때문에, 검증등으로 CI/CD의 파이프라인을 만들 때까지도 없는 환경에서도, 매니페스트를 재작성해 apply 하는 방법에 익숙해 두는 것이 좋을 것입니다.
Reference
이 문제에 관하여(ReplicaSet 스케일링), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다
https://qiita.com/dingtianhongjie/items/97532d38abfa16fa1855
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
sample-pod3-67b24 2/2 Running 0 35s
sample-pod3-fk967 2/2 Running 0 35s
sample-pod3-ssn7z 2/2 Running 0 35s
$ kubectl apply -f sampleReplicaSet.yaml
replicaset.apps/sample-pod3 configured
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
sample-pod3 5 5 5 97s
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
sample-pod3-67b24 2/2 Running 0 99s
sample-pod3-fk967 2/2 Running 0 99s
sample-pod3-mp6cs 2/2 Running 0 15s
sample-pod3-ssn7z 2/2 Running 0 99s
sample-pod3-w559b 2/2 Running 0 15s
ReplicaSet의 스케일링 동작을 확인할 수 있습니다.
kubectl scale 명령으로의 스케일링은, 지금까지의 인프라 운용(한 번 설정하면 별로 바꾸지 않는다)에 익숙해져 있는 분이라고 익숙해지기 쉬울지도 모릅니다. (나도 그렇습니다)
그러나 Kubernetes로 실현되는 마이크로 아키텍처는 환경을 자주 변경합니다. 따라서 수동으로 변경하는 것은 그리 현실적이지 않으며 실제로는 Git 리포지토리에서 코드를 관리하고 변경이 커밋되면 자동으로 적용하는 CI/CD 파이프 라인을 구축 할 수 있습니다. 많습니다.
그 때문에, 검증등으로 CI/CD의 파이프라인을 만들 때까지도 없는 환경에서도, 매니페스트를 재작성해 apply 하는 방법에 익숙해 두는 것이 좋을 것입니다.
Reference
이 문제에 관하여(ReplicaSet 스케일링), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://qiita.com/dingtianhongjie/items/97532d38abfa16fa1855텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)