AKS(Azure Kubernetes Service)의 애플리케이션에 대한 네트워킹 개념
애플리케이션 개발에 대한 컨테이너 기반 마이크로 서비스 접근 방식에서 애플리케이션 구성 요소는 함께 작동하여 해당 작업을 처리합니다. Kubernetes는 이 공동 작업을 사용 설정하는 다양한 리소스를 제공합니다.
- 애플리케이션을 내부 또는 외부에 연결하고 공개할 수 있습니다.
- 애플리케이션의 부하를 분산시켜 고가용성 애플리케이션을 빌드할 수 있습니다.
- Pod 및 노드에 대한 또는 서로 간에 네트워크 트래픽의 흐름을 제한하여 보안을 강화할 수 있습니다.
- 더 복잡한 애플리케이션의 경우 여러 구성 요소의 SSL/TLS 종료 또는 라우팅에 대한 수신 트래픽을 구성할 수 있습니다.
이 문서에서는 AKS에서 네트워킹을 애플리케이션에 제공하는 핵심 개념을 소개합니다.
Kubernetes 네트워킹 기본 사항
Kubernetes는 가상 네트워킹 계층을 사용하여 애플리케이션이나 해당 구성 요소 내부 및 간의 액세스를 관리합니다.
Kubernetes 노드 및 가상 네트워크: Kubernetes 노드는 가상 네트워크에 연결됩니다. 이 설정을 통해 Pod(Kubernetes의 기본 배포 단위)에 인바운드 및 아웃바운드 연결이 모두 있을 수 있습니다.
Kube-proxy 구성 요소: kube-proxy는 각 노드에서 실행되며 필요한 네트워크 기능을 제공하는 역할을 담당합니다.
특정 Kubernetes 기능 관련:
- 부하 분산 장치: 부하 분산 장치를 사용하여 네트워크 트래픽을 다양한 리소스에 균등하게 분산할 수 있습니다.
- 수신 컨트롤러: 이는 애플리케이션 트래픽을 전달하는 데 필수적인 계층 7 라우팅을 용이하게 합니다.
- 송신 트래픽 제어: Kubernetes를 사용하면 클러스터 노드에서 아웃바운드 트래픽을 관리하고 제어할 수 있습니다.
- 네트워크 정책: 이 정책은 Pod의 네트워크 트래픽에 대한 보안 측정값 및 필터링을 사용하도록 설정합니다.
Azure 플랫폼의 컨텍스트에서:
- Azure는 AKS(Azure Kubernetes Service) 클러스터에 대한 가상 네트워킹을 간소화합니다.
- Azure에서 Kubernetes 부하 분산 장치를 만들면 해당 Azure Load Balancer 리소스가 동시에 설정됩니다.
- Pod에 대한 네트워크 포트를 열면 Azure는 필요한 네트워크 보안 그룹 규칙을 자동으로 구성합니다.
- Azure는 새로운 수신 경로가 설정됨에 따라 HTTP 애플리케이션 라우팅을 위한 외부 DNS 구성도 관리할 수 있습니다.
Azure 가상 네트워크
AKS에서는 다음 네트워크 모델 중 하나를 사용하는 클러스터를 배포할 수 있습니다.
Kubenet 네트워킹
네트워크 리소스는 일반적으로 AKS 클러스터가 배포될 때 만들어지고 구성됩니다.
Azure CNI(Container Networking Interface) 네트워킹
AKS 클러스터는 기존 가상 네트워크 리소스 및 구성에 연결됩니다.
Kubenet(기본) 네트워킹
kubenet 네트워킹 옵션은 AKS 클러스터 만들기에 대한 기본 구성입니다. kubenet 사용:
- 노드가 Azure Virtual Network 서브넷의 IP 주소를 얻습니다.
- Pod는 노드의 Azure 가상 네트워크 서브넷이 아닌 논리적으로 다른 주소 공간에서 IP 주소를 받습니다.
- 그러면 Pod가 Azure 가상 네트워크의 리소스에 연결할 수 있도록 NAT(Network Address Translation)가 구성됩니다.
- 트래픽의 원본 IP 주소는 노드의 기본 IP 주소로 변환됩니다.
노드는 kubenet Kubernetes 플러그인을 사용합니다. Azure 플랫폼에서 가상 네트워크를 만들고 구성하거나 기존 가상 네트워크 서브넷에 AKS 클러스터를 배포하도록 선택할 수 있습니다.
노드만 라우팅 가능한 IP 주소를 받습니다. Pod는 NAT를 사용하여 AKS 클러스터 외부의 다른 리소스와 통신합니다. 이 방법을 사용하면 네트워크 공간에서 pod가 사용하도록 예약해야 하는 IP 주소의 수가 줄어듭니다.
참고 항목
kubenet은 AKS 클러스터에서 가상 네트워크 및 서브넷을 만들기 위한 기본 네트워킹 옵션이지만 프로덕션 배포에는 권장되지 않습니다. 대부분의 프로덕션 배포에서는 우수한 확장성과 성능 특성으로 인해 Azure CNI 네트워킹을 계획하고 사용해야 합니다.
자세한 내용은 AKS 클러스터에 대한 kubenet 네트워킹 구성을 참조하세요.
Azure CNI(고급) 네트워킹
모든 Pod는 Azure CNI를 사용하여 서브넷에서 IP 주소를 가져오며 바로 액세스 가능합니다. 이러한 IP 주소는 미리 계획되어야 하며 네트워크 공간 전체에서 고유해야 합니다. 각 노드에는 지원하는 최대 Pod 수에 대한 구성 매개 변수가 있습니다. 그러면 노드당 동일한 IP 주소 수가 미리 예약됩니다. 이 방식을 사용하면 IP 주소가 소진되거나 애플리케이션 요구 사항이 증가함에 따라 더 큰 서브넷에서 클러스터를 다시 빌드해야 할 수 있으므로 적절하게 계획해야 합니다. 이러한 계획 문제를 방지하려면 IP의 동적 할당 및 향상된 서브넷 지원을 위한 Azure CNI 네트워킹 기능을 사용하도록 설정할 수 있습니다.
참고 항목
Kubernetes 제한 사항으로 인해 리소스 그룹 이름, Virtual Network 이름 및 서브넷 이름은 63자 이하여야 합니다.
kubenet과 달리 동일한 가상 네트워크의 엔드포인트에 대한 트래픽은 노드의 기본 IP 주소로 변환(NAT)되지 않습니다. 가상 네트워크 내부 트래픽의 원본 주소는 Pod IP입니다. 가상 네트워크 외부에 있는 트래픽은 여전히 노드의 기본 IP에 대한 NAT입니다.
노드는 Azure CNI Kubernetes 플러그인을 사용합니다.
자세한 내용은 AKS 클러스터에 대한 Azure CNI 구성을 참조하세요.
Azure CNI 오버레이 네트워킹
Azure CNI 오버레이는 Azure CNI의 발전을 나타내며 가상 네트워크 IP를 Pod에 할당할 때 발생하는 확장성 및 계획 문제를 해결합니다. Azure CNI 오버레이는 프라이빗 CIDR IP를 Pod에 할당합니다. 개인 IP는 가상 네트워크와 별개이며 여러 클러스터에서 다시 사용할 수 있습니다. Azure CNI 오버레이는 Kubenet 클러스터에 적용되는 400개 노드 제한 이상으로 크기 조정될 수 있습니다. Azure CNI 오버레이는 대부분의 클러스터에 권장되는 옵션입니다.
Cilium에서 제공하는 Azure CNI
Cilium으로 구동되는 Azure CNI는 Cilium을 사용하여 고성능 네트워킹, 관측 가능성 및 네트워크 정책 적용을 제공합니다. IPAM(확장성 있는 IP 주소 관리)을 위해 Azure CNI Overlay와 기본적으로 통합됩니다.
또한 Cilium은 별도의 네트워크 정책 엔진 없이도 기본적으로 네트워크 정책을 적용합니다. eBPF 프로그램과 보다 효율적인 API 개체 구조를 사용하여 Cilium으로 구동되는 Azure CNI는 Azure Network Policy Manager의 250개 노드/20,000개 Pod 제한 이상으로 크기 조정할 수 있습니다.
Cilium으로 구동되는 Azure CNI는 네트워크 정책 적용이 필요한 클러스터에 권장되는 옵션입니다.
자체 CNI 가져오기
Bring Your Own CNI 기능을 사용하여 AKS에 타사 CNI를 설치할 수 있습니다.
네트워크 모델 비교
kubenet과 Azure CNI 모두 AKS 클러스터에 대한 네트워크 연결을 제공합니다. 그러나 각 방법에는 장단점이 있습니다. 대략적인 수준에서는 다음과 같은 고려 사항이 적용됩니다.
kubenet
- IP 주소 공간을 절약합니다.
- Kubernetes 내부 또는 외부 부하 분산 장치를 사용하여 클러스터 외부에서 Pod에 연결합니다.
- 수동으로 UDR(사용자 정의 경로)을 관리하고 유지 관리합니다.
- 클러스터당 최대 노드 수는 400개입니다.
Azure CNI
- Pod는 전체 가상 네트워크 연결을 가져오고 연결된 네트워크에서 개인 IP 주소를 통해 직접 연결할 수 있습니다.
- IP 주소 공간이 더 필요합니다.
| 네트워크 모델 | 사용 시기 |
|---|---|
| Kubenet | • IP 주소 공간 대화가 우선적으로 고려됩니다. • 단순 구성 • 클러스터당 노드 수가 400개 미만입니다. • Kubernetes 내부 또는 외부 부하 분산 장치는 클러스터 외부에서 Pod에 연결하는 데 충분합니다. • 사용자 정의 경로를 수동으로 관리하고 유지하는 것이 허용됩니다. |
| Azure CNI | • Pod에 대해 전체 가상 네트워크 연결이 필요합니다. • 가상 노드와 같은 고급 AKS 기능이 필요합니다. • 충분한 IP 주소 공간을 사용할 수 있습니다. • Pod-Pod 간 및 Pod-가상 머신 간 연결이 필요합니다. • 외부 리소스는 Pod에 직접 연결해야 합니다. • AKS 네트워크 정책이 필요합니다. |
| Azure CNI 오버레이 | • IP 주소 부족이 우려됩니다. • 노드당 최대 1,000개의 노드와 250개의 Pod로 스케일 업하면 충분합니다. • Pod 연결을 위한 추가 홉이 허용됩니다. • 보다 단순한 네트워크 구성 • AKS 송신 요구 사항을 충족할 수 있습니다. |
kubenet과 Azure CNI 간에는 다음의 동작 차이점이 존재합니다.
| 기능 | kubenet | Azure CNI | Azure CNI 오버레이 | Cilium으로 구동되는 Azure CNI |
|---|---|---|---|---|
| 기존 또는 새 가상 네트워크에 클러스터 배포 | 지원됨 - UDR이 수동 적용됨 | 지원됨 | 지원 | 지원됨 |
| Pod - Pod 연결 | 지원 여부 | 지원 | 지원 | 지원 여부 |
| Pod - VM 연결, 동일한 가상 네트워크의 VM | Pod에 의해 시작된 경우 작동함 | 두 가지 방식 작동 | Pod에 의해 시작된 경우 작동함 | Pod에 의해 시작된 경우 작동함 |
| Pod - VM 연결, 피어링된 가상 네트워크의 VM | Pod에 의해 시작된 경우 작동함 | 두 가지 방식 작동 | Pod에 의해 시작된 경우 작동함 | Pod에 의해 시작된 경우 작동함 |
| VPN 또는 Express 경로를 사용하여 온-프레미스 액세스 | Pod에 의해 시작된 경우 작동함 | 두 가지 방식 작동 | Pod에 의해 시작된 경우 작동함 | Pod에 의해 시작된 경우 작동함 |
| 서비스 엔드포인트에 의해 보호되는 리소스 액세스 | 지원 여부 | 지원 | 지원 여부 | |
| 부하 분산 장치 서비스, App Gateway 또는 수신 컨트롤러를 사용하는 Expose Kubernetes 서비스 | 지원 여부 | 지원 | 지원됨 | 오버레이 모드를 사용할 때에도 동일한 제한 사항 |
| Windows 노드 풀 지원 | 지원되지 않음 | 지원됨 | 지원됨 | Linux에서만 사용할 수 있고 Windows에서는 사용할 수 없습니다. |
| 기본 Azure DNS 및 프라이빗 영역 | 지원 여부 | 지원 | 지원됨 |
Azure CNI 및 kubenet에 대한 자세한 내용을 확인하고 가장 적합한 옵션을 결정하는 데 도움이 되려면 AKS에서 Azure CNI 네트워킹 구성 및 AKS에서 kubenet 네트워킹 사용을 참조하세요.
네트워크 모델 간의 범위 지원
어떤 네트워크 모델을 사용하든 kubenet과 Azure CNI는 다음 중 한 가지 방법으로 배포할 수 있습니다.
- Azure 플랫폼은 AKS 클러스터를 만들 때 가상 네트워크 리소스를 자동으로 만들고 구성할 수 있습니다.
- AKS 클러스터를 만들 때 가상 네트워크 리소스를 수동으로 만들고 구성하고 해당 리소스에 연결할 수 있습니다.
kubenet과 Azure CNI 모두 서비스 엔드포인트나 UDR 같은 기능이 지원되기는 하지만 AKS 지원 정책에서는 사용자가 수행할 수 있는 변경 작업을 정의합니다. 예시:
- AKS 클러스터의 가상 네트워크 리소스를 수동으로 만드는 경우 고유한 UDR이나 서비스 엔드포인트를 구성할 때 지원됩니다.
- Azure 플랫폼에서 AKS 클러스터의 가상 네트워크 리소스가 자동으로 만들어질 경우, 이와 같은 AKS로 관리되는 리소스를 수동으로 변경하여 자체 UDR 또는 서비스 엔드포인트를 구성할 수 없습니다.
수신 컨트롤러
LoadBalancer 형식 서비스를 만들 때 기본 Azure Load Balancer 리소스도 만듭니다. 부하 분산 장치는 지정된 포트에서 서비스의 Pod에 트래픽을 분산하도록 구성됩니다.
LoadBalancer는 계층 4에서만 작동합니다. 계층 4에서 서비스는 실제 애플리케이션을 인식하지 못하며 더 이상 라우팅을 고려할 수 없습니다.
수신 컨트롤러는 계층 7에서 작동하며 보다 지능적인 규칙을 사용하여 애플리케이션 트래픽을 분산할 수 있습니다. 수신 컨트롤러는 일반적으로 인바운드 URL에 따라 HTTP 트래픽을 다른 애플리케이션으로 라우팅합니다.
수신 옵션 비교
다음 표에서는 다양한 수신 컨트롤러 옵션 간의 기능 차이점을 나열합니다.
| 기능 | 애플리케이션 라우팅 추가 기능 | 컨테이너용 Application Gateway | Azure 서비스 메시/Istio 기반 서비스 메시 |
|---|---|---|---|
| 수신/게이트웨이 컨트롤러 | NGINX 수신 컨트롤러 | 컨테이너용 Azure Application Gateway | Istio 수신 게이트웨이 |
| API | 수신 API | 수신 API 및 게이트웨이 API | 게이트웨이 API |
| 호스팅 | 클러스터 내 | Azure 호스팅 | 클러스터 내 |
| 크기 조정 | 자동 확장 | 자동 확장 | 자동 확장 |
| 부하 분산 | 내부/외부 | 외부 | 내부/외부 |
| SSL 종료 | 클러스터 내 | 예: 오프로드 및 E2E SSL | 클러스터 내 |
| mTLS | 해당 없음 | 백 엔드의 경우 예 | 해당 없음 |
| 고정 IP 주소 | 해당 없음 | FQDN | 해당 없음 |
| Azure Key Vault에 저장된 SSL 인증서 | 예 | 예 | 해당 없음 |
| DNS 영역 관리에 대한 Azure DNS 통합 | 예 | 예 | 해당 없음 |
다음 표에서는 각 수신 컨트롤러를 사용할 수 있는 다양한 시나리오를 나열합니다.
| 수신 옵션 | 사용 시기 |
|---|---|
| 관리형 NGINX - 애플리케이션 라우팅 추가 기능 | • 클러스터 내 호스팅, 사용자 지정 가능 및 스케일링 가능한 NGINX 수신 컨트롤러 • 기본 부하 분산 및 라우팅 기능 • 내부 및 외부 부하 분산 장치 구성 • 정적 IP 주소 구성 • 인증서 관리를 위해 Azure Key Vault와 통합 • 퍼블릭 및 프라이빗 DNS 관리를 위해 Azure DNS 영역과 통합 • 수신 API를 지원합니다. |
| 컨테이너용 Application Gateway | • Azure 호스팅 수신 게이트웨이 • 컨트롤러에서 관리하는 유연한 배포 전략 또는 Bring Your Own 컨테이너용 Application Gateway • 자동 재시도, 가용성 영역 복원력, 백 엔드 대상에 대한 mTLS(상호 인증), 트래픽 분할/가중 라운드 로빈 및 자동 스케일링과 같은 고급 트래픽 관리 기능 • 인증서 관리를 위해 Azure Key Vault와 통합 • 퍼블릭 및 프라이빗 DNS 관리를 위해 Azure DNS 영역과 통합 • 수신 및 게이트웨이 API를 지원합니다. |
| Istio 수신 게이트웨이 | • 서비스 메시에 Istio와 함께 사용하는 경우 Envoy를 기준으로 합니다. • 속도 제한 및 회로 차단과 같은 고급 트래픽 관리 기능 • mTLS 지원 • 게이트웨이 API를 지원합니다. |
수신 리소스 만들기
애플리케이션 라우팅 추가 기능은 AKS에서 수신 컨트롤러를 구성하는 데 권장되는 방법입니다. 애플리케이션 라우팅 추가 기능은 다음 기능을 제공하는 AKS(Azure Kubernetes Service)용 완전 관리형 수신 컨트롤러입니다.
Kubernetes NGINX 수신 컨트롤러를 기준으로 하는 관리형 NGINX 수신 컨트롤러의 손쉬운 구성
퍼블릭 및 프라이빗 영역 관리를 위해 Azure DNS와 통합
Azure Key Vault에 저장된 인증서로 SSL 종료.
애플리케이션 라우팅 추가 기능에 대한 자세한 내용은 애플리케이션 라우팅 추가 기능을 사용하는 관리형 NGINX 수신을 참조하세요.
클라이언트 원본 IP 유지
AKS 클러스터의 컨테이너에 대한 요청에 클라이언트 원본 IP를 유지하도록 수신 컨트롤러를 구성합니다. 수신 컨트롤러가 클라이언트의 요청을 AKS 클러스터의 컨테이너에 라우팅하는 경우, 해당 요청의 원래 원본 IP는 대상 컨테이너에서 사용할 수 없습니다. 클라이언트 원본 IP 유지를 사용 설정하면 클라이언트의 원본 IP는 X-Forwarded-For 아래의 요청 헤더에서 사용할 수 있습니다.
수신 컨트롤러에서 클라이언트 원본 IP 유지를 사용하는 경우에는 TLS 통과를 사용할 수 없습니다. 클라이언트 원본 IP 유지 및 TLS 통과는 LoadBalancer 유형과 같은 다른 서비스와 함께 사용할 수 있습니다.
클라이언트 원본 IP 보존에 대한 자세한 내용은 AKS의 부하 분산 장치 서비스에서 클라이언트 원본 IP 보존이 작동하는 방식을 참조하세요.
아웃바운드(송신) 트래픽 제어
AKS 클러스터는 가상 네트워크에 배포되며 해당 가상 네트워크 외부의 서비스에 대한 아웃바운드 종속성이 있습니다. 이러한 아웃바운드 종속성은 거의가 FQDN(정규화된 도메인 이름)으로 정의됩니다. 기본적으로 AKS 클러스터에는 실행하는 노드 및 서비스가 필요에 따라 외부 리소스에 액세스할 수 있도록 하는 무제한 아웃바운드(송신) 인터넷 액세스가 있습니다. 원하는 경우 아웃바운드 트래픽을 제한할 수 있습니다.
자세한 내용은 AKS에서 클러스터 노드의 송신 트래픽 제어를 참조하세요.
네트워크 보안 그룹
네트워크 보안 그룹은 AKS 노드와 같은 VM의 트래픽을 필터링합니다. 부하 분산 장치와 같은 서비스를 만들 때 Azure 플랫폼은 필요한 모든 네트워크 보안 그룹 규칙을 자동으로 구성합니다.
AKS 클러스터의 Pod에 대한 트래픽을 필터링하는 네트워크 보안 그룹 규칙은 수동으로 구성할 필요가 없습니다. Kubernetes Service 매니페스트의 일부로 필요한 포트 및 전달을 정의하고 Azure 플랫폼에서 해당하는 규칙을 만들거나 업데이트하도록 할 수 있습니다.
또한 네트워크 정책을 사용하여 트래픽 필터 규칙을 Pod에 자동으로 적용할 수도 있습니다.
자세한 내용은 네트워크 보안 그룹이 네트워크 트래픽을 필터링하는 방법을 참조하세요.
네트워크 정책
기본적으로 AKS 클러스터의 모든 pod는 트래픽을 제한 없이 송수신할 수 있습니다. 보안 향상을 위해 다음과 같이 트래픽의 흐름을 제어하는 규칙을 정의할 수 있습니다.
- 백 엔드 애플리케이션은 필요한 프런트 엔드 서비스에만 노출됩니다.
- 데이터베이스 구성 요소에 연결하는 애플리케이션 계층에서만 해당 구성 요소에 액세스할 수 있습니다.
네트워크 정책은 AKS에서 사용 가능한 Kubernetes 기능으로서 사용자가 Pod 간의 트래픽 흐름을 제어하도록 돕습니다. 할당된 레이블, 네임스페이스 또는 트래픽 포트와 같은 설정에 따라 Pod에 대한 트래픽을 허용하거나 거부할 수 있습니다. 네트워크 보안 그룹은 AKS 노드에 더 적합하지만 네트워크 정책은 Pod에 대한 트래픽 흐름을 제어하는 데 더 적합한 클라우드 네이티브 방법입니다. Pod는 AKS 클러스터에서 동적으로 생성되므로 필요한 네트워크 정책을 자동으로 적용할 수 있습니다.
자세한 내용은 AKS(Azure Kubernetes Service)에서 네트워크 정책을 사용하여 pod 간 트래픽 보호를 참조하세요.
다음 단계
AKS 네트워킹을 시작하려면 kubenet이나 Azure CNI를 사용하여 자체 IP 주소 범위로 AKS 클러스터를 만들고 구성합니다.
관련된 모범 사례에 대해서는 AKS의 네트워크 연결 및 보안에 대한 모범 사례를 참조하세요.
Kubernetes 및 AKS 핵심 개념에 대한 자세한 내용은 다음 문서를 참조하세요.