조금 평범한 개발 이야기

개요 k8s 는 클러스트 노드에 대한 장애 내성을 가지고 있어 문제가 있다고 판단하면 컨테이너를 재시작 합니다. 문제가 있다는 것을 판단하는 기준은 다양한데 k8s worker 문제가 있어 활성 프로브 (LivenessProbe) 의 응답을 제대로 받지 못하거나 OOM 에러와 같이 컨테이너가 필요한 메모리를 충분히 확보하지 못했을때 발생 됩니다. 이렇게 다양한 기준으로 컨테이너가 종료되는데 원인을 파악하는 방법에 대해서 알아 보도록 하겠습니다. 컨테이너 상태 확인하기 컨테이너가 재시작 되면 재시작되기 직전의 종료 상태가 컨테이너 설정에 남는데 이를 먼저 확인해 봅니다. 컨텍스트에 있는 파드 리스트를 확인해 보겠습니다. (⎈ |jogeum-context:default)❯ kubectl get pods NA..

개요 k8s 는 워커의 자원 (cpu, memory) 을 공유하기 때문에 리소스 제한을 통해 파드가 사용할 자원을 미리 정의 합니다. 이는 워커에 있는 파드들이 요구하는 자원이 워커의 자원을 넘어서는 오버커밋 상태가 되었을때 특정 파드가 종료되거나 이상 동작되는 것을 막기 위함 입니다. resources: requests: cpu: 1 memory: 1Gi limits: cpu: 1 memory: 1Gi SPRING BOOT 으로 구성되었고 xms, xmx 메모리 설정이 아래와 같이 run.sh 에 1g 로 설정된 이미지가 있다고 가정해 보겠습니다. # Dockerfile ENTRYPOINT ["./run.sh"] #!/usr/bin/env bash exec java \ -jar /usr/local/se..

리소스 오버커밋 k8s에 파드를 띄울때 리소스 제한을 설정하지 않으면 파드는 워커 vm 에 있는 cpu, memory 를 서로 공유 하게 됩니다. 즉 파드 하나가 worker 의 모든 자원을 사용할 수도 있다는 이야기 입니다. 일반적인 경우에는 문제가 없으나 일순간 파드들이 동시에 많은 cpu, memory 자원을 사용하려고 할때 문제가 발생 됩니다. CPU CPU 의 경우 워커 vm 이 가지는 최대 Core 를 넘어서는 요청이 들어오면 오버커밋 상황이 되며 기대하는 응답 보다 느리게 동작이 됩니다. 이 경우에는 초과되는 요청을 한 파드가 퇴거(evict) 대상으로 지정되지 않으며 단지 워커가 전체적으로 느리게 동작이 될 뿐입니다. MEMORY 메모리의 경우 이와 다르게 최대 메모리 를 넘어서는 오버커밋..