개요

이번 글은 살짝 주제가 살짝 벗어난 외전 격으로, 내가 활용하는 아마존 리눅스 2023에서 노드를 세팅하는지에 대한 내용을 담는다.
아마존 리눅스 2, 아마존 리눅스 2023, bottlerocket 등 다양한 ami들은 저마다 초기화를 하는 방법이 다르게 돼있기에 사용할 ami의 설정 방법을 아는 것이 중요하다.

이 글은 추후에 다른 ami 설정 방법에 대한 내용이 추가될 수 있다.
사전 지식도 이후 추가될 내용이 있을 때 추가하겠다.

사전 지식

cloud-init 파일 형식

Cloud-init은 클라우드 환경에서 인스턴스의 OS 및 소프트웨어 설정을 초기화시켜주는 툴이다.
이 내용은 깊게 다루지 않고, 해당 링크를 참고하자.

여기에서 알아야 할 것은 Cloud-init의 설정 양식이다.
다양한 양식을 활용할 수 있지만, 범용적으로 적용할 수 있는 파일 형식은 바로 MIME 타입이다.

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"

--BOUNDARY
Content-Type: text/cloud-config

#cloud-config
ssh_authorized_keys:
  - ${aws_key_pair.eks_key_pair.public_key}

--BOUNDARY
Content-Type: text/x-shellscript

#!/bin/bash
yum install nvme-cli links tree tcpdump sysstat ipvsadm ipset bind-utils htop -y
mkfs -t xfs /dev/nvme1n1
systemctl stop containerd
rm -rf /var/lib/containerd/*
mount /dev/nvme1n1 /var/lib/containerd
echo "/dev/nvme1n1 /var/lib/containerd xfs defaults,noatime 0 2" >> /etc/fstab
systemctl start containerd
--BOUNDARY--

MIME 타입은 한번에 다양한 파일 형식을 넣을 수 있는 방식으로, 각 형식 간 구분자를 boundary로 지정해주면 된다.
위에서 boundary는 BOUNDARY로 설정이 됐고, 그래서 중간 중간 --BOUNDARY를 통해 구분을 지어주는 것이 보인다.
마지막으로 형식을 종료지을 때는 --BOUNDARY--과 같이 끝에도 마이너스를 붙여주면 된다.

AL 2023에서의 노드 초기화

amazon 2 노드에서는 bootstrap.sh라는 파일을 이용해 초기화를 진행한다.
그래서 관련한 세팅을 할 때는 pre bootstrap, post bootstrap 관련 세팅(테라폼 기준)을 해야 한다.
참고로 이때도 cloud init을 통한 mime 멀티파트 파일을 사용할 수 있다.

그러나 AL 2023에선 yaml 파일로 초기화하는 nodeadm이라는 별도의 툴을 활용한다.^[1]

그리고 이 툴에 유저 커스텀 설정을 하고 싶다면 다음과 같은 방식으로 NodeConfig yaml 파일을 전달하면 된다.
보다시피 content type을 node.eks.aws/v1alpha1로 해서 MIME 형태로 전달하는 식으로 설정하면 된다!
유저데이터에 값을 넣으면 알아서 해당 설정이 병합되도록 돼있다.

NodeConfig에는 크게 5가지의 필드를 넣을 수 있는데, 자세한 것은 api 문서를 참고하자.^[2]

이 사이트에서 설정을 넣는 방법을 간단하게 테스트할 수 있다.[^9]

실습 진행

그럼 이제 컴포넌트인 kubelet, 그리고 인스턴스 스토어를 세팅해보자.

kubelet log file 설정

일단 로깅 파일 설정은 kubelet에 실행 인자를 넣어주는 식으로 이뤄진다.^[3]
하지만 다른 컴포넌트와 같이 사전 구성된 설정 파일을 구성해둔 뒤, 이를 인자로 전달하여 설정하는 것도 가능하다.

그렇다면 이 설정을 어떻게 nodeadm에 전달하는가?

nodeadm api는 여기에서 확인해볼 수 있다.^[4]

    {
      content_type = "application/node.eks.aws"
      content      = <<-EOT
        ---
        apiVersion: node.eks.aws/v1alpha1
        kind: NodeConfig
        spec:
          kubelet:
            config:
              containerLogMaxSize: 50Mi
              containerLogMaxFiles: 10
              containerLogMaxWorkers: 2
              containerLogMonitorInterval: 8s
      EOT
    }

인스턴스 스토어 설정

테라폼 세팅에서 나는 이렇게 추가해봤다.

    {
      content_type = "application/node.eks.aws"
      content      = <<-EOT
        ---
        apiVersion: node.eks.aws/v1alpha1
        kind: NodeConfig
        spec:
          instance:
            localStorage:
              strategy: Mount
      EOT
    },

아울러, 이전에 직접적으로 인스턴스 스토어를 마운팅했었다.
그러나 api 문서를 보다가 인스턴스 스토어 관련 설정 옵션도 존재하는 것을 확인해서 이렇게 세팅했다.

확인

확실히 알아서 마운팅이 진행된 모습이 보인다.
문서를 보니까, 정말 그냥 마운팅만 해주고 끝일 뿐, 이 공간을 활용하기 위한 세팅은 직접 해야 한다...^[5]
이전에 내가 얻은 결론으로, 나는 Containerd의 root 영역으로 두는 게 좋다는 판단인데, 이런 식이라면 내가 커스텀 할 수 없으므로 이 방식은 로컬 프로비저너를 활용하고 싶은 사람에게만 유용하다고 할 수 있겠다.
확실히 attach된 디스크 이름을 항상 정확하게 특정할 수 없는 상황이라면 이 설정은 유효할 것이다.

        yum install nvme-cli -y
        
        # Get a list of instance-store NVMe drives
        nvme_drives=$(nvme list | grep "Amazon EC2 NVMe Instance Storage" | cut -d " " -f 1 || true)
        readarray -t nvme_drives <<< "$nvme_drives"

        for disk in "${nvme_drives[@]}"
        do
          # Format the disk to ext4
          mkfs.ext4 -F $disk
          
          # Get disk UUID
          uuid=$(blkid -o value -s UUID $disk)
   
          # Create a filesystem path to mount the disk
          mount_location="/mnt/fast-disks/${uuid}"
          mkdir -p $mount_location
   
          # Mount the disk
          mount $disk $mount_location
          
          # Mount the disk during a reboot
          echo $disk $mount_location ext4 defaults,noatime 0 2 >> /etc/fstab 
        done

라고 해봐야 사실 이 스크립트를 직접 넣어줘도 된다 ㅋ..
그럼 더 자유롭게 커스텀이 가능할 것이다.

cat /etc/kubernetes/kubelet/config.json.d/00-nodeadm.conf

직접 노드에 들어가서 kubelet 설정은 제대로 들어갔는지도 확인해본다.

success다.

k get --raw /api/v1/nodes/ip-192-168-1-41.ap-northeast-2.compute.internal/proxy/configz | jq '.kubeletconfig | with_entries(select(.key | contains("container")))'

노드의 설정 정보는 kubectl로도 체크할 수 있다.
api서버가 평소에 통신하는, 직접적으로 kubelet이 노출하고 있는 api의 값을 받아오도록 하는 방식이다.

설정이 제대로 이뤄진 것이 확인된다.

번외 - eksctl에서는?

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  kubelet:
	config:
	  containerLogMaxSize: 50Mi
	  containerLogMaxFiles: 10
	  containerLogMaxWorkers: 2
	  containerLogMonitorInterval: 8s
--BOUNDARY--

다른 툴로 세팅하더라도 결국 사용자 데이터에 설정을 넣어주면 된다는 것은 전부 매한가지다.
애초에 Cloud-init을 이용해 인스턴스 초기화를 해주기에, 해당 양식만 잘 맞춰주면 문제는 없을 것이다.

내가 eksctl을 거의 사용하지 않다보니 확실치는 않지만, preBootstrapCommands에 넣어주면 되지 않을까?

결론

ami 별 노드 초기화를 다르게 하도록 세팅됐기 때문에 이를 잘 알고 대처하는 것이 중요하다.
기본적으로 cloud init에 대한 이해가 있다면 다른 세팅 방식을 마주하더라도 크게 어렵지는 않을 것으로 생각된다.

이전 글, 다음 글

• 3W - EFS 드라이버, 인스턴스 스토어 활용: 6
• 4W - EKS 모니터링과 관측 가능성: 8

다른 글 보기

관련 문서

참고