Pod 안정성을 높이는 쿠버네티스 설정

이 글은 pod 장애를 최소화하기 위한 쿠버네티스 설정을 이야기합니다. 세부 설정 방법은 생략하고 어떤 설정이 Pod안정성과 관련있는지 설명합니다.
 
짧은 기간이지만 제가 약 10개월동안 서비스를 운영하면서 중요하게 느꼈던 쿠버네티스 pod 안전성 설정을 정리했습니다.

팟캐스트(오디오)로도 이 글을 들을 수 있습니다.
https://audioclip.naver.com/channels/5158/clips/10

pod 안정성을 높이는 설정 (by 악분)

 

1. pod 안정성이란

pod 안전성은 pod에 문제가 발생하더라도 서비스 중단을 최소화하는 것을 의미합니다. 이상적으로 pod안정성이 높으면, pod에 문제가 있더라도 서비스 중단은 발생하지 않고 문제가 있는 pod는 스스로 복구됩니다.
 
 

2. 안전성 관점에서 쿠버네티스 장점

쿠버네티스는 pod 안전성을 높이는 설정을 제공합니다. 그러므로 쿠버네티스 사용자는 어렵지 않게 안정성 설정을 하여 시간을 절약할 수 있습니다. 만약 애플리케이션을 쿠버네티스 아닌 서버에 실행되고 있다면 애플리케이션 안정성을 높이는 작업은 매우 어렵고 시간이 많이 걸립니다.
 

3. 안전성 설정들

3.1 설정1 - replica는 2개 이상

첫 번째 설정은 pod replica 개수입니다. pod replica는 2개 이상으로 설정하는 것이 좋습니다. pod replica를 1개만 설정하면, pod에 문제가 있으면 바로 서비스 장애로 이어집니다.
 
pod replica를 2개로 늘리기 전에 몇가지 점검이 필요합니다. 무작정 pod replica를 2개로 늘리면 pod가 예상한대로 실행되지 않는 경우가 있습니다 따라서 pod가 어떻게 동작하는지 이해해야 합니다.
데브옵스 엔지니어가 혼자 파악할 수 없고 개발자, 인프라 엔지니어 등 여러 사람과 커뮤니케이션 하면서 replica를 늘렸을 때 영향도를 검사해야 합니다.

1. pod replica를 늘려도 서비스에 영향없는지?(예: 배치 서비스)
2. pod가 세션관리 로직이 있다면 pod끼리 세션을 공유할 수 있는지?
3. 쿠버네티스 노드 자원이 충분한지?
4. pod에 할당할 수 있는 IP가 남아 있는지?
5. 기타 등등

 

 
 

3.2 설정2 - pod의 노드 분산 배치(토폴리지 분산)

pod를 배포할 때 여러 노드에 골고루 분배하는 것이 중요합니다. pod replica가 2개 이상 있더라도 하나의 노드에만 배치되면, 해당 노드에 장애가 발생할 경우 모든 pod가 영향을 받아 서비스가 중단됩니다. 따라서 노드 장애 시 서비스 장애를 예방하려면 pod를 여러 노드에 분산 배치해야 합니다.

 
컴퓨터 공학(computer science)에서는 토폴리지(topology)라는 용어가 있습니다. 시스템의 구성 요소들이 어떻게 연결되고 배치되어 있는지를 나타내는 구조를 말합니다. 쿠버네티스 pod에서 토폴리지는 어떻게 노드에 스케쥴링를 의미합니다.
 
pod를 토폴리지 분산되도록 하는 설정은 2개입니다. primary-secondary, sharding아키텍처를 갖는 pod는 podAntiAffinity를 사용하고, 나머지 유형은 topologySpreadConstraints를 사용합니다.

1. podAntiAffinity: 한 노드에 동일한 spec을 가지는 pod가 1개만 실행되도록 설정
2. topologySpreadConstraints: pod를 여러 노드에 분산 배치되도록 설정

 

3.3 설정3 - probe 설정

다음 설정은 probe입니다. probe는 pod가 비정상 상태인지 확인하는 설정입니다. pod에서 OOM, 데드락 등 애플리케이션 문제는 언제나 발생할 수 있는데 probe를 설정하면 문제진단을 자동화 합니다. probe는 문제가 발생한 pod에 트래픽을 보내지 않거나 pod를 강제로 재시작합니다. 

 

3.4 설정4 - resources 설정

pod 리소스(resource)는 pod가 사용하는 cpu, memory, storage의 최소 리소스 사용량을 보장하고 한계를 설정합니다. 안전성관점에서 리소스를 설정해야 하는 이유는 pod가 과도하게 리소스를 사용해서 노드가 비정상 상태로 빠지는 것을 막기 위해서입니다.
 
pod에 리소스를 사용하지 않으면 pod는 노드 리소스를 전부 사용하게 됩니다. pod가 노드의 메모리, 스토리지를 100% 사용하면 노드는 비정상상태가 됩니다. 그리고 노드에서 실행 중인 모든 pod또한 비정상 상태로 빠지게 됩니다. 결국 서비스 장애로 이어집니다.
 
kublet은 10초(디폴트)에 한번 노드 리소스가 부족하게 될 경우 강제로 pod를 죽이는 Node pressure-evicition을 실행합니다. 하지만, 10초에 한번 검사하기 때문에 갑자기 pod가 노드 자원을 100%사용하면 노드는 비정상상태가 됩니다.
 
이전에 제가 작성한 글을 참고하시면 좋습니다. 시연 주제는 “pod가 스토리지를 100%사용하여 발생한 노드장애 시연”입니다.

• 글: https://malwareanalysis.tistory.com/732
• 영상: https://youtu.be/asCq7pWaJtg?si=rATkbw2_nEEOXx04

 

3.5 설정5 - 자동 스케일링(HPA, VPA 등)

다음 설정은 자동 스케일링입니다. 종종 pod가 부하가 많아질 수 있어 스케일링 설정을 통해 pod 부하를 낮춰야 합니다. 설정 방법은 pod replica를 늘리는 HPA(수평 스케일링) 또는 리소스(예: cpu, memory)를 증가시키는 VPA(수직 스케일링)을 사용할 수 있습니다.
 
스케일링 설정이 없다면 pod는 부하 때문에 OOM 등이 발생하고 pod가 재실행됩니다.
 
쿠버네티스는 HPA등으로 스케일링 설정을 자동화 할 수 있습니다. 자동화 원리는 이전 제가 작성한 글을 참고하시면 됩니다.

• 쿠버네티스 metrics server: https://malwareanalysis.tistory.com/659

 

3.6 설정6 - 컨테이너 이미지 latest사용 금지

pod가 사용하는 컨테이너 이미지는 latest를 사용하면 안됩니다. latest는 여러 가지 문제를 가지고 있지만 가장 큰 문제는 장애가 생겼을 때 디버깅과 롤백이 어렵다는 것입니다.

• 변경 추적 어려움
• 롤백 어려움

 
2023년에 있었던 저의 경험을 잠깐 공유드리고 싶습니다. 물리서버 배터리가 방전되서 서버가 갑자기 새벽에 꺼진 상황이 발생했습니다. 서버를 배터리를 교체하기 위해 약 4시간이 걸린다는 답변을 받았습니다.
문제는 그 서버에 중요한 도커 컨테이너가 실행중이었는데, 다른 서버에 컨테이너가 실행되고 있지 않았습니다. 유일한 도커 컨테이너가 죽은 상황이어서 다른 서버에 도커 컨테이너를 옮겨야 했습니다.
컨테이너를 옮기기 위해 컨테이너 이미지 태그를 조사했는데, 태그가 latest였습니다. 1시간 안에 컨테이너를 옮겨야 하는 상황이었는데 컨테이너 이미지 버전을 몰라서 지연이 되었습니다.
 

3.7 설정 7 - 컨테이너 이미지 태그 덮어쓰기 금지

설정6과 연결되는 설정입니다. 컨테이너 이미지는 태그 덮어쓰기를 허용하면 안됩니다. 즉 컨테이너 이미지는 immutable이여야 합니다. 이미지 덮어쓰기를 허용하면 해당 버전에 예상하지 못하는 기능이 추가되거나 원래 기능이 수정됩니다. 그리고 서비스 장애로 자연스럽게 이어집니다
 
컨테이너 이미지 태그 덮어쓰기 금지 설정은 dockerhub, ECR, harbor 등 모든 컨테이너 이미지 저장소에서 지원하고 있습니다.
 

3.8 설정8 - pod grace shutdown

pod grace shtudown 설정은 pod가 실행중인 작업을 안전하게 종료한 후, pod를 종료시키는 것을 의미합니다. pod가 실행 중인 작업이 안전하게 종료되지 않으면 네트워크 등의 장애가 발생합니다.
 
자세한 설정 방법은 저의 이전 글과 영상을 참고하시길 바랍니다.

• 글: https://malwareanalysis.tistory.com/739
• 영상: https://youtu.be/VkGTzaaIkJU?si=qhUbThm4fV_ulKxY

  

4. 정책 검사 프로세스 구축 -Adminssion Controller

지금 까지 살펴봤던 설정은 사람이 일일이 검사할 수 없습니다. 따라서 정책 검사 시스템을 만들어서 실수로 배포되는 것을 막아야 합니다. 쿠버네티스는 admission controller로 정책을 검사할 수 있습니다.
 
2024년 7월 기준 admission controller을 설정할 때 OPA, kyverno 등 도구를 사용하는 것을 추천드립니다. 아직까지는 kubernetes 기본 기능으로 검사 정책을 만들기가 쉽지 않습니다.
 
admission controller원리는 저의 이전 글과 영상을 참고해주세요.

• 글: https://malwareanalysis.tistory.com/704
• 영상: https://youtu.be/5WM4hVhxMnA?si=ZxVnC4OctsIAEprX

 

5. 마치며

쿠버네티스는 컨테이너 오케스트레이션을 쉽게 할 수 있지만, 운영을 위한 설정은 쉽지 않습니다. pod가 비정상 상태에 빠져 서비스 장애가 발생하는 상황이 종종 있습니다.
 
그래서 이 글에서는 pod가 비정상 상태에 빠지지 않기 위한 제가 적용한 설정을 공유하고 싶었습니다. 막상 쓰다보다 글이 길어서 모니터링 관련 글은 삭제했습니다.
 
제일 중요한 것은 pod 설정으로 쿠버네티스 장애를 최소화 할 수 있지만 모든 장애를 막을 수 없습니다. 쿠버네티스 환경 이외에 장애를 일으키는 포인트는 정말 많습니다. 예를 들어 애플리케이션 코드 로직 오류, 외부 요인(데이터베이스 등)이 있습니다.
 
따라서, pod안정성을 높이는 최고 방법은 빠르게 장애를 인지하고 빠르게 고치는 것입니다. 인지하기 위한 모니터링과 알림 시스템, 어디서 장애가 발생했는지 파악할 수 있는 능력, 그리고 장애를 고치는 능력이 필요합니다.
 
역설적이지만 pod장애를 최소화하는 방법은 장애를 많이 마주치고 장애를 해소하면서 경험을 늘려야 합니다. 장애를 해소하기 위해서는 전체 서비스 구조 파악, CS지식(네트워크, 운영체제 등), 성능분석 능력이 필요합니다.
 

6. 참고자료

• kubernetes 문서: https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/
• kubernetes 문서: https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/
• kubernetes 문서: https://kubernetes.io/ko/docs/tasks/run-application/horizontal-pod-autoscale/
• kubernetes 문서: https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/
• kubernetes 문서: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
• kubernetes 문서: https://kubernetes.io/ko/docs/concepts/configuration/manage-resources-containers/

 
이하여백