1) Replication
일전에 소개된 컨트롤러 자체는 쿠버네티스의 뇌와 비슷한데, 쿠버네티스의 객체 상태를 확인하고 확인된 상태에 따라 반응하는 형태로 동작
이런 컨트롤러는 여러 종류가 있었는데, 그 중에서 Replication Controller가 이번에 소개할 객체와 관련됨
1. High Availability
Replication Controller가 필요한 경위에 대해 예를 들어 이해해볼 수 있는데, 만일 구동 중인 Pod가 모종의 이유로 동작할 수 없게 되었다고 가정
사용자의 어플리케이션 접근을 끊을 수 없기 때문에 동일한 형태의 Pod를 다중으로 구성하여 구동해줘야 함
Replication Controller는 실행 중인 단일 Pod를 자동으로 복제하여 다중 Pod로 동작할 수 있게 도와 위의 문제를 해결하게 도움
그렇다면 다중 Pod를 유지할 것이 아니라면 Replication 기법이 필요없는가라는 고민이 생길수 있음
노드 내에 한 어플리케이션을 단일 Pod로 운용할 계획이어도 해당 Pod의 상태에 문제가 생기는 경우 Replication Controller는 동작 가능한 단일 Pod를 유지하기 위해 노력하는데, 대체로 Replication 자체가 High Availability 확보를 위한 것임을 알 수 있음
Replication Controller는 정해진 개수의 Pod가 동작할 수 있도록 항상 보장
2. Load Balacing & Scaling
HA 외에도 Replication 기법은 부하를 분산하고, 부하량에 따른 스케일링을 수행할 때 유용하게 사용될 수 있음
예를 들어 트래픽이 늘어 단일 Pod로 부하를 감당할 수 없는 경우, 추가적인 Pod를 노드 내에 두면서 스케일링을 수행하고 각 Pod들로 트래픽이 유입될 수 있도록 밸런싱을 수행하게 됨
만일 노드 내에 가용 자원이 적어서 추가 Pod를 둘 수 없는 경우에도 Replication Controller가 제 기능을 할 수 있을까라는 고민이 들 수 있음
Replication Controller의 단위는 노드가 아니라 쿠버네티스 클러스터 단위이기 때문에 각 노드의 상태를 추적하고 있음
따라서 자원 가용 가능한 노드에 Pod를 추적하고 일정 수의 Pod를 유지하도록 도우며, 노드 단위의 밸런싱을 지원
Replication Controller는 클러스터 내부에 여러 노드에 걸쳐 있음
3. Replica Set
Replication Controller와 Replica Set은 Replication이라는 목적은 같지만 용도가 다름
Replication Controller가 조금 더 구식이며, Replica Set으로 대체되고 있음
동작 방식에 세세한 차이가 있으나, Replica Set을 이용하면 됨
Replication Controller와 Replication Set은 모두 selector를 지원하지만, Replication Set이 조금 더 풍부한 selector의 기능을 수행
둘다 selector가 없는 경우 template에 명시된 Pod들을 대상으로만 수행하지만, selector가 있는 경우는 이에 해당하는 Pod들도 Replication으로 관리
Replication Controller의 경우 단순 Exact Match만 지원하지만, Replica Set의 경우 selector의 matchLabels와 matchExpressions를 지원
** 라벨과 selector는 Replication을 위한 모니터링 시 필터링을 위한 수단
라벨과 selector를 활용하면 모니터링을 위한 Pod를 감시할 수 있는데, 굳이 template이 필요한가라는 고민이 들 수 있음
만일 기존에 생성되어 있는 Pod를 대상으로 Replica Set을 적용하면 굳이 새 Pod를 생성하지 않을 수 있는데, 구동 중인 Pod가 고장나는 등 새로운 Pod를 띄워야하는 판단이 생기는 경우 template이 없으면 Replica Set은 Pod를 생성해낼 수가 없음
따라서 적정 수의 Pod를 유지하기 위해 template이 Pod 생성의 설계도를 제공하는 것이라고 볼 수 있음
두 객체 모두 replicas라는 필드를 통해 REPLICATION을 수행하게 되는데, 이렇게 단순히 숫자를 명시하는 것 말고도 부하에 따라 자동으로 스케일링 하도록 만들 수도 있음
3) YAML
1. ReplicationController
apiVersion: v1, kind: ReplicationController
spec에는 Replication을 얼마나 유지할지 replicas를 수로 명시
spec에는 Replication 대상인 Pod를 지정해야하는데, 이를 template으로 정의하여 지정하는 것이 가능
** Pod를 정의할 때 사용했던 Root Level의 apiVersion과 kind를 제외한 나머지 metadata, spec 필드를 그대로 spec.template에 명시
apiVersion: v1
kind: ReplicationController
metadata:
name: rc-sample
labels:
app: rc-sample
type: rc-sample-type
spec:
template:
metadata:
name: nginx
labels:
app: nginx
type: ws
spec:
containers:
- name: nginx
image: nginx
replicas: 3
selector:
type: ws
YAML
복사
2. ReplicaSet
apiVersion: apps/v1, kind: ReplicaSet
spec은 ReplicationController를 정의할 때와 동일하게 명시
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: rs-sample
labels:
app: rs-sample
type: rs-sample-type
spec:
template:
metadata:
name: nginx
labels:
app: nginx
type: ws
spec:
containers:
- name: nginx
image: nginx
replicas: 3
selector:
matchExpressions:
- key: type
operator: In
values:
- ws
- key: app
operator: In
values:
- nginx
- key: env
operator: NotIn
values:
- prod
YAML
복사
4) Commands
kubectl get replicationcontroller
get pod와 동일한 정보를 Replication Controller 객체에 대해서 얻을 수 있음
kubectl get replicaset
Replica Set의 정보를 얻을 수 있음
kubectl replace -f ${FILE_NAME}
파일 내의 replicas를 수정 후 위 명령어를 실행하여 Replication 변경
kubectl scale —replicas=${REPLICATION} -f ${FILE_NAME}
파일에 해당하는 Replication을 옵션에 기재된 값으로 스케일링 (파일 내의 replicas에는 영향을 주지 않음)
kubectl scale —replicas=${REPLICATION} replicaset ${NAME}
구동 중인 Replica Set을 기재된 값으로 스케일링 (파일 내의 replicas에는 영향을 주지 않음)
kc edit replicaset ${NAME}
위 명령어를 이용하여 Replica Set을 수정할 수 있음
5) Abbreviation
Replica Set == rs