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와 통신이 가능한 상태여야 한다.

Pod 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위 1개 이상의 컨테이너로 구성된 컨테이너 집합 동일 파드 내 컨테이너는 여러 리눅스 네임스페이스 공유 (동일한 아이피 주소 사용) 사용자가 파드를 직접 관리하는 경우는 거의 없음 파드 수명주기 파드는 정의된 라이프 사이클을 따르며 반드시 한 번만 스케줄 되며 중지 및 종료 전까지 해당 노드에서 실행된다. 파드의 상태는 status필드는 phase 값에서 확인할 수 있다. 값 의미 Pending 파드가 클러스터 상에서 승인되었지만 파드를 실행하기 위한 준비중인 상태 Running 파드가 노드에 바인딩되었고 컨테이너가 생성된 상태 Succeeded 파드에 있는 모든 컨테이너가 정상적으로 실행된 상태 Failed 파드에 있는 모든 컨테이너가 종료되었고, 하나 이상의 컨테이너가 실패로 종료된 상태 Unknown 파드의 상태를 알 수 없는 상태로 일반적으로 파드가 실행되는 노드와 통신 문제로 발생

쿠버네티스란? 컨테이너화된 워크 로드와 서비스를 관리하기 위한 이식성이 있고, 확장 가능한 오픈소스 플랫폼 컨테이너 발전과정 쿠버네티스 특징 서비스 디스커버리와 로드 밸런싱 스토리지 오케스트레이션 자동화된 롤아웃과 롤백 자동화된 빈 패킹 자동화된 복구 시크릿과 구성 관리 쿠버네티스 컴포넌트 Control Plane 쿠버네티스 클러스터를 관리하는 역할 상태 관리 및 명령어 처리 구성 요소 apiserver