6 POSTS
회사에서 "API Gateway를 걷어내고, 쿠버네티스 앞에 LoadBalancer를 직접 붙여서 외부로 노출하자"는 작업을 맡게 됐다. 그런데 막상 들여다보니 나는 Ingress가 뭔지도 제대로 몰랐다. "외부 요청이 들어와서 서버가 응답한다" 정도로만 알고 있었지, 그 사이에 LoadBalancer니 Ingress Controller니 하는 것들이 몇...
> 외부 트래픽은 어떻게 Pod까지 닿는가를 먼저 읽으면 좋다. 그 글이 "LoadBalancer 타입 Service를 선언하면 클라우드가 LB를 만들어준다"까지 다뤘다면, 이 글은 선언했는데 안 만들어질 때 어디서부터 파고드는지를 다룬다. 공인 진입점 전환 작업에서 외부 전용 ingress-nginx controller를 배포했다. controller P...
> 선언한 LoadBalancer가 안 만들어질 때의 후속 편이다. 그 글에서 "클러스터 내부 인증 경로가 죽었다"까지 격리해 놓고 플랫폼 문의로 넘겼는데, 답이 왔고 원인은 예상보다 훨씬 사람 냄새 나는 것이었다. 클러스터를 만든 사람의 권한이 사라져 있었다. 관리형 쿠버네티스에서 LB 발급, 볼륨 생성, 클러스터 업그레이드가 몇 달에 걸쳐 하나씩 죽어...
> 관리형 클러스터는 누구의 권한으로 클라우드를 만지는가의 후속 편이다. 그 글에서 클러스터 신원 문제를 해결하고 나서야, 원래 하려던 일 — API Gateway를 걷어내고 공인 LoadBalancer를 그 자리에 앉히는 작업 — 을 이어갈 수 있었다. 이 글은 LB가 뜬 다음부터의 이야기다. API Gateway를 걷어내기로 한 이유는 단순했다. 5MB...
ingress controller를 하나 추가하는 작업은 "차트 만들고 배포하면 끝"일 줄 알았다. 그런데 실제로는 그 과정에서 처음 보는 개념들에 계속 걸렸다. annotation으로 설정을 관리하는 방식, admission webhook이 만드는 self-lock 위험, whitelist, Pod 분산 배치, 그리고 리소스 사양까지. 하나하나는 작지만,...
> 외부 트래픽은 어떻게 Pod까지 닿는가와 ingress-nginx 운영에서 부딪힌 디테일들을 먼저 읽으면 좋다. 이 글은 그 다음 단계로, 그때 걸어둔 whitelist가 실제로는 아무도 막지 못하고 있었다는 이야기다. 사내 전용으로 열어둔 검증 환경에 whitelist-source-range를 걸어놨다. kubectl get ingress로 보면 허용...