AWS EKS 설정 톺아보기 auto mode, network, vpc

 

 

기본 환경

- mac pro

- AWS CLI, kubectl

 

 

 

두가지 방법의 클러스터 구성에 대해 하나하나씩 해보겠다.

 

빠른 구성(EKS 자율 모드 사용) - 신규

아래는 "빠른 구성(EKS 자율 모드 사용) - 신규"

 

우선 EKS 클러스터를 만들기 위한 IAM을 만들어줘야 한다.

신뢰할 수 있는 유형 : AWS 서비스

서비스 또는 사용 사례 : EKS

사용 사례 : EKS - Cluster

 

 

다음으로 넘어가면, 아래와 같이 AmazonEKSClusterPolicy 정책이 나온다.

이를 선택하고, 생성을 한다.

 

 

클러스터 IAM 역할을 생성하고, 필요한 Amazon EKS IAM 관리형 정책을 연결해야 한다.

Amazon EKS에서 관리하는 Kubernetes 클러스터는 사용자를 대신하여

다른 AWS 서비스를 호출하여 서비스와 함께 사용하는 리소스를 관리한다.

역할 이름에 원하는 이름을,

클러스터 서비스 역할에 우리가 방금 만든 IAM Role을 넣고 쿠버네티스 버전을 설정한다.

 

 

 

그러면 다시 eks(Amazon Elastic Kubernetes Service)를 검색해서

"클러스터 생성"을 클릭해주었다.

 

+ 추가로 kubernetes 버전에 대한 정보가 드롭다운이 아예 안되는 것을 확인했다.

어떤 정책을 할당을 안받았는지 알려주었다면, 오류 트리거가 더 쉬웠을 것 같은데

검색으로도 안나와서 ,, 진짜 당황했다. 오류인지 아니면 그냥 버전이 안보이는건지

판단하건데, eks:DescribeClusterVersions 이 정책이 할당을 안받아서 그런 것 같다.

 

쿠버 버전은 뭘로할지 고민하다가, 그냥 냅다 최신 버전으로 하라고 해서 그렇게 했다.

 

 

아 이름 잘못했다. 개미 싫어하는데,,,

 

이제 연결이 됐는지, 로컬에서 aws eks 명령어로 확인해보았다.

CREATING 중이니까 기다리라는 명령어를 받았다.. 급한 한국인

 

아니 근데 생성된거 아닌가?

좀 더 침착한 마음을 가지고 다시해주었다. 생성완료되었다는게 보이는 명령어다.

 

그러면 이제 node 에 대한 정보를 알아보겠다.

node에 대한 정보를 확인해보려면 아래와 같이 명령어를 입력해주면 된다.

kubectl get nodes

 

아무것도 없다는 nodes 들이 나온다.

그러나 회사 내부의 vpn 으로 접근중이라면  i/o timeout이 뜨고 안된다.

그렇다면 왜 VPN을 키면, EKS에 kubectl 로 접속이 안되는가
이건 AWS EKS의 Control plane(=API server) 가 동작하는 방식과 VPN이 라우팅 테이블에 끼치는 영향이다.

EKS API server는 AWS에서 관리형 서비스로 제공하여, control plane은 AWS가 관리하는데, 
API endpoint는 보통 퍼블릭 IP기반의 URL이다.
이 API server에 접근하려면,
- public endpoint 가 열려있어야 함
- local 에서 outbound 443 (HTTPS) 요청이 정상적으로 나가야 한다.

VPN이 여기서 개입을 하면, kubectl 요청이 우회된다.

aws eks describe-cluster \
  --region ap-northeast-2 \
  --name <클러스터 이름,, 내 경우는 curious-grunge-ant다 ㅠㅠ> \
  --query "cluster.endpoint" \
  --output text​

그러면 EKS endpoint 에 대한 정보를 가져온다.
그리고 확인해보기

curl -v https://xxxxxxxxxx.gr7.ap-northeast-2.eks.amazonaws.com​

그러면, 172.31.x.x 는 AWS 내부 VPC IP 주소이고, 
from 10.255.x.x 로 log가 나오는데, 내 VPN 환경에서 할당받은 IP이다.
이것은 EKS API server가 프라이빗 모드라서 인터넷 접근이 불가능한 상태

그래서 퍼블릭 접근을 허용하고 있지 않나 확인해봤는데 그건 아님

aws eks describe-cluster \
  --name curious-grunge-ant \
  --region ap-northeast-2 \
  --query "cluster.resourcesVpcConfig.endpointPublicAccess"
true

그러면 회사에서 막고 있는 거라고 판단이 됨

 

helm repo add apache-airflow https://airflow.apache.org
helm repo update

 

 

---

 

사용자 지정 구성

클러스터 구성의 "사용자 지정 구성"으로 선택했다.

 

위에서도 작성하긴 했지만, 바로 "사용자 지정 구성"으로 오신 분들을 위해서 한번 더 언급을 하면

클러스터 IAM 역할을 생성하고, 필요한 Amazon EKS IAM 관리형 정책을 연결해야 한다.

Amazon EKS에서 관리하는 Kubernetes 클러스터는 사용자를 대신하여

다른 AWS 서비스를 호출하여 서비스와 함께 사용하는 리소스를 관리한다.

 

IAM > 역할 > 에서 역할을 추가해주어야 한다.

역할 이름에 원하는 이름을,

클러스터 서비스 역할에 우리가 방금 만든 IAM Role을 넣고 쿠버네티스 버전을 설정한다.

 

 

AmazonEKSClusterPolicy : 클러스터가 오토스케일링, EC2, ELB, IAM 등 다른 AWS 서비스를 호출하기 위한 권한들이 담긴 정책 이 정책이 있어야 EBS 볼륨을 동적으로 프로비저닝 및 관리할 수 있으며, ELB를 동적으로 프로비저닝 가능

 

그러면 다시 eks(Amazon Elastic Kubernetes Service)를 검색해서

"클러스터 생성"을 클릭해주었다.

 

아래에 EKS auto mode - 신규에 대한은 Quick configuration 에도 자동으로 포함이 되어있다

 

뭔가 EKS, EKS-A 를 선택하는 것인가?! 라는 의문도 들었다.

EKS, EKS-A, EKS-D? EKS-D(Distro) : 직접 설치하고 관리 가능하며, kubernetes 배포판을 온프레미스(BM, VM) 환경에 설치할 수 있도록 공개한 오픈소스 - kubeadm 또는 kops 와 같은 Kubernetes 설치 도구를 통해 설치 가능 EKS와 EKS-A와의 가장 큰 차이는 Kubernetes 클러스터를 AWS에서 관리해 주는지 고객이 직접 관리하는지이다. EKS : 완전 관리형  kubernetes 플랫폼 EKS-A(Anywhere) : kubernetes 배포판으로 온프레미스 환경에 간단하게 생성/확장/삭제 등 클러스터의 라이프사이클을 관리하기 위한 오픈소스로 Ops Tool과 Amazon 배포판인 EKS Distro로 구성되어있다. - 고객사의 인프라에 설치되고 고객이 직접 관리하지만 필요에 따라 유료 구독 서비스를 통해 기술 지원을 받을 수 있다

 

 

EKS Auto Mode

일단 EKS Auto Mode를 활성화 해준다면,

리소스에 따라서 시간별로 나가는 돈이 다르다.

 

Auto mode가 관리하는 영역을 이해하기 위해서 EKS 사용경험이 있어야 한다. EKS가 native kubernetes 사용과 다른 점은 AWS 리소스를 사용한다. 노드는 EC2 instance를 사용하고, load balancer 를 사용하려면 ELB, DNS를 사용하려면 Route 53, 스토리지를 사용하려면 EBS, EFS를 사용한다. kubernetes에서 AWS 리소스를 사용하려면 요청을 처리하는 중간 개입자가 필요하는데, 이 개입자를 컨트롤러(or EKS 애드온)이라고 한다. 원래 기본 eks 는 아래와 같이 control plane 정도만 관리를 해주는데, EKS에 대한 진입장벽이, 기술이 중요한 회사들이 사용하기에는 어려워서 아예 전체적으로 관리를 해주자라는 곳에서 auto mode 가 생겨났다고 한다. 아래처럼 Data plane의 일부분을 관리해준다. EKS Auto Mode는 EKS 애드온 설치/관리를 해주고, GPU설정, 보안, 비용 최적화 등 많은 영역을 자동으로 관리한다. 특징 클러스터 및 안프라 자동 프로비저닝 - control plane, worker node resource를 직접 만들지 않아도 되며, eksctl, console에 클릭만 해도 클러스더 구성 됨 노드 및 용량 관리 - EC2 instance, Fargate 프로파일 관리 필요 X, Pod 실행 시, AWS가 node 자동 생성 및 스케일 인/아웃 자동 처리 자동 스케일링 자동 보안 패치 및 업그레이드(장점인지, 단점인지는 모름) - control plane, 인프라 구성요소 보안 패치와 유지보수로, 최신의 클러스터 유지 - Worker Node의 최신 AMI 사용, 수정 X, 21일마다 교체 단점 여러가지 선택을 하지 못하는 부분이 있다. 서비스를 지속하고, 규모가 커질 수록 비용이 증가한다. EKS auto mode 사용시에는 클러스터에서 구성할 EKS auto mode를 선택 취소할 수 있다. 기본값은 위 사진과 같이 기본 노드 풀 및 노드 클래스를 모두 생성하는 것이다. 내 선택에는 업그레이드를 자동으로 관리하고, AWS에 Data plane 일부분을 맡기는 것보다는 control plane만 맡기는 것으로 충분하다고 생각이 들었다. 기능중에서 서비스 노드의 중단과 재시작을 수반하는데, 우리는 안정성이 좀 더 중요하고, 이것을 직접 컨트롤할 수 있는 인력이 없다고 생각하지 않는다. 완전 기술 X 회사가 아니기 때문에, 어느정도 지식을 가지고 구축하는게 더 맞다고 판단한다. 또한 security group for pod, custom network 등과 같이 일부 EKS 기능을 사용할 수 없다. 노드 원격접속(ssh, SSM)을 막았기 때문에 디버깅이 어려운 등이 있다. (ref. https://docs.aws.amazon.com/eks/latest/userguide/eks-compute.html) 쿠버네티스에서 서비스한다면 결국엔 관련 지식이 언젠가는 필요하기에, 해보는게 맞다고 생각했다.

 

변경 불가능한 name과, 전에 EKS관련 policy를 부여한 cluster IAM role을 선택해준다.

이 값은 kubernetes 컨트롤 플레인이 사용자를 대신하여, AWS 리소스를 관리하도록 허용한다.

두 값 모두 생성 후 변경할 수 없다. (당연한 말인듯? 갑자기 master node의 역할을 변경하기가..)

 

즉, 

✔ 이름(Name) - 클러스터의 이름

✔ Kubernetes version - 클러스터에 대해 사용할 Kubernetes 버전

✔ Cluster IAM role - 생성한 Amazon EKS 클러스터 IAM 역할을 선택

    (Kubernetes 컨트롤 플레인이 사용자를 대신하여 AWS 리소스를 관리)

 

kubernetes 버전은 최신버전으로 해주면 된다.

표준과 확장을 선택할 수 있는데, 표준을 선택해주었다. 확장은 지정한 버전의 지원이 끝난 이후부터 돈을 더 내야한다.

 

Cluster access

EKS Cluster는 Cluster를 생성한 IAM User나 Role 만이 접근할 수 있다. 

다른 IAM User나 Role이 접근하면 에러가 발생한다.

그래서 IAM User에 Access Key를 발급해야 하는데, 매번 하는 일은 귀찮다.

근데 클러스터 관리자 접근을 허용 안하면 어떻게 돌아가는지 궁금한데,,,

 

암호화나 ARC 영역 관련 내용도 존재한다.

다른 문서 자료를 참고하면 다 기본값으로 하고 넘어가는 것 같다.

 

---

네트워킹 지정

EKS cluster 생성시, 기존에 있던 VPC 안에 cluster를 배치해야 할까 했었는데, 

subnet 및 cluster endpoint access 설정부터 고민이 되었다.

이전의 vpc 들과 매핑이 되었는데,

이 값들은 본인이 타겟으로 하고 있는 airflow, batch 와 함께 들어가 있긴 한데

다른 api-score 계산이나 다른 곳과 함께있기 때문에,

보안 그룹이나 할당 설정을 과하게 주거나 ip 주소 할당 고갈이 있을수도 있으니 ("만약"이 있으니)

새롭게 vpc를 생성하고 subnet까지 할당해주는것으로 방향을 잡았다.

 

✔ VPC - 클러스터를 생성하려면 Amazon EKS VPC 요구 사항을 충족하는 VPC를 선택해야 한다. 클러스터 생성 후에는 사용하려는 VPC를 변경할 수 없기 때문이다.

 

 

cluster 생성 시, 택하는 subnet의 의미를 파악하면,

subnet CIDR 블록 크기에 따라 subnet에 들어갈 IP 개수가 달라지는데

ex. /26 이면 CIDR 라면 2^(32-26)=64

이를 적게 해서 cluster를 만들었다가 나중에 cluster 규모가 커지면? (또 나오는 "만약"에)

 

그러나 이건 control plane 이 배치될 subnet에 대한 설정으로,

AWS EKS 네트워크 문서에서 control plain과 worker node의 subnet은 서로 다를 수 있으며,

초기에 설정하지 않은 subnet으로 나중에 worker mode를 배포할 수 있다고 한다.

그래서 control plane 용의 private subnet 두 개를 작은 CIDR 블록 크기로 만들어 선택해주었다.

 

 

또, cluster endpoint access 부분도 고민해봐야했었는데

cluster endpoint access 는 public 은 비추천한다고 한다.(AWS 문서)

재밌던 건, public 으로 하면 aws 리소스 간의 통신 또한 public 으로 해야 된다는 점

(control plane과 node 간 통신은 굳이 VPC 외부로 오갈 필요가 없다고 생각한다.)

그래서 public and private vs private과 고민을 해야했었다.

 

 

control plane에 VPC 외부에서 접근할 수 있는가(kubectl을 로컬에서 쉽게 사용 가능한가)에 대한 것과
control plane과 node 들 간의 통신이 VPC 내부에서 가능한가에 대한 것이라고 한다.

 

aws blog 에서 친절히 설명해주고 있다. EKS cluster는 두개의 VPC로 구성된다. - kubernetes control plane을 호스팅하는 AWS 관리형 VPC - kubernetes node를 호스팅하는 고객 관리형 VPC로, container에 클러스터에서 사용하는 load balancer와 같은 다른 고객관리형 AWS 인프라도 이곳에서 실행된다. 클러스터 생성 전에 고객 관리 VPC를 생성해야 한다.(아니면 eksctl이 자동 생성) + 클러스터 생성시 두 개 이상의 VPC 서브넷 지정하고, X-ENI에 배치한다. Kubernetes API server는 교차 계정 ENI를 사용하여  customer-managed 클러스터 VPC 서브넷에 배포된 노드와 통신 worker node가 control plane에서 kubectl 명령을 수신하는 작업 순서는 아래와 같다. 1. EC2 instance start : kubelet+kubernetes node agent는 각 인스턴스의 부팅 프로세스의 일부로 시작됨 2. kubelet은 kubernetes cluster endpoint에 연결해 node 등록(VPC 외부의 퍼블릭 엔드포인트 또는 VPC 내부의 프라이빗 엔드포인트에 연결) 3. Kubelet은 API 명령을 수신하고 엔드포인트로 정기적인 상태 및 하트비트를 전송 - Public - Public + Private endpoint - only private endpoint ref : https://aws.amazon.com/ko/blogs/containers/de-mystifying-cluster-networking-for-amazon-eks-worker-nodes/

 

만약에, private를 택해서 cluster를 생성한다면?

VPC 내부에서 control plane 에 접근 가능한 bastion 역할을 할 EC2 인스턴스를 만들고 적절한 권한 부여 후 로컬에서 bastion을 통해 kubectl 을 실행하는 것과 같이 진행해야 한다. or VPN 사용

 

Public and private

control plane 에 대한 접근을 public 으로 만들고 K8S RBAC(Role-based Access Control) 및 AWS IAM을 이용해 kubectl 이용 권한을 관리함

 

---

 

VPC 추가

우리 회사는 VPC가 어느정도 구축이 되어있었는데

172.30.0.0/16, 172.31.0.0/16 가 되어있어서, 아, 그러면 나는 172.32.0.0/16 로 해야겠다!

라고 생각했다.

그러나 그러면 안된다. 해당 CIDR 블록들은 private network 용도로 할당된 주소들이었다.

서로 겹치지 않도록 분산해서 선택한 것인데,

172.32.0.0/16은 사설 IP 범위가 아니라고 한다.

 

RFC 1918에서 정의된 사설 IP 범위는 아래 3개 뿐이라고 한다.

그래서 만약에 172.32.0.0/16은 public ip 대역이라,

AWS VPC에 지정하면 라우팅 충돌 위험이 있고, AWS가 막을 수 있다고 한다.

+ 추가로 172.17.0.0/16 은 일부 AWS 서비스에서 사용한다고 한다! 사용 지양!

(와,, 몰랐으면 나중에 이슈 생길 뻔 했네.. 씸꿍)

그러면 172.29.0.0/16을 EKS를 위한 VPC CIDR 블록으로 사용해야겠다.

 

 

그러면 아래처럼 생성이 완료된다.

 

---

 

서브넷(Subnets)

기본적으로 이전 필드에서 지정한 VPC에서 사용 가능한 모든 서브넷이 사전 선택된다. 두 개 이상 선택 필수

 

 public 서브넷만 사용

• 동일한 퍼블릭 서브넷 : 노드 + 인그레스 리소스(예: 로드 밸런서)
• kubernetes.io/role/elb 로 퍼블릭 서브넷에 태그를 지정하여 인터넷에 연결된 로드 밸런서를 구성
• 이 구성에서 클러스터 endpoint 은 public, private 또는 둘 다(public and private)로 구성

private and public 서브넷 사용

• 프라이빗 서브넷 : 노드 | 퍼블릭 서브넷 : Ingress 리소스 인스턴스화
• 클러스터 endpoint 에 대한 public, private 또는 둘 다(public and private) 액세스를 활성화
• 클러스터 엔드포인트의 구성에 따라 노드 트래픽은 NAT 게이트웨이 또는 ENI를 통함

private 서브넷만 사용

• 프라이빗 서브넷 : 노드 + 인그레스
• kubernetes.io/role/internal-elb 서브넷 태그를 사용하여 내부 로드 밸런서
• EC2와 모든 Amazon ECR 및 S3 리포지토리에 대해 AWS PrivateLink를 활성화
• 클러스터의 private endpoint 만 활성화

 

✔ 보안 그룹(Security groups) - (선택 사항) 생성하는 네트워크 인터페이스에 Amazon EKS가 연결하려는 보안 그룹을 하나 이상 지정

그래서 생성해주고, 할당해주었다.

밑에 새로고침하는 버튼을 누르면 불러오는 부분이 리프레쉬된다.

 

나머지는 다 기본 설정으로 두었다.

 

 

클러스터 엔드포인트 액세스

Kubernetes API 서버 엔드포인트에 대한 액세스 권한을 구성(kubectl과 같은 Kubernetes 관리 도구 사용)

 

세가지의 설명은 아래와 같다.

Public  - 제어부 - EKS owned ENI - worker node(kubelet) - worker node - public domain - 제어부 - 사용자(Kubectl) - public domain - 제어부 Public + Private - 제어부 - EKS owned ENI - worker node(kubelet) - worker node - private domain, EKS owned ENI - 제어부 - 사용자(Kubectl) - public domain - 제어부 클러스터의 VPC 내 Kubernetes API 요청은 private VPC endpoint 사용 VPC 내에서 kubernetes API 요청이 VPC 내 X-ENI를 통해 control plane 과 소통 *X-ENIs(Cross-Account ENIs, 교차 계정 ENIs)는 EKS control plane 에서 생성 → VPC 내부의 kubernetes API 요청) VPC 내부의 교차 계정 ENIs를 통해 EKS control plane에 접근 → VPC 외부의 kubernetes API 요청) 인터넷을 통해 EKS control plane에 접근 Private - 제어부 - EKS owned ENI - worker node(kubelet) - worker node - private domain, EKS owned ENI - 제어부 - 사용자(Kubectl) - private domain, EKS owned ENI - 제어부 인터넷에서 API 서버로 퍼블릭 액세스 X 모든 kubectl 명령은 VPC 또는 연결된 네트워크 내에서 가져와야 함

 

두가지(퍼블릭 및 프라이빗 / 프라이빗)를 해보려고 한다.

 

 

관찰성 구성

활성화할 로그 유형을 선택적으로 선택할 수 있다. 기본적으로 각 로그 유형은 비활성(Disabled)

추가 기능 선택

일단 선택이 되어있는 것을 그대로 진행

- Amazon VPC CNI, kube-proxy, 노드 모니터링 에이전트, CoreDNS, Amazon EKS Pod Identity 에이전트

- External DNS, 지표 서버

 

 

 

 

 

검토 및 생성

 

 

 

aws eks update-kubeconfig --region ap-northeast-2 --name eks-luna

또 무한한 기다림

근데 지금은 vpn 을 끄지 않은 상태인데 접근이 가능한 것 같다.

 

연결 완료

 

출처 및 참고

- https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html

- https://aws.amazon.com/ko/blogs/containers/de-mystifying-cluster-networking-for-amazon-eks-worker-nodes/

- https://datatracker.ietf.org/doc/html/rfc1918

- https://www.getoutsidedoor.com/2021/03/30/rfc1918-%EC%A0%95%EB%A6%AC-address-allocation-for-private-internets/

- https://docs.aws.amazon.com/eks/latest/userguide/network-reqs.html

- https://malwareanalysis.tistory.com/787

- https://www.gomgomshrimp.com/posts/aws/eks-auto-mode

- https://aws.amazon.com/ko/blogs/containers/getting-started-with-amazon-eks-auto-mode/

- https://distro.eks.amazonaws.com/

- https://techblog.woowahan.com/10221/

- https://docs.aws.amazon.com/eks/latest/userguide/getting-started-console.html

- https://kschoi728.tistory.com/81