도커(Docker)와 쿠버네티스(Kubernetes) 기본 개념

들어가며

---

과거에는 애플리케이션을 배포할 때 다양한 환경에서 발생하는 호환성 문제를 해결하는 데 많은 노력이 필요했다. 그러나 이제는 컨테이너 기술의 도입으로 이를 표준화하고 자동화할 수 있게 되었다. 특히 소프트웨어 개발을 하다 보면 컨테이너 관리 도구와 관련한 용어를 자주 접하게 된다. 그래서 도커, 쿠버네티스 그리고 다중 클러스터에 대한 기본 개념을 정리해 봤다.

 

 

도커 (Docker)

---

 

쿠버네티스를 이해하기 위해선 먼저 도커(Docker)에 대해 알아야 한다. 2013년에 탄생한 도커는 소프트웨어 애플리케이션의 실행 환경과 소스 코드를 함께 패키징하여 하나의 컨테이너 이미지로 만드는 혁신적인 방식을 제안했다.

 

컨테이너 이미지는 그 자체가 바이너리 파일이기 때문에 바로 배포할 수 있는 장점이 있다. 즉, 다른 컴퓨터에 도커만 설치되어 있다면 해당 파일을 바로 실행할 수 있다. 소프트웨어가 "컨테이너"라는 가상 환경에서 실행되므로 실행 환경과 개발 환경을 일치시켜서 환경 설정 문제나 실행 오류를 방지한다.

 

특히 컨테이너 이미지는 표준화된 파일이어서 소프트웨어를 어떤 언어로 개발했든 최종적으로 컨테이너로 만들면 항상 동일한 형식을 갖추게 된다. 하나의 도구로 다양한 컨테이너 프로젝트를 배포할 수 있기 때문에 개발 언어의 차이를 효과적으로 극복할 수 있다.

 

이렇게 표준화되고 일원화된 소프트웨어 실행 프로세스를 제공하는 도커 덕분에 "컨테이너 애플리케이션 관리 도구"가 등장할 수 있는 기반이 마련됐다.

 

현재 도커는 소프트웨어 배포의 표준이라 할 수 있다. 소프트웨어가 소스 코드 형태로 배포되든, 컨테이너 이미지 형태로 배포되든 모두 도커 환경에서 실행될 수 있다.

 

 

마이크로서비스 아키텍처

---

이미지 출처 - Medium

도커가 등장한 이후 소프트웨어 배포가 크게 간소화되면서, 단순히 컨테이너 이미지를 실행하는 것만으로 배포가 가능해졌다. 이에 따라 개발자들은 거대한 단일 소프트웨어를 여러 독립적인 구성 요소로 분리하여 배포하는 방법을 적극적으로 활용하기 시작한다.

 

초기 기업용 대형 애플리케이션들은 다양한 기능을 포함한 거대한 단일 소프트웨어(모놀리식, Monolithic)로 구성되었다. 이러한 소프트웨어는 일부 구성 요소만 수정하더라도 전체를 다시 배포해야 하는 단점이 있었다.

 

이러한 문제를 해결하기 위해 주요 기능을 각각 독립적인 서비스로 분리하고, 각 서비스가 개별적으로 배포 및 실행될 수 있도록 설계했다. 도커 컨테이너는 이러한 마이크로서비스를 손쉽게 배포하고 관리할 수 있는 환경을 제공하여, 마이크로서비스 아키텍처의 구현을 더욱 용이하게 만들었다.

 

이처럼 단일 소프트웨어를 여러 개의 마이크로서비스로 구성된 시스템으로 전환한 것이 바로 오늘날 널리 사용되는 "마이크로서비스 아키텍처"다. 소프트웨어는 여러 개의 마이크로서비스로 구성되며, 각 마이크로서비스는 하나 이상의 도커 컨테이너로 배포될 수 있다.

 

 

컨테이너 관리 도구 쿠버네티스(Kubernetes)

---

이미지 출처 - Buddy

마이크로서비스는 매번 배포할 때마다 다수의 컨테이너를 관리해야 하기 때문에, 이를 효과적으로 다루는 것은 상당히 까다롭다. 이러한 문제를 해결하기 위해 컨테이너 관리 도구가 등장한다.

 

여러 컨테이너 관리 도구 중 쿠버네티스(Kubernetes)가 가장 유명하다. 쿠버네티스는 구글이 개발한 오픈소스 소프트웨어로, 이름의 첫 글자 K와 마지막 글자 s 사이에 8개의 문자가 있어 흔히 K8s로 줄여 쓴다. 현재 쿠버네티스는 사실상 컨테이너 관리의 표준으로 자리 잡았다.

 

쿠버네티스의 주요 기능은 다음과 같다.

1. 통일된 하드웨어 인터페이스: 개발자는 하드웨어 세부 사항을 신경 쓸 필요가 없으며, 서버 간 차이가 있더라도 이를 통일된 운영 인터페이스로 추상화하여 관리할 수 있다.
2. 자동 확장: 소프트웨어 부하 상황에 따라 수평적 확장을 자동으로 수행할 수 있다.
3. 고가용성: 특정 컨테이너가 실패할 경우, 쿠버네티스는 해당 컨테이너를 자동으로 재시작하거나 교체하여 가용한 노드로 트래픽이 흐르도록 보장한다. 또한, 소프트웨어 배포에 문제가 발생하면 자동으로 롤백할 수 있다.
4. 기타 기능: 서비스 디스커버리, 로드 밸런싱, 리소스 모니터링 등 다양한 관련 기능을 제공하며, 방대한 플러그인과 확장 기능, 그리고 활발한 커뮤니티를 갖추고 있다.

 

 

다중 클러스터란?

---

이미지 출처 - ZippyOPS

💡 기본 용어 설명

• 파드(Pod): 쿠버네티스에서 가장 작은 배포 단위. 하나 이상의 컨테이너를 포함할 수 있음. 파드는 동일한 네트워크와 스토리지를 공유하며, 논리적으로 하나의 호스트로 간주됨.
• 노드(Node): 물리적 또는 가상 머신으로, 클러스터 내에서 파드를 실행하는 역할. 노드는 파드를 호스팅 하며, 필요한 컴퓨팅 리소스(CPU, 메모리 등) 제공. 각 노드는 쿠버네티스의 컨트롤 플레인에 의해 관리되며, 여러 파드를 포함할 수 있음.
• 클러스터(Cluster): 여러 노드에 걸쳐 파드를 관리하는 역할. 클러스터는 파드의 배포, 확장, 관리를 자동화하여 컨테이너화된 애플리케이션의 안정적인 실행을 보장함.

 

쿠버네티스의 기본 구조는 여러 컨테이너가 실행되는 서버들의 집합으로 이루어져 있으며, 쿠버네티스의 각 인스턴스는 클러스터(Cluster, 集群)라고 부른다. 일반적인 소프트웨어 애플리케이션은 하나의 클러스터만으로도 충분하다. 하지만 대규모 분산 시스템이나 글로벌 서비스에서는 다중 클러스터 환경이 필요할 수 있다.

 

다중 클러스터(multi-cluster, 多集群)는 동일한 데이터센터 내에 있을 수도 있지만, 대부분 서로 다른 데이터 센터에 분산되어 있다. 특히 클러스터들이 서로 다른 클라우드 서비스 제공업체나, 성격이 다른 클라우드에서 운영되는 경우, 이를 멀티 클라우드라고 부른다.

 

다중 클러스터를 사용하는 주요 이유는 다음과 같다.

1. 재해 복구: 하나의 클러스터에 문제가 발생할 경우, 다른 클러스터가 가용성을 보장하여 시스템의 지속적인 운영을 유지할 수 있다.
2. 격리: 클러스터 간 물리적 격리가 매우 강하게 이루어져, 상위 사용자(tenant, 租户)의 격리를 보장할 수 있다.
3. 유연성: 멀티 클라우드는 공급업체 종속성을 줄이는 데 도움이 되며, 필요에 따라 가장 적합한 인프라와 서비스를 선택할 수 있다.
4. 규정 준수: 각 지역마다 상이한 규제 요구 사항이 있을 수 있으며, 다중 클러스터는 각 클러스터별로 세밀한 보안 정책과 접근 통제를 적용할 수 있도록 한다.

 

 

다중 클러스터의 도전 과제

---

다중 클러스터는 앞서 언급한 여러 장점이 있지만, 그만큼 복잡성도 증가하여 사용자에게 다양한 도전 과제를 안겨준다.

 

1. 구성 및 관리의 복잡성: 모든 클러스터는 일관된 구성과 배포를 유지해야 하며, 클러스터 간의 차이를 최소화하는 것이 중요하다.
2. 네트워크 연결 및 지연: 서로 다른 지리적 위치에 있는 클러스터 간의 안전하고 신뢰할 수 있는 연결을 보장하면서, 네트워크 지연을 최대한 줄여야 한다.
3. 서비스 디스커버리 및 로드 밸런싱: 각 클러스터에 분산된 서비스들이 서로를 어떻게 발견할 것인지, 그리고 각 클러스터 간에 효율적인 로드 밸런싱을 구현하는 방법이 필요하다.
4. 모니터링: 모든 클러스터의 지표와 로그를 중앙에서 수집하고 관리할 수 있어야 하며, 이를 통해 일관된 모니터링 시스템을 구축하는 것이 중요하다.
5. 보안 및 접근 제어: 다중 클러스터 환경에서는 보안 정책, 접근 제어, 자격 증명 관리가 더욱 복잡해지므로, 세밀한 규칙 설정과 개별적인 관리가 필요하다.

 

 

다중 클러스터 도구 및 문제점

---

앞서 언급한 도전 과제를 해결하기 위해 Argo CD, Rancher Fleet, Karmada와 같은 다중 클러스터 관리 도구가 등장한다. 이 도구들은 개발자와 쿠버네티스 사이의 중간 계층으로서, 클러스터 관리의 복잡성을 해결하는 역할을 수행한다.

 

그러나 문제는 이 도구들을 사용하려면 쿠버네티스에 대한 충분한 이해가 필요하며, 이는 상당한 학습 비용을 요구한다. 다중 클러스터 도구는 주로 애플리케이션 개발자보다는 클러스터 관리자를 대상으로 설계되어 있다.

 

실제로 다중 클러스터는 고도로 전문화된 분야이기 때문에, 다른 분야의 개발자들은 이를 이해하기 어려워한다. 개발자는 소프트웨어 개발을 완료한 후 애플리케이션을 클러스터 관리자에게 전달하고, 관리자는 이를 배포한다.

 

이 과정은 양쪽 모두에게 불편함을 초래할 수 있다.

• 개발자 입장에선 배포 전략을 결정할 수 없고, 하위 리소스를 이해하지 못한 채로 컨테이너 관리에 관여해야 하는 상황이 발생할 수 있다.
• 클러스터 관리자 입장에선 애플리케이션 레이어에 개입해야 하며, 하위 리소스 조정이 필요할 때 개발자에게 이를 알리고, 애플리케이션 운영에도 참여시켜야 한다.

 

 

애플리케이션 지향 다중 클러스터 도구

---

이와 같은 문제를 해결하기 위해 애플리케이션 개발자를 대상으로 한 TKE AppFabric 같은 도구가 등장한다. 이 도구는 앞단에서 애플리케이션을 지원하고, 뒷단에서 클러스터를 관리하는 중간 계층 역할을 수행한다. 이름에서 알 수 있듯, 애플리케이션 컨테이너들을 마치 하나의 직물처럼 엮어 효율적으로 관리한다. AppFabric의 장점은 아래와 같다.

 

1. 애플리케이션을 배포할 때, 개발자는 단순히 어떤 가용 구역에 배포할지만 지정하면 된다.
2. 애플리케이션 중심으로 작동하며, 쿠버네티스와의 결합을 최소화하여 개발자가 비즈니스에 더 집중할 수 있도록 한다.
3. 쿠버네티스의 애플리케이션 운영 기능을 통합하여 모니터링 지표와 로그 등을 하나의 대시보드에서 쉽게 확인할 수 있도록 제공한다.

 

 

레퍼런스

---

白话多集群：工具和应用助手 - 阮一峰的网络日志