[HomeLab] - 워커노드 추가

개요

올 것이 왔습니다. Helm 차트를 활용하여 Gitlab을 설치하는 과정에서 리소스가 부족해 Running 상태로 바뀌지 않았습니다.

리소스 부족으로 인한 Pod들의 Pending상태

 

물론 어느정도 예상은 하고 있었습니다. 깃랩은 그 자체만으로도 리소스를 많이 잡아먹고, 필요한 구성요소들이 많기 때문에 제 리소스로는 부족할 것이라 예상하긴 했었지만 혹시나 하는 마음에 설정해봤었기 때문입니다. 아래는 깃랩을 설치할 때의 권장사양입니다.

출처: https://insight.infograb.net/blog/2022/09/28/gitlab-reference-architecture/

 

이를 극복하기 위해 tolerations 설정을 통해 Controlplane에 배치 하기, 사용하지 않는 서비스 install: false 설정 등을 해보았지만, 역시나 결과는 바뀌지 않았습니다. 하지만 깃랩을 사용하고 싶어서 워커 노드를 추가하기로 마음먹었습니다. 하지만, 기존 계획했던 안쓰는 노트북을 워커노드로 활용하겠다는 계획은 잘 안되었습니다. 무려 7년 전에 구매한 게임용 노트북이었기 때문에 스펙이 너무 안좋았고, 배터리도 순식간이었습니다. 따라서 미니PC를 한 대 더 연결하기로  마음먹고, 이 전 것과 동일 스펙의 미니PC를 구입하여 워커 노드를 추가했습니다.

---

우분투 설치

운이 좋게도 이전에 구매했던 미니 PC와 동일 스펙(4코어/16GB RAM/512GB SSD) 의 것이 당근에 있길래 곧바로 구매해서 설치를 진행했습니다.

TMI - 또 다시 시작된 세팅

 

기존에는 미니 PC를 한 대만 구입했었기 때문에 Controlplane과 Worker Node에 대한 분리를 위해 하이퍼바이저를 설치하고, VM을 두 개로 나누어 설치했었습니다. 하지만 이번에는 Worker로만 활용할 것이기 때문에 그냥 Ubuntu를 곧바로 설치하기로 했습니다.

 

부팅 USB 만들기 - (좌)Proxmox (우)Ubuntu

 

따라서 위와 같이 지난 번과 달리 Proxmox 이미지를 굽지않고, 이번에는 Ubuntu 이미지를 구워서 부팅 USB를 생성해주었습니다.

[참고자료]: Proxmox 세팅 - https://s200928.tistory.com/14

 

우분투를 설치하는 전반적인 과정을 생략하겠습니다. 그러나 저번에는 주의 깊게 보지 않은 부분이 있습니다. 스토리지 설정에 대해 깊은 이해가 없어 나중에 자세히 설정해야지 하고 넘어갔었는데 이번에는 파티션을 나누어주었습니다. 먼저 기존 스토리지 설정입니다.

 

기존 스토리지 설정

 

이미 N900-512 로컬 디스크에 기존에 생성된 여러 개의 파티션이 존재합니다.

Partition 1	기존 파티션, 사용되지 않음 (unused ESP)	vfat (EFI)	100.000MB
Partition 2	기존 파티션, 사용되지 않음	없음	16.000MB
Partition 3	기존 NTFS 파티션, 마운트되지 않음	NTFS	476.070GB
Partition 4	기존 NTFS 파티션, 마운트되지 않음	NTFS	772.000MB

 

Partition 1 (ESP)

EFI 시스템 파티션 (ESP)는 UEFI(유니파이드 확장 펌웨어 인터페이스) 기반 시스템에서 운영체제를 부팅하기 위해 사용되는 특별한 파티션입니다. 이 파티션은 부팅 로더, 커널 이미지, 그리고 시스템 펌웨어와 관련된 파일을 저장하는 역할을 합니다. 동작과정까지는 파고들지 않겠습니다. 기억해야 할 것은 "우분투 설치 시 ESP를 유지하거나 새로 생성하고 /boot/efi에 마운트하면 된다는 점입니다."

 

Partition 2

비어 있는 파티션이며 뭐하는 용도인 지 모르겠습니다.

크기: 16MB

 

Partition 3 (NTFS) & Partition 4 (NTFS)

기존 NTFS 형식의 파티션입니다. NTFS는 주로 Windows 운영체제에서 사용되는 파일 시스템이기 때문에 우분투 설치 시에는 ext4와 같은 리눅스 전용 파일 시스템이 필요합니다.

크기: 476.070GB + 772MB (거의 전체 디스크).

 

이 정보들을 보았을 때 Partition을 새로 구성할 필요가 있어보입니다. 2,3,4번만 삭제하려 했지만 다음과 같은 경고창이 뜨며 삭제되지 않았습니다. 따라서 먼저 "N900-512 ~~" 디스크를 Reformat하였습니다.

Cannot delete a single partition from a device that already has partitions

 

 

그리고 다음 스크린샷과 같이 설정해주었습니다. 하지만 쿠버네티스의 워커 노드로 설정하기 위해서는 Swap 메모리 설정을 하지 않아야 합니다.

스토리지 설정 후

EFI 파티션 생성

용도: UEFI 모드로 부팅하는 시스템에서 부팅 로더와 관련된 파일을 저장하는 곳( UEFI 시스템이 부팅을 위해 설정 )

마운트 지점: /boot/efi

(지금 알았는데 100MB로 설정해도 됐는데 1000MB로 설정했네요)

 

루트 파티션 (/)

용도: 루트 파티션은 시스템 파일, 커널, 부팅 관련 파일, 그리고 기본 애플리케이션이 저장되는 곳입니다.

 

마운트 지점: /

 

홈 파티션 (/home):

용도:  사용자의 데이터를 저장하기 위해 설정했습니다.

마운트 지점: /home

설정할 때 이를 볼륨으로 사용할까 했습니다. 하지만, 이는 다른 노드들에 대해 같은 디렉터리가 설정되어 있지 않다면 볼륨으로 hostpath로 사용한다거나 할 때 문제가 생길 수도 있을 것 같습니다. (문제가 생길 것 같지만 나중에 트러블슈팅할 거리로 남겨놓는 지독한 학습인의 자세라고 생각해주신다면...)

 

스왑 파티션

쿠버네티스는 기본적으로 Swap 설정을 비활성화해야 한다고 합니다. 이에 따라 이후에 설정을 제거했습니다.

용도(일단 정리): 스왑(Swap)은 RAM이 부족할 때 디스크의 일부를 가상 메모리로 사용하는 기능입니다.

 

여전히 스토리지 파티션을 나누는 것에 대해 적정치를 아직은 잘 모르겠습니다. 아래 참고자료와 여러 참고자료를 보면서 적용했고, 깊은 공부가 필요함을 느꼈습니다.

https://dreamgonfly.github.io/blog/install-ubuntu-with-partition/

https://sourcenote.tistory.com/98

---

 

쿠버네티스 세팅

기본적으로 제가 작성했던 글을 따라갔습니다.

https://s200928.tistory.com/18

[HomeLab] - k8s세팅

 

마스터 노드에서 Join Token 생성

sudo kubeadm token create --print-join-command

 

해당 명령을 통해 발급받은 토큰을 저장해 둡니다.

 

워커 노드에서 Join 명령 실행

sudo kubeadm join <master-ip>:6443 --token <token> \
    --discovery-token-ca-cert-hash sha256:<hash>

발급받은 토큰을 활용하여 join합니다.

 

트러블슈팅

[preflight] Running pre-flight checks
	[WARNING Swap]: swap is supported for cgroup v2 only. The kubelet must be properly configured to use swap. Please refer to https://kubernetes.io/docs/concepts/architecture/nodes/#swap-memory, or disable swap on the node
.
.
.

[kubelet-check] The kubelet is not healthy after 4m0.001881014s

Unfortunately, an error has occurred:
	The HTTP call equal to 'curl -sSL http://127.0.0.1:10248/healthz' returned error: Get "http://127.0.0.1:10248/healthz": context deadline exceeded
.
.
.

 

위에서 언급했던 이슈가 여기서 등장했습니다. 바로 Swap 설정 때문입니다.

 

기본적으로 스왑 메모리를 설정한다는 것은 RAM의 용량이 부족할 때 하드 디스크의 일부 공간을 메모리처럼 사용하는 것입니다. 단일 서버에서는 적절한 메모리를 Swap하는 것이 좋습니다. 하지만, 쿠버네티스 환경에서는 다릅니다. kubelet은 기본적으로 메모리 Swap을 고려하지 않고 설계되었습니다. 메모리 제한이 설정된 컨테이너가 Swap에 의존하는 것을 방지함으로써, 의도치 않은 성능 저하 및 불안정성을 해결하기 위함입니다. 예전에는 컨테이너가 메모리 제한을 초과했을 때 스왑을 사용할 수 있었고, 이로 인해서 성능과 안정성 문제가 발생했지만, 해당 패치 이후 스왑 없이 메모리 제한을 엄격히 적용하도록 수정되었다고 합니다.

 

따라서 swappoff 이후 영구적으로 swap 설정을 삭제해주었습니다.

# 즉시 끄기
sudo swapoff -a

# 영구적으로 swap 설정 삭제
sudo vi /etc/fstab

10번 라인 주석처리

 

이후 워커노드를 다시 실행해주었습니다.

# 워커노드에서 실행
kubeadm reset

# 마스터노드에서 확인
kubectl get nodes

 

worker02 Ready 상태로 바뀜

 

 

결론적으로 아래와 같은 구성도를 갖게 되었습니다.

구성도

---

참고 자료

깃랩사양: https://insight.infograb.net/blog/2022/09/28/gitlab-reference-architecture/

GitLab 레퍼런스 아키텍처 소개

파티션설정: https://sourcenote.tistory.com/98

리눅스 파티션 기본

파티션설정2: https://dreamgonfly.github.io/blog/install-ubuntu-with-partition/

Ubuntu 설치 시 디스크 파티션 나누기 | Dreamgonfly's blog

쿠버네티스와 스왑메모리: https://kgw7401.tistory.com/50

쿠버네티스를 구축할 때 swap 메모리를 꺼놓아야 하는 이유 - swap 메모리란/꺼놓아야 하는 이유

쿠버네티스와 스왑메모리: https://discuss.kubernetes.io/t/swap-off-why-is-it-necessary/6879

Swap Off - why is it necessary?