[Container 이론] 4. 도커에서 쿠버네티스로

목차

1. Docker의 단점
2. Kubernetes 시작
3. Kubernetes란?
4. Kubernetes 구성
5. Kubernetes 핵심 기능
6. 마치며

---

Docker의 단점

이전에 우리는 Docker를 사용하기까지 과정과 Docker에 대해서 알아보았습니다. 하지만 그렇게 유용한 Docker도 점점 시스템에 배포 가능한 애플리케이션 구성 요소의 수가 많아짐에 따라 모든 구성 요소의 관리가 더욱 어려워졌고, 이로 인해 수천 개의 소프트웨어 구성 요소를 관리하고 비용 효율적으로 개발, 배포할 수 있는 솔루션을 개발해야만 했습니다. 다음은 해당 내용 외에 Docker의 단점을 조금 모아보았습니다.

1. 학습 곡선
   Docker는 컨테이너화 및 DevOps 관행에 익숙하지 않은 사람들을 위해 가파른 학습 곡선을 가질 수 있습니다.
   
   
2. 보안
   컨테이너는 호스트 운영 체제의 커널을 공유합니다. 즉, 하나의 컨테이너가 손상되면 동일한 호스트의 다른 컨테이너도 취약해질 수 있습니다.
   
   
3. 리소스 오버헤드
   실행 중인 컨테이너는 호스트 시스템의 성능에 영향을 미칠 수 있는 상당한 양의 리소스를 소비할 수 있습니다.
   
   
4. 복잡성
   Docker는 애플리케이션의 패키징 및 배포를 단순화하지만 특히 대규모 환경에서 전체 시스템 아키텍처에 복잡성을 추가할 수 있습니다.
   
   
5. 무분별한 이미지 확산
   도커 이미지는 빠르게 축적되어 관리하기 어려워져 "이미지 무분별한 확산"이라는 현상이 발생합니다.
   
   
6. 제한된 이식성
   Docker 컨테이너는 여러 운영 체제 간에 이식 가능하지만 시스템 아키텍처 및 커널 버전의 차이로 인해 이식성에 여전히 몇 가지 제한이 있습니다.
   
   
7. 볼륨 관리
   Docker 컨테이너에서 영구 데이터를 관리하는 것은 어려울 수 있습니다. 컨테이너를 삭제하거나 다시 빌드할 때 데이터가 손실되지 않도록 컨테이너 외부에 데이터를 저장해야 하기 때문입니다.

---

Kubernetes 시작

오랫 동안 구글은 보그(Borg)라는 내부 시스템을 개발해 애플리케이션 개발자와 시스템 관리자가 수천 개의 애플리케이션과 서비스를 관리하는 데 도움을 줬습니다. 개발과 관리를 단순화할 뿐 아니라 인프라 활용률을 크게 높일 수 있었는데, 이는 조직이 그만큼 클 때 중요해집니다. 사용률이 조금만 올라도 수백만 달러가 절약되므로 이런 시스템의 필요성을 충분했습니다.

 

이후 구글은 10년 가량 보그와 오메가를 비밀로 유지하다 2014년 보그, 오메가, 기타 내부 구글 시스템을 경험을 바탕으로 오픈 소스 시스템인 쿠버네티스를 출시했습니다.

---

Kubernetes란?

Kubernetes는 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하도록 설계된 오픈 소스 컨테이너 오케스트레이션 플랫폼입니다. 원래 Google에서 개발했으며 현재 CNCF(Cloud Native Computing Foundation)에서 관리하고 있습니다.

일반적으로 "K8s"라고 하는 Kubernetes는 분산 시스템의 원칙을 기반으로 하며 여러 호스트에서 컨테이너화된 워크로드를 관리하는 데 사용되어 자동 확장, 자가 복구 및 로드 밸런싱을 제공합니다. 이를 통해 개발자는 애플리케이션을 쉽게 배포, 관리 및 확장할 수 있으므로 클라우드 네이티브 애플리케이션을 구축하고 배포하는 데 널리 사용됩니다.

Kubernetes는 단일 컴퓨팅 리소스를 형성하기 위해 함께 그룹화되는 물리적 또는 가상 머신일 수 있는 노드의 클러스터를 생성하여 작동합니다. 이러한 노드는 노드에 대한 컨테이너 예약 및 배포, 상태 모니터링, 확장 및 로드 밸런싱 관리를 담당하는 컨트롤 플레인에서 관리합니다.

Kubernetes의 주요 기능 중 하나는 자동 확장 및 자가 복구를 포함하여 컨테이너화된 애플리케이션의 관리를 자동화하는 기능입니다. 즉, 컨테이너가 실패하거나 종료되면 Kubernetes는 애플리케이션이 계속해서 원활하게 실행되도록 다른 노드에서 컨테이너를 자동으로 다시 시작합니다.

또한 Kubernetes는 개발자가 고도로 확장 가능하고 유연한 방식으로 애플리케이션을 관리할 수 있도록 하는 풍부한 API 및 도구 세트를 제공합니다. 여기에는 업데이트 롤링, 버전 관리 및 업데이트 롤백을 위한 도구와 서비스 검색, 로드 밸런싱 및 스토리지에 대한 기본 제공 지원이 포함됩니다.

 

* 참고로 K8s는 K ubernete s. 즉, K와 s 사이에 8개의 알파벳이 있어서 이렇게 표현합니다.

---

Kubernetes 구성

가장 간단한 구성으로는 하나의 마스터 노드와 여러 워커 노드로 구성됩니다. 개발자가 애플리케이션 매니페스트를 마스터에 게시하면 쿠버네티스는 해당 애플리케이션을 워커 노드 클러스터에 배포합니다. 구성 요소가 어떤 노드에 배포되는지는 개발자나 시스템 관리자에게 중요하지 않습니다. 따로 설정하지 않아도, 현재 가장 적은 양을 가지고 있는 노드로 자동으로 분배가 되기 때문이죠.

 

개발자는 특정 애플리케이션이 함께 실행되도록 지정할 수 있고 쿠버네티스는 여러 애플리케이션을 동일한 워커 노드에 배포합니다. 다른 애플리케이션은 클러스터에 걸쳐서 분산되지만 배포된 위치에 상관없이 동일한 방식으로 서로 통신할 수 있습니다.

---

Kubernetes 핵심 기능

1. 개발자가 애플리케이션 핵심 기능에 집중할 수 있도록 해줍니다.
   쿠버네티스는 클러스터의 운영체제로 생각할 수 있지만 애플리케이션 개발자가 특정 인프라 관련 서비스를 애플리케이션에 구현하지 않아도 됩니다. 대신 쿠버네티스에 의존해 이런 서비스를 제공하고 있습니다. 여기에는 서비스 디스커버리, 스케일링, 로드밸런싱, 자가 치유, 리더 선출 같은 것들이 포함됩니다. 따라서 애플리케이션 개발자는 애플리케이션의 실제 기능을 구현하는 데 집중할 수 있으며 애플리케이션을 인프라와 통합하는 방법을 찾는 데 시간을 낭비하지 않아도 됩니다.
   
   
2. 운영 팀이 효과적으로 리소스를 활용할 수 있도록 해줍니다.
   쿠버네티스는 클러스터 어딘가에 컨테이너화된 애플리케이션을 실행하고 구성 요소 간에 서로를 찾는 방법에관한 정보를 제공하고 모든 애플리케이션을 계속 실행하게 합니다. 애플리케이션은 어떤 노드에서 실행되든 상관이 없기 때문에 쿠버네티스는 언제든지 애플리케이션을 재배치하고 애플리케이션을 조합함으로써 리소스를 수동 스케줄링보다 훨씬 더 잘 활용할 수 있습니다.

---

여기까지 컨테이너의 전후를 알아보았고, 간단하게(?) 도커와 쿠버네티스에 대해서도 알아보았습니다. 이제 도커 실습과 명령어 정리, 쿠버네티스의 더 깊은 이론과 기능들은 각각 카테고리에서 다룰 예정입니다.

 

근 1달 조금 넘는 기간동안 에티버스 러닝에서 하이브리드 클라우드 교육을 받으면서 "내가 정말 클라우드를 할 수 있을까?" 싶은 생각이 정말 많이 들었습니다. 어렵기도 어렵거니와 각 배운 내용이 어디에 사용되는지 또, 이제야 클라우드의 테두리에 발을 디뎠기 때문에 저번주까지만 해도 클라우드가 감조차 오지 않았었죠.

 

그런데 이번주부터 배우는 컨테이너 시스템부터 뭔가 클라우드의 테두리가 그려지는 느낌입니다. 뭔가 가슴속 응어리가 조금씩 풀어지는 듯한 느낌이라 기분이 좋습니다. 뭐든 꾸준히 하면 점차 빛을 본다는 게 완전히 틀린 말은 아닌가 봅니다.

 

블로그를 계속 작성하고 있지만 애드센스가 떨어져 변화를 주고 있는데, 이번 컨테이너 시리즈 제목이 굉장히 만족스럽습니다. 포스팅 200개에 다달아가며 이 작명 센스도 늘어나나 봅니다. 이것을 읽는 독자분들은 어떤지 잘 모르겠지만요. 이번주는 전환점이 되는 포인트인 듯한 느낌입니다. 이번 마무리도 역시 모든 독자분들, IT 업계 종사자들 모두 화이팅입니다. 감사합니다.

 

p.s 최근 알아야할 정보의 양이 늘어나며 실습이 아닌 이론 위주의 포스팅이 되고 있습니다. 이 부분은 정말 죄송하게 생각하고 있고, 학습이 마무리되고 프로젝트로 넘어가면 실습 위주 포스팅이 가능할 듯합니다. 더 양질의 정보를 제공할 수 있도록 노력하겠습니다. 다시 한번 감사합니다.