관리 콘솔을 통해서 EKS를 배포해보자.
그림의 숫자를 보며 순서대로 진행된다.
(1) 관리콘솔에서 EKS를 생성하면 컨트롤 플레인이 EKS 클러스터의 AWS Managed VPC영역에 생성된다.
이 때 AWS가 컨트롤 플레인에 접근하여 etcd 생성, API 서버 생성 등 필수적인 작업을 수행하기 위해서는 적절한 권한이 필요하다.
(2), (3) 따라서 적절한 권한을 가진 IAM Role을 생성하는 작업이 선행되게 된다.
(4) 다음으로 myeks-host 인스턴스에 kubeconfig를 통해서 EKS 클러스터 정보를 업데이트한다.
이를 통해서 myeks-host 인스턴스가 EKS 클러스터에 접근하고 관리할 수 있게된다. 즉, kubectl 명령을 내릴 수 있게 된다.
(5) 노드를 구성하기 위해서 관리형 노드 그룹을 생성한다.
이 때, 노드 그룹에 AWS EC2를 배치해야하므로 EKS에서 EC2를 배치하기 위한 적절한 권한을 가진 IAM Role이 필요하다.
(6) 따라서, 이러한 권한을 가진 IAM Role을 생성한 뒤, 노드 그룹에 연결하여 생성해 주도록 한다.
IAM 역할 생성에 들어가서 AWS 서비스 중 EKS-Cluster에 대한 IAM 역할을 생성한다.
이후 이름을 지정하고, 역할을 생성한다.
권한 정책을 열어보면 오토스케일링이나, EC2, ELB 등을 관리할 수 있는 권한을 부여한다는 정책들이 들어있다.
신뢰 정책을 살펴보면 Service": ["eks.amazonaws.com"]
으로, Amazon EKS 서비스가 이 역할을 맡을 수 있고, Action: "sts:AssumeRole"
로 AWS 자원에 접근하여 작업하는 것을 허용한다고 되어있다.
이제 EKS 클러스터를 생성해보자.
클러스터 서비스 역할에 들어가는 부분이 이전에 생성했던, EKS Cluster Role이 된다. 여기서는 MyeksClusterRole이라는 이름으로 생성했었다.
서브넷을 지정할 때 퍼블릭 서브넷 2개만 지정한다.
또한 EKS API에 접근하는 엔드포인트에 대해서는 퍼블릭을 설정함으로써 NLB의 퍼블릭 IP를 통해서 접근할 수 있도록 한다.
💡 여기서 지정하는 서브넷은 클러스터와 통신을 하기위해 AWS에서 관리하는 컨트롤 플레인이 ENI를 배치할 사용자의 VPC의 서브넷이고, 실제 노드가 배치되는 서브넷과는 다르다.
이로써 AWS 어딘가에 위치할 AWS Managed VPC는 다음과 같이 구성된다.
엔드포인트가 퍼블릭이므로 인터넷 게이트웨이가 있고,서브넷이 생성되고 컨트롤플레인의 구성요소가 배치된다.
myeks-host에 생성한 클러스터 정보를 kubeconfig에 등록(업데이트) 해야지만 생성한 클러스터에 접근할 수 있다.
🤗🔥 항상 잘 모르고 실행했던 바로 그 명령어가 이것이다.
kubeconfig 파일을 생성하고, 이를 업데이트 해줘야 kubectl
명령으로 EKS 클러스터에 접근하고 명령 내릴 수 있다.
// ⭐ EKS 클러스터 정보 업데이트
aws eks update-kubeconfig --region $AWS_DEFAULT_REGION --name $CLUSTER_NAME
// kubeconfig 정보 확인
cat ~/.kube/config | yh
// kube_ps1 비활성화 (클러스터 이름:AZ가 표시되는 기능)
kubeoff
// 생성한 Kubernetes 서비스 확인
kubectl get svc
관리 콘솔을 통해서 생성할 수도 있지만, 이번에는 CLI 방식으로 노드그룹이 사용할 역할을 생성해 보도록 하자.
이 역할은 EKS에서 노드그룹이 EC2노드를 생성하고 관리하기 위한 권한들을 가진다.
노드그룹 역할에 들어갈 필수적인 권한 3가지
- AmazonEKSWorkerNodePolicy
- AmazonEC2ContainerRegistryReadOnly
- AmazonEKS_CNI_Policy
IAM Role을 사용할 수 있는 신뢰 엔터티를 먼저 만든다.
신뢰 정책을 살펴보면 Service": ["ec2.amazonaws.com"]
으로, Amazon EC2 서비스가 이 역할을 맡을 수 있고, Action: "sts:AssumeRole"
로 AWS 자원에 접근하여 작업하는 것을 허용한다고 되어있다.
// EKS 노드 IAM 역할의 신뢰 대상 지정 파일 생성
cat <<EOT > node-role-trust-policy.json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
EOT
// EKS 노드 IAM 역할 생성 (eksNodeRole)
aws iam create-role \
--role-name eksNodeRole \
--assume-role-policy-document file://"node-role-trust-policy.json"
// EKS 노드 IAM 역할에 정책 연결
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy \
--role-name eksNodeRole
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly \
--role-name eksNodeRole
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy \
--role-name eksNodeRole
실제 콘솔에서 확인해보면 다음과 같이 역할과 신뢰관계 그리고 구권한까지 잘 할당되어 생성된 것을 확인할 수 있다.
이전에 생성한 eks 노드 Role을 지정하여 노드 그룹을 생성해 주도록 하자.
나머지는 전부 기본 설정으로 설정한다.
노드가 위치할 서브넷을 선택할 수 있다.
이 때, 기본적으로 EKS를 생성 할 때 지정한 서브넷(여기서는 퍼블릭서브넷 2개)이 나오게된다.
즉, EKS의 서브넷(ENI가 배치된 서브넷)과 동일한 서브넷에 노드를 배치시켜 주도록 하자.
ENI가 없는 서브넷에 배치해도, 같은 VPC 내에서 작동하긴 하니까 워커노드가 컨트롤 플레인에 등록되고 또 인식이 가능한지는 모르겠다.
EC2 노드에 직접 접근할 일이 있다면 다음과 같이 원격 엑세스 권한을 허용으로 설정해준다.
보안 그룹이 자동으로 생성되어 있으므로 이를 사용하면 된다.
생성된 결과는 다음 그림과 같다.
EKS를 퍼블릭 방식으로 생성했기에 EKS API 서버 엔드포인트 주소가 NLB 타입으로 노출되어 있는 것을 확인할 수 있다.
NLB를 통해서도 HTTP 통신이 가능하므로 웹으로 접속해보면 다음과 같이 엔드포인트에 접속할 수 있는 것을 확인할 수 있다.
노드 그룹을 확인해보면 ASG가 자동으로 생성된 것을 확인할 수 있다.
Reference📎 | CloudNet@와 함께하는 Amazon EKS 기본 강의