Kubernetes를 써보긴 해봐야겠어요.
회사에서는 고객에게 솔루션을 구동하도록 안내해야 했기 때문에 Kubernetes를 선택하기 어려웠다.
B2G로 납품되는건 서버 대수가 적을수록 도입비용이 낮아지고, 이게 경쟁력이 높아지다보니 힘들었고
고객사에서 먼저 Kubernetes로 요청하는 경우가 몇번 있었지만, 구성과 인수인계 후 내 손을 떠나버렸기 때문에 조금 그랬다.
그래서 언젠가는 직접 쿠버네티스 클러스터를 운영 해봐야 한다는 마음은 있었다.
홈랩에 쿠버네티스가 꼭 필요하냐고 하면 그건 아니긴 했지만…
사실상 모든 회사들은 이걸 요구하는게 트렌드다 보니 강점으로 보일수도 있겠다 싶었다.
집에 NAS로 시작해서 홈랩이 되어버린 서버에 Ubuntu를 올려 서비스를 돌리던 VM이 있었는데 SSD가 고장으로 설정이 통째로 날아갔고
그동안 잘 관리하던 compose.yml 파일이 홀라당 날라가버리면서 비통한 마음을 뒤로하고 다시 세팅하려니 한숨밖에 안나왔다.
그래서 이참에 도커로 돌리던 서비스들을 쿠버네티스 클러스터로 마이그레이션 해보자고 마음먹고
가상 머신 몇 개를 띄워서 실습용 클러스터를 만들어보기로 했다.
내 NAS였었던 홈랩 스펙은 이정도로 한참을 썼다.
- CPU: Ryzen 3600
- RAM: DDR4 24GB
- DISK: 8TB HDD * 2, 500GB SSD * 1
클러스터 구성
클러스터로 로드밸런싱도 경험하고 컨트롤 플레인 문제도 겪어보고 싶어서 노드 구성은 이렇게 계획했다.
컨트롤 플레인 3대, 워커 2대
컨트롤 플레인이 3대인 이유로는 etcd의 투표(?) 기반 리더 선출 후 리더의 주장을 모두 따라가는 컨센서스 특성상
투표 결과가 50%가 넘는 과반으로 종료되어야 한다. 50%로 끝나버리면 이후 진행이 어려워지는거다.
그래서 홀수 개수로 컨트롤 플레인 개수를 유지하는게 좋다고 하고, 사양도 모자르니 3대로 구성하는걸로 했다. 노드 1대가 장애가 나는 상황을 생각해보면 3대 구성도 문제가 있긴 하지만, 시작을 할수 있긴 하니까…
워커 노드는 실제 작업을 담당할 노드라서 1대만 두어도 상관은 없다.
근데 클러스터고 로드밸런싱도 해보고 싶은데 정작 워커 노드가 1개인건 좀 아닌것 같아서 2대로 결정했다.
배포판 고르기
국내 블로그에선 보통 k3s를 많이 쓰는 것 같다. 근데 조금 고민해볼수록 이상했다.
k3s를 설치해봤는데 Kubernetes 전에 우분투부터 세팅해서 5대 운용할 생각을 하니 너무 할일이 많았다.
Ansible Playbook 작성해서 돌리면 되겠지만 가볍게 만들자고 etcd도 빼버리는 배포판인데
배포판 설치를 위해 리눅스를 설치하고 거기에 수많은 서비스가 딸려오는걸 보면서 어라? 싶었다.
그렇다고 1대만 두고 쓰자니 docker compose 놔두고 뭐하는 짓인가 하는 생각이 떨쳐지질 않았다.
가뜩이나 8코어 16쓰레드, 24GB 램에 가상머신을 5대나 올려야 하는데
우분투 5대가 최소사양으로 돌아갈 생각을 하니 이건 아니다 싶은 생각은 깊게 자리잡았다.
그래서 다른걸 찾기 위해 k3s alternative 를 검색해보다 보니 Reddit에서 Talos Linux를 추천하는 댓글이 많아서 찾아봤다.
뭔가 딱 이거다 싶었은 구성에 OS를 배포하는 모습조차 인상적이었고
어차피 현업에서 쿠버네티스를 하게될때는 EKS나 GKS같이 컨트롤 플레인을 매니지드 서비스로 쓰게될텐데
리눅스 OS 설정 가지고 고생하는게 시간버리는것 같다는 생각도 들어서 Talos Linux로 결정했다.
Talos Linux는 어떤 친구인가
Talos Linux는 Sidero Labs가 만든, Kubernetes 전용 리눅스다.
사용자가 쉘로 접속해서 이것저것 만지는 방식을 버리고, talosctl과 gRPC API로 모든 설정을 바꾼다.
루트 파일 시스템은 읽기 전용 SquashFS로 올라가고, SSH와 일반 쉘은 아예 제공하지 않는다.
결국 “운영체제를 직접 만지는 일”을 줄여서 예측 가능성과 보안을 높이려는 선택이다.
멱등성 강조하던 Ansible을 보다가 이런 구조를 보니 너무나 매력적으로 보였다.
Ubuntu Pro 사용을 위해서 필수인 Snap 같은 것들도 다 치워버릴 수 있고,
추후에 VM에 문제가 생겨도 쉽게 복구할 수 있을것만 같아보였고, 설정파일들을 Github에 올려두면
우분투 백업이니 Ansible Playbook이니 하는것들 다 치워버려도 되는것 아닌가.
다들 그렇게 강조하는 IaaC를 홈랩 인프라에서도 실현시킬 수 있을것 같아 보였다.
VM 스펙 구성
CPU
이거 때문에 찾아보다보니 vCPU 라는 존재에 대해 자세히 알게 됐다.
난 당연하게도 VM에 CPU를 할당 해준다고 해서, 진짜 코어나 쓰레드가 그 VM에 엮이는 줄만 알았다.
근데 이건 CPU Pinning 이라고 하고 vCPU는 말 그대로 가상 CPU 그 자체였다.
어차피 실제 작업은 Host OS에서 스케줄러가 적절히 분배해서 처리할테니
코어나 쓰레드 개수보다 조금 더 줘도 문제가 생기진 않고, 이걸 OverCommit이라고 하는거였다.
이제 AWS의 t 시리즈 인스턴스가 CPU 사용에 크레딧 같은걸 두고 제한하는지 대략 짐작이 가는 부분이었다.
Talos Linux의 문서에서 권장이 4 Core 라서 오버커밋도 알게된 겸, 다 4코어씩 할당했다.
RAM
24GB 메모리에서 5노드를 모두 VM으로 띄우면 여유가 빠듯하다. Talos의 문서 기준으로 최소/권장 사양은 아래와 같다.
- 최소: 컨트롤 플레인 2GiB, 워커 1GiB, 디스크 10GiB.
- 권장: 컨트롤 플레인 4GiB, 워커 2GiB, 디스크 100GiB.
처음 시작할 때는 크게 필요없을것 같아서 2GB로 통일해서 시작했다.
지금은 HostOS에 도커로 돌리고 있는 서비스도 혼재되어있는 상태라서 2GB로 결정한 것도 있다.
Sidero Labs의 레퍼런스 아키텍처는 컨트롤 플레인에 넉넉한 메모리를 권장하니,
길게 운영하다보면 아마 이런저런 문제가 생길거고 그때 트러블슈팅하는 상황도 글로 남겨볼 수 있을것 같다.
vDisk
스토리지는 특히 주의. Talos는 설치 디스크를 이미지 기반 업그레이드를 위해 완전히 장악한다.
남는 파티션을 워크로드 용도로 쪼개 쓰는 구조가 아니다.
OS는 작은 전용 디스크에 설치하고, 워크로드/스토리지는 다른 디스크를 쓰는 구성이 권장된다.
나는 이미 HostOS가 8TB 정도의 파티션을 NFS로 공유할 수 있어서,
20GB 정도의 디스크만 할당해서 시작했다. 컨테이너 이미지 사이즈 정도만 감당할 수 있으면 되는듯?
가상화는 KVM/Proxmox 모두 잘 될거같다. 딱히 문제가 될거같지 않아보인게,
왠만한 클라우드별 이미지가 다 준비되어 있었기 때문에 부딪혀보면 될듯
설치는 어떻게 진행할까(예고)
이번 글은 OS 선정 배경과 설계 메모를 정리한 수준이다.
다음 편에서는 실제로 클러스터를 부팅하고, talosctl로 초기화하는 과정을 다뤄봐야겠다.
- ISO/이미지로 부팅, 노드 네트워크 확인
talosctl gen config로 설정 생성,talosconfig준비- 컨트롤 플레인 3대, 워커 1~2대 배치(리소스에 맞춰 조정)
talosctl bootstrap으로 초기화, 대시보드로 상태 확인- 시행착오와 자원 튜닝 정리
사실 이 글을 작성하는 시점에선 이미 설치해서 초기 구성까진 끝냈다.
딱히 어려웠던 부분은 없는데 세팅한거보다 글 쓰는게 더 시간이 오래 걸리고 있다. ㅋㅋㅋ
마무리
Talos Linux는 “또 하나의 리눅스”가 아니다.
쉘과 SSH를 지우고, 불변 이미지와 API로 운영을 고정시킨, Kubernetes 전용 운영체제다.
어쩌면 EKS, GKE 같은 관리형 컨트롤 플레인이 운영 환경의 대부분인 상황에서
홈랩과 같은 베어메탈 환경에서 비슷한 경험을 줄 수 있는 몇 안되는 OS가 아닐까 싶다.
집에서도 한 번 다뤄보면 얻는 게 분명히 있을것 같다. 다음 글에서 설치기를 이어가겠다.