https://RustRocket.rs -- Cloud Monk Losang Jinpa, Ph.D., MCSE / MCT, https://Rustaceans.rs, Full Stack Cloud Native Rust DevOps Engineer - Rocket Framework Rust Microservices on Kubernetes-AWS-Azure-GCP

AKS vs EKS vs GKE

Return to Managed Kubernetes Services - Kubernetes as a Service (KaaS)

Updates and Upgrades

GKE provides more flexibility, supporting many Kubernetes versions – four minor versions and a total of 12 versions from 1.14 and including 1.17. It provides automated upgrades for nodes and the control plane, detects and fixes unhealthy nodes, and offers release channels that automatically test new versions.

AKS quickly updates to support the latest Kubernetes versions and also provides support for minor patches. AKS utilizes a structured approach to supported versions, encouraging customers to update old versions so they can take advantage of new Kubernetes features. It also offers automated upgrades for nodes and release channels.

EKS supports the same amount of minor versions, but only four versions are available. The main advantage of EKS is that it continues supporting version 1.15, the most commonly used Kubernetes version in production.

Both AKS and EKS require some manual work for upgrades, for example, when upgrading the Kubernetes control plane.

Auto-Scaling

Kubernetes can seamlessly scale nodes, ensuring the cluster can optimally use resources. This feature helps save time and reduce costs, automatically provisioning the appropriate amount of resources for each workload.

GKE offers a highly reliable auto scaling solution. It lets users specify the desired VM size and the required number of nodes within a node pool. Google Cloud uses these instructions to automate the process.

AKS offers auto-scaling based on the Kubernetes Cluster Autoscaler. It identifies pods that could not be scheduled to nodes, and automatically scales the number of nodes to accommodate them. Users can customize cluster scaling settings.

EKS manages auto scaling via the Kubernetes Cluster Autoscaler and the Karpenter open source autoscaling project.

Operating Systems

All three solutions support common operating systems including Windows and Linux. In addition:

GKE provides its container-optimized operating system (COS), a simplified and hardened Linux version that enables quicker container deployment and scaling.

EKS provides Bottlerocket, Amazon’s COS that can run containers rather than the standard Docker engine.

Bare Metal Clusters

A bare metal cluster is deployed on a cloud architecture without a virtualization layer (VMs). It helps reduce infrastructure overhead significantly and provides application deployments with access to more storage and computing resources. As a result, it increases the overall computing power, helping reduce downtime and latency for application requests.

Here are how the three providers handle bare metal clusters:

Google offers Google Anthos, which lets customers run managed Kubernetes clusters on local bare metal infrastructure.

Azure does not offer a managed bare metal solution.

Amazon offers EKS Anywhere, which lets customers run a local version of EKS on their own bare metal servers.

Container Image Services

Each cloud vendor offers its own container image service, integrated with its respective managed Kubernetes service:

Google shifted from a Google Container Registry service into an Artifact Registry product, focusing on supporting more image formats. The Artifact Registry service offers various features, including integrated image scanning and binary authorization to enhance security.

Azure offers the Azure Container Registry (ACR), a paid registry with features like image scanning, image signing, immutable tags, and a financially backed SLA. Azure bills this service according to daily usage rates based on the amount of required storage but does not charge customers for network bandwidth. Premium plans also offer geo-redundancy.

Amazon offers Elastic Container Registry (ECR), a paid service that includes similar features to ACR – a financially-backed SLA, image scanning, and immutable image tags. ECR is geo-redundant by default, offering cross-region and cross-account support that eliminates the need to manage redundancy across zones.

Resource Monitoring

GKE uses Stackdriver to monitor resources in Kubernetes clusters. Stackdriver monitors master and worker nodes and all Kubernetes components across the platform, including logging.

AKS lets you use Azure Monitor to assess the health of containers and provides Application Insights to help monitor Kubernetes components.

EKS does not include native resource monitoring, requiring integration with third-party tools like Prometheus.

RBAC and Network Policies

All three providers configure Kubernetes deployments with default role-based access control (RBAC), and allow you to limit network access to the Kubernetes API endpoint of your cluster.

However, RBAC and secure authentication do not protect the API server, exposing it to attacks attempting to compromise the cluster. You must apply a classless inter-domain routing allowlist or give the API an internal, private IP address to protect against compromised cluster credentials.

Beyond this, here are the key differences between the providers:

AKS

AKS - Requires enabling network policies at cluster creation time.

Provides policy management features through Azure Policy.

Integrates with Azure Active Directory (AD) for user authentication.

Supports using Kubernetes RBAC with Azure AD user identities. EKS

Uses RBAC to maintain its core Kubernetes security controls by default in all clusters. Provides a Pod Security Policy with a permissive policy by default. Requires you to install and manage upgrades for the Calico CNI on your own. Lets you manage networking via managed node groups, but this creates a security issue, because it requires all nodes in a managed node group to be able to send traffic out of the virtual private cloud (VPC) and have a public IP address. Placing the nodes on private subnets can help you mitigate this issue.

GKE

Offers network policy with firewall rules at the pod level via the Network Policy API. Supports defense-in-depth, protecting applications at several levels, including ingress traffic, east-west traffic, and inter-pod traffic.

Allows applications to host data from different users in a multi-tenancy model, with network policy rules to prevent pods and services in one namespace from accessing another.“

Fair Use Source: https://komodor.com/blog/the-2022-managed-kubernetes-showdown-gke-vs-aks-vs-eks