쿠버네티스 클러스터를 구성할 때, 마주쳤던 바로 그것💡 클러스터 엔드포인트 액세스에 대해서 알아보자.
쿠버네티스의 엔트포인트 액세스란 쿠버네티스 API 서버에 대한 접근 방식이다.
쉽게 말해, 사용자가 쿠버네티스 API 서버에 kubectl로 명령을 내릴 때, 어떤 방식으로 클러스터와 상호 작용하는 지를 정의한다.
엔드포인트 방식을 퍼블릭으로 구성하는 경우 엔트포인트로 접근하는 도메인 주소는 NLB의 퍼블릭 IP주소가 된다.
이 이유는, 고 가용성을 위해 EKS에서 여러 API 서버가 구성(기본적으로 3개)되므로 이에 대해서 각 API서버에 고르게 부하분산하기 위해서 앞단에 NLB가 위치하는 것이다.
이제 사용자가 kubectl 명령을 내렸을 때 순.서.대.로 어떻게 통신이 일어나는지 살펴보자.
사용자가 kubectl 명령을 외부 인터넷을 통해 AWS Managed VPC
내 API 서버에 요청을 보낸다.
사용자가 자유롭게 접근이 가능하지만, 사용자가 아닌 사용자도 접근할 여지가 있다. (물론 보안이 존재하긴 함)
API 서버에서 kubelet으로 통하는 트래픽은 퍼블릭, 퍼블릭 프라이빗, 프라이빗 모두 동일하다.
사용자 명령을 받은 API 서버는 EKS owned ENI를 통해서 워커노드의 kubelet에 명령을 내리게 된다.
단순히 내부 통신이므로 별 거 없다.
명령을 받은 kubelet은 작업을 수행하고, 워커노드의 상태를 다시 API 서버로 보고한다.
이때 API 앤드포인트가 현재 NLB의 퍼블릭 IP주소로 되어있으므로, 해당 요청은 인터넷 게이트웨이를 통해서 외부로 빠져나가 API 서버에 전송된다.
즉, 외부 인터넷 구간으로 트래픽이 노출되게 된다는 단점이 있다.
EKS 클러스터 엔드포인트를 Public EndPoint Access로 구성하게되면 자유로운 접근이 가능하지만 보안적인 측면에서 조금 위험할 수 있다.
퍼블릭과 프라이빗이 혼용된 방식이다.
엔드포인트의 도메인 주소는 사용자를 위한 주소로, 동일하게 NLB의 퍼블릭 IP가 사용된다.
이 때 중요한 점은 워커노드를 위한 주소가 별도의 프라이빗 호스팅 존으로 구성되어 대상을 EKS owned ENI로 매핑한다.
kubectl을 통해 사용자가 API 서버로 요청을 보내는 과정은 퍼블릭과 동일하다.
API 서버에서 kubelet으로 통하는 트래픽은 퍼블릭, 퍼블릭 프라이빗, 프라이빗 모두 동일하다.
앞서 퍼블릭의 예제처럼 외부 인터넷으로 트래픽이 빠져나간 뒤 다시 API 서버로 들어오는 것이 아닌, AWS 내부의 프라이빗 호스팅 존을 통해서 EKS owned ENI를 통과해 나가게 된다.
이 부분이 퍼블릭과 퍼블릭+프라이빗 방식의 차이이다.
쉽게 비유하자면 퍼블릭 방식은 내 방에서 창문열고 밖으로 나가서 다시 집 대문 열고 들어오는 것이고, 퍼블릭+프라이빗 방식은 들어올 때 내 방 문 열고 들어왔으니, 나갈때도 내 방문으로 나가는 것이다.
완전한 퍼블릭 보다는 어느정도의 보안성과 어느정도의 효율성을 갖출 수 있다.
마지막으로 프라이빗만을 사용한 방식을 살펴보자.
중요한 점은 사용자의 VPC(Custom VPC) 내부에서 사용자가 접근하기 때문에 더이상 NLB의 퍼블릭 IP로 노출된 엔드포인트의 도메인 주소가 없다.
이 부분이 퍼블릭과 퍼블릭+프라이빗 방식의 차이이다.
사용자에서 API 서버에 kubeclt 요청을 보낼 때, 사용자가 사용자 VPC(Custom VPC) 내부에 있기 때문에 EKS owned ENI를 통해서 API 서버로 요청을 보낸다.
API 서버에서 kubelet으로 통하는 트래픽은 퍼블릭, 퍼블릭 프라이빗, 프라이빗 모두 동일하다.
앞선 퍼블릭 + 프라이빗 방식과 동일하다.
프라이빗 호스팅 존을 통해서 들어왔던 문인 EKS owned ENI를 통해서 API로 응답이 전송된다.
외부 인터넷에 노출되는 구간 없이 모든 것이 AWS 내부에서 동작하여 보안성있고 효율적인 통신이 가능하다.
따라서 대부분의 비즈니스 환경에서는 EKS 엔트포인트 액세스 환경을 프라이빗 환경으로 구성하는 것이 일반적이다.
Reference📎 | CloudNet@와 함께하는 Amazon EKS 기본 강의