쿠버네티스 [컨트롤러] 정리

JACKJACK·2023년 1월 5일

kubernetes

📝Liveness Probe란?

컨테이너의 상태를 판단해 문제가 생기면 재생성, 관리해주는 역할

쿠버네티스의 가장 큰 이점이 컨테이너 목록을 제공하면 해당 컨테이너를 클러스터의 kubelet이 에러가 난 컨테이너를 다른 어딘가에서 실행 시켜주는 것이다.
kubelet의 역할은 파드가 노드에 스케줄링되는 즉시 파드의 컨테이너가 실행되도록 하는 것이다.
하지만 kubelet도 내부에서 감지하지 못하는 문제(무한 루프, 교착 상태 등)가 발생하면 해결해주지 못해서 Liveness Probe가 외부에서 해결해 주어야 한다. 이 때 Liveness Probe는 헬스체크만 해줄 뿐 컨테이너의 재시작은 kubelet에서 수행한다.

Liveness Probe의 세가지 매커니즘

주기적으로 컨테이너가 살아있는지 http get, tcp, exec 프로브를 통해 확인한다.

HTTP GET 프로브
특정 경로에 HTTP GET 요청을 보내고 HTTP 응답 코드가 2XX 또는 3XX 이면 성공으로 간주
TCP 소켓 프로브
특정 TCP 포트에 연결을 시도해 연결이 되면 성공으로 간주
EXEC 프로브
컨테이너 내의 임의의 명령 (바이너리)을 실행, 명령의 종료 상태 코드가 0이면 성공으로 간주

Liveness Probe생성 및 조회 팁.

다음 GET요청은 5번 수행 후 상태코드 500을 반환받아서 라이브니스 프로브가 실패한것으로 간주해 컨테이너를 다시 시작한다.

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: [imageName]
    args:
    - /server
    livenessProbe: 
      httpGet:  # HTTP Get을 수행할 라이브니스 프로브
        path: /portal # 네트워크 포트 HTTP 요청에서 요청할 경로
        port: 8080 # 프로브가 연결해야 하는 네트워크 포트
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 2 # 컨테이너가 시작하고 2초 후 프로브 시작
      periodSeconds: 10 # 10초마다 프로브 실행

동작중인 Liveness Probe를 조회하려면?
kubectl get po [pod-name]를 수행해 restarts를 보면 라이브니스 프로브로 파드가 몇번 재시작 했는지 알 수 있다.
kubectl describe po [pod-name] 을 통해 컨테이너가 왜 이전에 종료되었는지 확인이 가능하다.
그 외에도 describe를 통해 수행 후 응답까지의 제한시간, 재시작 시간, 실행지연, 컨테이너 재시작의 실패횟수 등을 확인할 수 있다.
Liveness Probe를 정의하지 않으면 k8s 어플리케이션이 살아있는지 확인이 불가하며 항상 정상으로 간주할 것이다.
Liveness Probe는 너무 많은 연산을 사용하지 않도록, 가볍고 응답이 빨라야 좋다. 프로브가 너무 많은 일을 수행하면 컨테이너의 속도를 느리게 할 수 있기 때문이다.

📝Replication Controller(rc)란?

rc는 정확한 수의 파드가 항상 유지되고있는지 확인하고 관리해주는 요소이다.

kubelet은 노드안에 있으므로 노드 자체에서 크러쉬가 나면 재시작이 불가능하다. 따라서 control plain안의 rc에서 파드를 관리해주게 된다.
rc는 레이블 셀렉터를 통해 컨트롤러 범위에 있는 파드를 결정하고 정해진 레플리카 수와 파드템플릿(yaml 파일)에 따라 수평 확장을 해줄 수 있다. 이 때 레이블 셀렉터와 파드 템플릿을 변경해도 기존 파드의 관리를 멈출 뿐 영향을 미치진 않는다.

rc의 생성 및 조회 팁.

kubectl create -f [rcName.yaml] 과같이 생성하며 yaml파일 예시는 다음과 같다.
kubectl get rc [rcName]를 통해 생성한 rc의 조회가 가능하며, kubectl describe rc [rcName]을 통해 rc의 세부정보까지 조회가 가능하다.
kubectl edit rc [rcName]를 통해 rc의 수정이 가능하며 앞서 말한듯 레이블 셀렉터가 바뀌면 기존 파드의 관리를 멈추고, 파드템플릿이 바뀌면 새로 생성되는 파드가 달라진다.
kubectl scale rc [rcName] --replicas=10을 통해 replicas를 3->10으로 변경시 파드를 3->10개로 늘려준다. 반대로 줄이는 스케일링도 가능하다.
kubectl delete rc [rcName] --cascade=false를 통해 rc의 삭제가 가능하며 cascade 옵션을 통해 파드는 그대로 유지가 가능하다.(관리x)
kubectl delete pod [podName]을 수행하고 kubectl get pods 를 수행하면 rc가 하나가 사라짐을 확인하고 pod를 생성해줌을 확인 할 수 있다.

📝Replica Set(rs)란?

rc는 쿠버네티스가 처음 만들어졌을 때 사용한 개념이고 현재는 좀더 고도화된 rs를 사용한다.

rs는 deployment에 의해 생성되는데 이는 나중에 다룰 예정이다. rc은 key= value 한 쌍만 조회가 가능했는데, 레플리카셋은 Gpu=true, SSD = true 등과 같이 한번에 레이블의 여러 조건을 검색, 관리가 가능하다. 다음 사진들을 통해 레이블 셀렉트의 방식이 더 풍부하다는 점을 확인할 수 있다.
rs를 쉽게 풀어말하면 설정한 상태를 유지하는지 비교,확인 하기 위한 문서라고 볼 수 있다. deployment ->rs(replicas = 3) -> pod(3개)