쿠버네티스가 도대체 뭐야? 할 수 있는 것들 그리고 할 수 없는 것들

학습 차원에서 틈틈이 해외 전문가들이 블로그나 미디어 그리고 책에서 쓴 글을 정리하고 있습니다. 이번 포스팅도 그중 하나고요. 거칠고 오역된 부분이 있을 수 있습니다. 제대로 번역되지 않은 부분은 확인주시면 반영토록 하겠습니다. 이번 글은 다니엘 폰타니가 미디엄 블로그에 쿠버네티스에 대해 올린 글을 번역한 것입니다.

2015년 말 도커를 발견한 이후 나는 배치(deployment)가 소스코드처럼 될 수 있다는 것에 대해 큰 인상을 받았다. 그렇다. 나는 이것이 컨테이너가 채워주는 간극이었다고 생각한다. 소스코드를 만들고, 같은 것을 제공하라. 명령 컨트롤러에 당신의 변화를 주는 것처럼, 당신은 명령 컨트롤러를 제공하는 새로운 서버를 줄 수 있다. 당시에만 해도 개발자가 가동을 위해 수작업으로 파일을 업로드하거나 운이 좋으면 데브옵스 도구로 옮겨야 했던 것을 생각하면 그것은 혁명이었다.

이것은 새로운 시나리오를 열어준다. 인프라는 데브옵스 도구에 의해 배치된다. 정직하게 말하면, 모든 애플리케이션이 클릭 한번으로 복제될 수 있는 인프라를 필요로 하는 것은 아니다.

이것은 서비스형 소프트웨어(Saas)를 위한 요구사항이다. 그러나 모든 간단한 비즈니스 유스 케이스들에게는 값비싼 무언가가 추가된다.  하지만 도커로 돌아가면  그 세계에서는 여전히 애플리케이션을 배치하고, 확장하는 일부 노력들이 있었다.

나는 그것을 개발, 테스트, 프로덕션 환경에서 사용했다. 도커를 비판할 것은 없다. 나는 도커를 사랑한다. 그러나 개발자들이 모든 가벼운 프로세스가 주는 모든 혜택을 프로덕션 환경에서 얻을 수 있도록 하기 위해컨테니어를 사용하도록 오래된 방식을 바꿀 필요는 있다. 우리는 거의 그렇게 했다. 대부분의 개발자들은 도커를 그들의 PC에 갖고 있다. 컨테이너와 도커 컴포즈 업 (docker-compose up) 명령어를 돌리고 서버 클러스터를 사용한다.

이것은 멋진 일이었다. 다양한 환경에서 개발하는 것에 따른 많은 문제나 개발자들을 위한 셋업 비용을 막았다. 프로덕션에서 배치는 여전히 완전히 데브옵스 프로세스에 의해 관리된다. 그밖에 뭐가 있나? 나는 무언가 빠져 있다는 것을 알았다. 그러나 당시에는 그게 뭔지 확실히 알 수 없었다. 그러던 어느 날 쿠버네티스를 발견했다. 그것은 프로덕션 급(Production-Grade) 컨테니어 오케스트레이터였다. 당시엔 그것이 무엇이었는지 기억할 수 없다. 그러나 나를 믿어라. 오케스트레이터라는 말은 나의 마음을 열었다. 나는 컨테이너를 오케스트레이트할, 컨테이너 작업을 조정할 무언가가 필요했다. 컨테니어는 내가 놓친 것이었다. 그때 이후 나는 쿠버네티스를 프로덕션 환경에서 테스트했다. 개발 동안 마찰이 줄었고 셋업 시간도 감소했다. 데브옵스에 들어가는 품도 줄었다.

쿠버네티스란 무엇인가

나는 이미 컨테이너에 대해 긍정적으로 말했다. 나는 모든 컨테이너들이 우리의 애플리케이션을 출시하고 돌리는 분명하게 좋은 방법이기를 바란다. 프로덕션 환경에서  우리는 또한 많은 요구사항들을 갖고 있다. 무엇보다 당신은 다운타임 없이 배치하고, 로드가 늘어날 때 확장하고 싶을 것이다. 아마도 당신은 그렇게 할 수 있다. 한 컨테이너가 죽으면 다른 것이 시작할 것이다. 쿠버네티스를 분산화된 시스템을 회복 탄력성이 있게 운영하기 위한 프레임워크로 생각하라. 쿠버네티스는 당신이 필요로 하는 확장 요구사항, 페일오버(failover), 배치 패턴( deployment patterns) 등을 보살펴 준다.

아래 다이어그램은 쿠버네티스 클러스터가 요구를 어떻게 관리하는지 보여준다.

쿠버네티스는 특별한 기능들을 제공한다.

서비스 디스커버리와 로드 밸런싱(Service discovery and load balancing): 쿠버네티스는 인그레스 컨트롤러(ingress controller)로 불리는 스위스 군용 칼 같은 도구를 제공한다. 이것은 다양한 애드온에 의해 관리될 수 있다. 그러나 기본적으로 DNS나 IP주소를 사용해 컨테니어를 노출한다. 이것은 멋지다. 트래픽이 높으면 쿠버네티스가 균형을 잡아주고 분산시킬 것이기 때문이다. 나아가 이것은 HTTPS를 HTTP 메커니즘에 구현할 수 있다. 따라서 내부 컨테이너들은 HTTP에서 커뮤니케이션할 수 있다. 각각의 컨테이너들에서 인증서(certificates)를 출하해야 하는 번거로움이 없다. 원한다면 당신의 애플리케이션의 하나의 도메인으로 제공하기 위해 일종의 URL도 재작성할 수 있다.

예를 들어 당신은 앵귤러 SPA(angular SPA)를 마이사이트닷컴(www.mysite.com)에서, 마이사이트닷컴API(www.mysite.com/api/)에선 레스트 API(REST API) 앱을 가질 수 있다.

스토리지 오케스트레이션(Storage orchestration): 당신이, 도커 볼륨(docker volumes)에 대해 뭔가 기억한다면, 개념은, 같다. 그러나 약간 진화했다. 당신은 스토리지를 쿠버네티스 클러스터에 연결할 수 있다. 그때 컨테이너 볼륨을 탓하라. 좋은 것은 스토리지는 클라우드 기반 서비스로서 로컬 드라이브를 의미하는 것일 수 있다.

자동화된 롤아웃과 롤백(Automated rollouts and rollbacks): 당신은, 컨테이너 생성을 자동화할 수 있다. 단지, 일부 YAML 파일을 어딘가 추가하기만 하면 된다. 당신은 단지 어떻게 플랫폼을 확장하고 컨테이너들이 어떻게 상호 작용해야 하는지 설명하게 된다.

자동 빈 패킹(Automatic bin packing): 결국 쿠버네티스도 돌아가려면 물리적인 자원을 필요로 한다. 이것은, 당신이  컨테이너가 돌아가도록 하려면 여전히 CPU, 램, 디스크를 올려놓을 필요가 있다는 것을 의미한다. 좋은 소식은 당신이 각각의 컨테이너에  필요로 하는 자원을 명시하면 이것은 쿠버네티스가 보다 확장에 대해 잘 결정하도록 도울 것이다.

셀프 힐링(Self-healing): 쿠버네티스는 컨테이너 베이비시터(babysitter)다. 쿠버네티스는 모든 것을 돌본다. 한 컨테니어가 실패하면 그것을 대체하기 위해 시도할 것이고, 이 컨테이너가 대응하지 않으면 쿠버네티스는 그것을 죽일 것이다.

시크릿과 컨피규레이션 관리(Secret and configuration management): 쿠버네티스가 좋은 것은 컨테이너들에서 설정(컨피규레이션)을 분리해 낼 수 있다는 것이다. 이것은 환경 변수(environment variables)와 같다. 그러나 더 멋지다. 각각의 설정은 글로벌하게 될 수 있다. 하나 이상의 컨테니어에 추가될 수 있다. 더구나 시크릿으로 불리우는 일부 변수는 보안을 보장하기 위해 암호화된다.

이것은 비밀번호, 인증 토큰 또는 SSH 키들 같은 민감한 정보를 위해 매우 유용하다.

쿠버네티스가 아닌 것들.

쿠버네티스에는 좋은 것들이 많다. 모든 쿠버네티스 혜택을 분명하게 보여주기를 바란다. 쿠버네티스 초보자들에게 주요 문제들은 그들이 쿠버네티스가 그들이 생각한 것처럼 서비스형 플랫폼(PaaS)이 아니라는 것을 발견하는 것이다.  쿠버네티스에는 많은 것들이 있지만 모든 서비스가 포함된 것은 아니다. 쿠버네티스는 대단하고 작업양을 줄인다. 시스템 관리(sysadmin) 측면에서 그렇다. 그러나 당신에게 인프라 외에 어떤 것을 제공하지는 않는다.

당신이 완전한 매니지드 시스템을 위해 찾고 있는 대부분의 것들이 쿠버네티스에 있다. 간소화된 배치, 스케일링, 로드 밸런싱, 로깅, 모니터링 등이다. 보통 당신은 당신이 이용하는 호스팅 서비스 표준 설정을 받는다. 그러나 필요하면 이론적으로 그것을 최적화할 수 있다.

쿠버네티스 한계들.

쿠버네티스는 지원하는 애플리케이션 유형들을 제한하지는 않는다. 모든 것을 컨테니어로 쓰일 수 있다. 따라서 모든 컨테이너 애플리케이션들이 돌아갈 수 있다. 기술은 중요치 않다. 반대 상황은 당신이 컨테이너를 손으로 정의해야 한다는 것이다.

쿠버네티스는 자동화된 배치를 제공하지 않는다. 당신은 당신의 도커 저장소에 개발한 이미지를 넣어야 한다. 당신이 이미, 컨티뉴어스 인테그레이션 딜리버리, 배치(Continuous Integration, Delivery, and Deployment: CI/CD)작업을 한다면, 이것은 매우 쉽다. 그렇지 않다면 꽤 만만치 않은 일일 것이다.

쿠버네티스는 애플리케이션 레벨 서비스를 제공하지 않는다. 단지 인프라다. 당신이 데이터베이스를 필요로 하면 서비스를 사야 한다. 아니면 그것을 전용 컨테이너에서 돌려야 한다. 물론 백업 등에 대해서도 책임을 져야 한다.

시스템과의 상호 작용 대부분은 API를 아우르는 커맨드 라인(command line)행에 의해 이뤄진다. 이것은 매우 좋다. 각각의 설정을 자동화하기 때문이다. 커맨드 문법은 매우 간단하다. 그러나 당신이, UI에 의해 완전히 관리되는 시스템을 찾고 있다면, 최악의 공간을 찾은 것이다.

쿠버네티스는 어떻게 작동하나

기술적인 부분에 대해 좀 더 깊이 들어가 보자. 이 부분은 전체 컴포넌트들의 개요가 아니다. 나의 의도는 가장 중요한 컴포넌트들을 설명하고, 기사 후반부에서 덧붙이는 것들에 대해 분명하게 하는 것이다. 물론 스스로 쿠버네티스를 공부할 계획이라면 당신이 어디에 있는지 알기 시작하는 것은 대단한 플러스다.

팟(Pods)

팟은 컨테이너의 고수준 추상화로 생각하라. 추상화에서 팟은 단일 컨테이너 인스턴스나 그룹이 될 수 있다. 팟은 자원을 공유하는 하나 이상의 컨테이너들로 구성돼 있다. 호스트 머신 위에 같이 위치한다. 호스트 머신에서 각각의 팟들은 하나의 고유하게 할당된 IP주소를 갖고 있다. 이것은 도커 환경에 있는 컨테니어들처럼 하나의 팟이 서로 커뮤니케이션할 수 있다는 것을 의미한다. 판안에 각각의 컨테이너들은 버추얼 네트워크에서 모든 각각의 팟들에 이를 수 있다. 그러나 다른 팟에 있는 다른 컨테이너들에는 깊숙이 들어갈 수 없다.

이것은 팟 추상화를 보장하기 위해 중요하다. 팟이 내부적으로 어떻게 구성돼 있는지는 아무도 부른다. 나아가 할당된 IP는 바뀔 수 있다. 따라서 당신은 항상 바로 적절한 IP주소로 이해될 수 있는 서비스 이름을 사용해야 한다.

도커 컨테니어들처럼 팟도, 볼륨을 정의할 수 있다. 이것은 공유 네트워크 드라이브와 비교된다. 이것은 데이터를 계속 유지하고 팟들 사이에서 파일을 공유하는데도 유용하다.

당신은 API를 사용하거나 단지 셸에서 명령을 치는 방법으로 팟들을 관리할 수 있다.

서비스들(Services)

정보 과학에서 서비스라는 이름은 과도하게 사용된다. 쿠버네티스 관점에서 서비스를 생각하면 제공하고 싶은 무언가에 가깝다. 쿠버네티스 서비스들은 팟들의 세트를 포함하거나 복잡한 기능을 제공하거나 하나의 팟을 하나의 컨테이너로 노출한다. 당신은 내부에 데이터베이스와 웹서버를 갖추고 CMS 기능을 제공하는 서비스를 가질 수 있다. 아니면 각각의 두 개 서비스를 가질 수 있다. 하나는 데이터베이스, 다른 하나는 웹서버용이다. 이것은 당신에게 달려 있다.

인그레스 컨트롤러(Ingress controller)

인그레스 컨트롤러는 당신이 외부에 노출할 수 있는 컴포넌트다. 이렇게 하기 위해 로드 밸런서와 비슷한 역할을 하는 인그레스 컨트롤러가 있다. 이것은 사실상 외부 트래픽을 서비스로 밀어준다. 이 단계에서 당신이 선택한 인그레스 구현에 기반해 당신은 HTTPS 암호화를 추가하고 호스트네임이나 URL 세그먼트 기반으로 트래픽을 안내할 수 있다. 단지 서비스 만이 인그레스 컨트롤러에 연결될 수 있다. 팟은 아니다.

볼륨(Volumes)

팟 스토리지는 기본적으로 가변적이다. 이것을 아는 것이 중요하다. 처음 다시 시작할 때 모든 것을 잃을 것이라는 점을 아는 것이 중요하다. 쿠버네티스 볼륨은 쿠버네티스 하드 드라이브 일부를 안정한 장소로 매핑할 수 있게 한다. 이 장소는 컨테이너들 사이에서 공유될 수 있다. 올라가는 부분은 컨테이너의 어떤 부분이 될 수 있다. 그러나 한 볼륨은 또 다른 컨테이너로는 올려질 수 없다.

네임스페이스(Namespaces)

네임스페이스는 쿠버네티스를 멀티테넌트(multitenant)로 만들어주는 기능처럼 생각하라. 네임스페이슨느 테넌트 레벨이다. 각각의 네임스페이스는 서비스들, 인그레스, 다른 많은 것들을 고립시키기 위해 자원을 파티셔닝한다.  이 기능은 애플리케이션들을 강하게 분리하고, 안전하게 다양한 팀들에게 위임하고, 단일 인프라에서 환경을 분리하는데 좋다.

시크릿과 컨피규레이션(Secrets and configuration)

컨피규레이션은, 글로벌하게 컨피그 맵스(config maps) 통해 만들어진다. 이 메커니즘은 이렇게 동작한다. 우선, 당신은 하나의 이상의 컨피그 인벤토리(config inventory)를 만든다. 그리고 컨테이너 환경 변수를 글로벌 변수로 연결한다. 혜택은 분명하다. 한 변수가 바뀌면 당신은 그것을 한 번만 바꾸면 된다. 더구나 민감한 정보를 위해 거기에는 시크릿으로 불리는 멋진 메커니즘이 있다. 시크릿 변수는 암호화돼 한 시스템에 저장된다. 누구도 접근할 수 없다. 시크릿은 다시 그것을 필요로 하는 팟으로만 보내진다.

서비스형 쿠버네티스(Kubernetes as a service)

모든 비(non) 시스템 관리자로서 나는 시스템 어드민 모자를 쓰는 것을 싫어한다. 아마도 나는 과민반응하고 있을 수 있다. 아니면 이것은 단지 부러움일 수 있다. 그러나 두려운 것 중 하나는 다른 사람들의 일을 할 수 없는 것이다. 요즘 당신에게 쿠버네티스를 무료로 주는 많은 서비스들이 있다. 그것을 사용하지 않는 것은 어리석은 일이다. 우리는 수제 마멀레이드(hand-made marmalade)에 대해 말하는 것이 아니다. 그것은 소프트웨어다. 그냥 당신이 할 수 있다면 좀더 나은 플레이어의 것을 사라. 구글, 아마존, 마이크로소프트, IBM 모두 그들의 쿠버네티스 서비스를 갖고 있다. 같은 가격 모델로 돌아간다. 나에게 오라. 모든 쿠버네티스 서비스는  무료일 것이다. 당신은 단지 당신이 사용할 자원에 대해서만 돈을 낼 것이다.

많은 벤더들은 당신에게 무료 계층이나 체험 기간을 준다. 크레딧으로 놀이를 시작하는 것은 쉽다. 나는 이 기사를 위해 애저를 선택했다. 소스코드 통합 동안에 일부 시설 때문이었다. 그러나 이 기사에서 당신이 배울 대부분의 것들은 모두에게 적용된다. 서비스 쿠버네티스는 당신의 애프리케이션은 클라우드에 종속되어야 한다고 요구하지 않는다. 당신의 애플리케이션은 단지 원래의 컨테이너다. 이것은 일부 설정 파일에 의해 오케스트레이션되고, 쿠버네티스와 호환된다. 당신은 애저에서 구글로 , 아니면 구글에서 애저로  애플리케이션을 최소한의 노력으로 옮길 수 있다. 적어도 소스코드를 바꿀 필요는 없다.

따라서 쿠버네티스 서비스는 무료다. 당신은 그것을 위한 하드웨어에만 돈을 내면 된다. 여기서 하드웨어는, 쿠버네티스에 의해 사용되는 버추얼 머신(VM)을 의미한다.

꼭 알아야 할 것들

쿠버네티스는 매우 위대한 플랫폼이다.  전통적인 가상 머신 방패에서 안전하게 빠져나와 클라우드로 갈수 있게 해준다. 그리고 역동적이다. 시스템 관리 비용을 줄여주고 서비스 품질 수준을 끌어올린다. 다양하게 보장하기 어려운, 네트워킹이나 데이터 보호 같은 많은 전통적인 문제들을 진화된 쿠버네티스 설정으로 극복할 수 있다.

나는 쿠버네티스가 당신의 모든 프로젝트들에 좋다고 말할 수는 없다. 그러나 당신의 모든 새로운 프로젝트를 위한 옵션으로 쿠버네티스를 고려해야 한다는 나의 말은 믿어 달라.

테크잇 뉴스레터를 전해드립니다!

오피니언 기반 테크 블로그 'TechIt'
테크 비즈니스를 보는 다양한 통찰들을 이메일로 간편하게 받아 볼 수 있습니다.

About the author

endgame
endgame

테크 블로거 / 공유할만한 글로벌 테크 소식들 틈틈히 전달하겠습니다

No more pages to load


TechIT

테크 비즈니스를 보는 다양한 통찰 '테크잇'

독자 여러분들께서 좋은 의견이나 문의 사항이 있으시면 아래 양식에 따라 문의 주시기 바랍니다.

Contact