MCP가 포함된 🚀 Amazon EKS — AWS의 AI 기반 쿠버네티스 관리

🚀 Amazon EKS — Zero to Production Roadmap

1. Architecture

Core components:

EKS Control Plane
Managed Node Groups
VPC
Private/Public Subnets
VPC CNI
CoreDNS
kube-proxy
AWS Load Balancer Controller
EBS CSI Driver
IAM / EKS Access Entries
Kubernetes RBAC

1. Create EKS with Terraform

Recommended structure:

eks-project/
├── main.tf
├── variables.tf
├── outputs.tf
├── providers.tf
├── terraform.tfvars
└── modules/
├── vpc/
└── eks/

Your Terraform should create:

VPC
├── Internet Gateway
├── NAT Gateway
├── Public Subnets
├── Private Subnets
└── Route Tables

EKS
├── Control Plane
├── IAM Roles
├── Managed Node Group
└── EKS Add-ons

For production, place worker nodes in private subnets.

1. Verify AWS Authentication

Before touching Kubernetes:

aws sts get-caller-identity

You should get your AWS identity.

Then:

aws eks update-kubeconfig \
–region ap-south-1 \
–name

Verify:

kubectl config current-context

Then:

kubectl get nodes

Expected:

NAME STATUS ROLES
ip-10-0-1-xxx.ec2.internal Ready
ip-10-0-2-xxx.ec2.internal Ready

1. EKS Authentication

Think about authentication in two layers:

IAM
│
│ Authentication
▼
EKS API Server
│
│ Authorization
▼
Kubernetes RBAC
Authentication

AWS asks:

Who are you?

Example:

aws sts get-caller-identity
Authorization

Kubernetes asks:

What are you allowed to do?

Example:

kubectl auth can-i get pods

This distinction is very important in EKS interviews.

1. EKS Access Entry

For modern EKS clusters, use EKS Access Entries where possible.

Conceptually:

IAM User / IAM Role
│
▼
EKS Access Entry
│
▼
Access Policy / Kubernetes permissions
│
▼
Kubernetes API

For example, an IAM role can be granted administrative access to the cluster.

1. Kubernetes RBAC

RBAC controls permissions inside Kubernetes.

There are four important objects:

Role
ClusterRole
RoleBinding
ClusterRoleBinding
Role

Namespace-specific permissions.

Example:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: developer-role
namespace: dev
rules:

• apiGroups: [“”] resources: [“pods”] verbs: [“get”, “list”, “watch”]

This allows a user to:

GET pods
LIST pods
WATCH pods

but not:

DELETE pods
CREATE pods

1. RoleBinding

Connect the user to the Role:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: developer-binding
namespace: dev
subjects:

• kind: User name: ali apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: developer-role apiGroup: rbac.authorization.k8s.io

Apply:

kubectl apply -f role.yaml
kubectl apply -f rolebinding.yaml

Test:

kubectl auth can-i get pods -n dev –as=ali

Expected:

yes

Test something unauthorized:

kubectl auth can-i delete deployment -n dev –as=ali

Expected:

no

1. VPC CNI

This is one of the most important EKS concepts.

AWS VPC CNI gives Kubernetes pods networking through the AWS VPC.

EKS Node
│
├── Primary ENI
│
├── Secondary ENI
│
├── Pod IP
│
├── Pod IP
│
└── Pod IP

Check it:

kubectl get pods -n kube-system

Look for:

aws-node-xxxxx

Check:

kubectl get daemonset aws-node -n kube-system

1. Why VPC CNI Matters

Suppose your node has:

10.0.1.10

A pod may receive:

10.0.1.50

That IP comes from the VPC networking system.

Therefore your pods can communicate with AWS resources such as:

RDS
ElastiCache
ALB
S3 via VPC endpoints
Secrets Manager via VPC endpoints

1. Deploy an Application

Example:

apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
– name: nginx
image: nginx:latest
ports:
– containerPort: 80

Apply:

kubectl apply -f deployment.yaml

Check:

kubectl get pods

1. Service

Expose the pods internally:

apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app: nginx
ports:
– port: 80
targetPort: 80
type: ClusterIP

Then:

kubectl apply -f service.yaml

Check:

kubectl get svc

1. ALB Ingress

For external traffic:

Internet
│
▼
AWS ALB
│
▼
Kubernetes Ingress
│
▼
Service
│
▼
Pods

You’ll normally use the AWS Load Balancer Controller for this.

1. Production Application Architecture

For your DevOps project, a good architecture is:

                Internet
                   │
                   ▼
                Route 53
                   │
                   ▼
                AWS ALB
                   │
             ┌─────┴─────┐
             │   Ingress │
             └─────┬─────┘
                   │
          ┌────────┴────────┐
          │                 │
      Frontend           Backend
          │                 │
          │            ┌────┴────┐
          │            │         │
          │           RDS      Redis
          │
          ▼
         Pods

Enter fullscreen mode Exit fullscreen mode

1. CI/CD

Your final pipeline can be:

Developer
│
▼
GitHub
│
▼
GitHub Actions
│
├── Test
├── SonarQube
├── Docker Build
├── Docker Push
│
▼
Amazon ECR
│
▼
EKS
│
▼
Rolling Deployment

Use GitHub OIDC → AWS IAM Role rather than storing long-lived AWS access keys.

1. Final Production Flow GitHub │ ▼ GitHub Actions │ OIDC Authentication │ ▼ AWS IAM │ ┌──────────┴──────────┐ │ │ ▼ ▼ ECR EKS │ │ Docker Image Kubernetes │ ┌────────┴────────┐ │ │ Ingress Services │ │ └────────┬────────┘ │ ▼ Pods │ ┌─────────────┼─────────────┐ ▼ ▼ ▼ RDS Redis AWS APIs