8 POSTS
나는 오랫동안 Spring Boot 를 jar 로 말아서 서버에 올리는 방식으로 일했다. 배포는 "서버에 접속해서 기존 프로세스를 죽이고 새 jar 를 띄운다"였고, 그걸로 충분했다. 그러다 쿠버네티스 위에서 도는 서비스를 맡게 됐는데, ArgoCD 화면은 매일 보면서도 그 안에서 무슨 일이 벌어지는지는 몰랐다. Pod 가 왜 이름이 매번 바뀌는지, 왜 서...
> 컨테이너와 쿠버네티스가 필요한 이유에서 "원하는 상태를 선언하면 시스템이 맞춘다"까지 말하고 넘어갔다. 이 글은 그 문장의 내부를 연다. 쿠버네티스를 배우면서 가장 오래 헤맨 건 객체 이름이 아니었다. kubectl apply 를 하면 리소스가 "생긴다"는데, 누가 언제 그걸 만드는지가 안 잡혔다. 명령을 보냈으니 그 명령이 실행되는 거라고 막연히 생각...
쿠버네티스에서 외부 노출 작업을 하다가, Pod니 Service니 Ingress니 하는 단어들이 머릿속에서 자꾸 섞였다. 각각 뉘앙스는 알겠는데 "그래서 이것들이 서로 어떤 관계냐"가 안 잡혔다. 그래서 이 네 가지를 한 번에 정리하기로 했다. 이 네 개의 관계만 잡으면 쿠버네티스의 절반은 이해한 거라고 봐도 된다. 한 문장으로 시작하면 빠르다 — Pod는...
> 핵심 객체 4종에서 Pod 를 "불안정한 실체"로 소개하고 넘어갔다. 이 글은 그 Pod 를 실제로 만들고 유지하는 위쪽 두 층을 본다. ArgoCD 화면을 처음 봤을 때 이해가 안 됐던 게 있다. 내가 만든 건 Deployment 하나인데, 화면에는 api-deployment-7d4b9c 같은 중간 이름이 하나 더 있고 그 밑에 Pod 들이 달려 있었...
kubectl apply를 하면 리소스가 클러스터에 "생긴다". 그런데 그 사이에 뭐가 있는지는 오래 몰랐다. 공인 LoadBalancer를 붙이면서 ingress controller를 내부용·외부용으로 나눴는데, "새 Ingress를 만들면 admission webhook이 검증한다"는 문장이 계속 나왔다. admission이 정확히 어느 단계고, 왜 하...
> 여기까지 오면서 다룬 객체들(Deployment, Service, Ingress)은 전부 YAML 로 쓴다. 이 글부터는 그 YAML 을 어떻게 관리할 것인가로 넘어간다. 객체를 하나씩 배울 때는 YAML 을 손으로 쓰는 게 문제가 아니었다. 문제는 같은 서비스를 alpha · beta · real 세 환경에 올려야 할 때였다. 구조는 똑같고 repli...
> Helm이 "어떤 YAML 을 만들까"를 맡았다면, ArgoCD 는 "그 YAML 을 언제 어떻게 클러스터에 반영할까"를 맡는다. ArgoCD 는 웹 UI 가 있어서 배포 도구처럼 보인다. 그런데 구조를 열어보니 그게 아니었다. ArgoCD 는 2편에서 본 reconcile loop 를 git 까지 확장한 컨트롤러다. 목표 상태의 출처가 etcd 대신...
쿠버네티스에 새 컴포넌트(ingress controller 하나)를 추가하는 작업을 맡고 나서야, 그동안 "어딘가에서 알아서 배포되던" 그 과정의 구조를 처음 들여다봤다. Helm 차트가 뭐고, ArgoCD가 뭘 하고, Application이라는 게 왜 또 따로 있는지. 막상 정리해보니 큰 그림은 단순했다. 그 구조와, 실제로 새 컴포넌트를 추가하려면 어디...