loading
본문 바로가기
Skill-UP/Kubernetes

[Kubernetes] 쿠버네티스 ReplicaSet

by 개발자 김모씨 2020. 11. 16.
반응형

<쿠버네티스 레플리카셋>

 

안녕하세요.
개발자김모씨입니다.

오늘은 ReplicaSet에 대해 이야기해 보려고 합니다.

혹시 Kubernetes Pod 포스팅 안보신 분들은
얼릉 다녀오세요~~
artist-developer.tistory.com/32?category=949818

 

[Kubernetes] 쿠버네티스 Pod

<쿠버네티스 Pod> 안녕하세요. 개발자 김모씨입니다. 쿠버네티스 시리즈를 이어가고 있죠. 혹시 이전 포스팅 '쿠버네티스 구조'를 아직 안 보신 분은 얼렁 다녀오세요~ artist-developer.tistory.com/31 안

artist-developer.tistory.com


 

 

레플리카셋(ReplicaSet) 이란?

자. 이전 포스팅에서 알아보았던 Pod를 이용해서 서비스를 동작 중인 환경을 가정해봅시다.

 


개발자 김모씨는 정말 노력에 노력을 더해서, 끝내 서비스 개발을 완료했고 Pod으로 배포를 했어요.
이제 이 서비스가 잘 돌아가기만 하면 난 떼돈을 벌 수 있을 거에요!!!!!
'돈 긁어모으면 바로 벤츠 산다!!!!'
꿈에 가득찬 개발자 김모씨는 설레이는 마음을 다잡고 잠을 청했습니다.
세시간 뒤, 개발자 김모씨는 궁금함을 못 참고 새벽에 깨어났어요.
'돈을 얼마나 벌었는지 볼까?'
컴퓨터 화면을 켜 상태를 확인한 김모씨는 비명을 질렀어요.
서비스 배포를 위한 Pod이 모두 죽어 있었거든요.....
개발자 김모씨는 벤츠는 물론이고, 경차도 사지 못했어요.
Pod이 잘 동작하고 있는지를 5분마다 확인하느라 스트레스 받아서 탈모까지 와버렸네요...
머리가 빠져 결혼도 하지 못한 개발자 김모씨는 오늘도 혼자 늙어갑니다.


여러분.
위 이야기의 교훈은 무엇인가요?
위 이야기의 교훈은,
"개발자는 탈모에 걸려 혼자 늙어간다"
"Naked Pod(일반적인 Pod)만으로 배포하면 벤츠는 무슨, 아무것도 이룰 수 없다"
입니다.

Naked Pod을 믿을 수 없기 때문이죠.
Pod은 우리의 서비스 또는 서버의 동작을 보장해주지 않습니다.
실행된 노드의 리소스가 부족하거나, 동작에 실패하거나 등등의 여러가지 이유로 인해 Pod는 죽을 수 있습니다.
그리고, 누군가 이를 수정하거나 고쳐주기 전까진 '멍청하게도' 죽은 그 상태로 남아있죠.
이를 해결하기 위해 등장한 것이 바로! 레플리카셋입니다!

레플리카셋을 간단히 설명하자면,
"지정한 pod 갯수만큼 항상 실행될 수 있도록 관리해주는 Controller"
정도로 말할 수 있겠네요.

다시 말하면, 특정 Pod을 5개로 항상 유지하도록 하는 레플리카셋을 만든다면
Pod의 갯수를 모니터링 하다가, 임의의 이유로 인해 Pod가 삭제될 경우
자동으로 새로운 Pod 1개를 생성하여 5개를 유지해줍니다.

이를 통해,
명시된 Pod의 실행을 항상 안정적으로 유지하고,
Pod의 가용성을 보증하는 역할입니다.

 


레플리카셋 사용법

자 그럼 만들어봅시다.

Pod가 비슷하게, 레플리카셋 역시 기본적인 Template가 있습니다.
오늘은 이를 사용해서 nginx를 위한 replicaset을 만들어보죠.

#nginx-replicaset.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-replicaset
spec:
  replicas: 3
  selector:
    matchLabels: 
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx-container
        image: nginx
        ports:
        - containerPort: 80
  • apiVersion : 사용할 API 버전
  • kind : 배포할 오브젝트 종류
  • metadata : 배포할 오브젝트 정보
  • metadata.name : 배포할 오브젝트 이름
  • spec : 배포할 오브젝트 상세 명세
  • spec.replicas : 항상 떠있길 원하는 Pod의 갯수(Desired)
  • spec.selector : 레플리카셋이 Pod을 찾기 위한 방법 명세
  • spec.selector.matchLabels : 해당 라벨을 가진 Pod를 컨트롤 할 것임을 명세
  • spec.template : 레플리카셋에 의해 배포될 Pod의 템플릿
  • spec.template.metadata.labels : 레플리카셋에 의해 생성될 팟이 자동으로 가지는 라벨
  • spec.spec.containers : 배포될 Pod 안에 들어갈 컨테이너 명세

 

사실 위에서 spec.template 하위 부분은 기존 Pod 배포를 위한 template과 동일한 포맷입니다.

우리는 nginx라는 라벨을 가지는 Pod을 3개로 유지시켜줄 레플리카셋을 만들었습니다.
이제 이 레플리카셋을 배포해봅시다.

$ kubectl apply -f nginx-replicaset.yaml

그럼 확인해봐야겠죠.

$ kubectl get rs

그럼 배포 결과로,

NAME               DESIRED   CURRENT   READY   AGE
nginx-replicaset     3         3         3       6s

이런 레플리카셋을 확인할 수 있죠.
Desired 갯수와 Current 갯수가 같으니, 정상적으로 동작하고 있다는 의미죠.

실제 Pod가 생겼는지 확인해보기 위하여

$ kubectl get pods

명령어를 날려보시면,

NAME          READY   STATUS    RESTARTS    AGE
nginx-b2zdv   1/1     Running      0       6m36s
nginx-vcmts   1/1     Running      0       6m36s
nginx-wtsmm   1/1     Running      0       6m36s

이런 식으로 nginx Pod 3개가 정상적으로 실행되고 있음을 확인할 수 있습니다.
Pod의 이름은 위의 템플릿에서 지정한 'nginx'에 임의의 문자열이 붙어, 자동으로 지정됩니다.

만약 여기서

$ kubectl delete pod nginx-b2zdv

명령어를 실행하면 어떻게 될까요?

nginx 라벨을 가진 Pod의 갯수를 모니터링 하고 있던 레플리카셋
새로운 Pod을 빠르게 생성합니다.

다시 한번

$ kubectl get pods

명령어를 날려보시면,

NAME          READY   STATUS    RESTARTS    AGE
nginx-vcmts   1/1     Running      0       13m5s
nginx-wtsmm   1/1     Running      0       13m5s
nginx-68jdc   1/1     Running      0       10s

이렇게, 해당 Pod는 삭제되고
새로운 이름의 Pod가 새로 생성된 것을 확인할 수 있습니다.

 

테스트를 모두 마친 뒤에는,

$ kubectl delete nginx-replicaset.yaml

명령어를 통해 배포한 레플리카셋을 삭제할 수 있습니다.

 


오늘은 이렇게,
실행 중인 Pod의 갯수를 유지시켜 줌으로써 가용성을 보장해주는
쿠버네티스 레플리카셋에 대해 알아보았습니다.

오늘 예제에서는 생성 시 template으로 고정된 갯수의 Pod을 유지해주는 레플리카셋을 알아보았지만,
kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/

 

Horizontal Pod Autoscaler

The Horizontal Pod Autoscaler automatically scales the number of Pods in a replication controller, deployment, replica set or stateful set based on observed CPU utilization (or, with custom metrics support, on some other application-provided metrics). Note

kubernetes.io

이런 것처럼 트래픽 상태 또는 리소스 상태에 따라
레플리카 갯수(복제될 Pod의 갯수)를 가변적으로 조절할 수도 있습니다.

이런 내용은 추후에 알아볼 거에요.

쿠버네티스는 진입 장벽이 무척 높은 분야입니다.

그럼에도 불구하고,
우린 꽤 잘해가고 있는 중입니다!

그럼, 오늘은 여기까지.
구독과 댓글은 개발자 김모씨에게 큰 힘이 됩니다.

감사합니당당당

반응형

'Skill-UP > Kubernetes' 카테고리의 다른 글

[Kubernetes] 쿠버네티스 namespace  (4) 2020.11.12
[Kubernetes] 쿠버네티스 Pod  (3) 2020.11.11
[Kubernetes] 쿠버네티스 구조  (1) 2020.11.10
[Kubernetes] Kubernetes 소개  (1) 2020.11.06

댓글