POD & Replica

오늘은 컨디션이 영 나쁘지 않네.

실습 2개 Clear~

POD

• Pod는 code cloud에서 실습을 진행함. 크게 어렵지 않았음

• kubectl edit pod name을 하면 pod를 직접 수정하고 수정된 파드가 자동으로 배포된다.

Replica Set

• 파드의 운영을 도와주는 Controller. 보통 직접 수정하는 일은 잘 없고 Deployment Controller에서 제어된다.

• 기본적으로 여러 파드를 운영해서 손쉽게 HA를 구성할 수 있다는 장점이 있다.

• 단일 파드여도 Replica는 자동 회복 기능을 제공한다.

• 여러 유저가 늘어나면 레플리카는 LB과 Scaling을 수행한다.

• Replication Controller와 Replica Set는 둘의 목적같지만 같지 않다.

  • Replication Controller는 더 오래되었으며 Replica Set으로 대체되었다.
  • Replica Set은 레플리카를 구성하기 위해 더 추천되는 방법이다.
  • 둘의 가장 명확한 차이는 selector의 유무이다. Replica Set은 셀렉터가 있다.

label과 selector

• k8s에서 얘네는 왜 쓸까?
• 가령 3개의 웹 애플리케이션이 동작하고 있고, 레플리카 컨트롤러나 레플리카 셋이 이 세 애플리케이션을 항상 구동시키려고 한다고 가정해보자.
  • 레플리카는 지속적으로 파드들을 감시하고 에러가 생기면 새로운 파드를 배포하는 등의 역할을 담당하게 될 것이다.
  • 만약 수 천개의 파드가 있다면 레플리카로 이들을 모두 감시할 수도 있을 것이지만 이를 쉽게 구분하기 위해 우리는 Label을 사용한다.
• 수 천개의 파드 중 라벨로 지정된 3개의 pod들을 레플리카 컨트롤러로 관리하고 싶다면 파드에 라벨을, 레플리카셋에 셀렉터로 라벨의 이름을 지정해주면 손쉽게 관리할 수 있을 것이고 이것이 라벨과 셀렉터의 존재 이유이다.

scale 조정 명령어

kubectl replace -f replicaset.yml

kubectl scale --replicas=6 -f replicaset.yml

kubectl scale --replicas=6 replicaset harry-replicaset