안녕하세요,
업로드를 해야지해야지 하면서도 하기가 힘드네요.. 최근엔 이직까지 해서 시간이 정말 부족하다는 것을 새삼 느낌니다.
오늘 나누고 싶은 이야기는 쿠버네티스의 기술적인 이야기보다는 탄생과 시장을 지배하게된 이야기 등입니다.
가벼운 이야기가 될겁니다.
쿠버네티스?
제가 처음 쿠버네티스를 배울 때, 쿠버네티스를 공부해야한다고 말씀해주는 선배들이 하는 이야기가 대충 이랬습니다.
그게 요즘 유행이라던데?
다들 쓴다던데?
암튼 멋있잖아!
그거 하면 연봉오른다더라!
당시 클라우드 인프라 엔지니어로 일하던 저에게는 뭔가 멀면서도 생각보다 가까운 곳에 있는 어떤 기술이었습니다.
다들 당위성을 멋짐이나 연봉으로만 잡았고 기술적인 흐름에 대해서 말해주시진 않았던 것 같습니다. 지금 생각해보면 그런 이야기를 듣기에는 제가 많이 부족했었던 것 같기도 하네요.
그래서 오늘, 왜 쿠버네티스가 등장했고 지금 시장에서 지배적인지 다들 이해하게 되셨으면 좋겠습니다.
쿠버네티스의 등장
쿠버네티스는 구글이 직접 개발해서 이용하던 컨테이너 관리 툴입니다. 사실 구글은 예전부터 이 툴을 이용해오고 있었는데요 그 1세대는 Borg이며 2세대는 Omega였고 3세대가 Kubernetes입니다.
*쿠버네티스는 그리스어로 "조타수"라는 의미를 갖고 있습니다. 그래서 아이콘이 이런 모양이죠.
2015년에 구글은 "Large-scale cluster management at Google with Borg" 논문을 공식적으로 발표하면서 내부 프로젝트인 쿠버네티스를 오픈소스로서 CNCF 재단에 기증합니다.
CNCF란
CNCF는 Cloud Native Computing Foundation의 약자로 The Linux Foundation의 산하 기관입니다. CNCF는 지금은 아주 거대한 오픈소스 재단으로 성장해서 엄청나게 많은 오픈소스 프로젝트를 관리하고 있습니다. 이러한 오픈소스 재단이 존재하는 이유는 기술의 독점을 막기 위해서입니다. 특정 이권에 의해 기술이 사용되는 것을 막기 위해 이러한 재단을 통해 중립성을 보호하도록 관리합니다.
그 중에서도 CNCF는 매우 유명해서 아마 IT에 종사하신다면 한번 쯤은 CNCF에 대해서는 잘 모르시더라도 아래 Landscape는 보신적이 있을겁니다(아마도..).
이 CNCF에 오픈소스로 기증된 프로젝트는 Sandbox, Incubating, Graduated의 3단계로 관리됩니다.
Sandbox: 이 단계에서는 새로운 프로젝트가 CNCF 생태계로 첫 걸음을 내딛는 데 있어 안전한 환경을 제공 받습니다. 여기에 속하는 프로젝트들은 아직 초기 단계에 있으며, CNCF 커뮤니티의 일부로 성장하고 발전하는데 필요한 지원을 받게 됩니다.
Incubating: 샌드박스 단계를 거친 프로젝트는 Incubating 단계로 이동하게 됩니다. 이 단계에서 프로젝트들은 더 넓은 범위의 사용자들로부터 인식을 받고, 더욱 성장하고 개선하는데 필요한 지원을 받게 됩니다.
Graduated: 이 단계의 프로젝트는 CNCF의 기준에 따라 안정적이고, 다양한 기여자를 가지며, 건전한 거버넌스 구조를 가진 것으로 인정받습니다. Graduated 단계에 도달한 프로젝트는 CNCF 커뮤니티의 기술적 성과를 대표하며, 일반적으로 폭넓은 사용자들에게 신뢰받고 사용되는 것으로 알려져 있습니다.
쿠버네티스는 2015년 CNCF로 들어오게되어 2018년에 Graduated 단계에 들어가게 되었습니다. 2015년에는 위의 3단계가 갖춰지기 전이었으며 2018년에 위 체계를 잡았을 때 이미 엄청난 인지도가 있었으며 프로젝트의 성숙도도 매우 높아 곧바로 Graduated로 배정되어 관리되고 있습니다.
시장지배력이 생긴 이유?
사실 쿠버네티스가 등장하기 전에도 컨테이너를 관리하는 툴은 있었습니다.
그치만 다들 뭔가 하나씩 부족한 느낌이었습니다.
컨테이너를 관리하는 것에는 충분했지만 많은 수의 노드에 수 백에서 수 백만에 이르는 컨테이너를 관리하기에도 부족했고 장애 대응이나 스케쥴링 그리고 스케일아웃 등 사용자들의 요구사항을 모두 충족시켜주지는 못했습니다.
그러던 와중에 등장한 쿠버네티스는 혁신적이었습니다.
안정성, 확장성, 그리고 다양한 워크로드를 지원하는 기능이 계속해서 개발되고 추가되었으며, 엄청난 이식성으로 어느 플랫폼에서나 자유롭게 동작했습니다.
그래서 컨테이너를 사용하는 환경에서는 쿠버네티스를 사용하지 않을 이유가 없었습니다.
하지만..
뭐 장점만 있지는 않았습니다..
살인적인 러닝커브를 자랑했죠. 구글에 쿠버네티스를 검색하면 저런 밈을 쉽게 찾을 수 있습니다.
물론 지금은 많이 다릅니다! AWS의 EKS만 써도 인프라나 데브옵스 엔지니어의 암 발병률이 50퍼센트 정도는 감소하는 것 같습니다(비과학, 비공식, 무논리, 유경험😉).
엔지니어는 고통스럽겠지만 잘만 쓰면 너무나 활용도가 좋아 포기할 수가 없는 툴이 되어버렸습니다.
쿠버네티스를 쓸 수밖에 없는 이유 = 컨테이너를 쓰는 이유
지금까지 설명은 너무 당연하게 컨테이너를 사용한다는 전제로 말씀드렸는데요, 진짜 쿠버네티스를 쓰는 이유는 컨테이너를 왜 사용하는지 입니다.
결국 인프라는 어플리케이션이 올라가는 환경이니 어플리케이션에 대해 이해할 필요가 있습니다.
예전에는 어플리케이션이 데이터베이스 중심으로 개발되고 관리되었습니다. 어떤 데이터를 사용하는 어플리케이션인지를 기준으로 설계되었습니다. 하지만 시대가 바뀌면서, 어플리케이션은 시장의 변화에 민감하게 반응할 필요성이 생겼습니다. 그러다보니 데이터보다 비즈니스 로직을 얼마나 잘 반영하느냐가 중요하게 되었습니다(그래서 이때는 DBA가 Developer보다 대우가 더 좋지 않았나 생각합니다).
빠르게 변화하는 시장의 흐름을 따라 비즈니스도 변화합니다. 어플리케이션이 곧 비즈니스인 IT 산업에서는 비즈니스의 요구사항을 빠르게 변화하는 어플리케이션 개발 방식도 필요하게 되었습니다. 이에 맞춰 채택되는 것이 "에자일" 방법론, 개발론, 철학 등등 수많은 이름으로 불리는 어떤 개발 방식이었습니다. 이 개발 방식은 간단하게 말씀드리면 신속하게 플랜을 세우고 개발을하고 평가하고 다시 플랜을 세우고 하는 과정을 신속하게 하는 것이었습니다.
이런 개발 방식을 지원하는 인프라 또한 필요하게 되었습니다. 신속하게 코드를 빌드하고 테스트하고 배포하고 모니터링하는 밑바탕을 제공해야 했습니다. 이에 따라 등장하게된 것이 컨테이너입니다. 컨테이너는 어플리케이션과 그 어플리케이션이 필요로하는 종속성을 같이 패키징하여 어떤 환경에서도 동작하도록 만든 것입니다.
동시에 어플리케이션은 신속하게 빌드되기 위해 더욱 경량화 되어야한다는 요청도 반영되게 되었는데요, 이런 요구사항은 하나의 거대한 어플리케이션을 여러 개의 어플리케이션으로 나누어 개발하게 되도록하였습니다. 이러면서 자연스럽게 MSA(Micro Service Architecture)가 등장합니다. 어플리케이션을 여러 개로 나누어 독립된 서버형태로 관리하게되면 서로 결함이나 보안 문제를 공유하지 않게되어 더욱 훌륭한 아키텍처를 달성할 수도 있게 되었습니다.
기능별로 분리된 어플리케이션이 하나의 거대한 어플리케이션을 구성하도록 설계된 아키텍쳐에서는 컨테이너는 필수이며 이 컨테이너를 종합적으로 관리할 오케스트레이션 툴도 필요할 수밖에 없고 이것을 충족하는 것이 쿠버네티스인 것입니다! 그래서 오늘도 높은 러닝커브 속에서 직업안정성을 갖기 위해 검은 머리를 흰머리로 바꾸거나 민머리로 바꾸고 있죠..
오늘 드리고 싶었던 이야기는 여기까지입니다!
재미가 있으셨을지 모르겠네요 ㅎㅎ 다음엔 기술적인 내용을 가지고 돌아오겠습니다!
모두 건강하시고 더위 조심하세요!!
'Kubernetes' 카테고리의 다른 글
| K8s, _get_comp_words_by_ref: command not found 해결 (0) | 2023.04.25 |
|---|