Need advice about which tool to choose?Ask the StackShare community!
Amazon EKS vs Kubernetes: What are the differences?
Introduction
This Markdown code provides a comparison between Amazon EKS (Elastic Kubernetes Service) and Kubernetes. It outlines the key differences between these two container orchestration platforms.
Compute Resources Management: In Amazon EKS, the user does not have to worry about the underlying infrastructure management as it is handled by AWS. Kubernetes, on the other hand, requires manual configuration and management of compute resources, which can be complex and time-consuming.
Cluster Management: Amazon EKS simplifies cluster management as it automatically sets up and manages the Kubernetes control plane, including updates and patches. With Kubernetes, the user is responsible for managing the control plane themselves, including upgrading and applying security patches.
Integration with AWS Services: Amazon EKS seamlessly integrates with other AWS services, allowing for easy integration and consumption of services like EC2, RDS, and VPC. Kubernetes, being a platform-agnostic solution, requires additional configuration and setup to integrate with AWS services, which can be more complex.
High Availability and Scalability: Amazon EKS provides built-in high availability, automatically distributing worker nodes across multiple availability zones to ensure fault tolerance. Kubernetes requires manual setup and configuration for achieving high availability and scalability, which can be more time-consuming and error-prone.
Managed Control Plane Updates: Amazon EKS manages the Kubernetes control plane updates, ensuring the latest security patches and functionality updates are automatically applied. Kubernetes users need to manually upgrade the control plane to benefit from new features and security patches, which can be challenging, especially for large clusters.
Pricing: Amazon EKS is a managed service, and users pay for the AWS resources they consume along with a per-hour fee for each Amazon EKS cluster. Kubernetes, being an open-source solution, is free to use, but organizations may incur costs for hardware infrastructure, maintenance, and management.
In summary, Amazon EKS offers simplified management, seamless integration with AWS services, built-in high availability, and automatic control plane updates. In contrast, Kubernetes requires more manual configuration and management, additional setup to integrate with AWS services, and manual control plane upgrades. Amazon EKS also comes at a cost as a managed service, while Kubernetes is open-source and free to use.
If you want to integrate your cluster and control end to end your pipeline with AWS tools like ECR and Code Pipeline your best option is ECS using a EC2 instance. There are pros and cons but it's easier to integrate using cloud formation templates and visual UI for approvals, etc. ECS is free, you need to pay only for the EC2 instance but unfortunately, it is not standard then you cannot use standard tools to see and manage your Kubernetes. EKS in the other hand uses standard Kubernates definitions but you need to pay for the service and also for the EC2 instance(s) you have in your cluster.
Our whole DevOps stack consists of the following tools:
- GitHub (incl. GitHub Pages/Markdown for Documentation, GettingStarted and HowTo's) for collaborative review and code management tool
- Respectively Git as revision control system
- SourceTree as Git GUI
- Visual Studio Code as IDE
- CircleCI for continuous integration (automatize development process)
- Prettier / TSLint / ESLint as code linter
- SonarQube as quality gate
- Docker as container management (incl. Docker Compose for multi-container application management)
- VirtualBox for operating system simulation tests
- Kubernetes as cluster management for docker containers
- Heroku for deploying in test environments
- nginx as web server (preferably used as facade server in production environment)
- SSLMate (using OpenSSL) for certificate management
- Amazon EC2 (incl. Amazon S3) for deploying in stage (production-like) and production environments
- PostgreSQL as preferred database system
- Redis as preferred in-memory database/store (great for caching)
The main reason we have chosen Kubernetes over Docker Swarm is related to the following artifacts:
- Key features: Easy and flexible installation, Clear dashboard, Great scaling operations, Monitoring is an integral part, Great load balancing concepts, Monitors the condition and ensures compensation in the event of failure.
- Applications: An application can be deployed using a combination of pods, deployments, and services (or micro-services).
- Functionality: Kubernetes as a complex installation and setup process, but it not as limited as Docker Swarm.
- Monitoring: It supports multiple versions of logging and monitoring when the services are deployed within the cluster (Elasticsearch/Kibana (ELK), Heapster/Grafana, Sysdig cloud integration).
- Scalability: All-in-one framework for distributed systems.
- Other Benefits: Kubernetes is backed by the Cloud Native Computing Foundation (CNCF), huge community among container orchestration tools, it is an open source and modular tool that works with any OS.
We began our hosting journey, as many do, on Heroku because they make it easy to deploy your application and automate some of the routine tasks associated with deployments, etc. However, as our team grew and our product matured, our needs have outgrown Heroku. I will dive into the history and reasons for this in a future blog post.
We decided to migrate our infrastructure to Kubernetes running on Amazon EKS. Although Google Kubernetes Engine has a slightly more mature Kubernetes offering and is more user-friendly; we decided to go with EKS because we already using other AWS services (including a previous migration from Heroku Postgres to AWS RDS). We are still in the process of moving our main website workloads to EKS, however we have successfully migrate all our staging and testing PR apps to run in a staging cluster. We developed a Slack chatops application (also running in the cluster) which automates all the common tasks of spinning up and managing a production-like cluster for a pull request. This allows our engineering team to iterate quickly and safely test code in a full production environment. Helm plays a central role when deploying our staging apps into the cluster. We use CircleCI to build docker containers for each PR push, which are then published to Amazon EC2 Container Service (ECR). An upgrade-operator
process watches the ECR repository for new containers and then uses Helm to rollout updates to the staging environments. All this happens automatically and makes it really easy for developers to get code onto servers quickly. The immutable and isolated nature of our staging environments means that we can do anything we want in that environment and quickly re-create or restore the environment to start over.
The next step in our journey is to migrate our production workloads to an EKS cluster and build out the CD workflows to get our containers promoted to that cluster after our QA testing is complete in our staging environments.
Pros of Amazon EKS
- Better control1
- Possibility to log in into the pods1
- Broad package manager using helm1
Pros of Kubernetes
- Leading docker container management solution166
- Simple and powerful129
- Open source107
- Backed by google76
- The right abstractions58
- Scale services25
- Replication controller20
- Permission managment11
- Supports autoscaling9
- Simple8
- Cheap8
- Self-healing6
- Open, powerful, stable5
- Reliable5
- No cloud platform lock-in5
- Promotes modern/good infrascture practice5
- Scalable4
- Quick cloud setup4
- Custom and extensibility3
- Captain of Container Ship3
- Cloud Agnostic3
- Backed by Red Hat3
- Runs on azure3
- A self healing environment with rich metadata3
- Everything of CaaS2
- Gke2
- Golang2
- Easy setup2
- Expandable2
- Sfg2
Sign up to add or upvote prosMake informed product decisions
Cons of Amazon EKS
Cons of Kubernetes
- Steep learning curve16
- Poor workflow for development15
- Orchestrates only infrastructure8
- High resource requirements for on-prem clusters4
- Too heavy for simple systems2
- Additional vendor lock-in (Docker)1
- More moving parts to secure1
- Additional Technology Overhead1