[AEWS] EKS 소개 및 배포

Hi yena·2026년 3월 14일

AEWS

목록 보기
8/10

가시다님의 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 비교

1. Amazon EKS 소개

1.1 Amazon EKS란?

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 등 기존 툴체인을 그대로 사용할 수 있습니다.

1.2 Amazon EKS 아키텍처

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 을 사용합니다.

1.3 Amazon EKS 구성 요소

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 연동

1.4 EKS 배포 방식

EKS 클러스터를 생성하는 방법은 크게 세 가지입니다

▫️ AWS Management Console
웹 GUI로 클러스터를 생성하는 방식

▫️ eksctl
EKS 전용 CLI 도구로 빠르게 클러스터를 생성할 수 있습니다.

▫️ IaC
코드로 인프라를 정의하고 관리하는 방식(Terraform, AWS CDC, CloudFormation)


2. Amazon EKS 배포 및 확인

▶︎ 가시다님이 제공해주신 테라폼 코드를 사용해서 배포하였습니다

▫️ 변수 지정

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
  • 10여분정도 기다림 끝에 배포가 되었습니다

짜란✨

  • .kube/config에 자격증명 설정을 해줍니다

▫️ eks 정보 확인

- 클러스터 정보 확인

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 이미지, 커널버전, 컨테이너 런타임 정보도 확인 가능합니다.

  • add-on
    클러스터 내엔 coredns, kube-proxy, vpc-cni설치가 되어있습니다

CoreDNS — 클러스터 내부 DNS (서비스 이름 → IP 해석)
kube-proxy — 노드별 iptables 관리 → Service 트래픽 라우팅
vpc-cni — Pod에 VPC 실제 IP 직접 할당 (오버레이 없는 네이티브 라우팅)

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

▫️ 워커노드 정보 확인

  • EKS 관리형 노드 그룹: AWS가 노드(EC2)의 프로비저닝·등록·업데이트·종료를 자동으로 관리하는 노드 그룹
    - 특징
    Auto Scaling Group 기반 — 내부적으로 ASG로 동작, min/max/desired 설정
    노드 업그레이드 자동화 — Rolling update로 노드 교체 (drain → 새 노드 → 종료)
    AMI 관리 — AWS가 EKS 최적화 AMI 제공, 버전 업그레이드 시 교체
    자동 노드 등록 — kubelet이 자동으로 클러스터에 join
    Taint/Label 지원 — 노드 그룹 단위로 설정 가능
  • 노드 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를 고정해보고 써본적이 없어서 개인적으로 좋은방법인지는 잘 모르겠습니다!)


3. EKS Cluster Endpoint Access 실습

  • 현재 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에서 접속할 수 있게 변경이 됩니다

로컬 PC -> ssh → NODE1(VPC 내부) → dig $APIDNS 호출시

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

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

외부에서(로컬PC) dig $APIDNS 호출시


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


도전과제) aws eks vs vanilla k8s 간 controlplane , dataplane (간단ㅎㅎ,,)비교

0개의 댓글