들어가며:
레플리케이션 컨트롤러 소개
레플리케이션 컨트롤러 생성
레플리케이션 컨트롤러 확인
레플리케이션 컨트롤러와 파드
레플리케이션 컨트롤러와 레이블
파드의 수평 스케일링
레플리케이션 컨트롤러 및 파드 삭제
끝마치며:
들어가며:
쿠버네티스의 컨트롤러는 파드를 올바르게 동작하기 위해 특정 상태를 보장하기 위한 컨트롤러입니다. 특정 상태는 컨트롤러에 따라 동작하는 방식 및 정의하는 상태가 조심씩 다릅니다.
쿠버네티스 초기부터 이어져온 서비스 중 1개 입니다.
레플리카셋은 레플리케이션 컨트롤러를 대체하기 위해서 만들어졌기 때문에 거의 유사합니다.
그래서, 현재는 레플리케이션 컨트롤러보다 레플리카셋 또는 레플리카셋의 상위 개념인 디플로이먼트를 권장합니다. 레플리케이션 컨트롤러를 사용할 일은 없지만 아직까지는 사용할 수 있습니다.
레플리케이션 컨트롤러(ReplicationController) 소개
레플리케이션 컨트롤러는 파드가 특정 개수만큼 복제되고 동작하는 것을 보장합니다.
노드의 문제가 발생했거나 파드의 문제가 생겨 원하는 수의 파드가 동작하지 않는다면 자동으로 스케줄러에 의해 새로운 노드나 기존 노드에서 다시 새로운 파드를 생성해 원하는 수의 파드를 유지하고자 복제합니다.
심지어 일반적인 형태에서 발생할 일은 많이 없지만, 파드가 원하는 수보다 많은 경우에도, 원하는 파드 수를 맞춰줍니다.
즉, 불필요한 파드를 제거해 원하는 수를 맞춥니다.
원하는 수의 복제본 보다 더 많은 복제본이 많아질 수 있는 경우:
- 수동으로 동일한 형식을 파드를 생성
- 기존의 파드의 유형을 변경
- 원하는 수의 파드 복제본 수를 줄인 경우
즉, 실행 중인 파드의 목록을 주기적으로 모니터링하고, 원하는 수의 파드 수와 항상 일치시킵니다.
레플리케이션 컨트롤러를 구성하기 위한 세 가지 요소:
- 파드를 지정하는 레이블 셀렉터 [selector]
- 새로운 파드의 복제본을 만들기 위한 파드 템플릿 [template]
- 복제본 수(기본값: 1) [replicas]
레플리케이션 컨트롤러가 제공하는 기능
- 원하는 복제본 수의 파드가 없는 경우 파드 템플릿을 이용하여 파드를 생성
- 노드에 장애가 발생하면 장애가 발생한 노드에서 실행 중이던 파드를 다른 노드에 복제본을 생성
- 수동 or 자동으로 파드를 수평적으로 스케일링 가능
레플리케이션 컨트롤러 생성
//myapp-rc.yaml
apiVersion: v1
kind: ReplicationController
metadata:
name: myapp-rc
spec:
replicas: 3
selector:
app: myapp-rc
template:
metadata:
labels:
app: myapp-rc
spec:
containers:
- name: myapp
image: ghcr.io/c1t1d0s7/go-myweb
ports:
- containerPort: 8080
복제본 수는 3개로 구성하고, 레플리케이션이 관리할 파드의 레이블 셀렉터는 app=myapp-rc 레이블입니다.
레이블 셀렉터의 레이블과 파드 템플릿의 레이블이 맞지 않으면 생성되지 않습니다. 생성할 파드는 템플릿에 정의하였고, 당연히 레이블은 app=myapp-rc로 구성하였습니다.
레플리케이션 컨트롤러 확인
kubectl get replicationcontrollers,pods --show-labels -o wide
원하는(DESIRED) 복제본의 개수는 3개이고, 현재(CURRENT) 존재하는 파드는 3개, 준비(READY) 된 파드도 3개라고 출력하는 것을 볼 수 있습니다.
파드의 이름은 컨트롤러의 이름(myapp-rc)에 무작위 문자 다섯 자가 추가되어 있는 것을 볼 수 있습니다.
레플리케이션 컨트롤러와 파드
레플리케이션 컨트롤러에서 노드의 장애 발생을 가정하고 파드를 삭제했을 때 어떻게 되는지 확인해보겠습니다.
myapp-rc-wsnbm 파드가 삭제되었고, myapp-rc-jh2xq 란 새로운 파드가 생성된 것을 확인할 수 있습니다.
레플리케이션 컨트롤러는 레이블 셀렉터에 의해 관리되는 파드를 확인하고 있다가, 하나의 파드가 없어진 것을 확인하고, 파드의 복제본 수를 맞추기 위해 하나의 파드를 새롭게 생성한 것입니다.
레플리케이션 컨트롤러와 레이블
레플리케이션 컨트롤러는 관리할 파드를 파드의 레이블과 레플리케이션 컨트롤러의 레이블 셀렉터를 이용하여, 관리할 파드를 지정하고 관리하게 합니다.
기존 파드에 레이블 추가
기존 파드에 레이블을 추가했습니다. 결과는 기존 파드에 추가 레이블만 구성되었고 변경사항은 없습니다.
기존 파드의 레이블 변경
app=myapp-rc 를 다른 레이블로 변경해보겠습니다.
myapp-rc-qq4tz 파드의 레이블을 변경한 후, 레플리케이션 컨트롤러는 app=myapp-rc 레이블을 가진 파드가 2개 뿐이기에 새로운 파드를 생성한 것을 확인할 수 있습니다.
이제부터는 qq4tz 파드는 더 이상 myapp-rc 레플리케이션 컨트롤러가 관리하는 파드가 아닙니다.
그렇다면 다시 원래대로 app 레이블값을 myapp-rc로 변경해보겠습니다.
myapp-rc-qq4tz 파드의 레이블을 원래대로 변경했기 때문에 myapp-rc 레플리케이션 컨트롤러의 관리 파드로 지정되었습니다. 그러나 레플리케이션 컨트롤러는 관리할 파드가 4개가 되었으므로, 가장 최근에 생성한 파드 하나를 삭제하게됩니다.
파드의 수평 스케일링
레플리케이션 컨트롤러의 복제본 수만큼 파드를 만들고 관리한다는 것을 확인하였습니다.
그러면 복제본 수를 변경하여 수평 스케일링을 해보겠습니다.
명령을 이용한 스케일링
명령형 커맨드 kubectl scale 명령으로 스케일링이 가능합니다. 복제본 개수를 4로 스케일링 해보겠습니다.
모든 상태가 4개로 구성되었습니다. k9wph 라는 새로운 파드가 추가로 생성된 것을 확인할 수 있습니다.
kubectl describe 명령의 결과 중 Events 필드를 확인해도 어떤 파드가 생성되었는지 확인 할 수 있습니다.
오브젝트 수정을 이용한 스케일링
kubectl edit 명령으로 온라인 상태의 YAML 내용을 수정할 수 있습니다. 기본적으로 vi 에디터로 수정이 가능합니다. 복제본 개수를 하나 더 추가해보겠습니다.
kubectl edit 명령은 스케일링 이외 일부 필드를 온라인 상태에서 변경 가능합니다. 변경한 내용이 문법 오류일 경우 저장이 되지 않고, 변경사항이 반영되지 않습니다. 저장할 때 출력에 "xxx edited"라고 나오는지 반드시 확인해야합니다.
kubectl edit 명령은 KUBE_EDITOR 환경 변수에 에디터를 지정하여 vi/vim 이외의 원하는 에디터로 수정할 수 있습니다.
$ kubectl edit replicationcontrollers myapp-rc
...
**uid**: 5777d867-188d-4764-aaa7-949fbc69e428
**spec**:
**replicas**: 5
**selector**:
...
//출력
replicationcontroller/myapp-rc edited
replicas: 4를 5로 변경한 뒤 저장하고 확인해보겠습니다.
chtcr 이라는 파드가 새로 생성되었으며 총 5개의 파드가 존재하는 것을 확인할 수 있습니다.
오브젝트 파일 수정을 이용한 스케일링
앞서 myapp-rc.yaml 오브젝트 파일을 생성했었습니다. 현재 파드는 스케일링을 통해 다섯 개가 구성되었습니다. 그러나 YAML 파일을 수정한 것은 아니기 때문에 YAML 파일 내에 복제본 수는 3개로 정의되어 있습니다.
YAML 파일을 이용한 스케일링 방법은 YAML 파일을 적절하게 변경한 후 kubectl replace 명령을 사용하는 것 입니다. 이는 기존 생성된 오브젝트의 구성과 YAML 파일의 구성 정보를 비교한 후 변경된 사항에 대해서만 반영을 하게 됩니다.
$ kubectl replace -f myapp-rc.yaml
replicationcontroller/myapp-rc replaced
파일을 변경하지 않고(복제본: 3) 실행했다면, 당연히 현재 5개의 복제본에서 2개의 복제본이 삭제된 것을 확인할 수 있습니다.
레플리케이션 컨트롤러 및 파드 삭제
컨트롤러에 의해 관리되는 파드들은 파드 자체를 삭제한다다고 복제본 조건에 따라 다시 생성됩니다.
만약 삭제하고 싶다면 파드를 삭제하면 안되고, 컨트롤러를 직접 삭제해야 컨트롤러에 의해 관리되는 파드도 같이 삭제가 됩니다.
kubectl delete replicationcontrollers <name>
끝마치며:
레플리케이션 컨트롤러(디플로이먼트와 연결이 되지 않음) 를 대체하기 위해 레플리카셋을 만들어 사용하기 때문에 레플리케이션 컨트롤러는 사용할 일이 없을 것 입니다.
레플리케이션 컨트롤러와 레플리카셋은 유사하지만 약간의 차이점이 존재합니다.
자세한 내용을 알고 싶다면 다음 포스트를 확인하시기 바랍니다.
'Kubernetes > 05. 컨트롤러 종류 및 설명' 카테고리의 다른 글
[쿠버네티스] k8s 레플리카셋(ReplicaSet) 이란? & 레플리케이션 컨트롤러와의 비교 (0) | 2021.06.27 |
---|---|
[쿠버네티스] k8s 스테이트풀셋을 이용한 MySQL 백업 복제본 구성 (4) | 2021.06.25 |
[쿠버네티스] 쿠버네티스 스테이트풀셋 (StatefulSet) 소개 및 관리 (2) | 2021.06.25 |
[쿠버네티스] 디플로이먼트 업데이트 전략(RolliingUpdate, ReCreate, Blue/Green, Canary) (0) | 2021.06.24 |
[쿠버네티스] 데몬셋이란? (0) | 2021.06.17 |