Kubernetes 기초 - Controller(1)

1. ReplicationController      ←  오늘 볼 내용
2. ReplicaSet
3. Deployment
4. DaemonSet
5. StatefulSet
6. Job
7. CronJob

---

1. ReplicationController

Controller란

 

클러스터 내에서 리소스의 상태를 원하는 상태로 유지하도록 담당하는 엔터티다.

쿠버네티스의 컨트롤러들은 여러 종류가 있으며, 각각 특정 리소스 유형을 관리하며 원하는 상태로 유지하도록 설계되어 있다.

 

 

 

ReplicationController

요구하는 Pod의 개수를 보장하며 파드 집합의 실행을 항상 한정적으로 유지하는 것을 목표한다.

• 요구하는 Pod의 개수가 부족하면 template을  이용해 Pod를 추가
• 요구하는 Pod 수 보다 많으면 최근에 생성된 Pod를 삭제
• 기본 구성
  • selector : 특정 label에 포함되는 파드의 개수를 제어
  • replicas : 원하는 개수를 지정하여 그 수만큼 배포를 유지
  • template : 배포하려는 컨테이너의 구성

# app=webui라는 label을 가진 nginx 컨테이너 3개를 실행하는 명령
kubectl create rc-exam --image=nginx --replicas=3 --selector=app=webui

 

Pod-definition	ReplicationController-definition
apiVersion: v1 kind: Pod metadata:   name: nginx-pod   labels:     app: webui spec:   containers:   - name: nginx-container     image: nginx:1.25	apiVersion: v1 kind: ReplicationController metadata:   name: rc-nginx spec:   replicas: 3   selector:      app: webui   template:     metadata:       name: nginx-pod       labels:         app: webui     spec:       containers:       - name: nginx-container         image: nginx:1.25

 

왼쪽(Pod)과 오른쪽(ReplicationController)의 차이는 배포 리소스 유형이 다른 것이다.

배포할 파드가  template으로 묶여있으며 replicas를 통해 배포 및 유지할 파드의 개수를 지정했다.

여기서 눈여겨봐야할 것은 selector다.

selector를 통해 app이라는 key와 webui라는 value를 가진 파드에 대해서 복제를 진행한다.

이를 통해 쿠버네티스의 컨트롤러는 app: webui라는 레이블(라벨)을 가진 파드의 개수를 검증하고 수가 맞지 않으면 replicas로 설정한 개수만큼만 실행하도록 제어한다.

 

위 yaml코드를 그대로 활용해서 실행시켜보자.

nginx 3개 실행

 

라벨명도 함께 화면에 표시해보면

# 라벨명 확인
kubectl get pods --show-labels

라벨명 표시

 

좀 더 자세하게 보자.

# 더 자세하게 확인
kubectl describe rc rc-nginx

더 자세하게 표시

파드 생성은 성공적으로 3개 다 만들어졌으며 label도 정확하게 적용되었다.

 

 

만약 저 상태에서 app: webui라는 라벨을 가진 컨테이너를 하나 더 생성하면 어떤 일이 발생할까?

# redis.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    app: webui
  name: redis
spec:
  containers:
  - image: redis
    name: redis

 

일단 명령이 실행되기는 하지만 Createing 과정이 나오기도 전에 Terminating 된다.

컨트롤러가 새로운 파드가 생성되려는 것을 검토하여 생성되려고 하는 순간에 제거해버리는 것이다.

 

 

이번에는 ReplicationController의 구성을 바꿔서 3개가 아닌 4개가 복제되도록 만들어보자.

# ReplicationController 구성 수정
kubectl edit rc rc-nginx

replicas 수정

 

에디터 화면에서 다음과 같이 replicas를 4로 수정한다.

하나 더 생성

 

명령을 실행하면 파드 하나가 더 실행된다.

 

이를 스케일 아웃(Scale out)이라고도 하고 수평적 확장이라고도 한다.

수평적 확장이란 시스템의 수를 늘려서 트래픽을 분산시켜 더 많은 요청을 수용하고 성능을 확보하는 방법이다.

반대로 스케일 업(Scale up), 수직적 확장이라는 것도 있는데 이는 자체 시스템의 성능(RAM, CPU)을 증가시켜 더 빠른 처리를 할 수 있게 만드는 것을 말한다.

 

edit 명령이 아닌 scale 명령을 통해서 ReplicationController의 구성을 수정할 수도 있다.

# replicas를 변경하는 또 다른 방법 scale
kubectl scale rc rc-nginx --replicas=2

2개로 줄었다.

 

명령을 실행하면 즉시 파드수를 2개로 축소, 스케일 인(Scale in) 한다.

가장 최근이 만들어진 파드를 종료시키며 설정한 만큼 파드의 개수를 유지한다.

 

 

이번에는 replicas를 수정하지 않고 image의 버전을 수정한다면 어떤 일이 벌어질까?

파드가 종료되었다가 다시 생성될까?

아니면 다르게 동작할까?

 

edit 명령으로 다음과 같이 수정한다면 결과적으로 아무런 변화가 일어나지 않는다.

Controller가 일하지 않는 것이 아니라 Controller는 파드의 수와 Labels을 감시할 뿐 Template은 보지 않는다.

컨테이너 이미지에 변화없다.

 

 

그렇다고 명령이 의미가 없는 것은 아니다.

파드가 종료되었다가 다시 생성되는 경우에 컨트롤러는 tamplate에 명시되어있는 컨테이너의 정보대로 다시 생성하기에 그때는 nginx:1.15로 생성이 되는 것이다.

파드를 제거하고 다시 생성된 후 컨테이너 정보

 

 

이렇게 버전이 업데이트되는 것을 Rolling update라고 한다.

서비스 운영 중에 서비스를 중단하지 않으면서 버전을 바꾸고 비즈니스 연속성을 유지하는 방법이다.

지금은 직접 파드를 삭제하여 버전을 바꿨지만 Rolling update도 여러가지 방법들이 있으니 나중에 알아보도록 하자.

 

 

 

실습

 

1. 다음의 조건으로 ReplicationController를 사용하는 rc-lab.yaml 파일을 생성하고 동작시킵니다.

- labels(name: apache, app: main, rel:stable)를 가지는 httpd:2.2 버전의 Pod를 2개 운영합니다.

- rc name: rc-mainui

- container: httpd:2.2

- 현재 디렉토리에 rc-lab.yaml 파일이 생성되어야 하고, 애플리케이션 동작은 파일을 이용해 실행합니다.

 

2. 동작되는 httpd:2.2 버전의 컨테이너를 3개로 확장하는 명령을 CLI로 적고 실행하세요.

 

 

---

 

 

1번

# 1번 답안
apiVersion: v1
kind: ReplicationController
metadata:
  name: rc-mainui
spec:
  replicas: 2
  selector:
    app: main
  template:
    metadata:
      name: httpd-pod	# 이 필드가 필요한 지 모르겠다. 의미없으니 지워도 상관없다.
      labels:
        name: apache
        app: main
        rel: stable
    spec:
      containers:
      - name: apache-pod
        image: httpd:2.2

 

2번

kubectl scale rc rc-mainui --replicas=3

 

 

 

 

아래 참고는 무시해도 됨.

참고

직접 실습해보니 teplate 하위 metadata 하위 name, generateName이라는 필드는 사용해도 의미가 없다.
나중에 배울 ReplicaSet과 StatfulSet도 똑같이 적용해도 의미없다.

===============================================================================

찾다가 재밌는 것을 발견했다.
generateName이라는 필드로 이름을 정의하면 kubectl delete -f <파일명|URL>로 삭제가 안된다.
삭제할 때는
kubectl delete <type> <name> 혹은
kubectl delete <type> -l <label>
명령을 이용해야 한다.

 

 

 

---

 

 

아래 영상을 참고했습니다.

https://youtube.com/playlist?list=PLApuRlvrZKohaBHvXAOhUD-RxD0uQ3z0c&si=hbPclcPuc-6lTNdE

[따배쿠] 쿠버네티스 시리즈