Conversation
Updated image syntax for clarity and consistency in the document.
| ## 1. 쿠버네티스 아키텍처 | ||
| [Kubernetes - Cluster Architecture](https://kubernetes.io/docs/concepts/architecture/) |
| ### 2.2. LoadBalancer | ||
|
|
||
| 클라우드 환경에서 외부 로드 밸런서를 생성하고 고정 IP(VIP)를 부여한다. 외부 클라이언트는 이 VIP로 접근한다. | ||
|  | ||
|
|
||
| - 퍼블릭 클라우드(AWS, GCP, Azure)에서 주로 사용 | ||
| - Service마다 외부 IP가 하나씩 생성됨 |
There was a problem hiding this comment.
로드밸런서에 Service마다 외부 IP가 하나씩 생성됨을 단점으로 안 적었는데 이게 Ingress 쓰는 이유랑 직결되니까 명시해주면 흐름이 더 자연스러울 것 같아요
| # 50% 확률로 Pod A, 나머지는 Pod B (로드밸런싱) | ||
| -A KUBE-SVC-XXXX -m statistic --mode random --probability 0.5 -j KUBE-SEP-AAAA | ||
| -A KUBE-SVC-XXXX -j KUBE-SEP-BBBB |
There was a problem hiding this comment.
Pod가 2개일 때 50%/50% 예시는 맞는데 실제로는 1/n 확률로 체인이 구성되는 방식이라 Pod 3개면 첫 룰이 33%가 됩니다! 예시를 그냥 2개로 고정하거나, n개 Pod에 대해 1/n 확률 이라고 한 줄 더 명시하면 혼동이 없을 것 같아용
| ![[img/k8s-service-nodeport.png]] | ||
|
|
||
| - 가장 단순한 방법 | ||
| - 모든 노드에 동일한 포트가 열리므로, 어느 노드로 접근해도 동작 |
There was a problem hiding this comment.
실제 목적지인 Pod가 떠 있지 않은 노드에서도 동일한 NodePort가 열리는 이유가 궁금합니다. 만약 Pod가 없는 노드로 외부 트래픽이 들어왔을 때, 해당 노드의 iptables가 다른 노드에 있는 Pod의 IP로 패킷을 리다이렉션(NAT) 해주는 홉 과정을 알고 싶습니다
| - 외부 클라이언트가 클러스터 내 Service에 접근하는 방법: | ||
| 1. **NodePort**: Service is accessed via `NodeIP:port` | ||
| 2. **LoadBalancer**: Service is accessed via LoadBalncer | ||
| 3. **Ingress** |
There was a problem hiding this comment.
웹 배포 같은 경우는 NodePort, LoadBalancer, Ingress 중 무엇을 쓰나요?
|  | ||
| ### 3.3. Pod가 교체되어도 연결이 유지되는 이유 | ||
|
|
||
| **Endpoints Controller**가 Service selector와 일치하는 살아있는 Pod 목록을 **Endpoints** 오브젝트로 관리한다. Pod가 죽거나 새로 뜨면 자동으로 갱신된다. |
There was a problem hiding this comment.
만약에 파드가 새로 뜨긴 했는데, 아직 내부 프로그램이 로딩 중이라 손님을 받을 준비가 안 된 상태이라면
이때 Endpoints Controller가 성급하게 새 IP를 주소록에 넣어버리면, 사용자는 접속 오류를 겪게 될텐데 어떻게 처리되나요?
|
https://coffeewhale.com/packet-network1 쿠버네티스의 패킷의 삶이라는 4탄의 시리즈 글이 있네요 읽어보면 좋을 것 같아서 공유드립니다..! |
5 participants
📝 Description
쿠버네티스에서 외부 클라이언트의 패킷이 목적지 Pod에 도달하기까지의 흐름
🚀 Key Learning