쿠버네티스 통신

2024년 11월 29일

yeongki0944
작성자
2024.11.29.:59

Claude 3.5 Sonnet으로 학습하며 정리한 내용입니다.
할루시네이션으로 부정확한 정보가 있을 수 있습니다.

외부 요청 → HAProxy/로드밸런서
→ Ingress Controller 또는 API Gateway
→ Service Mesh (if present)
→ 최종 서비스/Pod (CNI를 통한 네트워크 연결 사용)

L7
East-West 트래픽(서비스간 내부 통신) - Service Mesh
> mTLS, 서킷브레이커, 결함 주입 등
> Istio

https://medium.com/codex/east-west-service-to-service-communication-what-is-service-mesh-4e56f94bc89c

North-South 트래픽(외부-내부 통신) - API Gateway
> API버전관리, 클라이언트와 마이크로서비스 사이의 중개자 역할
> Kong, Ambassador

North-South 트래픽 - Ingress Controller(Nginx)
> 쿠버네티스 클러스터로 들어오는 HTTP/HTTPS 트래픽을 관리

L7/L4
HAProxy (LB, Proxy)

L2 / L3
Pod간 통신 - CNI

L7 (애플리케이션 계층)
- API Gateway: 외부 API 트래픽 관리
- Service Mesh: 내부 서비스 간 통신
- Ingress Controller: HTTP/HTTPS 트래픽 라우팅

L4 (전송 계층)
- HAProxy: 로드 밸런싱, 프록시

L2/L3 (네트워크/데이터링크 계층)
- CNI: 기본 네트워크 인프라

1. Node 레벨 통신

Kubernetes Control Plane High Availability(HA) 구성 - HAProxy

아래 그림은 Claude가 알려주었지만, BestPractice는 아닌 것 같음

                   [Client/kubectl]
                          ↓ (6443/TCP)
                   [VIP/Keepalived]
                    ↙     ↓     ↘
             [HAProxy1 HAProxy2 HAProxy3]  # Active-Passive HA
                    ↘     ↓     ↙
                   로드밸런싱(TCP/L4)
                    ↙     ↓     ↘
[Control Plane 1] [Control Plane 2] [Control Plane 3]
   (API:6443)      (API:6443)      (API:6443)
   (etcd:2379)     (etcd:2379)     (etcd:2379)
        ↓               ↓               ↓
        └───────────────┴───────────────┘
                        ↓
                  [Worker Nodes]

구성 상세:
1. VIP (Virtual IP): 192.168.1.100
2. HAProxy Nodes:
  - HAProxy1: 192.168.1.101:6443
  - HAProxy2: 192.168.1.102:6443
  - HAProxy3: 192.168.1.103:6443
3. Control Planes:
  - CP1: 192.168.1.111:6443
  - CP2: 192.168.1.112:6443
  - CP3: 192.168.1.113:6443

HAProxy 설정:
frontend k8s-api
   bind *:6443
   mode tcp
   default_backend control-planes

backend control-planes
   mode tcp
   balance roundrobin
   option tcp-check
   server cp1 192.168.1.111:6443 check
   server cp2 192.168.1.112:6443 check
   server cp3 192.168.1.113:6443 check

Keepalived 설정:
vrrp_instance VI_1 {
   interface eth0
   virtual_router_id 51
   priority 100
   virtual_ipaddress {
       192.168.1.100
   }
}

통신 흐름:
1. Client → VIP:6443
2. VIP → Active HAProxy
3. HAProxy → Control Plane (라운드로빈)
4. Control Plane → Worker Nodes

https://www.linuxfunda.com/kubernetes/How-to-create-high-available-kubernetes-cluster/

https://www.gmhafiz.com/blog/highly-available-kubernetes-cluster/

https://docs.mirantis.com/mcp/q4-18/mcp-ref-arch/kubernetes-cluster-plan/kubernetes-ha.html

https://blog.devops.dev/creating-a-highly-available-kubernetes-cluster-with-kubeadm-and-haproxy-best-practices-and-8de9001197de

위에 그림에서 통신흐름이 단방향인가?? Worker > Master로 ??? Master > Worker로는 안되나?

https://www.securityandit.com/network/kubernetes-service-nodeport-ingress-and-loadbalancer/

각 계층별 역할

L3 계층: Keepalived (VIP 관리)
L4 계층: HAProxy (로드밸런싱)
L7 계층: kube-apiserver (쿠버네티스 API)

작동 방식

1) Active-Passive HA
   - Keepalived로 HAProxy 이중화
   - 장애 시 자동 페일오버

2) 로드밸런싱
   - HAProxy가 API 서버로 트래픽 분산
   - 라운드로빈 방식 사용

3) Control Plane HA
   - 3개 노드로 구성
   - etcd 클러스터 구성
   - 쿼럼 기반 합의

[외부 클라이언트/사용자]
          ↓ 
   [HAProxy/LoadBalancer] (6443/TCP)
   ┌─────────┴─────────┐
   ↓                   ↓
[Control Plane 1]    [Control Plane 2]    
   |  |                |  |              
   |  └────────┬───────┘  |                  
   |           ↓          |          CNI 네트워크 솔루션(Calico/Flannel/Cilium)          
   |    [etcd cluster]    |          ┌──────────────────────────────┐
   |           ↑          |          |                              |
   |  ┌────────┴───────┐  |          ↓                              ↓
   |  |                |  |     [Worker Node 1]              [Worker Node 2]
   ↓  ↓                ↓  ↓     - kubelet                    - kubelet
[네트워크 메시]             - kube-proxy                  - kube-proxy
   |  |                |  |     - containerd                 - containerd
   |  |                |  |     - CNI Plugin                 - CNI Plugin
   |  |                |  |          ↕                              ↕
   |  |                |  |     [Pod A]←------------------------→[Pod B]
   |  |                |  |     [Pod C]←------------------------→[Pod D]
   ↓  ↓                ↓  ↓          ↕                              ↕
[Worker Node 3]    [Worker Node 4]    └──────────────────────────────┘
- kubelet          - kubelet               Overlay Network/VXLAN
- kube-proxy       - kube-proxy            (10.244.0.0/16 등)
- containerd       - containerd
- CNI Plugin       - CNI Plugin

포트 정보:
- kube-apiserver: 6443/TCP
- kubelet: 10250/TCP
- etcd: 2379,2380/TCP

네트워크 범위:
- Pod Network: 10.244.0.0/16 (Flannel 기본)
- Service Network: 10.96.0.0/16
- Node Network: 실제 호스트 네트워크 대역

통신 흐름:
1. 외부→HAProxy→Control Plane (API 서버 접근)
2. Control Plane 노드 간 통신 (etcd 클러스터)
3. Worker 노드 간 Pod 통신 (CNI/Overlay)
4. kubelet→API 서버 상태 보고

[External Client/User]
         ↓   
    [Route 53]
         ↓ 
[AWS ALB/NLB] (포트: 443/80)
         ↓
         ↓ VPC 내부통신
         ↓    
[EKS Control Plane - AWS Managed] ←→ [AWS IAM/KMS]
 |       |        |
 |       |        └─→ [CloudWatch/CloudTrail]
 |       |            (로깅/모니터링)
 |       |     
 |       └─→ [AWS VPC CNI Controller]
 |             (Pod IP 할당/관리)
 |              
 ├────────────┬─────────────┐   VPC 내부통신
 ↓            ↓             ↓
[AZ-a]      [AZ-b]        [AZ-c]     
 |            |             |
 |    Node Group 1          |    Cross-AZ 통신
 ↓            ↓             ↓    (VPC 피어링/전송)
[EC2-1]     [EC2-2]      [EC2-3]  
 |            |             |
ENI-1       ENI-2        ENI-3      AWS VPC CNI
 |            |             |        (Pod IP = VPC IP)
 ↓            ↓             ↓
[Pod-A]     [Pod-B]      [Pod-C]    
 ↕            ↕             ↕         Pod 간 통신
 └──────────→←─────────────┘         (VPC 라우팅)

네트워크 흐름:
1. 외부 접근
Client → Route 53 → ALB → Control Plane (443/TCP)
                  └─→ Worker Nodes (80,443/TCP)

2. Pod 네트워킹 (AWS VPC CNI)
- 각 Pod는 VPC IP 할당 (보조 IP)
- ENI를 통한 VPC 네트워킹
- Security Group으로 트래픽 제어

3. 노드간 통신
- VPC 내부 라우팅
- Cross-AZ 통신은 AWS 백본 사용
- Pod to Pod 직접 통신 (VPC 라우팅)

포트/프로토콜:
- kube-apiserver: 443/TCP
- 노드포트 범위: 30000-32767/TCP
- Pod 통신: VPC 내부 모든 포트

IP 대역:
- VPC CIDR: 10.0.0.0/16
- Pod CIDR: VPC 보조 IP 대역
- Service CIDR: 172.20.0.0/16

2. 컨트롤 플레인 컴포넌트 통신

API 서버 ↔ etcd
컨트롤러 매니저 ↔ API 서버
스케줄러 ↔ API 서버
cloud-controller-manager ↔ API 서버

저작자표시 비영리 변경금지

다음 글이 없습니다.

이전 글이 없습니다.