그냥 좀 해 그냥 좀 해

들어가기 전에 첫번째 포스트에서는 한 Pod 가 다른 노드에 위치하는 다른 Pod 들과 어떻게 서로 통신하는지 알아보았다. 두번째 포스트에서는 service network 가 어떻게 Pod 들의 부하를 분산 시키는지 설명하였고 이를 통해 클러스터 내의 클라이언트가 안정적으로 각 Pod 들과 통신할 수 있는것을 확인할 수 있었다. 마지막 세번째 포스트에서는 앞선 포스팅 네트워킹 개념들을 가지고 어떻게 기술을 이용하여 클러스터 외부에서 각 Pod 들로 트래픽을 전달하는지 알아보려고 한다. 라우팅은 로드 밸런싱이 아니다 두번째 포스트에서 Deployment 를 이용하여 몇가지 Pod 들을 만들었고 그것들에 "Cluster IP" 이름의 서비스 IP를 부여했다. 그리고 각 Pod 들은 이 서비스 IP를 이용하여..

들어가기 전에 이전 포스팅에서 클라이언트 Pod 에 서버 Pod 의 IP 를 알고 있는 상황을 가정해 살펴보았고 Pod 끼리 통신이 어떻게 동작하는지 확인해보았다. Pod 가 새로 생성되었을 때 IP 가 고정적이지 않기 때문에 서비스 앞단에 reverse-proxy 를 위치시켜 현재 살아있는 서버에게 트래픽을 전달해야 한다. 또한 proxy 서버는 장애애 대응할 수 있어야 하고 트래픽을 전달할 서버 리스트를 가지고 있어야 하며 해당 서버가 정상적인지 확인할 수 있어야 한다. k8s 설계자들은 이 문제를 service 리소스 타입으로 정의했다. 이제부터 k8s service 의 대해 알아보자. Services 아래 예시를 바탕으로 k8s service 가 클라이언트와는 상관 없이 어떻게 여러 Pod 에 걸..

들어가기 전에 Kubernetes(k8s) 를 사용하다 동작방식을 생각해보면 헷갈릴 수 있다. k8s 가 내부적으로 가지는 구조와 통신방식을 이해하지 못하기 때문이다. 어떤 문제가 발생했을 때 각 Layer 별로 어떤 역할을 하는지 쪼개어 이해한다면 보다 효율적으로 전체를 이해할 수 있을 것이다. 이 글은 k8s 네트워킹을 이해하기 위한 정리가 될 것이다. Pods Pod 는 적어도 한 개 이상의 컨테이너를 구성하고 같은 host 와 network 스택을 공유하고 volume 과 같은 리소스들을 공유할 수 있다. Pod 는 k8s 의 가장 기본이 되는 단위이다. "네트워크 스택을 공유한다"의 의미는 Pod 안의 모든 컨테이너가 localhost 를 통해 서로에게 도달이 가능하다는 것을 의미한다. 예를 들..