가시다님의 AWS EKS Workshop Study(AEWS) 1주차 학습 내용을 기반으로 작성하였습니다.
목차
1. Amazon EKS 소개
2. Amazon EKS 배포 및 확인
3. EKS Cluster Endpoint Access 소개 및 실습
4. (약간의) aws eks vs vanilla k8s 간 controlplane , dataplane 비교
Amazon EKS는 AWS에서 제공하는 완전관리형 Kubernetes 서비스입니다. Kubernetes 클러스터의 Control Plane을 AWS가 직접 운영하여 운영 복잡성을 크게 줄여줍니다.
Kubernetes를 직접 구축하면 다음 구성 요소를 직접 운영해야 합니다🥲
etcd, API Server, Scheduler, Controller Manager
고가용성 구성
버전 업그레이드 및 보안 패치
EKS를 사용하면 컨트롤 플레인 관리를 AWS가 대신 수행하고 사용자는 애플리케이션이 실행되는 Worker Node와 Pod 관리에만 집중할 수 있습니다.
또한 EKS는 AWS 서비스와 긴밀하게 통합되어 아래 기능을 손쉽게 활용할 수 있습니다.
- IAM 기반 인증 (IRSA, EKS Pod Identity)
-> 저는 eks pod identity를 좀더 선호합니다
- VPC 네트워크 통합 (VPC CNI)
- Load Balancer 연동
- CloudWatch 로그 및 모니터링
표준 Kubernetes와 완전 호환되므로 kubectl, Helm 등 기존 툴체인을 그대로 사용할 수 있습니다.
EKS는 크게 Control Plane과 Data Plane으로 구성됩니다.
▫️ Control Plane (AWS 관리 영역)
AWS가 관리하는 Kubernetes 핵심 구성 요소입니다.
kube-apiserver
etcd
kube-scheduler
kube-controller-manager
Control Plane은 AWS 관리 계정에서 멀티 AZ로 운영되며, 사용자가 직접 접근하거나 관리할 필요가 없습니다. 가용성과 업그레이드는 AWS가 책임집니다.
▫️ Data Plane (사용자 관리 영역)
실제 애플리케이션 Pod가 실행되는 Worker Node 영역입니다. 사용자가 직접 관리하며, 세가지 방식으로 구성할 수 있습니다.
-> 제가 담당하는 사이트의 경우 Managed Node Group 을 사용합니다.

EKS 클러스터는 다음 구성 요소로 이루어집니다.
▫️ Cluster
Kubernetes Control Plane과 Worker Node를 포함하는 전체 실행 환경
▫️ Control Plane
AWS가 완전 관리하는 Kubernetes 핵심 컴포넌트로, 클러스터의 상태를 관리
kube-apiserver — 모든 API 요청의 진입점
etcd — 클러스터 상태 저장소
kube-scheduler — Pod 배치 결정
kube-controller-manager — 리소스 상태 조정
▫️ Worker Node
컨테이너가 실제로 실행되는 서버
kubelet — 노드와 Control Plane 간 통신
container runtime — 컨테이너 실행 (containerd)
kube-proxy — 네트워크 라우팅
▫️ Add-ON
EKS가 기본 제공하거나 선택 설치하는 핵심 컴포넌트
VPC CNI — Pod에 VPC IP 직접 할당
CoreDNS — 클러스터 내부 DNS
kube-proxy — 서비스 네트워킹
AWS Load Balancer Controller — LB 프로비저닝
EBS / EFS CSI Driver — PV 연동
EKS 클러스터를 생성하는 방법은 크게 세 가지입니다
▫️ AWS Management Console
웹 GUI로 클러스터를 생성하는 방식
▫️ eksctl
EKS 전용 CLI 도구로 빠르게 클러스터를 생성할 수 있습니다.
▫️ IaC
코드로 인프라를 정의하고 관리하는 방식(Terraform, AWS CDC, CloudFormation)

▶︎ 가시다님이 제공해주신 테라폼 코드를 사용해서 배포하였습니다
aws ec2 describe-key-pairs --query "KeyPairs[].KeyName" --output text
export TF_VAR_KeyName=$(aws ec2 describe-key-pairs --query "KeyPairs[].KeyName" --output text)
export TF_VAR_ssh_access_cidr=$(curl -s ipinfo.io/ip)/32
echo $TF_VAR_KeyName $TF_VAR_ssh_access_cidr
TF_VAR_ssh_access_cidr=$(curl -s ipinfo.io/ip)/32
-> 내 공인 IP에서만 워커노드에 접근할 수 있도록 설정하는 것
terraform 내에 my-eks 라는 cluseter 이름으로
node type은 t3.medium, 2개의 워커노드로 배포되도록 설정되어있고, EBS 는 30GiB씩 붙어있습니다
variable "KubernetesVersion" {
description = "Kubernetes version for the EKS cluster."
type = string
default = "1.34"
}
variable "WorkerNodeInstanceType" {
description = "EC2 instance type for the worker nodes."
type = string
default = "t3.medium"
}
variable "WorkerNodeCount" {
description = "Number of worker nodes."
type = number
default = 2
}
variable "WorkerNodeVolumesize" {
description = "Volume size for worker nodes (in GiB)."
type = number
default = 30
}
az 는 a,b,c 존 할당될수있도록 설정이 되어있으며
192.168.0.0/16 을 할당 받은 VPC에서
192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24
세개의 서브넷이 퍼블릭에 할당되도록 설정되어있습니다.
variable "TargetRegion" {
description = "AWS region where the resources will be created."
type = string
default = "ap-northeast-2"
}
variable "availability_zones" {
description = "List of availability zones."
type = list(string)
default = ["ap-northeast-2a", "ap-northeast-2b", "ap-northeast-2c"]
}
variable "VpcBlock" {
description = "CIDR block for the VPC."
type = string
default = "192.168.0.0/16"
}
variable "public_subnet_blocks" {
description = "List of CIDR blocks for the public subnets."
type = list(string)
default = ["192.168.1.0/24", "192.168.2.0/24", "192.168.3.0/24"]
}

퍼블릭 라우팅 테이블은 192.168 대역은 로컬에서 처리하고 나머지 대역은 인터넷으로 라우팅되도록 설정되어있습니다.
클러스터의 노드 보안그룹엔 사전에 내 공인 ip 만 접근가능하도록 설정해준부분을 확인할 수 있습니다.

제 공인ip 주소는 121.168.85.74 입니다.

제 공인 ip에서는 노드에 접근가능하도록 인바운드규칙이 생성되어있습니다.

terraform init
terraform plan
nohup sh -c "terraform apply -auto-approve" > create.log 2>&1 &
tail -f create.log

짜란✨


- 클러스터 정보 확인
kubectl cluster-info
Kubernetes control plane is running at https://0865098D3CE859D1FEE6ED6E1A8E61BC.gr7.ap-northeast-2.eks.amazonaws.com
CoreDNS is running at https://0865098D3CE859D1FEE6ED6E1A8E61BC.gr7.ap-northeast-2.eks.amazonaws.com/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
- endpoint 확인
CLUSTER_NAME=myeks
aws eks describe-cluster --name $CLUSTER_NAME | jq

현재는 public 에서 클러스터 api 접근이 가능하며,(따라서 nat-gw는 필요없음)
워커노드도 퍼블릭에 배치되어 인터넷을 통해 api 서버와 통신한다.

노드 정보를 describe 해보면
kubernetes 버전, 내 외부IP 정보, os 이미지, 커널버전, 컨테이너 런타임 정보도 확인 가능합니다.
CoreDNS — 클러스터 내부 DNS (서비스 이름 → IP 해석)
kube-proxy — 노드별 iptables 관리 → Service 트래픽 라우팅
vpc-cni — Pod에 VPC 실제 IP 직접 할당 (오버레이 없는 네이티브 라우팅)

웹콘솔 내부에 추가기능 탭에서도 확인할 수 있습니다.

aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,PrivateIPAdd:PrivateIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output table


제 로컬 PC 에서 ping 통신이 됩니다
노드 보안그룹을 확인해보면
aws ec2 describe-security-groups --filters "Name=tag:Name,Values=myeks-node-group-sg" --query 'SecurityGroups[*].IpPermissions' --output text

제 로컬 PC 공인IP가 지정되어있는것을 확인가능합니다.
ssh 접속을 해보자
ssh -i ./my-keypair.pem -o StrictHostKeyChecking=no ec2-user@$NODE1 hostname

노드의 hostname은 맨아래찍힌내용과 같습니다.
ssh config 파일 내부에 설정을 아래와 같이 설정하면
cat ~/.ssh/config
Host 3.35.172.225
User ec2-user
IdentityFile ~/aews/1w/my-keypair.pem

쉽게 노드에 접속할 수 있습니다.
(음 그런데.. eks운영할 때 노드 ip를 고정해보고 써본적이 없어서 개인적으로 좋은방법인지는 잘 모르겠습니다!)
현재 EKS Cluster Endpoint 관련 정보 확인

퍼블릭에 전부 오픈되어있는 상태 입니다.
eks access endpoint 변경 (by Terraform)
eks.tf 파일 내 아래 항목을 변경해줍니다
1) endpoint_private_access: false->true
2) endpoint_public_access_cidrs 주석제거

terraform apply 를 해주면 아래와 같이 제 로컬pc의 ip(public) 및 private에서 접속할 수 있게 변경이 됩니다

ssh로 노드에 접속해서 dig를 실행하는 거라서 dig 질의 자체는 노드(VPC 내부)에서 날아감

내부 응답값 리턴(192.168.1.105,192.168.2.174)

외부 응답값 리턴하는것을 확인할 수 있습니다!
