[K8s] 쿠버네티스 ReplicaSet의 개념

 

ReplicaSet은 Pod 복제본을 생성하고 관리한다

더 이상 N개의 Pod을 생성하기 위해 생성명령을 N번실행할 필요가 없다

ReplicaSet오브젝트를 정의하고 원하는 Pod의 개수를 replicas속성으로 선언한다

클러스터관리자대신 Pod수가부족하거나 넘치지 않게 Pod 수를 조정

 

레플리카셋을 사용하는 시기

쿠버네티스 공식 docs에서 말하는 레플리카셋은 지정된 수의 파드 레플리카가 항상 실행되도록 보장한다. 그러나 디플로이먼트는 레플리카셋을 관리하고 다른 유용한 기능과 함께 파드에 대한 선언적 업데이트를 제공하는 상위 개념이다. 따라서 우리는 사용자 지정 오케스트레이션이 필요하거나 업데이트가 전혀 필요하지 않은 경우라면 레플리카셋을 직접적으로 사용하기보다는 디플로이먼트를 사용하는 것을 권장한다.

이는 레플리카셋 오브젝트를 직접 조작할 필요가 없다는 것을 의미한다. 대신 디플로이먼트를 이용하고 사양 부분에서 애플리케이션을 정의하면 된다. 

Pod에 문제가 생겼을 때 Pod는 즉시 종료되고 클라이언트의 요청을 처리할 수없다. 또한 클러스터 관리자가 하루종일 사시사철 Pod의 상태를 감시하고 정상 복구해야 한다 그렇기 때문에 N개의 Pod를 실행하고 상태 이상에 대비할 필요가 있게 된다 그렇기 때문에 Replicaset 오브젝트를 사용한다

 

 

내결함성을 요구

장애 허용 (Fault tolerant system) 시스템을 구성하는 부품의 일부에서 결함(fault) 또는 고장(failure)이 발생하여도 정상적 혹은 부분적으로 기능을 수행할 수 있는 시스템이다 즉 소프트웨어는 내결함성을 가진다 다시 얘기해 보자면

 

- 소프트웨어나 하드웨어실패가 발생하더라도 소프트웨어가 정상적인 기능을 수행할 수 있어야 한다

- 소프트웨어가 내결함성이 없으면 고객요구사항을 만족시킬 수 없다

- 사람의 개입 없이 내결함성을 가진 소프트웨어를 구성할 수는 없을까?

 

 

Pod/노드 상태에 따라 Pod의 수를 조정할 수 있도록 ReplicaSet에게 역할을 위임한다

- ReplicaSet을 이용해 Pod복제 및 복구작업을 자동화

- 클러스터관리자는 ReplicaSet을 만들어 필요한 Pod의 개수를 쿠버네티스에게 선언한다

- 쿠버네티스가 ReplicaSet요청서에 선언된 replicas를 읽고 그 수만큼 Pod실행을 보장한다

이제 Replicaset으로 배포를 해보겠다(컨테이너 이미지는 준비되어 있다)

apiVersion: apps/v1 #Pod와 다르게 apiVersion은 apps/v1이다
kind: ReplicaSet    #오브젝트 종류는 ReplicaSet
metadata:           # 배포할 ReplicaSet 이름
  name: blue-replicaset
spec:				
  replicas: 3    	# 복제할 Pod의 갯수
  selector:		# Pod template에서 지정한 label app: blue-app을 
    matchLabels:	# selector로 리소스 지정하여 ReplicaSet에 의해 관리하게된다
      app: blue-app
  template:			# 여기서 부터는 Pod의 내용과 비슷하다
    metadata:
      labels:
        app: blue-app
    spec:
      containers:
      - name: blue-app
        image: yoonjeong/blue-app:1.0
        ports:
        - containerPort: 8080
        env:
        - name: NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        - name: NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
        resources:
          limits:
            memory: "64Mi"
            cpu: "50m"

실행하고 조회한다면 아래의 그림처럼 보인다

$ kubectl get <오브젝트 종류> <오브젝트 이름> -o wide
$ kuvectl get pod -o wide

replicas를 3으로 지정했기 때문에 3개의 Pod가 서로 다른 Node에 지정된 걸 확인할 수 있다.

 

이번에는 dexcribe 명령어로 조회해보자 조회한다면 아래의 이벤트에 3개의 Pod가 생성된 걸 확인할 수 있다 

blue-replicaset뒤에 붙은 문자와 숫자의 조합은 replicaset의 해시값이다

$ kubectl describe <오브젝트 종류> <오브젝트 이름>

 

ReplicaSet의 Pod 생성 이후 과정을 더욱 자세하게 확인해보자

# 이벤트만 조회 하기위해 events 커멘드를 사용하고 가독성을 위해 --sort-by옵션으로 생성시간으로 정렬했다
$ kubectl get events --sort-by=.metadata.creationTimestamp

시간순서부터 확인해보자면 replicaset에 의해 Pod가 만들어지고 스케쥴링에 의해 각 노드에 할당되어 컨테이너가 생성되고 실행되기까지 자세하게 확인할 수 있다.

마지막으로 Pod를 로컬과 포트바인딩을 해서 로드벨런싱이 이루어지고 있는지 확인해 보자

curl 명령어로 컨테이너 내부에 설정한 endpoints로 요청을 여러 번 확인해도 Pod IP가 변하지 않고 같은 IP를 통해 응답을 한다는 걸 알 수 있다 ReplicaSet은 로드벨런싱을 지원하지 않고 있다.

 

Replicaset을 삭제 해보고 다시 한번 실행해서 내결함성을 어떻게 지키는지 확인해보자

$ kubectl delete <오브젝트 종류> <오브젝트 이름>

삭제했다면 위에서 배포해했던 똑같은 ReplicaSet을 배포를해보자 기억할건 replicas를 3을준것만 기억하자

이번에는 Pod를 하나 삭제 해보고 어떤 상태가되는지 확인해보자 하나의 터미널 더 띄우고 아래의 명령어로 상태를 실시간으로확인 

# -w는 watch 모드 이다
$ kubectl get pod -w

 

그다음 Pod를 삭제 해보겠다 첫번째 Pod를 삭제하는순간 새로운 Pod를 생성하고 있고

새로운 Pod 라는걸 아는건 뒤에 헤시값이 다르기때문이다 이렇게 ReplicaSet은 설정한 replicas를 유지하려한다

다시 조회해보면 처음 배포 했을 때와는 다르게 새로운 Pod가 생성된걸 확인할 수 있다

 

describe 명령어로 replicaset을 확인 해보면 다시 확인이 가능하다

$ kubectl describe <오브젝트 종류> <오브젝트 이름>

 

이번에는 replicas를 2로 수정해보고 어떻게 상태가 바뀌는지 확인해보겠다

2로 지정하는 순간 Pod 하나가 삭제되는걸 확인 할 수있다 replicaset을 조회하면 2개의 파드만을 관리하게된다

$ kubectl scale rs <오브젝트 이름> --replicas=<조정할 갯수>

마지막으로는 replicaset을 삭제 할때 --cascade-orphan옵션을 통해 어떤 상태가 일어나는지 확인하려한다

예를 들어보면 delete rs <오브젝트 이름> 명령어를 입력한다면 replicaset가 관리하는 Pod들까지 삭제가된다 하지만 

뒤에 --cascade-orphan옵션을 준다면 지정한 replicaset만 삭제가되고 Pod는 유지되어 replicaset의 관리에서 벗어나게된다

바로이게 고아 전략이다

확인해보기전에 일단 Pod의 Owner을 확인해보자 확인 해본다면 처음에 ReplicaSet 이름인 blue-replicaset인걸 확인했다

# 뒤에오는 json경로는 kubectl get <오브젝트 종류> <오브젝트 이름> -o json
# 형식에서 확인해보면 설정한 경로에 Owner가 누구인지 즉 관리하는 오브젝트가 누군지 알 수 있다
$ kubectl get pod <pod-name> -o jsonpath="{.metadata.ownerReferences[0].name}"

이제 고아전략으로 replicaset을 삭제 시켜보겠다

삭제하고 rs와 pod를 조회했더니 replicaset은 찾을 수 없다고 출력해주고있고

Pod는 잘 출력이된걸 확인 할 수있다

그렇다면 이상태에서 우리가 배포한 yaml파일 자체에서 replicas를 4로 수정하고 다시 배포하면 어떤상태일지 확인 하자

 

yaml을 수정하고 배포하는 순간 Pod는 2개가 생성이되고 Replicaset은 4개로 확인이되었다

분명 전에 고아전략으로 두개의 Pod는 Replicaset의 관리에서 벗어났다

하지만 replicas만 4로 수정했다.그래서 기존에 있었던 2개의 Pod도 다시 Replicaset의 관리로 들어갔기 때문에

4개의 Pod가 생성되는 것이아닌 2개의 Pod만 생성되는 것이다

 

 

 

 

정리

- ReplicaSet을이용해서Pod복제본(replicas)을생성하고관리한다

- 여러 노드에 걸쳐 배포된 Pod Up/Down 상태를 감시하고 replicas 수만큼 실행을 보장한다

- ReplicaSet의spec.selector.matchLabels는PodTemplate부분의 tspec.template.metada.labels와 같아야 한다

- spec.replicas를선언하지않으면기본값은1이다

 

기술 출처

https://kubernetes.io/ko/docs/concepts/workloads/controllers/replicaset/

레플리카셋