Kubernetes

Kubernetes Probes & Pod

id1112 2025. 4. 14. 11:15

Kubernetes Probes

Kubernetes는 설정된 probes를 통해 컨테이너를 주기적으로 검사한다.

probes는 Kubernetes가 컨테이너를 자동으로 복구하거나 서비스에서 제외하도록 도와주는 자율 건강 진단 시스템 이다.

1) httpGet

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 10

위에 설정된 것처럼 10초마다 /healthz path 로 HTTP GET 요청을 보낸다. State Code 가 200~399 면 통과시키고 아닐경우 실패하게 된다. 실패하게 되면 재시작한다.

2) exec

livenessProbe:
  exec:
    command:
      - cat
      - /tmp/healthy

컨테이너 내부에서 cat /tmp/healthy 명령어를 실행한다.

exit code 가 0이면 okay이고 아니면 실패가 된다.

 

3) tcpSocket

livenessProbe:
  tcpSocket:
    port: 3306

해당 포트로 tcp 연결을 시도한다. 

 

  • livenessProbe → 컨테이너 자체의 생명
  • readinessProbe → 컨테이너가 서비스 받을 준비 되었는지
  • startupProbe → 앱이 늦게 시작할 때 헷갈리지 않게 유예 시간 주는 용도

 

 

시나리오 1: livenessProbe로 재시작 감지
웹서버가 응답을 안 해 (/healthz 응답 없음)

쿠버네티스는 

컨테이너를 강제로 재시작 


시나리오 2: readinessProbe로 트래픽 차단
DB 연결이 안됨

readiness가 실패:
Kubernetes는 해당 서비스가 준비되지 않았다고 판
클라이언트가 요청 보내도 이 파드한테는 절대 안 감

-> 클라이언트가 요청을 보내도 해당 Pod 에 요청이 가지 않는 다는 말은 무엇일까?

이 말은 해당 Pod를 Kubernetes가 서비스 대상에서 제외한다는 것이다. 그러면 Service가 해당 Pod를 Loadbalancing 대상에서 제외시키고 Client는 해당 Service의 IP로 요청을 보낼 수 있지만 내부적으로는 probes 실행결과 문제가 없는 Pod 들로만 트래픽이 분산된다는 의미이다.

 

readinessProbe 실패의 효과

Kubernetes action - 해당 pod를 "준비되지 않음"상태로 표시

Service action - 해당 pod를 Loadbalancing 대상에서 제외한다

Client Request - 서비스 IP로 보낸 요청은 준비된 pod 한테만 간다.

Network - Pod는 살아있지만 외부 트래픽은 들어가지 않는다.

readlinessProbe 가 OK 되면 kubernetes는 해당 Pod를 다시 서비스 대상에 추가한다.

 

 

Kubernetes Pod

Pod는 Kubernetes에서 사용되는 가장 기본이 되는 실행 단위이다.

"컨테이너 1개 이상을 감싸는 단위"를 의미하며 Kubernetes가 배포하고 관리하는 최소 단위이다.

Kubernets는 컨테이너를 직접 관리하지 않고 Pod를 관리한다.

 

그렇다면 Pod는 왜 존재할까?

Kubernetes 에서는 하나의 기능(예를 들어 웹서버)를 실행할 때 보조 컨테이너도 같이 사용할 수 있다. (예를 들어 로그 수접, 프록시 등) 그래서 컨테이너 여러 개를 묶는 하나의 실행 단위가 필요한데 이때 사용하는 게 Pod 이다.

이론적으로 Pod 안에 컨테이너 개수는 제한이 없지만 일반적으로 1~2개 정도의 컨테이너만 넣는 게 일반저이다. 왜냐면 컨테이너의 개수가 너무 많이지면 디버깅의 어려움, 리소스 충돌 가능성 그리고 복잡성이 증가하게 된다.

 그래서 보통 1개만 넣고 목적에 따라 sidecar(보조 컨테이너) 를 2~3개 추가한다.

 

- Pod 안에 컨테이너들은 같은 네트워크를 공유한다.

Pod 안에 모든 컨테이너는 IP / Port / localhost 를 공유한다. 같은 IP 주소를 가지면 localhost 를 통해 Pod 안에 컨테이너끼리 서로 접근이 가능하다.

 

- Pod 안에 컨테이너들은 같은 스토리지 사용이 가능하다

Volumes 을 공유할 수 있다. 

volumes:
  - name: shared-logs
    emptyDir: {}

containers:
  - name: app
    volumeMounts:
      - name: shared-logs
        mountPath: /logs

  - name: logger
    volumeMounts:
      - name: shared-logs
        mountPath: /logs

둘 다 /logs 폴더를 통해 같은 Volumes 으로 파일 시스템도 공유가 가능하다.

컨테이너 A 가 /data/logs 에 로그를 저장하고 컨테이너 B가 그걸 읽어서 전송하거나 가공하고 있다.

 

-Pod 안에 모든 컨테이너는 항상 같은 노드에 배치되고 동시에 시작되고 함께 재시작되고 함께 죽는다.

하나의 컨테이너 죽으면 전체 Pod가 재시작되고 하나의 컨테이너의 Node 변경 되면 Pod 전체가 같이 이동한다,

이처럼 Kubernetes는 Pod를 가장 작은 단위로 본다.