K8s/Kubernetes: AWS 대 GCP 대 Azure

게시 됨: 2022-03-11

Kubernetes(종종 “K8s”로 양식화됨)는 몇 년 전 컨테이너 오케스트레이션 도구의 싸움에서 승리했습니다. 그럼에도 불구하고 오늘날에도 Kubernetes를 구현하고 다양한 인프라 및 많은 도구와 함께 작동하도록 하는 방법이 여전히 많이 있습니다. 일부는 다른 것보다 더 잘 유지 관리됩니다. 하지만 그 측면에서 가장 흥미로운 개발은 최고의 클라우드 제공업체가 자체적으로 관리되는 Kubernetes 버전을 출시하기로 결정했다는 것입니다.

  • Microsoft Azure는 AKS(Azure Kubernetes Service)를 제공합니다.
  • AWS는 Amazon Elastic Kubernetes Service(EKS)를 제공합니다.
  • Google Cloud는 Google Kubernetes Engine(GKE)을 제공합니다.

DevOps 관점에서 이러한 플랫폼은 무엇을 제공합니까? 그들은 약속을 지키고 있습니까? 생성 시간과 다른 벤치마크를 어떻게 비교합니까? 각 플랫폼, 특히 CLI 도구와 얼마나 잘 통합됩니까? 그들과 함께 유지하고 일하는 것은 어떤가요? 아래에서 이러한 질문 등을 자세히 살펴보겠습니다.

참고: 읽기 전에 Kubernetes 클러스터의 개념을 설명하고 싶은 독자를 위해 Dmitriy Kononov가 훌륭한 소개를 제공합니다.

AKS 대 EKS 대 GKE: 광고 기능

각 관리형 Kubernetes 버전에 사용할 수 있는 다양한 기능을 사일로로 그룹화하기로 결정했습니다.

  • 글로벌 개요
  • 네트워킹
  • 확장성 및 성능
  • 보안 및 모니터링
  • 생태계
  • 가격

참고: 이러한 세부 정보는 클라우드 공급자가 정기적으로 제품을 업데이트함에 따라 시간이 지나면서 변경될 수 있습니다.

글로벌 개요

서비스 측면 AKS EKS GKE
출시 연도 2017년 2018년 2014년
최신 버전 1.15.11(기본값) - 1.18.2(미리 보기) 1.16.8(기본값) 1.14.10(기본값) - 1.16.9
특정 구성 요소 oms 에이전트, 터널 프론트 AWS 노드 fluentd, fluentd-gcp-scaler, 이벤트 내보내기, l7-default-backend
Kubernetes 제어 평면 업그레이드 수동 수동 자동(기본값) 또는 수동
작업자 업그레이드 수동 예(관리 노드 그룹으로 용이함) 예: 자동 및 수동, 미세 조정 가능
SLA 가용 영역이 있는 경우 99.95%, 없는 경우 99.9% EKS(마스터)의 경우 99.9%, EC2(노드)의 경우 99.99% 지역 내 99.95%, 영역 내 99.5%
네이티브 네이티브 지원 아니요 아니요 아니요(하지만 기본 Istio 설치)
Kubernetes 제어 평면 가격 무료 $0.10/시간 $0.10/시간

Kubernetes 자체가 Google의 프로젝트였기 때문에 2014년에 호스팅 버전을 최초로 제안한 것은 당연합니다.

여기에서 비교되는 세 가지 중 Azure는 AKS 다음이었고 개선할 시간이 있었습니다. 몇 년 전에 Azure에서 Kubernetes를 프로비저닝하는 데 사용되었던 acs-engine을 기억한다면 교체에 대한 Microsoft의 노력에 감사할 것입니다. 아크-엔진.

AWS는 자체 버전인 EKS를 마지막으로 출시했기 때문에 때때로 기능면에서 뒤쳐져 있는 것처럼 보일 수 있지만 따라잡고 있습니다.

물론 가격 면에서 상황은 항상 변하고 있으며 Google은 2020년 6월부터 시간당 $0.10의 가격으로 AWS에 합류하기로 결정했습니다. Azure는 AKS 서비스를 무료로 제공하는 외부인이지만 어떻게 오래 지속될 수 있습니다.

또 다른 주요 차이점은 클러스터의 업그레이드 기능에 있습니다. 가장 자동화된 업그레이드는 GKE에 있으며 기본적으로 켜져 있습니다. 그러나 AKS와 EKS는 모두 마스터 또는 작업자 노드를 업그레이드할 수 있으려면 수동 요청이 필요하다는 점에서 서로 비슷합니다.

네트워킹

서비스 측면 AKS EKS GKE
네트워크 정책 예: Azure 네트워크 정책 또는 Calico Calico를 설치해야 합니다. 예: Calico를 통해 네이티브
로드 밸런싱 기본 또는 표준 SKU 로드 밸런서 클래식 및 네트워크 로드 밸런서 컨테이너 네이티브 로드 밸런서
서비스 메시 기본 제공되는 항목 없음 AWS App Mesh(Envoy 기반) Istio(즉시 사용 가능하지만 베타 버전)
DNS 지원 CoreDNS 사용자 지정 VPC 내부의 CoreDNS + Route53 CoreDNS + 구글 클라우드 DNS

네트워크 측면에서 세 클라우드 공급자는 서로 매우 가깝습니다. 예를 들어 고객은 모두 Calico로 네트워크 정책을 구현할 수 있습니다. 로드 밸런싱과 관련하여 모두 자체 로드 밸런서 리소스와의 통합을 구현하고 엔지니어에게 사용할 항목을 선택할 수 있도록 합니다.

여기서 발견된 주요 차이점은 서비스 메시의 부가가치를 기반으로 합니다. AKS는 기본적으로 서비스 메시를 지원하지 않습니다(엔지니어가 Istio를 수동으로 설치할 수 있음). AWS는 App Mesh라는 자체 서비스 메시를 개발했습니다. 마지막으로 Google은 고객이 클러스터를 생성할 때 직접 추가할 수 있는 Istio(아직 베타 버전임)와의 자체 통합을 출시했습니다.

최선의 선택: GKE

확장성 및 성능

서비스 측면 AKS EKS GKE
베어메탈 노드 아니요 네 아니요
클러스터당 최대 노드 1,000 1,000 5,000
고가용성 클러스터 아니요 제어 계획의 경우 예, 작업자의 경우 AZ 전체에서 수동 예, 지역 클러스터를 통해 마스터와 작업자가 복제됩니다.
오토 스케일링 예, 클러스터 자동 확장 처리를 통해 예, 클러스터 자동 확장 처리를 통해 예, 클러스터 자동 확장 처리를 통해
수직형 포드 자동 확장 처리 아니요 네 네
노드 풀 네 네 네
GPU 노드 네 네 네
온프레미스 Azure ARC(베타)를 통해 사용 가능 아니요 Anthos GKE를 통한 GKE On-Prem

GKE 대 AKS 대 EKS 성능 및 확장성과 관련하여 GKE가 앞서 있는 것 같습니다. 실제로 가장 많은 수의 노드(5,000개)를 지원하고 클러스터를 적절하게 확장하는 방법에 대한 광범위한 문서를 제공합니다. 고가용성을 위한 모든 기능을 사용할 수 있으며 미세 조정이 쉽습니다. 또한 GKE는 최근 GKE 및 그 기능을 중심으로 생태계를 구축하기 위한 프로젝트인 Anthos를 출시했습니다. Anthos를 사용하면 GKE On-Prem을 배포할 수 있습니다.

하지만 AWS에는 베어메탈 노드가 Kubernetes 클러스터를 실행할 수 있는 유일한 이점이 있습니다.

2020년 6월 현재 AKS는 마스터에 대한 고가용성이 부족하며 이는 고려해야 할 중요한 측면입니다. 하지만 언제나 그렇듯이 곧 바뀔 수 있습니다.

최선의 선택: GKE

보안 및 모니터링

서비스 측면 AKS EKS GKE
앱 비밀 암호화 아니요 예, AWS KMS를 통해 가능 예, Cloud KMS를 통해 가능
규정 준수 HIPAA, SOC, ISO, PCI DSS HIPAA, SOC, ISO, PCI DSS HIPAA, SOC, ISO, PCI DSS
RBAC 네 예, IAM과의 강력한 통합 네
모니터링 Azure Monitor 컨테이너 상태 기능 Cloudwatch에 연결된 Kubernetes 제어 평면 모니터링, 노드에 대한 Container Insights 메트릭 Kubernetes Engine 모니터링 및 Prometheus와의 통합

규정 준수 측면에서 세 클라우드 공급자는 모두 동일합니다. 그러나 보안 측면에서 EKS 및 GKE는 내장된 키 관리 서비스를 통해 또 다른 보안 계층을 제공합니다.

모니터링과 관련하여 Azure와 Google Cloud는 Kubernetes를 중심으로 자체 모니터링 생태계를 제공합니다. 특히 Kubernetes용으로 설계된 Kubernetes Engine Monitoring을 사용하도록 Google이 최근 업데이트되었다는 점은 주목할 가치가 있습니다.

Azure는 원래 Kubernetes가 아닌 기본 컨테이너 에코시스템을 위해 만들어진 자체 컨테이너 모니터링 시스템을 제공합니다. 2020년 6월 현재 미리보기 모드에서 일부 Kubernetes 관련 메트릭 및 리소스(클러스터 상태, 배포)에 대한 모니터링을 추가했습니다.

AWS는 Cloudwatch에서 직접 제어 플레인에 대한 경량 모니터링을 제공합니다. 작업자를 모니터링하려면 클러스터에 설치할 수 있는 특정 CloudWatch 에이전트를 통해 제공되는 Kubernetes Container Insights 메트릭을 사용할 수 있습니다.

최선의 선택: GKE

생태계

서비스 측면 AKS EKS GKE
시장 Azure Marketplace(그러나 명확한 AKS 통합은 없음) AWS Marketplace(250개 이상의 앱) Google 마켓플레이스(90개 이상의 앱)
코드로서의 인프라(IaC) 지원 테라폼 모듈
앤서블 모듈		 테라폼 모듈
앤서블 모듈		 테라폼 모듈
앤서블 모듈
선적 서류 비치 약하지만 완전하고 강력한 커뮤니티(2,000개 이상의 스택 오버플로 게시물) 완전하지는 않지만 강력한 커뮤니티(1,500개 이상의 스택 오버플로 게시물) 광범위한 공식 문서 및 매우 강력한 커뮤니티(4,000개 이상의 스택 오버플로 게시물)
CLI 지원 완벽한 전체 및 별도의 특수 도구 eksctl (아래에서 설명) 완벽한

생태계 측면에서 세 공급자는 서로 다른 강점과 자산을 가지고 있습니다. AKS는 이제 플랫폼에 대한 매우 완전한 문서를 보유하고 있으며 스택 오버플로에 대한 게시물 측면에서 두 번째입니다. EKS는 Stack Overflow에서 게시물 수가 가장 적지만 AWS Marketplace의 장점을 활용합니다. 가장 오래된 플랫폼인 GKE는 Stack Overflow에서 가장 많은 게시물을 보유하고 있으며 시장에서 상당한 수의 앱을 보유하고 있을 뿐만 아니라 가장 포괄적인 문서도 보유하고 있습니다.

최선의 선택: GKE 및 EKS

가격

서비스 측면 AKS EKS GKE
무료 사용 한도 $170 상당 프리 티어를 사용할 수 없음 $300 상당
Kubernetes 제어 평면 비용 무료 $0.10/시간 $0.10/시간(2020년 6월)
할인된 가격(스팟 인스턴스/선점형 노드) 네 네 네
한 달 동안의 예시 가격 $342
3 D2 노드		 $300
3 t3.large 노드		 $190
3개의 n1-standard-2 노드

전반적인 가격과 관련하여 GKE가 모든 클러스터에 대해 $0.10/시간 가격대를 구현하려는 움직임에도 불구하고 여전히 가장 저렴한 클라우드입니다. 이는 Google의 고유한 기능인 지속 사용 할인 덕분에 온디맨드 리소스의 월별 사용량이 특정 최소값을 충족할 때마다 적용됩니다.

예시 가격 행은 클라우드 제공자가 청구할 수 있는 Kubernetes 클러스터에 대한 트래픽을 고려하지 않는다는 점에 유의하는 것이 중요합니다.

AWS가 프리 티어를 사용하여 EKS 클러스터를 테스트하는 것을 허용하지 않는 이유는 EKS에 tX.micro 티어보다 더 큰 머신이 필요하고 EKS 시간당 요금이 프리 티어에 없기 때문입니다.

그럼에도 불구하고 각 클라우드 제공업체의 스팟/선점형 노드를 사용하여 적절한 부하로 이러한 관리형 Kubernetes 옵션을 테스트하는 것이 여전히 경제적일 수 있습니다. 이러한 전략은 최종 가격에서 80~90%를 쉽게 절약할 수 있습니다. (물론 그러한 머신에서 상태 저장 프로덕션 로드를 실행하는 것은 권장하지 않습니다!)

광고 기능 및 Google의 장점

온라인에서 광고되는 다양한 기능을 살펴보면 관리되는 Kubernetes 버전이 출시된 기간과 기능의 수 사이에 상관 관계가 있는 것으로 보입니다. 언급한 바와 같이 Google이 Kubernetes 프로젝트의 개시자라는 점은 부인할 수 없는 이점인 것 같습니다. 결과적으로 자체 클라우드 플랫폼과의 통합이 더욱 강력해지고 향상되었습니다.

그러나 AKS와 EKS는 성숙함에 따라 과소평가되어서는 안 됩니다. 둘 다 고유한 기능을 활용할 수 있습니다. 예를 들어, AWS는 베어메탈 노드 통합을 보유한 유일한 기업이며 시장에서 가장 많은 수의 애플리케이션을 자랑합니다.

이제 각 Kubernetes 제품에 대해 광고된 기능이 명확해졌으므로 몇 가지 실습 테스트를 통해 더 자세히 살펴보겠습니다.

Kubernetes: 실제로 AWS 대 GCP 대 Azure

광고는 한 가지이지만 프로덕션 로드를 제공할 때 다른 플랫폼을 어떻게 비교합니까? 클라우드 엔지니어로서 저는 코드로서의 인프라를 시행할 때 클러스터를 생성하고 중단하는 데 걸리는 시간의 중요성을 알고 있습니다. 그러나 또한 각 CLI의 가능성을 탐색하고 각 클라우드 공급자가 클러스터를 생성하는 것이 얼마나 쉬운지(또는 그렇지 않은지) 의견을 말하고 싶었습니다.

클러스터 생성 사용자 경험

AKS

AKS에서 클러스터 생성은 AWS에서 인스턴스 생성과 유사합니다. AKS 메뉴를 찾아 다양한 메뉴를 차례로 살펴보세요. 구성이 검증되면 2단계 프로세스로 클러스터를 생성할 수 있습니다. 매우 간단하며 엔지니어는 기본 설정으로 클러스터를 쉽고 빠르게 시작할 수 있습니다.

EKS

클러스터 생성은 EKS와 AKS에서 확실히 더 복잡합니다. 우선 기본적으로 AWS는 Kubernetes 제어 평면에 대한 새 역할을 생성하고 여기에 엔지니어를 할당하기 위해 먼저 IAM으로 이동해야 합니다. 또한 이 클러스터 생성에는 노드 생성이 포함되지 않기 때문에 평균 11분을 측정했을 때 마스터 생성에만 해당된다는 점에 유의해야 합니다. 노드 그룹 생성은 관리자를 위한 또 다른 단계이며 IAM 제어판을 통해 세 가지 필수 정책이 있는 작업자의 역할이 다시 필요합니다.

GKE

제게는 수동으로 클러스터를 생성하는 경험이 GKE에서 가장 즐겁습니다. Google Cloud Console에서 Kubernetes Engine을 찾은 후 클릭하여 클러스터를 만듭니다. 다양한 카테고리의 설정이 왼쪽 메뉴에 나타납니다. Google은 쉽게 수정할 수 있는 기본 노드 풀로 새 클러스터를 미리 채웁니다. 마지막으로 GKE는 클러스터 생성 시간이 가장 빠르기 때문에 다음 표로 넘어갑니다.

클러스터 생성 시간

서비스 측면 AKS EKS GKE
크기 노드 3개(Ds2-v2), 각각 vCPU 2개, 7GB RAM 포함 3노드 t3.large 3노드 n1-standard-2
시간(분:초) 전체 클러스터의 경우 평균 5:45 마스터의 경우 11:06에 노드 그룹의 경우 2:40(전체 클러스터의 경우 총 13:46) 전체 클러스터의 경우 평균 2:42

이 차이가 산란 시간에 미칠 수 있는 영향을 제거하기 위해 동일한 지역(AKS의 경우 프랑크푸르트 및 서유럽)에서 이러한 테스트를 수행했습니다. 또한 클러스터의 노드에 대해 동일한 크기를 선택하려고 시도했습니다. 각 노드에는 2개의 vCPU와 7~8GB의 메모리가 있으며 Kubernetes에서 작은 부하를 실행하고 실험을 시작하기 위한 표준 크기입니다. 평균을 계산하기 위해 각 클러스터를 세 번 생성했습니다.

이 테스트에서 GKE는 항상 3분 미만의 생성 시간으로 앞서 있었습니다.

Kubernetes: AWS 대 GCP 대 Azure CLI 개요

모든 CLI가 동일하게 생성되는 것은 아니지만 이 경우 세 개의 CLI는 모두 실제로 더 큰 CLI의 모듈입니다. 각 클라우드 제공업체의 CLI 도구 체인을 시작하고 실행하는 것은 어떻습니까?

AKS CLI( az 를 통해)

az 도구를 설치한 다음 AKS 모듈( az aks install-cli 를 통해)을 설치한 후 엔지니어는 프로젝트의 Azure 계정과 통신하도록 CLI에 권한을 부여해야 합니다. 이것은 간단한 az aks get-credentials --resource-group myResourceGroup --name myAKSCluster 를 통해 로컬 kubeconfig 파일을 업데이트하기 위한 자격 증명을 얻는 문제입니다.

마찬가지로 클러스터를 만들려면: az aks create --resource-group myResourceGroup --name myAKSCluster

EKS CLI( aws 또는 eksctl 을 통해)

AWS에서는 다른 접근 방식을 찾았습니다. EKS 클러스터를 관리하기 위한 두 가지 공식 CLI 도구가 있습니다. 언제나처럼 aws 는 AWS 리소스, 특히 클러스터에 연결할 수 있습니다. aws eks update-kubeconfig --name cluster-test 를 통해 자격 증명을 로컬 kubeconfig로 가져올 수 있습니다.

그러나 엔지니어는 eksctl 에서 개발하고 Go로 작성된 eksctl을 사용하여 EKS 클러스터를 쉽게 만들고 관리할 수도 있습니다. 클라우드 엔지니어에게 EKS가 제공하는 주요 이점은 CloudFormation과 함께 작동하기 때문에 YAML 구성 파일과 결합하여 코드로서의 인프라(IaC)를 생성할 수 있다는 것입니다. EKS 클러스터를 AWS의 더 큰 인프라에 통합할 때 확실히 고려해야 할 자산입니다.

eksctl 을 통해 클러스터를 생성하는 것은 eksctl create cluster 만큼 쉽습니다. 다른 매개변수는 필요하지 않습니다.

GKE CLI( gcloud 를 통해)

GKE의 경우 단계는 매우 유사합니다. gcloud 를 설치한 다음 gcloud init 를 통해 인증합니다. 거기에서 가능성: 엔지니어는 클러스터를 생성, 삭제, 설명, 자격 증명 얻기, 크기 조정, 업데이트 또는 업그레이드하거나 클러스터를 나열할 수 있습니다.

gcloud 로 클러스터를 만드는 구문은 간단합니다. gcloud container clusters create myGCloudCluster --num-nodes=1

AKS 대 EKS 대 GKE: 테스트 드라이브 결과

실제로 GKE는 콘솔 단순성과 클러스터 생성 시간 모두에서 기본 클러스터를 가동하는 데 확실히 가장 빠릅니다. UX 측면에서 클러스터 옆에 연결 버튼이 있어 클러스터에 연결하는 것도 가장 간단합니다.

CLI 도구와 관련하여 세 클라우드 공급자는 유사한 기능을 구현했습니다. 그러나 Weaveworks for EKS에서 제공하는 추가 도구에 스트레스를 줄 수 있습니다. eksctl 은 다른 서비스를 EKS와 결합하여 기존 AWS 인프라 위에 코드로서의 인프라를 구현하기 위한 완벽한 도구입니다.

관리형 Kubernetes 제품이 앞서가다: AWS 대 GCP 대 Azure

Kubernetes의 세계를 막 시작하는 사람들에게 가장 간단하기 때문에 가장 적합한 구현은 GKE입니다. 설정하기 쉽고, 생성을 위한 간단하고 빠른 UX가 있으며, Google Cloud Platform 생태계에 잘 통합되어 있습니다.

AWS가 경쟁에 마지막으로 참가했지만 베어메탈 노드와 가장 큰 마음 점유율을 가진 공급자와 통합된다는 단순한 사실과 같은 몇 가지 부인할 수 없는 이점이 있습니다.

마지막으로 AKS는 창설 이후 큰 발전을 이루었습니다. 툴링 및 기능 패리티는 오래 걸리지 않을 것이며 혁신을 위한 프로세스의 여지를 남겨둡니다. 그리고 모든 관리형 Kubernetes 제품과 마찬가지로 이미 상위 플랫폼에 있는 제품의 경우 통합이 판매 포인트가 될 것입니다.

팀이 Kubernetes 클라우드 제공업체를 선택하면 다른 팀의 경험, 특히 실패를 살펴보는 것이 흥미로울 수 있습니다. 이러한 사후 분석은 실제 사례를 반영한 ​​것입니다. 항상 자신의 최첨단 모범 사례를 개발하기 위한 좋은 출발점입니다. 아래 의견을 기다리겠습니다!

관련 항목: Kubernetes 서비스 메시 비교