Fairy ' s
[K8s] Replication controller & ReplicaSets 본문
컨트롤러는 쿠버네티스의 두뇌이며, 쿠버네티스 오브젝트를 모니터링하고 반응하는 프로세스이다.
애플리케이션을 실행하는 단일 파드가 있고, 그 애플리케이션과 파드가 죽었다면, 유저는 더 이상 애플리케이션에 접근할 수 없다. 이러한 상황에서도 유저가 애플리케이션에 접근 권한을 잃지 않도록 하고 싶고, 동시에 실행되는 둘 이상의 인스턴스 또는 파드를 가지고 싶을 때, Replication controller가 도움이 된다.
Replication Controller
클러스터에서 파드의 여러 인스턴스를 실행하는 데에 도움이 되며, 이는 곧 고가용성을 제공한다고 할 수 있다. 만약 파드 한 개만 사용할 예정이어도 Replication contoller가 도움이 될 수 있다. Replication contoller는 기존 파드가 죽었을 때, 새로운 파드를 자동으로 불러와 지정된 수의 파드가 항상 실행 중이라는 것을 보장한다.
만약 유저들에게 서비스를 제공하는 하나의 파드가 있을 때, 유저가 늘어나면 로드밸런싱을 위해 추가 파드를 배포한다. 해당 노드의 리소스가 부족해지면 클러스터의 다른 노드에 추가 파드를 배포할 수 있다. Replication controller는 클러스터의 여러 노드에 걸쳐 있기 때문에 여러 노드에서 파드와 애플리케이션의 로드 밸런싱을 하는 데에 도움이 된다.
Replication Controller VS ReplicaSet
- Replication controller는 더 오래된 기술이며, ReplicaSet에 의해 대체되었다.
- ReplicaSet은 Replication을 설정하는 새로운 권장 방법이다.
- 고가용성과 로드밸런싱, 스케일링에 두 기술 모두 적용이 가능하지만, 작동 방식에는 약간의 차이가 있다.
- 이 외의 차이점은 아래에서 더 자세히 설명
Create Replication controller
Replication controller를 만드는 방법은 Pod를 만드는 방법과 큰 차이가 없지만, 4가지 필수 섹션 중 spec에서 차이가 발생한다. spec 섹션에는 Replicaton controller가 Pod를 복제하는 데 필요한 Pod 템플릿을 정의한다. Pod 템플릿을 Pod 생성 시 사용했던 Definition file 내용을 재사용하면 된다.
Replication controller의 Definition File안의 spec에는 template이 있다. template에는 복제할 Pod의 템플릿이 들어가며, 템플릿의 하위에는 metadata, spec이 들어간다. 이 외에도 replicas라는 옵션은 복제본의 수가 들어간다.
# replication.yaml
apiVersion: v1
kind: ReplicationController
metadata:
name: myapp-rc
labels:
app: myapp
type: front-end
spec:
template:
metadata:
name: myapp-pod
labels:
app: myapp
type: front-end
spec:
containers:
- name: nginx-container
image: nginx
replicas: 3
# Replication controller를 yaml로 작성한 후 아래 명령을 실행하면 Replication controller가 생성된다.
$ kubectl create -f replication.yaml
# 생성한 Replication controller 조회
$ kubectl get replicationcontroller
# Replication controller로 시작된 Pod 조회
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
myapp-rc-6mn7d 1/1 Running 0 2m7s
myapp-rc-9bfgk 1/1 Running 0 2m7s
myapp-rc-jh6fx 1/1 Running 0 2m7s
# 생성된 Pod들은 모두 Replication controller에 의해 자동으로 생성되었다.
Create ReplicaSet
apiVersion : Replication controller는 v1를 입력했지만, ReplicaSet은 apps/v1를 지원한다. 만일 v1라고 적으면 아래와 같은 에러가 발생한다.
error: unable to recognize "replicaset.yaml": no matches for /,kind=ReplicaSet
spec : Replication controller와 다른 점은 selector이다. selector는 어떤 파드가 ReplicaSet 아래에 있는지 식별하는 역할을 한다.
- selector : Replication controller에서는 필수 필드는 아니지만 사용이 가능하며, selector를 사용하지 않으면 pod definition file에서 제공된 labes와 동일하다고 가정한다. ReplicaSet에서는 필수로 작성해야 하며, 작성 시 matchLabes를 포함해야 한다.
- matchLabels : Pod의 labels와 매칭되는 정보이다. matchLabels에서는 Replication controller에서 사용하지 못하는 옵션도 제공한다.
- Question. spec 섹션의 template에 Pod의 Definition file 내용을 포함시켰는데 왜 selector 섹션을 작성해야 할까?
- Answer. ReplicaSet을 생성할 때 함께 만들어진 파드가 아닌 다른 파드도 관리가 가능하기 때문이다. 예를 들어, ReplicaSet 생성 전에 있었던 파드들을 selector의 labels와 매칭해주면, ReplicaSet이 Replica(복제본)을 만들 때 해당 파드들도 고려해 Replica를 만들게 된다.
# replicaset.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: myapp-replicaset
labels:
app: myapp
type: front-end
spec:
template:
metadata:
name: myapp-pod
labels:
app: myapp
type: front-end
spec:
containers:
- name: nginx-container
image: nginx
replicas: 3
selector:
matchLabels:
type: front-end
# 생성한 ReplicaSet조회
$ kubectl get replicaset
NAME DESIRED CURRENT READY AGE
myapp-replicaset 3 3 2 10s
# ReplicaSet으로 시작된 Pod 조회
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
myapp-replicaset-2fzmd 1/1 Running 0 12s
myapp-replicaset-8pbw9 1/1 Running 0 12s
myapp-replicaset-qmljw 1/1 Running 0 12s
ReplicaSet의 역할과 Labels, Selectors
만약 프론트엔드 웹 애플리케이션의 인스턴스를 3개 배포했다고 가정할 때, Replication controller나 ReplicaSet을 생성해서 항상 3개의 파드가 실행중인 상태로 만들고 싶다. ReplicaSet을 사용해 기존에 이미 존재하고 있는 파드를 모니터링할 수 있고, 만약 기존에 파드가 없다면 ReplicaSet은 자동으로 파드를 생성해준다. ReplicaSet의 역할은 파드를 모니터링하고 파드가 하나라도 실패하면 새로운 파드를 배포하는 것이다.
이 때, ReplicaSet이 어떠한 파드를 모니터링할 지 정할 수 있는 것이 labels이다. labels는 ReplicaSet에 대한 필터로 제공할 수 있다. selector 섹션에서는 matchLabels 필터를 사용했고, 파드를 생성할 때도 동일한 label을 사용했다. 이렇게 하면 ReplicaSet이 모니터링 할 파드를 알 수 있다.
이전 시나리오에서 3개의 replicas를 생성했었는데, 이미 생성된 3개의 기존 파드가 있는 경우, 그 파드가 항상 3개가 실행되는 것을 모니터링하기 위해 ReplicaSet을 생성해야 한다. 만약 Replication controller가 생성되면 해당 레이블에 이미 3개의 파드가 존재하기 때문에 파드에 새 인스턴스를 배포하지 않는다. 이 상황에서도 ReplicaSet의 spec 섹션에서 template을 작성해야 할까? 이 질문에 대한 답은, 파드 중 하나가 죽을 경우에 ReplicaSet이 파드 수를 유지하기 위해 새 파드를 만들어야 하기 때문에 그 경우를 대비해 template을 작성 해야 한다.
How to scale ReplicaSet
예시로 기존에 3개의 Replicas가 있는 상태에서 6개로 확장해야 한다면 어떻게 ReplicaSet을 업데이트 해야하는지에 대해 알아보자. ReplicaSet을 확장하는 방법에는 3가지 방법이 있다.
1. 첫 번째 방법 : Definition file에서 replicas 수를 6으로 업데이트 한다.
# replicaset.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: myapp-replicaset
labels:
app: myapp
type: front-end
spec:
template:
metadata:
name: myapp-pod
labels:
app: myapp
type: front-end
spec:
containers:
- name: nginx-container
image: nginx
replicas: 6
# 3에서 6으로 변경
selector:
matchLabels:
type: front-end
위와 같이 수정 후 다음 커맨드를 실행한다. 이 커맨드를 통해 ReplicaSet의 수정된 내용을 업데이트 할 수 있다.
' -f ' 옵션을 사용하면 쿠버네티스 리소스가 구성되어 있는 파일을 지정할 수 있다.
# ReplicaSet Update
$ kubectl replace -f replicaset.yaml
$ kubectl apply -f replicaset.yaml
2. 두 번째 방법
다음 커맨드를 실행한다. ' replicaset.yaml ' 파일의 replicas 옵션의 스케일을 6으로 변경하는 커맨드이다.
$ kubectl scale --replicas=6 -f replicaset.yaml
3. 세 번째 방법
type(replicaset)과 name(myapp-replicaset)을 사용해 ' kubectl scale ' 커맨드를 실행한다. 하지만 이렇게 하면 파일이 자동으로 바뀌지는 않기 때문에 여전히 Definition file에는 replica가 3개로 정의되어 있을 것이다.
$ kubectl scale --replicas=6 replicaset myapp-replicaset
Question.
ReplicaSet의 Image 이름을 변경한 후 재배포 하고 싶을 때 어떻게 해야할까?
# ReplicaSet의 yaml 파일을 수정하는 명령어
# 명령어 사용 후 수정하고자 하는 부분의 내용을 수정한다.
$ kubectl edit replicaset <replicaset_name>
### -> 수정 후 저장은 :wq , <Enter>
# Pod 이름을 보기 위해 Pod를 조회한 후,
$ kubectl get pods
# ReplicaSet이 생성한 Pod들을 모두 삭제한다.
$ kubectl delete pods <pods_name>
'Study > K8s' 카테고리의 다른 글
[K8s] kubectl command (0) | 2023.08.07 |
---|---|
[K8s] Deployment (0) | 2023.08.06 |
[K8s] Pods (0) | 2023.07.28 |
[K8s] Kube Scheduler & Kublet & Kube Proxy (0) | 2023.07.12 |
[K8s] CLI (0) | 2023.07.12 |