controller/ 개념 & replication controller

# 개념

이전에 pod 실행 순서를 설명하면서 써먹었던 그림인데, 파드가 생성되는건 먼저 API에 명령어로 요청을 보내고 etcd에서 노드 정보들을 가져와서 scheduler가 파드를 노드에 알아서 분배해주는 과정으로 pod가 생성된다고 했다.

근데 그 전에도 있던 controller도 포함했는데 설명에 없었다.

controller는 pod의 갯수를 보장해주는? 그런거라고 볼 수있다.

aws의 auto scaling?에서의 수평적 확산 개념과 연동지어서 생각 할 수도 있을듯..? 

파드의 갯수를 보장해준다.

이걸 마스터 노드의 controller가 보장을 해주게 된다.

 

 

 

 

 

# 컨트롤러의 종류

이렇게 일곱가지의 컨트롤러 종류가 있는데, 

cronjob - job은 짝꿍, deployment와 replicaset은 짝꿍이다.

예를들어 deployment를 생성하면 자동으로 replicaset이 생겨나는 이런식.

물론 replicaset만 생성 가능하기도 하다. 다만 deployment를 만들면 자동으로 replicaset이 생성되기에

deployment만 만들 수는 없다.

각각의 역할은 다른데 차근차근 알아보자

 

 

# 생성 명령어

kubectl create 컨트롤러종류 작명이름 --image=이미지이름태그

기본적인 cli명령어인데 보통은 yaml로 만든다.

먼저 가장 기본적인 replication controller부터 보자~

 

 

# replication controller

가장 기본적인 컨트롤러이다. 롤링업데이트, 롤백등이 지원되지않아서 자주 안쓰기때문에 개념설명을 위해서만 설명할예정이다.

 

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    app: nginx
  template:
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

기본 yaml템플릿이다.

 

이걸 좀 자세하게 보자면, 

템플릿에는 익히 알던 pod 템플릿이 있다.

특별하게 labels라는게 있는데 여기서 라벨링을 해줘야

replication controller의 스펙의 selector에 있는 키값쌍과 연결이 된다.

그리고 빨간글씨로 replication controller가 보장하는 pod갯수를 정해서 넣으면 된다.

 

이걸 cli 명령어로 친다면 

kubectl create replicationcontroller [컨트롤러_이름] --image=[이미지_이름:태그] --replicas=[복제_수] --selector=[라벨_셀렉터]

 

양식은 이렇고

kubectl create replicationcontroller test-rc --image=nginx --replicas=3 --selector=app=nginx

이렇게 될거같은데.. ㅅㅂ 내껀 안된다. 

정신건강을 위해 매니페스트(yaml)를 쓰도록 하자

 

 

# 매니페스트에서 템플릿을 분리할 수 있을까?

일단 궁금했던게.. 템플릿에는 pod 양식이 들어가고 그 위에는 replication controller양식이 있었는데 이 두가지를 분류 할 수 없을까? 했었다.

첫번째로는 두가지 yaml로 나눴었다.

apiVersion: v1
kind: Pod
metadata:
  name: label-demo
  labels:
    app: muzzi
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

이게 템플릿 pod부분의 양식이었고

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  # modify replicas according to your case
  replicas: 3
  selector:
    matchLabels:
      app: muzzi

이게 replication controller 부분의 양식이었다.

 

이러고 replication controller을 create -f 로 생성하려했는데 안됐다.

뭐 당연히 셀렉터부분으로 연결되야하는 pod가 없으니 안되는게 당연하다고 생각했다.

 

그래서 먼저

kubectl create -f test-pod.yaml

명령어로 파드를 생성후,

kubectl create -f test-repli.yaml

로 replication controller를 생성하려고 하자

셀렉터에 매치되는 템플릿이 없다고 에러가 떴다.

 

그래서 최종적으로는 

이 replication controller의 selector에 맞는 라벨링이 되어있는 pod 만 있는 양식을 따로 만들어주고,

템플릿이 있는 replication controller 매니페스트로 생성하면 될듯..

사실 공식문서에는 이렇게 pod를 따로 만들어서 관리하지는 말라고한다.

rolling update와 rollback이 지원되는 deployment를 사용하는게 더 나을듯..

 

 

 

 

# 파드를 죽여보자

다시 기본으로 돌아와서..

replication controller로 생성된 세개의 파드가 있다.

kubectl delete pod post-replic-해시

명령어로 한번 파드 하나를 죽여보자.

죽인게 없어지고 새로운 pod가 자동으로 만들어진다.

 

다지워보면?

kubectl delete pod --all

다죽고 새로 또 다 만들어진다.

이렇게 컨트롤러는 pod의 갯수를 보장해준다.

 

 

# replication controller의 갯수 조절하기

이미 생성된 replication controller의 replicas를 조절해주면 된다.

 kubectl edit replicationcontrollers post-repli

이렇게 하면, vi 에디터가 뜨는데

저렇게 숫자를 3에서 2로 바꿔줌.

그리고 wq로 저장하면

하나가 죽는다

 

또다른 방법은 cli로 바꾸는 방법인데

kubectl scale replicationcontroller 레콘이름 --replicas=파드갯수

kubectl scale replicationcontroller post-repli --replicas=5

이렇게 scale로 바꿀 수도 있다.

잘 바뀌어졌다 ㅎ

 

 

#  파드입장에서 얘를 관리하고 있는 controller 알아내기

kubectl describe pod 파드이름

왠만한건 describe에 다 나온다 암튼 보면,

저기 controlled by에 얘를 가지고 있는 컨트롤러가 나와있다.

 

위에도 설명했듯이 selector로 연결을 짓기 때문에 꼭 replication controller 매니패스트 template에 있는 pod가 아니라

따로 생성했지만 labeling이 맞는 pod도 컨트롤러에 의해 관리될 수도 있다.

 

 

 

# pod 생성하면서 라벨링을 cli로 해보자

kubectl run 파드이름 --image=이미지이름태그 --labels=라벨짝꿍

이렇게 라벨달고 나올 수도 있다.

kubectl run test-pod --image=nginx:latest --labels=app=muzzi

 

이렇게하면 이 파드는 app=muzzi라는 라벨링하고 생성된다.

 

 

# 파드 새로 하나만 갈아끼우기

이걸 고민했었는데 deployment를 배우면 있다더라.

현재 pod 가 replication controller 관리하에 세 개가 띄워져 있는데, 이중 하나만 다른 파드로 갈아끼우고 싶다.

라벨링은 같다는 얘기임.

근데 이미 template에 있는 pod들이 replicas갯수에 맞춰 띄워져있기 때문에 같은 라벨링인 pod를 따로만들려해도 띄우자 마자 죽는다.,

 

그럼 어떤 방법이 좋을까? 생각해봤는데,,

일단 replication controller를 지워서 파드 싹다지운다음 pod.yaml로 특정파드 하나 만들고 replication controller yaml을 create 해주면 하나는 특정파드가 되고 나머지 두개는 원래있던거로 동작한다.

근데 이건 중간에 파드들을 지웠다가 다시 만들어주는 텀이 있기에 실제 서비스에서는 안좋은 방법일거다.

어쩃든 이렇게 서로 다른 파드들이더라도 라벨링은 같기떄문에 한 repication controller에 의해 관리되게 될 것이다.

참고로 replication controller는 셀렉터만 보기때문에 rolling update와 rollback등은 지원하지 않는다.

 

 

# 라벨정보 cli로 보기

kubectl get pods --show-labels

현재 띄워진 모든 pod들의 라벨링이 보인다보여

 

 

 

 

 

# 롤링업데이트 안되는 예

kubectl edit rc post-repli

이걸로 container이미지를 버전을 바꿔보자

wq로 저장하고 pod의 describe 이벤트를 보면,

kubectl describe pod 파드이름

버전업데이트가 안되었다..

 

그럼 replication controller로 생성된 파드 하나를 지워보자

kubectl delete pod post-repli-해시

기존에있던 6으로 해시가 시작되는 pod를 지워보았다.

그리고 새로 생성된 j로 시작하는 pod의 describe를 보니

kubectl describe pod post-repli-j머시기

이렇게 새로 생긴건 새로 edit한 버전이 적용되어 생성되었다.

 

실무에서 이렇게 매번 버전을 edit할때마다 pod들을 다 삭제하고 생성하고 하기엔 번거롭기때문에 rolling update와 rollback이 필요한거다.

 

 

 

 

 

# 컨트롤러만 지우기

kubectl describe pod post-repli-6k9ls | grep Controll

먼저 replication controller로 생성된 파드 하나의 describe를 보면

아렇게 controller가 잘 나와있다.

그럼 이제 얘를 관리하는 replication controller를 지워보겠다.

kubectl delete rs 레플이름 --cascade=false

이렇게 컨트롤러만 지우면 이 replication controller로 생성된 템플릿에 있던 pod들은 살아남고

replication controller만 삭제되게 된다.

false도 되는데 orphan으로 고아만들라고 한다. 근데 뭐 작동은 된거다.

그리고 다시 아까 있던 pod의 describe를 보면,

controlled by가 사라져버렸다.

 

 

 

 

+ selector의 AND연산

지금까진 셀렉터를 한개만 했는데, 셀렉터에 키값쌍을 두개 이상 쓰면 무슨 의미일까?

저 키 라벨이 모두 있는 파드들만 해당된다는 것이다.

따라서 저 사진같은 yaml파일로 생성을 해보면,

셀렉터가 맞지않는다면서 안된다.

즉 라벨 두개다 해당되는 애들만 이 replication controller로 관리하겠다는 의미가 된다.

 

 

 

+ 과제

apiVersion: v1
kind: ReplicationController
metadata:
  name: rc-mainui
spec:
  replicas: 2
  selector:
    app: main
  template:
    metadata:
      name: apache
      labels:
        app: main
        rel: stable
    spec:
      containers:
      - name: apache-con
        image: httpd:2.2
        ports:
        - containerPort: 80

요건 과제

 

 

 

 

 

 

replication controller 공식문서

https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/

ReplicationController