![]()
쿠버네티스 네트워킹 글을 보다 보면 이제 거의 공통된 메시지가 보인다. Ingress를 계속 쓸 수 있느냐가 아니라, 언제 어떤 방식으로 Gateway API로 넘어갈 것이냐가 더 현실적인 질문이 됐다는 점이다.며칠 전에는 왜 Gateway API가 중요해졌는지 개념 위주로 정리했는데, 오늘은 그 다음 단계로 가보려 한다. 실제 운영 관점에서 더 중요한 건 개념 소개보다 어떻게 안전하게 옮길 것인가다.특히 최근 Kubernetes 공식 블로그에서 Ingress2Gateway 1.0이 발표되면서 이 흐름은 더 분명해졌다. 단순히 새 API를 배우는 수준이 아니라, 기존 Ingress-NGINX 설정을 Gateway API로 옮기는 구체적인 도구와 가이드가 같이 나오고 있다.이 글은 Ingress-NGINX..
쿠버네티스를 공부하다 보면 한 번쯤 이런 생각이 든다. Service, Ingress까지는 익숙해졌는데, 요즘은 왜 다들 Gateway API 이야기를 할까.나도 처음에는 이름만 보고 Ingress의 대체재 정도로 가볍게 생각했다. 그런데 최근 Kubernetes 공식 문서와 SIG Network 쪽 흐름을 다시 보면서 느낌이 좀 달라졌다. 이건 단순히 새 리소스 하나가 나온 정도가 아니라, 쿠버네티스 네트워킹을 다루는 방식 자체를 더 구조적으로 바꾸려는 흐름에 가깝다.특히 최근 Ingress를 정리하면서 더 분명해졌다. Ingress는 분명 단순하고 빠르게 시작하기 좋은데, 운영 요구사항이 조금만 복잡해져도 annotation이 늘어나고, 컨트롤러마다 동작이 달라지고, YAML이 점점 읽기 어려워진다...
쿠버네티스를 처음 공부할 때 꽤 자주 막히는 부분이 Service와 Ingress다. 이름은 익숙한데 막상 문제로 나오면 머리가 잠깐 멈춘다. ClusterIP는 내부 통신용이라고 외웠고, NodePort는 외부 접근용이라고 들었고, LoadBalancer도 있고, Ingress도 있는데 이걸 언제 어떻게 구분해서 써야 하는지 애매해진다.나도 처음엔 그냥 외웠다. 그런데 조금 지나니까 외운 건 금방 섞였다. 특히 CKA 문제를 풀 때는 더 그랬다. YAML을 직접 써야 하고, 서비스가 왜 안 붙는지도 봐야 하고, Ingress 규칙까지 같이 건드리다 보면 개념을 암기만 해서는 금방 꼬인다.이 주제는 결국 하나로 정리하면 편했다.Service는 트래픽을 Pod로 보내는 방법이고, Ingress는 외부에서 ..
쿠버네티스를 공부하다 보면 livenessProbe, readinessProbe, startupProbe는 분명 익숙한데 막상 손으로 쓰려고 하면 자꾸 헷갈립니다. 이름도 비슷하고, 다 비슷하게 컨테이너 상태를 체크하는 것처럼 보여서 더 그렇죠.저도 처음에는 이 셋을 대충 같은 계열로만 이해했습니다. 그런데 CKA 문제를 직접 풀고, Pod 재시작이 반복되는 상황을 몇 번 보다 보니 기준이 딱 하나로 정리되더라고요.Probe는 상태를 묻는 게 아니라, 쿠버네티스가 어떤 행동을 하게 만들지 정하는 장치다이 관점으로 보면 세 개가 훨씬 덜 헷갈립니다.왜 Probe가 필요한가겉으로는 Running 상태인 컨테이너도 실제로는 문제가 있을 수 있습니다. 프로세스는 살아 있지만 내부가 멈춰 있거나, 부팅은 덜 끝났..
