Kubernetes, 이 정도는 알아야 합니다.

요새 성숙한 서비스들은 대부분 쿠버네티스를 이용해 안정적인 운영을 하고 있습니다. 참고로 '성숙한'이라는 의미는 안정적으로 수익이 발생하는 상태를 의미합니다. 

서비스를 처음 런칭할 때는 트래픽도 적으니 간단하게 서버 하나만 있어도 되지만, 서비스가 성장하고 트래픽이 늘고, 안정적으로 운영을 할 필요성이 커지면 대부분 쿠버네티스를 이용해 운영을 하기 시작합니다. 

그리고 일을 하다 보면, '저게 무슨 말이지 ...?' 싶은 때가 존재합니다. 특히 Infra 관련된 이야기를 할때면 빠짐 없이 등장하는 것이 쿠버네티스입니다. 당장 우리 서비스가 쿠버네티스 위에서 운영되고 있는데 쿠버네티스를 말하지 않고는 이야기가 불가능하기 때문이죠. 특히 MSA로 운영되고 있는 서비스는 더욱 그렇습니다. 

K8s, 적어도 이 정도는 알아야 합니다.

이거 Pod 계속 죽는데요?

Pod(파드)은 우리가 만든 서버 인스턴스를 의미합니다. 이 Pod가 최종적으로 들어오는 트래픽에 대한 응답을 하는 것이죠. 그래서 쿠버네티스가 하는 일을 쉽게 말하면, 약속한 대로 Pod를 잘 관리하는 일입니다. 우리가 이 Pod를 몇 개를 띄울지, 어느 정도 트래픽이 들어오면 늘릴지를 쿠버네티스에게 알려주면, K8S가 알아서 관리를 해주는 것입니다.

Pod가 죽는다는 의미는 서버에서 의문의 에러가 발생해, 종료되었다는 것입니다. 그런데 실제로 Pod는 죽었다 살아나기를 자주 반복하기 때문에, K8S는 Pod는 불안정한 리소스로 여깁니다. 그래서 Pod를 대표할 Service라는 자원을 따로 두어서 Pod들을 대표하도록 하고 있습니다. Service가 Pod에 트래픽을 나눠주고 있습니다.

물론 계속 죽는다는 것은 문제가 있다는 소리입니다. 얼른 문제를 파악해서 해결을 해야 서비스가 안정적으로 동작합니다.

Ingress 설정 잘 되어있나요?

Ingress 는 외부에서 서버로 유입되는 것을 의미합니다. 쉽게 이해하려면 IP와 관련된 리소스라고 생각하시면 됩니다. Ingress의 기본적인 역할은 트래픽을 처리하는 것을 의미합니다. K8S 내부에 접근가능한 URL을 부여해서 사용자들의 요청이 Pod까지 잘 전달되도록 통로를 제공하는 것이죠.

Ingress 설정을 통해서 위에서 언급한 Service로 트래픽을 전달하게 됩니다. 

HPA는 설정하셨어요?

HPA는 Horizontal Pod AutoScaler 의 약자입니다. Pod에 대한 수평 확장(Scale out) 설정을 의미합니다. 우리가 설정한 일정 임계값이 넘어가는 작업량이 Pod에 주어지면, Pod의 개수를 늘리게 됩니다. 그리고 트래픽이 줄어들면, 다시 Pod의 개수를 원상복구까지 시켜줍니다.

시간에 따라 트래픽이 다른 경우에 보통 이 HPA 설정을 통해 서비스의 문제를 해결합니다. 항상 피크 타임에서의 트래픽을 감당할 수 있는 서버를 작동시키는 것은 비용이 많이 들기 때문에, 이 설정으로 트래픽이 점점 많아지면, 서버를 하나씩 더 올리게 하는 것이죠.

하지만 HPA만 설정되었다고 모든 트래픽 증가를 감당할 수 있는 것은 아닙니다. 예를 들어, 이벤트로 트래픽이 갑자기 몰리는 상황에는 이 HPA는 도움이 되지 않습니다. Pod를 확장할 때에는 시간이 필요하기 때문에, Pod를 추가적으로 만든 이후에는 이미 이벤트가 종료가 되어있을 겁니다. 이런 경우에는 HPA를 믿는 것이 아니라 미리 서버를 더 만들어 놓는 것이 필요합니다.

이거 Node 설정이 잘못된거 아니에요?

Pod가 K8S 에서 최소 단위라고 한다면, Node는 최대 단위입니다. K8S 상에는 여러개의 노드가 존재하고, 노드 아래에 Pod가 존재하게 됩니다. 다르게 말하면, Node는 컴퓨팅 리소스(CPU, Memory)를 부여받고, 그 리소스를 Pod가 나눠가지게 됩니다.  Node의 정책이 곧 Pod의 정책이 됩니다.

Pod는 Node에 종속적이기 때문에 어떤 Node에 위치하느냐가 굉장히 중요합니다. 그리고 어떤 Node에 위치시킬지 결정하는 것이 바로 Label입니다.

Label을 이용해 특정 리소스를 지정할 수 있습니다. 예컨데, INT라는 Label을 붙이면, 언제든지 그 INT와 관련된 리소스를 찾아낼 수 있는 것이죠.

Helm Chart 한번 확인해보세요.

Helm은 쿠버네티스 패키지 매니저입니다. 자바의 Gradle, Maven 같은 것이죠. K8S에는 이 글에서 소개되지 않은 여러가지 리소스들이 존재하는데, 그 리소스를 잘 관리하기 위해 Helm을 이용하고 있습니다. 그리고 그 Helm에서 요구하는 포맷이 Helm Chart입니다.

Helm Chart에는 여러가지 정보들이 들어갑니다. 앞서 말했던 Service, Ingress를 어떻게 설정할 것인지, HPA는 어떻게 할지 등등 우리 서비스를 어떻게 운영할지를 모두 이 차트에 적어놓는 것이죠. 

오늘은 쿠버네티스를 조금 알아봤습니다.

당연한 이야기지만, 사실 이 글에서 나온 것보다, K8S는 더 복잡하고 어지럽습니다. 그래서 많은 분들이 자신의 서비스에 K8S를 도입하는 것을 고민하는 것이죠. 좋다고는 하지만 잘 못쓰면 없는 것보다 못하니까요.

하지만 이미 쓰고 있다면 한번 쯤은 공부해 볼 가치가 있다고 생각합니다. '이런게 있구나'정도만 알아 둔다면, 앞으로의 개발에 조금은 도움이 되지 않을까 싶습니다.