🔭Kubernetes v1.29 최신 릴리즈: Sidecar 패턴 지원 고도화!

안녕하세요, 최신 DevOps 소식을 알기 쉽게 공유하는 DevOps 여행을 위한 소식지입니다.

이번 소식지에서는 컨테이너 애플리케이션 관리 시스템의 대표 주자, Kubernetes의 2023년 마지막 업데이트 버전 1.29(Mandala)에서 소개한 주요 업데이트 중 Sidecar 패턴 지원 고도화에 대해 쉽게 풀어보았습니다. 그럼 같이 살펴보시죠 :)

이번 Kubernete 릴리즈의 코드네임은 만물의 본질을 표현한 무늬, 만달라(Mandala)인데요. 'Kubernetes라는 우주는 Kubernetes의 컨트리뷰터와 유저, 서포터라는 별들이 있었기에 빛날 수 있었다'라는 것을 표현하려고 이와 같은 코드네임을 지었다고 하네요.✨🌌

이번 v1.29에서 소개하는 주요 업데이트 중 저희가 주목할 Sidecar 패턴은 v1.28 릴리즈에서도 관련 기능이 추가되었던 만큼, Kubernetes에서 오랫동안 주요 컨셉으로 자리잡았던 것인데요. 그렇다면 Sidecar 패턴이 무엇인지, 이번 릴리즈에선 Sidecar 패턴과 관련된 어떤 고도화가 있었는지 차근차근 살펴보겠습니다.

🏍Sidecar 패턴이 뭘까?

앞에서 Sidecar 패턴이 Kubernetes에서 주요 컨셉으로 쓰인다고 했었죠. 소프트웨어 개발에 디자인 패턴이 있듯이, 클라우드 아키텍처에도 디자인 패턴이 있는데요. 그 중 하나가 Sidecar 패턴입니다.

이름에서 알 수 있는 것처럼, Sidecar 패턴은 Service를 제공하는 컨테이너(Main)를 실행할 때 Main 컨테이너의 로그 수집, 모니터링, 네트워킹 등의 보조 기능을 수행하는 컨테이너(Sidecar)를 함께 실행하는 컨셉을 이야기합니다.

이런 Sidecar 패턴은 Kubernetes 초기부터 주요 컨셉으로 자리잡았으나, Kubernetes에서 시스템상으로 지원(Native support)하기 시작한 건 v1.28 릴리즈부터였습니다. v1.29부터는 이러한 Sidecar 패턴 지원을 고도화하려 하고 있는데요. 대표적인 개선점은 바로, Sidecar 컨테이너의 종료 순서를 최적화 하는 것입니다.

✔Sidecar 컨테이너 종료 순서가 중요한 이유...

로그 수집을 하던 Sidecar 컨테이너가 먼저 종료되면... 중요한 로그를 놓칠 수도...!

한 Pod(Kubernetes의 가장 기본 단위. 하나 또는 여러 컨테이너의 집합) 안에 Main 컨테이너와 Sidecar 컨테이너가 같이 있을 때 Pod가 재배포 등의 이유로 종료될 경우, Main과 Sidecar 컨테이너가 동시에 종료 동작을 시작하는 것이 기존 방식이었습니다.

하지만 이 방식엔 문제가 있는데, 바로 Sidecar 컨테이너가 먼저 종료될 경우엔 Sidecar 컨테이너의 본래 기능 수행을 완전히 보장하지 못한다는 점이었습니다. (Sidecar 컨테이너가 Main 컨테이너에 대한 로그 수집 또는 모니터링 작업을 수행 중이었다면, 제 역할을 끝까지 수행하지 못하고 먼저 종료하게 되는 것입니다..😓)

이러한 문제점을 개선하기 위해 등장한 것이 바로 Sidecar 컨테이너의 종료 순서 최적화라고 합니다.👍

✨그래서 이제부터는 순서대로!

Sidecar의 기능을 온전히 수행할 수 있도록, 이제는 컨테이너 종료도 순서대로!

Sidecar 컨테이너가 먼저 종료되는 것을 방지하고 제 역할도 충실히 수행하도록 v1.29부터 도입한 것이 Sidecar 컨테이너 종료의 직렬화(Serialization)인데요.

단어 자체는 어려워 보이지만 단어 속 의미는 단순합니다. 이제부턴 Main 컨테이너와 Sidecar 컨테이너를 줄세워 차례대로 종료시키겠다는 겁니다.

그 순서 역시 중요하겠죠. 일단 Main 컨테이너들이 가장 먼저 종료됩니다. 그 다음 Sidecar 컨테이너가 종료되는데요. 만약 Pod 안에 Sidecar 컨테이너가 여럿 있었다면, 가장 늦게 시작한 Sidecar 컨테이너부터 역순으로 종료됩니다.

이런 순서를 가지게 되면서, 모든 컨테이너가 자신의 역할을 마지막까지 수행한 다음 종료할 수 있게 된 것입니다! 🙌