가장 적합한 네트워킹 옵션 선택하기
Calico가 지원하는 다양한 네트워킹 옵션을 비교해서 여러분 환경에 맞는 조합을 고르는 방법을 안내해요. 오버레이와 비오버레이, BGP 라우팅, CNI 선택, IPAM 모드 같은 개념부터 환경별 추천 구성까지 한 번에 정리했어요. 처음 Calico 네트워킹을 설계할 때 이 문서 하나로 방향을 잡을 수 있어요.
출처: 문서
본문
큰 그림
Calico가 지원하는 다양한 네트워킹 옵션을 살펴보고, 여러분의 필요에 가장 맞는 옵션을 고르는 방법을 알아봐요.
가치
Calico의 유연한 모듈형 아키텍처는 폭넓은 배포 옵션을 지원해서, 환경과 필요에 맞는 최선의 네트워킹 방식을 고를 수 있어요. 다양한 CNI·IPAM 플러그인과 기반 네트워크 유형을 사용할 수 있고, 비오버레이 또는 오버레이 모드, BGP 사용 여부도 선택할 수 있어요.
개념
네트워크 선택지를 제대로 이해하고 싶다면 아래 개념에 익숙해지는 것을 권해요. 학습을 건너뛰고 바로 선택지와 추천을 보고 싶다면 네트워킹 옵션으로 건너뛰어도 돼요.
Kubernetes 네트워킹 기본
Kubernetes 네트워크 모델은 다음과 같은 "플랫(flat)" 네트워크를 정의해요:
- 모든 파드는 자신만의 IP 주소를 가져요.
- 어느 노드에 있는 파드든 NAT 없이 다른 모든 노드의 모든 파드와 통신할 수 있어요.
덕분에 포트 할당, 네이밍, 서비스 디스커버리, 로드 밸런싱, 애플리케이션 구성, 마이그레이션 관점에서 파드를 VM이나 물리 호스트처럼 다룰 수 있는 깔끔하고 하위 호환되는 모델이 만들어져요. 네트워크 세그멘테이션은 네트워크 정책으로 정의해서 이 기본 네트워킹 기능 안에서 트래픽을 제한할 수 있어요.
이 모델 안에서도 다양한 네트워킹 방식과 환경을 지원할 여지가 꽤 많아요. 네트워크가 실제로 어떻게 구현되는지는 사용 중인 CNI, 네트워크, 클라우드 프로바이더 플러그인 조합에 따라 달라져요.
CNI 플러그인
CNI(Container Network Interface)는 서로 다른 네트워크 구현이 Kubernetes에 플러그인 형태로 붙을 수 있게 해주는 표준 API예요. Kubernetes는 파드가 생성되거나 삭제될 때마다 이 API를 호출해요. CNI 플러그인에는 두 가지 유형이 있어요:
- CNI 네트워크 플러그인: 파드를 Kubernetes 파드 네트워크에 추가하거나 삭제하는 일을 담당해요. 여기에는 각 파드의 네트워크 인터페이스를 생성/삭제하고, 네트워크 구현의 나머지 부분과 연결/해제하는 작업도 포함돼요.
- CNI IPAM 플러그인: 파드가 생성·삭제될 때 IP 주소를 할당하고 회수하는 일을 담당해요. 플러그인에 따라 각 노드에 하나 이상의 IP 주소 범위(CIDR)를 할당하거나, 기반 퍼블릭 클라우드 네트워크에서 IP 주소를 받아 파드에 할당하기도 해요.
클라우드 프로바이더 통합
Kubernetes 클라우드 프로바이더 통합은 클라우드별 컨트롤러로, 기반 클라우드 네트워크를 구성해서 Kubernetes 네트워킹을 도와줘요. 클라우드 프로바이더에 따라 파드 트래픽을 라우팅하는 방법을 기반 클라우드 네트워크가 기본적으로 알 수 있도록 경로를 자동으로 프로그래밍하기도 해요.
kubenet
kubenet은 Kubernetes에 내장된 매우 기초적인 네트워크 플러그인이에요. 노드 간 네트워킹이나 네트워크 정책은 구현하지 않아요. 보통 클라우드 프로바이더 네트워크에 노드 간 통신용 경로를 설정해 주는 클라우드 프로바이더 통합과 함께 쓰이거나, 단일 노드 환경에서 사용돼요. kubenet은 Calico와 호환되지 않아요.
오버레이 네트워크
오버레이 네트워크는 다른 네트워크 위에 겹쳐 올리는 네트워크예요. Kubernetes 맥락에서 오버레이 네트워크는 파드 IP 주소나 어느 노드에 어떤 파드가 있는지 모르는 기반 네트워크 위에서, 노드 사이의 파드 투 파드 트래픽을 처리하는 데 쓸 수 있어요. 오버레이 네트워크는 기반 네트워크가 처리 방법을 모르는 네트워크 패킷(예: 파드 IP 주소를 사용하는 패킷)을, 기반 네트워크가 처리할 수 있는 외부 패킷(예: 노드 IP 주소를 사용하는 패킷) 안에 캡슐화하는 방식으로 동작해요. 캡슐화에 흔히 쓰이는 네트워크 프로토콜 두 가지가 VXLAN과 IP-in-IP예요.
오버레이 네트워크를 쓰는 가장 큰 장점은 기반 네트워크에 대한 의존성을 줄여준다는 점이에요. 예를 들어 거의 모든 기반 네트워크 위에서 VXLAN 오버레이를 운영할 수 있고, 기반 네트워크와 통합하거나 변경할 필요가 전혀 없어요.
오버레이 네트워크를 쓰는 가장 큰 단점은 다음과 같아요:
- 약간의 성능 영향이 있어요. 패킷을 캡슐화하는 과정에 소량의 CPU가 들고, 캡슐화 정보(VXLAN 또는 IP-in-IP 헤더)를 담기 위한 추가 바이트 때문에 보낼 수 있는 내부 패킷의 최대 크기가 줄어들어요. 그 결과 같은 총 데이터량을 보내려면 더 많은 패킷을 보내야 할 수 있어요.
- 파드 IP 주소가 클러스터 외부에서 라우팅되지 않아요. 아래에서 자세히 다룰게요!
크로스 서브넷 오버레이
표준 VXLAN 또는 IP-in-IP 오버레이 외에도 Calico는 VXLAN과 IP-in-IP의 "크로스 서브넷" 모드를 지원해요. 이 모드에서는 같은 서브넷 안에서는 기반 네트워크가 L2 네트워크처럼 동작해요. 단일 서브넷 안에서 보내는 패킷은 캡슐화되지 않아서 비오버레이 네트워크의 성능을 얻을 수 있어요. 서브넷을 넘어 보내는 패킷은 일반 오버레이 네트워크처럼 캡슐화되어 기반 네트워크에 대한 의존성을 줄여줘요(기반 네트워크와 통합하거나 변경할 필요 없이).
표준 오버레이 네트워크와 마찬가지로 기반 네트워크는 파드 IP 주소를 알지 못하고, 파드 IP 주소는 클러스터 외부에서 라우팅되지 않아요.
클러스터 외부에서의 파드 IP 라우팅 가능성
서로 다른 Kubernetes 네트워크 구현을 가르는 중요한 특징 중 하나는, 파드 IP 주소가 클러스터 외부의 더 넓은 네트워크에서 라우팅 가능한지 여부예요.
라우팅 불가
파드 IP 주소가 클러스터 외부에서 라우팅 불가능하다면, 파드가 클러스터 밖 IP 주소로 네트워크 연결을 시도할 때 Kubernetes는 SNAT(Source Network Address Translation) 기법을 사용해 소스 IP를 파드의 IP에서 파드를 호스팅하는 노드의 IP로 바꿔요. 연결의 응답 패킷은 자동으로 다시 파드 IP 주소로 매핑돼요. 그래서 파드는 SNAT가 일어나는지 알 수 없고, 연결 대상에게는 노드가 연결의 출처로 보이며, 더 넓은 네트워크는 파드 IP 주소를 전혀 보지 못해요.
반대 방향 연결, 즉 클러스터 외부의 무언가가 파드에 연결해야 하는 경우에는 Kubernetes 서비스나 Kubernetes 인그레스를 통해서만 가능해요. 더 넓은 네트워크가 파드 IP 주소로 패킷을 라우팅하는 방법을 모르기 때문에, 클러스터 외부에서는 어떤 것도 파드 IP 주소에 직접 연결할 수 없어요.
라우팅 가능
파드 IP 주소가 클러스터 외부에서 라우팅 가능하다면 파드는 SNAT 없이 외부 세계로 연결할 수 있고, 외부 세계도 Kubernetes 서비스나 Kubernetes 인그레스를 거치지 않고 파드에 직접 연결할 수 있어요.
클러스터 외부에서 라우팅 가능한 파드 IP 주소의 장점은 다음과 같아요:
- 아웃바운드 연결에서 SNAT를 쓰지 않는 것은 기존의 더 넓은 보안 요구 사항과 통합할 때 필수일 수 있어요. 디버깅과 운영 로그의 이해도도 단순해져요.
- Kubernetes 서비스나 Kubernetes 인그레스를 거치지 않고 직접 접근 가능해야 하는 파드가 있는 특수 워크로드라면, 호스트 네트워크 파드를 쓰는 대안보다 라우팅 가능한 파드 IP가 운영상 더 단순할 수 있어요.
클러스터 외부에서 라우팅 가능한 파드 IP 주소의 가장 큰 단점은 파드 IP가 더 넓은 네트워크에서 유일해야 한다는 점이에요. 예를 들어 여러 클러스터를 운영한다면 클러스터마다 다른 파드 IP 주소 범위(CIDR)를 사용해야 해요. 이는 규모가 커지거나 IP 주소 공간에 다른 중요한 엔터프라이즈 수요가 있을 때 IP 주소 범위 고갈 문제로 이어질 수 있어요.
라우팅 가능 여부는 무엇이 결정할까?
클러스터에 오버레이 네트워크를 사용하고 있다면 파드 IP는 보통 클러스터 외부에서 라우팅되지 않아요.
오버레이 네트워크를 사용하지 않는다면, 파드 IP의 외부 라우팅 가능 여부는 CNI 플러그인, 클라우드 프로바이더 통합, (온프레미스라면) 물리 네트워크와의 BGP 피어링 중 어떤 조합을 사용하는지에 달려 있어요.
BGP
BGP(Border Gateway Protocol)는 네트워크 전반에 경로를 공유하기 위한 표준 기반 네트워킹 프로토콜이에요. 인터넷의 기본 구성 요소 중 하나로, 뛰어난 확장성 특성을 갖고 있어요.
Calico는 BGP를 기본으로 지원해요. 온프레미스 배포에서는 Calico가 물리 네트워크(보통 Top of Rack 라우터)와 피어링해 경로를 교환할 수 있어서, 파드 IP 주소가 더 넓은 네트워크에서 다른 워크로드처럼 라우팅 가능한 비오버레이 네트워크를 만들 수 있어요.
Calico 네트워킹 살펴보기
Calico의 유연한 모듈형 네트워킹 아키텍처에는 다음이 포함돼요.
Calico CNI 네트워크 플러그인
Calico CNI 네트워크 플러그인은 가상 이더넷 장치 쌍(veth pair)을 사용해 파드를 호스트 네트워크 네임스페이스의 L3 라우팅에 연결해요. 이 L3 아키텍처는 다른 많은 Kubernetes 네트워킹 솔루션에 들어 있는 불필요한 L2 브리지의 복잡성과 성능 오버헤드를 피해요.
Calico CNI IPAM 플러그인
Calico CNI IPAM 플러그인은 하나 이상의 구성 가능한 IP 주소 범위에서 파드에 IP 주소를 할당하고, 필요에 따라 노드별로 작은 IP 블록을 동적으로 할당해요. 그 결과 많은 네트워킹 솔루션이 쓰는 host-local IPAM 플러그인을 포함해 다른 많은 CNI IPAM 플러그인보다 IP 주소 공간을 더 효율적으로 사용해요.
오버레이 네트워크 모드
Calico는 크로스 서브넷 전용 모드를 포함해 VXLAN 또는 IP-in-IP 오버레이 네트워크를 모두 제공할 수 있어요.
비오버레이 네트워크 모드
Calico는 어떤 기반 L2 네트워크 위에서든, 또는 적절한 클라우드 프로바이더 통합이 있는 퍼블릭 클라우드 네트워크나 BGP 지원 네트워크(보통 표준 Top-of-Rack 라우터가 있는 온프레미스 네트워크)인 L3 네트워크 위에서 동작하는 비오버레이 네트워크를 제공할 수 있어요.
네트워크 정책 적용
Calico의 네트워크 정책 적용 엔진은 Kubernetes Network Policy 기능 전체와 Calico Network Policy의 확장 기능을 구현해요. Calico의 내장 네트워킹 모드와 함께, 또는 그 외 Calico 호환 네트워크 플러그인 및 클라우드 프로바이더 통합과 함께 동작해요.
Calico와 호환되는 CNI 플러그인과 클라우드 프로바이더 통합
Calico CNI 플러그인과 내장 네트워킹 모드 외에도 Calico는 여러 서드파티 CNI 플러그인 및 클라우드 프로바이더 통합과 호환돼요.
Amazon VPC CNI
Amazon VPC CNI 플러그인은 기반 AWS VPC에서 파드 IP를 할당하고 AWS 탄력적 네트워크 인터페이스를 사용해 VPC 네이티브 파드 네트워킹(클러스터 외부에서 라우팅 가능한 파드 IP)을 제공해요. Amazon EKS의 기본 네트워킹이며, 네트워크 정책 적용에는 Calico를 함께 사용해요.
Azure CNI
Azure CNI 플러그인은 기반 Azure VNet에서 파드 IP를 할당하고 Azure 가상 네트워크를 구성해 VNet 네이티브 파드 네트워킹(클러스터 외부에서 라우팅 가능한 파드 IP)을 제공해요. Microsoft AKS의 기본 네트워킹이며, 네트워크 정책 적용에는 Calico를 함께 사용해요.
Azure 클라우드 프로바이더
Azure 클라우드 프로바이더 통합은 Azure CNI 플러그인의 대안으로 사용할 수 있어요. host-local IPAM CNI 플러그인으로 파드 IP를 할당하고, 기반 Azure VNet 서브넷에 대응하는 경로를 프로그래밍해요. 파드 IP는 VNet 서브넷 안에서만 라우팅 가능해요(흔히 이는 클러스터 외부에서 라우팅 불가능하다는 의미예요).
Google 클라우드 프로바이더
Google 클라우드 프로바이더 통합은 host-local IPAM CNI 플러그인으로 파드 IP를 할당하고, Google 클라우드 네트워크의 Alias IP 범위를 프로그래밍해서 Google 클라우드에서 VPC 네이티브 파드 네트워킹(클러스터 외부에서 라우팅 가능한 파드 IP)을 제공해요. Google Kubernetes Engine (GKE)의 기본값이며, 네트워크 정책 적용에는 Calico를 함께 사용해요.
Host local IPAM
host-local CNI IPAM 플러그인은 널리 쓰이는 IP 주소 관리 CNI 플러그인으로, 각 노드에 고정 크기 IP 주소 범위(CIDR)를 할당하고 그 범위 안에서 파드 IP 주소를 할당해요. 기본 주소 범위 크기는 256개 IP 주소(/24)지만, 그중 두 개는 특수 목적으로 예약되어 파드에 할당되지 않아요. host-local CNI IPAM 플러그인의 단순함은 이해하기 쉽다는 장점이지만, Calico CNI IPAM 플러그인에 비해 IP 주소 공간을 덜 효율적으로 사용해요.
Flannel
Flannel은 host-local IPAM CNI 플러그인에서 얻은 노드별 고정 CIDR로 파드 트래픽을 라우팅해요. Flannel은 여러 네트워킹 백엔드를 제공하지만 주로 VXLAN 오버레이 백엔드와 함께 사용돼요. Calico CNI와 Calico 네트워크 정책을 flannel 및 host-local IPAM 플러그인과 결합하면 정책 적용이 되는 VXLAN 네트워크를 만들 수 있어요. 이 조합은 흔히 "Canal"이라고 불려요.
SECONDARY: Calico는 이제 VXLAN을 기본으로 지원해요. 단순함을 위해 Calico+Flannel 조합보다 VXLAN 내장 지원을 사용하는 것을 일반적으로 권해요.
네트워킹 옵션
온프레미스
Calico 온프레미스에서 가장 흔한 네트워크 구성은 BGP 피어링으로 물리 네트워크(보통 top of rack 라우터)와 연결해 파드 IP를 클러스터 외부에서 라우팅 가능하게 만드는 비오버레이 모드예요. (원한다면 온프레미스 네트워크의 나머지 부분을 구성해서 클러스터 외부 파드 IP 라우팅의 범위를 제한할 수도 있어요.) 이 구성은 Kubernetes 서비스 IP(클러스터 IP 또는 외부 IP) 광고, 파드·네임스페이스·노드 수준의 IP 주소 관리 제어 등 풍부한 고급 Calico 기능을 제공해서, 기존 엔터프라이즈 네트워크 및 보안 요구 사항과의 폭넓은 통합을 지원해요.
| Policy | IPAM | CNI | Overlay | Routing |
|---|---|---|---|---|
| Calico | Calico | Calico | No | BGP |
물리 네트워크로의 BGP 피어링이 옵션이 아니라면, 클러스터가 단일 L2 네트워크 안에 있고 Calico가 클러스터 내 노드들끼리만 BGP 피어링한다면 비오버레이 모드로 운영할 수도 있어요. 이는 엄밀히 말해 오버레이 네트워크는 아니지만, 더 넓은 네트워크에 파드 IP 경로가 없기 때문에 파드 IP는 클러스터 외부에서 라우팅되지 않아요.
| Policy | IPAM | CNI | Overlay | Routing |
|---|---|---|---|---|
| Calico | Calico | Calico | No | BGP |
또는 크로스 서브넷 오버레이 모드를 활용해 각 L2 서브넷 안의 성능을 최적화하면서, VXLAN 또는 IP-in-IP 오버레이 모드로 Calico를 운영할 수도 있어요.
추천:
| Policy | IPAM | CNI | Cross-subnet | Routing |
|---|---|---|---|---|
| Calico | Calico | Calico | VXLAN | Calico |
대안:
| Policy | IPAM | CNI | Cross-subnet | Routing |
|---|---|---|---|---|
| Calico | Calico | Calico | IPIP | BGP |
AWS
파드 IP 주소를 클러스터 외부에서 라우팅 가능하게 하려면 Amazon VPC CNI 플러그인을 사용해야 해요. 이것이 EKS의 기본 네트워킹 모드이며, 네트워크 정책에는 Calico를 사용해요. 파드 IP 주소는 기반 VPC에서 할당되고, 노드당 최대 파드 수는 인스턴스 유형에 따라 달라져요.
| Policy | IPAM | CNI | Overlay | Routing |
|---|---|---|---|---|
| Calico | AWS | AWS | No | VPC Native |
특정 클라우드 프로바이더에 대한 의존성을 피하고 싶거나, IP 주소 범위 고갈 문제 때문에 기반 VPC에서 파드 IP를 할당하기 어렵거나, Amazon VPC CNI 플러그인이 노드별로 지원하는 최대 파드 수가 부족하다면 크로스 서브넷 오버레이 모드의 Calico 네트워킹을 권해요. 파드 IP는 클러스터 외부에서 라우팅되지 않지만, 기반 클라우드 네트워크에 의존하지 않고 Kubernetes 한도까지 클러스터를 확장할 수 있어요.
| Policy | IPAM | CNI | Cross-subnet | Routing |
|---|---|---|---|---|
| Calico | Calico | Calico | VXLAN | Calico |
Azure
파드 IP 주소를 클러스터 외부에서 라우팅 가능하게 하려면 Azure CNI 플러그인을 사용해야 해요. AKS가 지원하며, 네트워크 정책에는 Calico를 사용해요. 파드 IP 주소는 기반 VNet에서 할당돼요.
| Policy | IPAM | CNI | Overlay | Routing |
|---|---|---|---|---|
| Calico | Azure | Azure | No | VPC Native |
또는 Calico를 Azure CNI 오버레이 모드로 운영할 수도 있어요.
| Policy | IPAM | CNI | Overlay | Routing |
|---|---|---|---|---|
| Calico | Azure | Azure | Yes | VPC Native |
AKS를 사용하되 IP 주소 범위 고갈 문제 때문에 기반 VNet에서 파드 IP를 할당하기 어렵다면, Calico를 Azure 클라우드 프로바이더 통합과 함께 사용할 수 있어요. 이 조합은 host-local IPAM으로 노드별 /24를 할당하고, 클러스터의 기반 VNet 서브넷 안에 그 /24에 대한 경로를 프로그래밍해요. 파드 IP는 클러스터/VNet 서브넷 외부에서 라우팅되지 않기 때문에, 원한다면 같은 파드 IP 주소 범위(CIDR)를 여러 클러스터에서 재사용할 수 있어요.
SECONDARY: 일부 AKS 문서에서는 이를 kubenet + Calico라고 부르지만, 실제로는 Azure 클라우드 프로바이더를 사용하는 Calico CNI이며 kubenet 플러그인은 쓰지 않아요.
| Policy | IPAM | CNI | Overlay | Routing |
|---|---|---|---|---|
| Calico | Host Local | Calico | No | VPC Native |
AKS가 아니고, 특정 클라우드 프로바이더 의존성을 피하고 싶거나 IP 주소 범위 고갈 문제 때문에 기반 VNet에서 파드 IP를 할당하기 어렵다면 크로스 서브넷 오버레이 모드의 Calico 네트워킹을 권해요. 파드 IP는 클러스터 외부에서 라우팅되지 않지만, 기반 클라우드 네트워크에 의존하지 않고 Kubernetes 한도까지 클러스터를 확장할 수 있어요.
| Policy | IPAM | CNI | Cross-subnet | Routing |
|---|---|---|---|---|
| Calico | Calico | Calico | VXLAN | Calico |
Google Cloud
파드 IP 주소를 클러스터 외부에서 라우팅 가능하게 하려면 Google 클라우드 프로바이더 통합을 host-local IPAM CNI 플러그인과 함께 사용해야 해요. GKE가 지원하며, 네트워크 정책에는 Calico를 사용해요. 파드 IP 주소는 기반 VPC에서 할당되고, 대응하는 Alias IP 주소가 노드에 자동으로 할당돼요.
| Policy | IPAM | CNI | Overlay | Routing |
|---|---|---|---|---|
| Calico | Host Local | Calico | No | VPC Native |
특정 클라우드 프로바이더 의존성을 피하고 싶거나 IP 주소 범위 고갈 문제 때문에 기반 VPC에서 파드 IP를 할당하기 어렵다면 오버레이 모드의 Calico 네트워킹을 권해요. Google 클라우드 네트워크는 순수 L3 네트워크라서 크로스 서브넷 모드는 지원되지 않아요. 파드 IP는 클러스터 외부에서 라우팅되지 않지만, 기반 클라우드 네트워크에 의존하지 않고 Kubernetes 한도까지 클러스터를 확장할 수 있어요.
추천:
| Policy | IPAM | CNI | Overlay | Routing |
|---|---|---|---|---|
| Calico | Calico | Calico | VXLAN | Calico |
대안:
| Policy | IPAM | CNI | Overlay | Routing |
|---|---|---|---|---|
| Calico | Calico | Calico | IPIP | BGP |
IBM Cloud
IBM Cloud를 사용한다면 Calico가 내장되어 크로스 서브넷 IP-in-IP 오버레이를 제공하는 IKS를 권해요. IKS는 파드에 네트워크 정책을 제공하는 것 외에도 Calico 네트워크 정책을 사용해 클러스터 내 호스트 노드를 보호해요.
| Policy | IPAM | CNI | Cross-subnet | Routing |
|---|---|---|---|---|
| Calico | Calico | Calico | IPIP | BGP |
어디서든
위 환경 목록이 모든 경우를 담는 건 아니에요. 이 가이드의 개념과 설명이 여러분 환경에 맞는 선택을 하는 데 도움이 됐길 바라요. 그래도 확신이 없다면 Calico Users Slack이나 Discourse 포럼에서 조언을 구할 수 있어요. 그리고 다양한 옵션을 깊이 고민하지 않고 시작하고 싶다면, 거의 모든 환경에서 VXLAN 오버레이 모드로 Calico를 운영할 수 있다는 점도 기억하세요.
| Policy | IPAM | CNI | Cross-subnet | Routing |
|---|---|---|---|---|
| Calico | Calico | Calico | VXLAN | Calico |
추가 리소스
- 동영상 재생 목록: Kubernetes 네트워킹에 대해 알아야 할 모든 것
- BGP 피어링 구성
- 오버레이 네트워킹 구성
- Kubernetes 서비스 IP 주소 광고
- IP 주소 관리 커스터마이즈
- IP 범위로 레거시 방화벽과 상호 운용하기
더 알아보기 (Learn more)
오버레이 사용 여부와 파드 IP 외부 라우팅 가능성만 정해도 선택지가 크게 좁혀져요. 퍼블릭 클라우드에서는 매니지드 서비스의 기본 조합을 따르는 것이 가장 간단한 출발점이고, 온프레미스에서는 BGP 피어링 가능 여부를 먼저 확인해 보세요.