**Help improve this page**
To contribute to this user guide, choose the **Edit this page on GitHub** link that is located in the right pane of every page.
# What is Amazon EKS?
**Tip**
[Register](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) for upcoming Amazon EKS workshops.
## Amazon EKS: Simplified Kubernetes Management
Amazon Elastic Kubernetes Service (EKS) provides a fully managed Kubernetes service that eliminates the complexity of operating Kubernetes clusters. With EKS, you can:
+ Deploy applications faster with less operational overhead
+ Scale seamlessly to meet changing workload demands
+ Improve security through AWS integration and automated updates
+ Choose between standard EKS or fully automated EKS Auto Mode
Amazon Elastic Kubernetes Service (Amazon EKS) is the premier platform for running [Kubernetes](https://kubernetes.io/docs/concepts/overview/) clusters, both in the Amazon Web Services (AWS) cloud and in your own data centers ([EKS Anywhere](https://anywhere.eks.amazonaws.com/) and [Amazon EKS Hybrid Nodes](hybrid-nodes-overview.md)).
Amazon EKS simplifies building, securing, and maintaining Kubernetes clusters. It can be more cost effective at providing enough resources to meet peak demand than maintaining your own data centers. Two of the main approaches to using Amazon EKS are as follows:
+ **EKS standard**: AWS manages the [Kubernetes control plane](https://kubernetes.io/docs/concepts/overview/components/#control-plane-components) when you create a cluster with EKS. Components that manage nodes, schedule workloads, integrate with the AWS cloud, and store and scale control plane information to keep your clusters up and running, are handled for you automatically.
+ **EKS Auto Mode**: Using the [EKS Auto Mode](automode.md) feature, EKS extends its control to manage [Nodes](https://kubernetes.io/docs/concepts/overview/components/#node-components) (Kubernetes data plane) as well. It simplifies Kubernetes management by automatically provisioning infrastructure, selecting optimal compute instances, dynamically scaling resources, continuously optimizing costs, patching operating systems, and integrating with AWS security services.
The following diagram illustrates how Amazon EKS integrates your Kubernetes clusters with the AWS cloud, depending on which method of cluster creation you choose:
![\[Amazon EKS standard and EKS Auto Mode\]](http://docs.aws.amazon.com/eks/latest/userguide/images/whatis.png)
Amazon EKS helps you remove friction and accelerate time to production, improve performance, availability and resiliency, and enhance system security. For more information, see [Amazon Elastic Kubernetes Service](https://aws.amazon.com/eks/).
## Building and scaling with Kubernetes: Amazon EKS Capabilities
Amazon EKS not only helps you build and manage clusters, it helps you build and scale application systems with Kubernetes. [Amazon EKS Capabilities](capabilities.md) are fully managed cluster services that extend your cluster’s functionality with hands-free Kubernetes-native tools, including:
+ **Argo CD**: Argo CD provides declarative, GitOps-based continuous deployment for your workloads, AWS resources, and cloud infrastructure.
+ ** AWS Controllers for Kubernetes (ACK)**: ACK enables Kubernetes-native creation and lifecycle management of AWS resources, unifying workload orchestration and Infrastructure-as-code workflows.
+ **kro (Kube Resource Orchestrator)**: kro extends native Kubernetes features to simplify custom resource creation, orchestration, and compositions, giving you the tools to create your own customized cloud building blocks.
EKS Capabilities are cloud resources that minimize the operational burden of installing, maintaining, and scaling these foundational platform components in your clusters, letting you focus on building software rather than cluster platform operations.
To learn more, see [EKS Capabilities](capabilities.md).
## Features of Amazon EKS
Amazon EKS provides the following high-level features:
**Management interfaces**
EKS offers multiple interfaces to provision, manage, and maintain clusters, including AWS Management Console, Amazon EKS API/SDKs, CDK, AWS CLI, eksctl CLI, AWS CloudFormation, and Terraform. For more information, see [Get started with Amazon EKS](getting-started.md) and [Amazon EKS cluster lifecycle and configuration](clusters.md).
**Access control tools**
EKS relies on both Kubernetes and AWS Identity and Access Management (AWS IAM) features to [manage access](cluster-auth.md) from users and workloads. For more information, see [Grant IAM users and roles access to Kubernetes APIs](grant-k8s-access.md) and [Grant Kubernetes workloads access to AWS using Kubernetes Service Accounts](service-accounts.md).
**Compute resources**
For [compute resources](eks-compute.md), EKS allows the full range of Amazon EC2 instance types and AWS innovations such as Nitro and Graviton with Amazon EKS for you to optimize the compute for your workloads. For more information, see [Manage compute resources by using nodes](eks-compute.md).
**Storage**
EKS Auto Mode automatically creates storage classes using [EBS volumes](create-storage-class.md). Using Container Storage Interface (CSI) drivers, you can also use Amazon S3, Amazon S3 Files, Amazon EFS, Amazon FSX, and Amazon File Cache for your application storage needs. For more information, see [Use application data storage for your cluster](storage.md).
**Security**
The shared responsibility model is employed as it relates to [Security in Amazon EKS](security.md). For more information, see [Security best practices](security-best-practices.md), [Infrastructure security](infrastructure-security.md), and [Kubernetes security](security-k8s.md).
**Monitoring tools**
Use the [observability dashboard](observability-dashboard.md) to monitor Amazon EKS clusters. Monitoring tools include [Prometheus](prometheus.md), [CloudWatch](cloudwatch.md), [Cloudtrail](logging-using-cloudtrail.md), and [ADOT Operator](opentelemetry.md). For more information on dashboards, metrics servers, and other tools, see [EKS cluster costs](cost-monitoring.md) and [Kubernetes Metrics Server](metrics-server.md).
**Cluster capabilities**
EKS provides managed cluster capabilities for continuous deployment, cloud resource management, and resource composition based on open source innovations. EKS installs Kubernetes APIs in your clusters, but controllers and other components run in EKS and are fully managed, providing automated patching, scaling, and monitoring. For more information, see [EKS Capabilities](capabilities.md).
**Kubernetes compatibility and support**
Amazon EKS is certified Kubernetes-conformant, so you can deploy Kubernetes-compatible applications without refactoring and use Kubernetes community tooling and plugins. EKS offers both [standard support](kubernetes-versions-standard.md) and [extended support](kubernetes-versions-extended.md) for Kubernetes. For more information, see [Understand the Kubernetes version lifecycle on EKS](kubernetes-versions.md).
## Related services
**Services to use with Amazon EKS**
You can use other AWS services with the clusters that you deploy using Amazon EKS:
**Amazon EC2**
Obtain on-demand, scalable compute capacity with [Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html).
**Amazon EBS**
Attach scalable, high-performance block storage resources with [Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/what-is-ebs.html).
**Amazon ECR**
Store container images securely with [Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html).
**Amazon CloudWatch**
Monitor AWS resources and applications in real time with [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html).
**Amazon Prometheus**
Track metrics for containerized applications with [Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html).
**Elastic Load Balancing**
Distribute incoming traffic across multiple targets with [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html).
**Amazon GuardDuty**
Detect threats to EKS clusters with [Amazon GuardDuty](integration-guardduty.md).
** AWS Resilience Hub**
Assess EKS cluster resiliency with [AWS Resilience Hub](integration-resilience-hub.md).
## Amazon EKS Pricing
Amazon EKS has per cluster pricing based on Kubernetes cluster version support, pricing for Amazon EKS Auto Mode, and per vCPU pricing for Amazon EKS Hybrid Nodes.
When using Amazon EKS, you pay separately for the AWS resources you use to run your applications on Kubernetes worker nodes. For example, if you are running Kubernetes worker nodes as Amazon EC2 instances with Amazon EBS volumes and public IPv4 addresses, you are charged for the instance capacity through Amazon EC2, the volume capacity through Amazon EBS, and the IPv4 address through Amazon VPC.
Visit the respective pricing pages of the AWS services you are using with your Kubernetes applications for detailed pricing information.
+ For Amazon EKS cluster, Amazon EKS Auto Mode, Amazon EKS Capabilities, and Amazon EKS Hybrid Nodes pricing, see [Amazon EKS Pricing](https://aws.amazon.com/eks/pricing/).
+ For Amazon EC2 pricing, see [Amazon EC2 On-Demand Pricing](https://aws.amazon.com/ec2/pricing/on-demand/) and [Amazon EC2 Spot Pricing](https://aws.amazon.com/ec2/spot/pricing/).
+ For AWS Fargate pricing, see [AWS Fargate Pricing](https://aws.amazon.com/fargate/pricing).
+ You can use your savings plans for compute used in Amazon EKS clusters. For more information, see [Pricing with Savings Plans](https://aws.amazon.com/savingsplans/pricing/).
# Common use cases in Amazon EKS
Amazon EKS offers robust managed Kubernetes services on AWS, designed to optimize containerized applications. The following are a few of the most common use cases of Amazon EKS, helping you leverage its strengths for your specific needs.
**Deploying high-availability applications**
Using [Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/), you can make sure that your applications are highly available across multiple [Availability Zones](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/).
**Building microservices architectures**
Use Kubernetes service discovery features with [AWS Cloud Map](https://aws.amazon.com/cloud-map/) or [Amazon VPC Lattice](https://aws.amazon.com/vpc/lattice/) to build resilient systems.
**Automating software release processes**
Manage continuous integration and continuous deployment (CI/CD) pipelines that simplify the process of automated building, testing, and deployment of applications. For declarative continuous deployment, see [Continuous Deployment with Argo CD](argocd.md).
**Running serverless applications**
Use [AWS Fargate](https://aws.amazon.com/fargate/) with Amazon EKS to run serverless applications. This means you can focus solely on application development, while Amazon EKS and Fargate handle the underlying infrastructure.
**Executing machine learning workloads**
Amazon EKS is compatible with popular machine learning frameworks such as [TensorFlow](https://www.tensorflow.org/), [MXNet](https://mxnet.apache.org/), and [PyTorch](https://pytorch.org/). With GPU support, you can handle even complex machine learning tasks effectively.
**Deploying consistently on-premises and in the cloud**
To simplify running Kubernetes in on-premises environments, you can use the same Amazon EKS clusters, features, and tools to run self-managed nodes on [AWS Outposts](eks-outposts.md) or can use [Amazon EKS Hybrid Nodes](hybrid-nodes-overview.md) with your own infrastructure. For self-contained, air-gapped environments, you can use [Amazon EKS Anywhere](https://aws.amazon.com/eks/eks-anywhere/) to automate Kubernetes cluster lifecycle management on your own infrastructure.
**Running cost-effective batch processing and big data workloads**
Utilize [Spot Instances](https://aws.amazon.com/ec2/spot/) to run your batch processing and big data workloads such as [Apache Hadoop](https://aws.amazon.com/emr/details/hadoop/what-is-hadoop/) and [Spark](https://aws.amazon.com/big-data/what-is-spark/), at a fraction of the cost. This lets you take advantage of unused Amazon EC2 capacity at discounted prices.
**Managing AWS resources from Kubernetes**
Use [AWS Controllers for Kubernetes (ACK)](ack.md) to create and manage AWS resources directly from your Kubernetes cluster using native Kubernetes APIs.
**Building platform engineering abstractions**
Create custom Kubernetes APIs that compose multiple resources into higher-level abstractions using [kro (Kube Resource Orchestrator)](kro.md).
**Securing applications and ensuring compliance**
Implement strong security practices and maintain compliance with Amazon EKS, which integrates with AWS security services such as [AWS Identity and Access Management](https://aws.amazon.com/iam/) (IAM), [Amazon Virtual Private Cloud](https://aws.amazon.com/vpc/) (Amazon VPC), and [AWS Key Management Service](https://aws.amazon.com/kms/) (AWS KMS). This ensures data privacy and protection as per industry standards.
# Amazon EKS architecture
Amazon EKS aligns with the general cluster architecture of Kubernetes. For more information, see [Kubernetes Components](https://kubernetes.io/docs/concepts/overview/components/) in the Kubernetes documentation. The following sections summarize some extra architecture details for Amazon EKS.
## Control plane
Amazon EKS ensures every cluster has its own unique Kubernetes control plane. This design keeps each cluster’s infrastructure separate, with no overlaps between clusters or AWS accounts. The setup includes:
**Distributed components**
The control plane positions at least two API server instances and three [etcd](https://etcd.io/) instances across three AWS Availability Zones within an AWS Region.
**Optimal performance**
Amazon EKS actively monitors and adjusts control plane instances to maintain peak performance.
**Resilience**
If a control plane instance falters, Amazon EKS quickly replaces it, using a different Availability Zone if needed.
**Consistent uptime**
By running clusters across multiple Availability Zones, a reliable [API server endpoint availability Service Level Agreement (SLA)](https://aws.amazon.com/eks/sla) is achieved.
Amazon EKS uses Amazon Virtual Private Cloud (Amazon VPC) to limit traffic between control plane components within a single cluster. Cluster components can’t view or receive communication from other clusters or AWS accounts, except when authorized by Kubernetes role-based access control (RBAC) policies.
## Compute
In addition to the control plane, an Amazon EKS cluster has a set of worker machines called nodes. Selecting the appropriate Amazon EKS cluster node type is crucial for meeting your specific requirements and optimizing resource utilization. Amazon EKS offers the following primary node types:
**EKS Auto Mode**
[EKS Auto Mode](automode.md) extends AWS management beyond the control plane to include the data plane, automating cluster infrastructure management. It integrates core Kubernetes capabilities as built-in components, including compute autoscaling, networking, load balancing, DNS, storage, and GPU support. EKS Auto Mode dynamically manages nodes based on workload demands, using immutable AMIs with enhanced security features. It automates updates and upgrades while respecting Pod Disruption Budgets, and includes managed components that would otherwise require add-on management. This option is ideal for users who want to leverage AWS expertise for day-to-day operations, minimize operational overhead, and focus on application development rather than infrastructure management.
** AWS Fargate**
[Fargate](fargate.md) is a serverless compute engine for containers that eliminates the need to manage the underlying instances. With Fargate, you specify your application’s resource needs, and AWS automatically provisions, scales, and maintains the infrastructure. This option is ideal for users who prioritize ease-of-use and want to concentrate on application development and deployment rather than managing infrastructure.
**Karpenter**
[Karpenter](https://karpenter.sh/) is a flexible, high-performance Kubernetes cluster autoscaler that helps improve application availability and cluster efficiency. Karpenter launches right-sized compute resources in response to changing application load. This option can provision just-in-time compute resources that meet the requirements of your workload.
**Managed node groups**
[Managed node groups](managed-node-groups.md) are a blend of automation and customization for managing a collection of Amazon EC2 instances within an Amazon EKS cluster. AWS takes care of tasks like patching, updating, and scaling nodes, easing operational aspects. In parallel, custom `kubelet` arguments are supported, opening up possibilities for advanced CPU and memory management policies. Moreover, they enhance security via AWS Identity and Access Management (IAM) roles for service accounts, while curbing the need for separate permissions per cluster.
**Self-managed nodes**
[Self-managed nodes](worker.md) offer full control over your Amazon EC2 instances within an Amazon EKS cluster. You are in charge of managing, scaling, and maintaining the nodes, giving you total control over the underlying infrastructure. This option is suitable for users who need granular control and customization of their nodes and are ready to invest time in managing and maintaining their infrastructure.
**Amazon EKS Hybrid Nodes**
With [Amazon EKS Hybrid Nodes](hybrid-nodes-overview.md), you can use your on-premises and edge infrastructure as nodes in Amazon EKS clusters. Amazon EKS Hybrid Nodes unifies Kubernetes management across environments and offloads Kubernetes control plane management to AWS for your on-premises and edge applications.
## EKS Capabilities
Amazon EKS provides fully managed cluster capabilities, installing and managing Kubernetes APIs (with Kubernetes Custom Resource Definitions) in your cluster while operating controllers and other components in AWS-owned infrastructure, separate from your cluster. EKS provides automated patching, scaling, and monitoring of these capabilities, fully managing their lifecycle to reduce the burden of operating in-cluster services for workload orchestration, AWS resource management, and more.
EKS provides the following capability types:
** AWS Controllers for Kubernetes (ACK)**
[AWS Controllers for Kubernetes (ACK)](ack.md) enables you to manage AWS resources using Kubernetes APIs, allowing you to define S3 buckets, RDS databases, IAM roles, and other AWS resources as Kubernetes custom resources. You can manage AWS resources alongside your Kubernetes workloads using the same tools and workflows, with support for 50\$1 AWS services including S3, RDS, DynamoDB, and Lambda.
**Argo CD**
[Argo CD](argocd.md) implements GitOps-based continuous deployment for your application workloads, AWS resources, and cluster configuration, using Git repositories as the source of truth. Argo CD automatically syncs your clusters with your Git repositories and detects drift, continuously reconciling to ensure your deployed applications and resources match your desired state in version control. You can use Argo CD to manage applications on a given cluster, or deploy and manage applications across multiple clusters from a single Argo CD resource, with automated deployment from Git repositories whenever changes are committed.
**kro (Kube Resource Orchestrator)**
[kro (Kube Resource Orchestrator)](kro.md) enables you to create custom Kubernetes APIs that compose multiple resources into higher-level abstractions, allowing platform teams to define reusable patterns for common resource combinations. This enables platform teams to provide self-service capabilities with appropriate guardrails, allowing developers to provision complex infrastructure using simple, purpose-built APIs while maintaining organizational standards and best practices.
# Kubernetes concepts
Amazon Elastic Kubernetes Service (Amazon EKS) is an AWS managed service based on the open source [Kubernetes](https://kubernetes.io/) project. While there are things you need to know about how the Amazon EKS service integrates with AWS Cloud (particularly when you first create an Amazon EKS cluster), once it’s up and running, you use your Amazon EKS cluster in much the same way as you would any other Kubernetes cluster. So to begin managing Kubernetes clusters and deploying workloads, you need at least a basic understanding of Kubernetes concepts.
This page divides Kubernetes concepts into three sections: [Why Kubernetes?](#why-kubernetes), [Clusters](#concepts-clusters), and [Workloads](#workloads). The first section describes the value of running a Kubernetes service, in particular as a managed service like Amazon EKS. The Workloads section covers how Kubernetes applications are built, stored, run, and managed. The Clusters section lays out the different components that make up Kubernetes clusters and what your responsibilities are for creating and maintaining Kubernetes clusters.
**Topics**
+ [
## Why Kubernetes?
](#why-kubernetes)
+ [
## Clusters
](#concepts-clusters)
+ [
## Workloads
](#workloads)
+ [
## Next steps
](#next-steps)
As you go through this content, links will lead you to further descriptions of Kubernetes concepts in both Amazon EKS and Kubernetes documentation, in case you want to take deep dives into any of the topics we cover here. For details about how Amazon EKS implements Kubernetes control plane and compute features, see [Amazon EKS architecture](eks-architecture.md).
## Why Kubernetes?
Kubernetes was designed to improve availability and scalability when running mission-critical, production-quality containerized applications. Rather than just running Kubernetes on a single machine (although that is possible), Kubernetes achieves those goals by allowing you to run applications across sets of computers that can expand or contract to meet demand. Kubernetes includes features that make it easier for you to:
+ Deploy applications on multiple machines (using containers deployed in Pods)
+ Monitor container health and restart failed containers
+ Scale containers up and down based on load
+ Update containers with new versions
+ Allocate resources between containers
+ Balance traffic across machines
Having Kubernetes automate these types of complex tasks allows an application developer to focus on building and improving their application workloads, rather than worrying about infrastructure. The developer typically creates configuration files, formatted as YAML files, that describe the desired state of the application. This could include which containers to run, resource limits, number of Pod replicas, CPU/memory allocation, affinity rules, and more.
### Attributes of Kubernetes
To achieve its goals, Kubernetes has the following attributes:
+ **Containerized** — Kubernetes is a container orchestration tool. To use Kubernetes, you must first have your applications containerized. Depending on the type of application, this could be as a set of *microservices,* as batch jobs or in other forms. Then, your applications can take advantage of a Kubernetes workflow that encompasses a huge ecosystem of tools, where containers can be stored as [images in a container registry](https://kubernetes.io/docs/concepts/containers/images/#multi-architecture-images-with-image-indexes), deployed to a Kubernetes [cluster](https://kubernetes.io/docs/concepts/architecture/), and run on an available [node](https://kubernetes.io/docs/concepts/architecture/nodes/). You can build and test individual containers on your local computer with Docker or another [container runtime](https://kubernetes.io/docs/setup/production-environment/container-runtimes/), before deploying them to your Kubernetes cluster.
+ **Scalable** — If the demand for your applications exceeds the capacity of the running instances of those applications, Kubernetes is able to scale up. As needed, Kubernetes can tell if applications require more CPU or memory and respond by either automatically expanding available capacity or using more of existing capacity. Scaling can be done at the Pod level, if there is enough compute available to just run more instances of the application ([horizontal Pod autoscaling](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)), or at the node level, if more nodes need to be brought up to handle the increased capacity ([Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) or [Karpenter](https://karpenter.sh/)). As capacity is no longer needed, these services can delete unnecessary Pods and shut down unneeded nodes.
+ **Available** — If an application or node becomes unhealthy or unavailable, Kubernetes can move running workloads to another available node. You can force the issue by simply deleting a running instance of a workload or node that’s running your workloads. The bottom line here is that workloads can be brought up in other locations if they can no longer run where they are.
+ **Declarative** — Kubernetes uses active reconciliation to constantly check that the state that you declare for your cluster matches the actual state. By applying [Kubernetes objects](https://kubernetes.io/docs/concepts/overview/working-with-objects/) to a cluster, typically through YAML-formatted configuration files, you can, for example, ask to start up the workloads you want to run on your cluster. You can later change the configurations to do something like use a later version of a container or allocate more memory. Kubernetes will do what it needs to do to establish the desired state. This can include bringing nodes up or down, stopping and restarting workloads, or pulling updated containers.
+ **Composable** — Because an application typically consists of multiple components, you want to be able to manage a set of these components (often represented by multiple containers) together. While Docker Compose offers a way to do this directly with Docker, the Kubernetes [Kompose](http://kompose.io/) command can help you do that with Kubernetes. See [Translate a Docker Compose File to Kubernetes Resources](https://kubernetes.io/docs/tasks/configure-pod-container/translate-compose-kubernetes/) for an example of how to do this.
+ **Extensible** — Unlike proprietary software, the open source Kubernetes project is designed to be open to you extending Kubernetes any way that you like to meet your needs. APIs and configuration files are open to direct modifications. Third-parties are encouraged to write their own [Controllers](https://kubernetes.io/docs/concepts/architecture/controller/), to extend both infrastructure and end-user Kubernetes features. [Webhooks](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) let you set up cluster rules to enforce policies and adapt to changing conditions. For more ideas on how to extend Kubernetes clusters, see [Extending Kubernetes](https://kubernetes.io/docs/concepts/extend-kubernetes/).
+ **Portable** — Many organizations have standardized their operations on Kubernetes because it allows them to manage all of their application needs in the same way. Developers can use the same pipelines to build and store containerized applications. Those applications can then be deployed to Kubernetes clusters running on-premises, in clouds, on point-of-sales terminals in restaurants, or on IOT devices dispersed across company’s remote sites. Its open source nature makes it possible for people to develop these special Kubernetes distributions, along will tools needed to manage them.
### Managing Kubernetes
Kubernetes source code is freely available, so with your own equipment you could install and manage Kubernetes yourself. However, self-managing Kubernetes requires deep operational expertise and takes time and effort to maintain. For those reasons, most people deploying production workloads choose a cloud provider (such as Amazon EKS) or on-premises provider (such as Amazon EKS Anywhere) with its own tested Kubernetes distribution and support of Kubernetes experts. This allows you to offload much of the undifferentiated heavy lifting needed to maintain your clusters, including:
+ **Hardware** — If you don’t have hardware available to run Kubernetes per your requirements, a cloud provider such as AWS Amazon EKS can save you on upfront costs. With Amazon EKS, this means that you can consume the best cloud resources offered by AWS, including computer instances (Amazon Elastic Compute Cloud), your own private environment (Amazon VPC), central identity and permissions management (IAM), and storage (Amazon EBS). AWS manages the computers, networks, data centers, and all the other physical components needed to run Kubernetes. Likewise, you don’t have to plan your datacenter to handle the maximum capacity on your highest-demand days. For Amazon EKS Anywhere, or other on premises Kubernetes clusters, you are responsible for managing the infrastructure used in your Kubernetes deployments, but you can still rely on AWS to help you keep Kubernetes up to date.
+ **Control plane management** — Amazon EKS manages the security and availability of the AWS-hosted Kubernetes control plane, which is responsible for scheduling containers, managing the availability of applications, and other key tasks, so you can focus on your application workloads. If your cluster breaks, AWS should have the means to restore your cluster to a running state. For Amazon EKS Anywhere, you would manage the control plane yourself.
+ **Tested upgrades** — When you upgrade your clusters, you can rely on Amazon EKS or Amazon EKS Anywhere to provide tested versions of their Kubernetes distributions.
+ **Add-ons** — There are hundreds of projects built to extend and work with Kubernetes that you can add to your cluster’s infrastructure or use to aid the running of your workloads. Instead of building and managing those add-ons yourself, AWS provides [Amazon EKS add-ons](eks-add-ons.md) that you can use with your clusters. Amazon EKS Anywhere provides [Curated Packages](https://anywhere.eks.amazonaws.com/docs/packages/) that include builds of many popular open source projects. So you don’t have to build the software yourself or manage critical security patches, bug fixes, or upgrades. Likewise, if the defaults meet your needs, it’s typical for very little configuration of those add-ons to be needed. See [Extend Clusters](#extend-clusters) for details on extending your cluster with add-ons.
### Kubernetes in action
The following diagram shows key activities you would do as a Kubernetes Admin or Application Developer to create and use a Kubernetes cluster. In the process, it illustrates how Kubernetes components interact with each other, using the AWS cloud as the example of the underlying cloud provider.
![\[A Kubernetes cluster in action.\]](http://docs.aws.amazon.com/eks/latest/userguide/images/k8sinaction.png)
A Kubernetes Admin creates the Kubernetes cluster using a tool specific to the type of provider on which the cluster will be built. This example uses the AWS cloud as the provider, which offers the managed Kubernetes service called Amazon EKS. The managed service automatically allocates the resources needed to create the cluster, including creating two new Virtual Private Clouds (Amazon VPCs) for the cluster, setting up networking, and mapping Kubernetes permissions directly into the new VPCs for cloud asset management. The managed service also sees that the control plane services have places to run and allocates zero or more Amazon EC2 instances as Kubernetes nodes for running workloads. AWS manages one Amazon VPC itself for the control plane, while the other Amazon VPC contains the customer nodes that run workloads.
Many of the Kubernetes Admin’s tasks going forward are done using Kubernetes tools such as `kubectl`. That tool makes requests for services directly to the cluster’s control plane. The ways that queries and changes are made to the cluster are then very similar to the ways you would do them on any Kubernetes cluster.
An application developer wanting to deploy workloads to this cluster can perform several tasks. The developer needs to build the application into one or more container images, then push those images to a container registry that is accessible to the Kubernetes cluster. AWS offers the Amazon Elastic Container Registry (Amazon ECR) for that purpose.
To run the application, the developer can create YAML-formatted configuration files that tell the cluster how to run the application, including which containers to pull from the registry and how to wrap those containers in Pods. The control plane (scheduler) schedules the containers to one or more nodes and the container runtime on each node actually pulls and runs the needed containers. The developer can also set up an application load balancer to balance traffic to available containers running on each node and expose the application so it is available on a public network to the outside world. With that all done, someone wanting to use the application can connect to the application endpoint to access it.
The following sections go through details of each of these features, from the perspective of Kubernetes Clusters and Workloads.
## Clusters
If your job is to start and manage Kubernetes clusters, you should know how Kubernetes clusters are created, enhanced, managed, and deleted. You should also know what the components are that make up a cluster and what you need to do to maintain those components.
Tools for managing clusters handle the overlap between the Kubernetes services and the underlying hardware provider. For that reason, automation of these tasks tend to be done by the Kubernetes provider (such as Amazon EKS or Amazon EKS Anywhere) using tools that are specific to the provider. For example, to start an Amazon EKS cluster you can use `eksctl create cluster`, while for Amazon EKS Anywhere you can use `eksctl anywhere create cluster`. Note that while these commands create a Kubernetes cluster, they are specific to the provider and are not part of the Kubernetes project itself.
### Cluster creation and management tools
The Kubernetes project offers tools for creating a Kubernetes cluster manually. So if you want to install Kubernetes on a single machine, or run the control plane on a machine and add nodes manually, you can use CLI tools like [kind](https://kind.sigs.k8s.io/), [minikube](https://kubernetes.io/docs/tutorials/hello-minikube/), or [kubeadm](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) that are listed under Kubernetes [Install Tools](https://kubernetes.io/docs/tasks/tools/). To simplify and automate the full lifecycle of cluster creation and management, it is much easier to use tools supported by an established Kubernetes provider, such as Amazon EKS or Amazon EKS Anywhere.
In AWS Cloud, you can create [Amazon EKS](https://docs.aws.amazon.com/eks/) clusters using CLI tools, such as [eksctl](https://eksctl.io/), or more declarative tools, such as Terraform (see [Amazon EKS Blueprints for Terraform](https://github.com/aws-ia/terraform-aws-eks-blueprints)). You can also create a cluster from the AWS Management Console. See [Amazon EKS features](https://aws.amazon.com/eks/features/) for a list what you get with Amazon EKS. Kubernetes responsibilities that Amazon EKS takes on for you include:
+ **Managed control plane** — AWS makes sure that the Amazon EKS cluster is available and scalable because it manages the control plane for you and makes it available across AWS Availability Zones.
+ **Node management** — Instead of manually adding nodes, you can have Amazon EKS create nodes automatically as needed, using Managed Node Groups (see [Simplify node lifecycle with managed node groups](managed-node-groups.md)) or [Karpenter](https://karpenter.sh/). Managed Node Groups have integrations with Kubernetes [Cluster Autoscaling](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md). Using node management tools, you can take advantage of cost savings, with things like [Spot Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) and node consolidation, and availability, using [Scheduling](https://karpenter.sh/docs/concepts/scheduling/) features to set how workloads are deployed and nodes are selected.
+ **Cluster networking** — Using CloudFormation templates, `eksctl` sets up networking between control plane and data plane (node) components in the Kubernetes cluster. It also sets up endpoints through which internal and external communications can take place. See [De-mystifying cluster networking for Amazon EKS worker nodes](https://aws.amazon.com/blogs/containers/de-mystifying-cluster-networking-for-amazon-eks-worker-nodes) for details. Communications between Pods in Amazon EKS is done using Amazon EKS Pod Identities (see [Learn how EKS Pod Identity grants pods access to AWS services](pod-identities.md)), which provides a means of letting Pods tap into AWS cloud methods of managing credentials and permissions.
+ **Add-Ons** — Amazon EKS saves you from having to build and add software components that are commonly used to support Kubernetes clusters. For example, when you create an Amazon EKS cluster from the AWS Management Console, it automatically adds the Amazon EKS kube-proxy ([Manage `kube-proxy` in Amazon EKS clusters](managing-kube-proxy.md)), Amazon VPC CNI plugin for Kubernetes ([Assign IPs to Pods with the Amazon VPC CNI](managing-vpc-cni.md)), and CoreDNS ([Manage CoreDNS for DNS in Amazon EKS clusters](managing-coredns.md)) add-ons. See [Amazon EKS add-ons](eks-add-ons.md) for more on these add-ons, including a list of which are available.
To run your clusters on your own on-premises computers and networks, Amazon offers [Amazon EKS Anywhere](https://anywhere.eks.amazonaws.com/). Instead of the AWS Cloud being the provider, you have the choice of running Amazon EKS Anywhere on [VMWare vSphere](https://anywhere.eks.amazonaws.com/docs/getting-started/vsphere/), [bare metal](https://anywhere.eks.amazonaws.com/docs/getting-started/baremetal/) ([Tinkerbell provider](https://tinkerbell.org)), [Snow](https://anywhere.eks.amazonaws.com/docs/getting-started/snow/), [CloudStack](https://anywhere.eks.amazonaws.com/docs/getting-started/cloudstack/), or [Nutanix](https://anywhere.eks.amazonaws.com/docs/getting-started/nutanix/) platforms using your own equipment.
Amazon EKS Anywhere is based on the same [Amazon EKS Distro](https://distro.eks.amazonaws.com/) software that is used by Amazon EKS. However, Amazon EKS Anywhere relies on different implementations of the [Kubernetes Cluster API](https://cluster-api.sigs.k8s.io/) (CAPI) interface to manage the full lifecycle of the machines in an Amazon EKS Anywhere cluster (such as [CAPV](https://github.com/kubernetes-sigs/cluster-api-provider-vsphere) for vSphere and [CAPC](https://github.com/kubernetes-sigs/cluster-api-provider-cloudstack) for CloudStack). Because the entire cluster is running on your equipment, you take on the added responsibility of managing the control plane and backing up its data (see `etcd` later in this document).
### Cluster components
Kubernetes cluster components are divided into two major areas: control plane and worker nodes. [Control Plane Components](https://kubernetes.io/docs/concepts/overview/components/#control-plane-components) manage the cluster and provide access to its APIs. Worker nodes (sometimes just referred to as Nodes) provide the places where the actual workloads are run. [Node Components](https://kubernetes.io/docs/concepts/overview/components/#node-components) consist of services that run on each node to communicate with the control plane and run containers. The set of worker nodes for your cluster is referred to as the *Data Plane*.
#### Control plane
The control plane consists of a set of services that manage the cluster. These services may all be running on a single computer or may be spread across multiple computers. Internally, these are referred to as Control Plane Instances (CPIs). How CPIs are run depends on the size of the cluster and requirements for high availability. As demand increase in the cluster, a control plane service can scale to provide more instances of that service, with requests being load balanced between the instances.
Tasks that components of the Kubernetes control plane performs include:
+ **Communicating with cluster components (API server)** — The API server ([kube-apiserver](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/)) exposes the Kubernetes API so requests to the cluster can be made from both inside and outside of the cluster. In other words, requests to add or change a cluster’s objects (Pods, Services, Nodes, and so on) can come from outside commands, such as requests from `kubectl` to run a Pod. Likewise, requests can be made from the API server to components within the cluster, such as a query to the `kubelet` service for the status of a Pod.
+ **Store data about the cluster (`etcd` key value store)** — The `etcd` service provides the critical role of keeping track of the current state of the cluster. If the `etcd` service became inaccessible, you would be unable to update or query the status of the cluster, though workloads would continue to run for a while. For that reason, critical clusters typically have multiple, load-balanced instances of the `etcd` service running at a time and do periodic backups of the `etcd` key value store in case of data loss or corruption. Keep in mind that, in Amazon EKS, this is all handled for you automatically by default. Amazon EKS Anywhere provides instruction for [etcd backup and restore](https://anywhere.eks.amazonaws.com/docs/clustermgmt/etcd-backup-restore/). See the [etcd Data Model](https://etcd.io/docs/v3.5/learning/data_model/) to learn how `etcd` manages data.
+ **Schedule Pods to nodes (Scheduler)** — Requests to start or stop a Pod in Kubernetes are directed to the [Kubernetes Scheduler](https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/) ([kube-scheduler](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/)). Because a cluster could have multiple nodes that are capable of running the Pod, it is up to the Scheduler to choose which node (or nodes, in the case of replicas) the Pod should run on. If there is not enough available capacity to run the requested Pod on an existing node, the request will fail, unless you have made other provisions. Those provisions could include enabling services such as Managed Node Groups ([Simplify node lifecycle with managed node groups](managed-node-groups.md)) or [Karpenter](https://karpenter.sh/) that can automatically start up new nodes to handle the workloads.
+ **Keep components in desired state (Controller Manager)** — The Kubernetes Controller Manager runs as a daemon process ([kube-controller-manager](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/)) to watch the state of the cluster and make changes to the cluster to reestablish the expected states. In particular, there are several controllers that watch over different Kubernetes objects, which includes a `statefulset-controller`, `endpoint-controller`, `cronjob-controller`, `node-controller`, and others.
+ **Manage cloud resources (Cloud Controller Manager)** — Interactions between Kubernetes and the cloud provider that carries out requests for the underlying data center resources are handled by the [Cloud Controller Manager](https://kubernetes.io/docs/concepts/architecture/cloud-controller/) ([cloud-controller-manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager)). Controllers managed by the Cloud Controller Manager can include a route controller (for setting up cloud network routes), service controller (for using cloud load balancing services), and node lifecycle controller (to keep nodes in sync with Kubernetes throughout their lifecycles).
#### Worker Nodes (data plane)
For a single-node Kubernetes cluster, workloads run on the same machine as the control plane. However, a more standard configuration is to have one or more separate computer systems ([Nodes](https://kubernetes.io/docs/concepts/architecture/nodes/)) that are dedicated to running Kubernetes workloads.
When you first create a Kubernetes cluster, some cluster creation tools allow you to configure a certain number nodes to be added to the cluster (either by identifying existing computer systems or by having the provider create new ones). Before any workloads are added to those systems, services are added to each node to implement these features:
+ **Manage each node (`kubelet`)** — The API server communicates with the [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) service running on each node to make sure that the node is properly registered and Pods requested by the Scheduler are running. The kubelet can read the Pod manifests and set up storage volumes or other features needed by the Pods on the local system. It can also check on the health of the locally running containers.
+ **Run containers on a node (container runtime)** — The [Container Runtime](https://kubernetes.io/docs/setup/production-environment/container-runtimes/) on each node manages the containers requested for each Pod assigned to the node. That means that it can pull container images from the appropriate registry, run the container, stop it, and responds to queries about the container. The default container runtime is [containerd](https://github.com/containerd/containerd/blob/main/docs/getting-started.md). As of Kubernetes 1.24, the special integration of Docker (`dockershim`) that could be used as the container runtime was dropped from Kubernetes. While you can still use Docker to test and run containers on your local system, to use Docker with Kubernetes you would now have to [Install Docker Engine](https://docs.docker.com/engine/install/#server) on each node to use it with Kubernetes.
+ **Manage networking between containers (`kube-proxy`)** — To be able to support communication between Pods, Kubernetes uses a feature referred to as a [Service](https://kubernetes.io/docs/concepts/services-networking/service/) to set up Pod networks that track IP addresses and ports associated with those Pods. The [kube-proxy](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/) service runs on every node to allow that communication between Pods to take place.
### Extend Clusters
There are some services you can add to Kubernetes to support the cluster, but are not run in the control plane. These services often run directly on nodes in the kube-system namespace or in its own namespace (as is often done with third-party service providers). A common example is the CoreDNS service, which provides DNS services to the cluster. Refer to [Discovering builtin services](https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster-services/) for information on how to see which cluster services are running in kube-system on your cluster.
There are different types of add-ons you can consider adding to your clusters. To keep your clusters healthy, you can add observability features (see [Monitor your cluster performance and view logs](eks-observe.md)) that allow you to do things like logging, auditing, and metrics. With this information, you can troubleshoot problems that occur, often through the same observability interfaces. Examples of these types of services include [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring.html), CloudWatch (see [Monitor cluster data with Amazon CloudWatch](cloudwatch.md)), [AWS Distro for OpenTelemetry](https://aws-otel.github.io/), Amazon VPC CNI plugin for Kubernetes (see [Assign IPs to Pods with the Amazon VPC CNI](managing-vpc-cni.md)), and [Grafana Kubernetes Monitoring](https://grafana.com/docs/grafana-cloud/monitor-infrastructure/kubernetes-monitoring/configuration/config-aws-eks/). For storage (see [Use application data storage for your cluster](storage.md)), add-ons to Amazon EKS include Amazon Elastic Block Store CSI Driver (see [Use Kubernetes volume storage with Amazon EBS](ebs-csi.md)), Amazon Elastic File System CSI Driver (see [Use elastic file system storage with Amazon EFS](efs-csi.md)), and several third-party storage add-ons such as Amazon FSx for NetApp ONTAP CSI driver [Use high-performance app storage with FSx for NetApp ONTAP](fsx-ontap.md)).
For a more complete list of available Amazon EKS add-ons, see [Amazon EKS add-ons](eks-add-ons.md).
## Workloads
Kubernetes defines a [Workload](https://kubernetes.io/docs/concepts/workloads/) as "an application running on Kubernetes." That application can consist of a set of microservices run as [Containers](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-container) in [Pods](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-pod), or could be run as a batch job or other type of applications. The job of Kubernetes is to make sure that the requests that you make for those objects to be set up or deployed are carried out. As someone deploying applications, you should learn about how containers are built, how Pods are defined, and what methods you can use for deploying them.
### Containers
The most basic element of an application workload that you deploy and manage in Kubernetes is a * [Pod](https://kubernetes.io/docs/concepts/workloads/pods/) *. A Pod represents a way of holding the components of an application as well as defining specifications that describe the Pod’s attributes. Contrast this to something like an RPM or Deb package, which packages together software for a Linux system, but does not itself run as an entity.
Because the Pod is the smallest deployable unit, it typically holds a single container. However, multiple containers can be in a Pod in cases where the containers are tightly coupled. For example, a web server container might be packaged in a Pod with a [sidecar](https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/) type of container that may provide logging, monitoring, or other service that is closely tied to the web server container. In this case, being in the same Pod ensures that for each running instance of the Pod, both containers always run on the same node. Likewise, all containers in a Pod share the same environment, with the containers in a Pod running as though they are in the same isolated host. The effect of this is that the containers share a single IP address that provides access to the Pod and the containers can communicate with each other as though they were running on their own localhost.
Pod specifications ([PodSpec](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)) define the desired state of the Pod. You can deploy an individual Pod or multiple Pods by using workload resources to manage [Pod Templates](https://kubernetes.io/docs/concepts/workloads/pods/#pod-templates). Workload resources include [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) (to manage multiple Pod Replicas), [StatefulSets](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) (to deploy Pods that need to be unique, such as database Pods), and [DaemonSets](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) (where a Pod needs to run continuously on every node). More on those later.
While a Pod is the smallest unit you deploy, a container is the smallest unit that you build and manage.
#### Building Containers
The Pod is really just a structure around one or more containers, with each container itself holding the file system, executables, configuration files, libraries, and other components to actually run the application. Because a company called Docker Inc. first popularized containers, some people refer to containers as Docker Containers. However, the [Open Container Initiative](https://opencontainers.org/) has since defined container runtimes, images, and distribution methods for the industry. Add to that the fact that containers were created from many existing Linux features, others often refer to containers as OCI Containers, Linux Containers, or just Containers.
When you build a container, you typically start with a Dockerfile (literally named that). Inside that Dockerfile, you identify:
+ **A base image** — A base container image is a container that is typically built from either a minimal version of an operating system’s file system (such as [Red Hat Enterprise Linux](https://catalog.redhat.com/software/base-images) or [Ubuntu](https://gallery.ecr.aws/docker/library/ubuntu)) or a minimal system that is enhanced to provide software to run specific types of applications (such as a [nodejs](https://catalog.redhat.com/software/container-stacks/detail/611c11fabd674341b5c5ed64) or [python](https://gallery.ecr.aws/docker/library/python) apps).
+ **Application software** — You can add your application software to your container in much the same way you would add it to a Linux system. For example, in your Dockerfile you can run `npm` and `yarn` to install a Java application or `yum` and `dnf` to install RPM packages. In other words, using a RUN command in a Dockerfile, you can run any command that is available in the file system of your base image to install software or configure software inside of the resulting container image.
+ **Instructions** — The [Dockerfile reference](https://docs.docker.com/reference/dockerfile/) describes the instructions you can add to a Dockerfile when you configure it. These include instructions used to build what is in the container itself (`ADD` or `COPY` files from the local system), identify commands to execute when the container is run (`CMD` or `ENTRYPOINT`), and connect the container to the system it runs on (by identifying the `USER` to run as, a local `VOLUME` to mount, or the ports to `EXPOSE`).
While the `docker` command and service have traditionally been used to build containers (`docker build`), other tools that are available to build container images include [podman](https://docs.podman.io/en/stable/markdown/podman-build.1.html) and [nerdctl](https://github.com/containerd/nerdctl). See [Building Better Container Images](https://aws.amazon.com/blogs/containers/building-better-container-images) or [Overview of Docker Build](https://docs.docker.com/build/) to learn about building containers.
#### Storing Containers
Once you’ve built your container image, you can store it in a container [distribution registry](https://distribution.github.io/distribution/) on your workstation or on a public container registry. Running a private container registry on your workstation allows you to store container images locally, making them readily available to you.
To store container images in a more public manner, you can push them to a public container registry. Public container registries provide a central location for storing and distributing container images. Examples of public container registries include the [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/), [Red Hat Quay](https://quay.io/) registry, and [Docker Hub](https://hub.docker.com/) registry.
When running containerized workloads on Amazon Elastic Kubernetes Service (Amazon EKS) we recommend pulling copies of Docker Official Images that are stored in Amazon Elastic Container Registry. Amazon ECR has been storing these images since 2021. You can search for popular container images in the [Amazon ECR Public Gallery](https://gallery.ecr.aws/), and specifically for the Docker Hub images, you can search the [Amazon ECR Docker Gallery](https://gallery.ecr.aws/docker/).
#### Running containers
Because containers are built in a standard format, a container can run on any machine that can run a container runtime (such as Docker) and whose contents match the local machine’s architecture (such as `x86_64` or `arm`). To test a container or just run it on your local desktop, you can use `docker run` or `podman run` commands to start up a container on the localhost. For Kubernetes, however, each worker node has a container runtime deployed and it is up to Kubernetes to request that a node run a container.
Once a container has been assigned to run on a node, the node looks to see if the requested version of the container image already exists on the node. If it doesn’t, Kubernetes tells the container runtime to pull that container from the appropriate container registry, then run that container locally. Keep in mind that a *container image* refers to the software package that is moved around between your laptop, the container registry, and Kubernetes nodes. A *container* refers to a running instance of that image.
### Pods
Once your containers are ready, working with Pods includes configuring, deploying, and making the Pods accessible.
#### Configuring Pods
When you define a Pod, you assign a set of attributes to it. Those attributes must include at least the Pod name and the container image to run. However, there are many other things you want to configure with your Pod definitions as well (see the [PodSpec](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec) page for details on what can go into a Pod). These include:
+ **Storage** — When a running container is stopped and deleted, data storage in that container will disappear, unless you set up more permanent storage. Kubernetes supports many different storage types and abstracts them under the umbrella of [Volumes](https://kubernetes.io/docs/concepts/storage/volumes/). Storage types include [CephFS](https://kubernetes.io/docs/concepts/storage/volumes/#cephfs), [NFS](https://kubernetes.io/docs/concepts/storage/volumes/#nfs), [iSCSI](https://kubernetes.io/docs/concepts/storage/volumes/#iscsi), and others. You can even use a [local block device](https://kubernetes.io/docs/concepts/storage/volumes/#local) from the local computer. With one of those storage types available from your cluster, you can mount the storage volume to a selected mount point in your container’s file system. A [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) is one that continues to exist after the Pod is deleted, while an [Ephemeral Volume](https://kubernetes.io/docs/concepts/storage/ephemeral-volumes/) is deleted when the Pod is deleted. If your cluster administrator created different [storage classes](https://kubernetes.io/docs/concepts/storage/storage-classes/) for your cluster, you might have the option for choosing the attributes of the storage you use, such as whether the volume is deleted or reclaimed after use, whether it will expand if more space is needed, and even whether it meets certain performance requirements.
+ **Secrets** — By making [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/) available to containers in Pod specs, you can provide the permissions those containers need to access file systems, databases, or other protected assets. Keys, passwords, and tokens are among the items that can be stored as secrets. Using secrets makes it so you don’t have to store this information in container images, but need only make the secrets available to running containers. Similar to Secrets are [ConfigMaps](https://kubernetes.io/docs/concepts/configuration/configmap/). A `ConfigMap` tends to hold less critical information, such as key-value pairs for configuring a service.
+ **Container resources** — Objects for further configuring containers can take the form of resource configuration. For each container, you can request the amount of memory and CPU that it can use, as well as place limits of the total amount of those resources that the container can use. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/) for examples.
+ **Disruptions** — Pods can be disrupted involuntarily (a node goes down) or voluntarily (an upgrade is desired). By configuring a [Pod disruption budget](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/#pod-disruption-budgets), you can exert some control over how available your application remains when disruptions occur. See [Specifying a Disruption Budget](https://kubernetes.io/docs/tasks/run-application/configure-pdb/) for your application for examples.
+ **Namespaces** — Kubernetes provides different ways to isolate Kubernetes components and workloads from each other. Running all the Pods for a particular application in the same [Namespace](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) is a common way to secure and manage those Pods together. You can create your own namespaces to use or choose to not indicate a namespace (which causes Kubernetes to use the `default` namespace). Kubernetes control plane components typically run in the [kube-system](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) namespace.
The configuration just described is typically gathered together in a YAML file to be applied to the Kubernetes cluster. For personal Kubernetes clusters, you might just store these YAML files on your local system. However, with more critical clusters and workloads, [GitOps](https://www.eksworkshop.com/docs/automation/gitops/) is a popular way to automate storage and updates to both workload and Kubernetes infrastructure resources.
The objects used to gather together and deploy Pod information is defined by one of the following deployment methods.
#### Deploying Pods
The method you would choose for deploying Pods depends on the type of application you plan to run with those Pods. Here are some of your choices:
+ **Stateless applications** — A stateless application doesn’t save a client’s session data, so another session doesn’t need to refer back to what happened to a previous session. This makes it easier to just replace Pods with new ones if they become unhealthy or move them around without saving state. If you are running a stateless application (such as a web server), you can use a [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) to deploy [Pods](https://kubernetes.io/docs/concepts/workloads/pods/)and [ReplicaSets](https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/). A ReplicaSet defines how many instances of a Pod that you want running concurrently. Although you can run a ReplicaSet directly, it is common to run replicas directly within a Deployment, to define how many replicas of a Pod should be running at a time.
+ **Stateful applications** — A stateful application is one where the identity of the Pod and the order in which Pods are launched are important. These applications need persistent storage that is stable and need to be deployed and scaled in a consistent manner. To deploy a stateful application in Kubernetes, you can use [StatefulSets](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/). An example of an application that is typically run as a StatefulSet is a database. Within a StatefulSet, you could define replicas, the Pod and its containers, storage volumes to mount, and locations in the container where data are stored. See [Run a Replicated Stateful Application](https://kubernetes.io/docs/tasks/run-application/run-replicated-stateful-application/) for an example of a database being deployed as a ReplicaSet.
+ **Per-node applications** — There are times when you want to run an application on every node in your Kubernetes cluster. For example, your data center might require that every computer run a monitoring application or a particular remote access service. For Kubernetes, you can use a [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) to ensure that the selected application runs on every node in your cluster.
+ **Applications run to completion** — There are some applications you want to run to complete a particular task. This could include one that runs monthly status reports or cleans out old data. A [Job](https://kubernetes.io/docs/concepts/workloads/controllers/job/) object can be used to set up an application to start up and run, then exit when the task is done. A [CronJob](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/) object lets you set up an application to run at a specific hour, minute, day of the month, month, or day of the week, using a structure defined by the Linux [crontab](https://man7.org/linux/man-pages/man5/crontab.5.html) format.
#### Making applications accessible from the network
With applications often deployed as a set of microservices that moved around to different places, Kubernetes needed a way for those microservices to be able to find each other. Also, for others to access an application outside of the Kubernetes cluster, Kubernetes needed a way to expose that application on outside addresses and ports. These networking-related features are done with Service and Ingress objects, respectively:
+ **Services** — Because a Pod can move around to different nodes and addresses, another Pod that needs to communicate with the first Pod could find it difficult to locate where it is. To solve this problem, Kubernetes lets you represent an application as a [Service](https://kubernetes.io/docs/concepts/services-networking/service/). With a Service, you can identify a Pod or set of Pods with a particular name, then indicate what port exposes that application’s service from the Pod and what ports another application could use to contact that service. Another Pod within a cluster can simply request a Service by name and Kubernetes will direct that request to the proper port for an instance of the Pod running that service.
+ **Ingress** — [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) is what can make applications represented by Kubernetes Services available to clients that are outside of the cluster. Basic features of Ingress include a load balancer (managed by Ingress), the Ingress controller, and rules for routing requests from the controller to the Service. There are several [Ingress Controllers](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/) that you can choose from with Kubernetes.
## Next steps
Understanding basic Kubernetes concepts and how they relate to Amazon EKS will help you navigate both the [Amazon EKS documentation](https://docs.aws.amazon.com/eks/) and [Kubernetes documentation](https://kubernetes.io/docs) to find the information you need to manage Amazon EKS clusters and deploy workloads to those clusters. To begin using Amazon EKS, choose from the following:
+ [Get started with Amazon EKS – `eksctl`](getting-started-eksctl.md)
+ [Create an Amazon EKS cluster](create-cluster.md)
+ [Deploy a sample application on Linux](sample-deployment.md)
+ [Organize and monitor cluster resources](eks-managing.md)
# Deploy Amazon EKS clusters across cloud and on-premises environments
## Understand Amazon EKS deployment options
Amazon Elastic Kubernetes Service (Amazon EKS) is a fully managed Kubernetes service that enables you to run Kubernetes seamlessly in the cloud and in your on-premises environments.
In the cloud, Amazon EKS automates Kubernetes cluster infrastructure management for the Kubernetes control plane and nodes. This is essential for scheduling containers, managing application availability, dynamically scaling resources, optimizing compute, storing cluster data, and performing other critical functions. With Amazon EKS, you get the robust performance, scalability, reliability, and availability of AWS infrastructure, along with native integrations with AWS networking, security, storage, and observability services.
To simplify running Kubernetes in your on-premises environments, you can use the same Amazon EKS clusters, features, and tools to [Create Amazon Linux nodes on AWS Outposts](eks-outposts-self-managed-nodes.md) or [Amazon EKS Hybrid Nodes](hybrid-nodes-overview.md) on your own infrastructure, or you can use [Amazon EKS Anywhere](https://anywhere.eks.amazonaws.com/) for self-contained air-gapped environments.
## Amazon EKS in the cloud
You can use Amazon EKS with compute in AWS Regions, AWS Local Zones, and AWS Wavelength Zones. With Amazon EKS in the cloud, the security, scalability, and availability of the Kubernetes control plane is fully managed by AWS in the AWS Region. When running applications with compute in AWS Regions, you get the full breadth of AWS and Amazon EKS features, including Amazon EKS Auto Mode, which fully automates Kubernetes cluster infrastructure management for compute, storage, and networking on AWS with a single click. When running applications with compute in AWS Local Zones and AWS Wavelength Zones, you can use Amazon EKS self-managed nodes to connect Amazon EC2 instances for your cluster compute and can use the other available AWS services in AWS Local Zones and AWS Wavelength Zones. For more information see [AWS Local Zones features](https://aws.amazon.com/about-aws/global-infrastructure/localzones/features/) and [AWS Wavelength Zones features](https://aws.amazon.com/wavelength/features/).
| | Amazon EKS in AWS Regions | Amazon EKS in Local/Wavelength Zones |
| --- | --- | --- |
| Kubernetes control plane management | AWS-managed | AWS-managed |
| Kubernetes control plane location | AWS Regions | AWS Regions |
| Kubernetes data plane | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/eks/latest/userguide/eks-deployment-options.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/eks/latest/userguide/eks-deployment-options.html) |
| Kubernetes data plane location | AWS Regions | AWS Local or Wavelength Zones |
## Amazon EKS in your data center or edge environments
If you need to run applications in your own data centers or edge environments, you can use [Deploy Amazon EKS on-premises with AWS Outposts](eks-outposts.md) or [Amazon EKS Hybrid Nodes](hybrid-nodes-overview.md). You can use self-managed nodes with Amazon EC2 instances on AWS Outposts for your cluster compute, or you can use Amazon EKS Hybrid Nodes with your own on-premises or edge infrastructure for your cluster compute. AWS Outposts is AWS-managed infrastructure that you run in your data centers or co-location facilities, whereas Amazon EKS Hybrid Nodes runs on your physical or virtual machines that you manage in your on-premises or edge environments. Amazon EKS on AWS Outposts and Amazon EKS Hybrid Nodes require a reliable connection from your on-premises environments to an AWS Region, and you can use the same Amazon EKS clusters, features, and tools you use to run applications in the cloud. When running on AWS Outposts, you can alternatively deploy the entire Kubernetes cluster on AWS Outposts with Amazon EKS local clusters on AWS Outposts.
| | Amazon EKS Hybrid Nodes | Amazon EKS on AWS Outposts |
| --- | --- | --- |
| Kubernetes control plane management | AWS-managed | AWS-managed |
| Kubernetes control plane location | AWS Regions | AWS Regions or AWS Outposts |
| Kubernetes data plane | Customer-managed physical or virtual machines | Amazon EC2 self-managed nodes |
| Kubernetes data plane location | Customer data center or edge environment | Customer data center or edge environment |
## Amazon EKS Anywhere for air-gapped environments
[Amazon EKS Anywhere](https://aws.amazon.com/eks/eks-anywhere/) simplifies Kubernetes cluster management through the automation of undifferentiated heavy lifting such as infrastructure setup and Kubernetes cluster lifecycle operations in on-premises and edge environments. Unlike Amazon EKS, Amazon EKS Anywhere is a customer-managed product and customers are responsible for cluster lifecycle operations and maintenance of Amazon EKS Anywhere clusters. Amazon EKS Anywhere is built on the Kubernetes sub-project Cluster API (CAPI) and supports a range of infrastructure including VMware vSphere, bare metal, Nutanix, Apache CloudStack, and AWS Snow. Amazon EKS Anywhere can be run in air-gapped environments and offers optional integrations with regional AWS services for observability and identity management. To receive support for Amazon EKS Anywhere and access to AWS-vended Kubernetes add-ons, you can purchase [Amazon EKS Anywhere Enterprise Subscriptions](https://aws.amazon.com/eks/eks-anywhere/pricing/).
| | Amazon EKS Anywhere |
| --- | --- |
| Kubernetes control plane management | Customer-managed |
| Kubernetes control plane location | Customer data center or edge environment |
| Kubernetes data plane | Customer-managed physical or virtual machines |
| Kubernetes data plane location | Customer data center or edge environment |
## Amazon EKS tooling
You can use the [Amazon EKS Connector](eks-connector.md) to register and connect any conformant Kubernetes cluster to AWS and view it in the Amazon EKS console. After a cluster is connected, you can see the status, configuration, and workloads for that cluster in the Amazon EKS console. You can use this feature to view connected clusters in Amazon EKS console, but the Amazon EKS Connector does not enable management or mutating operations for your connected clusters through the Amazon EKS console.
[Amazon EKS Distro](https://aws.amazon.com/eks/eks-distro/) is the AWS distribution of the underlying Kubernetes components that power all Amazon EKS offerings. It includes the core components required for a functioning Kubernetes cluster such as Kubernetes control plane components (etcd, kube-apiserver, kube-scheduler, kube-controller-manager) and networking components (CoreDNS, kube-proxy, CNI plugins). Amazon EKS Distro can be used to self-manage Kubernetes clusters with your choice of tooling. Amazon EKS Distro deployments are not covered by AWS Support Plans.