🔗 eksctl 깃헙

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

If you are running a stateful application across multiple Availability Zones that is backed by Amazon EBS volumes and using the Kubernetes Cluster Autoscaler, you should configure multiple node groups, each scoped to a single Availability Zone. In addition

docs.aws.amazon.com

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}

'...' 카테고리의 다른 글

[AWS] S3 퍼블릭 액세스 차단을 활성화 하면서 객체에 접근하는 방법을 알아보자!! (0)	2022.06.28
[Kotlin] 데이터 집합 표현에 data 한정자를 사용하라 (0)	2022.06.16
[Spring] Security +Google Oauth2 + JWT 구현하기 (4) - JWT 재발급 해주기 (0)	2022.06.05
[Spring] Security +Google Oauth2 + JWT 구현하기 (3) - 생성한 JWT에 대해 인증/인가 하기 (0)	2022.06.05
[Spring] Security +Google Oauth2 + JWT 구현하기 (2) - JWT에 권한 추가해주기 (0)	2022.06.04