EKS 배포
EKS를 배포 방법에는 3가지 방법이 있습니다.
- AWS 웹 관리 콘솔
- eksctl
- IaC(CDK, CloudFormation, Terraform)
이번 실습에서는 eksctl 명령어를 활용하여 EKS를 배포합니다.
eksctl
eksctl은 Amazon EKS 클러스터를 생성하고 관리하기 위한 공식 CLI(Command Line Interface) 도구입니다.
eksctl로 클러스터 생성 시, 내부 로직(코드)을 살펴보면 aws cloudformation 서비스를 통해서 스택을 생성하고 업데이트를 수행합니다.

eksctl 설치
OS 플랫폼에 맞게 eksctl을 설치합니다.
- 실습은 ubuntu(amd64) 환경에서 진행합니다.
# for ARM systems, set ARCH to: `arm64`, `armv6` or `armv7`
ARCH=amd64
PLATFORM=$(uname -s)_$ARCH
curl -sLO "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_$PLATFORM.tar.gz"
# (Optional) Verify checksum
curl -sL "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_checksums.txt" | grep $PLATFORM | sha256sum --check
tar -xzf eksctl_$PLATFORM.tar.gz -C /tmp && rm eksctl_$PLATFORM.tar.gz
sudo mv /tmp/eksctl /usr/local/bin
eksctl로 eks 배포하기
eksctl 명령어는 다양한 옵션을 제공합니다. --dry-run 옵션을 통해서 yaml파일로 추출하고, 클러스터 정보를 한번 더 확인하고 배포합니다.
eksctl create cluster \
--name myeks \ # 클러스터 이름 지정
--region=ap-northeast-2 \ # AWS 리전 (서울)
--nodegroup-name=mynodegroup \ # 워커 노드 그룹의 이름
--node-type=t3.medium \ # 워커 노드의 EC2 인스턴스 타입
--node-volume-size=30 \ # 워커 노드의 EBS 볼륨 크기(GB)
--zones=ap-northeast-2a,ap-northeast-2c \ # 사용할 가용영역 지정
--vpc-cidr=172.20.0.0/16 \ # VPC의 CIDR 블록
--ssh-access \ # SSH 접근 허용
--node-ami-family Ubuntu2004 \ # 노드의 AMI 유형 (Ubuntu 20.04)
--dry-run > cluster.yaml # 실제 생성하지 않고 YAML 파일로 출력
# 클러스터 생성
eksctl create cluster -f cluster.yaml
# 클러스터 삭제
eksctl delete cluster -f cluster.yaml
cluster.yaml (파일 전체 내용)
apiVersion: eksctl.io/v1alpha5
cloudWatch:
clusterLogging: {}
iam:
vpcResourceControllerPolicy: true
withOIDC: false
kind: ClusterConfig
kubernetesNetworkConfig:
ipFamily: IPv4
managedNodeGroups:
- amiFamily: AmazonLinux2
desiredCapacity: 2
disableIMDSv1: true
disablePodIMDS: false
iam:
withAddonPolicies:
albIngress: false
appMesh: false
appMeshPreview: false
autoScaler: false
awsLoadBalancerController: false
certManager: false
cloudWatch: false
ebs: false
efs: false
externalDNS: true
fsx: false
imageBuilder: false
xRay: false
instanceSelector: {}
instanceType: t3.medium
labels:
alpha.eksctl.io/cluster-name: myeks
alpha.eksctl.io/nodegroup-name: myeks-nodegroup
maxSize: 2
minSize: 2
name: myeks-nodegroup
privateNetworking: false
releaseVersion: ""
securityGroups:
withLocal: null
withShared: null
ssh:
allow: true
publicKeyPath: ~/.ssh/id_rsa.pub
tags:
alpha.eksctl.io/nodegroup-name: myeks-nodegroup
alpha.eksctl.io/nodegroup-type: managed
volumeIOPS: 3000
volumeSize: 30
volumeThroughput: 125
volumeType: gp3
metadata:
name: myeks
region: ap-northeast-2
version: "1.31"
privateCluster:
enabled: false
skipEndpointCreation: false
vpc:
autoAllocateIPv6: false
cidr: 192.168.0.0/16
clusterEndpoints:
privateAccess: false
publicAccess: true
id: vpc-0a551426479f827a5
manageSharedNodeSecurityGroupRules: true
nat:
gateway: Disable
subnets:
public:
ap-northeast-2a:
az: ap-northeast-2a
cidr: 192.168.1.0/24
id: subnet-0a2fcb9fd9f7bc75d
ap-northeast-2c:
az: ap-northeast-2c
cidr: 192.168.2.0/24
id: subnet-0a2bbbd67c56e7398
EKS 배포 확인
AWS CloudFormation 스택이 생성되고 eks 리소스들이 잘 생성됨을 확인할 수 있습니다.

EKS 메뉴에서도 EKS 클러스터가 잘 생성됨을 확인할 수 있습니다.

eks 클러스터 리소스 확인
클러스터에 접속하여 EKS 리소스를 확인합니다.
# eks 클러스터 정보 확인
kubectl cluster-info
Kubernetes control plane is running at https://B3F28FF068F03C89E989FC87F2B1E8B9.gr7.ap-northeast-2.eks.amazonaws.com
# 노드 정보 확인
kubectl get node -owide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
ip-192-168-1-202.ap-northeast-2.compute.internal Ready <none> 4h24m v1.31.4-eks-aeac579 192.168.1.202 3.35.206.234 Amazon Linux 2 5.10.233-223.887.amzn2.x86_64 containerd://1.7.25ip-192-168-2-245.ap-northeast-2.compute.internal Ready <none> 4h24m v1.31.4-eks-aeac579 192.168.2.245 13.209.68.75 Amazon Linux 2 5.10.233-223.887.amzn2.x86_64 containerd://1.7.25
(admin-eks@myeks:N/A) [root@myeks-host ~]# kubectl get pod -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system aws-node-557l4 2/2 Running 0 4h24m
kube-system aws-node-99ckp 2/2 Running 0 4h24m
kube-system coredns-9b5bc9468-6gzt5 1/1 Running 0 4h28m
kube-system coredns-9b5bc9468-vq2rw 1/1 Running 0 4h28m
kube-system kube-proxy-bmqtt 1/1 Running 0 4h24m
kube-system kube-proxy-zgnkz 1/1 Running 0 4h24m
kube-system metrics-server-86bbfd75bb-9dlv6 1/1 Running 0 4h28m
kube-system metrics-server-86bbfd75bb-t6smv 1/1 Running 0 4h28m
노드 정보 확인
데이터 플레인의 프로세스 상세 정보를 확인합니다.
N1=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2a -o jsonpath={.items[0].status.addresses[0].address})
N2=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2c -o jsonpath={.items[0].status.addresses[0].address})
for i in $N1 $N2; do echo ">> node $i <<"; ssh ec2-user@$i sudo pstree; echo; done
for i in $N1 $N2; do echo ">> node $i <<"; ssh ec2-user@$i ps afxuwww; echo; done
for i in $N1 $N2; do echo ">> node $i <<"; ssh ec2-user@$i ps axf |grep /usr/bin/containerd; echo; done
for i in $N1 $N2; do echo ">> node $i <<"; ssh ec2-user@$i ls /etc/kubernetes/kubelet/; echo; done
# EKS에서는 static pod를 사용하지 않음을 확인
for i in $N1 $N2; do echo ">> node $i <<"; ssh ec2-user@$i ls /etc/kubernetes/manifests/; echo; done
EKS owned ENI
EKS 생성 시, ENI가 생성된 것을 확인할 수 있는데, EKS의 클러스터 엔드포인트 액세스의 네트워크 구성을 이해하기 위해서는 EKS Owned ENI라는 개념을 알 필요가 있습니다.
- EKS owned ENI는 AWS 소유의 네트워크 인터페이스입니다.
- ENI는 EKS의 각 노드에 생성되며 관리노드(AWS)와 워커노드(사용자) 간 통신을 하는 인터페이스 역할을 합니다.
- AWS가 이러한 ENI를 소유하고 관리함으로써 보안이 강화되고, 클러스터의 네트워크 관리를 단순화하고 운영을 간소화할 수 있습니다

EKS 클러스터 엔드포인트 액세스
EKS는 클러스터의 Kubernetes API 서버와 통신을 위해 3가지 엔드포인트 액세스 모드를 제공합니다.

1. 퍼블릭 액세스(public)
- 특징
- 인터넷을 통해 API 서버에 직접 접근
- 보안 그룹을 통한 IP 기반 접근 제어
- 개발 환경이나 테스트에 적합
- 통신흐름
- 컨트롤 플레인 -> EKS owned ENI -> 워커노드
- 워커노드 -> 퍼블릭 도메인 -> 컨트롤플레인
- 클라이언트 -> 퍼블릭 도메인 -> 컨트롤플레인

2. 퍼블릭 + 프라이빗 액세스(public + private)
- 특징
- VPC 내부와 외부 모두에서 접근 가능
- 내부 시스템은 VPC 내에서 직접 통신
- 외부 관리 도구는 퍼블릭 엔드포인트 사용
- 통신흐름
- 컨트롤플레인 -> EKS onwed ENI -> 워커노드
- 워커노드 -> Private Domain , EKS Owned ENI -> 컨트롤플레인
- 클라이언트 -> 퍼블릭도메인 -> 컨트롤플레인

3. 프라이빗 액세스(private)
- 특징
- VPC 내부에서만 API 서버 접근 가능
- 가장 높은 수준의 보안 제공
- VPN 또는 AWS Direct Connect 필요
- 엄격한 보안 요구사항이 있는 프로덕션 환경에 적합
- 통신흐름
- 컨트롤플레인 -> EKS onwed ENI -> 워커노드
- 워커노드 -> Private Domain ,EKS Owned ENI -> 컨트롤플레인
- 클라이언트 -> Private Domain ,EKS Owned ENI -> 컨트롤플레인

퍼블릭 + 프라이빗(Public + Private) 적용
Public + Private 액세스 모드를 적용하고 기존 Public 모드와의 차이점을 살펴보겠습니다.
적용 전(public)
먼저 현재 클러스터의 API 서버 엔드포인트 IP를 확인해 보면, Public 모드에서는 퍼블릭 IP가 할당되어 있는 것을 확인할 수 있습니다.
APIDNS=$(aws eks describe-cluster --name $CLUSTER_NAME | jq -r .cluster.endpoint | cut -d '/' -f 3) AME | jq -r .cluster.endpoint
dig +short $APIDNS
3.36.252.2
43.203.43.52

이제 클러스터의 엔드포인트 액세스 모드를 Public + Private로 변경하고 다시 확인해 보겠습니다.
# publicAccessCidrs는 자신의 환경에 맞는 퍼블릭 공인 IP
aws eks update-cluster-config --region $AWS_DEFAULT_REGION --name $CLUSTER_NAME --resources-vpc-config endpointPublicAccess=true,publicAccessCidrs="$(curl -s ipinfo.io/ip)/32",endpointPrivateAccess=true
적용 후(public + private)
설정 후, 6분 정도 후 웹 콘솔에서도 API 서버 엔드포인트 액세스가 변경됨을 확인할 수 있습니다.

업데이트 기록 확인

VPC 내부 IP로 변경된 것을 확인할 수 있습니다
APIDNS=$(aws eks describe-cluster --name $CLUSTER_NAME | jq -r .cluster.endpoint | cut -d '/' -f 3) AME | jq -r .cluster.endpoint
dig +short $APIDNS
192.168.2.209
192.168.1.174
해당 IP는 AWS owned CNI의 IP임을 확인할 수 있습니다.

Public + Private 액세스로 변경 시, api-server와 통신하기 위해서는 추가적으로 기존 작업 인스턴스의 IP대역을 추가해주어야 합니다
# kubectl 사용 확인
kubectl get node -v=6
kubectl cluster-info
# EKS ControlPlane 보안그룹 ID 확인
aws ec2 describe-security-groups --filters Name=group-name,Values=*ControlPlaneSecurityGroup* --query "SecurityGroups[*].[GroupId]" --output text
CPSGID=$(aws ec2 describe-security-groups --filters Name=group-name,Values=*ControlPlaneSecurityGroup* --query "SecurityGroups[*].[GroupId]" --output text)
echo $CPSGID
# 노드 보안그룹에 eksctl-host 에서 노드(파드)에 접속 가능하게 룰(Rule) 추가 설정
aws ec2 authorize-security-group-ingress --group-id $CPSGID --protocol '-1' --cidr 192.168.1.100/32
# kubectl 사용 확인
kubectl get node -v=6
kubectl cluster-info
이러한 Public + Private 액세스 방식을 통해 외부 접근은 허용된 IP만 가능하도록 제한하고, VPC 내부에서는 프라이빗 IP를 통한 직접 통신으로 보안 강화를 할 수 있습니다. 따라서, 운영 환경에서는 적어도 Public + Private 액세스 방식을 사용하는 것을 적극 권장합니다.
'AWS > EKS' 카테고리의 다른 글
EKS 기본 스토리지(EBS + EFS CSI Driver, Instance Store) (0) | 2025.02.23 |
---|---|
EKS 기본 네트워크(AWS VPC CNI + AWS LoadBalancer Controller) (0) | 2025.02.16 |
EKS IaC(Terraform) - AEWS 8주차 (1) | 2024.04.28 |
EKS CI/CD - AEWS 7주차 (1) | 2024.04.20 |
EKS 보안(Security) - AEWS 6주차 (1) | 2024.04.14 |
EKS 배포
EKS를 배포 방법에는 3가지 방법이 있습니다.
- AWS 웹 관리 콘솔
- eksctl
- IaC(CDK, CloudFormation, Terraform)
이번 실습에서는 eksctl 명령어를 활용하여 EKS를 배포합니다.
eksctl
eksctl은 Amazon EKS 클러스터를 생성하고 관리하기 위한 공식 CLI(Command Line Interface) 도구입니다.
eksctl로 클러스터 생성 시, 내부 로직(코드)을 살펴보면 aws cloudformation 서비스를 통해서 스택을 생성하고 업데이트를 수행합니다.

eksctl 설치
OS 플랫폼에 맞게 eksctl을 설치합니다.
- 실습은 ubuntu(amd64) 환경에서 진행합니다.
# for ARM systems, set ARCH to: `arm64`, `armv6` or `armv7`
ARCH=amd64
PLATFORM=$(uname -s)_$ARCH
curl -sLO "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_$PLATFORM.tar.gz"
# (Optional) Verify checksum
curl -sL "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_checksums.txt" | grep $PLATFORM | sha256sum --check
tar -xzf eksctl_$PLATFORM.tar.gz -C /tmp && rm eksctl_$PLATFORM.tar.gz
sudo mv /tmp/eksctl /usr/local/bin
eksctl로 eks 배포하기
eksctl 명령어는 다양한 옵션을 제공합니다. --dry-run 옵션을 통해서 yaml파일로 추출하고, 클러스터 정보를 한번 더 확인하고 배포합니다.
eksctl create cluster \
--name myeks \ # 클러스터 이름 지정
--region=ap-northeast-2 \ # AWS 리전 (서울)
--nodegroup-name=mynodegroup \ # 워커 노드 그룹의 이름
--node-type=t3.medium \ # 워커 노드의 EC2 인스턴스 타입
--node-volume-size=30 \ # 워커 노드의 EBS 볼륨 크기(GB)
--zones=ap-northeast-2a,ap-northeast-2c \ # 사용할 가용영역 지정
--vpc-cidr=172.20.0.0/16 \ # VPC의 CIDR 블록
--ssh-access \ # SSH 접근 허용
--node-ami-family Ubuntu2004 \ # 노드의 AMI 유형 (Ubuntu 20.04)
--dry-run > cluster.yaml # 실제 생성하지 않고 YAML 파일로 출력
# 클러스터 생성
eksctl create cluster -f cluster.yaml
# 클러스터 삭제
eksctl delete cluster -f cluster.yaml
cluster.yaml (파일 전체 내용)
apiVersion: eksctl.io/v1alpha5
cloudWatch:
clusterLogging: {}
iam:
vpcResourceControllerPolicy: true
withOIDC: false
kind: ClusterConfig
kubernetesNetworkConfig:
ipFamily: IPv4
managedNodeGroups:
- amiFamily: AmazonLinux2
desiredCapacity: 2
disableIMDSv1: true
disablePodIMDS: false
iam:
withAddonPolicies:
albIngress: false
appMesh: false
appMeshPreview: false
autoScaler: false
awsLoadBalancerController: false
certManager: false
cloudWatch: false
ebs: false
efs: false
externalDNS: true
fsx: false
imageBuilder: false
xRay: false
instanceSelector: {}
instanceType: t3.medium
labels:
alpha.eksctl.io/cluster-name: myeks
alpha.eksctl.io/nodegroup-name: myeks-nodegroup
maxSize: 2
minSize: 2
name: myeks-nodegroup
privateNetworking: false
releaseVersion: ""
securityGroups:
withLocal: null
withShared: null
ssh:
allow: true
publicKeyPath: ~/.ssh/id_rsa.pub
tags:
alpha.eksctl.io/nodegroup-name: myeks-nodegroup
alpha.eksctl.io/nodegroup-type: managed
volumeIOPS: 3000
volumeSize: 30
volumeThroughput: 125
volumeType: gp3
metadata:
name: myeks
region: ap-northeast-2
version: "1.31"
privateCluster:
enabled: false
skipEndpointCreation: false
vpc:
autoAllocateIPv6: false
cidr: 192.168.0.0/16
clusterEndpoints:
privateAccess: false
publicAccess: true
id: vpc-0a551426479f827a5
manageSharedNodeSecurityGroupRules: true
nat:
gateway: Disable
subnets:
public:
ap-northeast-2a:
az: ap-northeast-2a
cidr: 192.168.1.0/24
id: subnet-0a2fcb9fd9f7bc75d
ap-northeast-2c:
az: ap-northeast-2c
cidr: 192.168.2.0/24
id: subnet-0a2bbbd67c56e7398
EKS 배포 확인
AWS CloudFormation 스택이 생성되고 eks 리소스들이 잘 생성됨을 확인할 수 있습니다.

EKS 메뉴에서도 EKS 클러스터가 잘 생성됨을 확인할 수 있습니다.

eks 클러스터 리소스 확인
클러스터에 접속하여 EKS 리소스를 확인합니다.
# eks 클러스터 정보 확인
kubectl cluster-info
Kubernetes control plane is running at https://B3F28FF068F03C89E989FC87F2B1E8B9.gr7.ap-northeast-2.eks.amazonaws.com
# 노드 정보 확인
kubectl get node -owide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
ip-192-168-1-202.ap-northeast-2.compute.internal Ready <none> 4h24m v1.31.4-eks-aeac579 192.168.1.202 3.35.206.234 Amazon Linux 2 5.10.233-223.887.amzn2.x86_64 containerd://1.7.25ip-192-168-2-245.ap-northeast-2.compute.internal Ready <none> 4h24m v1.31.4-eks-aeac579 192.168.2.245 13.209.68.75 Amazon Linux 2 5.10.233-223.887.amzn2.x86_64 containerd://1.7.25
(admin-eks@myeks:N/A) [root@myeks-host ~]# kubectl get pod -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system aws-node-557l4 2/2 Running 0 4h24m
kube-system aws-node-99ckp 2/2 Running 0 4h24m
kube-system coredns-9b5bc9468-6gzt5 1/1 Running 0 4h28m
kube-system coredns-9b5bc9468-vq2rw 1/1 Running 0 4h28m
kube-system kube-proxy-bmqtt 1/1 Running 0 4h24m
kube-system kube-proxy-zgnkz 1/1 Running 0 4h24m
kube-system metrics-server-86bbfd75bb-9dlv6 1/1 Running 0 4h28m
kube-system metrics-server-86bbfd75bb-t6smv 1/1 Running 0 4h28m
노드 정보 확인
데이터 플레인의 프로세스 상세 정보를 확인합니다.
N1=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2a -o jsonpath={.items[0].status.addresses[0].address})
N2=$(kubectl get node --label-columns=topology.kubernetes.io/zone --selector=topology.kubernetes.io/zone=ap-northeast-2c -o jsonpath={.items[0].status.addresses[0].address})
for i in $N1 $N2; do echo ">> node $i <<"; ssh ec2-user@$i sudo pstree; echo; done
for i in $N1 $N2; do echo ">> node $i <<"; ssh ec2-user@$i ps afxuwww; echo; done
for i in $N1 $N2; do echo ">> node $i <<"; ssh ec2-user@$i ps axf |grep /usr/bin/containerd; echo; done
for i in $N1 $N2; do echo ">> node $i <<"; ssh ec2-user@$i ls /etc/kubernetes/kubelet/; echo; done
# EKS에서는 static pod를 사용하지 않음을 확인
for i in $N1 $N2; do echo ">> node $i <<"; ssh ec2-user@$i ls /etc/kubernetes/manifests/; echo; done
EKS owned ENI
EKS 생성 시, ENI가 생성된 것을 확인할 수 있는데, EKS의 클러스터 엔드포인트 액세스의 네트워크 구성을 이해하기 위해서는 EKS Owned ENI라는 개념을 알 필요가 있습니다.
- EKS owned ENI는 AWS 소유의 네트워크 인터페이스입니다.
- ENI는 EKS의 각 노드에 생성되며 관리노드(AWS)와 워커노드(사용자) 간 통신을 하는 인터페이스 역할을 합니다.
- AWS가 이러한 ENI를 소유하고 관리함으로써 보안이 강화되고, 클러스터의 네트워크 관리를 단순화하고 운영을 간소화할 수 있습니다

EKS 클러스터 엔드포인트 액세스
EKS는 클러스터의 Kubernetes API 서버와 통신을 위해 3가지 엔드포인트 액세스 모드를 제공합니다.

1. 퍼블릭 액세스(public)
- 특징
- 인터넷을 통해 API 서버에 직접 접근
- 보안 그룹을 통한 IP 기반 접근 제어
- 개발 환경이나 테스트에 적합
- 통신흐름
- 컨트롤 플레인 -> EKS owned ENI -> 워커노드
- 워커노드 -> 퍼블릭 도메인 -> 컨트롤플레인
- 클라이언트 -> 퍼블릭 도메인 -> 컨트롤플레인

2. 퍼블릭 + 프라이빗 액세스(public + private)
- 특징
- VPC 내부와 외부 모두에서 접근 가능
- 내부 시스템은 VPC 내에서 직접 통신
- 외부 관리 도구는 퍼블릭 엔드포인트 사용
- 통신흐름
- 컨트롤플레인 -> EKS onwed ENI -> 워커노드
- 워커노드 -> Private Domain , EKS Owned ENI -> 컨트롤플레인
- 클라이언트 -> 퍼블릭도메인 -> 컨트롤플레인

3. 프라이빗 액세스(private)
- 특징
- VPC 내부에서만 API 서버 접근 가능
- 가장 높은 수준의 보안 제공
- VPN 또는 AWS Direct Connect 필요
- 엄격한 보안 요구사항이 있는 프로덕션 환경에 적합
- 통신흐름
- 컨트롤플레인 -> EKS onwed ENI -> 워커노드
- 워커노드 -> Private Domain ,EKS Owned ENI -> 컨트롤플레인
- 클라이언트 -> Private Domain ,EKS Owned ENI -> 컨트롤플레인

퍼블릭 + 프라이빗(Public + Private) 적용
Public + Private 액세스 모드를 적용하고 기존 Public 모드와의 차이점을 살펴보겠습니다.
적용 전(public)
먼저 현재 클러스터의 API 서버 엔드포인트 IP를 확인해 보면, Public 모드에서는 퍼블릭 IP가 할당되어 있는 것을 확인할 수 있습니다.
APIDNS=$(aws eks describe-cluster --name $CLUSTER_NAME | jq -r .cluster.endpoint | cut -d '/' -f 3) AME | jq -r .cluster.endpoint
dig +short $APIDNS
3.36.252.2
43.203.43.52

이제 클러스터의 엔드포인트 액세스 모드를 Public + Private로 변경하고 다시 확인해 보겠습니다.
# publicAccessCidrs는 자신의 환경에 맞는 퍼블릭 공인 IP
aws eks update-cluster-config --region $AWS_DEFAULT_REGION --name $CLUSTER_NAME --resources-vpc-config endpointPublicAccess=true,publicAccessCidrs="$(curl -s ipinfo.io/ip)/32",endpointPrivateAccess=true
적용 후(public + private)
설정 후, 6분 정도 후 웹 콘솔에서도 API 서버 엔드포인트 액세스가 변경됨을 확인할 수 있습니다.

업데이트 기록 확인

VPC 내부 IP로 변경된 것을 확인할 수 있습니다
APIDNS=$(aws eks describe-cluster --name $CLUSTER_NAME | jq -r .cluster.endpoint | cut -d '/' -f 3) AME | jq -r .cluster.endpoint
dig +short $APIDNS
192.168.2.209
192.168.1.174
해당 IP는 AWS owned CNI의 IP임을 확인할 수 있습니다.

Public + Private 액세스로 변경 시, api-server와 통신하기 위해서는 추가적으로 기존 작업 인스턴스의 IP대역을 추가해주어야 합니다
# kubectl 사용 확인
kubectl get node -v=6
kubectl cluster-info
# EKS ControlPlane 보안그룹 ID 확인
aws ec2 describe-security-groups --filters Name=group-name,Values=*ControlPlaneSecurityGroup* --query "SecurityGroups[*].[GroupId]" --output text
CPSGID=$(aws ec2 describe-security-groups --filters Name=group-name,Values=*ControlPlaneSecurityGroup* --query "SecurityGroups[*].[GroupId]" --output text)
echo $CPSGID
# 노드 보안그룹에 eksctl-host 에서 노드(파드)에 접속 가능하게 룰(Rule) 추가 설정
aws ec2 authorize-security-group-ingress --group-id $CPSGID --protocol '-1' --cidr 192.168.1.100/32
# kubectl 사용 확인
kubectl get node -v=6
kubectl cluster-info
이러한 Public + Private 액세스 방식을 통해 외부 접근은 허용된 IP만 가능하도록 제한하고, VPC 내부에서는 프라이빗 IP를 통한 직접 통신으로 보안 강화를 할 수 있습니다. 따라서, 운영 환경에서는 적어도 Public + Private 액세스 방식을 사용하는 것을 적극 권장합니다.
'AWS > EKS' 카테고리의 다른 글
EKS 기본 스토리지(EBS + EFS CSI Driver, Instance Store) (0) | 2025.02.23 |
---|---|
EKS 기본 네트워크(AWS VPC CNI + AWS LoadBalancer Controller) (0) | 2025.02.16 |
EKS IaC(Terraform) - AEWS 8주차 (1) | 2024.04.28 |
EKS CI/CD - AEWS 7주차 (1) | 2024.04.20 |
EKS 보안(Security) - AEWS 6주차 (1) | 2024.04.14 |