작고 귀여운 쿠버네티스를 2년간 운영하면서 알면 좋은 것들

 

 

비록 크지 않은 규모의 쿠버네티스지만 2년 동안 운영하면서 많은 것들을 경험할 수 있었습니다.

 

경험속에서 배울 수 있었던 작은 팁들을 공유하고자 합니다.

 

제가 공유하고픈 팁들은

• 노드 및 파드 스케줄링
• HA 유지
• 쿠버네티스 매니페스트 관리
• IaC

입니다.

 

그럼 바로 본론으로 가보죠.

 

렛츠두더코드~

 

 

 

노드 및 파드 스케줄링

---

 

쿠버네티스를 처음 공부했을 때, 노드 및 파드 스케줄링 파트는 그렇게 유심히 보지 않았습니다. 그렇게 어려워 보이지 않았거든요.

 

그냥 Resource Request/Limit, NodeAffinity/PodAffinity/AntiAffinity 등 yaml 에 작성하면 파드는 그에 맞게 알아서 배포가 되니깐요.

 

당연한 것이 공부할땐 기껏해야 3개 정도의 파드로 진행하는데, 현실에선 최소 몇 백개의 파드가 있어버리니...!!

 

그런데 현실에서는 그리 간단하지 않습니다. 다양한 환경과 다양한 기능들을 가진 애플리케이션을 배포하려면 상당히 신경 쓸 것이 많아집니다.

 

만약 무분별하게 생성되는 파드들의 로그로 인해, 노드의 스토리지 공간이 부족해지면 어떨까요? 혹은 사용하지 않는 이미지가 계속해서 쌓여서 공간이 부족해지면 어떨까요?

그림1 - 공간이 부족해...!!

 

만약 무중단을 유지해야 하는 파드가 같은 노드에 배포되는 바람에 노드가 업데이트나 Drain 될 때 파드가 Evict 되면 어떨까요?

이럴 경우 무중단이 유지 될 수 없죠. 하지만 이런 행위는 쿠버네티스 입장에선 지극히 정상입니다. 

그림2 - Istio Gateway 파드가 2개 있는데 전부 Evict 되어버리면... 순간적으로 외부에서 내부 파드로 접근을 못하는 순간이 생기죠!

 

만약 2Gi 의 Memory 를 가진 노드에 .resources.request 가 각각 1Gi 인 파드가 2개가 배포되었는데, 하나는 .resources.limit 을 걸어두고, 다른 하나는 걸어두지 않았는데 노드의 메모리가 꽉찼습니다.

 

둘 중 하나는 OOM 이 발생할 것이 때문에 하나는 Evict 해서 메모리를 확보해야하는데 과연 쿠버네티스를 누굴 Evict 할까요?

그림3 - 어떤 녀석을 죽여야 하지??!!

 

쿠버네티스에서 애플리케이션을 배포할때 늘 어떻게 스케줄링이 진행될지 예측을 해야하는데 쉽지 않습니다. 분명히 완벽한 설계를 했다고 생각했는데 늘 구멍이 생겨서 말썽을 부리죠. 

 

그래도 더 정확한 예측을 위해 쿠버네티스를 공부하는 거죠!

 

 

우선 두번째 질문부터 답해보죠.

 

무중단을 요구하는 애플리케이션일 경우, 당연하게도 중단되었을 경우 크리티컬한 이슈가 발생할 수 있습니다. 여기서 발생하는 중단은 파드 내 에러로 인한 중단을 말하는 것은 아닙니다.

노드 업데이트 같은 것들로 인한 파드의 종료를 쿠버네티스에서는 자발적 중단라고 하죠! 
더 자세한 내용은 여기 참고!

자발적 중단과 비자발적 중단

 

절대 에러가 발생하지 않는 파드일지라도 같은 노드에 파드가 존재하면 중단될 수 있는 상황이 발생할 수 있습니다.

 

간단하게 Node Update 만 생각해도 업데이트가 진행 중일 때는 모든 파드들을 축출합니다. 그렇게 되면 아무리 완벽한 파드라도 순간적으로 전부 중단되버리는 경우가 발생하죠. (그림2 참고)

 

이럴때는 PodDistruptionBudget 를 생성해주면 됩니다. 간단하지만 아주 강력한 쿠버네티스 리소스라고 생각합니다.

 

PodDistruptionBudget 는 설정에 따라 최소/최대 1개 이상의 파드는 항상 실행될 수 있도록 보장 해줍니다. 즉, 2개 이상의 파드가 동시에 전부 Evicted 되는 것을 막아줍니다.

그림4 - PDB 로 인해 모든 파드가 Evict 되는 것을 방지

 

그런데 만약 노드를 업데이트 해야 하는데, 이 노드는 PodDistruptionBudget 를 가진 2개의 이상의 파드를 가지고 있습니다.

 

이럴 경우 어떻게 될까요?

 

업데이트는 진행되지 않습니다. 서비스가 중단되지 않아서 우선은 다행인데, 이러면 영원히 노드를 업데이트 할 수 없습니다. 따라서 이럴 경우 PodAnityAffinity 를 통해서 다른 노드에 파드가 배포될 수 있게 해주어 순차적으로 노드 업데이트를 진행시켜주죠. 그러면 최소 1개 이상의 파드는 살아 있을 겁니다.

 

그리고 다행히 PodDistruptionBudget 을 걸어버리면 기본적으로 최소 서로 다른 2개의 노드에 파드가 배포되게끔 해줍니다.

 

세번째 질문에 답은 어떨까요?

 

답은 하기전에 우선 QoSClass 에 대해 알아보겠습니다. QoSClass 의 종류에는 Best-Effort, Bustable, Gauranted 가 있는데, 이는 노드에 존재하는 파드가 Evict 되는 순서를 정해줍니다. Best-Effort 인 파드가 가장 우선순위 Evict 를 가지고 Gauranted 인 파드가 가장 후순위 Evict 를 가집니다.

 

.resources 를 설정해주지 않으면 Best-Effort 가 되고, .resources 의 request 와 limit 를 다르게 설정하면 Bustable 를, .resources 의 request 와 limit 와 같으면 Gauranted 가 됩니다.

 

위 경우라면 .resources.limit 를 설정하지 않은 파드를 먼저 Evict 하게 될 것입니다.

 

QoSClass 말고도 Evict 우선순위를 설정할 수 있는데 PriorityClass 를 사용하면 됩니다.

 

쿠버네티스는 기본적으로 2개 PriorityClass 를 가지고 있고, 당연히 Value 값이 낮은 것이 먼저 Evict 됩니다.

PriorityClass

 

그리고 QoSClass 와 PriorityClass 2개가 있을 경우, PriorityClass 가 더 우선시 됩니다.

 

예를 들어 Best-Effort 일지라도 system-node-critical 가 걸려있다면, Gauranted 이지만 아무 PriorityClass 를 가지지 않은 파드가 먼저 Evict 됩니다. 

그림 5 - QoS 보다 Priority Class 의 우선 순위가 더 중요!

 

 

그리고 다시 돌아와 첫번째 질문에 대해 답해보죠.

 

이 부분에 대해서는 순수 쿠버네티스 리소스만으로는 불가능합니다. 그렇다고 어렵진 않습니다. Karpenter 와 Loki (로그 수집기) 를 이용해서 해결했습니다.

 

예를 들어 Karpenter 를 통해 30일이 지난 노드는 삭제하고 새롭게 생성하며, 노드에 있는 파드들의 로그는 Loki 로 수집하는 것이죠.

 

이 부분에 대해서는 예전에 다룬 로그 때문에 노드 디스크가 부족하면? 이미지가 노드 디스크를 전부 차지하면 어떡하지? 을 참고 바랍니다.

 

저는 쿠버네티스를 잘 다루는 사람과 그렇지 못한 사람의 차이는 노드 및 파드를 어떻게 스케줄링하냐에 달려있다고 생각할 정도로 스케줄링은 중요하면서 어렵다고 생각합니다.

 

위에서 공유드린 내용들 말고도 훨씬 더 다양한 스케줄링 방법들이 있으니 알아보시길 바랍니다!

 

 

HA 구성

---

 

파드는 언제 죽을지 모를 녀석입니다. 죽더라도 이상할게 없는 녀석이죠. 그럴려고 만들어진 녀석이니깐요.

하지만 파드가 죽더라도 서비스까지 죽어선 안됩니다. 때문에 쿠버네티스에선 HA 구성을 위해 더 신경써줘야 합니다!

 

단순히 replicas: 2 로 해도 쿠버네티스 상에 있는 애플리케이션들은 충분히 HA 구성할 수 있습니다. 하지만 늘 인생이 쉽지 않죠. 이런 단순한 방법으로는 HA 를 구성 하지 못하는 애플리케이션도 존재합니다.

 

실제 애플리케이션들로 예시를 들어보죠.

 

쿠버네티스 상에 파일시스템인 Nexus 라는 애플리케이션이 있습니다. Nexus 는 기본적으로 Stateful 을 유지해야 하는 싱글 인스턴스 서비스입니다. 만약 HA 구성을 위해 2개 이상의 파드로 배포된다면, 데이터의 병합성이 깨질 수 있습니다.

Nexus Pro 라면 다중 인스턴스 HA 를 지원해주긴 합니다! 여기선 예시를 위해!

 

다음은 Karpenter 입니다.

 

HA 를 구성해주기 위해 파드를 2개 생성해주었습니다.

 

그런데 막상 로그를 보면 한 놈만 실질적으로 실행되고 있죠. 다른 녀석은 리더가 되기 위해 애를 쓰고 있습니다. 

attempting to acquire leader lease karpenter/karpenter-leader-election...

 

만약 리더인 녀석이 죽으면, 바로 그 자리를 차지하겠죠.

 

다음은 Prometheus 입니다.

 

Prometheus 는 메트릭을 수집해주는 녀석인데, 공식 문서에도 나와있듯 절대적인 Stateful 서비스입니다. 

오로지 1개로만 실행되어야 합니다. 때문에 HA 는 지원되지 않습니다. 하지만... 저는 HA 를 구성하고 싶습니다...

 

이 부분들에 대해서 어떻게 해결할 수 있을까요?

 

들어가기 앞서 애플리케이션은 크게 Stateless 와 Stateful 한 애플리케이션으로 나눌 수 있습니다.

 

Stateless 같은 경우 파드를 2개 이상 배포함으로써 아주 쉽게 HA 를 구성할 수 있습니다. 반면 Stateful 는 단순히 파드를 2개 이상 배포한다고 해서 해결할 수 없습니다.

 

따라서 Stateful 한 애플리케이션일 경우 HA 를 구성하기 위해 애플리케이션 내부 잠금과 애플리케이션 외부 잠금 메커니즘을 이용할 수 있습니다.

 

애플리케이션 외부 잠금은 또 한번 Soft 한 잠금과 Hard 한 잠금으로 나뉘죠.

 

Soft 한 잠금은 Deployment + Service + replicas = 1 를 통해 구현할 수 있고, Hard 한 잠금은 StatefulSet + Headless Service + replicas >= 1 로 구현할 수 있습니다.

 

Headless Service 덕분에 Replica 가 1개 이상이 되어도 상관없습니다!

 

여기서 꼭 주의할 점이 있습니다.

 

파드의 replicas 는 유지되는 최소한의 파드 수를 의미합니다. 최대가 아니죠. replicas: 1 일지라도 2개가 될 수 있는 상황이 발생합니다.

 

만약 파드가 배포되어 있는 노드에 문제가 생겨, 클러스터 바운더리에 벗어난 경우 쿠버네티스는 replica 가 0 으로 인지하여 1개를 더 배포하게 됩니다. 즉 실질적으론 파드가 2개가 떠있는거죠. 

클러스터에 의해 관리되진 않지만 여전히 실행되고 있는 파드와 다시 쿠버네티스가 배포한 파드 이렇게 총 2개입니다.
비자발적인 중단에 의해서 위와 같은 상황이 발생할 수 있습니다.

Replica: 1 이지만... 생겨 버린 이 녀석

 

위 상황처럼 Pod2 가 생겨버려 서비스로 인해 Pod2 로도 로드밸런싱 되는 경우가 발생할 수 있습니다. 이럴 경우 Stateful 이 깨질 수 있죠. 그래서 이런 경우를 Soft 한 외부 애플리케이션 잠금이라고 합니다.

 

Hard 한 잠금 역시 Soft 한 잠금에서 발생할 수 있는 문제가 똑같이 발생할 순 있는데, Headless Service 를 통해 이를 방지할 수 있습니다.

 

다른 글에서 자세히 다룰테지만 간단하게 말해보면, 2개의 파드가 생기더라도 Headless Service 를 통해 첫번째 파드의 도메인으로만 요청을 보내는 것이죠. StatefulSet 은 네트워크 식별자를 가지니, Headless Service 와 결합하면 다른 파드가 생기더라도 한 곳의 파드로만 요청이 갈 수 있게 할 수 있죠.

 

네트워크 식별자를 가지는 StatefulSet 과 파드 도메인을 가지는 Headless Service

 

순간적으로 파드가 죽어 서비스가 중단되겠지만, 금방 다시 쿠버네티스가 파드를 살릴 것입니다.

 

애플리케이션 밖에 있는 쿠버네티스 자원을 이용해 잠금을 건다해서 애플리케이션 외부 잠금이라고 명칭합니다.

 

애플리케이션 외부 잠금을 통해 Stateful 한 애플리케이션의 HA 를 구성할 수 있는데, 완벽한 HA 유지는 아닙니다. 때문에 애플리케이션 외부 잠금보단 애플리케이션 내부 잠금을 사용하는 것이 좋습니다.

 

애플리케이션 내부 잠금은 이제 애플리케이션 내부에서 분산락 메커니즘, 리더-선출 메커니즘을 구현하는 것이죠. 아니면 zookeeper 와 Kafka 를 이용하는 방법도 있습니다.

 

애플리케이션 내부 잠금에 대해서는 양이 너무 방대하니 다른 글에서 다루도록 하겠습니다!

 

그럼 이제 위에서 던진 첫번째, 두번째 질문엔 답은 충분히 할 수 있습니다.

 

Nexus 는 Hard 한 애플리케이션 외부 잠금을 통해 싱글인스턴스와 HA 를 유지할 수 있고, Karpenter 는 로그에서 알 수 있듯이 리더-선출 메커니즘을 통해 애플리케이션 내부 잠금을 사용했습니다.

 

그럼 Prometheus 는 어떨까요?

 

Prometheus 는 혼자만의 힘으로 HA 를 유지할 수 없습니다. 애플리케이션 내부 잠금, 외부 잠금 모두 사용하기가 어렵습니다. 대신 Prometheus Operator 와 Thanos, Grafana Mimir 를 통해 HA 를 유지할 수 있죠.

 

왼쪽부터 Prometheus Operator, Thanos, Mimir

 

사실 이 방법도 정확히는 Prometheus 를 HA 로 유지시켜주는 것은 아니고, Prometheus 가 수집하는 메트릭을 Push 받아 데이터를 병합성과 무결성을 유지시켜줍니다. 

 

추가적으로 CNCF 프로젝트 같은 것들을 사용할 때 문서에서 HA 구성은 대부분 가이드해주기 때문에 따라하면 어렵지 않게 구성할 수 있습니다. 예를 들어 ArgoCD 의 HA 는 공식 문서에 가이드되고 있습니다.

 

바로 다음 글에서 이어집니다.

바로 다음 글에서 이어질려고 했지만, 관련한 내용은 강의로 만들었기 때문에 자세한 내용이 궁금하다면 강의를 참고해주세요!
[강의 출시] 쿠버네티스를 활용한 스몰 비즈니스 운영