GKE vs. EKS vs. AKS? Which is best for a beginner to learn? Which is most used is production environments?
GKE vs. EKS vs. AKS? 초보자가 배우기에 가장 좋은 것은 무엇입니까? 프로덕션 환경 중 가장 많이 사용되는 것은 무엇입니까?
Hi everyone, I have recently started learning kubernetes, ansible, docker, and etc around two weeks ago to become either a jr. dev ops engineer or something related to it. I have experience setting up my own local clusters with kubeadm and minikube. I also have experience setting up clusters on linode but, I would like to use one of the big three cloud providers because I know most companies are using them. I only used linode because of how cheap and easy it was to use.
안녕하세요 여러분, 저는 주니어가 되기 위해 최근 약 2주 전부터 kubernetes, ansible, docker 등을 배우기 시작했습니다. 개발 운영 엔지니어 또는 이와 관련된 것. 저는 kubeadm 및 minikube를 사용하여 자체 로컬 클러스터를 설정한 경험이 있습니다. 나는 또한 linode에 클러스터를 설정한 경험이 있지만 대부분의 회사가 이를 사용하고 있다는 것을 알고 있기 때문에 Big 3 클라우드 공급자 중 하나를 사용하고 싶습니다. 저렴하고 사용하기 쉽기 때문에 linode만 사용했습니다.
Which of them would be best for a beginner and what are the pros and cons of all three?
초보자에게 가장 적합한 것은 무엇이며, 세 가지 모두 장단점은 무엇입니까?
I use all 3. They are pretty much the same until you start bumping against some of the edges when you get deep into the ops side and each has their own quirks, especially when it comes to autoscaling. I think EKS is probably the most widely used, but it’s also my least favourite and has the most confusing concepts to deal with.
저는 3개를 모두 사용합니다. 운영 측면에 깊이 들어가고 각 가장자리에 고유한 특징이 있을 때 일부 가장자리에 부딪치기 시작할 때까지는 거의 동일합니다. 특히 자동 크기 조정과 관련하여 더욱 그렇습니다. 내 생각에 EKS는 아마도 가장 널리 사용되는 것 같지만, 내가 가장 선호하지 않는 것이기도 하고 다루기 가장 혼란스러운 개념이기도 합니다.
Can I ask what the concepts are that you find confusing? I've just started with a company that wants me to move them into EKS, and I'd love to not have to find this stuff out by myself.
당신이 혼란스러워하는 개념이 무엇인지 물어봐도 될까요? 나는 EKS로 옮기기를 원하는 회사에서 막 시작했는데, 이 물건을 혼자서 찾을 필요가 없었으면 좋겠습니다.
Both AKS and GCP are pretty straight forward when it comes to node pools and autoscaling: you create a node pool, specify the VM type and specify min/max node counts. But with EKS you need to deal with LaunchTemplates, AMIs and Auto Scaling Groups as separate concepts. For autoscaling you also need to separately deploy and configure an autoscaler and there is some special config needed as well for it to be able to scale from 0 if your pods use node selectors based on labels on the node groups.
AKS와 GCP는 모두 노드 풀 및 자동 크기 조정과 관련하여 매우 간단합니다. 즉, 노드 풀을 만들고 VM 유형을 지정하고 최소/최대 노드 수를 지정합니다. 그러나 EKS를 사용하면 LaunchTemplate, AMI 및 Auto Scaling 그룹을 별도의 개념으로 처리해야 합니다. 자동 크기 조정을 위해서는 자동 크기 조정기를 별도로 배포하고 구성해야 하며, 포드가 노드 그룹의 레이블을 기반으로 하는 노드 선택기를 사용하는 경우 0에서 크기를 조정할 수 있으려면 몇 가지 특별한 구성도 필요합니다.
Have a look at Karpenter as an autoscaler. It is quite nice and takes away a bit of the problems you are facing.
자동 크기 조정기로 Karpenter를 살펴보십시오. 그것은 매우 좋으며 당신이 직면하고 있는 문제를 약간 없애줍니다.
It does.... It is also complicated AF if you want anything more configured than basic autoscaling. But the ability to cost promise is pretty insane
그렇습니다.... 기본 자동 크기 조정보다 더 많은 구성을 원하는 경우 AF도 복잡합니다. 하지만 약속을 지키는 능력은 정말 미친 짓이야
AKS autoscaler is nice to begin with but quickly shows its limitations. I'd rather have more upfront cost but get more longterm flexibility now that I have experience with it. It's not the end of the world but we want to use it in part to ensure that things feel "snappy" by allocating resources slightly before they're needed and there are basically no levers to make that happen -- you get a new node only once you have a pod that cannot fit anywhere on any current node.
AKS 자동 크기 조정기는 처음에는 좋지만 금방 한계를 드러냅니다. 초기 비용이 더 많이 들지만 이제 경험이 있으므로 더 장기적인 유연성을 얻고 싶습니다. 세상의 종말은 아니지만 우리는 리소스가 필요하기 조금 전에 리소스를 할당하여 상황이 "빠른" 느낌을 갖도록 부분적으로 사용하고 싶습니다. 기본적으로 그렇게 할 수 있는 수단은 없습니다. 새 노드만 얻을 수 있습니다. 현재 노드 어디에도 들어갈 수 없는 포드가 있는 경우.
In the portal there are no levers, but the API (Azure CLI/Terraform/ARM) allows quite a bit of customization.
포털에는 레버가 없지만 API(Azure CLI/Terraform/ARM)를 사용하면 상당한 사용자 지정이 가능합니다.
Yep I'm familiar, none of them apply to the concern I mention
네, 잘 알고 있습니다. 그 중 어느 것도 제가 언급한 우려 사항에 적용되지 않습니다.
Could you explain what kind of levers you're looking for? Metrics-based, similar to HPA (with custom metrics) or KEDA?
어떤 종류의 레버를 찾고 있는지 설명해 주시겠어요? HPA(사용자 정의 측정항목 포함) 또는 KEDA와 유사한 측정항목 기반인가요?
I want to overprovision nodes to allow for a certain percentage of available resources at a given time, so things can scale up without needing to always wait for node provisioning
주어진 시간에 특정 비율의 사용 가능한 리소스를 허용하기 위해 노드를 초과 프로비저닝하고 싶습니다. 그러면 항상 노드 프로비저닝을 기다릴 필요 없이 확장할 수 있습니다.
Still don't understand how you wouldn't be able to do this with the current available options by just setting a low threshold.
낮은 임계값을 설정하는 것만으로는 현재 사용 가능한 옵션으로 어떻게 이를 수행할 수 없는지 여전히 이해하지 못합니다.
The current available options don't allow for what I describe. I will assume if you knew specifically of which options would provide that you would've pasted them and since you didn't include any specific recommendations that you're just saying "I feel like it should be possible" and since I have looked at all the available options and haven't found any that would directly manage what I'm after, I'm saying to the best of my knowledge it is not possible. Of course there may be some other options than those that are documented on the docs that describe the auto-scaler config options.
현재 사용 가능한 옵션은 제가 설명하는 것을 허용하지 않습니다. 어떤 옵션을 제공할지 구체적으로 알고 붙여넣었을 것이며 특정 권장 사항을 포함하지 않았으므로 "가능할 것 같다"고만 말하고 있다고 가정하겠습니다. 사용 가능한 모든 옵션이 있지만 내가 원하는 것을 직접 관리할 수 있는 옵션은 찾지 못했습니다. 제가 아는 한 그것은 불가능하다는 것입니다. 물론 자동 크기 조정기 구성 옵션을 설명하는 문서에 설명된 옵션 외에 다른 옵션이 있을 수도 있습니다.
If you want to have a node spun up ready to go. Check out my blog post on how to do this using pause pods and priority. https://pixelrobots.co.uk/2021/03/aks-how-to-over-provision-node-pools/
노드를 가동할 준비가 되기를 원하는 경우. 일시 중지 포드와 우선 순위를 사용하여 이 작업을 수행하는 방법에 대한 내 블로그 게시물을 확인하세요. https://pixelrobots.co.uk/2021/03/aks-how-to-over-provision-node-pools/
You could also look at the scale down mode of deallocate rather than delete.
삭제 대신 할당 취소의 축소 모드를 볼 수도 있습니다.
Nice!!! 멋진!!!
It’s worth mentioning that it is the most flexible. Also if you learn this one first the rest are trivial.
가장 유연하다는 점은 언급할 가치가 있습니다. 또한 이것을 먼저 배우면 나머지는 사소한 것입니다.
In what way is it more flexible than the others?
다른 것보다 어떤 면에서 더 유연합니까?
EKS tends to be more convoluted in getting a cluster actually running. Having gone from GKS in my own work to an EKS shop there are quite a few moments in just setting up a cluster where you wonder what the hell is going on and why is it so complicated? They have a couple different terraform blueprints on getting an EKS cluster stood up and they all have their advantages and disadvantages.
EKS는 클러스터를 실제로 실행하는 데 더 복잡한 경향이 있습니다. 내 작업에서 GKS에서 EKS 매장으로 이동한 후 클러스터를 설정하는 데 도대체 무슨 일이 일어나고 있고 왜 그렇게 복잡한지 궁금해하는 꽤 많은 순간이 있습니다. 그들은 EKS 클러스터를 구축하는 데 있어 몇 가지 서로 다른 테라폼 청사진을 가지고 있으며 모두 장점과 단점이 있습니다.
GKE is relatively dead simple to deploy in terraform.
GKE는 테라폼에 배포하기가 비교적 간단합니다.
EKS is a barely usable mess, mostly shoehorned in around AWS concepts. GKE is probably most beginner friendly in the sense that you get a lot of components one click away (like nginx ingress, service mesh, etc) and truly abstracts away the nitty-gritty (eg: you create your first node pool with autoscaling and various options from the start, vs EKS where creating a 'cluster' actually doesn't give you the whole thing). On EKS you have to deal with a lot of AWS concepts and your default networking is awsvpc, which limits the IPs available inside the cluster while in GKE you get an overlay by default. There's still no easy way to automate replacing awsvpc with a 3rd party overlay that gives you ipv6 inside the cluster (you need to manually create your separate launch template and replace what your autoscaling group has). ipv6 with awsvpc? AWS just recently created the relevant policy, a few months ago you had to create your own customer managed policy so that you get ipv6 with EKS (but then good luck making an ingress controller work as expected).
EKS는 거의 사용할 수 없는 엉망이며 대부분 AWS 개념에 맞춰져 있습니다. GKE는 클릭 한 번으로 많은 구성요소(예: nginx 인그레스, 서비스 메시 등)를 얻을 수 있고 핵심적인 내용을 추상화한다는 점에서 초보자에게 가장 친숙할 것입니다(예: 자동 확장 및 다양한 기능을 사용하여 첫 번째 노드 풀 생성) 처음부터 옵션을 사용하는 것과 '클러스터'를 생성하는 것이 실제로 모든 것을 제공하지 않는 EKS와 비교). EKS에서는 많은 AWS 개념을 처리해야 하며 기본 네트워킹은 awsvpc입니다. 이는 클러스터 내에서 사용 가능한 IP를 제한하는 반면 GKE에서는 기본적으로 오버레이를 얻습니다. awsvpc를 클러스터 내부에 ipv6을 제공하는 타사 오버레이로 자동 교체하는 쉬운 방법은 아직 없습니다(별도의 시작 템플릿을 수동으로 생성하고 자동 확장 그룹의 템플릿을 교체해야 함). awsvpc와 ipv6? AWS는 최근에 관련 정책을 생성했습니다. 몇 달 전에는 EKS로 ipv6을 얻을 수 있도록 자체 고객 관리형 정책을 생성해야 했습니다. 하지만 수신 컨트롤러가 예상대로 작동하게 되기를 바랍니다.
The only thing I like about EKS is that it's easy to created IAM roles for service accounts that let you access AWS resources (like SQS, RDS, etc) without custom authentication (just attach a service account to your pods and your application using aws libraries will automatically assume the IAM role of the service account)
Try this little experiment:
Go build a very basic cluster in each of the 3; compare the experience.
Now, go try to delete them.
I'll wait. ;)
I think GKE handholds you the best as a beginner, and includes the widest range of things 'out of the box' so to speak, where EKS expects you to be already familiar with managing k8s clusters and do your own detail handling for a lot of it. Makes it more flexible but also easier to muck up.
내 생각에 GKE는 초보자에게 최고를 안겨줄 것이며 말하자면 '즉시 사용 가능한' 가장 광범위한 기능을 포함합니다. 여기서 EKS는 귀하가 이미 k8s 클러스터 관리에 익숙하고 많은 세부 사항을 직접 처리할 것으로 기대합니다. 그것. 더 유연해지지만 더 쉽게 정리할 수 있습니다.
Basically how I would put it as well. The hand-holding did get annoying to me personally with GCP after a while though, since I was already pretty familiar with k8s. With EKS you have to put in more time to build out all the pieces (though they are starting to include some "add-ons" out of the box). I personally still prefer EKS due to liking AWS overall more, but GKE itself is definitely more advanced feature wise.
기본적으로 어떻게 표현할까요? 하지만 나는 이미 k8s에 꽤 익숙했기 때문에 손을 잡는 것이 잠시 후 GCP를 사용하는 나에게 개인적으로 짜증이 났습니다. EKS를 사용하면 모든 부분을 구축하는 데 더 많은 시간을 투자해야 합니다(기본적으로 일부 "추가 기능"이 포함되기 시작했지만). 저는 개인적으로 AWS를 전반적으로 더 좋아하기 때문에 여전히 EKS를 선호하지만 GKE 자체는 확실히 기능 면에서 더 고급입니다.
I have worked with "the big three". And each of them also brings with it the peculiarities of each Cloud provider. AWS is the one that maintains legacy component configurations, for example you can't put worker nodes on a Private subnet and use ELB on the public subnet for access, or your worker nodes are on the public network and you put security groups to protect it or else you use ALB, but it can only be in AWS regions that have at least 3 availability zones available at the time of configuration. I haven't experienced this with either Azure or Google Cloud, and it's a different world with AWS IAM Profiles for permissions compared to Azure AD and Google's simple account system.
나는 "빅 3"와 함께 일했습니다. 또한 각 클라우드 제공업체의 특성도 함께 제공됩니다. AWS는 레거시 구성 요소 구성을 유지하는 것입니다. 예를 들어 작업자 노드를 프라이빗 서브넷에 배치할 수 없고 액세스를 위해 퍼블릭 서브넷에서 ELB를 사용할 수 없거나 작업자 노드가 퍼블릭 네트워크에 있고 이를 보호하기 위해 보안 그룹을 배치합니다. 또는 ALB를 사용하지만 구성 시 사용 가능한 가용성 영역이 3개 이상 있는 AWS 지역에만 있을 수 있습니다. 저는 Azure나 Google Cloud에서 이런 경험을 해본 적이 없으며, Azure AD와 Google의 간단한 계정 시스템에 비해 권한에 대한 AWS IAM 프로필이 있는 것은 다른 세상입니다.
For me, the best to learn are AKS (Azure) and GKE, but the most implemented is AWS EKS (and yes, it is the one I have worked with the most).
제가 배우기에 가장 좋은 것은 AKS(Azure)와 GKE이지만 가장 많이 구현된 것은 AWS EKS입니다(네, 제가 가장 많이 작업한 것입니다).
I learned with GKE, GKE로 배웠는데,
I found google cloud platform way more approachable than AWS, also the docs were great.
Google 클라우드 플랫폼이 AWS보다 훨씬 더 접근하기 쉽다는 것을 알았고 문서도 훌륭했습니다.
You get $300 free credits and I shut down my cluster when I’m done learning.
$300의 무료 크레딧을 받고 학습이 끝나면 클러스터를 종료합니다.
EKS is most popular in the job market, with AKS close behind. GKE is awesome but nobody uses GCP relative to the other two imho.
EKS는 취업 시장에서 가장 인기가 높으며 AKS가 그 뒤를 따릅니다. GKE는 훌륭하지만 다른 두 imho에 비해 GCP를 사용하는 사람은 없습니다.
GKE is by far the best. We use GCP only at Etsy
GKE가 단연 최고입니다. 우리는 Etsy에서만 GCP를 사용합니다
Truth. GKE is by far the most polished and integrated. Workload identity just working, node pools being managed, etc.
진실. GKE는 지금까지 가장 세련되고 통합되어 있습니다. 워크로드 아이덴티티가 작동 중, 노드 풀 관리 중 등
Its great. And config connector? Amazing tooling.
훌륭해요. 그리고 구성 커넥터? 놀라운 도구.
You all hiring? Heh. 다들 채용 중이신가요? ㅎ.
Which is used in production most is loaded question. It really will depend on the cloud your organization or team uses.
프로덕션에서 가장 많이 사용되는 질문이 있습니다. 실제로 조직이나 팀이 사용하는 클라우드에 따라 달라집니다.
I do not believe EKS, GKE or AKS are actually production ready out of the box. When I think of production ready I would think of governance, policies, network configuration, IAM. Typically ask your self what do I need todo to hand over this cluster to a developer team?
나는 EKS, GKE 또는 AKS가 실제로 즉시 생산 준비가 되어 있다고 믿지 않습니다. 프로덕션 준비가 완료되면 거버넌스, 정책, 네트워크 구성, IAM이 떠오릅니다. 일반적으로 이 클러스터를 개발자 팀에 넘겨주기 위해 무엇을 해야 하는지 스스로에게 물어보세요.
Google just released GKE Enterprise which is trying to bring all the capabilities of Anthos to GKE. Anthos actually tries to tackle all the problems of making the cluster production ready. This also is heavily dependent on the size of the organization and number of teams that will be deploying.
Google은 방금 Anthos의 모든 기능을 GKE에 가져오려는 GKE Enterprise를 출시했습니다. Anthos는 실제로 클러스터 프로덕션을 준비하는 데 필요한 모든 문제를 해결하려고 노력합니다. 이는 또한 조직 규모와 배포할 팀 수에 따라 크게 달라집니다.
I don’t think you can go wrong with any of those but as you learn make sure you understand how to make these systems practical for your company to use as a platform.
나는 이들 중 어떤 것도 잘못될 수 없다고 생각하지만 배우면서 이러한 시스템을 회사에서 플랫폼으로 사용할 수 있도록 실용적으로 만드는 방법을 이해했는지 확인하십시오.
They’re all the same thing, just on different platforms. None or easier or more difficult. If you want to learn Kubernetes, build your own cluster at home on an old computer with Proxmox.
플랫폼만 다르고 모두 똑같습니다. 없음 또는 더 쉽거나 더 어렵습니다. Kubernetes를 배우고 싶다면 Proxmox를 사용하여 집에서 오래된 컴퓨터에 자신만의 클러스터를 구축하세요.
Is there a difference between proxmox and vagrant cause I currently use vagrant to setup vms in VirtualBox for my clusters.
proxmox와 vagrant 사이에 차이점이 있습니까? 현재 vagrant를 사용하여 내 클러스터의 VirtualBox에서 vms를 설정하고 있습니다.
Vagrant is meant for development, not production. Also, it's not a plateform as Proxmox. Vagrant only set up the VM while Proxmox will manage the resources shared by all VM. E.g it allows you to do overprovisionning (not that I think it's a good idea)
Vagrant는 생산용이 아닌 개발용입니다. 또한 Proxmox와 같은 플랫폼이 아닙니다. Vagrant는 VM만 설정하고 Proxmox는 모든 VM이 공유하는 리소스를 관리합니다. 예를 들어 과잉 프로비저닝을 수행할 수 있습니다(좋은 생각은 아닙니다).
One of the main reasons I recommend Proxmox for learning is because there is a Terraform provider for it as well so you can learn how to write some tf files for deploying to your own mini-cloud. It's not nearly as robust as the Azure, GCP, or AWS terraform providers, but it's a good start to get a grasp on the concepts. Then you can set up your Helm deployments into your cluster and you'll have the core skills needed for cloud devops.
제가 학습을 위해 Proxmox를 추천하는 주요 이유 중 하나는 이를 위한 Terraform 제공업체도 있어서 자신의 미니 클라우드에 배포하기 위해 일부 tf 파일을 작성하는 방법을 배울 수 있기 때문입니다. Azure, GCP 또는 AWS Terraform 공급자만큼 강력하지는 않지만 개념을 이해하기 위한 좋은 시작입니다. 그런 다음 Helm 배포를 클러스터에 설정할 수 있으며 클라우드 개발에 필요한 핵심 기술을 갖추게 됩니다.
And don’t forget you don’t pay the use of your master nodes in AKS.
그리고 AKS에서는 마스터 노드 사용에 대한 비용을 지불하지 않는다는 것을 잊지 마십시오.
EKS just added EBPF support 3 years after GKE. AKS got it in the last year. GKE is by far superior IMO.
EKS는 GKE 이후 3년 만에 EBPF 지원을 추가했습니다. AKS는 작년에 그것을 얻었습니다. GKE는 훨씬 뛰어난 IMO입니다.
It’s all the same. You’re really just comparing which cloud platform you like best. My fave is GCP/GKE.
모두 똑같습니다. 당신은 실제로 어떤 클라우드 플랫폼을 가장 좋아하는지 비교하고 있습니다. 제가 가장 좋아하는 것은 GCP/GKE입니다.
I have briefly used eks and extensively used AKS.
나는 eks를 간략하게 사용하고 AKS를 광범위하게 사용했습니다.
I really have no issues with AKS. I think it’s pretty straight forward and I think the IAM with azure is easier than aws IAM.
AKS에는 아무런 문제가 없습니다. 제 생각에는 꽤 간단하고 Azure를 사용한 IAM이 aws IAM보다 더 쉽다고 생각합니다.
I have used both GKE and EKS pretty evenly the last couple of years but if I decide myself I would pick GKE every time.
나는 지난 몇 년 동안 GKE와 EKS를 거의 균등하게 사용해왔지만 스스로 결정한다면 매번 GKE를 선택할 것입니다.
Do it yourself with gitops IAC and k3s. You will learn way more that way.
gitops IAC 및 k3s를 사용하여 직접 수행하십시오. 그렇게 하면 훨씬 더 많은 것을 배울 수 있을 것입니다.
Easiest is GKE. Most used is EKS.
가장 쉬운 것은 GKE입니다. 가장 많이 사용되는 것은 EKS입니다.
You also could try using KOPs to build up a productionish cluster in AWS, which gives you a lot of the features of AWS without having to swallow the nuance of EKS.
또한 KOP를 사용하여 AWS에서 프로덕션 클러스터를 구축해 볼 수도 있습니다. 이는 EKS의 미묘한 차이를 이해하지 않고도 AWS의 많은 기능을 제공합니다.
Learn k3s first. k3를 먼저 배우세요.
it really depends on what the client is using. You can be a super expert in AWS but if the client uses azure is not gonna matter how many badges you have in AWS for them to hire you.
실제로 클라이언트가 무엇을 사용하고 있는지에 따라 다릅니다. 귀하는 AWS의 최고 전문가가 될 수 있지만 고객이 Azure를 사용하는 경우 귀하를 고용하기 위해 AWS에 얼마나 많은 배지를 가지고 있는지는 중요하지 않습니다.
Think of those clusters more of a pepsi/coke kinda thing. They're exactly the same thing but one comes in a blue can and the other in a red can. At the end they are kubernetes on the inside.
그 클러스터를 펩시/콜라 같은 것으로 생각해보세요. 그것들은 똑같습니다. 그러나 하나는 파란색 캔에, 다른 하나는 빨간색 캔에 들어 있습니다. 결국 그들은 내부의 kubernetes입니다.