분산형 Kubernetes PaaS를 위한 컨트롤 플레인

Ankur Singla

이 글은 당사의 SaaS 서비스를 구축하고 운영하기까지의 다양한 측면을 다루는 블로그 시리즈의 첫 번째 글입니다:

1. 분산형 Kubernetes PaaS를 위한 컨트롤 플레인
2. 분산 애플리케이션을 위한 글로벌 서비스 메시
3. 분산 인프라, 애플리케이션 및 데이터를 위한 플랫폼 보안
4. 분산 클러스터의 애플리케이션 및 네트워크 보안
5. 전 세계에 분산된 플랫폼 전반의 관측 가능성
6. 전 세계에 분산된 플랫폼의 운영 및 SRE
7. 분산 마이크로서비스를 위한 Golang 서비스 프레임워크

앞서 블로그에서 설명했듯이, 고객들은 스마트 제조, 공공 안전을 위한 비디오 포렌식, 알고리즘 트레이딩, 통신사의 5G 네트워크 등 복잡하고 다양한 비즈니스 솔루션을 구축하고 있습니다. 따라서 당사는 이러한 애플리케이션과 최종 사용자에게 상시 가동되고 연결성과 안정성이 보장되는 경험을 제공해야 합니다.

이러한 애플리케이션은 여러 클라우드 제공업체 또는 고객의 엣지 위치에 있는 여러 클러스터에서 실행될 수 있으므로, 플랫폼 팀은 여러 멀티테넌트 Kubernetes 클러스터를 배포하고 보호하며 운영하기 위한 분산형 컨트롤 플레인과 PaaS 서비스를 구축해야 했습니다. 이 분산형 컨트롤 플레인은 운영, 확장성 및 성능 측면에서 많은 이점을 제공했으며, 이에 대해서는 발표(동영상 링크)에서 다룰 예정입니다. 예를 들어 GitOps로 수천 개의 엣지 K8s 클러스터를 관리하는 방법을 소개하며, 향후 몇 주 내에 별도의 블로그 게시물로도 다룰 예정입니다.

요약

• 클라우드 제공업체, 프라이빗 클라우드 또는 여러 엣지 위치에 분산된 다수의 애플리케이션 클러스터를 배포하고 보호하며 운영하는 문제를 해결할 수 있으면서도 사용하기 쉬운 솔루션을 시장에서 찾을 수 없었습니다.
  
• 분산 클러스터에 필요한 포괄적인 보안 및 운영 서비스(예: PKI 기반 ID, RBAC 및 사용자 액세스 관리, 클라우드 제공업체 전반의 시크릿 및 키 관리, 멀티 클러스터 서비스 메시, 관측 가능성 및 감사 로그, 애플리케이션 및 네트워크 보안)를 제공하는 강력한 Kubernetes 배포판이나 PaaS(예: OpenShift, Cloud Foundry 등)를 찾을 수 없었습니다.
  
• Anthos(Google), Azure Arc(Microsoft), Rancher는 멀티 클러스터 관리 플랫폼이자 여러 서비스를 하나로 패키징한 솔루션입니다. 하지만 분석 결과, 이러한 솔루션으로는 여러 클러스터에 걸친 애플리케이션 및 인프라 서비스에 필요한 운영, 확장성, 보안, 멀티테넌시 요구 사항을 충족할 수 없었을 것으로 판단했습니다.
  
• Kubernetes를 기반으로 구축된 관리형 PaaS를 위해 자체 분산 제어 플레인을 구축해야 했습니다. 기본 Kubernetes로 시작한 후 DevOps 및 SRE 팀에 필요한 플랫폼 서비스를 제공하기 위해 대대적인 변경을 적용했습니다. 또한 수많은 분산 클러스터를 관리하고 이기종 인프라(엣지, 자체 네트워크 및 여러 클라우드 제공업체)에 걸쳐 멀티테넌시를 제공하기 위한 제어 플레인을 구축해야 했습니다.

애플리케이션 관리를 위한 Kubernetes: 도입 이유와 방법

Kubernetes(K8s)는 지나치게 규범적이지 않으면서도 풍부한 기능을 제공해 고객에게 중요하다고 생각하는 부분을 유연하게 혁신할 수 있으므로, 분산 애플리케이션 관리 플랫폼의 핵심으로 채택했습니다. 이를 기반으로 서비스를 구축하기 시작했으며, K8s의 인기가 높아지면서 이에 익숙한 개발자와 운영자를 찾기도 더 쉬워졌습니다.

하지만 하이브리드 환경(여러 클라우드, 네트워크 POP 및 엣지 위치) 전반에 걸쳐 프로덕션급 Kubernetes 클러스터를 대규모로 배포하고 관리하는 일은 쉽지 않습니다. Kubernetes에는 다음과 같은 기능을 즉시 제공하는 솔루션이 없기 때문입니다:

1. 자동화된 클러스터링, 확장 및 무인 프로비저닝을 통해 이기종 인프라 리소스를 통합 관리합니다. 특히 엣지와 네트워크 PoP에서는 이 작업이 매우 까다로웠습니다.
2. 서로 다른 위치 간에 고성능의 안정적인 연결을 제공합니다. 특히 클라우드 제공업체 간을 연결하거나 엣지 위치에서 접속할 때 유용합니다.
3. 전송 중인 데이터, 저장된 데이터, 비밀 정보, 키 및 네트워크의 보안 문제를 해결합니다. 이 모든 요소는 엣지, 네트워크 및 클라우드 전반에서 작동하는 통합 PKI ID로 보호됩니다.
4. 진정한 멀티테넌시(테넌트 격리 및 보안 보장)를 제공하여 동일한 클러스터에서 내부 및 고객 요구 사항을 위한 프로덕션 및 개발 워크로드를 실행할 수 있도록 지원
5. 복잡한 로그 및 메트릭 수집 체계를 구축할 필요 없이 중앙 집중식 정책 및 의도와 연계되는 분산 클러스터 전반의 관측 가능성과 운영 기능을 제공합니다

여러 클라우드 제공업체와 GKE, AKS, EKS, RKE 같은 오픈 소스 플랫폼은 물론 OpenShift와 Cloud Foundry를 대상으로 여러 차례 개념 증명을 진행한 결과, 그 어느 것도 위의 다섯 가지 요구 사항을 모두 충족하지 못한다는 사실을 깨달았습니다. 이에 따라 기본 Kubernetes에서 시작해 ID, 네트워킹, 보안, 멀티테넌시, 로깅, 메트릭 등을 위한 여러 기능을 추가하여 자체 PaaS를 구축하기로 했습니다. 내부 요구 사항을 충족하기 위해 Kubernetes를 사용하고 있지만, 내부 사용자 및/또는 고객이 워크로드를 실행할 수 있도록 이러한 Kubernetes 클러스터를 직접 노출하지 않는 등 어려운 결정을 내려야 했습니다. 멀티테넌시는 당사의 핵심 목표였으며, 이에 대해서는 뒤에서 자세히 설명하겠습니다.

추가해야 할 여러 새로운 기능 외에도 엣지, 자체 네트워크, 퍼블릭/프라이빗 클라우드 전반의 다양한 위치에서 고객 워크로드와 함께 당사의 워크로드/서비스를 실행해야 했습니다. 이를 위해 여러 환경의 다수 클러스터를 관리할 수 있는 추가 기능을 구축해야 했습니다. 이 모든 클러스터는 당사의 글로벌 네트워크와 분산형 애플리케이션 게이트웨이를 통해 연결되어 클러스터 간 제로 트러스트 및 애플리케이션 수준의 연결성을 제공합니다.

어려운 과제: Kubernetes를 위한 멀티테넌시 및 멀티클러스터

단일 Kubernetes 클러스터에서 실행되는 애플리케이션을 구축하고 운영하는 일은 클라우드 공급자가 관리하는 클러스터를 사용하더라도 결코 간단하지 않습니다. 따라서 DevOps 및 SRE 팀은 운영 부담을 최소화하고 여러 클러스터의 복잡성을 피하려는 경우가 많습니다. 하나의 대규모 Kubernetes 클러스터를 구축하고 모든 유형의 리소스를 동일한 클러스터에 배치하는 팀도 흔히 볼 수 있습니다. 이렇게 하면 운영을 간소화하고 컴퓨팅 효율성과 비용 측면에서 클러스터를 최대한 효율적으로 운영할 수 있어 좋아 보이지만, 여러 가지 이유로 최선의 방법은 아닙니다. 우선 프로덕션 워크로드의 요구 사항은 개발·테스트 및 스테이징 환경의 요구 사항과 크게 다르며, 불안정한 개발 워크로드가 상대적으로 안정적인 프로덕션 워크로드에 문제를 일으킬 수 있습니다.

다양한 워크로드의 요구 사항 외에도 K8s의 보안 및 격리 한계는 멀티 클러스터 도입을 촉진하는 또 다른 요인입니다. K8s의 보안 및 리소스 격리 문제를 해결하는 일반적인 방법은 멀티 테넌트 모델을 사용하여 각 테넌트별로 독립적인 클러스터를 구축하는 것입니다. 클라우드에서는 이 방식이 가능할 수 있지만, 엣지에서 여러 클러스터를 실행하는 것은 불가능합니다. 엣지 사이트는 컴퓨팅 및 스토리지 리소스가 제한되어 있으며, 추가되는 각 클러스터의 로그와 메트릭을 중앙 클라우드로 전송하기 위한 네트워크 대역폭에도 제약이 있습니다.

여러 Kubernetes 클러스터로 인한 문제를 해결하기 위해, Kubernetes 클러스터를 중앙에서 관리할 수 있는 Rancher(당시에는 Anthos와 Azure Arc가 존재하지 않았음)와 KubeFed를 평가했습니다. 당시 사용할 수 있었던 접근 방식은 다음 두 가지였으며, 이는 오늘날에도 마찬가지입니다:

1. 중앙 콘솔에서 멀티 클러스터 관리(예: Rancher)를 사용했다면 어느 위치에든 여러 클러스터를 배포하고 업그레이드, 롤백 등의 수명 주기 관리 작업을 수행할 수 있었을 것입니다. 이러한 시스템 중 일부는 애플리케이션 구성 및 배포 자동화를 통해 개별 클러스터를 관리하는 기능도 제공했습니다.
   
2. 또 다른 접근 방식은 Kubernetes 클러스터 페더레이션(KubeFed) 컨트롤 플레인을 배포하여 여러 물리적 클러스터가 하나의 클러스터처럼 보이게 하는 것입니다. 저희가 검토했을 당시 이 프로젝트는 막 시작된 단계였으며, 현재도 알파 단계에 머물러 있습니다.

최근 GCP Anthos와 Azure Arc가 발표된 후, 분산형 컨트롤 플레인을 구축하기로 했던 기존 결정을 재검토했습니다. 그 결과, 이 두 가지 새로운 솔루션으로도 분산 클러스터의 두 가지 핵심 문제를 해결할 수 없었을 것이라는 결론을 내렸습니다. 당사 플랫폼에 필요했던 두 가지 핵심 기능은 다음과 같습니다:

1. 여러 클러스터를 하나의 플릿으로 관리하여 전체 클러스터 또는 논리적으로 그룹화된 클러스터 전반에서 구성, 배포, 메트릭 등의 작업을 수행할 때 발생하는 문제를 해결합니다. 이는 SRE 팀의 운영 부담을 줄이고, DevOps 팀의 디버깅 편의성을 높이며, 시스템의 확장성을 개선하는 데 매우 중요합니다.
   
2. 물리적 클러스터를 새로 구축하지 않고도 하나의 물리적 Kubernetes 클러스터를 멀티테넌시용으로 분할할 수 있는 기능 — 이는 멀티테넌시만을 위해 새로운 물리적 클러스터를 추가하고 싶지 않은 리소스 제약 환경에서 특히 중요합니다

이 두 가지 문제를 해결하기 위해, 우리는 새로운 기법인 분산형 컨트롤 플레인을 고안해야 했습니다. 이를 통해 ‘여러’ 클러스터로 인한 운영 부담을 줄이고, 리소스가 제한된 환경에서도 멀티테넌시를 위한 ‘여러 클러스터’와 동등한 환경을 제공할 수 있습니다.

분산형 컨트롤 플레인: 멀티 클러스터 Kubernetes를 구현한 방법

플랫폼 팀은 팀에서 사용할 수 있도록 Kubernetes API를 제공하는 Kubernetes용 분산 컨트롤 플레인을 구축하기로 했습니다. 다만 이러한 API는 컨트롤 플레인에만 존재하는 ‘가상’ 클러스터, 즉 가상 K8s 클러스터용 가상 K8s(vK8s) API 서버에서 제공됩니다(그림 1 참조). 이 컨트롤 플레인은 사용자의 의도를 엣지, 네트워크 POP, 퍼블릭 클라우드 위치에서 실행되는 여러 물리적 Kubernetes 클러스터에 매핑합니다. 이러한 물리적 클러스터에는 분산 컨트롤 플레인만 접근할 수 있으며, 개별 테넌트나 사용자는 접근할 수 없습니다.

그림 1: 분산 제어 플레인

이 컨트롤 플레인은 각 테넌트에 애플리케이션을 배포할 수 있는 하나 이상의 ‘가상’ 애플리케이션 클러스터를 제공합니다. 컨트롤 플레인은 구성에 따라 애플리케이션을 여러 물리적 Kubernetes 클러스터에 복제하고 관리합니다. 구성 및 배포 작업뿐만 아니라 모니터링 작업도 이 ‘가상’ 클러스터를 기준으로 수행되므로, 여러 물리적 클러스터에서 데이터를 수집하고 분석하기 위한 도구를 별도로 구축할 필요가 없습니다.

productpage라는 샘플 UI 애플리케이션을 예로 들어 보겠습니다. 사용자는 이 애플리케이션을 pa2-par, ny8-nyc, ams9-ams의 3개 위치에 분산하고, 각 위치에서 복제본 2개씩 실행하려고 합니다. 사용자가 vK8s 객체를 생성해 가상 클러스터에 연결하면 표준 kubectl로 사용할 수 있는 vK8s API 서버가 즉시 프로비저닝됩니다.

다음 단계로 사용자는 이 가상 클러스터의 kubeconfig를 다운로드하고, productpage의 K8s 배포를 정의하는 표준 yaml을 작성합니다.

배포 사양을 생성한 후 사용자는 이 가상 클러스터에 배포를 생성할 수 있습니다:

이제 사용자가 자신의 배포를 확인하면 각 위치(pa2-par, ny8-nyc, ams9-ams)에서 2개씩, 총 6개의 복제본이 시작된 것을 확인할 수 있습니다.

다음 출력은 각 위치에서 2개의 Pod가 실행 중이며 특정 물리적 노드에 매핑되어 있음을 보여줍니다.

이 간단한 예시는 설치나 관리 부담 없이 단 몇 분 만에 어떤 애플리케이션이든 여러 클러스터에 복제하는 것이 얼마나 손쉬운지 보여줍니다. 분산형 컨트롤 플레인은 의도를 매핑할 뿐만 아니라 개별 클러스터 단위가 아닌 가상 클러스터 단위의 관측 가능성도 제공합니다.

멀티테넌시를 위한 분산 제어 및 중앙 집중식 관리

그림 2에서 볼 수 있듯이, 중앙 집중식 관리 플레인은 두 퍼블릭 클라우드 공급자에 걸쳐 실행되고 있습니다(각각 한 리전씩). 하나는 AWS에, 다른 하나는 Azure에 배치되어 이중화를 제공합니다. 이 관리 플레인을 통해 SRE는 엄격한 멀티테넌시가 적용된 테넌트를 생성할 수 있습니다. 예를 들어 VoltMesh 서비스를 개발하는 팀을 하나의 테넌트로 구성하고, 고객 POC를 담당하는 고객 솔루션 팀을 별도의 사용자 집합을 보유한 독립적인 테넌트로 구성할 수 있습니다.

그림 2: 멀티테넌시 및 멀티클러스터

각 테넌트는 여러 네임스페이스를 생성하고, 사용자 그룹을 할당하여 해당 네임스페이스에서 협업하도록 할 수 있습니다. 여기서 네임스페이스는 Kubernetes 네임스페이스가 아니라, 사용자에 대한 RBAC 규칙과 IAM 정책이 적용되는 플랫폼 내 격리 경계입니다.

네임스페이스 내 사용자가 애플리케이션 클러스터를 생성하려면 vK8s 객체를 생성합니다. 그러면 이 객체가 관리 플레인에 vK8s API 서버를 생성합니다. 사용자는 이 vK8s 객체를 사용하여 디플로이먼트, 스테이트풀셋, PVC 등을 생성할 수 있으며, 컨트롤 플레인은 vK8s 객체와 연결된 사이트를 기준으로 이러한 작업이 하나 이상의 물리적 클러스터에서 수행되도록 합니다.

각 테넌트와 사용자가 표준 K8s 작업을 수정 없이 그대로 사용하므로, 이 시스템은 Spinnaker, Helm, Jenkins 등 운영자들이 널리 사용하는 여러 도구와 호환됩니다.

분산형 컨트롤 플레인을 통해 얻은 이점

분산형 컨트롤 플레인의 가장 큰 장점은 SRE 및 DevOps 팀의 운영 부담을 해소했다는 점입니다. 이제 이들 팀은 가상 클러스터 전반에서 작업(구성, 배포, 모니터링, 정책 등)을 수행할 수 있으며, 컨트롤 플레인은 이를 여러 물리적 클러스터에 자동으로 매핑합니다. 또한 컨트롤 플레인은 여러 클러스터의 운영을 간소화할 뿐만 아니라 멀티테넌시의 보안 및 격리 문제도 해결했습니다.

이 분산형 컨트롤 플레인은 플랫폼에 새로운 기능을 추가하려는 개발자의 생산성도 향상시켰습니다. 여러 클러스터의 구성이나 운영에 영향을 미치는 기능을 추가할 때마다 새로운 자동화 기능을 구축할 필요가 없기 때문입니다. 개발자는 의도 기반 구성 모델을 사용하며, 컨트롤 플레인은 수행해야 할 작업을 파악합니다. 또한 또 다른 CLI를 사용하지 않고도 kubectl을 통해 이 분산형 멀티 클러스터 객체인 가상 kubernetes와 계속 상호 작용할 수 있습니다.

이를 개발·테스트, 스테이징 및 프로덕션 환경에서 1년 넘게 운영한 결과, 네트워크 POP에서 실행되는 이 전 세계 분산형 컨트롤 플레인이 확장성, 성능 및 안정성 측면에서도 상당한 이점을 제공한다는 사실을 깨달았습니다. 이는 초기에는 미처 충분히 예상하지 못했던 부분입니다. 이 결과는 곧 있을 KubeCon 발표에서 다루고, 앞으로 몇 주 내에 별도의 블로그 게시물로도 소개할 예정입니다.

계속됩니다…

이 블로그 시리즈에서는 퍼블릭 클라우드, 자체 네트워크 PoP, 엣지 사이트에 걸쳐 수많은 애플리케이션 클러스터로 구성된 글로벌 분산형 SaaS 서비스를 구축하고 운영하기까지의 다양한 측면을 다룹니다. 다음 주제는 분산 애플리케이션을 위한 글로벌 서비스 메시입니다…

작성자 소개

Ankur Singla

Ankur Singla의 다른 블로그 게시물