안녕하세요. 저는 클라우드 및 애자일·협업 전문 기업 오픈소스컨설팅의 이건웅이라고 합니다. 우리회사는 클라우드, 데브옵스(DevOps), 컨테이너 아키텍처 등 인프라 관련 최신 기술 전문성을 보유, 이를 토대로 서비스 애플리케이션 분석 자동화 솔루션인 ‘플레이스 로로(Playce RoRo)’와 오픈스택 및 쿠버네티스 커뮤니티 오픈소스 패키지인 ‘플레이스 클라우드(Playce Cloud)’를 개발 및 공급하고 있습니다.
우리 팀은 지속적으로 CNCF의 공개버전을 이용하여 크고 작은 사이트들에 설계, 구축 및 유지보수 업무를 진행 하고 있는데요. 이때 생기는 알찬 노하우를 공유하고자 합니다. 많은 분들이 오픈소스를 쉽게 접할 수는 있지만 실제 환경에 적용해서 사용하기에는 많은 시행착오와 경험이 필요한데요. 누군가가 구현가능하고 바로 사용가능한 아키텍쳐를 보여준다면 너무 좋겠죠. 그래서 준비 했습니다.
구현 가능하고 적절한 사용이 가능한 Kubernetes 구축과 운영포인트를 저와 같이 확인해 주시면 감사하겠습니다.
오픈소스를 사용한다는 것은 생각보다 쉽고 어렵습니다.
오픈소스 제품을 사용해보신 분들은 모두 동의 하실텐데요. 하지만 우리는 “Apache httpd”, “Nginx”, “Apache Tomcat”, “JBoss”, “My-SQL”, “PostgreSQL” 등 등의 오픈소스 프로그램을 생각보다 일찍, 그리고 많이 사용하고 있었습니다.
물론 오픈소스 제품들은 오래 사용된 만큼 우리에게 익숙하고, 폭넓은 엔지니어 들을 보유하고 있습니다. 그리고 많은 레퍼런스들이 있는 만큼, 엔지니어의 능력에 따라 사용 및 구성이 천차만별 입니다. 그러한 만큼 시스템을 잘 운영하는 것은 어려운 일이었습니다.
Google에서는 오래전 부터 동일한 어려움을 격고 있었고, Borg를 시작하면서 대규모 시스템을 관리 하고 대응하기 시작했습니다. Kubernetes는 Google의 Borg로 시작이 되었는데요.
점점 커지는 서비스 처리 요건과 다양한 언어, 그리고 다양한 OS, 그리고 대규모 서버팜의 관리 등을 위해 탄생했습니다.
이번 블로그에서는 Kubernetes의 구성 요소와 구조를 통해서 엔지니어에게 Kubernetes란 무엇인지를 생각해 보도록 하겠습니다.
엔지니어에게 Kubernetes란 무엇인지 생각해 보십시오.
Kubernetes는 컨테이너화 된 개발 소스를 오케스트레이션하는 시스템입니다. 엔지니어 시점에서는 컨테이너 관리가 원할 하게 되기위한 요소들의 집합입니다.
즉, 서버의 가용 자원, 네트워크와 인터페이스, 공유 스토리지 등을 운영하는 오픈소스 환경입니다.
엔지니어는 이러한 오픈소스환경을 디자인하여 구축해주고, 개발자(소프트웨어 엔지니어)가 개발한 소스를 컨테이너화 해서 사용 할 수 있도록 지원하게 됩니다.
위의 그림처럼 Kubernetes를 생각하는 영역은 엔지니어와 개발자가 다를 텐데요. 이러한 부분은 Kubernetes 교육을 하게 되면 알게 됩니다.
왜냐하면, 인프라 교육으로 Kubernetes를 교육하지만 Kubernetes 교육이라는 이름만으로 생각보다 많은 개발자 분들이 와서 교육을 받기 때문 입니다.
엔지니어들에게는 Kubernetes는 Web + WAS를 자동 관리하는 인프라 요소로 보게 됩니다.
하지만 개발자의 입장에서는 개발소스의 운영이 자동으로 되고, 배포 한번으로 필요한 Add-On들이 쉽게 구성되는 업무 툴에 가깝게 보이는 것 같습니다.
네트워크 스토리지를 사용하는 부분과 성능의 관점에 차이를 많이 보이는데요.
기존의 서버에서는 마운트 되어 있는 네트워크 스토리를 대용량 파일의 저장소로 이용하는 정도로 사용했습니다. 그러나, Kubernetes는 로그부터 운영 파일까지 Pod에 직접 할당하여 사용합니다.
성능 부분에서도, 오토 스케일링으로 Pod가 수평 확장 되는 만큼 성능이 무한정 늘어 날 수 있다고 생각합니다.
하지만, 하드웨어의 처리의 한계가 있기 때문에 불가능한 일이라는 것을 항상 명심해야 합니다.
– 자 그럼 엔지니어 입장에서 Kubernetes를 조금 더 보겠습니다. –
기존에는 사람이 직접 명령어와 모니터링 프로그램으로 시스템과 서비스를 확인했습니다. 그래서 많은 시간과 인적 자원을 사용 했죠.
하지만 Kubernetes는 이러한 관리작업을 배치작업을 통해 자동화 했습니다.
엔지니어를 대신해 매일 24시간 서버를 확인하고, 트래픽과 세션 수를 대신 체크하면서 처리량을 조절 합니다.
그리고 문제가 있을 경우 자동 복구 하고 있는 것입니다.
엔지니어를 대신해 관리를 해주는 Kubernetes는 그럼 만능일까요? 불행히도 그렇지 않습니다.
Kubernetes는 컨테이너를 관리하기 위한 오케스트레이션 시스템이므로, 관리 서버(Control-Plane)를 안정적인 운영을 위해 정족수방식(Quorum)으로 구축합니다.
그리고 워커 노드의 가용성을 위해 2기 이상으로 구축하게 됩니다. 컨테이너 오케스트레이션을 잘 사용하기 위한 사전 지식도 필요하게 되죠.
예를 들자면, 소규모 혹은 개인 개발용에 사용하기에는 적합하지 않고, 서비스의 규모가 작다면 기존 WEB/WAS/DB의 3Tier구조를 사용 하라고 안내를 하고있습니다.
그 이유는 Kubernetes의 최초 모습인 Borg의 컨셉을 생각해본 알 수 있는데요. Kubernetes는 대형 클러스터와 다양한 언어로 개발된 소스의 인스턴스들을 스케쥴화하여 관리하기 때문 입니다.
이제 우리는 Kubernetes는 소규모 구성보다는 대규모 구성과 다중화, 그리고 다양성에 대비된 시스템이라는 것을 알게 되었습니다.
그렇다면 Kubernetes를 잘 쓰기위해 각 요소들도 속속들이 잘 알아야 것입니다.
– 정리 해보겠습니다. –
Kubernetes는 사람이 하나하나 모니터링 하고 매일 점검하여, 확인하고 관리하던 것을 배치작업으로 순서대로 처리하는 것입니다.
이전의 방식처럼 1개의 소스를 미리 성능만 크게 하거나, 수십, 수백개의 인스턴스를 예비 구성해 놓지않아도 됩니다.
그리고, 장애가 발생하면 일일이 분석하고 수정하지 않아도 됩니다.
엔지니어에게 Kubernetes란, 물리 환경에 문제가 없다면 실시간 성능 분배가 가능하고 이슈발생 시, 자동 복구등을 24시간 지원 해주는 최적의 인프라 환경인 것입니다.
이렇게 좋은 Kubernetes를 잘 쓰려면 구조를 잘 알아야겠죠? Kubernetes의 구조를 살펴 보겠습니다.
아래의 그림처럼 Kubernetes는 Quorum 구성 으로 된 Control-Plane 3기, 2중화 이상의 구성 으로 된 최소 2기이상의 Worker 입니다.
물론 Worker는 1기여도 구성은 되지만, 물리적인 장애의 극복을 할 수 없으므로 최소 2기 이상 구성되어야 하겠습니다. Control-Plane의 경우 홀수로 구성해야 하기 때문에, 반드시 3, 5, 7 등 정족수가 가능한 홀수 구성으로 구축 됩니다.
모든 Node에는 Kubelet과 Containerd(Runtime)이 있고, 이를 기반으로 컨테이너화 되어 있는 Kube-apiserver, Kube-Controler-manager, Kube-Schduler를 구성합니다.
그리고 Kubernetes의 정보를 key: value 구조로 저장하는 etcd가 운영되고 있습니다.
몇 개 안되는 컴포넌트로 수많은 Pod를 자동으로 운영 할 수 있다니 너무나도 놀랍습니다. 빨리 더 알아보고 싶네요.
하지만 위 그림처럼 모든 시스템이 엔터프라이즈 환경에서만 서비스를 구성하지는 않습니다.
그래서 Kubernetes는 개발환경이라던가 테스트, PoC등 1기 정도의 서버라도 소규모에 맞춰진 K3s, Minikube, Microk8s등의 소규모 Kubernetes도 준비 되어 있습니다.
소형 Kubernetes들은 온전한 컴포넌트들이 있지 않고, 소형 환경이기에 적절하게 사용하기 위해서는 많은 고민이 필요합니다.
예를 들자면, 개발기 혹은 테스트 환경으로 사용 하기에는 소형화된 Kubernetes가 최적 일 것입니다.
소형화된 Kubernetes의 기본구성은 서버 1기에 모든 컴포넌트들이 들어오는 구조입니다.
클러스터의 구성이라던지, 가상 네트워크 사용 그리고 레포지터리 사용등에 큰차이가 있으므로 소형 클러스터를 필요로 할때는 자세한 비교후에 사용 하시길 바랍니다.
Microk8s 홈페이지에는 세 가지 소형 Kubernetes의 차이를 잘 비교해서 보여주는 표가 있습니다.
만약 경량화 Kubernetes를 사용 한다면 꼭 참조 하시길 바랍니다. (경량화 Kubernetes 비교표)
아래의 그림은 위에 설명된 Kubernetes를 경계별로 DMZ, DEV, PRD Zone등 요구하는 성능별로 구분하여 클러스터를 구분하여 운영할때의 간단한 예시입니다.
대 외 서비스를 대비하고 필요한 성능과 규모에 따라 디자인한다면, 아래의 그림처럼 구성될 수 있습니다.
이중 PRD Zone을 아래의 그림처럼 Namespace를 이용해 사용 한다면 PRD에 구역을 나누지 않고, 조금 더 작은 규모에서 개발환경과 운영환경을 구성해 운영할 수 도 있습니다. DEV가 별도로 있다면, STG Zone으로 사용 할 수도 있겠죠.
이때 주의할 점은 Kubernetes는 컨테이너화 된 이미지를 이용하여 자동 확장과 축소, 자동 배포와 복구가 지원되지만 하드웨어의 물리적 성능을 벗어날 수는 없다는 것입니다. (물리 성능과 최대 Pod생성 갯수, IP Pool수 등의 제한이 있습니다.)
Kubernetes는 필요한 만큼 무조건 스케일 아웃 되는 것이 아닌, 사용량이 많은 Pod와 적은 Pod의 벨런스를 맞춰주는 시스템이라는 점을 꼭 기억해두세요.
최적의 환경을 구축하기 위해서는 Kubernetes의 자체에 대한 학습이 필요해 보이지만, 개인의 능력에 의존해야 했던 기존의 시스템에 비하면 사용과 관리가 아주 좋은 시스템입니다.
Kubernetes란 무엇인가 라는 주제를 가지고 특장점이나 비교보다는 Kubernetes를 구축하고 사용하는 사람의 관점에서 Kubernetes를 생각해봤습니다.
한마디로 Kubernetes란 “컨테이너화된 이미지를 ‘자동배포’, ‘자동복구’, ‘자동스케일링’ 해주는 시스템”인 것입니다.
참 쉽죠? 우리는 Kubernetes의 특장점을 잊지 말고, 단점들의 조심하여, 각 컴포넌트들의 기능을 범위 내에서 잘 쓸수있게 연구 해야겠습니다.
지금까지 Kubernetes를 설계하고 구축을 할때, 최대한 보편화된 구성을 완성하기 위해 고민 한 부분을 바탕으로, Kubernetes란 무엇인가를 작성해 보았습니다.
물론 다른 분들과 생각이 다를 수 있고, 제 블로그를 보시며 혼란 스러우실까봐 걱정이 되었습니다만, 제가 이해한 부분을 모두 공감 할 수 있도록 최선을 다해 작성해 봤습니다.
Kubernetes란 무엇인가를 시작으로, 고객의 니즈와 서비스 형태를 바탕으로 완성한 쿠버네티스 시스템을 분석하여 블로깅 할 예정입니다.
우리 모두 오픈소스컨설팅의 미션 처럼 기술을 나누고, 모두 함께 성장했으면 좋겠습니다.
참고사이트
