# EKS: Advance

# **Agenda of the Day**

* Understanding Load Balancers in EKS: Application vs. Network Load Balancers
* EKS Load Balancer Controller: Managing External and Internal Traffic
* Kubernetes Metrics Server: Why It’s Essential for HPA (Horizontal Pod Autoscaler)
* Autoscaling in EKS: Vertical, Horizontal, and Cluster Node Autoscaling Explained
* Monitoring EKS Clusters: Tools, Best Practices, and Performance Optimization

---

# Understanding Load Balancers in EKS: Application vs. Network Load Balancers

## What is a Load Balancer in EKS?
In Amazon EKS, a **Load Balancer** distributes incoming traffic across multiple Pods running inside the cluster. It ensures **high availability, scalability, and fault tolerance** for Kubernetes applications.

EKS primarily supports two types of AWS-managed Load Balancers:

1. **Application Load Balancer (ALB)** – Works at the **HTTP/HTTPS (Layer 7)** level.
2. **Network Load Balancer (NLB)** – Works at the **TCP/UDP (Layer 4)** level.

---

## Application Load Balancer (ALB) in EKS

### **How ALB Works**
- Operates at **Layer 7 (Application Layer)** and routes traffic based on **hostnames, paths, and headers**.
- Best suited for **HTTP/HTTPS-based applications**, such as websites and REST APIs.
- Supports **sticky sessions, SSL termination, and WebSockets**.

### **Use Cases**
* Hosting **multiple applications** under a single ALB using **path-based or host-based routing**.
* Secure traffic management with **SSL termination** (HTTPS).
* Load balancing for **microservices and API gateways**.

### **Key Features**
* **Path-based Routing** – Route requests based on URL paths (e.g., `/api`, `/user`).
* **Host-based Routing** – Route traffic based on domain names (e.g., `app.example.com`).
* **SSL Termination** – Offloads HTTPS processing to ALB, reducing Pod CPU usage.

---

## Network Load Balancer (NLB) in EKS

### **How NLB Works**
- Operates at **Layer 4 (Transport Layer)** and forwards raw TCP/UDP traffic to Pods.
- Designed for **high-performance, low-latency applications**.
- Can handle **millions of requests per second**.

### **Use Cases**
* **gRPC-based applications** that require low latency.
* **TCP/UDP-based services** such as gaming servers and databases.
* **Handling large volumes of traffic** with ultra-low latency.

### **Key Features**
* **Static IP Support** – Each NLB gets a fixed Elastic IP for consistent traffic routing.
* **Preserves Client IP** – Allows backend services to see the original client IP.
* **Handles High Throughput** – Ideal for applications needing fast and reliable networking.

---

## ALB vs. NLB: When to Use What?

| Feature | Application Load Balancer (ALB) | Network Load Balancer (NLB) |
|----------------------|--------------------------------|----------------------------|
| Layer | **7 (Application Layer)** | **4 (Transport Layer)** |
| Protocols Supported | **HTTP, HTTPS, WebSockets** | **TCP, UDP, TLS** |
| Routing Type | **Path-based, Host-based** | **Direct traffic forwarding** |
| Use Case | **Web apps, APIs, microservices** | **gRPC, databases, gaming servers** |
| Latency | **Higher (due to HTTP processing)** | **Ultra-low latency** |
| SSL Termination | **Yes** | **No** |
| Preserves Client IP | **No** | **Yes** |

---

## Choosing the Right Load Balancer in EKS

* **Use ALB if:**
1. You need **path-based or host-based routing**.
2. Your application runs over **HTTP/HTTPS**.
3. You require **SSL termination** at the load balancer level.

* **Use NLB if:**
1. Your application requires **low latency and high performance**.
2. You need to handle **TCP/UDP traffic** (e.g., gaming, databases).
3. You want to **preserve the original client IP**.

---

# EKS Load Balancer Controller: Managing External and Internal Traffic

## What is the EKS Load Balancer Controller?
The **AWS Load Balancer Controller** is a Kubernetes controller that automatically provisions **Application Load Balancers (ALB) and Network Load Balancers (NLB)** for services running in an Amazon EKS cluster.

It replaces the legacy **AWS Ingress Controller** and provides enhanced capabilities for managing external and internal traffic.

---

## Managing **External Traffic** in EKS

### What is External Traffic?
External traffic refers to requests coming from the **internet (public users)** that need to reach applications inside the Kubernetes cluster.

### How External Traffic is Handled
1. **ALB (Application Load Balancer) for Ingress Traffic** – Routes HTTP/HTTPS traffic from external users to backend services inside the cluster.
2. **NLB (Network Load Balancer) for Low-Latency Applications** – Directs external TCP/UDP traffic efficiently to backend services.

### Key Considerations for External Traffic
- The ALB/NLB must have a **public-facing IP address**.
- Security Groups and IAM roles must be properly configured.
- The Load Balancer Controller should be deployed in the cluster to manage routing.

---

## Managing **Internal Traffic** in EKS

### What is Internal Traffic?
Internal traffic is communication that happens **within AWS infrastructure**, such as:
* Traffic between **different microservices inside the cluster**.
* Access to backend services like databases, caches, and internal APIs.
* Requests from private VPCs or corporate networks (VPN, Direct Connect).

### How Internal Traffic is Handled
1. **Internal ALB (Application Load Balancer)** – Used for **internal Ingress**, ensuring private access to services.
2. **Internal NLB (Network Load Balancer)** – Used for high-throughput internal communication, such as database or gRPC connections.

### Key Considerations for Internal Traffic
- The ALB/NLB must be set to **internal mode** so it is only accessible within the VPC.
- Services should be deployed using **private subnets** for security.
- Route 53 can be used for **private DNS resolution** within the VPC.

---

## Differences: External vs. Internal Traffic in EKS

| Feature | External Traffic (Internet-Facing) | Internal Traffic (Private Network) |
|--------------------|----------------------------------|--------------------------------|
| Load Balancer Type | **Public ALB/NLB** | **Internal ALB/NLB** |
| Accessibility | Available over the **internet** | Only accessible **within the VPC** |
| Use Case | **Websites, APIs, External Apps** | **Internal microservices, databases** |
| Security | Requires **public-facing security rules** | Restricted to **private networks** |
| Subnet Placement | **Public subnets** | **Private subnets** |

---

## When to Use the AWS Load Balancer Controller?

1. You need **automated load balancer provisioning** for Kubernetes services.
2. You are running **public-facing applications** that require secure **external traffic routing**.
3. You have **internal microservices** that need private, **internal traffic management**.
4. You want to leverage **AWS networking best practices** to optimize Kubernetes performance.

---

# Kubernetes Metrics Server: Why It’s Essential for HPA (Horizontal Pod Autoscaler)

## Understanding Metrics Server in Kubernetes

### **What is Metrics Server?**
- Metrics Server is a **lightweight, cluster-wide aggregator of resource usage data** in Kubernetes.
- It collects **CPU and memory (RAM) usage** metrics from the **Kubelets** running on each node.
- Metrics Server provides this data to Kubernetes **API Server**, making it available for features like **Horizontal Pod Autoscaler (HPA)** and the `kubectl top` command.

## What is the Kubernetes Metrics Server?
The **Kubernetes Metrics Server** is a lightweight, scalable **aggregator of resource usage data** in a Kubernetes cluster. It provides **real-time CPU and memory usage metrics** for Pods and Nodes.

It is essential for **autoscaling**, as it supplies the data needed for Kubernetes **Horizontal Pod Autoscaler (HPA)** and **Vertical Pod Autoscaler (VPA)** to make scaling decisions.

---

## Why is the Metrics Server Important?

* **Enables HPA to scale Pods based on CPU & memory usage**.
* **Provides real-time resource utilization** for monitoring.
* **Lightweight and optimized for Kubernetes clusters**.
* **Works as a central metrics provider** for other Kubernetes components.

Without the Metrics Server, **HPA cannot retrieve CPU/memory metrics**, and autoscaling will not function properly.

---

## How Does the Metrics Server Work?

1. **Collects resource usage data** from each node in the cluster using the Kubernetes API.
2. **Aggregates CPU and memory metrics** for running Pods and Nodes.
3. **Exposes metrics through the Kubernetes API**, which HPA queries for scaling decisions.
4. **Continuously updates** resource usage data for real-time autoscaling.

---

## Role of Metrics Server in HPA (Horizontal Pod Autoscaler)

### What is HPA?
The **Horizontal Pod Autoscaler (HPA)** automatically increases or decreases the number of **replica Pods** in a Deployment or StatefulSet **based on CPU or memory usage**.

### How Metrics Server Helps HPA
* HPA queries the Metrics Server for **CPU and memory utilization** of running Pods.
* Based on the configured threshold, HPA **adds or removes** Pods to maintain performance.
* Without the Metrics Server, HPA **cannot retrieve real-time metrics** and **autoscaling will fail**.

### Example Use Case
- You have a web application receiving **spiky traffic** during peak hours.
- The **Metrics Server collects CPU usage data** from running Pods.
- If CPU usage crosses the defined threshold (e.g., 80%), **HPA automatically scales out more Pods**.
- When traffic reduces, **HPA scales Pods back down**, optimizing resource utilization.

---

## Metrics Server vs. Prometheus: What’s the Difference?

| Feature | Metrics Server | Prometheus |
|--------------------|---------------|-----------|
| Purpose | Provides **real-time CPU & memory metrics** for autoscaling | **Time-series monitoring and alerting** |
| Used By | **HPA, VPA, Kubectl top commands** | **Grafana, Alertmanager, custom dashboards** |
| Storage Type | **Does not store historical data** | **Stores long-term historical metrics** |
| Scalability | **Lightweight, cluster-wide** | **More complex, requires setup** |
| Installation Complexity | **Easy** | **Requires more configuration** |

---

## When Do You Need the Metrics Server?

* If you use **HPA for automatic Pod scaling**.
* If you want to **monitor real-time CPU and memory usage** of Pods/Nodes.
* If you need a **lightweight solution** without long-term metric storage.
* If you rely on `kubectl top` commands to check cluster health.

❌ If you need **detailed historical monitoring, custom dashboards, and alerts**, use **Prometheus** instead.

---

# Autoscaling in EKS: Vertical, Horizontal, and Cluster Node Autoscaling Explained

## What is Autoscaling in EKS?
Autoscaling in Amazon EKS ensures that applications and the underlying infrastructure **automatically scale up or down** based on resource demand. This helps in **optimizing performance and cost-efficiency**.

Kubernetes provides three types of autoscaling mechanisms:

1. **Horizontal Pod Autoscaler (HPA)** – Adjusts the number of Pods.
2. **Vertical Pod Autoscaler (VPA)** – Adjusts CPU & memory of individual Pods.
3. **Cluster Autoscaler (CA)** – Adjusts the number of worker nodes in the cluster.

---

## Horizontal Pod Autoscaler (HPA)

### **What is HPA?**
The **Horizontal Pod Autoscaler (HPA)** automatically **increases or decreases the number of Pods** in a Deployment, StatefulSet, or ReplicaSet based on CPU or memory utilization.

### **How HPA Works**
* Continuously **monitors resource utilization** using the **Metrics Server**.
* If CPU/memory usage **exceeds the threshold**, HPA **scales out** (adds more Pods).
* If resource usage **drops**, HPA **scales in** (removes Pods) to save costs.

### **Example Use Case**
- A web application experiences **high traffic surges** during peak hours.
- HPA detects that **CPU usage exceeds 80%** and **adds more Pods**.
- When traffic reduces, **HPA scales down the Pods** automatically.

### **Key Considerations**
- **Requires the Metrics Server** to collect CPU and memory data.
- Works well for **stateless applications** (e.g., web servers, APIs).
- Does **not** work well for stateful applications (e.g., databases).

---

## Vertical Pod Autoscaler (VPA)

### **What is VPA?**
The **Vertical Pod Autoscaler (VPA)** automatically **adjusts CPU and memory requests/limits** for Pods based on real-time resource usage.

### **How VPA Works**
* Monitors **historical and real-time resource usage** of Pods.
* If a Pod needs **more CPU/memory**, VPA **increases** its resource limits.
* If a Pod is **over-provisioned**, VPA **reduces** its resource limits to save costs.

### **Example Use Case**
- A **batch processing job** runs on a fixed number of Pods but sometimes needs more CPU.
- VPA automatically **increases CPU requests**, ensuring smooth performance.
- When resource demand reduces, VPA **lowers CPU/memory requests**.

### **Key Considerations**
- Works well for **stateful applications** like databases and ML workloads.
- Requires **Pod restarts** to apply new CPU/memory values.
- Should **not** be used with HPA (conflicts in scaling logic).

---

## Cluster Autoscaler (CA)

### **What is Cluster Autoscaler?**
The **Cluster Autoscaler (CA)** automatically **adds or removes worker nodes** in an Amazon EKS cluster based on Pod scheduling needs.

### **How CA Works**
* Checks if any Pods **are stuck in a Pending state** due to lack of node resources.
* If needed, CA **adds new EC2 worker nodes** to accommodate the workload.
* If node usage drops, CA **removes underutilized nodes** to reduce costs.

### **Example Use Case**
- An application scales up using HPA, but the cluster runs out of available nodes.
- The Cluster Autoscaler **provisions additional worker nodes** to schedule the new Pods.
- When demand drops, **extra nodes are removed** to optimize costs.

### **Key Considerations**
- Works with **Amazon EC2 Auto Scaling Groups**.
- Only scales nodes if **Pods cannot be scheduled** due to lack of resources.
- Prevents **over-provisioning** by removing underutilized nodes.

---

## Comparing HPA, VPA, and Cluster Autoscaler

| Feature | HPA (Horizontal Pod Autoscaler) | VPA (Vertical Pod Autoscaler) | CA (Cluster Autoscaler) |
|--------------------|--------------------------------|------------------------------|--------------------------|
| Scaling Type | **Scales Pods (replicas count)** | **Adjusts CPU & memory for Pods** | **Adds or removes worker nodes** |
| Based On | **CPU/memory usage** from Metrics Server | **Historical CPU/memory data** | **Pending Pods (scheduling issues)** |
| Best For | **Web apps, APIs, microservices** | **Databases, batch jobs, ML workloads** | **Clusters with dynamic workloads** |
| Works With | **Cluster Autoscaler** | **Cluster Autoscaler** | **HPA & VPA** |
| Requires Restart? | **No** | **Yes** (Pods restart) | **No** |

---

## When to Use Each Autoscaler?

**Use HPA if:**
* You have **stateless applications** (e.g., web apps, APIs).
* You need to **automatically add/remove Pods** based on traffic spikes.

**Use VPA if:**
* Your application has **fixed Pod counts** but needs **dynamic resource allocation**.
* You are running **stateful workloads** like databases or ML models.

**Use Cluster Autoscaler if:**
* Your Pods are stuck in a **Pending state due to lack of resources**.
* You want to **automatically add/remove EC2 instances** based on cluster demand.

---

# Monitoring EKS Clusters: Tools, Best Practices, and Performance Optimization

## Why is Monitoring Important in EKS?
Monitoring an Amazon EKS (Elastic Kubernetes Service) cluster is essential for ensuring **performance, availability, and cost efficiency**. Without proper monitoring, issues like **Pod failures, resource bottlenecks, and security threats** can go unnoticed, leading to application downtime and inefficiencies.

### Key Objectives of Monitoring:
* **Track cluster health** (Nodes, Pods, and Services).
* **Optimize resource usage** (CPU, Memory, Storage).
* **Detect and resolve issues** before they impact users.
* **Ensure security compliance** and threat detection.

---

## Essential Monitoring Tools for EKS

Amazon EKS provides **native and third-party tools** for monitoring.

### **AWS Native Monitoring Tools**

**Amazon CloudWatch**
- **Logs and metrics collection** for Kubernetes components.
- Monitors **CPU, memory, disk usage, and network performance**.
- Helps in setting up **alerts and dashboards**.

**AWS X-Ray**
- Traces requests **across microservices** in an EKS cluster.
- Helps diagnose **latency issues** and bottlenecks.

**Amazon Managed Prometheus**
- Fully managed **Prometheus-compatible monitoring** for EKS.
- Collects **Kubernetes performance metrics** at scale.

**AWS CloudTrail**
- Logs **API calls** and activities within the EKS cluster.
- Useful for **security audits** and compliance tracking.

---

### **Open-Source & Third-Party Monitoring Tools**

**Prometheus**
- The most popular **Kubernetes-native monitoring system**.
- Collects **time-series metrics** from Nodes, Pods, and Services.

**Grafana**
- Provides **interactive dashboards** for EKS monitoring.
- Integrates with **Prometheus, CloudWatch, and Loki**.

**Loki**
- **Log aggregation system** designed for Kubernetes.
- Works seamlessly with **Grafana dashboards**.

**Fluent Bit / Fluentd**
- Collects and **forwards logs** from EKS Pods and Nodes.
- Works with **CloudWatch, Elasticsearch, and Loki**.

---

## Best Practices for Monitoring EKS Clusters

### **1. Monitor Cluster Health and Resource Utilization**
* Use **CloudWatch or Prometheus** to monitor CPU, memory, and disk usage.
* Identify **over-provisioned or underutilized** resources.
* Set up **alerts** for **Node failures, Pod restarts, and high resource consumption**.

### **2. Collect and Analyze Logs Efficiently**
* Enable **CloudWatch Container Insights** for automatic log collection.
* Use **Fluent Bit or Fluentd** to centralize logs from EKS workloads.
* Store logs in **Amazon S3 or Elasticsearch** for long-term analysis.

### **3. Implement Request Tracing for Microservices**
* Use **AWS X-Ray** or **Jaeger** for tracing requests across services.
* Identify **slow API calls** and latency bottlenecks in the application.

### **4. Automate Alerts and Notifications**
* Use **Amazon CloudWatch Alarms** for real-time alerts.
* Set up notifications with **Amazon SNS (Simple Notification Service)**.
* Integrate alerts with **Slack, PagerDuty, or email** for incident response.

### **5. Optimize Costs with Efficient Monitoring**
* Avoid **storing excessive logs**—filter logs before storage.
* Use **sampled metrics collection** instead of collecting everything.
* Analyze **CloudWatch billing metrics** to optimize log retention costs.

---

## Performance Optimization Strategies for EKS

### **1. Optimize Pod Scheduling**
* Use **Cluster Autoscaler** to ensure Nodes are efficiently utilized.
* Implement **Taints and Tolerations** to schedule workloads effectively.

### **2. Improve Network Performance**
* Use **Amazon VPC CNI (Container Network Interface)** for optimized networking.
* Enable **AWS App Mesh** for microservices traffic control.
* Monitor **network latency** using CloudWatch metrics.

### **3. Fine-Tune Kubernetes Resources**
* Set **Resource Requests & Limits** for CPU and memory in Deployments.
* Use **HPA (Horizontal Pod Autoscaler)** to auto-scale Pods based on usage.
* Enable **VPA (Vertical Pod Autoscaler)** for dynamic resource allocation.

### **4. Secure the EKS Cluster**
* Enable **AWS IAM roles for service accounts** to manage access securely.
* Use **Kubernetes Network Policies** to restrict inter-Pod communication.
* Monitor **audit logs with CloudTrail** for security events.

---

## Comparing EKS Monitoring Tools

## Observability Tools Comparison Table

| Feature | Amazon CloudWatch | Prometheus | Grafana | Fluent Bit | AWS X-Ray |
|--------------------------|-------------------|------------|---------|------------|-----------|
| Metric Collection | Yes | Yes | No | No | No |
| Log Aggregation | Yes | No | No | Yes | No |
| Tracing Requests | No | No | No | No | Yes |
| Visualization & Dashboards| Yes | Yes | Yes | No | Yes |
| Best Use Case | Native AWS monitoring | Kubernetes performance tracking | Custom dashboards | Log processing | Tracing microservices |
---

## Summary: How to Effectively Monitor EKS?

* **Use Prometheus & CloudWatch** for real-time metrics.
* **Set up Grafana dashboards** to visualize cluster health.
* **Centralize logs** with Fluent Bit and CloudWatch Logs.
* **Enable tracing with AWS X-Ray** for microservices observability.
* **Implement alerts & notifications** for proactive monitoring.

---

# Wrap-Up and Q&A:

### Understanding Load Balancers in EKS: Application vs. Network Load Balancers
Application Load Balancers (ALB) are ideal for **HTTP/HTTPS-based traffic** with advanced routing, while Network Load Balancers (NLB) provide **low-latency, high-performance** traffic handling at Layer 4. Choosing the right load balancer ensures **optimal application performance and availability** based on workload requirements.

### EKS Load Balancer Controller: Managing External and Internal Traffic
The EKS Load Balancer Controller enables **seamless management of both external and internal traffic** by automating ALB and NLB provisioning for Kubernetes services. Properly configuring this controller ensures **secure, scalable, and efficient traffic distribution** across your EKS workloads.

### Kubernetes Metrics Server: Why It’s Essential for HPA (Horizontal Pod Autoscaler)
The Kubernetes Metrics Server is critical for **enabling Horizontal Pod Autoscaler (HPA)** by providing real-time CPU and memory usage data. Without it, Kubernetes cannot automatically adjust Pod replicas, leading to **inefficient resource utilization and potential service disruptions**.

### Autoscaling in EKS: Vertical, Horizontal, and Cluster Node Autoscaling Explained
EKS supports **multi-layered autoscaling**—HPA scales Pods dynamically, VPA optimizes resource requests, and Cluster Autoscaler adjusts worker nodes based on demand. Implementing the right combination ensures **cost efficiency, high availability, and workload adaptability** in a dynamic cloud environment.

### Monitoring EKS Clusters: Tools, Best Practices, and Performance Optimization
Effective EKS monitoring combines **metrics, logs, and tracing tools** like Prometheus, CloudWatch, and AWS X-Ray to detect performance issues proactively. By setting up **automated alerts and dashboards**, teams can ensure **optimized cluster performance, security, and cost efficiency**.

# Multiple Choice Questions (MCQs)

## Understanding Load Balancers in EKS: Application vs. Network Load Balancers

**1. Which load balancer should you use for path-based or host-based routing in EKS?**
- A) Network Load Balancer (NLB)
- B) Classic Load Balancer (CLB)
- C) Application Load Balancer (ALB)
- D) Gateway Load Balancer (GLB)

**Answer:** C) Application Load Balancer (ALB)

**2. What is the primary advantage of using a Network Load Balancer (NLB)?**
- A) Handles only HTTP/HTTPS traffic
- B) Provides ultra-low latency and high-performance TCP/UDP traffic handling
- C) Supports advanced routing features like path-based routing
- D) Requires manual scaling of backend instances

**Answer:** B) Provides ultra-low latency and high-performance TCP/UDP traffic handling

**3. When should you choose an ALB over an NLB in EKS?**
- A) When you need a load balancer that supports TCP/UDP traffic
- B) When you need Layer 7 routing for web applications
- C) When you need the fastest possible network performance
- D) When the application runs only on private subnets

**Answer:** B) When you need Layer 7 routing for web applications

---

## EKS Load Balancer Controller: Managing External and Internal Traffic

**4. What is the primary role of the EKS Load Balancer Controller?**
- A) Manually provisions AWS Load Balancers
- B) Automatically manages ALB and NLB for Kubernetes Services
- C) Controls the security of Amazon RDS instances
- D) Replaces the Kubernetes Ingress Controller

**Answer:** B) Automatically manages ALB and NLB for Kubernetes Services

**5. How can you ensure that an ALB created by the Load Balancer Controller is internal-only?**
- A) Attach an IAM role that restricts internet access
- B) Set the `alb.ingress.kubernetes.io/scheme: internal` annotation in the Ingress resource
- C) Modify the security group to allow only internal traffic
- D) Deploy it in a public subnet

**Answer:** B) Set the `alb.ingress.kubernetes.io/scheme: internal` annotation in the Ingress resource

**6. Which AWS resource is required for the EKS Load Balancer Controller to function?**
- A) IAM roles with necessary permissions
- B) Amazon RDS instance
- C) AWS Lambda functions
- D) Amazon CloudFront

**Answer:** A) IAM roles with necessary permissions

---

## Kubernetes Metrics Server: Why It’s Essential for HPA (Horizontal Pod Autoscaler)

**7. What is the function of the Kubernetes Metrics Server?**
- A) Stores long-term logs for Kubernetes applications
- B) Provides real-time monitoring for CloudWatch
- C) Collects CPU and memory usage data for autoscaling decisions
- D) Replaces Prometheus for cluster monitoring

**Answer:** C) Collects CPU and memory usage data for autoscaling decisions

**8. Without the Kubernetes Metrics Server, which feature cannot function in EKS?**
- A) Cluster Autoscaler
- B) Horizontal Pod Autoscaler (HPA)
- C) Vertical Pod Autoscaler (VPA)
- D) Ingress Controller

**Answer:** B) Horizontal Pod Autoscaler (HPA)

**9. What command can you run to check if the Metrics Server is running in your EKS cluster?**
- A) `kubectl get deployment -n kube-system metrics-server`
- B) `kubectl logs -n kube-system coredns`
- C) `eksctl get cluster`
- D) `aws eks describe-cluster`

**Answer:** A) `kubectl get deployment -n kube-system metrics-server`

---

## Autoscaling in EKS: Vertical, Horizontal, and Cluster Node Autoscaling Explained

**10. What does the Horizontal Pod Autoscaler (HPA) do in Kubernetes?**
- A) Scales worker nodes in an EKS cluster
- B) Increases or decreases the number of Pod replicas based on CPU/memory usage
- C) Optimizes CPU and memory requests for Pods
- D) Modifies IAM roles dynamically

**Answer:** B) Increases or decreases the number of Pod replicas based on CPU/memory usage

**11. Which EKS autoscaler is responsible for adding and removing worker nodes based on pending pods?**
- A) Horizontal Pod Autoscaler (HPA)
- B) Cluster Autoscaler
- C) Vertical Pod Autoscaler (VPA)
- D) Load Balancer Controller

**Answer:** B) Cluster Autoscaler

**12. If a Pod needs more memory than its allocated limit, which autoscaler can help adjust the request size dynamically?**
- A) Horizontal Pod Autoscaler (HPA)
- B) Cluster Autoscaler
- C) Vertical Pod Autoscaler (VPA)
- D) Kubernetes Metrics Server

**Answer:** C) Vertical Pod Autoscaler (VPA)

---

## Monitoring EKS Clusters: Tools, Best Practices, and Performance Optimization

**13. Which tool is commonly used for collecting and visualizing Kubernetes metrics?**
- A) Prometheus and Grafana
- B) AWS Lambda
- C) AWS CloudFormation
- D) Kubernetes Metrics Server

**Answer:** A) Prometheus and Grafana

**14. What is the primary benefit of using AWS X-Ray in an EKS cluster?**
- A) Encrypts Kubernetes Secrets automatically
- B) Replaces Kubernetes Metrics Server for monitoring
- C) Provides distributed tracing for debugging microservices
- D) Provisions new worker nodes in an autoscaling event

**Answer:** C) Provides distributed tracing for debugging microservices

**15. What is a best practice for monitoring logs in an EKS cluster?**
- A) Use Kubernetes Metrics Server for log storage
- B) Integrate Fluent Bit or Fluentd to ship logs to CloudWatch or Elasticsearch
- C) Store all logs inside the container filesystem
- D) Only use `kubectl logs` for monitoring applications

**Answer:** B) Integrate Fluent Bit or Fluentd to ship logs to CloudWatch or Elasticsearch

---

# Scenario Based Questions

## Understanding Load Balancers in EKS: Application vs. Network Load Balancers

### Scenario 1: Choosing Between ALB and NLB
**Question:**
You are deploying an application on Amazon EKS. The application serves HTTP/HTTPS traffic and requires path-based routing to different microservices. However, you also have another service that requires low-latency TCP connections. Which load balancers should you use for each case?

**Step-by-Step Answer:**
1. Identify traffic type
- HTTP/HTTPS traffic → Needs Layer 7 routing → Use Application Load Balancer (ALB)
- Low-latency TCP traffic → Needs Layer 4 performance → Use Network Load Balancer (NLB)

2. Configure ALB for HTTP/HTTPS Traffic
- Use Ingress with annotations to specify ALB.
- Enable path-based routing to direct requests to different microservices.

3. Configure NLB for TCP Traffic
- Use Kubernetes Service of type LoadBalancer with annotation to specify NLB.
- Ensure the security groups and target groups allow required TCP ports.

4. Verify Load Balancer Assignments
- Use `kubectl get svc` to check if the ALB/NLB has been created successfully.
- Check AWS Console > EC2 > Load Balancers to confirm the correct LB type is used.

**Final Decision:** ALB for HTTP/HTTPS with path-based routing, and NLB for low-latency TCP traffic.

---

## EKS Load Balancer Controller: Managing External and Internal Traffic

### Scenario 2: Setting Up an Internal ALB
**Question:**
You want to expose an internal web service within your EKS cluster, making it accessible only from within your VPC. How do you configure an ALB as an internal load balancer?

**Step-by-Step Answer:**
1. Ensure the EKS Load Balancer Controller is installed
- Verify using:

     kubectl get deployment -n kube-system aws-load-balancer-controller

- If not installed, deploy it using Helm.

2. Modify the Ingress resource to specify an internal ALB
- Add the annotation:

     alb.ingress.kubernetes.io/scheme: internal

3. Deploy the Ingress resource and verify
- Apply the configuration using:

     kubectl apply -f my-ingress.yaml

- Check the ALB using:

     kubectl get ingress -n my-namespace

4. Test Internal Access
- Use an EC2 instance within the same VPC to test access:

     curl http://<internal-alb-dns>

**Final Result:** The ALB is internal-only, restricting traffic to the VPC.

---

## Kubernetes Metrics Server: Why It’s Essential for HPA (Horizontal Pod Autoscaler)

### Scenario 3: HPA Not Scaling Pods Automatically
**Question:**
You have configured an HPA for your application in EKS, but the number of pods does not scale based on CPU load. How do you troubleshoot and fix this issue?

**Step-by-Step Answer:**
1. Check if the Metrics Server is installed
- Run:

     kubectl get deployment -n kube-system metrics-server

2. Verify Metrics Availability
- Run:

     kubectl top pods

3. Check HPA Status
- Run:

     kubectl get hpa

4. Fix Common Issues
- Ensure the Metrics Server has the correct API aggregation layer permissions.
- Check that resource requests and limits are correctly set in pod specs.

**Final Result:** Metrics Server is running, providing CPU usage, and HPA scales pods dynamically.

---

## Autoscaling in EKS: Vertical, Horizontal, and Cluster Node Autoscaling Explained

### Scenario 4: Scaling Up Node Capacity Dynamically
**Question:**
Your EKS cluster is running out of capacity as new pods are scheduled, causing them to remain in a "Pending" state. How do you ensure nodes are automatically added to meet demand?

**Step-by-Step Answer:**
1. Check Pending Pods
- Run:

     kubectl get pods --field-selector=status.phase=Pending

2. Ensure Cluster Autoscaler is Installed
- Verify using:

     kubectl get deployment -n kube-system cluster-autoscaler

3. Configure Auto-Scaling for Node Groups
- Ensure the node group is set to scale with min/max nodes:

     eksctl create nodegroup --cluster my-cluster --name autoscaling-ng --min-size 2 --max-size 5

4. Test Node Auto-Scaling
- Deploy a workload that exceeds current node capacity.
- Run:

     kubectl get nodes

**Final Result:** Cluster Autoscaler scales nodes dynamically based on workload demand.

---

## Monitoring EKS Clusters: Tools, Best Practices, and Performance Optimization

### Scenario 5: Setting Up Monitoring with Prometheus and Grafana
**Question:**
You need to monitor your EKS cluster and set up a dashboard for CPU, memory, and pod usage. How do you achieve this?

**Step-by-Step Answer:**
1. Deploy Prometheus for Metrics Collection
- Install Prometheus using Helm:

     helm install prometheus prometheus-community/kube-prometheus-stack

2. Deploy Grafana for Dashboards
- Install Grafana using Helm:

     helm install grafana grafana/grafana

3. Access Grafana and Configure Dashboards
- Port-forward Grafana to access it locally:

     kubectl port-forward svc/grafana 3000:80

4. Set Up Alerts for Resource Usage
- Configure alerts in Grafana for high CPU/memory usage.

**Final Result:** A fully functional monitoring setup with real-time metrics and alerts.