소개

Pod의 성능과 가용성을 높이기 위해 Kubernetes는 기본적으로 "스케일 아웃"합니다. 스케일 아웃은 노드(여기에서는 Pod/컨테이너)의 CPU/메모리를 늘리는 것이 아니라, 노드(Pod/컨테이너)를 늘립니다.
덧붙여서, CPU나 메모리를 늘리는 것은 「스케일 업」.
이 스케일 아웃의 구조로서 ReplicaSet가 있으므로, 이번에는이 동작을 확인해 보겠습니다.

ReplicaSet 만들기

다음 yaml 파일을 만들었습니다.

sampleReplicaSet.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: sample-pod3
spec:
  replicas: 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 apply -f sampleReplicaSet.yaml
replicaset.apps/sample-pod3 created

여기에서는 한 번에 배포할 수 있게 되어 있지만 실제로는 yaml 파일의 실수로 여러 번 오류가 발생합니다.
· 맞춤법 오류
· 들여 쓰기가 잘못되었습니다.
yaml의 서식에도 익숙해지지 않으면.

확인

$ kubectl get rs
NAME          DESIRED   CURRENT   READY   AGE
sample-pod3   3         3         3       16m
$ kubectl get replicasets.apps -o wide
NAME          DESIRED   CURRENT   READY   AGE   CONTAINERS    IMAGES                      SELECTOR
sample-pod3   3         3         3       16m   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-7nxxr   2/2     Running   0          18m   192.168.69.216   k8s-worker02   <none>           <none>
sample-pod3-86kqh   2/2     Running   0          18m   192.168.79.74    k8s-worker01   <none>           <none>
sample-pod3-thbbx   2/2     Running   0          18m   192.168.69.202   k8s-worker02   <none>           <none>

sample-pod3의 복제본이 3개 만들어졌는지 확인할 수 있습니다.
Pod 이름은 "[metadata.name]-[랜덤 영숫자]"입니다.
그건 그렇고, 복제 세트를 확인하는 부속 명령의 'rs'와 'replicasets.apps'는 같은 의미입니다.

포드가 배포되는 worker 노드도 분산되어 있습니다.
그림으로 쓰면 이런 느낌입니다.

셀프 힐링 기능 확인

Kubernetes의 특징으로 셀프 힐링 기능이 있습니다. 이것은 뭔가 장애가 발생했을 경우에도 미리 설정되어 있는 「어야 할 모습」으로 되돌리는 기능입니다.
이 경우의 "해야 할 모습"은 sample-pod3의 복제본이 세 가지라는 것입니다.

작업자 노드 중지

여기서 worker01을 중지합니다. shutdown 할 뿐이므로 할애.
상태를 확인합니다. worker01이 NotReady입니다.

$ kubectl get node
NAME           STATUS     ROLES    AGE   VERSION
k8s-master     Ready      master   11d   v1.17.3
k8s-worker01   NotReady   <none>   11d   v1.17.3
k8s-worker02   Ready      <none>   11d   v1.17.3

ReplicaSet 확인

중지하고 조금 기다린 다음 상태를 확인합니다.

$ kubectl get pod -o wide
NAME                READY   STATUS        RESTARTS   AGE   IP               NODE           NOMINATED NODE   READINESS GATES
sample-pod3-7nxxr   2/2     Running       0          66m   192.168.69.216   k8s-worker02   <none>           <none>
sample-pod3-86kqh   2/2     Terminating   0          66m   192.168.79.74    k8s-worker01   <none>           <none>
sample-pod3-ngw8x   2/2     Running       0          20m   192.168.69.217   k8s-worker02   <none>           <none>
sample-pod3-thbbx   2/2     Running       0          66m   192.168.69.202   k8s-worker02   <none>           <none>
$ kubectl get rs
NAME          DESIRED   CURRENT   READY   AGE
sample-pod3   3         3         3       70m

worker01에 있던 「sample-pod3-86kqh」가 「Terminating」상태가 되어, 새롭게 「sample-pod3-ngw8x」가 worker02에 배치되고 있습니다.
새로 만들어진 곳이 포인트로 Active-Standby와 같은 데이터를 이어받은 페일오버가 아닌 새로운 Pod가 배포되고 있습니다. 즉, 지금까지 worker01에서 처리된 데이터는 인계되지 않았습니다.
Kubernetes에서 제공하는 마이크로서비스는 이러한 방식으로 데이터를 유지하지 않는 '상태가 없는' 앱을 기반으로 합니다.
이를 위해 유지해야 하는 데이터나 로그 등은 다른 볼륨에 저장하기 때문에 이 근처는 또 조사하고 싶습니다.

또한 Pod 배포의 이력은 아래에서 확인할 수 있습니다.

$ kubectl describe rs sample-pod3
Name:         sample-pod3
・・・
Events:
  Type    Reason            Age    From                   Message
  ----    ------            ----   ----                   -------
  Normal  SuccessfulCreate  49m    replicaset-controller  Created pod: sample-pod3-thbbx
  Normal  SuccessfulCreate  49m    replicaset-controller  Created pod: sample-pod3-86kqh
  Normal  SuccessfulCreate  49m    replicaset-controller  Created pod: sample-pod3-7nxxr
  Normal  SuccessfulCreate  3m30s  replicaset-controller  Created pod: sample-pod3-ngw8x

이 Terminating이 되어 있는 Pod는 delete로 지우면 좋다.
쿠베르 자고 s. 이오

$ kubectl delete pod sample-pod3-86kqh
pod "sample-pod3-86kqh" deleted

어쨌든, 사용할 수 없게 된 Pod의 delete까지 해 주면 좋은 생각이 듭니다만, 뭔가 이유라도 있는 것일까?
이제 일단 ReplicaSet의 동작을 확인할 수 있었습니다. ReplicaSet은 Kubernetes를 사용하는 데 중요한 요소라고 생각하기 때문에 좀 더 알아보고 싶습니다.