[K8S] EKSCTL 를 이용한 EKS 구성

🔗 eksctl 깃헙

🔗 eksctl 공식 문서

🔗 eksctl config file example

 

eksctl 설치

curl --silent --location "<https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$>(uname -s)_arm64.tar.gz" | tar xz -C /tmp
sudo mv /tmp/eksctl /usr/local/bin
eksctl version

---

EKS 구성

eks 는 아마존의 쿠버네티스 서비스이며, eksctl 은 eks 를 쉽게 구성할 수 있도록 도와주는 커맨드 툴

• eksctl 공식 문서는 굉장히 친절한 편이라고 생각

💡 eksctl 은 EKS 를 위한 커맨트 툴이므로 aws configure 가 된 상태여야 함

aws 로그인

aws configure

---

1. Using Config Files (가장 기본)

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: basic-cluster
  region: eu-north-1 

nodeGroups:
  - name: ng-1
    instanceType: m5.large
    desiredCapacity: 10
    volumeSize: 80
    ssh:
      allow: true # will use ~/.ssh/id_rsa.pub as the default ssh key
  - name: ng-2
    instanceType: m5.xlarge
    desiredCapacity: 2
    volumeSize: 100
    ssh:
      publicKeyPath: ~/.ssh/ec2_id_rsa.pub

• nodeGroups[0].ssh : 키의 위치를 명시하지 않으면 자동으로 ~/.ssh/id_rsa.pub 을 따라감

 

eksctl create cluster -f cluster.yaml

• 20~30분 정도 소요됨

 

이후 삭제하기

eksctl delete cluster -f cluster.yaml

---

2. VPC 지정하기

---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: non-eksctl-created-cluster
  region: us-west-2

vpc:
  id: "vpc-12345"
  securityGroup: "sg-12345"    # this is the ControlPlaneSecurityGroup
  subnets:
    private:
      private1:
          id: "subnet-12345"
      private2:
          id: "subnet-67890"
    public:
      public1:
          id: "subnet-12345"
      public2:
          id: "subnet-67890"

nodeGroups:
...

---

3. 다양한 노드그룹의 ssh

managedNodeGroups:
  - name: ng-1
    instanceType: m5.large
    desiredCapacity: 1
    ssh: # import public key from file
      publicKeyPath: ~/.ssh/id_rsa_tests.pub
  - name: ng-2
    instanceType: m5.large
    desiredCapacity: 1
    ssh: # use existing EC2 key
      publicKeyName: ec2_dev_key
  - name: ng-3
    instanceType: m5.large
    desiredCapacity: 1
    ssh: # import inline public key
      publicKey: "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDqZEdzvHnK/GVP8nLngRHu/GDi/3PeES7+Bx6l3koXn/Oi/UmM9/jcW5XGziZ/oe1cPJ777eZV7muEvXg5ZMQBrYxUtYCdvd8Rt6DIoSqDLsIPqbuuNlQoBHq/PU2IjpWnp/wrJQXMk94IIrGjY8QHfCnpuMENCucVaifgAhwyeyuO5KiqUmD8E0RmcsotHKBV9X8H5eqLXd8zMQaPl+Ub7j5PG+9KftQu0F/QhdFvpSLsHaxvBzA5nhIltjkaFcwGQnD1rpCM3+UnQE7Izoa5Yt1xoUWRwnF+L2TKovW7+bYQ1kxsuuiX149jXTCJDVjkYCqi7HkrXYqcC1sbsror someuser@hostname"
  - name: ng-4
    instanceType: m5.large
    desiredCapacity: 1
    ssh: # enable SSH using SSM
      enableSsm: true

 

---

4. managed node group 과 unmanaged node group

managed node group

Managed node groups - Amazon EKS

EKS 관리 노드 그룹은 Amazon EKS 클러스터에 대해 AWS에 의해 관리되는 자동 확장 그룹 및 관련 EC2 인스턴스입니다. 각 노드 그룹은 Amazon EKS에 최적화된 Amazon Linux 2 AMI를 사용합니다. Amazon EKS는 노드에 버그 수정 및 보안 패치를 쉽게 적용할 수 있을 뿐만 아니라 최신 Kubernetes 버전으로 업데이트할 수 있습니다. 각 노드 그룹은 클러스터에 대해 고가용성(HA)을 위해 여러 AWS VPC 가용성 영역 및 서브넷에 걸쳐 있는 자동 확장 그룹을 시작합니다.

 

• 기본적으로 Amazon Linux 2 AMI 사용 (다른 OS 변경 가능)
• 오토 스케일링을 위함
• eks console 에서 관리 가능
• managed , unmanged 모두 한 클러스터 내에서 구성 가능 하지만 unmanaged 는 eks console 에 안보임

 

# cluster.yaml
# A cluster with two managed nodegroups
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: managed-cluster
  region: us-west-2

managedNodeGroups:
  - name: managed-ng-1
    minSize: 2
    maxSize: 4
    desiredCapacity: 3
    volumeSize: 20
    ssh:
      allow: true
      publicKeyPath: ~/.ssh/ec2_id_rsa.pub
      # new feature for restricting SSH access to certain AWS security group IDs
      sourceSecurityGroupIds: ["sg-00241fbb12c607007"]
    labels: {role: worker}
    tags:
      nodegroup-role: worker
    iam:
      withAddonPolicies:
        externalDNS: true
        certManager: true

  - name: managed-ng-2
    instanceType: t2.large
    minSize: 2
    maxSize: 3

unmanaged node group

 

ekctl에서 --managed=false를 설정하거나 nodeGroups 필드를 사용하면 관리되지 않는 노드 그룹이 생성됩니다. 관리되지 않는 노드 그룹은 EKS 콘솔에 나타나지 않으며 일반적으로 EKS 관리 노드 그룹에 대해서만 알 수 있습니다.

 

• config yaml 에서 managedNodeGroups 이렇게 하면 managed, nodeGroups 이면 unmanged
• eks console 에서 관리 불가능

 

---

5. taint

taints:
  - key: your.domain.com/db
    value: "true"
    effect: NoSchedule
  - key: your.domain.com/production
    value: "true"
    effect: NoExecute

• 이런식으로 Node 에 taint 를 할 수 있다.
  • 만약 taint 가 걸린 노드에 파드를 배포하려면, toleration 설정을 파드 스펙에 명시해주면 됨
  • ex) GPU 사용하는 노드에 gpu 테인트를 설정하고, gpu 가 필요한 파드에 toleration 을 해줌

---

6. Instance Selector

eksctl은 vCPU, 메모리 등의 리소스 기준에 따라 인스턴스 유형 목록을 생성하여 이 문제를 해결하는 EC2 인스턴스 선택기와 통합됩니다. 인스턴스 선택기 기준이 전달되면 ekctl은 제공된 기준과 일치하는 인스턴스 유형으로 설정된 인스턴스 유형을 사용하여 노드 그룹을 생성합니다.

# instance-selector-cluster.yaml
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: cluster
  region: us-west-2

nodeGroups:
- name: ng
  instanceSelector:
    vCPUs: 2
    memory: "4" # 4 GiB, unit defaults to GiB

managedNodeGroups:
- name: mng
  instanceSelector:
    vCPUs: 2
    memory: 2GiB #
    cpuArchitecture: x86_64 # default value

 

---

7. Setting the node AMI Family

 

nodeGroups:
  - name: ng1
    instanceType: m5.large
    amiFamily: AmazonLinux2
managedNodeGroups:
  - name: m-ng-2
    instanceType: m5.large
    amiFamily: Ubuntu2004

---

8. Define Container Runtime

🔗 containerd는 무엇이고 왜 중요할까?

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: container-runtime-test
  region: us-west-2

nodeGroups:
  - name: ng-1
    instanceType: m5.xlarge
    desiredCapacity: 2
    amiFamily: AmazonLinux2
    containerRuntime: containerd

• 이 값은 이전 버전과의 호환성을 유지하기 위해 기본적으로 dockerd로 설정되지만 곧 사용되지 않습니다.

잠깐 딴 얘기를 해보자면,

아무 컨테이너도 안보인다. 그 이유는 1.24 부터는 dockerd 가 아닌 containerd 로 동작하기 때문

따라서 containerd 를 볼 수 있는 crictl 이라는 패키지가 필요합니다

• 쿠버네티스에서는 cri표준을 준수하는 컨테이너 런타임을 통합하여 관리하기 위해 crictl이란 명령어 툴을 제공하고 있습니다
• crictl은 docker,ctr과 달리 cri를 준수하는 모든 컨테이너 런타임에 사용이 가능합니다
• 일반적인 패키지 매니저를 통해 kubeadm kubelet등을 설치했다면 자동으로 설치 되어 집니다

vi /etc/crictl.yaml 
runtime-endpoint: unix:///run/containerd/containerd.sock
image-endpoint: unix:///run/containerd/containerd.sock

sudo crictl ps
sudo crictl pods

---

9. Additional Volume Mappings

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: dev-cluster
  region: eu-north-1

managedNodeGroups:
  - name: ng-1-workers
    labels: { role: workers }
    instanceType: m5.xlarge
    desiredCapacity: 10
    volumeSize: 80
    additionalVolumes:
      - volumeName: '/tmp/mount-1' # required
        volumeSize: 80
        volumeType: 'gp3'
        volumeEncrypted: true
        volumeKmsKeyID: 'id'
        volumeIOPS: 3000
        volumeThroughput: 125
      - volumeName: '/tmp/mount-2'  # required
        volumeSize: 80
        volumeType: 'gp2'
        snapshotID: 'snapshot-id'

---

10. Networking

기본적으로 ekctl 클러스터 생성은 클러스터에 대한 전용 VPC를 생성합니다. 이 작업은 보안을 비롯한 다양한 이유로 인해 기존 리소스에 대한 간섭을 피하기 위해 수행되지만 기존 VPC에서 모든 설정을 감지하는 것이 어렵기 때문에 수행됩니다.

eksctl에서 사용하는 기본 VPC CIDR은 192.168.0.0/16입니다. 8개의 서브넷(프라이빗 3개, 퍼블릭 3개, 예약 2개)으로 나뉩니다. --allow-ssh를 지정하지 않으면 SSH 액세스가 비활성화되어 초기 노드 그룹이 공용 서브넷에 생성됩니다. 노드 그룹은 기본적으로 포트 1025 - 65535에서 제어부 보안 그룹의 인바운드 트래픽을 허용합니다.

11. Config file schema

🔗 공식 문서 참고

 

---

외부에서 EKS 마스터 노드에 접근하기

aws configure 확인

aws sts get-caller-identity

 

kube config 에 적용

aws eks --region ${region_name} update-kubeconfig --name ${cluster_name}