여러 AWS의 매니지드 서비스를 사용하다 보면 커스터마이징을 하는 부분에 있어 제약이 많다.
하지만 EKS를 사용하면 그러한 제약이 없도록 구성 하여 이식성을 그대로 가져갈 수 있도록 구성되었다.
클라우드 환경에서 K8S를 서비스 해주면 'Managed Kubernetes' 라고 불리며 직역하면 관리형 쿠버네티스 인데 Control Plane을 클라우드 서비스 벤더사에서 관리해 준다.
사용자는 Master Node를 관리할 필요가 없고 Worker Node만 관리하면 되므로 관리 용의성이 좋다.
EKS(Elastic Kubernetes Service)는 AWS에서 제공하는 'Managed Kubernetes' 이다.
쿠버네티스를 구축하고 관리할 떄는 마스터 노드 및 etcd를 이중화, 삼중화 하는것이 매우 중요하다. 하지만 EKS에서는 마스터노드와 etcd 노드를 관리해주고 Private Link로 연결되어 내부망 통신으로 안전하게 워커노드와 통신 할 수 있다.
위에서도 한번 언급한 내용인데 쿠버네티스는 Master Node와 Worker Node 둘다 관리해야 하지만
EKS의 Master Node와 Worker Node 둘 다 AWS Managed이다.
즉, 모든 노드를 AWS에서 관리할 수 있는것이다.
EKS에서 Node Group을 생성을 하면 AWS에서 ASG(Auto Scaling Group)에 속한 EC2가 생성이 된다.
일반 K8S에서 클러스터를 업그레이드 하려고 하면 매뉴얼과 절차대로 진행해야 한다.
반면 EKS를 사용하게 되면 AWS에서 클러스터 업그레이드를 클릭 한번으로 업데이트를 할 수 있다.
쿠버네티스에서 파드를 생성하면 해당 파드는 클러스터 내에서만 볼 수 있게 가상 네트워크를 부여받는다.
네트워크 플러그인으로는 AWS CNI라는 플러그인이 사용되는데 해당 플러그인은 일반적인 CNI(Flannel, Callico)와 차이점이 있다.
클러스터의 IP 대역을 VPC로 할당 받기 때문에 파드를 생성하면 VPC와 동일한 네트워크를 공유하게 된다.
즉, 파드는 클러스터를 생성하는 데 사용되는 서브넷의 IP를 사용하게 되고 Worker Node는 여러 네트워크 인터페이스(=ENI)로 파드(=오브젝트)의 IP를 괸리한다.
이렇게 되면 단점으로는 많은 오브젝트가 생성되기 시작한다면 클러스터 내에 부여할 IP가 부족하게 될 것이다. 부여할 IP가 부족하다면 ENI가 추가로 생성되는데 이 ENI는 인스턴스의 유형에 따라 갯수가 제한이 되어 있기 때문에 Worker Node의 인스턴스 유형을 잘 고려해서 선택해야 한다.
다음은 EKS에서 사용자에게 롤을 할당하는 과정이다.
aws-auth
configmap - mapRole에 rolearn
에 IAM Role ARN 추가 https://www.youtube.com/watch?v=O3znWPUdt18&t=480s&ab_channel=AmazonWebServicesKorea