ETC

[CKA] kubernetes Controller - ReplicaSet

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

이번 시간에는 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
저작자표시