EKS 설치 및 클러스터 엔드포인트(EKS Cluster Endpoint)

EKS 배포

EKS를 배포 방법에는 3가지 방법이 있습니다.

1. AWS 웹 관리 콘솔
2. eksctl
3. IaC(CDK, CloudFormation, Terraform)

이번 실습에서는 eksctl 명령어를 활용하여 EKS를 배포합니다.

eksctl

eksctl은 Amazon EKS 클러스터를 생성하고 관리하기 위한 공식 CLI(Command Line Interface) 도구입니다.

eksctl로 클러스터 생성 시, 내부 로직(코드)을 살펴보면 aws cloudformation 서비스를 통해서 스택을 생성하고 업데이트를 수행합니다.

https://github.com/eksctl-io/eksctl/blob/8064a501bd4c9c0fa2199ba358fcbd1db63e3356/pkg/cfn/manager/api.go#L93

 

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 액세스 방식을 사용하는 것을 적극 권장합니다.