Study guide
Technical reference and lesson notes
Deploying and Scaling Amazon EKS Clusters with eksctl and kubectl
Purpose of This Lesson
This lesson demonstrates an end-to-end Amazon Elastic Kubernetes Service (Amazon EKS) workflow:
- Install the Kubernetes and EKS administration tools.
- Provision an EKS cluster and managed node group with
eksctl. - Deploy multiple replicas of an NGINX container using a Kubernetes Deployment.
- Expose the application through a Kubernetes LoadBalancer service.
- Configure a Horizontal Pod Autoscaler (HPA).
- Grant an AWS IAM identity permission to interact with Kubernetes through a configuration map.
For CloudOps assessment preparation, the important skill is recognizing which tool or Kubernetes object belongs at each stage of the workflow.
Key Concepts
kubectl and eksctl
kubectl is the primary command-line client for interacting with resources inside a Kubernetes cluster. It can apply YAML manifests, inspect services, and work with Kubernetes configuration and access settings.
eksctl is used to create and manage Amazon EKS clusters. In the demonstrated workflow, it provisions the cluster and node group and launches AWS CloudFormation to create the required infrastructure.
These tools have different scopes:
| Tool | Primary responsibility |
|---|---|
eksctl | Provision and manage the EKS cluster infrastructure and node groups |
kubectl | Deploy and manage Kubernetes resources running in the cluster |
Kubernetes Deployment
A Deployment describes a desired set of application resources and keeps the declared number of pod replicas running. The lesson uses a YAML manifest to deploy up to three copies of an NGINX web server container.
The normal workflow is to create or edit the manifest and then apply it to the cluster with kubectl.
Kubernetes LoadBalancer Service
A Kubernetes Service provides stable access to an application. The LoadBalancer service type requests an externally reachable load balancer. After the service is created, inspecting its details shows the load balancer and its public address, which can be entered in a browser to reach the NGINX application.
The service provides an external-facing access point while the cluster and workloads also have internal networking identities.
Horizontal Pod Autoscaler
A Horizontal Pod Autoscaler scales the number of pod replicas for a workload based on its configured autoscaling behavior. In this lesson, the HPA is configured to scale the NGINX Deployment between three and ten replicas.
The HPA changes the number of application pods; it is distinct from scaling the underlying cluster nodes.
Kubernetes Access Through an IAM Identity
The lesson also demonstrates granting an AWS IAM user the ability to interact with Kubernetes. The workflow retrieves the relevant Kubernetes configuration map, exports it to YAML, edits the user identity data, and applies the updated configuration back to the cluster.
The new entry includes the IAM user’s Amazon Resource Name (ARN) and username. After the updated permissions are applied, the demonstration demo-admin user has complete privileges within the system.
EKS Deployment and Scaling Workflow
1. Install the administration tools
The environment first installs kubectl, which is needed to communicate with Kubernetes resources inside EKS. The EKS administration tool is then downloaded for the identified AMD64 architecture, unzipped, checksum-verified, and placed in the appropriate location.
The installation steps are collected in an executable shell script named eks-control.sh. The script downloads the required files, copies them into place, removes the initial archive, and is then executed.
Checksum verification is an important operational safeguard: it confirms that the downloaded tool matches the expected package before installation.
2. Provision the EKS cluster
The example creates a cluster named my-eks-cluster in us-east-1 with the following node-group settings:
- Node group:
my-node-group - Instance type:
t2.small - Initial node count: 3
- Minimum node count: 1
- Maximum node count: 5
eksctl invokes CloudFormation to provision the AWS resources required for the architecture. This illustrates that a high-level EKS provisioning command can orchestrate infrastructure creation through CloudFormation.
3. Deploy the application
A YAML manifest defines a Kubernetes Deployment for NGINX with as many as three application replicas. Applying the manifest makes the desired state known to the Kubernetes control plane.
The Deployment is the appropriate object for managing a replicated application workload. It is not the object that provides public network access; that responsibility belongs to the Service.
4. Expose the application
A LoadBalancer Service named my-service is created for the application. Inspecting the service confirms whether a load balancer was provisioned and provides its public address.
Once the address is available, a browser request to that endpoint reaches an NGINX container. This validates both the application deployment and the external service path.
5. Configure pod autoscaling
An HPA manifest is created and applied for the NGINX Deployment. The configured replica range is:
- Minimum: 3 replicas
- Maximum: 10 replicas
This setting allows Kubernetes to adjust the number of NGINX pods while keeping the workload within the declared lower and upper bounds.
6. Grant Kubernetes access to an IAM user
The access-control workflow uses a Kubernetes configuration map containing user identity settings. The map is retrieved, exported to YAML, edited to add the IAM user’s ARN and username, and then applied back to the cluster.
This is a separate concern from application deployment and autoscaling. A user may have AWS identity credentials but still require the appropriate Kubernetes-side mapping and privileges to interact with cluster resources.
Exam- or Assessment-Relevant Takeaways
- Choose
eksctlwhen the task is to provision or configure the EKS cluster and its node group. - Choose
kubectlwhen the task is to apply Kubernetes YAML, inspect services, configure workloads, or manage Kubernetes-side access settings. - Recognize CloudFormation as the infrastructure provisioning engine launched by the demonstrated
eksctlworkflow. - A Deployment manages a replicated application workload; it does not itself expose the workload publicly.
- A
LoadBalancerService provides an externally reachable endpoint for the application. - An HPA scales pod replicas, with the demonstrated range set from 3 to 10; it is not the same as scaling the EC2 worker nodes.
- The cluster’s node-group scaling range in the example is 1 to 5 nodes, while the application’s HPA range is 3 to 10 pods. These are separate scaling layers.
- Kubernetes access for an IAM identity requires the relevant identity data to be added to the cluster’s configuration map and applied.
- Verify downloaded administration tools with their checksums before placing them into the execution path.
Tool / Feature Decision Guide
| Requirement | Appropriate tool or feature | Reason |
|---|---|---|
| Provision an EKS cluster and node group | eksctl | It creates the EKS environment and invokes CloudFormation for supporting infrastructure |
| Install or use the Kubernetes client | kubectl | It communicates with Kubernetes resources inside the cluster |
| Define and maintain replicated application pods | Kubernetes Deployment | It declares the desired application replica state |
| Make the application reachable from outside the cluster | LoadBalancer Service | It provides a public load balancer endpoint |
| Adjust the number of application pods | Horizontal Pod Autoscaler | It scales pod replicas between configured minimum and maximum values |
| Allow an IAM user to interact with Kubernetes | Kubernetes identity configuration map | It maps the IAM identity and username into the cluster’s access configuration |
Common Traps / Misconceptions
- Confusing
eksctlwithkubectl:eksctlprovisions the EKS environment;kubectlmanages Kubernetes resources after the cluster is available. - Treating a Deployment as an endpoint: A Deployment manages pods, but a Service is needed to provide stable or external access.
- Confusing pod and node scaling: The HPA changes the number of application replicas. The node group’s minimum and maximum values govern the worker-node layer.
- Assuming an IAM identity automatically has Kubernetes privileges: The demonstrated workflow adds the IAM ARN and username to Kubernetes access configuration before applying permissions.
- Skipping checksum verification: Installing a downloaded administration tool without verifying its checksum removes an important integrity check.
- Mixing the two replica ranges: The initial Deployment uses up to three NGINX copies, while the HPA is configured for a minimum of three and a maximum of ten replicas.
- Assuming a public address appears immediately: The LoadBalancer Service must be inspected to confirm that the load balancer and public address are available.
Real-World Engineer / Analyst Notes
- Keep cluster provisioning and workload deployment conceptually separate. Infrastructure creation may be orchestrated through CloudFormation, while application state is declared through Kubernetes YAML.
- Treat YAML manifests as version-controlled desired state. This makes deployment, review, and rollback workflows easier to manage than ad hoc command sequences.
- When troubleshooting external access, inspect the Service and its load balancer details separately from the Deployment and its pods.
- When troubleshooting scaling, first determine whether the issue concerns pod replicas or insufficient worker-node capacity. The HPA and node-group limits operate at different layers.
- Access changes should be reviewed carefully. Adding a user with complete privileges is a high-impact administrative action and should be limited to identities that require it.
- Tool installation scripts are convenient, but they should preserve architecture awareness and checksum verification rather than blindly downloading binaries.
Quick Reference Summary
- Install
kubectlfor Kubernetes operations and the EKS administration tool for cluster provisioning. - Use
eksctlto createmy-eks-clusterinus-east-1withmy-node-group, three initialt2.smallnodes, and a 1-to-5 node range. - Use a Kubernetes Deployment YAML manifest to run replicated NGINX containers.
- Apply manifests with
kubectl. - Use a
LoadBalancerService namedmy-serviceto obtain a public application endpoint. - Use an HPA to scale the NGINX Deployment between three and ten pods.
- Update the Kubernetes access configuration map with the IAM user’s ARN and username, then apply the change to grant access.
Flashcards
Q: You need to provision an Amazon EKS cluster, its node group, and the supporting AWS infrastructure. Which tool should you choose?
A: Choose eksctl. In the demonstrated workflow, it creates the EKS environment and launches CloudFormation to provision the required resources.
Q: When should you use kubectl instead of eksctl?
A: Use kubectl for Kubernetes-side operations such as applying YAML manifests, inspecting Services, configuring autoscaling, and managing Kubernetes access settings.
Q: What does the Kubernetes Deployment in this workflow manage?
A: It manages the desired collection of NGINX application replicas and keeps the workload aligned with the declared state.
Q: An NGINX Deployment is running, but users outside the cluster need a reachable endpoint. What should you add?
A: Add a Kubernetes Service using the LoadBalancer type. It requests an external load balancer and exposes a public address for the application.
Q: What is the difference between the example node-group limits and HPA limits?
A: The node group can range from 1 to 5 worker nodes, while the HPA can range from 3 to 10 application pods. They scale different layers of the system.
Q: What HPA replica range is configured for the NGINX workload?
A: The HPA is configured for a minimum of 3 replicas and a maximum of 10 replicas.
Q: Why inspect the LoadBalancer Service after applying its YAML manifest?
A: Inspection confirms that the load balancer exists and reveals its public address, which can be used to test external access to the application.
Q: What AWS service is launched by eksctl during the demonstrated cluster-creation process?
A: CloudFormation is launched to bring the AWS resources required for the EKS architecture into existence.
Q: What information is added when mapping an IAM user into Kubernetes access configuration?
A: The configuration includes the IAM user’s Amazon Resource Name and username, after which the updated configuration is applied to the cluster.
Q: An IAM user has AWS credentials but cannot perform the required Kubernetes operations. What is the likely issue highlighted by this lesson?
A: The IAM identity may not yet be mapped into the cluster’s Kubernetes access configuration with the needed privileges.
Q: Why verify the checksum of a downloaded EKS administration tool?
A: Checksum verification confirms the downloaded file matches the expected content before it is installed and executed.
Q: What is the functional difference between a Deployment and a LoadBalancer Service?
A: A Deployment manages application pods and replicas; a LoadBalancer Service provides network access to the application, including an external endpoint in this example.
Practice Questions
Question 1
An operator must create an EKS cluster in us-east-1 with a node group and have AWS resources provisioned automatically. Which approach best matches the demonstrated workflow?
A. Create only a Kubernetes Deployment with kubectl
B. Use eksctl, which invokes CloudFormation
C. Create an HPA and wait for nodes to appear
D. Create a LoadBalancer Service before creating the cluster
Correct answer: B
Explanation: eksctl provisions the EKS cluster and node group, and the demonstrated process uses CloudFormation for the underlying AWS resources.
Question 2
A three-replica NGINX Deployment is healthy, but no public address is available for clients outside the cluster. What is the most appropriate next step?
A. Increase the HPA maximum to ten replicas
B. Change the EC2 instance type to t2.small
C. Create a LoadBalancer Service and inspect its details
D. Edit the IAM user’s username
Correct answer: C
Explanation: The Deployment manages pods but does not expose them externally. A LoadBalancer Service provides the external load balancer and public address.
Question 3
An application should maintain between three and ten pod replicas as its scaling configuration changes. Which Kubernetes feature should be applied?
A. A node group
B. A LoadBalancer Service
C. A Kubernetes access configuration map
D. A Horizontal Pod Autoscaler
Correct answer: D
Explanation: The HPA controls the number of application pod replicas within configured minimum and maximum values.
Question 4
A user can authenticate to AWS but cannot use the required Kubernetes operations in the EKS cluster. The user’s ARN and username are not present in the cluster access configuration. What should the operator do?
A. Add the identity data to the Kubernetes configuration map and apply the updated YAML
B. Increase the node group from three to five nodes
C. Create another NGINX Deployment
D. Replace the LoadBalancer Service with an HPA
Correct answer: A
Explanation: The lesson’s access workflow retrieves the configuration map, adds the IAM ARN and username, and applies the updated permissions to the cluster.
WordPress Metadata
Suggested Slug:
deploying-scaling-amazon-eks-clusters-eksctl-kubectl
Meta Description:
Study guide to provisioning an Amazon EKS cluster, deploying an NGINX workload, exposing it through a load balancer, configuring horizontal pod autoscaling, and granting Kubernetes user access.
Tags:
Amazon EKS, eksctl, kubectl, Kubernetes, CloudFormation, Kubernetes Deployments, Horizontal Pod Autoscaler, Kubernetes RBAC, Load Balancers, AWS IAM