ETC

[CKA] kubernetes Controller - ReplicaSet

코린이s 2023. 9. 3. 11:45

이번 시간에는 Contoller 종류중 하나인 ReplicaSet에 대해 알아보자!

저번 시간에 알아본 ReplicationController 보다 풍부한 selector를 가지고 있다.

예시를 통해 살펴보자!

이전 ReplicationController의 경우 아래와 같이 정의 하고 label 2개 모두 해당 될 시 관리 대상에 포함된다.

spec:
  replicas: 3
  selector:
    app: webui
    version: "2.1"

ReplicaSet 으로 동일하게 구현 하면 matchLabels를 통해 구현하면 된다.

spec:
  replicas: 3
  selector:
    matchLabels:
      app: webrui
      version: "2.1"

matchLabels으로만 구현도 가능하나 matchExpressions을 이용하면 더 다양하게 컨트롤 할 수 있다.

matchLabels 을 보면 app 이 webui 이여야 하고 matchExpressions 부분을 보면 key 는 version 이면서 operator 는 In 을 사용하여 value 에 있는 값인 2.1 이 포함되어 있다면 관리 대상에 포함된다.

spec:
  replicas: 3
  selector:
    matchLabels:
      app: webui
    matchExpressions:
    - {key: version, operator: In, value:["2.1"]}

만약 app 이 webui 이고 2.1 버전 이거나 2.2 버전인 값을 관리 대상에 포함하고 싶다면 아래와 같이 value 리스트에 넣으면 된다.

spec:
  replicas: 3
  selector:
    matchLabels:
      app: webui
    matchExpressions:
    - {key: version, operator: In, value:["2.1","2.2"]}

만약 app 이 webui 이고 2.1 버전이 포함 되어 있지 않은 파드를 관리하고 싶다면 아래와 같이 operator NotIn 을 사용하면 되며

spec:
  replicas: 3
  selector:
    matchLabels:
      app: webui
    matchExpressions:
    - {key: version, operator: NotIn, value:["2.1"]}

아래와 같이 정의한 key 인 version 이 존재하기만 해도 값이랑 상관없이 관리 대상에 포함될 수 있도록 할 수 있다.

spec:
  replicas: 3
  selector:
    matchLabels:
      app: webui
    matchExpressions:
    - {key: version, operator: Exists}

반대로 version 키값이 없는 파드를 관리 하고 싶다면 아래와 같이 operator 를 사용하면 된다.

spec:
  replicas: 3
  selector:
    matchLabels:
      app: webui
    matchExpressions:
    - {key: version, operator: DoesNotExist}

이처럼 ReplicaSet 을 사용하면 좀 더 쉽게 파드를 관리 대상에 포함 시킬 수 있다.

이제 실제 실습을 진행해보자!

아래와 같이 nginx replicaSet을 생성한다.

# rs-nginx.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: rs-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webui
  template:
    metadata:
      name: pod-nginx
      labels:
        app: webui
    spec:
      containers:
      - name: pod-nginx
        image: nginx:1.14

이제 해당 RepllicaSet 을 생성한다.

$ kubectl create -f rs-nginx.yaml

이제 파드가 정상적으로 생성되었는지 라벨과 같이 보면 정상적으로 3개가 생성 되었다.

replicaset name 명으로 뒤에 해시 난수가 붙어서 파드가 생성되니 replicaset을 통해서 생성된 파드인것을 알 수 있다.

$ kubectl get pod --show-labels
NAME             READY   STATUS    RESTARTS   AGE   LABELS
rs-nginx-98xsb   1/1     Running   0          33s   app=webui
rs-nginx-gw854   1/1     Running   0          33s   app=webui
rs-nginx-xprdc   1/1     Running   0          33s   app=webui

replicaSet 을 확인하는 명령어로 확인 할 수도 있다. 

3개 요청(DESIRED), 현재 생성된 파드(CURRENT)가 3개 , 준비된 파드 (READY)가 3개 인것을 알 수 있다.

$ kubectl get rs
NAME       DESIRED   CURRENT   READY   AGE
rs-nginx   3         3         3       19s

ReplicationController와 동일하게 파드 하나 삭제시 동일하게 생성 되는지 확인해보면 바로 다시 3개가 생성 되었음을 알 수 있다.

$ kubectl delete pod rs-nginx-XXX
$ kunectl get pod
NAME             READY   STATUS    RESTARTS   AGE   LABELS
rs-nginx-gw854   1/1     Running   0          64s   app=webui
rs-nginx-sfw46   1/1     Running   0          2s    app=webui
rs-nginx-xprdc   1/1     Running   0          64s   app=webui

이제 scale 을 이용하여 replica 수를 3개 > 2개 로 변경해보자!

ReplicationController와 동일하게 2개의 파드가 떠있음을 알 수 있다.

$ kubectl scale rs rs-nginx --replica=2
$ kubectl get rs
NAME             READY   STATUS    RESTARTS   AGE    LABELS
rs-nginx-gw854   1/1     Running   0          103s   app=webui
rs-nginx-xprdc   1/1     Running   0          103s   app=webui

우리는 rs 를 제거할 시 rs 가 관리하고 있는 파드도 같이 삭제 되는것을 알고 있다.

만약 파드는 그대로 유지하고 싶은데 가능할까? 가능하다! --cascade=false 를 넣어 주면 된다.

$ kubectl delete rs rs-nginx --cascade=false

아래와 같이 rs 확인해보면 삭제 되었으나 pod 확인시 그대로 라벨이 붙은채로 유지  되어 있다.

$ kubectl get rs
No resources found in default namespace.
$ kubectl get pods --show-labeles
NAME             READY   STATUS    RESTARTS   AGE     LABELS
rs-nginx-gw854   1/1     Running   0          2m38s   app=webui
rs-nginx-xprdc   1/1     Running   0          2m38s   app=webui

이제 실습을 종료 하기위해 모든 파드를 제거한다.

$ kubectl delete pod --all

이제 version 이라는 키값이 있는 파드가 있다면 관리 할 수 있도록 replicaset을 만들어보자!

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: rs-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webui
    matchExpressions:
    - {key: version, operator: Exists}
  template:
    metadata:
      name: pod-nginx
      labels:
        app: webui
        version: "1.0"
    spec:
      containers:
      - name: pod-nginx
        image: nginx:1.14

아래와 같이 version 태그가 붙은 파드가 3개 생성 된 것을 볼 수 있다.

$ kubectl get pod --show-labels 
NAME             READY   STATUS    RESTARTS   AGE   LABELS
rs-nginx-8w48g   1/1     Running   0          27s   app=webui,version=1.0
rs-nginx-ddm84   1/1     Running   0          27s   app=webui,version=1.0
rs-nginx-shr84   1/1     Running   0          27s   app=webui,version=1.0

이제 버전 키만 가지고 관리 하는지 보기 위해 라벨 버전과 container 이미지 버전을 변경 한다.

$ kubectl edit rs rs-nginx
...
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: webui
        version: "1.1"
      name: pod-nginx
    spec:
      containers:
      - image: nginx:1.15
..

이제 파드를 하나 삭제하여 해당 버전이 적용된 파드가 생성 되는지 본다.

$ kubectl delete pod rs-nginx-XXX
$ kubectl get pod --show-labels
NAME             READY   STATUS    RESTARTS   AGE     LABELS
rs-nginx-cxflp   1/1     Running   0          15s     app=webui,version=1.1
rs-nginx-ddm84   1/1     Running   0          3m51s   app=webui,version=1.0
rs-nginx-shr84   1/1     Running   0          3m51s   app=webui,version=1.0

정상적으로 1.1 버전의 파드가 생성 된 것을 볼 수 있으며 version 키값이 존재하면 관리 된다는것을 알 수 있다.

이처럼 ReplicaSet을 사용하면 ReplicaController 보다 더 정교하게 컨트롤 할 수 있다.

이제 실습을 마치며 모든 파드를 제거한다.

$ kubectl delete rs rs-nginx
replicaset.apps "rs-nginx" deleted
$ kubectl get pod
No resources found in default namespace.

끝!

728x90
저작자표시 (새창열림)