kubernetes 레플리케이션과 그밖의 컨트롤러

쿠버네티스는 파드를 직접 생성하는것이 아니라 

레플리케이션 컨트롤러 또는 디플로이먼트등을 생성해 파드를 생성하고 관리해준다.

 

쿠버네티스의 이점 중 하나는 쿠버네티스에 컨테이너 목록을 제공하면 해당 컨테이너를 클러스터 어딘가에서 계속 실행 할 수 있다는 점이다.

파드가 노드에 스케줄링 되는 순간 노드의 kubelet은 파드의 컨테이너를 실행하고 파드가 존재하는한 컨테이너가 계속 실행되게 한다.

이때 컨테이너가 충돌이나면 kubelet 이 컨테이너를 다시 시작하는데 어플리케이션이 다시 시작되도록 외부에서 어플리케이션 상태를 체크해야 한다.

 

이걸 liveness probe 를 통해 알 수 있다.

 

라이브니스 프로브

쿠버네티스는 라이브니스 프로브를 통해 컨테이너가 살아 있는지 확인한다.

spec에서 각 컨테이너의 라이브니스 프로브를 지정할 수 있다.

쿠버네티스는 주기적으로 프로브를 실행하고 프로브가 실패하면 컨테이너를 다시 시작한다.

 

컨테이너에 프로브를 실행하는 메카니즘

• HTTP GET 프로브는 ip주소, 포트, 경로에 GET 요청을 수행해서 오류를 나타내지 않으면 성공으로 간주한다. 응답이 없으면 컨테이너를 다시 시작
• TCP 소켓 프로브는 컨테이너 지정 포트에 TCP 연결을 시도해서 성공하면 프로브가 성공 실패시 컨테이너 재시작
• EXEC 프로브는 컨테이너 내부에 임의 명령어를 실행하고 종료 상태 코드를 확인한다. 상태 코드가 0이면 성공 다른 경우 컨테이너 재시작

 

효과적인 라이브니스 프로브 생성하기

 

 

livenessProbe:
  httpGet:
    path: / 
    port: 8080

initialDealySeconds: 15
periodSeconds: 10
timeOutSeconds: 1
successThreshold: 1
failureThreshold: 3

initialDealySeconds: 첫 번쨰 프로브 실행까지 딜레이 하는 시간

periodSeconds: 얼마나 자주 프로브를 실행할지에 대한 값

•  

timeOutSeconds: 프로브 타임 아웃 시간

successThreshold: 연속적으로 성공해야하는 횟수

failureThreshold: 재시도 횟수

 

 

라이브니스 프로브 확인 해야할 사항

 

• 어플리케이션 내부만 체크해야한다 예를들어 DB의 문제인데 실패를 반환하면 안된다. 컨테이너가 재시작되도 해결되지 않기때문에
• 프로브는 가벼워야한다. 너무 많은 일을 하는 프로브는 컨테이너의 속도를 늦춘다.
• 재시도 루프를 구현하지 말자. 

 

여기까지 컨테이너 충돌이 발생했을때 라이브니스 프로브로 해결하는 법을 배웠다.

 

근데 노드 자체에 문제가 있다면?

kubelet은 워커노드에 있기때문에 노드 자체가 문제라면 할 수 있는게 없다.

이걸 해결하려면 다른 방법을 사용해야 한다.

 

 

레플리케이션 컨트롤러

클러스터에서 노드가 사라지거나 노드에서 파드가 제거된 경우

사라진 파드를 감지해 교체 파드를 생성한다.

 

파드 B를 레플리케이션 컨트롤러가 관리하고 있다면 사라진 것을 인지하고 새로운 파드 인스턴스를 다른 노드에 생성한다.

파드 A는 레플리케이션 컨트롤러가 관리하지 않고 있기 때문에 다시 생성 되지 않는다.

 

 

레플리케이션 컨트롤러의 동작

파드 목록을 지속적으로 모니터링 하고, 실제 파드 수가 의도한 수가 일치하는지 확인

너무 많으면 초과하는 파드 수를 줄이고

적으면 파드 템플릿에서 복제본을 만든다.

 

레플리케이션 컨트롤러의 세가지 요소

• 레이블 셀렉터: 레플리케이션 컨트롤러의 범위에 있는 파드를 결정
• 레플리카 수: 실행할 파드의 의도하는 수를 지정
• 파드 템플릿: 새로운 파드 레플리카를 만들 때 사용  

 

 

수동 또는 자동으로 파드를 쉽게 수평 확장 할 수 있게 한다.

 

레플리케이션 컨트롤러 생성

apiVersion: v1
kind: ReplicationController
metadata:
  name: kubia
spec:
  replicas: 3
  selector:
    app: kubia
  template:
    metadata:
      labels:
        app: kubia
    spec:
      containers:
      - name: kubia
         image: luksa/kubia
         ports:
           - containerPort: 8080

 

생성 명령어

kubectl create -f kubia-rc.yaml

레플리케이션컨트롤러 작동 확인

kubectl get pods

레플리케이션컨트롤러 정보 얻기

kubectl get rc

레플리케이션컨트롤러의 세부 정보 표시

kubectl describe rc kubia

 

노드 장애 대응

노드 장애가 발생하면 발생한 노드는 not know 로 상태를 변경하고 

새로운 파드를 생성시킨다. 

만약 장애 노드가 재부팅 되면 노드는 준비상태로 돌아오고 now know 파드는 삭제시킨다.

 

파드의 이동

레플리케이션 컨트롤러는 레이블 셀렉터와 일치하는 파드만 관리한다.

파드의 레이블이 변경되면 레플리케이션 컨트롤러의 범위에서 제거되거나 추가 될 수 있다.

 

파드 템플릿 변경

파드 템플릿은 언제든지 수정이 가능하다.

파드 템플릿을 변경해도 기존 파드엔 영향을 미치지 않고 새로 생겨나는 파드에만 영향을 준다.

 

 

레플리케이션 파드의 수 확대 축소

replicas 수를 변경해서 파드 수를 늘릴 수 있다.

 

ReplicaSet

 

초기에는 레플리케이션 컨트롤러가 파드를 복제하고 장애시 재스케줄링 해주는 유일한 구성요소였지만

레플리카셋이 나오면서 완전히 대체해버렸다.

일반적으로는 레플리카셋을 직접 만들지 않고 상위 수준의 디플로이먼트로 자동 생성한다.

 

 

레플리카셋과 레플리케이션컨트롤러 비교

레플리카셋은 레플리케이션컨트롤러와 똑같이 동작하지만 더 풍부한 표현식을 사용하는 파드 셀렉터를 가지고 있다.

• 레플리카셋의 셀렉터는 파드나 레이블의 값과 상관 없이 특정 레이블의 키를 갖는 파드를 매칭시킬 수 있다.
• 하나의 레플리카 셋으로 두 파드 세트를 모두 매칭시켜 하나의 그룹으로 취급할 수 있다.

apiVersion: apps/v1beta2
kind: ReplicaSet
metadata:
  name: kubia
spec:
  replicas: 3
  selector:
    matchLabels:
       app: kubia
   template:
     metadata:
       labels:
         app: kubia
      spec:
        containers:
        - name: kubia
          image: luksa/kubia

 

레플리카셋은 apiVersion을 지정해줘야한다.

유일한 차이점은 셀렉터에 matchLabels를 지정해주는 것이다.