분산 쿠버네티스 PaaS를 위한 제어 평면

이 블로그는 SaaS 서비스를 구축하고 운영하는 데 필요한 다양한 측면을 다루는 일련의 블로그 중 첫 번째입니다.

1. 분산 Kubernetes PaaS를 위한 제어 평면
2. 분산 애플리케이션을 위한 글로벌 서비스 메시
3. 분산 인프라, 앱 및 데이터를 위한 플랫폼 보안
4. 분산 클러스터의 응용 프로그램 및 네트워크 보안
5. 전 세계적으로 분산된 플랫폼에서의 관찰 가능성
6. 전 세계적으로 분산된 플랫폼의 운영 및 SRE
7. 분산 마이크로서비스를 위한 Golang 서비스 프레임워크

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

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

TL;DR (요약)

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

앱 관리를 위한 Kubernetes: 왜 & 어떻게

우리는 분산 애플리케이션을 관리하기 위한 플랫폼의 핵심으로 Kubernetes(K8s)를 선택했습니다. Kubernetes는 지나치게 규범적이지 않으면서도 다양한 기능을 제공하기 때문에 고객에게 중요하다고 생각되는 사항을 혁신하는 데 있어 유연성을 제공합니다. 우리는 이를 기반으로 서비스를 구축하기 시작했으며 K8s의 인기가 커지면서 이에 익숙한 개발자와 운영자를 찾기도 쉬워졌습니다.

즉, 하이브리드 환경(여러 클라우드, 네트워크 POP 및 엣지 위치)에서 대량의 프로덕션 등급 Kubernetes 클러스터를 배포하고 관리하는 것은 Kubernetes에 대한 기본 제공 솔루션이 없기 때문에 그리 쉽지 않습니다.

1. 자동화된 클러스터링, 확장 및 제로터치 프로비저닝을 통해 이기종 인프라 리소스를 조화시키는 것은 특히 에지와 네트워크 PoP에서 매우 힘들었습니다.
2. 특히 클라우드 공급자를 교차하고 엣지 위치에서 오는 경우 서로 다른 위치에서 고성능 및 안정적인 연결 제공
3. 에지, 네트워크 및 클라우드 전반에서 작동하는 통일된 PKI ID로 지원되는 전송 중 데이터, 저장 중 데이터, 비밀, 키 및 네트워크의 보안 문제를 해결합니다.
4. 내부 및 고객 요구 사항에 맞게 동일한 클러스터에서 프로덕션 및 개발 워크로드를 실행할 수 있는 기능을 통해 진정한 멀티 테넌시(테넌트 격리 및 보안 보장)를 제공합니다.
5. 복잡한 로그 및 메트릭 수집을 구축할 필요 없이 중앙 정책 및 의도에 연결되는 분산 클러스터 전반의 관찰 가능성 및 운영을 제공합니다.

GKE, AKS, EKS, RKE와 같은 여러 클라우드 공급업체와 오픈소스 플랫폼, 그리고 OpenShift와 Cloud Foundry를 대상으로 여러 가지 개념 증명을 실시한 결과, 위의 5가지 요구 사항을 모두 충족하는 솔루션은 없다는 사실을 깨달았습니다. 그 결과, 우리는 "바닐라" 쿠버네티스로 시작하여 ID, 네트워킹, 보안, 다중 테넌시, 로깅, 메트릭 등을 위한 여러 가지 추가 기능을 갖춘 자체 PaaS를 구축하기로 결정했습니다. 우리는 내부적 필요를 충족하기 위해 Kubernetes를 사용하지만, Kubernetes 클러스터를 내부 사용자 및/또는 고객에게 직접 노출하여 워크로드를 실행하지 않는 것과 같은 몇 가지 어려운 결정을 내려야 했습니다(다중 테넌시가 우리의 핵심 목표였으므로 나중에 자세히 설명하겠습니다).

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

어려운 부분: 쿠버네티스를 위한 멀티 테넌시 및 멀티 클러스터

단일 Kubernetes 클러스터에서 실행되는 애플리케이션을 빌드하고 운영하는 것은 클라우드 공급자가 관리하는 클러스터를 사용하는 경우에도 간단한 작업이 아닙니다. 이것이 DevOps 및 SRE 팀이 오버헤드를 최소화하고 여러 클러스터의 복잡성을 처리하지 않는 것이 일반적인 이유입니다. 팀이 하나의 대규모 Kubernetes 클러스터를 구축하고 동일한 클러스터 내에 모든 유형의 리소스를 배치하는 것은 흔한 일입니다. 이 방법은 운영을 단순화하고 클러스터를 최대의 컴퓨팅 효율성과 비용으로 실행할 수 있으므로 좋은 방법이지만, 몇 가지 이유에서 최선의 방법은 아닙니다. 첫째, 프로덕션 워크로드에 대한 요구 사항은 개발-테스트 및 스테이징과 매우 다릅니다. 불안정한 개발 워크로드는 보다 안정적인 프로덕션 워크로드에 문제를 일으킬 가능성이 있습니다.

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

여러 개의 Kubernetes 클러스터 문제를 해결하기 위해 우리는 Kubernetes 클러스터의 중앙 관리를 위해 Rancher를 평가했고(시작했을 당시에는 Anthos와 Azure Arc가 없었습니다) KubeFed도 평가했습니다. 그 당시 사용 가능한 두 가지 접근 방식은 다음과 같았습니다(오늘날에도 상황은 동일합니다).

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

최근 GCP Anthos와 Azure Arc가 발표된 이후, 우리는 분산 제어 평면을 구축하기로 한 원래 결정을 다시 평가했고, 이 두 가지 새로운 제품조차도 분산 클러스터의 두 가지 심각한 문제를 해결할 수 없다는 결론에 도달했습니다. 우리 플랫폼에 필요한 두 가지 핵심 역량은 다음과 같습니다.

1. 모든 클러스터 또는 논리적 클러스터 그룹에서 작업 수행 문제를 해결하기 위해 여러 클러스터를 하나의 플릿으로 관리합니다. 여기에는 구성, 배포, 메트릭 등의 작업이 포함됩니다. 이는 SRE 팀의 운영 오버헤드를 줄이고 DevOps의 디버깅 기능을 개선하며 시스템의 확장성을 개선하고자 하기 때문에 중요합니다.
    
2. 물리적 클러스터를 스핀업하지 않고도 다중 테넌시를 위해 개별 물리적 Kubernetes 클러스터를 분할할 수 있는 기능 - 이는 다중 테넌시를 위해 새로운 물리적 클러스터를 추가하고 싶지 않은 리소스가 제한된 환경에서 특히 중요합니다.

이 두 가지 문제를 해결하기 위해 우리는 '다중' 클러스터의 운영 오버헤드를 해결하고 리소스가 제한된 환경에서 다중 테넌시에 대해 '다중 클러스터'와 동등한 것을 제공하기 위해 분산 제어 평면이라는 새로운 기술을 고안해야 했습니다.

분산 제어 평면: 멀티 클러스터 쿠버네티스를 달성한 방법

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

이 제어 평면은 각 테넌트에게 애플리케이션을 배포할 수 있는 하나 이상의 "가상" 애플리케이션 클러스터를 제공하며, 구성에 따라 제어 평면은 이를 여러 개의 물리적 Kubernetes 클러스터에서 복제하고 관리합니다. 구성 및 배포 작업 외에도 모니터링 작업은 여러 물리적 클러스터에서 데이터를 수집하고 분석하기 위한 툴을 빌드할 필요 없이 이 "가상" 클러스터를 따릅니다.

productpage라는 샘플 UI 애플리케이션을 살펴보겠습니다. 사용자 의도는 3개 위치(pa2-par, ny8-nyc 및 ams9-ams)에 분산하여 실행하고 각 위치에 복제본 2개를 두는 것입니다. 사용자가 vK8s 객체를 생성하여 가상 클러스터에 연결하면 표준 kubectl과 함께 사용할 수 있는 vK8s API 서버가 즉시 프로비저닝됩니다.

다음 단계로, 사용자는 이 가상 클러스터에 대한 kubeconfig를 다운로드하고 productpage에 대한 K8s 배포를 설명하는 표준 YAML을 생성합니다.

배포 사양을 만든 후 사용자는 이 가상 클러스터에 배포를 만들 수 있습니다.

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

다음 출력은 특정 물리적 노드에 매핑된 각 위치에서 실행되는 2개의 포드를 보여줍니다.

이 간단한 예제는 설치나 관리에 따른 부담 없이 몇 분 만에 모든 앱의 다중 클러스터 복제를 얻는 것이 얼마나 간단한지 보여줍니다. 의도를 매핑하는 것 외에도 분산 제어 평면은 개별 클러스터 기반이 아닌 가상 클러스터에 대한 관찰성을 제공합니다.

다중 테넌시를 위한 분산 제어 및 중앙 관리

그림 2 에서 볼 수 있듯이, 중앙 관리 평면은 두 개의 퍼블릭 클라우드 공급자(각 지역 하나)에서 실행됩니다. 하나는 AWS에 있고 다른 하나는 Azure(중복성을 위해)에 있습니다. 이 관리 플레인을 사용하면 SRE에서 하드 멀티 테넌시를 갖춘 테넌트를 생성할 수 있습니다. 예를 들어 VoltMesh 서비스에서 작업하는 개발 팀은 테넌트가 될 수 있고, 고객 POC에서 작업하는 고객 솔루션 팀은 자체 사용자 집합을 갖춘 자체 테넌트가 될 수 있습니다.

각 테넌트는 많은 네임스페이스를 만들고 이러한 네임스페이스에서 협업할 사용자 그룹을 할당할 수 있습니다. 이러한 네임스페이스는 Kubernetes 네임스페이스가 아닙니다. 이는 사용자를 위한 RBAC 규칙 및 IAM 정책이 적용된 플랫폼 내의 격리 경계입니다.

네임스페이스 내의 사용자가 애플리케이션 클러스터를 생성하려면 vK8s 객체를 생성하고, 그러면 관리 플레인에 vK8s API 서버가 생성됩니다. 이 vK8s 객체를 사용하면 사용자는 배포, 상태 저장 세트, PVC 등을 생성할 수 있으며 제어 평면은 이러한 작업이 vK8s 객체와 연결된 사이트를 기반으로 하나 이상의 물리적 클러스터에서 수행되도록 보장합니다.

각 테넌트와 사용자는 아무런 수정 없이 표준 K8s 작업을 사용하므로 시스템은 운영자에게 인기 있는 여러 도구(예: Spinnaker, Helm, Jenkins 등)와 호환될 수 있습니다.

분산 제어 평면에서 실현된 이익

분산 제어 평면의 가장 큰 장점은 SRE 및 DevOps 팀의 운영 오버헤드를 해결했다는 것입니다. 이제 가상 클러스터에서 작업(구성, 배포, 모니터링, 정책 등)을 수행할 수 있으며 제어 평면은 이를 여러 물리적 클러스터에 자동으로 매핑합니다. 여러 클러스터의 운영을 단순화하는 것 외에도 제어 평면은 다중 테넌시에 대한 보안 및 격리 문제도 해결했습니다.

이 분산 제어 평면은 또한 플랫폼에 새로운 기능을 추가하려는 개발자의 생산성을 개선했습니다. 여러 클러스터에서 구성이나 운영에 영향을 미치는 새로운 기능을 추가할 때마다 새로운 자동화를 구축할 필요가 없습니다. 그들은 의도 기반 구성 모델을 사용하고 제어 평면은 무엇을 해야 하는지 알고 있습니다. 또한 kubectl을 사용하고 다른 CLI를 사용하지 않고도 분산되고 다중 클러스터 객체(가상 Kubernetes)와 계속 상호 작용할 수 있습니다.

1년 넘게 개발 테스트, 스테이징, 프로덕션 환경에서 이를 실행해 온 결과, 네트워크 POP에서 실행되는 이 글로벌 분산 제어 평면이 상당한 규모, 성능 및 안정성 이점을 제공한다는 사실을 깨달았습니다. 이는 초기에는 완전히 상상하지 못했던 것입니다. 이 연구 결과에 대해서는 다가올 KubeCon 프레젠테이션에서 다룰 예정이며, 몇 주 안에 별도의 블로그 게시물로 게시할 예정입니다.

계속됩니다…

이 블로그 시리즈에서는 퍼블릭 클라우드, 프라이빗 네트워크 PoP, 엣지 사이트의 많은 애플리케이션 클러스터를 사용하여 전 세계적으로 분산된 SaaS 서비스를 구축하고 운영하는 데 필요한 다양한 측면을 다룰 것입니다. 다음은 분산 앱을 위한 글로벌 서비스 메시 입니다.