쿠버네티스/AEWS

AEWS 1주차 - Endpoint Access에 따른 트래픽 흐름 확인

라리음 2025. 2. 4. 20:43



본 글은 가시다님이 진행하시는 AEWS(AWS EKS Workshop Study)를 참여하여 정리한 글입니다. 
모르는 부분이 많아서 틀린 내용이 있다면 말씀 부탁드리겠습니다!

 

 

 

 


EKS Owned ENI

 

 

AEWS 1주차 - EKS Control Plane & Endpoint Access

 

AEWS 1주차 - EKS Control Plane & Endpoint Access

본 글은 가시다님이 진행하시는 AEWS(AWS EKS Workshop Study)를 참여하여 정리한 글입니다. 모르는 부분이 많아서 틀린 내용이 있다면 말씀 부탁드리겠습니다!   EKS란? Amazon Elastic Kubernetes Service(Amazo

rhims.tistory.com

에서 언급했듯이. Public Endpoint Access로 클러스터를 구축하면 

 

클러스터 엔드포인트 엑세스 - Public

 

 

사용자가 API서버에 통신을 할때 Public으로 통신합니다.

(kubelet, kube-proxy도 Public 통신합니다.)

 

 

여기서 API서버 -> Kubeblet만 Private 통신입니다. 이때 API서버와 kubelet은 같은 VPC가 아닌데도 통신이 가능합니다.

이유는 EKS owned ENI를 통해서 통신하기때문입니다.

 

EKS owned ENI란 API서버와 소유한 클러스터의 노드들이 통신이 가능하게끔 도와주는 인터페이스입니다.

 

 

 

EKS owned ENI는 콘솔에서도 확인이 가능합니다.

EKS owned ENI 콘솔 화면

 

* 보통 ENI를 생성하게 되면 소유자와 인스턴스 소유자가 동일한데 API서버는 AWS Managed이다보니 

  인스턴스 소유자의 계정 번호가 소유자 계정 번호와 다른걸 확인할 수 있습니다.

 

 

 

지난번에 같이 클러스터 구축하신 분들도 쉽게 이해하실 수 있도록 구성도로도 보여드리겠습니다.

 

API서버 -> Kubelet 통신

 

정확하게는 노드들의 ENI도 있고 복잡하지만 EKS owned ENI만 특정하여 표현하였습니다.

 

 

 

 

 


EKS Endpoint Access

 

목표 : Public 방식과 Public & Private 방식의 통신 흐름이 다름을 확인

 

방법

1) Bastion에서 API서버와 kubelet, kube-proxy의 peer IP 확인

2) 로컬(외부망)에서 API서버와 kubelet, kube-proxy의 peer IP 확인

 

 

Public

 

 

 

현재 Public이므로 kubelet, kube-proxy는 아래와 같이 통신하게 될 것입니다.

API서버와 통신 흐름

 

 

 

Bastion에서 API서버로 통신을 확인하겠습니다.

 

dig 명령

 

 


이후 kubelet과 kube-proxy의 peer IP를 확인합니다.

APIDNS=$(aws eks describe-cluster --name $CLUSTER_NAME | jq -r .cluster.endpoint | cut -d '/' -f 3)
dig +short $APIDNS
while true; do dig +short $APIDNS ; echo "------------------------------" ; date; sleep 1; done

Data Plane -> API서버 통신 (kubelet, kube-proxy)

 

 

모두 15.164.246.222/43.202.15.0와 peer을 맺고있습니다.

 

 

 

 

이제 로컬(외부)에서 API로 통신을 확인합니다.

 

 

저는 Windows 환경이여서 dig대신 다른 방법으로 확인했습니다.(powershell)

$CLUSTER_NAME = "myeks"
$APIDNS = (aws eks describe-cluster --name $CLUSTER_NAME | ConvertFrom-Json).cluster.endpoint -replace "https://", ""

while ($true) {
    Resolve-DnsName $APIDNS | Select-Object Name, IPAddress
    Write-Host "------------------------------"
    Get-Date
    Start-Sleep -Seconds 1
}

 

로컬(외부) -> API서버 통신

 

 

 

같은 공인IP를 표현하고 있습니다. 이는 둘다 API서버와 외부 통신하고 있음을 나타냅니다.

(사용자는 kubectl을 가정합니다.)

 

 

 


Public & Private

 

 

 

Endpoint Access 방식 변경 명령어

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

 

업데이트에는 조금 걸립니다.

 

 

* Bastion이 노드에 접근할 수 있도록 클러스터 보안그룹에 Bastion을 허용해줘야합니다.

 

 

 

설정이 완료가 되었으면 이제 아래와 같이 통신이 되어야합니다.

 

 

 

먼저 Bastion에서 확인을 해봅니다.

 

 

아까와 같이 dig를 통해 APIDNS를 확인합니다.

dig 명령

 

그리고 똑같이 kubelet, kube-proxy의 Peer IP를 확인합니다.

Data Plane -> API서버 통신 (kubelet, kube-proxy)

 

이번에는 지난번과 다른 IP를 바라봅니다. 이는 아까 말했던 EKS owned ENI를 바라보는 것입니다.

 

당연히 콘솔에서 있던 EKS owned ENI를 통해 확인할 수 있습니다.

콘솔 화면

 

 

 

그러면 로컬(외부)에서 사용자가 API서버와 통신했을때도 확인해봅시다.

 

로컬(외부) -> API서버 통신

 

 

아까와 동일하게 공인IP을 바라보고 있습니다.

 

이는 여전히 인터넷을 통해서 외부 통신을 하고있음을 나타냅니다.

 

이로써 저희가 목표했던 Public과 Public & Private의 통신 흐름이 다르다는 것을 확인해보았습니다.

 

 

 


 

출처

 

https://www.ongja.space/13d4c62d-36c3-80da-8e8d-ee082f0b2c90

 

Amazon EKS Cluster Endpoint Access

Amazon EKS Cluster의 API 서버 접근 방법

www.ongja.space