레플리카셋 (replicaset) = 일정 개수의 파드를 유지하는 컨트롤러
: 파드 집합의 실행을 항상 안정적으로 유지하는 것이 목적이다.
보통 명시된 동일 파드 개수에 대한 가용성을 보증하는데 사용한다.
동일한 컨테이너를 여러 개 실행하려고 하는 경우 사용한다.
1. 동일한 컨테이너를 실행하는 파드를 여러개 정의해서 실행
예시) 같은 내용의 컨테이너 2개를 실행하는 yaml 파일
apiVersion: v1
kind: Pod
metadata:
name: my-nginx-pod-A
spec:
containers:
- name: my-nginx-container
image: nginx
ports:
- containerPort: 80
protocol: TCP
---
apiVersion: v1
kind: Pod
metadata:
name: my-nginx-pod-B
spec:
containers:
- name: my-nginx-container
image: nginx
ports:
- containerPort: 80
protocol: TCP
- 이 방법은 비효율적이다.
- 파드가 삭제되거나 파드가 위치한 노드에 장애가 발생하여 파드에 접근하지 못하는 경우,
관리자가 직접 파드를 삭제하고 다시 생성해야 한다.
- 이 문제는 레플리카셋을 이용하면 해결된다.
2. 레플리카셋을 이용
- yaml 파일 작성 (/home//vagrant/replicaset-nginx.yaml)
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: replicaset-nginx
spec:
replicas: 3
selector:
matchLabels:
app: my-nginx-pod-label
template:
metadata:
name: my-nginx-pod
labels:
app: my-nginx-pod-label
spec:
containers:
- name: my-nginx-container
image: nginx
ports:
- containerPort: 80
protocol: TCP
template : 레플리카의 조건에 맞는 파드들을 구동하는 파드들의 명세(spec)
metadata에는 파드의 이름과 selector에서 인식할 수 있는 label 정보가,
스펙에는 파드 내 컨테이너의 이름과 사용하는 이미지 및 포트의 정보가 기입되어 있다.
selector : 레플리카를 구동하는 파드들의 조건
여기선 app:~ 이라는 label 을 가진 파드들이 해당된다.
- 작성한 yaml 파일을 실행해 레플리카셋 구동
> kubectl apply -f replicaset-nginx.yaml
vagrant@controlplane:~$ kubectl apply -f replicaset-nginx.yaml
replicaset.apps/replicaset-nginx created
- 생성된 파드의 개수 확인
> kubectl get pad -o wide
vagrant@controlplane:~$ kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
my-nginx-pod-cli 1/1 Running 0 23h 172.16.140.72 node02 <none> <none>
replicaset-nginx-4hklm 1/1 Running 0 22s 172.16.196.143 node01 <none> <none>
replicaset-nginx-n5wxr 1/1 Running 0 22s 172.16.140.79 node02 <none> <none>
replicaset-nginx-ncszg 1/1 Running 0 22s 172.16.196.142 node01 <none> <none>
- 생성된 레플리카셋 확인
> kubectl get replicaset -o wide
vagrant@controlplane:~$ kubectl get replicaset -o wide
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
replicaset-nginx 3 3 3 69s my-nginx-container nginx app=my-nginx-pod-label
3. 파드의 개수를 늘려서 실행
- replicaset-nginx.yaml 파일의 이름을 바꿔 복사
> cp replicaset-nginx.yaml replicaset-nginx-4pods.yaml
vagrant@controlplane:~$ cp replicaset-nginx.yaml replicaset-nginx-4pods.yaml
=> replicaset-nignx.yaml 파일의 내용이 이름만 바뀌어 복사됨
- VSCode 에서 replicaset-nginx-4pods.yaml 파일을 열어 replicas 속성을 3에서 4로 변경
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: replicaset-nginx
spec:
replicas: 4
selector:
matchLabels:
app: my-nginx-pod-label
template:
metadata:
name: my-nginx-pod
labels:
app: my-nginx-pod-label
spec:
containers:
- name: my-nginx-container
image: nginx
ports:
- containerPort: 80
protocol: TCP
- 변경된 레플리카셋 생성
> kubectl apply -f replicaset-nginx-4pods.yaml
vagrant@controlplane:~$ kubectl apply -f replicaset-nginx-4pods.yaml
replicaset.apps/replicaset-nginx configured
=> replicaset-nginx-4pods.yaml의 내용은 replicas 속성의 값만 다르고 replicaset-nginx.yaml 의 내용과 동일하다.
따라서 created가 아닌 configured가 출력됨을 확인할 수 있다.
- 변경된 pod의 개수를 확인
> kubectl get pod -o wide
vagrant@controlplane:~$ kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
my-nginx-pod-cli 1/1 Running 0 23h 172.16.140.72 node02 <none> <none>
replicaset-nginx-4hklm 1/1 Running 0 4m59s 172.16.196.143 node01 <none> <none>
replicaset-nginx-8mwmd 1/1 Running 0 35s 172.16.140.80 node02 <none> <none>
replicaset-nginx-n5wxr 1/1 Running 0 4m59s 172.16.140.79 node02 <none> <none>
replicaset-nginx-ncszg 1/1 Running 0 4m59s 172.16.196.142 node01 <none> <none>
=> 8mwmd로 끝나는 파드가 생성되어 파드 개수가 4개 실행 중임을 확인한다.
4. scale 명령으로 레플리카셋 yaml 파일의 replicas 속성 수정
- scale 명령어를 사용해 replicas의 수를 5로 수정
> kubectl scale replicaset replicaset-nginx --replicas=5
vagrant@controlplane:~$ kubectl scale replicaset replicaset-nginx --replicas=5
replicaset.apps/replicaset-nginx scaled
- 변경된 파드의 개수 확인
> kubectl get pod -o wide
vagrant@controlplane:~$ kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
my-nginx-pod-cli 1/1 Running 0 23h 172.16.140.72 node02 <none> <none>
replicaset-nginx-4hklm 1/1 Running 0 7m4s 172.16.196.143 node01 <none> <none>
replicaset-nginx-8mwmd 1/1 Running 0 2m40s 172.16.140.80 node02 <none> <none>
replicaset-nginx-cg66v 1/1 Running 0 29s 172.16.140.81 node02 <none> <none>
replicaset-nginx-n5wxr 1/1 Running 0 7m4s 172.16.140.79 node02 <none> <none>
replicaset-nginx-ncszg 1/1 Running 0 7m4s 172.16.196.142 node01 <none> <none>
=> replicas 속성값 5로 변경하여 유지되는 파드의 수가 5개임을 확인
5. edit 명령으로 레플리카셋 yaml 파일의 수정
- edit 모드로 진입
> kubectl edit replicaset replicaset-nginx
vagrant@controlplane:~$ kubectl edit replicaset replicaset-nginx
:
spec:
replicas: 6
selector:
matchLabels:
app: my-nginx-pod-label
:
edit 사용 예시) replicas 속성 수정
방향키를 replicas : 5 앞으로 이동 -> x (한글자 삭제) -> i (편집 모드) -> 6 입력
-> ESC (명령 모드로 전환) -> :wq (콜론 + wq : 저장 후 종료)
replicaset.apps/replicaset-nginx edited
=> edit 모드에서 콜론+wq 입력 후 엔터 시 정상적으로 수정이 완료되면 edited가 출력됨을 확인해야 한다.
- replicas 속성 수정에 따른 파드 개수 변경 확인
> kubectl get pod -o wide
vagrant@controlplane:~$ kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
my-nginx-pod-cli 1/1 Running 0 23h 172.16.140.72 node02 <none> <none>
replicaset-nginx-4hklm 1/1 Running 0 11m 172.16.196.143 node01 <none> <none>
replicaset-nginx-8mwmd 1/1 Running 0 6m58s 172.16.140.80 node02 <none> <none>
replicaset-nginx-cg66v 1/1 Running 0 4m47s 172.16.140.81 node02 <none> <none>
replicaset-nginx-k9bqj 1/1 Running 0 25s 172.16.196.144 node01 <none> <none>
replicaset-nginx-n5wxr 1/1 Running 0 11m 172.16.140.79 node02 <none> <none>
replicaset-nginx-ncszg 1/1 Running 0 11m 172.16.196.142 node01 <none> <none>
6. 레플리카셋 삭제 => 레플리카셋에 의해 생성된 파드도 함께 삭제된다.
- 레플리카셋 삭제
> kubectl delete -f replicaset-nginx-4pods.yaml
vagrant@controlplane:~$ kubectl delete -f replicaset-nginx-4pods.yaml
replicaset.apps "replicaset-nginx" deleted
- 레플리카셋, 파드 동시 확인
> kubectl get rs,pod
vagrant@controlplane:~$ kubectl get rs,pod
NAME READY STATUS RESTARTS AGE
pod/my-nginx-pod-cli 1/1 Running 0 23h
=> 레플리카셋이 삭제되고, (추가로 생성한 파드를 포함한) 모든 파드가 삭제된다.
selector에 명시되어 있는 라벨을 기준으로 삭제되기 때문이다.
7. 파드를 유지한 상태에서 레플리카셋을 삭제
- 레플리카셋 구동, 레플리카셋 및 파드 생성을 확인
> kubectl apply -f replicaset-nginx-4pods.yaml
vagrant@controlplane:~$ kubectl apply -f replicaset-nginx-4pods.yaml
replicaset.apps/replicaset-nginx created
> kubectl get rs,pod
vagrant@controlplane:~$ kubectl get rs,pod
NAME DESIRED CURRENT READY AGE
replicaset.apps/replicaset-nginx 4 4 4 18s
NAME READY STATUS RESTARTS AGE
pod/my-nginx-pod-cli 1/1 Running 0 23h
pod/replicaset-nginx-472ql 1/1 Running 0 18s
pod/replicaset-nginx-5nk88 1/1 Running 0 18s
pod/replicaset-nginx-ttvw5 1/1 Running 0 18s
pod/replicaset-nginx-w72mf 1/1 Running 0 18s
- 레플리카셋을 삭제할 때 파드를 남기는 옵션을 추가하여 명령어 입력
> kubectl delete -f replicaset-nginx-4pods.yaml --cascade=orphan
vagrant@controlplane:~$ kubectl delete -f replicaset-nginx-4pods.yaml --cascade=orphan
replicaset.apps "replicaset-nginx" deleted
- 남아있는 파드의 개수 확인
> kubectl get rs,pod
NAME READY STATUS RESTARTS AGE
pod/my-nginx-pod-cli 1/1 Running 0 23h
pod/replicaset-nginx-472ql 1/1 Running 0 18s
pod/replicaset-nginx-5nk88 1/1 Running 0 18s
pod/replicaset-nginx-ttvw5 1/1 Running 0 18s
pod/replicaset-nginx-w72mf 1/1 Running 0 18s
=> 레플리카셋은 사라지고 파드는 남아 있는 것을 확인할 수 있다.
- 파드 모두 삭제
> kubectl delete pod --all => --all 옵션을 사용하면 해당하는 모든 내용을 삭제할 수 있다.
* 레플리카셋의 동작
: label selector 를 이용해서 파드를 유지
1) app : my-nginx-pod-label 라벨을 가지는 파드를 생성함
2) replicaset-nginx-4pods.yaml : 작성된 파일의 내용에 따라 레플리카셋을 생성함
3-1) 레플리카셋을 이용해 생성한 파드의 개수를 확인하고 1)에서 생성한 파드를 삭제
-2) scale 명령어를 사용한 replicas 값 변경에 맞춰 파드가 추가 생성되는 것을 확인한다.
4-1) kubectl edit 명령으로 파드 중 하나의 라벨을 삭제하거나 replicas 속성의 값 변경
-2) 변경된 값에 맞춰 파드가 추가 생성되는 것을 확인
5) replicaset-nginx-4pods.yaml 파일을 이용해서 레플리카셋을 삭제하고 삭제된 것을 확인
디플로이먼트 (deployment)
: 파드, 레플리카셋의 배포를 관리하는 것이 목적이다. 앱의 배포와 업데이트를 편리하게 하기 위해 사용
쿠버네티스에서 상태가 없는(stateless) 앱을 배포할 때 사용하는 가장 기본적인 컨트롤러이다.
디플로이먼트는 스케일, 롤아웃/롤백, 자동복구 기능이 있다.
| | | 노드 수준에서 장애가 발생했을 때 파드를 복구하는 기능
| | 서비스를 유지하면서 파드를 교체
| 파드의 개수를 변경하는 명령어
구동하는 방법
1. 디플로이먼트 생성
- /home/vagrant/에 deployment-nginx.yaml 파일을 생성하고 코드를 작성한다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: my-nginx
template:
metadata:
name: my-nginx-pod
labels:
app: my-nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
- 디플로이먼트를 생성한다.
> kubectl apply -f deployment-nginx.yaml
vagrant@controlplane:~$ kubectl apply -f deployment-nginx.yaml
deployment.apps/my-nginx-deployment created
2. 디플로이먼트, 레플리카셋, 파드 생성 확인
> kubectl get deployment,replicaset,pod
vagrant@controlplane:~$ kubectl get deployment,replicaset,pod
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/my-nginx-deployment 3/3 3 3 87s
| | | | 파드가 실행되고 있는 지속 시간
| | | 서비스 가능한 파드의 개수
| | 최신 상태로 업데이트된 파드의 개수
| 파드 개수
NAME DESIRED CURRENT READY AGE
replicaset.apps/my-nginx-deployment-c5ddf7856 3 3 3 87s
NAME READY STATUS RESTARTS AGE
pod/my-nginx-deployment-c5ddf7856-9vkwp 1/1 Running 0 87s
pod/my-nginx-deployment-c5ddf7856-ggg9n 1/1 Running 0 87s
pod/my-nginx-deployment-c5ddf7856-wwsvk 1/1 Running 0 87s
pod/my-nginx-pod-cli 1/1 Running 0 24h
pod/replicaset-nginx-472ql 1/1 Running 0 37m
pod/replicaset-nginx-5nk88 1/1 Running 0 37m
pod/replicaset-nginx-ttvw5 1/1 Running 0 37m
pod/replicaset-nginx-w72mf 1/1 Running 0 37m
3. 디플로이먼트 삭제
: yaml 또는 이름을 이용해서 삭제가 가능하며, 삭제 시 replicaset과 pod가 함께 삭제된다.
- yaml 또는 이름으로 이용해서 삭제
> kubectl delete deployment my-nginx-deployment 또는
kubectl delete -f deployment-nginx.yaml
vagrant@controlplane:~$ kubectl delete deployment my-nginx-deployment
deployment.apps "my-nginx-deployment" deleted
- 삭제 확인 (replicaset과 pod도 모두 삭제됨을 확인)
> kubectl get rs,pod
디플로이먼트를 사용하는 이유 1) Scale
: replicas 값을 변경해서 파드 개수 조절
1. relicas 값을 3으로 설정한 디플로이먼트 yaml 파일 생성
- /home/vagrant/ 에 web-deploy-replicas-3.yaml 파일 생성 및 코드 작성
- 디플로이먼트 구동
>
- 디플로이먼트 생성 확인
>
2. replicas 속성값을 5로 수정
- 디플로이먼트 파일 복사 후 replicas 속성을 5로 변경
>
- replicas 값이 변경된 yaml 파일을 apply
>
- 디플로이먼트, 레플리카셋, 파드 확인
>
3. kubectl scale 명령어로 replicas의 값을 변경
- replicas 의 속성값을 10으로 변경하는 scale 명령어 입력
>
- 디플로이먼트, 레플리카셋, 파드 확인
>
4. 디플로이먼트 삭제
>
- 삭제 확인
>
디플로이먼트를 사용하는 이유 2) 롤아웃/롤백
1. --record 옵션을 추가해 디플로이먼트를 생성
> kubectl apply -f deployment-nginx.yaml --record
=> --record는 앞으로 삭제될 것이기 때문에 안써도 된다.
- 디플로이먼트 생성을 확인
> kubectl get all
2. kubectl set image 명령으로 파드의 컨테이너 이미지를 변경
>
- 이미지 변경을 확인 = 기존의 파드가 중지되고 이미지를 업데이트한 파드를 새로 생성한다.
> kubectl get all
3. 기록된 리비전 정보를 확인하고 롤백
> kubectl rollout history deployment my-nginx-deployment
- 리비전 1번으로 롤백
>
- 롤백되는 과정 확인
> kubectl get deploy,pd
- 기록된 리비전 정보 재확인
>
=> 기존 리비전 1번이 롤백되면서 리비전 3번으로 넘어간 것을 확인
4. 디플로이먼트 상세 정보 출력
>
5. 스케일 변경 및 롤백
- 스케일 변경
>
=> 레플리카셋을 유지하고 scale만 변경되어 pod 개수만 추가 되었다.
- 다른 실습을 위해 모든 리소스 삭제
>
디플로이먼트를 사용하는 이유 3) 자동 복구
1. 30초 단위로 재기동하는 파드를 정의
- /home/vagrant/ 에 restart-pod.yaml 을 작성
2. 같은 사양의 파드를 4개 가동하는 디플로이먼트를 정의
- /home/vagrant 에 restart-deployment.yaml 을 작성
3. 파드와 디플로이먼트를 배포(구동)
- 파드 배포
>
- 디플로이먼트 배포
>
4. 노드와 파드의 동작을 확인
>
5. 단독으로 실행된 test1 파드가 배포된 노드를 정지
=> 클러스터를 구성하고 있는 노드를 중지 => 노드에 장애를 유발
- 다른 터미널에서 진행, 가상머신의 실행 상태 확인
>
- test1 이 실행되고 있는 노드를 중지
6. 원래 터미널에서 노드와 파드 동작 확인
>
- 노드와 연결된 파드의 상태 확인
>
* 노드가 종료되고 약 6분 정도 경과하면 디플로이먼트로 배포한 test2는
활성화 노드에 대체 파드를 생성하여 자동으로 복구하는 반면,
단독으로 기동한 test1 파드는 원래 노드에 위치하는 것을 확인할 수 있다.
7. 노드 재기동 후 노드와 파드 확인
- 종료한 node01 재기동
>
- 노드와 파드 확인
>
8. 모든 리소스 삭제
>
- 삭제 확인
>
데몬셋 (DaemonSet)
: 각 노드에 파드를 하나씩 배치하는 리소스.
모든 노드에 대하여 클러스터 스토리지 / 로그 수집 / 노드 모니터링 용도로 사용한다.
1. 데몬셋 정의
- /home/vagrant/ 에 sample-daemonset.yaml 을 생성한다.
=> 데몬을 만들어 줄 것이기 때문에 replicas 항목을 작성할 필요가 없다.
2. node01을 중지
> vagrant halt node01
- node01이 중지되었는지 확인
> vagrant status
> controlplane:~$ kubectl get node
3. 데몬셋 생성
>
- 데몬셋 확인
>
- 할당된 노드를 확인하기 위해서는 파드 정보를 불러온다.
>
4. node01 기동 및 확인
- node01 기동
>
- node 상태 확인
>
>
5. 데몬셋 확인
>
6. 데몬셋 삭제
>
- 데몬셋 삭제 확인
>
서비스 (Service)
: 파드를 연결하고 외부에 노출하는 역할
- 서비스 타입
| ClusterIP | |
| NodePort | |
| LoadBalancer | |
| ExternalName |
* 서비스를 생성하는 방법
매니페스트(yaml)을 이용해서 생성
kubectl expose 명령을 사용해서 생성
- ClusterIP 타입의 서비스
1. 디플로이먼트 생성
- /home/vagrant/ 에 hostname-deployment.yaml 생성
2. 서비스 생성
- /home/vagrant/ 에 hostname-service-clusterip.yaml 생성
NodePort 타입의 서비스
: 모든 노드의 특정 포트를 개방해 서비스에 접근하는 방식
노드의 IP 주소에 공개 포트를 오픈 => 클러스터 외부에서 내부의 파드로 요청을 전달하는 것이 가능하다.
30,000 ~ 32,767 범위
그러나 외부에서 접근하려면 IP 주소를 일일히 공개해야 하기 때문에 잘 사용하지 않는 방식
1. 서비스 정의
- /home/vagrant/ 에 hostname-service-nodeport.yaml 파일 생성
2. 디플로이먼트와 서비스 생성
- 디플로이먼트 생성
>
- 서비스 생성
>
- 확인
>
3. 클러스터 내부에서는 모든 노드의 INTERNAL-IP 또는 EXTERNAL-IP와 노드 공개 포트로 접근이 가능하다.
- 노드 확인
>
- controlplane 노드에서 controlplane 노드의 공개 포트로 요청을 전달 가능
>
- controlplane 노드에서 node01 노드의 공개 포트로 요청을 전달 가능
>
- controlplane 노드에서 node02 노드의 공개 포트로 요청을 전달 가능
>
- controlplane 노드에서 서비스 이름으로는 접근이 불가능하다.
4. 클러스터 내에서 CLUSTER-IP와 ClusterIP 서비스 포트를 이용한 접근 가능
- 서비스 확인
>
- CLUSTER-IP 와 ClusterIP 서비스 포트를 사용하여 접근
>
5. 클러스터 외부(호스트 PC)에서 웹 브라우저로 접근
- 웹 브라우저 주소창에 "http://{node의 포트}:{할당된 공개 포트}"를 입력하여 접근
> http://10.0.0.10:***** (controlplane의 포트)
> http://
6. 리소스 정리
- 디플로이먼트 삭제
>
- 서비스 삭제 후 확인
>
>
참고. 업데이트 전락
참고. 데몬셋 업데이트 전략
'Study > seSAC 금천 4기' 카테고리의 다른 글
| 클라우드_1일차_241001 (0) | 2024.10.08 |
|---|---|
| 컨테이너 Orchestration_3일차_240926 (3) | 2024.09.30 |
| 컨테이너 Orchestration_1일차_240924 (0) | 2024.09.30 |
| 컨테이터 애플리케이션 개발_4일차_240923 (0) | 2024.09.30 |
| 컨테이너 애플리케이션 개발_3일차_240920 (1) | 2024.09.30 |