Share
Sign In
Kubernetes
Amazon EKS Cluster Endpoint 네트워크 유형별 차이점
mchlkim
👍
Add headers to automatically create a table of contents
EKS를 생성할 때 클러스터 엔드포인트 액세스 유형을 지정해야한다.
클러스터 엔드포인트는 Control Plane의 Kubernetes API 서버용 엔드포인트를 의미한다.
클러스터 엔드포인트는 시스템 요구사항에 맞춰 유형을 지정하여 생성하면 되는데 이 때 유형별로 어떤 차이점이 있는지와 어떤 네트워크 흐름을 가지는지 궁금했다.
우선 클러스터 엔드포인트 액세스 유형은 3가지로 Public, Public & Private, Private 중 선택하여 생성할 수 있다.
Public Access
사용자는 인터넷에서 클러스터 API 서버에 접근할 수 있다.
워커 노드가 존재하는 VPC에서 DNS 질의를 해도 클러스터 엔드포인트의 퍼블릭 아이피가 조회된다.
외부 환경에서도 동일하게 클러스터 엔드포인트의 퍼블릭 아이피가 조회된다.
위의 구성도에서 PUBLIC ACCESS SOURCE CIDR를 보면 0.0.0.0/0으로 되어있는데 해당 CIDR는 직접 조정이 가능하며 최대 40개까지 CIDR를 추가할 수 있다.
Netowrk ACL로 제어하는 것으로 보인다.
그러나 위의 경우 워커 노드에서 API Server와 통신할 때 Amazon 네트워크 내에서 이동되며 외부 인터넷으로는 이동되지 않는다.
Private Access
Private Access로 설정하게 되면 EKS OWNED ENI를 통한 접근만 허용하게 된다.
Public Access로 생성해도 EKS OWNED ENI가 생성되지만 직접 통신은 하지 않는다.
클러스터 API에 접근하기 위해서는 EKS OWNED ENI와 통신이 가능한 상태여야 한다.
가장 큰 특징은 Amazon EKS에서 사용자 대신 Route53 Private Hosted Zone을 생성하고 Cluster의 VPC와 연결된다. AWS에서 관리되며 사용자 계정의 Route53에서는 확인할 수 없으며 사용자 VPC에서 enableDnsHostnamesenableDnsSupport가 활성화 되어 있어야 하며 DHCP 옵션에 도메인 이름 서버 목록에 AmazonProviderDNS가 포함되어 있어야 한다.
그리고 내부 VPC 서버에서 DNS 질의했을 때 EKS OWNED ENI 아이피주소가 조회된다.
이는 Route53 Private Hosted Zone 레코드에 EKS OWNED ENI가 등록되어 있기 때문이다.
외부 환경에서 DNS 질의 했을 때 동일하게 EKS OWNED ENI 아이피 주소가 조회되지만 이때에는 퍼블릭 DNS 서버에 의해 해당 아이피주소를 반환하게 된다.
그리고 인터넷 통신이 안되는 환경인 경우 VPC 엔드포인트를 구성하여 사용해야 한다.
필요한 엔드포인트 목록은 아래 문서에서 확인 가능하다.
Public & Private Access
마지막으로 Public & Private은 위에서 설명한 Public Access와 Private Access가 합쳐진 형태로 이해하면 된다.
외부 환경에서는 허용된 CIDR를 통해 퍼블릭 엔드포인트 주소로 통신이 되며 내부 VPC에서는 Route53 PHZ에서 EKS OWNED ENI 아이피 주소로 통신하게 된다.
Mc
Subscribe to 'mchlkim'
Welcome to 'mchlkim'!
By subscribing to my site, you'll be the first to receive notifications and emails about the latest updates, including new posts.
Join SlashPage and subscribe to 'mchlkim'!
Subscribe
👍
Other posts in 'Kubernetes'See all
Kubernetes Pod
Pod 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위 1개 이상의 컨테이너로 구성된 컨테이너 집합 동일 파드 내 컨테이너는 여러 리눅스 네임스페이스 공유 (동일한 아이피 주소 사용) 사용자가 파드를 직접 관리하는 경우는 거의 없음 파드 수명주기 파드는 정의된 라이프 사이클을 따르며 반드시 한 번만 스케줄 되며 중지 및 종료 전까지 해당 노드에서 실행된다. 파드의 상태는 status필드는 phase 값에서 확인할 수 있다. 값 의미 Pending 파드가 클러스터 상에서 승인되었지만 파드를 실행하기 위한 준비중인 상태 Running 파드가 노드에 바인딩되었고 컨테이너가 생성된 상태 Succeeded 파드에 있는 모든 컨테이너가 정상적으로 실행된 상태 Failed 파드에 있는 모든 컨테이너가 종료되었고, 하나 이상의 컨테이너가 실패로 종료된 상태 Unknown 파드의 상태를 알 수 없는 상태로 일반적으로 파드가 실행되는 노드와 통신 문제로 발생
Kubernetes 기초
쿠버네티스란? 컨테이너화된 워크 로드와 서비스를 관리하기 위한 이식성이 있고, 확장 가능한 오픈소스 플랫폼 컨테이너 발전과정 쿠버네티스 특징 서비스 디스커버리와 로드 밸런싱 스토리지 오케스트레이션 자동화된 롤아웃과 롤백 자동화된 빈 패킹 자동화된 복구 시크릿과 구성 관리 쿠버네티스 컴포넌트 Control Plane 쿠버네티스 클러스터를 관리하는 역할 상태 관리 및 명령어 처리 구성 요소 apiserver