VPN 사용자를 위한 Pod IP, ClusterIP 또는 내부 로드 밸런서
Pod IP는 Pod가 교체될 때까지 VPN을 통해 라우팅할 수 있습니다. Pod 직접 액세스, ClusterIP, 내부 밸런서를 비교하고 각각의 비용을 확인하세요.
VPC CNI를 사용하면 Pod가 VPC의 주소를 가질 수 있고, 올바른 경로를 가진 VPN 사용자는 그 주소에 직접 접근할 수 있습니다. 그래서 Pod 직접 액세스가 가장 단순한 선택처럼 보이며, Pod가 교체되기 전까지는 실제로 그렇습니다. 사용자가 기억하는 주소는 복제본이 아니라 애플리케이션에 속해야 합니다. 세 진입점의 비교는 결국 주소를 어느 오브젝트가 소유하는지, 워크로드가 이동할 때 무엇이 계속 동작해야 하는지로 귀결됩니다.
먼저 수명 주기로 선택하고, 그다음 진입점을 접근 가능하게 만들기 위해 네트워크가 무엇을 해야 하는지로 선택하세요.
세 진입점, 세 가지 수명 주기
Pod IP는 Pod가 소유하며 Pod와 함께 할당되고 종료될 때 해제됩니다. ClusterIP는 Service가 소유하며 가상 주소이므로 클러스터의 서비스 라우팅이 있는 곳에서만 의미가 있습니다. 내부 로드 밸런서는 클러스터 컨트롤러가 백엔드로 구성하는 클라우드 리소스가 소유합니다. 이러한 소유 모델은 오래된 주소, 도달할 수 없는 이름, 오래된 백엔드 집합이라는 장애를 예고합니다.
선택하기 전에 비교를 적어 두세요. 소유자와 장애의 이름이 정해지면 선택은 대개 스스로 이루어집니다.
| Entry | Owner | Failure when the workload moves |
|---|---|---|
| Pod IP | The Pod | Address changes and saved links break |
| ClusterIP | The Service | Virtual address with no meaning outside cluster routing |
| Internal balancer | Cloud resource plus controller | Backends update, but the DNS view is yours to maintain |
Pod 직접 액세스: 유용하지만 일시적
직접 액세스는 관리자 한 명, 짧은 세션 하나, 특정 포트 하나라는 통제된 점검에는 정말 유용합니다. 그러나 주소는 배포할 때마다 바뀌는 구현 세부 사항이므로 사용자에게는 나쁜 계약입니다. 그리고 그것을 위키에 기록하는 것은 동작하는 서비스가 소문이 되는 방법입니다.
또한 넓은 규칙을 부릅니다. 관리자 한 명이 Pod 하나에 접근하는 권한은 노드 서브넷의 모든 주소에 대한 권한이 아니며, 보통은 후자가 기록됩니다.
ClusterIP: 설계상 클러스터로 한정
ClusterIP는 클러스터의 데이터 플레인이 클러스터 내부에서 그 주소의 라우팅을 구성하기 때문에 동작합니다. VPN에 연결된 노트북에서는 무언가가 의도적으로 노출하지 않는 한 그 주소는 아무 의미가 없습니다. svc.cluster.local로 끝나는 이름은 클러스터 DNS에 속하므로, 다른 리졸버를 가진 클라이언트로 복사하면 라우팅 오류가 아니라 존재하지 않는 이름이 됩니다.
클러스터 내부 호출자, 다른 워크로드를 포함해 ClusterIP는 여전히 올바른 진입점입니다. 다만 클러스터의 라우팅 도메인 밖 사용자를 위한 게시 수단은 아닙니다.
내부 로드 밸런서: 게시된 경로
내부 로드 밸런서는 안정적인 사설 주소와 여러분의 영역이 가리킬 수 있는 이름을 제공하고, 컨트롤러는 EKS 로드 밸런싱 가이드가 설명하는 것처럼 백엔드 집합을 최신으로 유지합니다. 이것이 누구도 문서를 편집하지 않고도 일반적인 Pod 교체를 견디는 진입점입니다. 비용은 클라우드 리소스, 컨트롤러 구성, VPN에서 오는 경로이며, 사람들이 과소평가하는 부분이 바로 이것입니다.
클러스터가 실제로 실행하는 컨트롤러 모델을 사용하세요. 한 통합을 위해 작성된 주석은 다른 통합에 적용되지 않습니다.
소스 주소는 누구인가
보안 그룹은 경계에 도착하는 소스를 보며, 이는 VPN과 로드 밸런싱 경로에 따라 연결된 클라이언트이거나 변환된 주소일 수 있습니다. EC2 기반 노드에서는 일반 VPC CNI Pod가 기본적으로 노드의 ENI 그룹을 상속하지만, 지원되는 구성에서는 Pod 전용 그룹을 연결할 수 있습니다. 추측한 노트북 주소가 아니라 문서화된 경로에 대해 규칙을 작성하세요.
애플리케이션 자체의 리스너와 인증을 별도의 통제로 유지하세요. 흐름을 허용하는 네트워크 규칙은 인가 결정이 아니며 그렇게 다루어서는 안 됩니다.
사용자에게 무엇을 줄 것인가
사용자에게 주소가 아니라 서비스 이름을 주세요. 이름을 사설 영역에 게시하고 내부 진입점을 가리키게 한 다음, 클라이언트가 같은 이름을 열어 둔 상태에서 백엔드 Pod를 교체해 시험하세요. 이 연습은 일상적인 배포 후에도 같은 애플리케이션에 도달한다는 중요한 속성을 검증합니다.
Pod 직접 액세스는 자체 범위를 가진 문서화된 운영 예외로, 사용자 안내에서 멀리 두세요.