분산 Kubernetes PaaS 용 제어 플레인

(Ankur Singla) (11 월 15 일 , 2019)

저자 : Ankur Singla , Harshad Nakil

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

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

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

이러한 애플리케이션 이후 클라우드 제공 업체 또는 고객의 엣지 로케이션에 걸쳐 여러 클러스터에서 실행될 수 있기 때문에 플랫폼 팀은 분산 제어 플레인과 PaaS 서비스를 구축하여 여러 멀티 테넌트 Kubernetes 클러스터를 배포, 보호 및 운영해야했습니다. 이 분산 된 제어 영역은 프레젠테이션 (에서 다루게 될 많은 운영, 확장 및 성능 이점을 제공했습니다. 비디오 링크 ) — 예 GitOps를 사용하여 수천 개의 에지 K8 클러스터를 관리하는 방법 — 앞으로 몇 주 내에 별도의 블로그 게시물로 제공됩니다.

TL; DR (요약)

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

Kubernetes 앱 관리 : 왜 & 방법

다양한 기능을 제공하는 분산 애플리케이션 관리 플랫폼의 핵심으로 Kubernetes (K8)를 선택했습니다. 지나치게 규범 적이 지 않고 고객에게 중요하다고 생각되는 것을 혁신 할 수있는 유연성을 제공합니다. 우리는 이것을 서비스 구축을 시작하기위한 기초로 사용했으며 K8s의 인기가 높아지면서 이에 익숙한 개발자와 운영자를 찾기가 더 쉽습니다.

즉, 하이브리드 환경 (다중 클라우드, 네트워크 POP 및 엣지 로케이션)에서 다수의 프로덕션 등급 Kubernetes 클러스터를 배포하고 관리하는 것은 쉽지 않습니다. 다음을 수행 할 수있는 Kubernetes 용 솔루션 :

  1. 자동 클러스터링, 확장 및 제로 터치 프로비저닝으로 이기종 인프라 리소스를 조화시킵니다. 이는 엣지와 네트워크 PoP에서 특히 고통 스러웠습니다.
  2. 특히 클라우드 제공 업체를 교차하고 엣지 위치에서 들어오는 경우 서로 다른 위치에서 고성능 및 안정적인 연결을 제공합니다.
  3. 보안 해결 전송중인 데이터, 미사용 데이터, 비밀, 키 및 네트워크 문제… 모두 에지, 네트워크 및 클라우드에서 작동하는 균일 한 PKI ID로 뒷받침됩니다.
  4. 진정한 멀티 테넌시 제공 — 테넌트 격리 및 보안 보장 — 동일한 클러스터에서 내부 및 고객 요구 사항에 대한 프로덕션 및 개발 워크로드를 실행할 수있는 기능
  5. 복잡한 구축없이 중앙 집중식 정책 및 의도에 연결된 분산 클러스터 전반에 걸쳐 관찰 성과 운영을 제공합니다. 로그 및 측정 항목 수집

여러 클라우드 제공 업체와 GKE, AKS, EKS, RKE와 같은 오픈 소스 플랫폼과 OpenShift 및 Cloud Foundry와 같은 몇 가지 개념 증명을 통해 그들 중 누구도 모든 fi를 만날 수 없다는 것을 위의 ve 요구 사항. 결과적으로 우리는 “바닐라”Kubernetes로 시작하여 ID, 네트워킹, 보안, 다중 테넌시, 로깅, 메트릭 등을 위해 자체 PaaS를 구축하기로 결정했습니다. 내부 요구 사항을 충족하기 위해 Kubernetes를 사용하는 동안, 워크로드를 실행하기 위해 이러한 Kubernetes 클러스터를 내부 사용자 및 / 또는 고객에게 직접 노출하지 않는 것과 같은 몇 가지 어려운 결정을 내려야했습니다 (다중 테넌시가 우리의 핵심 목표이므로 나중에 자세히 설명합니다).

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

The 어려운 부분 : Kubernetes 용 멀티 테넌시 및 멀티 클러스터

단일 Kubernetes 클러스터에서 실행되는 애플리케이션을 구축하고 운영하는 것은 클라우드 제공 업체 관리 클러스터를 사용하더라도 사소한 작업입니다. 이것이 DevOps 및 SRE 팀이 오버 헤드를 최소화하고 많은 클러스터의 복잡성을 처리하지 않는 것이 일반적인 이유입니다. 팀이 하나의 대규모 Kubernetes 클러스터를 구축하고 모든 유형의 리소스를 동일한 클러스터에 배치하는 것은 매우 일반적입니다. 운영을 단순화하고 컴퓨팅 효율성과 비용을 극대화하기 위해 클러스터를 실행할 수 있기 때문에 이것은 훌륭해 보이지만 여러 가지 이유로 최상의 아이디어는 아닙니다. 첫째, 프로덕션 워크로드에 대한 요구는 개발 테스트 및 스테이징과 매우 다릅니다. 불안정한 개발 워크로드는 잠재적으로보다 안정적인 프로덕션 워크로드에 문제를 일으킬 수 있습니다.

다양한 워크로드, K8s 보안 및 격리 제한은 다중 클러스터의 또 다른 동인입니다. K8 보안 및 리소스 격리를 해결하기위한 일반적인 접근 방식은 다중 테넌트 모델을 사용하여 각 테넌트에 대해 독립적 인 클러스터를 스핀 업하는 것입니다. 클라우드에서는 가능할 수 있지만 에지에서는 여러 클러스터를 실행할 수 없습니다. 에지 사이트에는 컴퓨팅 및 스토리지 리소스 제한이 있으며 각 추가 클러스터에 대한 로그 및 메트릭을 중앙 클라우드로 보내기위한 제한된 네트워크 대역폭이 있습니다.

여러 Kubernetes 클러스터의 문제를 처리하기 위해 Rancher를 평가하여 중앙 집중식 관리를 수행했습니다. Kubernetes 클러스터 (시작 당시 Anthos 및 Azure Arc는 존재하지 않음) 및 KubeFed. 그 당시 사용 가능한 두 가지 접근 방식은 다음과 같습니다 (현재도 동일한 상황).

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

최근 GCP Anthos 및 Azure Arc가 발표 된 후 우리는 다음과 같은 원래 결정을 재평가했습니다. 분산 된 제어 플레인을 구축하고 결론은이 두 가지 새로운 제품으로도 분산 클러스터의 두 가지 중요한 문제를 해결할 수 없다는 것입니다.플랫폼에 필요한이 두 가지 핵심 기능은 다음과 같습니다.

  1. 전체 또는 논리적 클러스터 그룹 (구성과 같은 작업)에서 작업을 수행하는 문제를 해결하기 위해 여러 클러스터를 집합으로 관리 배포, 메트릭 등. SRE 팀의 운영 오버 헤드를 줄이고, DevOps의 디버그 기능을 개선하고, 시스템의 확장 성을 개선하기 위해 매우 중요합니다.
  2. 개별 물리적 물리적 클러스터를 가동 할 필요가없는 멀티 테넌 시용 Kubernetes 클러스터 — 이는 멀티 테넌시를 위해 새 물리적 클러스터를 추가하지 않으려는 리소스가 제한된 환경에서 특히 중요합니다.

이 두 가지 문제를 해결하기 위해 우리는 새로운 기술인 분산 제어 플레인 을 고안하여 운영 오버 헤드를 해결해야했습니다. “다중”클러스터 및 리소스 제약에서 다중 테넌시를 위해 “다중 클러스터”에 해당하는 기능 제공 d 환경.

분산 제어 플레인 : 다중 클러스터 Kubernetes를 달성 한 방법

우리 플랫폼 팀은 Kubernetes API를 제공하는 Kubernetes 용 분산 제어 플레인을 구축하기로 결정했습니다. , 이러한 API는 제어 플레인에만 존재하는 “가상”클러스터 ( 그림 1에 표시된 것처럼 가상 K8s 클러스터 용 가상 K8s (vK8s) API 서버)에서 제공됩니다. ). 이 제어 플레인은 사용자의 의도를 에지, 네트워크 POP 및 퍼블릭 클라우드 위치에서 실행되는 여러 물리적 Kubernetes 클러스터에 매핑합니다. 이러한 물리적 클러스터는 개별 테넌트 / 사용자가 아닌 분산 제어 영역에서만 액세스 할 수 있습니다.

그림 1 : 분산 제어 플레인

이 제어 플레인은 각 테넌트에 애플리케이션을 배포 할 수있는 하나 이상의 “가상”애플리케이션 클러스터를 제공합니다. ) 및 구성을 기반으로 제어 플레인은 여러 물리적 Kubernetes 클러스터에서이를 복제하고 관리합니다. 구성 및 배포 작업 외에도 모니터링 작업은 여러 물리적 클러스터에서 데이터를 수집하고 분석하는 도구를 구축 할 필요없이이 “가상”클러스터를 따릅니다.

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

다음 단계로 사용자는이 가상의 kubeconfig를 다운로드합니다. 클러스터를 생성하고 제품 페이지에 대한 K8s 배포를 설명하는 표준 yaml을 만듭니다.

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

이제 사용자가 그의 배포에 따르면 6 개의 복제본이 각 위치 (pa2-par, ny8-nyc 및 ams9-ams)에서 2 개로 시작되었습니다.

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

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

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

As 그림 2 에서 볼 수 있듯이 중앙 집중식 관리부는 두 개의 퍼블릭 클라우드 제공 업체 (각각 하나의 지역)에서 실행되고 있습니다. AWS 및 Azure에서 하나 (중복 용). 이 관리 플레인을 통해 SRE는 하드 멀티 테넌시를 사용하여 테넌트를 만들 수 있습니다. VoltMesh 서비스를 작업하는 개발 팀은 테넌트가 될 수 있으며 고객 POC를 작업하는 고객 솔루션 팀은 자체 사용자 집합이있는 자체 테넌트가 될 수 있습니다.

그림 2 : 다중 테넌시 및 다중 클러스터

이러한 각 테넌트는 네임 스페이스에 대해 공동 작업 할 사용자 그룹을 할당합니다. 이러한 네임 스페이스는 Kubernetes 네임 스페이스가 아닙니다. 이는 사용자를위한 RBAC 규칙 및 IAM 정책이있는 플랫폼의 격리 경계입니다.

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

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

분산 제어 플레인에서 실현되는 이득

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

이 분산 제어 플레인은 새로운 기능을 추가하려는 개발자의 생산성을 향상 시켰습니다. 우리 플랫폼 — 여러 클러스터의 구성이나 운영에 영향을 미치는 새로운 기능을 추가 할 때마다 새로운 자동화를 구축 할 필요가 없습니다. 그들은 의도 기반 구성 모델을 사용하고 제어 플레인은 수행해야 할 작업을 알고 있습니다. 또한 아직 다른 CLI가 아닌 kubectl을 사용하여 분산 및 다중 클러스터 객체 (가상 kubernetes)와 계속 상호 작용할 수 있습니다.

개발 테스트, 스테이징 및 프로덕션 환경에서이를 실행 한 후 더 많은 정보를 얻을 수 있습니다. 1 년이 지난 지금, 우리는 네트워크 POP에서 실행되는이 전 세계적으로 분산 된 컨트롤 플레인이 초기에 완전히 상상하지 못했던 상당한 규모, 성능 및 안정성 이점을 제공한다는 사실을 깨달았습니다. 이 결과는 향후 KubeCon 프레젠테이션과 향후 몇 주 내에 별도의 블로그 게시물로 다룰 것입니다.

계속하려면…

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