목차

1. EKS 란?

2. EKS Cluster의 엔드포인트 타입

3. 생성하기

  • VPC
  • Subnet
  • SG
  • IAM Role
  • VPC Endpoint
  • ECR
  • EKS
  • 워커노드

 

EKS 란?

EKS 는 컨트롤 플레인을 직접 구성하지 않고 AWS 에서 관리하여 K8S 를 손쉽게 사용할 수 있도록 편리함을 제공해주는 매니지드 서비스이다. 우리가 EKS Cluster를 생성을 하면, 클러스터는 우리 계정에서 확인이 되지만, 실제 컨트롤 플레인은 AWS의 VPC 에서 생성된다. 

따라서 컨트롤 플레인과 우리가 셋팅한 워커노드가 통신이 되게끔 설정하는 것이 이번 포스팅의 핵심이다.

 

kubectl 을 통해 컨트롤 플레인의 api 서버를 찌르고, etcd에 저장된 aws_auth 에 선언된 권한을 확인해 클러스터에 접근할 수 있다.

현재는 eks 에서 access api 를 따로 제공해서, api 방식과 aws_auth configmap 방식을 둘 다 제공하고 있다.

 

쿠버네티스는 매우 빠른 주기로 마이너 버전을 업데이트 하는데, 이때문에 1년에 4번 정도는 클러스터 업그레이드를 진행해야 한다.

현재 eks에서 지원하는 버전은 보통 5~6개의 마이너 버전을 지원하며 (현재 1.25~1.29), 평균 3개월마다 새 버전 제공한다. 처음 14개월을 지원하고, 12개월 연장이 가능하지만 비용이 추가 될 수 있다. - 링크

  • v1.25.Y → Major.Minor.Patch ⇒ Major(Breaking Changes) . Minor(New Features) . Patch(Bug fixes Security)

 

 

기본적으로 클라우드에서 제공하는 managed k8s 서비스는 위와 같은 구성을 갖는다. 

EKS 의 ControlPlane 과 워커노드는 아래와 같은 특징을 가진다.

ControlPlane

 

managed k8s 서비스는 API 서버가 아닌 cloud-controle-manager 가 실제 엔드포인트로 질의를 받아 처리하는데, API 부하분산을 ALB가 아닌 NLB를 사용한다. 컨트롤 플레인의 영역은 동적으로 스케일링 되는데, 이 때에 부하 분산이 가장 중요하다. 빠른 확장성, 낮은 지연시간, 초고성능의 특징 때문에 ALB 대신 NLB를 사용한다.

DataPlane

 

EKS 의 워커노드는 쉽게 구분하자면, EC2를 워커노드로 사용할 거냐, Fargate를 사용할거냐로 나뉜다. EC2를 사용한다면, 관리형을 사용할거냐, 직접 관리할거냐로 나뉜다. 

  • Managed node groups (관리형 노드 그룹) : 최신 EKS Optimized AMI를 사용 - 링크, AWS에서 AMI 관리, Capacity(On-Demand, Spot) - 링크
  • Self-managed nodes : Custom AMI를 사용, ASG 직접 관리, OS 기본구성/패치를 고객이 직접 관리 - 링크
  • AWS Fargate (서버리스) : 고객은 별도의 EC2관리할 필요 없이, AWS Fargate 환경에서 제공하는 Micro VM을 이용하여 Pod 별 VM 할당 - 링크

EKS owned ENI

관리형 노드 그룹의 워커 노드는 내 소유지만, 연결된 ENI(NIC)의 인스턴스(관리형 노드)는 AWS 소유이다. ENI는 가용영역 별로 생성되며, kubelet과 통신한다.

따라서 kubectl 로 exec로 접근하면 접근하는 IP 는 ENI의 IP 가 확인된다. 통신경로가 api 서버 통해서 eni 통해서 접근하기 때문이다.

# kubelet, kube-proxy 통신 Peer Address는 어딘인가요?
for i in $N1 $N2; do echo ">> node $i <<"; ssh ec2-user@$i sudo ss -tnp; echo; done

# 참고
APIDNS=$(aws eks describe-cluster --name $CLUSTER_NAME | jq -r .cluster.endpoint | cut -d '/' -f 3)
dig +short $APIDNS

# [터미널] aws-node 데몬셋 파드 1곳에 bash 실행해두기 
kubectl exec daemonsets/aws-node -it -n kube-system -c aws-eks-nodeagent -- bash

# exec 실행으로 추가된 연결 정보의 Peer Address는 어딘인가요? >> AWS 네트워크 인터페이스 ENI에서 해당 IP 정보 확인
for i in $N1 $N2; do echo ">> node $i <<"; ssh ec2-user@$i sudo ss -tnp; echo; done
...
ESTAB 0      0      [::ffff:192.168.1.129]:10250 [::ffff:192.168.1.7]:38238 users:(("kubelet",pid=2933,fd=9))
...

EKS Cluster 의 엔드포인트 타입

AWS 에는 EKS cluster 엔드포인트 타입이 3가지가 있다.

  1. Public
  2. Private
  3. Public & Private

이 엔드포인트는 kubectl 명령어를 날릴 엔드포인트라고 생각하면 쉽다.

 

1. EKS Cluster Endpoint - Public : 

Public cluster는 말 그대로 클러스터의 엔드포인트와 워커 노드의 트래픽이 전부 퍼블릭을 통해서 통신한다는 의미이다. 그래서 이 경우, 엔드포인트를 사용하지 않아도 통신이 되지만, 보안상의 문제로 운영에서는 사용을 권장하지 않는다.

  1. 사용자 kubectl → (퍼블릭 도메인) 제어부
  2. 워커노드의 kube-proxy와 kubelet → (퍼블릭 도메인) 제어부
  3. 제어부 → (EKS owned ENI) 워커노드 kubelet

클러스터의 퍼블릭 엔드포인트만 활성화된 경우 클러스터의 VPC 내에서 시작되는 Kubernetes API 요청(예: 작업자 노드와 제어 플레인 간 통신)은 VPC에서 나가지만 Amazon의 네트워크에서는 나가지 않는다. 노드가 제어 플레인에 연결하려면 공용 IP 주소와 인터넷 게이트웨이에 대한 경로 또는 NAT 게이트웨이의 공용 IP 주소를 사용할 수 있는 NAT 게이트웨이에 대한 경로가 있어야 한다.

여기서 그럼 ENI로 들어오는 트래픽은 s3와 같은 서비스를 어떻게 사용할까? 워커노드가 올라가는 서브넷의 라우팅 테이블이 nat gw와 연결되어 인터넷 게이트웨이를 타고 ecr이나 s3 에 접근할 수 있다.

 

kube-proxy와 kubelet은 kube-api의 NLB IP와 동일한데, 아래 내용으로 확인 가능하다.

# kube-api 주소 확인
$ kubectl cluster-info
Kubernetes control plane is running at https://ED33C3C0E78B1FFD02B473D88D029CBA.gr7.ap-northeast-2.eks.amazonaws.com
CoreDNS is running at https://ED33C3C0E78B1FFD02B473D88D029CBA.gr7.ap-northeast-2.eks.amazonaws.com/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy


# kube-api 주소의 NLB IP 확인
$ dig +short  ED33C3C0E78B1FFD02B473D88D029CBA.gr7.ap-northeast-2.eks.amazonaws.com
43.200.250.77
15.165.245.171

# kubelet, kube-proxy 통신 Peer Address 확인
ssh -i ~/.ssh/id_rsa ec2-user@$N1 sudo ss -tnp | grep kube
ESTAB 0      0               192.168.2.66:54444          43.200.250.77:443   users:(("kube-proxy",pid=3087,fd=11))
ESTAB 0      0                  127.0.0.1:51208              127.0.0.1:44121 users:(("kubelet",pid=2842,fd=30))
ESTAB 0      0               192.168.2.66:52938         15.165.245.171:443   users:(("kubelet",pid=2842,fd=16))
ESTAB 0      0      [::ffff:192.168.2.66]:10250 [::ffff:192.168.1.249]:48716 users:(("kubelet",pid=2842,fd=7))

2. EKS Cluster Endpoint - Private : 

Private 은 아예 반대로, 엔드포인트와 워커노드의 트래픽이 VPC 내부에서 이루어져, 외부에서 접근할 수 없다. 

 

  1. 사용자 kubectl → (내부 도메인) 제어부 : 따라서 VPC 안에 있거나 연결된 네트워크 망안에서 가능
  2. 워커노드의 kube-proxy와 kubelet → (내부 도메인) 제어부
  3. 제어부 → (EKS owned ENI) 워커노드 kubelet

프라이빗 엔드포인트만 활성화된 경우 클러스터 API 서버에 접근할 수 있는 NLB 가 프라이빗 IP 만 보유하고 있다. 따라서, 모든 트래픽은 클러스터의 VPC 또는 연결된 네트워크 내에서 발생해야 한다. 노드는 NLB의 프라이빗 IP를 통해 제어부에 접근할 수 있다. kube-proxy와 kubelet이 물고 있는 엔드포인트의 IP가 노드는 NLB의 프라이빗 IP라는 의미다. 또한, VPC 외부에 있는 서비스를 사용하기 위하여 필요한 VPC Endpoint 를 생성해주어야 한다.

 

3. EKS Cluster Endpoint - Public & Private :

클러스터의 엔드포인트는 퍼블릭이고, 워커노드의 트래픽이 VPC 내부에서 이루어지는 혼합형이다. 외부에서 접근이 가능해 바로 배포가 가능하다. VPC endpoint 를 생성하지 않아도, 서브넷에 Nat gw가 라우팅 되어 있다면 인터넷을 통해 s3와 ecr 등에 접근이 가능해서 vpc endpoint 는 굳이 만들지 않아도 되지만, 인터넷을 통한 트래픽 비용이 많이 나오는 경우라면 VPC endpoint 를 생성해주는 것이 좋다.

 

  1. 사용자 kubectl → (퍼블릭 도메인) 제어부
  2. 워커노드의 kube-proxy와 kubelet → (내부 도메인) 제어부
  3. 제어부 → (EKS owned ENI) 워커노드 kubelet

만약 Public → Public & Private 으로 변경하는 경우, 기존 kube-proxy와 kubelet이 물고 있는 엔드포인트의 ip는 변경되지 않는다. 따라서 재시작을 해주어야 하는데, kube-proxy는 Pod 여서 rollout 명령어로 가능하지만, kubelet 은 노드 별 프로세스로 돌고있어서 노드마다 프로세스를 재시작 해주어야 한다.

💡 사실 Public & Private 와 Private 의 보안 이슈를 정확히 파악하지 못했다. Public & Private 의 경우 엔드포인트가 퍼블릭인데, 보안그룹으로 회사 ip와 auth-config (iam에 mfa 를 걸어두고 권한 제한) 로 제어를 하는 것과 무조건 bastion을 통하는 것의 차이가 큰지…
>> Private + bastion 이 권장되며, Public & Private 의 경우 엔드포인트가 퍼블릭이기 때문에 데이터가 탈취될 가능성이 있다고 한다. 그러나, 보안이 완전 빡센 환경만 아니라면, 엔드포인트에 접근할 ip 제어와 RBAC 관리 등으로 조절은 가능하다. 보통 회사의 보안 정책과 요구사항을 고려하여 적절한 방법을 사용한다고 한다.

 

여기서 의문 이였던 게, 퍼블릭 & 프라이빗 인 경우에 VPC 엔드포인트 설정이 필요없어?? 이전에 퍼블릭 & 프라이빗으로 변경 했을 때, VPC 엔드포인트가 없으니 네트워크 이슈가 생겼었는데?? 였다. 생각해보니, 바로 위의 이유로 재시작을 해줘야 했는데, 그과정을 안거치면서 네트워크 이슈가 생겼던 것 같다.

 

생성하기

AWS 에서 public & private eks cluster 를 생성해 보자. 아키텍쳐는 아래와 유사하다.

VPC

VPC의 아래 두 옵션은 활성화를 확인해야 한다.

# Enable DNS resolution
  enable_dns_support   = true

  # Enable DNS hostnames 
  enable_dns_hostnames = true

두 옵션은 프라이빗 호스팅 영역에서 DNS 쿼리를 위해 설정하는 값이다. DNS hostname 은 인스턴스에 DNS name 을 부여한다. 이를 통해 인스턴스를 쉽게 찾고 통신할 수 있다. 도메인 이름을 사용하여 VPC 내 리소스를 참조할 수도 있다. DNS resolution은 managed service의 엔드포인트 도메인의 프라이빗 ip 주소를 확인할 때 사용된다.

VPC에는 NAT와 IGW를 생성해 준다.

subnet

프라이빗 서브넷의 경우 endpoint와 eks가 올라갈 서브넷을 나누어서 생성한다.

alb ingress controller를 위해서는 서브넷에 특정 태그를 달아줘야 한다. 그래야 올라갈 서브넷을 태그기반으로 찾아 동작하기 때문이다.

앞단에 alb 가 올라갈 public 서브넷과 internal 이 올라갈 프라이빗 서브넷에 아래와 같이 태깅해 준다.

# eks - alb ingress controller 를 위한 태깅.
  public_subnet_tags = {
    "kubernetes.io/cluster/${eks_cluster_name}" = "shared"
    "kubernetes.io/role/elb"                  = 1
  }
  private_subnet_tags = {
    "kubernetes.io/cluster/${eks_cluster_name}" = "shared"
    "kubernetes.io/role/internal-elb"         = 1
  }

SG

현재 아키텍쳐에서 보안그룹을 생성하여 적용하는 서비스는 endpoint와 eks 이다. 이중 필수로 생성해야 하는 보안그룹은 엔드포인트의 보안그룹이며, eks 의 보안그룹은 기본으로 생성되는 보안 그룹으로만으로도 생성 가능하다.

endpoint 의 sg

먼저 endpoint의 보안그룹을 생성한다.

보안그룹의 인바운드는 서브넷의 CIDR 를 소스로 하고 모든 트래픽을 받는 규칙을 하나 추가해 준다. 보안상으로는 조금 위험해서 실제 사용할 때에는 서브넷 단위로 더 작은 범위를 설정하겠지만, 지금은 테스트여서 간단하게 vpc 범위에 있는 모든 트래픽을 sg에서 추가하도록 한다.

추가로 넣어야 하는 규칙은 엔드포인트를 사용하는 리소스의 보안그룹을 허용하는 규칙이다. 엔드포인트가 https 로 통신해서 포트는 443만 허용해주면 된다. 현제 케이스의 경우 eks 에서의 트래픽만 허용하면 되므로 eks 의 보안그룹을 추가해주어야 한다. eks 의 보안그룹은 eks 생성될 때 자동으로 생성되는 보안그룹을 이후에 추가해 주면 된다.

대략 완료가 되면 이런 형태가 된다.

eks 의 sg

eks 는 생성을 하고 나면 자동으로 생성이 되는 보안그룹과 생성하여 추가로 연결할 수 있는 보안그룹이 있다.

  • 자동으로 생성이 되는 보안그룹

자동으로 생성되는 보안그룹은 자체 트래픽을 받는 규칙과 클러스터에 관한 태그가 붙은 상태로 생성된다. 이 태그 값을 가지고 이후에 클러스터가 내부 통신을 위하여 인바운드 규칙을 알아서 조절한다. 해당 보안그룹이 노드그룹에도 적용된다.

  • 추가 보안그룹

만약 클러스터에 따로 규칙을 추가하고 싶다면, 생성하여 연결할 수 있다. 클러스터 생성 시 붙이는 보안그룹이 추가 보안그룹에 해당된다. 이 보안그룹은 클러스터에만 적용이 되어, 노드그룹에는 적용되지 않는다.

IAM Role

EKS Cluster Role

클러스터에서 노드를 확인하고 보안그룹을 사용하는 등등의 작업에 대한 권한이 필요하다. 예를들어, 스케쥴러가 노드를 확인하고 파드를 올리거나 하는 등의 작업에서 필요한 권한들을 전부 포함하고 있는 것이다.

EKS - Cluster 로 role 을 생성한다.

 

생성 후 아래 정챙을 추가한다. AmazonEKSClusterPolicy 의 경우 EKS - Cluster 로 생성시 자동으로 연결된다.

# AmazonEKSClusterPolicy 
-> Kubernetes가 사용자를 대신하여 리소스를 관리하는 데 필요한 권한을 제공. 
-> 인스턴스, 보안 그룹, 탄력적 네트워크 인터페이스를 포함

# AmazonEKSVPCResourceController 
-> VPC 리소스 컨트롤러가 워커 노드의 ENI 및 IP를 관리하는 데 사용하는 정책

# KMS 권한에 대한 정책 생성

{
        "Action": [
            "kms:Encrypt",
            "kms:Decrypt",
            "kms:ListGrants",
            "kms:DescribeKey"
        ],
        "Effect": "Allow",
        "Resource": "클러스터에 적용된 KMS ARN"
    }

-> 암호화를 사용하는 경우 KMS 권한

 

클러스터에 적용된 KMS ARN 은 eks cluster 콘솔에서 개요 탭에서 적용된 kms 를 확인할 수 있다.

Fargate Role

Fargate를 사용하는 경우 만들어야 하는 Role이다.

Fargate 는 pod 1개당 fargate 하나가 뜬다. 각 fargate 당 가지고 있는 role 이 네트워크와 ecr에서 이미지를 가져올 수 있는 정책이 연결되어야 한다.

Role 은 eks-fargate-pods sts role 로 생성한다.

 

생성 시 AmazonEKSFargatePodExecutionRolePolicy 가 연결된 채로 생성이 되는데, pod에서 ecr로 접근해 이미지를 가져올 수 있는 권한이다.

role 생성 후 정책 추가로 AmazonEKS_CNI_Policy 정책을 추가해 준다.

# [AmazonEKSFargatePodExecutionRolePolicy](https://us-east-1.console.aws.amazon.com/iam/home?region=us-east-1#/policies/details/arn%3Aaws%3Aiam%3A%3Aaws%3Apolicy%2FAmazonEKSFargatePodExecutionRolePolicy) 
-> pod에서 ecr로 접근해 이미지를 가져올 수 있는 권한

# [AmazonEKS_CNI_Policy](https://us-east-1.console.aws.amazon.com/iam/home?region=us-east-1#/policies/details/arn%3Aaws%3Aiam%3A%3Aaws%3Apolicy%2FAmazonEKS_CNI_Policy)
-> ENI를 연결해 주기 위한 정책으로, 워커노드에서 CNI가 동작했을 때, ENI 를 붙이기 위한 정책

Node Group Role

노드그룹을 사용하는 경우 만들어야 하는 Role이다.

노드 그룹의 경우, ec2 가 생성이 되고 해당 ec2안에서 여러개의 pod 가 생성되는 구조이기 때문에 노드의 정보를 가져올 수 있는 권한이 추가로 필요하다.

EC2 role 로 생성한다.

 

해당 role은 아무 정책도 연결안된 상태로 생성이 되는데, 아래 3개의 정책을 추가하여 role 을 생성하면 된다.

# AmazonEKSWorkerNodePolicy
-> 워커노드가 리소스 관리를 위해서 aws ec2 리소스의 정보를 읽어올 때 사용된다. 
-> ec2의 타입, 라우팅테이블, 서브넷, 보안그룹, 볼륨, vpc, eks 클러스터 정보를 가져올 수 있다.
-> 추가로, eks 클러스터 내에 특정 파드가 aws 리소스에 액세스하기 위해 iam 역할을 허용하는 권한이 추가되어 있다.

# AmazonEC2ContainerRegistryReadOnly
-> ec2에서 ecr로 접근해 이미지를 가져올 수 있는 권한

# AmazonEKS_CNI_Policy
-> ENI를 연결해 주기 위한 정책으로, 워커노드에서 CNI가 동작했을 때, ENI 를 붙이기 위한 정책

 

fargate role 에는 ec2 에 대한 정책을 추가하지 않는데, fargate 는 pod 1개당 fargate 하나가 생성이 되면서 각각이 노드로 적용된다. 따로 노드를 읽어서 리소스를 확인하고 새로 생성되거나 서브넷을 확인하거나 할 필요없이 각각의 fargate의 ip 만 안다면 서로 통신할 수 있기 때문에 이러한 권한을 추가하지 않는 것으로 보인다.

endpoint

VPC 내부에서 연결을 위해 vpc endpoint 를 생성해야 한다. aws vpc 에 있는 컨트롤 플레인에서 내부 네트워크 연결로 리소스가 연결되어야 하기 때문이다.

관련된 엔드포인트는 아래와 같다.

 

그 중 위의 4개는 필수 항목이고, 나머지는 필요에 따라 만들면 되는데, 예를들어 fargate 를 사용하는 경우 아래 5개를 추가하여 사용한다.

  • com.amazonaws.ap-northeast-2.s3 (gw)
  • com.amazonaws.ap-northeast-2.ecr.api
  • com.amazonaws.ap-northeast-2.ec2
  • com.amazonaws.ap-northeast-2.sts (fargate 사용시 필요)
  • com.amazonaws.ap-northeast-2.ecr.dkr

s3 gateway 는 eks 가 올라갈 서브넷을 묶은 라우팅테이블에 붙여준다. (gw 로 올리는 이유는 비용때문이다. 인터페이스 타입은 비용이 나가지만, gw 는 비용이 추가되지 않는다. )

나머지 엔드포인트의 경우, ap-northeast-2b에서는 올라가지 않는다. ap-northeast-2a와 ap-northeast-2c 에 올라갈 수 있게 해주자.

위에서 생성한 엔드포인트 보안그룹을 적용해서 생성해주고 완료한다.

ECR

ECR 은 컨테이너 레퍼지토리로, 배포할 이미지를 저장하는 서비스다.

클러스터에서 ECR 에 있는 이미지를 가져갈 때, 1. 네트워크가 연결되어 있는지, 2.ECR 경로가 일치하는지 3. 적절한 권한이 있는지를 확인해야 한다.

1번의 경우 endpoint를 설정을 잘 했다면 문제 없이 해결될 것이다.

2번은 배포할 때 참조하는 ECR 주소를 주의하도록 하자.

3번이 제일 중요한데, 클러스터를 생성할때의 iam role을 넣어주어야 한다.

권한은 Delete 권한을 제외한 전부를 주어도 되지만, 좀 더 나눠 준다면 아래 값으로 체크해서 생성하면 된다.

# ReadWrite
ecr:CompleteLayerUpload
ecr:InitiateLayerUpload
ecr:PutImage
ecr:UploadLayerPart

# ReadOnly
ecr:BatchCheckLayerAvailability
ecr:BatchGetImage
ecr:DescribeImageScanFindings
ecr:DescribeImages
ecr:DescribeRepositories
ecr:GetAuthorizationToken
ecr:GetDownloadUrlForLayer
ecr:GetLifecyclePolicy
ecr:GetLifecyclePolicyPreview
ecr:GetRepositoryPolicy
ecr:ListImages
ecr:ListTagsForResource

그 외에 ECR 에서 참고해야할 내용들은 추후 서술하겠다. (Tag, Lifecycle Policy…)

EKS

이제 본격적으로 클러스터를 생성해보자. EKS 는 클러스터를 생성 후 워커노드를 구성하여 Pod 를 올릴 수 있다. 따라서 클러스터 생성과 워커노드를 만드는 것은 별개라는 것을 기억하자. 클러스터만 만들고 pod 가 안올라간다고 하면 안된다는 거다..

일단 EKS 콘솔에서 생성버튼을 눌러 클러스터를 생성해보자 .

 

이름과 버전을 정해주는데, 버전은 다른 것과 맞춰야하는게 아닌 이상 최신버전이 좋다. 버전이 생각보다 빠르게 업데이트 되므로 생성 후에도 업데이트를 자주 해줘야 한다.

위에서 생성한 IAM Role 도 적용해준다.

그 다음 네트워크로 넘어가면, 생성해 두었던 VPC와 subnet, sg 를 추가해 준다.

 

위에서 언급했듯이 이번에는 Pub & Pri 로 선택하고 넘어가자

 

addon 은 eks 에 붙이는 플러그인이라고 생각하면 된다. 아래 3개는 디폴트 옵션이니 확인 후 넘어가면된다. (이 세개는 EKS 의 네트워크를 담당하는 중요한 아이들이다..)

 

 

생성이 완료되고 나면, 아래 명령어로 EKS 접근이 가능하다.

만약 설치가 안되어있다면 awscli 와 kubectl 은 먼저 설치 해야 한다.

aws configure
aws eks --region ${region} update-kubeconfig --name ${cluster}
kubectl config use-context arn:aws:eks:${region}:${account_id}:cluster/${cluster}

워커노드의 타입

EKS 는 워커노드의 대상을 EC2 와 Fargate로 설정할 수 있다. 각각 장단점이 다른데, Fargate 의 경우 서버리스로 간단하게 사용할 수 있지만, pod 가 늘어날 때, 일반 노드에서 올리는 것보다 다소 시간이 소요될 수 있다. 

EC2를 사용하는 방법은 다시 두가지로 나뉘는데, 매니지드 노드그룹과 커스텀 노드그룹이 있다. EKS 콘솔에서 만들 수 있는 노드그룹은

매니지드 노드그룹으로, 설정 몇번으로 생성이 가능하며, 워커노드가 생성되면 EC2 콘솔에서 노드를 확인할 수 있다. 커스텀 노드그룹은 본인이 노드그룹을 커스텀하여 구성해서 연결하는 방식이다.

이번에는 간단하게 만들 수 있는 Fargate와 매니지드 노드그룹의 생성과 특징만 정리하였다.

Fargate

  • Fargate는 profile을 생성해야 사용할 수 있다.
    • EKS 콘솔 > 클러스터 선택 > Compute 탭 선택 > 하단 Fargate profiles 에서 add Fargate profile
    • 서브넷은 클러스터에서 선택된 서브넷이 기본으로 잡힌다. 변경이 필요하지 않다면 그대로 넘어가도 된다.
  • selector로 namespace와 label를 정할 수 있다. 이때 생성하려는 namespace 값이 fargate profile 에 반드시 존재해야 해당 namespace 에 pod 가 올라갈 수 있으니 주의하자
  • 클러스터 생성시 addon 으로 선택했던 coredns는 fargate 를 찾지 못해 올라가지 못한다. 이 친구로 클러스터 내 dns 동작이 되므로, pod가 올라가지 못하면 네트워크 이슈가 생기므로 아래 명령어로 fargate에 올리도록 하자. ec2를 찾아 올라가라는 어노테이션을 제거하는 명령어이다
  • kubectl patch deployment coredns \ -n kube-system \ --type json \ -p='[{"op": "remove", "path": "/spec/template/metadata/annotations/eks.amazonaws.com~1compute-type"}]'

Node Group

  • EKS 콘솔 > 클러스터 선택 > Compute 탭 선택 > Add node group 으로 생성할 수 있다.
  • 생성시 워커노드에 적용할 IAM role을 지정해야한다. ec2로 치면 iam profile 과 동일하다.
  • 생성될 노드에 label과 taint를 설정할 수 있다. 특정 pod 를 노드를 지정해서 올리고자 할 때 사용하기 좋다.
  • 그다음 서버의 타입과 사이즈 등등을 정하고, 서브넷도 정해 생성할 수 있다.
  • aws_auth Configmap 에 node의 role 이 추가되어 있어야 접근 가능하다.
  • 노드그룹을 사용할 거라면, karpenter를 사용해서 올리는 것이 리소스 활용도 면에서는 좋은 것 같다.

 

Terraform code sample :

https://github.com/o-dev-lab/eks-terraform-sample.git

 

GitHub - o-dev-lab/eks-terraform-sample: k8s 강의를 위한 eks 생성 테라폼 코드

k8s 강의를 위한 eks 생성 테라폼 코드. Contribute to o-dev-lab/eks-terraform-sample development by creating an account on GitHub.

github.com

* samples/basic_s3_backend 내용 참고. (+ 가시다님이 제공해 주신 작업 인스턴스의 user_data 적용) 

'가시다님 AEWS' 카테고리의 다른 글

[가시다's AEWS] 2주차 AWS LBC 설치하기  (1) 2024.03.17
[가시다's AEWS] 2주차 EKS Networking  (0) 2024.03.17
[가시다's AEWS] 1주차 Terraform 으로 Fargate Only EKS Cluster 배포해보기  (0) 2024.03.09

+ Recent posts

티스토리툴바