Kubernetes는 10 세가되었습니다 : 지난 10 년 동안 클라우드 네이티브 컴퓨팅을 조종하는 방법 - 다음은 다음과 같습니다.

리눅스, 클라우드, 컨테이너, 또는 쿠버네티스를 기술 환경에서 제거한다면, 전혀 알아볼 수 없는 세상에 놓이게 될 것입니다. 리눅스는 이 모든 기술의 기반을 이루며, 클라우드는 방대한 자원과 애플리케이션에 대한 접근을 제공하고, 컨테이너는 이러한 앱의 집을 제공하며, 쿠버네티스는 모든 컨테이너를 조화롭게 유지합니다. 이 중 하나라도 없어진다면, 우리는 기술의 더 원시적인 시대로 되돌아갈 것입니다.

특히 쿠버네티스는 지난 10년 동안 클라우드 네이티브 컴퓨팅의 세계를 극적으로 변화시켰습니다. 10주년을 기념하는 쿠버네티스는 오픈소스 협업과 혁신의 힘을 보여주는 빛나는 사례입니다. 구글에서 시작되어 컨테이너 오케스트레이션의 표준으로 자리 잡으며, 애플리케이션 배포, 관리, 확장을 혁신적으로 바꿔놓았습니다.

그리고 제 말만 믿을 필요는 없습니다. 퓨어 스토리지의 최근 2024 쿠버네티스 전문가의 목소리 보고서에 따르면, "앞으로 5년 동안 신규 애플리케이션의 80%가 클라우드 네이티브 플랫폼에서 구축될 것"이라고 밝혔습니다. 개인적으로는 이 수치가 더 높지 않은 것이 놀랍습니다.

쿠버네티스의 컴퓨팅에 미친 영향

쿠버네티스는 컴퓨팅 접근 방식을 근본적으로 변화시켰습니다. eBPF 기반 네트워킹, 보안, 관찰 가능성 회사인 이소밸런트(Isovalent)의 최고 오픈소스 책임자인 리즈 라이스(Liz Rice)가 제게 설명했듯이, 쿠버네티스는 네트워킹과 보안 접근 방식을 변화시켰습니다:

쿠버네티스는 본질적으로 동적입니다. 파드는 수요에 따라 확장하거나 축소할 수 있으며, 워크로드는 다른 머신에 스케줄링되거나 재스케줄링될 수 있습니다. 따라서 쿠버네티스 워크로드 간의 네트워킹은 IP 패킷을 사용하지만, IP 주소는 단기적으로만 의미가 있습니다. 왜냐하면 IP 주소는 다른 시간에 다른 워크로드에 대해 사용되고 재사용되기 때문입니다. 이는 포트와 IP 주소를 기반으로 트래픽을 식별하는 전통적인 네트워킹 및 보안 도구로는 더 이상 충분하지 않다는 것을 의미합니다. 우리는 일시적인 IP 주소를 파드, 서비스, 네임스페이스, 노드와 같은 의미 있는 쿠버네티스 아이덴티티에 매핑하는 도구가 필요합니다.

지난 10년을 되돌아보며 쿠버네티스가 어디서 시작되었는지, 클라우드 네이티브 환경을 어떻게 형성했는지, 그리고 미래에는 어떤 가능성이 있는지 살펴보겠습니다.

쿠버네티스의 기원

쿠버네티스의 이야기는 2010년대 초 구글에서 시작됩니다. 당시 엔지니어들은 대규모 컨테이너화된 애플리케이션 관리의 도전 과제를 해결하고 있었습니다. 컨테이너는 점점 더 중요해지고 있었고, 관리 솔루션이 절실히 필요했습니다.

구글 내부에서는 컨테이너를 조직화하는 중요성이 이미 잘 이해되고 있었습니다. 구글은 도커가 컨테이너를 대중화하기 훨씬 전부터 컨테이너를 사용해왔습니다. 2013년 구글 엔지니어인 크레이그 맥럭키(Craig McLuckie), 조 베다(Joe Beda), 브렌던 번스(Brendan Burns)가 당시 구글의 기술 인프라 책임자였던 우르스 회즐레(Urs Hölzle)에게 이 아이디어를 제안했을 때, 그는 이렇게 반응했습니다: "잠깐, 제대로 이해했는지 확인하고 싶습니다. 당신들은 Borg 작업 스케줄러의 외부 버전을 만들고 싶다고요? 우리에게 가장 중요한 경쟁 우위 중 하나이자, 외부에 전혀 언급하지 않는 그 기술을? 게다가 그것을 오픈소스로 공개하고 싶다고요?"

네, 정확히 그들이 원했던 것입니다. 그리고 결국 그들은 회즐레를 설득했습니다.

맥럭키는 그들의 논리를 이렇게 설명했습니다:

우리는 항상 쿠버네티스를 오픈소스로 공개하는 것이 올바른 방향이라고 믿었습니다. 이는 프로젝트에 많은 이점을 가져왔습니다. 첫째, 피드백 루프는 거의 즉각적이었습니다. 문제가 있거나 제대로 작동하지 않는 부분이 있으면 즉시 알 수 있었습니다. 하지만 가장 중요한 것은, 컨테이너 배포로 혜택을 볼 수 있는 비즈니스의 요구를 진정으로 이해하는 훌륭한 엔지니어들과 함께 일할 수 있었다는 점입니다. 이는 선순환이었습니다: 뛰어난 엔지니어들의 작업은 프로젝트에 대한 더 많은 관심을 불러일으켰고, 이는 개선 속도와 사용률을 더욱 높였습니다.

2014년 6월 초, 첫 번째 도커콘(DockerCon)에서 "컨테이너 오케스트레이션 전쟁"이 시작되었습니다. 아파치 메소스(Apache Mesos), 레드햇의 기어D(GearD), 도커 립스웜(Docker Libswarm), 페이스북의 터퍼웨어(Tupperware), 그리고 쿠버네티스가 모두 발표되었습니다. 당시 드론.io(Drone.io)의 설립자인 브래드 리드제프스키(Brad Rydzewski)는 이렇게 말했습니다: "#dockercon에서 배운 것: 모두가 자신만의 오케스트레이션 플랫폼을 만들고 있습니다. 진심으로, 모두가요."

그의 말이 틀리지 않았습니다. 더 많은 오케스트레이션 프로그램이 빠르게 뒤따랐습니다.

초기 시절에도 저는 쿠버네티스가 승자로 떠오를 것이라고 믿었습니다. 이는 구글의 Borg 컨테이너 관리 프로그램에서 영감을 얻었으며, Borg는 2003년부터 사용되어 다른 경쟁자들보다 성숙한 수준을 갖추고 있었습니다.

쿠버네티스는 빠르게 주목을 받았습니다. "쿠버네티스"라는 이름은 그리스어로 "조타수" 또는 "파일럿"을 의미하는 단어에서 유래했으며, 이는 컨테이너화된 애플리케이션을 조종하는 역할을 상징합니다. 쿠버네티스 로고는 7개의 스포크가 있는 배의 키를 형상화하여 Borg 유산과 초기 이름인 세븐 오브 나인(Seven of Nine, 스타트렉의 친근한 Borg 캐릭터)을 기리지만, 상표 문제로 인해 이 이름은 사용되지 않았습니다.

빠른 채택과 커뮤니티 성장

쿠버네티스의 오픈소스 특성과 강력한 기능 세트는 개발자와 기업들 사이에서 즉각적인 인기를 끌었습니다. 2015년까지 쿠버네티스는 버전 1.0에 도달했고, 구글은 리눅스 재단(Linux Foundation)과 협력하여 클라우드 네이티브 컴퓨팅 재단(CNCF)을 설립했으며, 쿠버네티스를 그 씨앗 기술로 삼았습니다. 이 움직임은 쿠버네티스 주변에 활기찬 커뮤니티를 형성하는 데 결정적이었으며, 빠른 혁신과 광범위한 채택으로 이어졌습니다.

다른 컨테이너 오케스트레이션 프로그램들이 여전히 존재하지만, 2017년 아마존 웹 서비스(AWS)가 쿠버네티스용 엘라스틱 컨테이너 서비스(EKS)를 발표하며 쿠버네티스의 클라우드 네이티브 세계에서의 지배력을 알렸습니다.

동시에 CNCF는 쿠버네티스 생태계를 육성했습니다. 오늘날 수백 개의 클라우드 네이티브 프로그램이 쿠버네티스에 의존하고 있습니다. 주요 클라우드 제공업체 중 쿠버네티스 없이 운영되는 곳은 없습니다. 이는 컨테이너 오케스트레이션 플랫폼의 표준이 되었습니다.

클라우드 네이티브 개발의 변화

쿠버네티스가 클라우드 네이티브 개발에 미친 영향은 과소평가될 수 없습니다. 이는 애플리케이션 배포 및 관리에 대한 새로운 패러다임을 도입하여 개발자들이 인프라 관리보다는 코드 작성에 집중할 수 있게 했습니다. 쿠버네티스는 컨테이너 오케스트레이션의 복잡성을 추상화하여 자동화된 롤아웃 및 롤백, 자가 치유, 수평 확장과 같은 기능을 제공합니다.

쿠버네티스의 또 다른 중요한 장점은 이식성입니다. 쿠버네티스에 배포된 애플리케이션은 모든 클라우드 제공업체나 온프레미스 인프라에서 실행될 수 있어 하이브리드 및 멀티 클라우드 환경에 이상적인 선택입니다. 이러한 유연성은 기업들에게 판도를 바꾸는 요소였으며, 벤더 종속을 피하고 클라우드 전략을 최적화할 수 있게 했습니다.

수년에 걸쳐 쿠버네티스는 그 기능을 확장하는 풍부한 도구와 프로젝트의 생태계를 낳았습니다. 여기에는 애플리케이션 배포 및 관리를 단순화하는 쿠버네티스 패키지 매니저인 헬름(Helm)과 쿠버네티스 환경을 위한 강력한 모니터링 및 경고 도구인 프로메테우스(Prometheus)가 포함됩니다.

쿠버네티스의 부상은 또한 GitOps와 같은 새로운 패러다임을 낳았으며, 이는 선언적 인프라 및 애플리케이션 관리를 위한 단일 진실의 소스로 Git을 활용합니다.

쿠버네티스의 미래

앞으로 쿠버네티스는 느려질 기미를 보이지 않습니다. 플랫폼은 정기적으로 새로운 기능과 개선 사항이 추가되며 계속 진화하고 있습니다. 쿠버네티스 커뮤니티는 사용자 경험을 단순화하고, 보안을 강화하며, 확장성을 향상시킬 방법을 탐구하고 있습니다.

체인 가드(Chainguard)의 공동 설립자이자 쿠버네티스 창시자 중 한 명인 빌레 아이카스(Ville Aikas)는 이렇게 관찰했습니다:

우리는 CNCF 환경이 크게 확장된 것을 보았으며, 이는 플랫폼 팀에게 다양한 도구와 인프라 옵션을 제공한다는 점에서 멋진 일입니다. 하지만 이는 쿠버네티스를 운영하기 위해 많은 선택을 해야 한다는 것을 의미하기도 합니다. 저는 항상 쿠버네티스가 인기를 얻은 핵심 이유 중 하나가 그 API가 매우 단순하고 사용에 따른 인지적 부담이 상대적으로 낮다는 점이라고 느꼈습니다. 쿠버네티스가 계속 성숙해짐에 따라, 그 정신적 모델의 단순성과 API의 사용성을 유지해야 합니다.

쿠버네티스와 클라우드 네이티브 프로그래밍 패러다임의 균형은 점점 더 복잡해지고 있습니다.

eBPF 성능 모니터링 회사인 그라운드커버(Groundcover)의 CEO이자 공동 설립자인 샤하르 아줄라이(Shahar Azulay)는 이렇게 말했습니다:

쿠버네티스는 다양한 작업을 효과적으로 관리할 수 있는 능력을 입증했지만, 그 복잡성으로 인해 상당한 설정과 지속적인 유지보수가 필요합니다. 리눅스가 신뢰할 수 있는 운영 체제로 발전한 것처럼, 저는 쿠버네티스가 더 사용자 친화적인 추상화 계층으로 변모할 것으로 기대합니다. 쿠버네티스 채택이 10년째 계속 증가함에 따라 효율성과 비용 최적화의 필요성이 점점 더 중요해지고 있습니다.

미래를 내다보며 이소밸런트의 라이스(Rice)는 이렇게 덧붙였습니다:

우리는 이미 쿠버네티스가 레거시 워크로드와 함께 더 많은 하이브리드 환경에서 그리고 에지 디바이스에서 사용되는 것을 보고 있습니다. 실리움(Cilium)의 비전은 애플리케이션 개발자가 자신이 상호작용하고자 하는 서비스가 어디에서 실행되고 있는지 알거나 신경 쓸 필요가 없어야 한다는 것입니다: 연결성과 보안은 모두 플랫폼 레이어에서 처리되어야 합니다.

또 다른 흥미로운 발전은 쿠버네티스와 서버리스 컴퓨팅의 통합입니다. 큐블리스(Kubeless)와 피션(Fission)과 같은 프로젝트는 쿠버네티스에 서버리스 기능을 도입하여 개발자들이 기존 쿠버네티스 클러스터 위에 함수로서의 서비스(FaaS)를 구축하고 배포할 수 있게 합니다. 서버리스와 쿠버네티스의 이 융합은 클라우드 네이티브 애플리케이션에 새로운 가능성을 열어줄 것입니다.

에지 컴퓨팅과 쿠버네티스도 함께 성장하고 있습니다. 더 많은 디바이스와 애플리케이션이 에지로 이동함에 따라, 쿠버네티스는 에지 배포를 지원하도록 적응되고 있습니다. 쿠버네티스 커뮤니티는 KubeEdge, MicroK8s, 레드햇 디바이스 에지(Red Hat Device Edge)와 같은 프로젝트를 통해 에지 디바이스에서 실행될 수 있는 가볍고 효율적인 쿠버네티스 클러스터를 가능하게 하고 있습니다.

쿠버네티스의 미래는 밝아 보입니다. 지속적인 혁신과 활기찬 생태계로, 쿠버네티스는 앞으로도 수년간 클라우드 네이티브 환경을 형성할 준비가 되어 있습니다. 혁신, 협업, 그리고 컨테이너 오케스트레이션의 우수성으로 가득한 또 다른 10년의 쿠버네티스를 기대합니다.