EKS Basic Concepts

EKS 란?

EKS는 AWS Managed Service로 K8S 클러스터를 자동관리 해주는 서비스 이다.

이 때 관리형 서비스라고 해서 모든 영역을 관리해주는 것이 아니므로 기본적으로 쿠버네티스에 대한 지식과 개념을 알아야 구성할 수 있다.

 

EKS 아키텍처

 

EKS 관리 영역

EKS의 컨트롤 플레인은 AWS 에서 관리한다. 실제로 클러스터를 생성해 보면 해당 컨트롤 플레인의 노드는 사용자가 직접 접근할 수 없고 EKS를 생성할 때 지정한 VPC에 마스터 노드와 연결되는 ENI가 생기는데 해당 ENI 상세 정보를 보면 해당 ENI의 연결된 인스턴스의 소유자는 AWS 어카운트 인 것을 확인할 수 있다. 이는 컨트롤 플레인은 전적으로 AWS 에서 관리하겠다는 것이고 EKS 네트워크의 특징이다. 

 

일반적으로 내가 생성한 EC2의 ENI와는 다르게 Requester ID라는 속성이 있다. 이는 AWS 계정이다.

해당 ENI와 연결된 인스턴스의 소유자는 AWS 계정인 것을 확인할 수 있다.

 

 

EKS 클러스터 구축

EKS 클러스터를 구축하는 방법에는 여러 가지 방법이 있다. 

 ▪️ 웹 콘솔 

 ▪️ eksctl

 ▪️ IaC (Terraform, CDK, Terraform)

 ▪️ (awscli)

위 처럼 다양한 방법이 있지만 EKS를 처음 구성해본다면 웹 콘솔로 작업하는 게 좋을 듯 하다. eksctl, IaC등의 방법은 너무 뚝딱 만들어 지기 때문에 EKS의 동작방식과 컴포넌트들을 톺아보기 어렵기 때문이다. 물론 IaC 템플릿이 아니라 직접 한땀한땀 작성 한다면 오히려 더 자세히 살펴볼 수 있겠지만?

대부분 가장 대중적인 방법은 eksctl로 구성하는 것이다. eksctl로 구성하고 여러 컴포넌트를 하나씩 살펴봐도 된다. 이는 AWS EKS Workshop에 아주 잘 정리가 되어있다. 🔗

대략적으로 EKS 생성시간은 15분 정도 소요되므로 여유를 갖고 기다리자

 

EKS 클러스터 생성 시 주의할 점

 ▪️ 서브넷 생성 시 반드시 2개 이상의 가용영역을 지정해야 한다. 가용성 보장을 위해 필수 조치.

 ▪️ 클러스터와 노드그룹에 적절한 역할을 부여한다.
    ▪️ 각 역할에 관련된 정책을 살펴보면 해당 컴포넌트가 어떤 동작을 수행하고 어떤 리소스에 접근하는지 파악할 수 있어서 살펴보면 좋다.

    ▪️ EKS 클러스터가 사용하는 역할

        ▪️ AmazonEKSClusterPolicy 🔗

        ▪️ AmazonEKSVPCResourceController 🔗

        ▪️ 기타 추가 정책

    ▪️ EKS 노드 그룹 역할

        ▪️ AmazonEKSWorkerNodePolicy 🔗

        ▪️ AmazonEC2ContainerRegistryReadOnly 🔗

              EKS Add-on 사용시 ECR 참조. Add-on 사용 시 필요.

        ▪️ AmazonEKS_CNI_Policy 🔗
              VPC CNI 플러그인을 사용하는 경우 필요. 워커노드의 IP를 관리하는 데 사용

 

EKS 클러스터의 접근 권한 설정

AWS EKS 에서는 EKS IAM Access Entries 기능을 제공하여 클러스터 접근 권한을 콘솔로 쉽게 관리할 수 있다. 🔗

또한 다음과 같은 이점이 있다.

✔️ 기존 aws-auth ConfigMap을 직접 수정할 필요 없음. 예전에는 aws-auth ConfigMap을 직접 작성하고 관리해야 했는데 이 부분이 매우 번거로워서 애를 먹었었다. 하지만 이제는 콘솔에서도 쉽게 관리가 가능해졌다.
✔️ IAM 및 RBAC(Role-Based Access Control) 통합 관리 가능
✔️ 관리가 더 쉬워지고, 보안성이 향상됨

 

아래는 iam 에서 생성한 user를 josh-fc-eks-cluster 클러스터 관리자 권한을 부여한 예제이다.

이때, IAM access entries 에서 추가한 policy는 실제 Iam 콘솔에서는 확인이 안되지만 해당 권한이 부여됨을 kubectl 명령어로 확인해 볼 수 있다. 

 

 

참고로 IAM Access Entries 의 아키텍처는 다음과 같다.

IAM Access Entries는 AWS API를 통해 IAM 역할과 EKS 클러스터의 Kubernetes RBAC(Role-Based Access Control)를 직접 연결해 주는 방식이다.

 

EKS 네트워크의 특징

EKS 네트워크의 특징은 EKS의 기본 아키텍처에서 부터 상속이 된다. 컨트롤 플레인과 데이터 플레인이 다른영역에 있다 보니 이들간의 네트워크 구성이 재밌다. 이는 API 서버와의 통신하는 방식에 따라 다음과 같이 Public, Public + Private, Private 세 가지 구성 옵션이 생긴다.

https://www.youtube.com/watch?v=E49Q3y9wsUo

 

퍼블릭이 제일 간단한 구성이고 생성하기 쉽지만 보안적 측면에서 권장하지는 않는다. 다만 시간, 돈 비용을 고려했을 때 개인계정에서 테스트 하려면 퍼블릭 구성이 좋은 대안이다.

https://www.youtube.com/watch?v=E49Q3y9wsUo

kubectl 명령어를 수행하는 클라이언트는 API 서버에 퍼블릭으로 접근하지만, API 서버와 워커노드 간의 통신은 프라이빗 통신으로 구성된다. 

https://www.youtube.com/watch?v=E49Q3y9wsUo

kubectl 수행하는 환경 자체가 프라이빗 서브넷에 구성된다. 가장 안전한 방법이다. 다만 s3, lb, ec2 등의 서비스를 사용하기 위해서는 vpc endpoint 를 뚫어줘야 한다. 이는 매우 비용이 많이 부과될 수 있으므로 고려해봐야 한다.

 

또한 한가지 더 눈여겨볼 만한 특징은 일반적인 docker, k8s와 다르게 AWS EKS는 VPC CNI를 사용하면 Pod의 IP가 VPC CIDR의 IP를 사용하게 된다는 것이다. 

이를 통해 오버레이 네트워크 구성 없이 더 낮은 지연시간과 높은 처리량을 가질 수 있다는 이점이 있다. 하지만 IP 주소 pool을 잘 관리해야 할 필요가 있다. 따라서 초기 구성할 때 VPC CIDR를 좀 넉넉하게 잡고 구성하는 걸 권장한다.