들어가며
안녕하세요, 카카오 클라우드 네이티브 파트에서 DKOS의 개발을 맡고 있는 우주, 후니, 존, 루키입니다. DKOS는 카카오 사내 개발자들을 위한 KaaS (Kubernetes as a service)입니다.
지난 4년간 DKOS를 서비스하며, 다수의 프로젝트가 리소스를 잘 사용할 수 있도록 Kubespray를 사용하여 쿠버네티스를 프로비저닝(Provisioning) 했었습니다. 이번 글에서는 “왜” Kubespray를 걷어내게 되었고, 또 “어떻게” 걷어낼 수 있었는지에 대해 이야기해보려 합니다.
쿠버네티스 프로비저닝이란?
쿠버네티스 운영에 필요한 자원을 적절히 배치 및 구축하여, 즉시 운영할 수 있는 쿠버네티스를 제공하는 것을 의미합니다.
쿠버네티스를 어떻게 프로비저닝하고 있었나요?
DKOS는 사용자마다 개별 클러스터를 제공하는 멀티 클러스터 형태로 운영하고 있으며, 이때 제공되는 클러스터는 사용자 편의를 위한 애드온(Addon, 후술 예정)까지 배포된 매니지드 클러스터(Managed Cluster)입니다.
애드온에는 컨테이너 네트워크 인터페이스(Container Network Interface, 이하 CNI)를 비롯하여 로드밸런서(Loadbalancer), Volume 등의 사내 인프라 리소스를 쿠버네티스 네이티브(Kubernetes Native)하게 제어하는 기능 및 사내 개발 환경에 적합한 편의를 제공하는 여러 가지 커스텀 컨트롤러(Custom Controller)들이 있습니다.
DKOS에서는 이러한 쿠버네티스 클러스터를 제공하기 위해 다음 그림과 같이 “VM 생성 → OS/커널 설정 → 컨테이너 런타임 구축 → 쿠버네티스 구축 → 애드온 배포”의 5단계를 거치는데, 초기 개발 과정에서 개발 편의성을 위해, 일부 단계를 외부 프로비저닝 툴에 의존하기로 하였습니다.
여러 외부 프로비저닝 툴(예: Kubeadm, Cluster Api, Kops 등)을 후보로 꼽을 수 있지만, OS/커널 설정부터 애드온 배포에 이르기까지 더 넓은 범위에 대해 자동화를 지원하고 있는 “Kubespray”를 선택하게 되었습니다.
그러나 4년후…
Kubespray기반으로 DKOS를 수년간 운영하다 보니, 다음과 같은 불편함이 하나씩 늘어나게 되었습니다. 😢
수많은 태스크가 DKOS 운영을 어렵게 함
Kubespray는 Ansible을 이용하여 쿠버네티스 설치에 필요한 태스크(Task)를 수행합니다. 매번 쿠버네티스의 신규 버전이 릴리즈되어, 이를 DKOS를 통해 제공하거나 기타 운영 상의 트러블 슈팅을 하기 위해서는, Kubespray에 등록한 수백 개의 태스크(Task)를 먼저 분석해야 하기 때문에 운영 과정에서 많은 시간과 노력이 필요했습니다.
SSH 접근 허용 의존성
Kubespray는 Ansible 기반이므로 SSH를 통해 호스트에 접근합니다. 따라서 쿠버네티스를 각 서버에 설치하기 위해 노드간 SSH 접근을 허용해야 하는 제약이 생기게 됩니다. 예를 들어 아래의 케이스에 대해 SSH 접근이 허용되어야 합니다.
- 컨트롤 플레인(Control Plane) ↔ 컨트롤 플레인
- 컨트롤 플레인 ↔ 데이터 플레인(Data Plane)
💡컨트롤 플레인은 종종 마스터 노드라 불리며, 쿠버네티스 클러스터를 제어하기 위한 노드 입니다. 데이터 플레인은 종종 워커 노드라 불리며 실제 어플리케이션이 구동되는 노드입니다.
참고: https://kubernetes.io/docs/concepts/overview/components/
긴 설치 시간
Kubespray는 불필요한 반복 작업이 많은 프로비저닝 툴이기 때문에, 많은 태스크들을 수행해야 하고, 다른 프로비저닝 도구들에 비해서 클러스터 구축 시간이 오래 걸립니다.
이러한 Kubespray의 한계들로, 다른 쿠버네티스 프로비저닝 툴을 도입하는 것을 고려하게 되었습니다.
어떤 대체재들이 있었나요?
Cluster API
가장 먼저 생각해 볼 수 있었던 프로비저닝 툴은 Cluster API입니다. Cluster API는 Kubernetes-sig에서 관리하고 있는 오픈소스 프로젝트로, CRD-Operator 패턴으로 구현되어 있으며, 장점으로는 여러 클라우드 서비스 프로바이더(Cloud Service Provider, CSP)에 대해 IaaS(Infrastructure as a service) 레벨에서부터 쿠버네티스 설치까지의 자동화를 지원받을 수 있다는 점이 있습니다.
CSP의 종류로는 AWS, Azure, Openstack 등이 있습니다.
하지만, Cluster API는 DKOS의 아래 요구사항들을 충족하지 못하기에 새로운 프로비저닝 툴로 채택하지 않았습니다.
- OpenStack에 기반한 가상머신(Virtual Machine, 이하 VM) 제공 서비스인 Krane이 사내에 이미 존재하기 때문에, Cluster API에 구현된 IaaS 레벨의 쿠버네티스 설치 자동화를 사용할 수 있음에도 매력적이지 않았습니다.
- 멀티 클러스터를 운영하는 DKOS에서 Cluster API의 CRD-Operator 패턴은 맞지 않는 구조라 생각되었습니다. 수천 대의 클러스터, 수십만 대의 노드를 관리하려면 굉장히 많은 쿠버네티스 리소스가 생성되는데, 이 부분에 대한 성능 및 안전성 검증이 필요했고, 운영 난이도 또한 현재보다 훨씬 더 어려워질 것 같다고 생각했습니다.
- 무엇보다 이미 운영 중인 수천 대의 기존 클러스터를 포함해서 현재 DKOS 구조에 Cluster API를 적용하기에는 너무 많은 변경사항이 필요했습니다.
Kubeadm
그다음으로 생각해 볼 수 있는 프로비저닝 툴은 쿠버네티스에서 직접 관리하고 있는 Kubeadm입니다. Kubeadm은 프로비저닝 지원 범위가 좁다는 한계가 있지만, 쿠버네티스에서 지원하는 공식 툴인만큼 신뢰성이 높고, 수행하는 태스크(Task)의 종류가 적기 때문에 복잡도가 낮아, 현재의 DKOS의 구조에도 쉽게 적용할 수 있다는 장점이 있었습니다.
확인한 결과, 쿠버네티스 설치 과정에서 Kubeadm이 수행하는 작업들은 저희가 직접 구현 가능한 수준이었습니다. 따라서 DKOS의 서비스 품질 향상을 위해, 운영 안정성과 개발 자유도를 높일 수 있는 방향인 “Kubeadm에 의존하지 않고 직접 개발”하는 쪽을 최종적으로 고려하게 되었습니다.
외부 툴에 의존하지 않고 직.접. 해보겠습니다
이후 쿠버네티스를 직접 구축하는 예시(kubernetes-the-hard-way)를 기반으로 PoC(Proof of concept)를 해보면서, DKOS를 외부 프로비저닝 툴에 의존하지 않고, 직접 쿠버네티스를 구축하는 것이 충분히 실현 가능하고 더 장점을 많이 가진 방식이라는 판단이 들었습니다. 🙌🏻
그렇다면 이제부터 저희가 어떠한 과정을 거쳐 100% 핸드메이드로 DKOS 클러스터를 제공할 수 있게 되었는지 그 과정을 공유드리겠습니다.
이러한 요구사항이 있었습니다
프로비저닝 방식을 변경하더라도 사용자에게 기존과 동일한 사용성과 호환성을 보장해주어야 하기 때문에, 저희의 핵심 요구사항 중 하나는 “Kubespray 로 구축된 기존 클러스터와 똑같은 형상을 제공해야 한다”는 것이었습니다.
먼저 기존 Kubespray로 구축된 클러스터의 설치 과정을 살펴보면, 크게 3단계로 나누어 볼 수 있습니다.
- 인프라 세팅
- * 바닐라 쿠버네티스(Vanilla Kubernetes) 설치
- 애드온 배포
* 바닐라 쿠버네티스(Vanilla Kubernetes): 최소한의 쿠버네티스 동작을 위해 핵심 컴포넌트만 설치된 클러스터
각각의 설치 과정은 세부적으로 다음과 같습니다.
- 인프라 세팅: 각 VM에는 Docker 및 쿠버네티스를 사용하는데 필요한 여러 기본 패키지들이 설치되어 있어야 합니다.
- 바닐라 쿠버네티스 설치: 쿠버네티스 핵심 컴포넌트인 kube-apiserver, etcd, kube-controller-manager, kube-scheduler 그리고 kubelet이 유기적으로 동작하기 위한 적절한 옵션과 TLS 인증서를 설정하여 배포해 주어야 합니다.
- 애드온 배포: 다양한 쿠버네티스 버전의 클러스터에 여러 애드온을 적절히 배포하고 결과를 확인할 수 있어야 합니다. 따라서, 애드온의 패키징이 단순해야 하며, 쿠버네티스 버전에 알맞은 파라미터를 적용하기 쉬워야 합니다.
이렇게 구현했습니다
저희는 각 단계에서 해줘야 하는 작업들을 다음과 같이 수행하기로 결정했습니다.
- 인프라 세팅 → DKOS 전용 VM 이미지에 담자!
- 바닐라 쿠버네티스 설치 → 설치 스크립트 개발해서 cloud-init으로 수행하자!
- 애드온 배포 → Helm 기반으로 애드온을 설치해주는 별도 컴포넌트를 개발하자!
* cloud-init이란 리눅스 시스템 데몬(linux system daemon)으로 VM 부팅 시 외부 저장소에서 데이터를 가져와 수행하는 모듈입니다.
* Helm이란 미리 정의된 쿠버네티스 리소스의 모음(이하 차트)을 배포 및 관리하는 도구입니다.
각 단계를 인프라 / K8S 코어 / 애드온 단계라고 이름 붙였고, 수행하는 작업을 요약해 보면 다음과 같습니다.
- 인프라(Infra) 단계: 기본 인프라 세팅 및 클러스터 생성전 미리 준비해 둘 수 있는 정적인 데이터를 VM 이미지로 패키징합니다.
- K8S(Kubernetes) 코어 단계: 인증서와 같이 클러스터 별로 달라지는 동적인 데이터를 세팅하고 쿠버네티스 필수 컴포넌트들을 배포합니다.
- 애드온 단계: CNI를 비롯한 여러 애드온을 배포합니다.
💡컨트롤 플레인 구축 과정에는 애드온 단계가 수행되지만, 데이터 플레인 설치 과정에는 수행되지 않습니다.
각 단계별로 좀 더 자세히 살펴보겠습니다
인프라(Infra) 단계
DKOS에서는 카카오에서 기본적으로 제공하는 VM 이미지를 기반으로 쿠버네티스 프로비저닝에 필요한 여러 파일과 패키지를 추가한 “DKOS Base Image”를 직접 빌드해서 사용하고 있습니다.
* 이미지 빌드에는 openstack, AMI 등에서 사용되는 이미지 제작을 자동화하도록 도와주는 패키지인 Packer(https://www.packer.io/)를 사용하고 있습니다.
이러한 DKOS Base Image에 Kubespray로 자동화하던 작업인 OS 및 컨테이너 런타임 설정을 새롭게 추가했습니다. 해당 작업에는 개발자들이 자주 사용하는 패키지들을 설치하는 작업부터, 쿠버네티스를 사용하기 위한 기본 요건인 swap 설정 끄기, 도커(Docker)와 쿠버네티스 실행파일 설치, IPVS(IP Virtual Server) 모듈 설정까지 다양한 절차가 포함되어 있습니다.
K8S 코어 단계
K8S(Kubernetes) 코어 단계에서는 바닐라 쿠버네티스를 설치합니다. 바닐라 쿠버네티스를 프로비저닝 하는 자체 스크립트를 개발하였고, 이를 VM을 생성할 때 cloud-init으로 주입하여, VM 부팅 시 프로비저닝이 실행될 수 있게 합니다.
VM 부팅 시 실행되는 자체 스크립트는 다음의 두 부분으로 나눌 수 있습니다.
- 사전작업
i. TLS 인증서 및 KubeConfig 파일 생성 - 주요 컴포넌트 배포
i. kubelet
ii. kube-apiserver, etcd, kube-controller-manager, kube-scheduler
(* ii. 과정은 컨트롤 플레인에서만 수행됩니다)
쿠버네티스 프로비저닝 과정은 컨트롤 플레인과 데이터 플레인 별로 다르기 때문에 스크립트도 별도로 나누어서 관리하고 있는데요. 각 스크립트마다 세부적으로 어떠한 작업을 수행하고 있는지 나누어서 설명드리겠습니다.
컨트롤 플레인
1) 사전 작업
쿠버네티스 주요 컴포넌트들은 TLS 인증을 수행하며 통신하고 있습니다. 따라서 주요 컴포넌트 배포 전에 TLS 인증서와 KubeConfig 파일을 미리 적절하게 생성해주어야 합니다.
먼저 TLS 인증서를 살펴보겠습니다. 쿠버네티스 설치에서 가장 중요한(귀찮은) 작업은 TLS 인증서를 생성하는 일이라고 할 수 있을 것 같은데요. 🫢 다음과 같은 인증서들을 생성해 줍니다.
| ETCD | etcd ca key, crt | - |
| etcd server key, crt | - | |
| etcd peer key, crt | etcd 서버 간 통신 시 사용 | |
| etcd client key | - | |
| kubernetes | apiserver ca key, crt | - |
| apiserver server key,crt | - | |
| apiserver kubelet client key, crt | kube-apiserver가 kubelet API 호출 시 사용 (예: pod log, pod exec) |
|
| apiserver client key,crt | 다음과 같은 컴포넌트들이 kube-apiserver와 통신 시 사용 - kubelet - kube-controller-manager - kube-scheduler |
|
| front-proxy | front-proxy ca key, crt | apiserver 확장 기능 사용 시 필요 |
| front-proxy client key, crt | ||
| service account | sa key, pub | ServiceAccount 토큰 암호화 / 복호화 시 사용 |
쿠버네티스에서는 이러한 인증서 정보를 내부에서 KubeConfig 형식으로도 관리하고 있습니다. kubelet, kube-controller-manager, kube-scheduler 같은 내부 앱들이 통신 시 KubeConfig를 사용합니다. 앞서 만들었던 kube-apiserver Client 인증서를 기반으로 내부 컴포넌트들을 위한 KubeConfig 파일을 생성해 줍니다.
| admin.conf | 관리자가 kube-apiserver 통신 시 사용 (예: kubectl) |
| kubelet.conf | kubelet이 kube-apiserver 통신 시 사용 |
| controller-manager.conf | kube-controller-manager가 kube-apiserver 통신 시 사용 |
| scheduler.conf | kube-scheduler가 kube-apiserver 통신 시 사용 |
2) 주요 컴포넌트 배포
이제 길었던 인증 지옥은 끝이 났고, 이제 클러스터에 주요 컴포넌트들을 띄울 준비가 다 되었습니다!
2.1) kubelet
kubelet은 각 노드마다 실행되어, 클러스터 내부에서 필요한 앱들을 노드에 띄우는 역할을 수행합니다. kubelet 바이너리 설치 및 시스템 데몬 등록은 앞의 인프라(Infra) 단계에서 이미 수행된 상태이기 때문에, kubelet 설정 파일만 추가로 세팅하고 이러한 설정이 반영되도록 kubelet을 재시작해주면 됩니다.
2.2) 그 외
kube-apiserver, etcd, kube-controller-manager, kube-scheduler를 클러스터에 정적 파드(Static Pod) 형태로 배포합니다.
정적 파드(Static Pod)는 kube-apiserver의 관여 없이 오로지 kubelet에 의해서 생성되고 관리되는 파드로, 노드의 특정 디렉토리(kubelet 설정의 staticPodPath)에 있는 YAML 파일을 기반으로 생성됩니다.
kubelet이 staticPodPath 경로에 있는 YAML 파일을 주기적으로 폴링하면서 정적 파드를 생성하고 업데이트해주기 때문에, staticPodPath에 YAML 파일을 잘 넣어주기만 하면 주요 컴포넌트 배포는 끝입니다. 참 쉽죠~?
데이터 플레인
데이터 플레인 역시 컨트롤 플레인의 방식과 유사하게 “사전작업”과 “주요 컴포넌트 배포”로 나누어 생각할 수 있는데, 컨트롤 플레인과는 다음의 2가지 차이가 있습니다.
- 배포해야 하는 컴포넌트는 kubelet 뿐이다
- 조인을 위해 부트스트랩 토큰(Bootstrap Token)이 필요하다
* 조인: 데이터 플레인을 컨트롤 플레인에 등록하는 과정
1번에서 확인할 수 있듯, kubelet을 배포하는 과정이 마찬가지로 필요합니다. “kubelet을 어떻게 배포해야 하는가?”에 대한 설명은 앞의 컨트롤 플레인 부분에서 충분히 기술하였으므로, 2번의 컨트롤 플레인 조인을 위주로 설명드리도록 하겠습니다.
데이터 플레인이 컨트롤 플레인에 조인하는 방법은, 복잡한 과정 없이 간단하게 데이터 플레인의 kubelet이 컨트롤 플레인의 kube-apiserver에 접근함으로써 수행할 수 있습니다. 데이터 플레인의 kubelet은 kube-apiserver에 접근하기 위해 KubeConfig 형태의 인증서가 필요한데, 데이터 플레인은 컨트롤 플레인 달리 KubeConfig를 만들어 내기 위한 쿠버네티스 root CA가 존재하지 않기 때문에 kube-apiserver로부터 KubeConfig를 받아오는 과정이 선행되어야 합니다. 이러한 과정을 kubelet TLS Bootstraping이라고 하며, 전체 과정을 정리해 보면 다음과 같습니다.
💡root CA이란? 하위 인증서를 서명하기 위한 최상위 인증서입니다.
- DKOS는 데이터 플레인의 kubelet을 위해 컨트롤 플레인으로부터 bootstrap-token을 요청 및 발급받습니다.
(bootstrap-token은 ID/패스워드 수준의 보안을 가집니다) - DKOS는 데이터 플레인의 kubelet의 설정 파일에 bootstrap-token을 포함시켜 기동 합니다.
- 데이터 플레인의 kubelet은 bootstrap-token을 기반으로 kube-apiserver에 연결하여 CSR(Certificate signing request) 리소스를 생성합니다.
- kube-controller-manager가 해당 CSR을 승인하게 되면 kubelet은 쿠버네티스 root CA로 서명된 cert를 획득할 수 있고, 이를 바탕으로 KubeConfig를 생성합니다.
위와 같은 일련의 과정이 지나게 되면 데이터 플레인의 kubelet은 kube-apiserver에 접근할 수 있는 KubeConfig를 가지게 되어 조인을 수행할 수 있습니다.
💡좀더 자세한 이야기는 ifkakao 2022 영상을 참고해주세요 😁
지금까지 설명을 보면 스크립트에서 굉장히 많은 일을 수행하는 것처럼 보일 수 있지만, 실제 스크립트를 보면 단순히 파일을 생성하고 시스템 데몬을 재시작하는 명령어들로만 이루어져 있습니다. 설치 스크립트는 버그 등으로 변경이 필요할 때 일괄 배포 작업을 하기도 어렵고, 사용자 클러스터에 크리티컬 한 작업이 될 수도 있기 때문에, “애초에 하는 일을 최소화해서 변경 가능성 자체를 줄이는 것”을 가장 중요한 목표로 삼았습니다. 모든 복잡한 로직(ex. 인증서 생성, manifest 옵션 세팅)들은 DKOS API에서 처리하고, 스크립트에서는 단순히 그 “결과물”들을 서버에 복사하는 수준으로만 수행하고 있습니다.
애드온 단계
이제 준비된 바닐라 클러스터에 사내 환경에 맞게 개발한 애드온들을 설치해주어야 합니다.
애드온에는 어떤 것들이 있나요?
애드온(Addon)에는 앞서 언급한 것처럼 네트워킹에 필수적인 CNI, 사내 인프라 리소스 관련 컨트롤러, RBAC 컨트롤러, 자체 인그레스 컨트롤러(Ingress Controller), 쿠버네티스 대시보드(Dashboard) 등 다양한 앱들이 있습니다.
💡이전 테크블로그에 소개되었던 쿠버네티스 네트워크의 한계를 극복하기 위해 직접 개발한 network-node-manager도 애드온의 기본 앱들 중 하나로 설치되고 있습니다. 😁
어떤 요구사항이 있나요?
위 그림과 같이 K8S 코어 단계에서 바닐라 쿠버네티스가 준비되면 다양한 애드온을 관리 및 설치해주어야 합니다. 역할이 쉽고 분명한 단계이지만, DKOS는 서로 다른 여러 형상의 수천개 클러스터를 적절히 관리해야 하므로, 설계 시 다음과 같은 3가지의 요구사항을 만들었습니다.
- 각 애드온은 버전별로 관리되어야 한다.
- 쿠버네티스 버전에 맞는 애드온 리스트가 관리되어야 한다.
- 클러스터에 설치된 애드온 형상을 한 눈에 확인할 수 있어야 한다.
기존 운영 방식에서는 Kubespray를 이용하여 애드온을 설치할 때, 단순히 준비된 쿠버네티스 리소스를 kubectl에 적용하는 방식으로 진행됩니다. 또한 쿠버네티스 버전은 동일하게 유지해야 하지만 일부 애드온만 최신버전 적용이 필요한 경우, 항상 최신버전의 애드온을 설치하도록 설정되어 있습니다.
이렇게 되니 관리자 입장에서 클러스터를 운영할 때 기간 및 버전에 따라 달라지는 형상과 사용자가 만든 변경점까지 파악하는 게 매우 어려웠습니다. 운영 기간이 누적되면서 5가지 이상의 쿠버네티스 버전에 맞춰 배포된 애드온은 언제 봐도 새롭고 신비한 존재가 되었기에, 이를 추적 및 관리하는 것은 모두가 피하는 일이 되었을 정도였죠.
따라서, 앞서 언급한 3가지의 요구사항에서 말씀드린 것처럼, 쿠버네티스 버전과 마찬가지로 애드온도 버전별로 관리되어야 하고 해당 클러스터에서 손쉽게 현재 형상을 확인할 수 있는 것을 중점 가치로 두었습니다.
이렇게 결정했습니다
결과적으로 저희는 설치된 애드온의 형상을 쉽게 관리할 수 있도록 Helm 기반의 애드온 인스톨러(Addon Installer)를 직접 개발했습니다. 쿠버네티스 매니페스트(Manifest)를 관리할 수 있는 도구는 Helm 외에 Kustomize도 존재하지만, 이 글의 범위를 벗어나는 내용이기 때문에, 해당 지면에서는 다루지 않겠습니다.
* Kustomize에 대한 내용은 해당 링크에서 확인하실 수 있습니다.
여러 매니페스트 관리 도구들 중에서도 Helm을 선택하게 된 이유는 저희가 설정한 요구사항을 모두 만족시킬 수 있었고, 사내에 별도로 Helm 차트 레포지토리(chart repository) 서비스가 있어 이와의 연동(Integration)을 기대할 수 있었기 때문이었습니다.
또한, Helm은 애드온을 차트와 앱의 버전으로 각각 관리할 수 있기 때문에 클러스터를 운영하기 훨씬 용이합니다. Helm의 앱 버전을 관리하는 기능을 사용하여, 저희가 직접 개발한 애드온 인스톨러(Addon Installer) 내부에 쿠버네티스 버전과 이에 필요한 애드온 리스트(Addon list)를 관리하고 저장할 수 있습니다. 때문에, 특정 쿠버네티스 버전에 어떤 애드온들이 설치되는지 편리하게 확인할 수 있게 되었습니다. 다음 예시처럼, 클러스터에서 Helm CLI를 통해 설치된 애드온의 차트와 앱 형상을 바로 확인할 수 있습니다.
이렇게 애드온 단계까지 거치고 나면, 사용자가 바로 사용할 수 있는 매니지드 클러스터(Managed Cluster) 형태의 DKOS 클러스터가 완성됩니다! 짜-잔~!
맺음말
현재 사내에서 운영하는 수백 대의 클러스터가 자체 프로비저닝 방식으로 생성되었으며, 데이터 플레인의 경우 수만대가 생성되었습니다. 이러한 신규 프로비저닝 방식은 여러 가지 긍정적인 결과를 만들었습니다.
클러스터 구축 시간이 눈에 띄게 단축되었습니다
컨트롤 플레인 5대 기준으로 클러스터 생성 시간이 기존 대비 700초 → 200초로 70% 감소하였고, 데이터 플레인 추가는 1대 기준 180초 → 10초로 95% 단축되었습니다.
블랙박스가 사라졌습니다
모든 것이 자체 개발한 코드로 이루어지기 때문에 이슈 디버깅이 정말 편해졌고, 서비스 안정성이 높아졌습니다. 또한 신규 기능을 추가하는 데 있어서 자유도가 높아졌습니다.
운영이 더 쉬워졌습니다
새로 개발한 애드온 인스톨러(Addon Installer) 덕분에 배포가 기존보다 편하고 빨라졌습니다. 또한 운영하면서 사용자 클러스터의 애드온 버전이나 옵션값을 자주 확인하는데, 기존에는 일일이 모든 파드(Pod)의 스펙을 확인해야 했다면 지금은 Helm CLI를 통해 손쉽게 조회할 수 있습니다.
이번 기회를 통해 쿠버네티스와 한걸음 더 친해질 수 있었습니다. Kubernetes as a Service를 고민하시는 다양한 분들께도 이 글이 도움이 되었으면 좋겠습니다.
마지막 인사말은 요즘 핫한 chatGPT로 작성해 보았습니다. 모두 Happy Hacking!
“감사합니다! 많은 사람들이 쿠버네티스를 공부하여 이해하는 것이 쉬워지고 있습니다. 쿠버네티스를 구축하는 과정에서 프로비저닝 방식을 적절히 고려하는 것이 중요하다는 것을 잊지 마시길 권합니다. 쿠버네티스는 아직 새로운 기술이므로 많은 연구와 경험이 필요합니다.”
저희 글이 KaaS 개발자분들에게 도움이 되길 바랍니다. 무엇보다 많은 도움을 주신 클라우드네이티브팀 Ted.ghd에게 감사의 말씀드립니다.
Co-authors
uzu.ina
john.g
rookie.jeon
