오늘은 거의 모두가 드러낸 받지만 설명은 하기 어려운 것, 바로 쿠버네티스에 대해 이야기해보겠습니다.이것이 혼란스러운 이유는 대부분의 사람들이 직접 부딪히기 전까지는 알지 못하는 문제를 해결하기 때문입니다.모두가 중요하다는 건 알지만, 무엇을 하는지 물어보면 다들 멍하니 쳐다보기 일쑤죠.사람들이 흔히 추측하는 것처럼 도커를 대체하는 것이나 클라우드 운영체제는 아닙니다.쿠버네티스는 직면하기 전까지는 존재조차 모르는 문제를 해결하기 때문에 혼란스러울 수밖에 없습니다.이 도구는 관리해야 할 컨테이너가 몇 개를 넘어설 때 비로소 필수적인 존재가 됩니다.이번 에피소드를 끝낼 때쯤이면 여러분은 쿠버네티스가 정확히 무엇인지, 컨테이너와는 어떻게 조화를 이루는지, 그리고 왜 A저 키버넷 서비스가 밑바닥부터 모든 것을 구축하고 싶지 않은 팀에게 실용적인 선택지인지 이해하게 될 겁니다.커피 한 잔 준비하시고 본격적으로 시작해보죠.컨테이너 이전의 문제들, 그 문제로 다시 돌아가 보겠습니다. 10년 전이 소프트웨어 회사를 떠올려 보세요.실행할 애플리케이션이 몇 개 있으면 서버를 사고, 운영체제를 설치하고, 모든 것을 수동으로 배포해야 했습니다.각 앱은 전용기기를 할당받았고, 그들 사이에 자원을 공유할 수는 없었습니다.한 앱은 많은 메모리가 필요하고, 다른 앱은 거의 사용하지 않아도, 어쨌든 각자 자신만의 서버를 가졌죠.낭비가 엄청났습니다.서버는 아마 20%의 용량만 사용하며 돌아갔지만, 애플리케이션 간 의존성 문제로 인해 서버를 통합할 수도 없었습니다.결국 서버실은 거의 일도 안 하면서 전력과 냉방비만 잡아먹는 서버들로 가득 찼고, 모두 끊임없는 유지보수가 필요했습니다.한 앱은 파이썬 3.7이 필요하고, 다른 앱은 파이썬 3.8이 필요합니다.하나는 이전 라이브러리가 필요하고, 다른 하나는 최신 버전이 필요하죠.

무언가를 망가뜨리지 않고는 같은 기기에서 실행할 수 없었기에, 결국 서버를 더 구매하고 대부분 놀고 있는 하드웨어에 비용을 지불해야 했습니다.가상 머신은 물리적 서버를 더 작은 단위로 쪼개어 각각 OS를 실행하게 함으로써 조금 도움이 되었지만,각 VM은 전체 OS를 포함해 무겁고, 디스크 공간과 메모리를 차지하며 시작하는 데 몇 분씩 걸렸습니다.게다가 각각 따로 구성해야 했으니 정말 많은 일이 필요했죠.여전히 그 모든 운영체제를 관리하고, 패치하고, 업데이트하고, 보안을 유지해야 했습니다.팀들은 더 가볍고 이식성이 뛰어난 것이 필요했습니다.전체 가상 머신의 오버헤드 없이 애플리케이션을 실행해 필요한 모든 것과 함께 패키징하고,기기 간에 쉽게 이동할 수 있는 방법 이어, 거기에 컨테이너가 등장했습니다.컨테이너란 무엇인가?컨테이너는 애플리케이션과 실행해 필요한 모든 것을 포함하는 작은 패키지입니다.즉, 코드, 런타임, 라이브러리, 설정 파일이 하나의 단위로 묶여있다는 뜻이죠.소프트웨어를 위한 선박용 컨테이너라고 생각하시면 됩니다.해온 컨테이너는 트럭, 기차, 선박 어디에나 실을 수 있으며, 컨테이너 자체는 그대로 유지됩니다.소프트웨어 컨테이너도 같은 방식으로 작동합니다.한 번 빌드하면 노트북, 테스트 서버, 운영 환경 어디에 써든 동일하게 실행됩니다.컨테이너와 가상 머신의 핵심적인 차이는 효율성에 있습니다.가상 머신은 자체적인 전체 운영체제를 실행함으로,각 VM마다 고유 한 커널, 시스템 파일 등 모든 것을 갖추고 있습니다.반면 컨테이너는 호스트 운영체제를 공유합니다.컨테이너는 그저 자신만의 격리된 시각을 가진 프로세스일 뿐입니다.즉, 컨테이너는 몇 분이 아니라 몇 초 만에 시작됩니다.메모리를 적게 사용함으로 단일 장비에 더 많이 탑재할 수 있습니다.도커는 개발자가 단일 명령어로 컨테이너를 빌드하고 실행하는 간단한 방법을 제공하여 컨테이너를 대중화했습니다.

갑자기, 내 컴퓨터에서는 잘 되는데, 라는 문제가 사라지기 시작했습니다.노트북에서 컨테이너로 실행되는 애플리케이션은 서버에서도 동일하게 실행됩니다.어디에서나 일관된 환경이 유지됩니다.하지만 컨테이너는 하나의 문제를 해결하는 동시에 다른 문제를 만들어냅니다.컨테이너가 몇 개일 때는 수동관리로도 충분합니다.직접 시작하고 중지하며 상태를 추적할 수 있기 때문입니다.하지만 수백 개의 컨테이너가 있다면 어떻게 될까요?어떤 서버에서 어떤 컨테이너를 실행할지 결정하고, 실패한 컨테이너를 재시작하고, 서로 연결하며 트래픽 급증 시 규모를 확장해야 합니다.그것은 새로운 도전 과제이며, 바로 이 지점에서 쿠버네티스가 등장합니다.오케스트레이션 문제라는 것이죠.컨테이너가 잘 작동하고 애플리케이션을 패키징했으며, 어디서나 일관되게 실행되니 모든 것이 순조롭습니다.하지만 그것도 잠시뿐입니다. 10개에서 20개의 컨테이너라면 수동으로 관리할 수 있습니다.어떤 서버에 어떤 컨테이너가 있는지 알고, 충돌 시 재시작할 수 있으며, 이따금 업데이트도 가능하니까요.관리 가능한 수준입니다.하지만 애플리케이션이 커지면 상황이 달라집니다.마이크로 서비스로 전환하게 되죠.하나의 거대한 애플리케이션 대신 20개의 작은 애플리케이션을 갖게 됩니다.신뢰성을 위해 각 애플리케이션마다 여러 복제본이 필요해지면, 이제 200개의 컨테이너를 마주하게 됩니다.더 이상 수동 관리로는 불가능합니다.어떤 서버에서 각 컨테이너를 실행할지 결정하고, 실패시 재시작하며, 서로 통신할 수 있도록 연결해야 합니다.또한 할인 행사나 제품 출시 등으로 트래픽이 급증할 때 규모를 늘리고, 잠잠해지면 다시 줄여야 합니다.또한 중단 없이 업데이트를 배포해야 하는데, 이는 기존 컨테이너를 하나씩 조심스럽게 새 컨테이너로 교체하여 아무것도 깨뜨리지 않아야 함을 의미합니다.

이러한 문제들이 바로 오케스트레이션 문제이며, 쿠버네티스는 이를 해결하기 위해 탄생했습니다.쿠버네티스는 컨테이너화된 애플리케이션의 배포, 확장, 관리를 자동화하는 오픈소스 플랫폼입니다.데이터 센터를 위한 운영체제라고 생각하면 됩니다.윈도우 나 리눅스가 단일 컴퓨터의 CPU, 메모리, 디스크 같은 자원을 관리하듯, 쿠버네티스는 모든 서버의 자원을 관리합니다.쿠버네티스는 모든 머신을 하나의 거대한 컴퓨팅 파워풀로 취급합니다.실행할 것을 알려주기만 하면, 어디에 배치할지, 어떻게 계속 실행할지, 어떻게 다른 것들과 연결할지를 알아서 처리합니다.핵심 개념, 파드, 핫, 노드, 노드, 그리고 클러스터, 클러스터.쿠버네티스가 실제로 어떻게 작동하는지 살펴보겠습니다.쿠버네티스에서 가장 작은 단위는 파드라고 불립니다.파드는 하나 이상의 컨테이너를 감싸는 역할을 합니다.같은 파드 내의 컨테이너들은 스토리지와 네트워크를 공유하므로 로컬고스트를 통해 서로 통신할 수 있습니다.파드를 단일 배포 단위로 생각할 수 있습니다.쿠버네티스에서는 컨테이너를 직접 배포하지 않습니다.대신 파드를 배포합니다.파드는 스스로 실행되지 않으며 노드 위에서 실행됩니다.노드는 쿠버네티스 클러스터의 일부인 물리적 또는 가상 서버를 의미합니다.각 노드는 파드를 실행하는 데 필요한 소프트웨어와 곧 설명할 몇 가지 다른 요소들을 실행합니다.클러스터는 하나의 통합된 시스템으로 관리되는 모든 노드의 집합입니다.간단히 말해 파드는 애플리케이션이고 노드는 그것이 실행되는 곳이며 클러스터는 전체 환경입니다.파드는 일시적입니다.파드는 언제든지 생성, 삭제 또는 이동될 수 있습니다.그것이 설계 위도입니다.노드에 문제가 생기면 쿠버네티스는 파드를 다른 노드로 옮깁니다.확장이 필요할 때는 새로운 파드를 생성합니다.그리고 파드가 중단되면 자동으로 교체됩니다.

시스템 전체가 파드를 일시적인 것으로 취급합니다.하지만 파드가 계속 생성되고 사라진다면 그들과 통신할 방법이 필요합니다.파드와 직접 통신하는 대신 서비스, 서비스를 통해 통신합니다.서비스는 파드가 변경되더라도 적절한 파드로 트래픽을 라우팅하는 안정적인 네트워크 주소를 제공합니다.호텔을 상상해보세요.호텔의 전화번호가 바로 서비스입니다.객실 투숙객은 계속 바뀌지만 전화번호는 그대로 유지됩니다.프런트 데스크에 전화하면 그들이 적절한 방으로 연결해주는 것과 같습니다.쿠버네티스의 서비스가 하는 역할도 정확히 이와 같습니다.서비스는 현재 애플리케이션을 실행 중인 파드들로 항상 연결되는 고정된 주소를 제공합니다.컨트롤 플레인, 클러스터의 두뇌, 자, 이제 파드, 노드, 클러스터에 대해 알게 되었습니다.그렇다면 무엇이 어디서 실행될지 결정하는 주체는 누구일까요?그것이 바로 컨트롤 플레인의 역할입니다.모든 쿠버네티스 클러스터에는 컨트롤 플레인이 있으며 이것이 전체 운영의 두뇌 역할을 합니다.모든 결정은 여기서 이루어집니다.컨트롤 플레인에는 여러 구성 요소가 있습니다.첫 번째는 클러스터의 정문 역할을 하는 API 서버입니다.명령줄, 대시보드, 자동화된 스크립트 등 키버넷으로 보내는 모든 명령은 API 서버를 통과합니다.요청을 인증하고 허용된 작업인지 확인한 다음 적절한 곳으로 전달합니다. API 서버를 거치지 않고는 키버넷에서 아무 일도 일어나지 않습니다.다음은 각 파드를 실행할 노드를 결정하는 스케줄러입니다.이 애플리케이션을 실행하고 싶다, 고 말하면스케줄러는 사용 가능한 모든 노드를 살펴보고 CPU, 메모리, 디스크 공간 등 가용 자원을 확인하여 작업에 가장 적합한 노드를 선택합니다.마치 호텔 매니저가 투숙객에 필요에 따라 객실을 배정하는 것과 같습니다.짐이 많은 손님에게는 더 큰 방을 배정하고, 가벼운 애플리케이션은 여유 공간이 있는 작은 노드에 배치합니다.

그 다음은 컨트롤러 매니저입니다.이 구성 요소는 클러스터를 감시하며 실제 상태가 사용자가 선언한 상태와 일치하는지 확인합니다.웹앱의 복제본 3개를 실행하겠다고 선언했다고 가정해봅시다.컨트롤러 매니저는 실제로 3개의 복제본이 실행 중인지 확인합니다.하나가 중단되면 이를 감지하고 대체 인스터스를 시작합니다.누군가 실수로 파드를 삭제하면 즉시 새로운 파드를 생성합니다.클러스터의 상태를 올바르게 유지해주는 구성 요소입니다.마지막으로 클러스터의 데이터베이스인 etcd가 있습니다.무엇이 실행 중인지, 어디에서 실행 중인지, 어떻게 구성되었는지 등 모든 것을 저장합니다.클러스터 전체의 진실의 원천, 소스 오브 트로스입니다. api 서버가 정문이라면 etcd는 모든 기록이 보관된 사무실 뒤편의 캐비닉과 같습니다.이 설계의 아름다움은 당신이 원하는 것을 설명하면 퀴버넷과 이를 구현하는 방법을 알아서 처리한다는 점입니다.어떻게 해야 하는지 지시하는 것이 아니라 최종 결과물이 어떠해야 하는지 알려주는 것입니다.이것이 선언적 모델이며 퀴버넷과 수행하는 모든 작업의 핵심 아이디어입니다.워크로드, 배포, 서비스, 그리고 스케일링입니다.이제 퀴버넷에서 애플리케이션을 실제로 어떻게 실행하는지 이야기해봅시다.파드를 직접 만들지는 않을 것입니다.대신 배포, 디플로이먼트라는 더 높은 수준의 객체를 사용하게 됩니다.배포는 퀴버넷에게 파드 복제본을 몇 개 실행할지, 어떤 컨테이너 이미지를 사용할지,새 버전이 나올 때 어떻게 업데이트할지 알려주는 관리자라고 생각하세요.상태 비저장, 스테이틀러스, 애플리케이션을 실행하는 표준 방식입니다.배포를 업데이트할 때, 즉 앱의 새 버전을 푸시하면 퀴버넷는 롤링 업데이트를 수행합니다.포드를 하나씩 교체하여 최소한 하나의 복제본은 항상 실행되도록 보장합니다.즉, 사용자에게 가동 중지 시간이나 갑작스러운 중단이 발생하지 않습니다.

새 버전에 문제가 생기, 더라도 명령어 한 번으로 이전 버전으로 되돌릴 수 있습니다.매우 강력한 안전망인 셈이죠.하지만 포드는 여전히 연결 가능한 상태여야 합니다.바로 이때 서비스, 서비스가 필요합니다.서비스는 트래픽을 올바른 포드로 전달하는 안정적인 네트워크 주소를 제공합니다.또한 이러한 포드를 애플리케이션의 다른 부분이나 외부 세계에 노출할 수도 있습니다.서비스는 클러스터 내부에서만 접근 가능한 내부용이거나,사용자가 인터넷을 통해 접근할 수 있는 공용 IP 주소를 가진 외부용일 수 있습니다.이제 확장성에 대해 이야기해보겠습니다.쿠버네티스는 수요에 따라 애플리케이션을 자동으로 확장하거나 축소할 수 있습니다.예를 들어 CPU 사용률 70%를 목표로 설정하면,쿠버네티스는 사용량이 그 임계값을 초과할 때 포드를 추가하고, 낮아지면 제거합니다.애플리케이션은 트래픽이 급증할 때 확장되고, 트래픽이 줄어들면 다시 축소됩니다.수동 개입은 필요하지 않습니다.하지만 이 모든 강력한 기능에는 복잡함이 따릅니다.직접 쿠버네티스 클러스터를 운영한다는 것은 컨트롤 플레인, 업그레이드, 보안 패치, 백업을 직접 책임져야 함을 의미합니다.노드 장애, 네트워크 구성, 클러스터 확장을 처리하려면 깊은 전문 지식이 필요합니다.많은 팀이 애플리케이션을 구축하는 시간보다 클러스터를 관리하는 데 더 많은 시간을 보냅니다.바로 여기서 관리형 쿠버네티스가 등장합니다.직접 관리형과 관리형 쿠버네티스의 비교입니다.그럼 쿠버네티스를 직접 운영하는 현실에 대해 이야기해봅시다.직접 클러스터를 설정하면 컨트롤 플레인, 업그레이드, 보안 패치, ETCD 백업 등 모든 것을 책임져야 합니다. API 서버가 중단되면 그것은 여러분의 문제입니다.사용 중인 버전의 보안 취약점이 발견되면 직접 패치해야 합니다. ETCD가 손상되면 백업에서 복원해야 합니다.

이 모든 과정에는 깊은 전문 지식이 필요합니다.노드가 어떻게 실패하는지, 클러스터 수준에서 네트워킹이 어떻게 작동하는지,그리고 시스템을 중단시키지 않고 어떻게 확장하는지 이해해야 합니다.많은 팀이 놀라는 사실이 있습니다.많은 조직이 클러스터에서 실행되는 애플리케이션을 구축하는 것보다쿠버네티스 클러스터를 관리하는데 더 많은 시간을 소비합니다.그들은 끊임없이 업그레이드와 실험하고 네트워크 문제를 해결하며 노드 장애를 처리합니다.클러스터 관리가 풀타임 업무가 되어버리는 것입니다.애초에 쿠버네티스를 도입한 이유는 그런 것이 아니었을 겁니다.이때 바로 관리형 쿠버네티스 서비스가 필요합니다.에이저 퀴버넷 서비스, AKS와 같은 서비스가 컨트롤 플레인을 대신 처리해줍니다.에이저는 API 서버, ETCD, 스케줄러, 컨트롤러 관리자를 직접 관리합니다.여러분은 패치나 운영 유지에 대해 걱정할 필요가 없습니다.실제 워크로드를 실행하는 가상 머신인 워커노드에 대해서만 비용을 지불하면 됩니다.제어 평면 자체는 무료입니다.이는 상황을 완전히 바꿔놓습니다.클러스터 유지 관리에 시간을 쏟는 대신,팀은 구축 중인 애플리케이션 등 더 중요한 일에 집중할 수 있습니다.대부분의 팀, 특히 이제 막 시작하는 팀에게는 관리형 쿠버네티스가 올바른 선택입니다.운영 부담 없이 쿠버네티스 위 모든 강력한 기능을 누릴 수 있습니다. AKS, 에이저에서 간편하게 구현하는 쿠버네티스.그렇다면 AKS란 정확히 무엇일까요?에이저 위 관리형 쿠버네티스 서비스로처음부터 구축할 필요 없이 모든 기능을 갖춘 클러스터를 제공합니다.앞서 언급했듯이 제어 평면은 무료임으로워크로드를 실행하는 가상 머신에 대해서만 비용을 지불합니다.즉, 작게 시작하여 비용을 최소화하고 필요에 따라 규모를 확장할 수 있습니다.에이저가 모든 복잡한 작업을 처리합니다.제어 평면에 대한 업그레이드, 패치, 상태 모니터링이 모두 자동으로 이루어집니다.

시스템 운영을 위해 쿠버네티스 전문가로 구성된 전담팀이 필요하지 않습니다.또한 AKS는 에이저 생태계의 일부임으로이미 사용 중일 가능성이 높은 도구들과 통합됩니다.인증을 위한 에이저 액티브 디렉토리,로깅 및 매트릭을 위한 에이저 모니터,거버넌스를 위한 에이저 플리시 가 있습니다.이 모든 것이 기본적으로 함께 작동합니다.별도의 구성 요소를 덧붙일 필요가 없습니다.기터브 액션스 나이저 데북스를 통한 CI, CD 파이프 라인 설정은 몇 분이면 충분합니다.저장소의 변경 사항을 푸시하면 자동으로 새 컨테이너 이미지가 빌드되고,에이저 컨테이너 레지스트리 로 푸시되며, AKS 위 배포가 업데이트됩니다.수동 단계나 서버에 SSH로 접속할 필요가 없습니다.모든 과정이 자동화되어 있습니다.초보자를 위해 클러스터 구성에 관한 모든 결정을 내리기 원치 않는 팀을 위한AKS 자동 모드가 마련되어 있습니다.확장, 네트워킹, 보안 및 업그레이드를 위한 바로 사용할 수 있는 기본값을 제공합니다.시작하기 위해 쿠버네티스 전문가가 될 필요는 없습니다.애플리케이션을 설명하기만 하면 AKS가 나머지를 처리합니다.명령어 하나로 클러스터를 생성하고,매니페스트 파일 하나로 애플리케이션을 실행할 수 있습니다. AKS에서 익힌 기술은 표준 쿠버네티스를 기반으로 함으로,다른 어떤 쿠버네티스 환경에서도 그대로 활용 가능합니다.독점적인 시스템을 배우는 것이 아니라,에이저가 운영 복잡성을 처리하는 실제 쿠버네티스를 배우는 것입니다.이제 큰 그림을 이해하셨을 겁니다.컨테이너는 애플리케이션을 패키징하여 어디서나 일관되게 실행되도록 하며,쿠버네티스는 해당 컨테이너를 대규모로 오케스트레이션하여 배포, 확장, 복구를 자동으로 처리합니다. AKS는 제어 평면을 관리하고,이미 알고 있는 에이저 도구와 통합함으로써 이러한 오케스트레이션을 쉽게 만듭니다.

핵심은 이것입니다.쿠버네티스는 거대한 엔지니어링 팀을 둔 대기업만을 위한 것이 아닙니다. AKS와 같은 관리형 서비스를 이용하면 어떤 팀이든 이를 활용할 수 있습니다.이번 주 숙제는 간단합니다.무료 에이저 계정을 만들고, AKS 클러스터를 시작한 뒤, 간단한 애플리케이션을 배포해보세요.몇 분이면 충분하며, 플랫폼이 얼마나 발전했는지 알게 되실 겁니다.더 깊이 알아볼 준비가 되셨나요?다음 에피소드에서는 첫 컨테이너 이미지를 빌드하고,에이저 컨테이너 레지스트리 FC하는 방법을 다룹니다.즐겨 사용하는 팟캐스트 플랫폼에서 구독하시고,쿠버네티스를 막 시작하려는 분들께의 영상을 공유해주세요.