애플리케이션 개발에 대한 컨테이너 기반 마이크로 서비스 접근 방식에서 애플리케이션 구성 요소는 함께 작동하여 해당 작업을 처리합니다. Kubernetes는 이 공동 작업을 사용 설정하는 다양한 리소스를 제공합니다.
- 애플리케이션을 내부 또는 외부에 연결하고 공개할 수 있습니다.
- 애플리케이션의 부하를 분산시켜 고가용성 애플리케이션을 빌드할 수 있습니다.
- Pod 및 노드에 대한 또는 서로 간에 네트워크 트래픽의 흐름을 제한하여 보안을 강화할 수 있습니다.
- 더 복잡한 애플리케이션의 경우 여러 구성 요소의 SSL/TLS 종료 또는 라우팅에 대한 수신 트래픽을 구성할 수 있습니다.
이 문서에서는 AKS에서 네트워킹을 애플리케이션에 제공하는 핵심 개념을 소개합니다.
Kubernetes 네트워킹 기본 사항
Kubernetes는 가상 네트워킹 계층을 사용하여 애플리케이션이나 해당 구성 요소 내부 및 간의 액세스를 관리합니다.
Kubernetes 노드 및 가상 네트워크: Kubernetes 노드는 가상 네트워크에 연결됩니다. 이 설정을 통해 Pod(Kubernetes의 기본 배포 단위)에 인바운드 및 아웃바운드 연결이 모두 있을 수 있습니다.
서비스 라우팅 구성 요소: 네트워크 데이터 플레인에 따라 노드는 Kubernetes 서비스 라우팅에
kube-proxy또는 Cilium을 사용합니다. Azure CNI Powered by Cilium을 사용하는 AKS 클러스터는kube-proxy를 사용하지 않습니다.
특정 Kubernetes 기능 관련:
- 부하 분산 장치: 부하 분산 장치를 사용하여 네트워크 트래픽을 다양한 리소스에 균등하게 분산할 수 있습니다.
- 수신 컨트롤러: 이는 애플리케이션 트래픽을 전달하는 데 필수적인 계층 7 라우팅을 용이하게 합니다.
- 송신 트래픽 제어: Kubernetes를 사용하면 클러스터 노드에서 아웃바운드 트래픽을 관리하고 제어할 수 있습니다.
- 네트워크 정책: 이 정책은 Pod의 네트워크 트래픽에 대한 보안 측정값 및 필터링을 사용하도록 설정합니다.
Azure 플랫폼의 컨텍스트에서:
- Azure AKS(Azure Kubernetes Service) 클러스터에 대한 가상 네트워킹을 간소화합니다.
- Azure Kubernetes 부하 분산 장치를 만들면 해당 Azure 부하 분산 장치 리소스가 동시에 설정됩니다.
- Kubernetes
LoadBalancerService를 만들 때 Azure AKS에서 관리하는 리소스의 서비스 트래픽에 필요한 네트워크 보안 그룹 규칙을 구성합니다. - Azure는 새로운 Ingress 경로가 설정될 때 HTTP 애플리케이션 라우팅을 위한 외부 DNS 구성을 관리할 수도 있습니다.
가상 네트워크 Azure
AKS에서는 다음 네트워크 모델 중 하나를 사용하는 클러스터를 배포할 수 있습니다.
- 오버레이 네트워크 모델: 오버레이 네트워킹은 Kubernetes에서 사용되는 가장 일반적인 네트워킹 모델입니다. Pod에는 AKS 노드가 배포되는 Azure 가상 네트워크 서브넷과 논리적으로 분리된 프라이빗 CIDR의 IP 주소가 제공됩니다. 이 모델을 사용하면 플랫 네트워크 모델과 비교할 때 더 간단하고 향상된 확장성을 구현할 수 있습니다.
- 플랫 네트워크 모델: AKS의 플랫 네트워크 모델은 AKS 노드와 동일한 Azure 가상 네트워크의 서브넷에서 Pod에 IP 주소를 할당합니다. 프라이빗 네트워크 트래픽의 경우 대상에 표시되는 원본 IP 주소는 IPAM(IP 주소 관리) 옵션에 따라 달라집니다. Azure CNI Pod 서브넷은 연결된 가상 네트워크에서 Pod IP 주소를 유지합니다. Azure CNI 노드 서브넷을 사용하면 클러스터 가상 네트워크의 대상에 Pod IP 주소가 표시되지만 클러스터 가상 네트워크 외부의 대상에는 노드 IP 주소가 표시됩니다. 인터넷 송신의 경우 구성된 아웃바운드 메서드는 인터넷 대상에서 볼 수 있는 공용 원본 IP 주소를 결정합니다.
AKS의 네트워킹 모델에 대한 자세한 내용은 AKS의 CNI 네트워킹을 참조하세요.
아웃바운드(송신) 트래픽 제어
AKS 클러스터는 가상 네트워크에 배포되며 거의 전적으로 FQDN(정규화된 도메인 이름)으로 정의되는 해당 가상 네트워크 외부의 서비스에 대한 아웃바운드 종속성을 갖습니다. AKS는 이러한 외부 리소스에 액세스하는 방법을 사용자 지정할 수 있는 몇 가지 아웃바운드 구성 옵션을 제공합니다.
중요합니다
March 31, 2026부터 AKS(Azure Kubernetes Service) VM(가상 머신)에 대한 기본 아웃바운드 액세스를 더 이상 지원하지 않습니다.
AKS 관리형 가상 네트워크 옵션을 사용하는 새 AKS 클러스터는 기본적으로() defaultOutboundAccess = false에 배치합니다. 이 설정은 명시적으로 구성된 아웃바운드 경로를 사용하는 AKS 관리형 클러스터 트래픽에 영향을 주지 않습니다. 다른 리소스를 동일한 서브넷에 배포하는 것과 같이 지원되지 않는 시나리오에 영향을 줄 수 있습니다.
BYO VNet을 사용하는 클러스터는 이 변경의 영향을 받지 않습니다. 지원되는 구성에서는 아무 작업도 필요하지 않습니다. 이 사용 중지에 대한 자세한 내용은 Azure 업데이트 사용 중지 공지 참조하세요. 공지 사항 및 업데이트에 대한 정보를 알아보려면 AKS 릴리스 정보를 참조하십시오.
아웃바운드 구성 옵션
지원되는 AKS 클러스터 출구 구성 유형에 대한 자세한 내용은 AKS(Azure Kubernetes Service)에서 구성할 수 있는 클러스터 출구 유형 사용자 지정을 참조하세요.
기본적으로 AKS 클러스터에는 실행하는 노드 및 서비스가 필요에 따라 외부 리소스에 액세스할 수 있도록 하는 무제한 아웃바운드(송신) 인터넷 액세스가 있습니다. 원하는 경우 아웃바운드 트래픽을 제한할 수 있습니다.
클러스터에서 아웃바운드 트래픽을 제한하는 방법에 대한 자세한 내용은 AKS에서 클러스터 노드에 대한 송신 트래픽 제어를 참조하세요.
네트워크 보안 그룹
네트워크 보안 그룹은 AKS 노드와 같은 VM의 트래픽을 필터링합니다. 서비스(예: LoadBalancer서비스)를 만들 때 Azure 플랫폼은 AKS에서 관리하는 리소스의 서비스 트래픽에 필요한 네트워크 보안 그룹 규칙을 자동으로 구성합니다.
AKS는 서브넷에 네트워크 보안 그룹을 적용하거나 고객이 제공한 서브넷과 연결하는 네트워크 보안 그룹을 수정하지 않습니다. 네트워크 보안 그룹을 사용자 지정 서브넷과 연결하는 경우 해당 규칙이 필요한 노드 및 Pod 트래픽을 허용하는지 확인해야 합니다. 자세한 내용은 AKS CNI 네트워킹 필수 구성 요소를 참조하세요.
또한 네트워크 정책을 사용하여 트래픽 필터 규칙을 Pod에 자동으로 적용할 수도 있습니다.
자세한 내용은 네트워크 보안 그룹이 네트워크 트래픽을 필터링하는 방법을 참조하세요.
사용자 지정 가상 네트워크 요구 사항
AKS 클러스터에서 사용자 지정 가상 네트워크를 사용하는 경우 서브넷 간의 트래픽을 제한하는 네트워크 보안 그룹 규칙을 추가하는 경우 규칙이 클러스터 구성에 필요한 트래픽을 허용하는지 확인합니다.
API 서버 VNet 통합은 AKS 자동에서 미리 구성됩니다. AKS 표준에서 이 기능은 선택 사항이며 명시적으로 사용하도록 설정해야 합니다. 클러스터에서 API 서버 VNet 통합을 사용하는 경우 다음 트래픽을 허용합니다.
| 목적지 | 출처 | 프로토콜 | 항구 | 사용 |
|---|---|---|---|---|
| APIServer 서브넷 CIDR | 클러스터 서브넷 | TCP | 443 및 4443 | 노드와 API 서버 간 통신을 사용하도록 설정하는 데 필요합니다. |
| APIServer 서브넷 CIDR | Azure 부하 분산 장치 | TCP | 9988 | Azure Load Balancer API 서버 간의 통신을 사용하도록 설정하는 데 필요합니다. Azure Load Balancer와 API 서버 서브넷 CIDR 간의 모든 통신을 활성화할 수도 있습니다. |
자세한 내용은 API Server VNet 통합을 참조하세요.
노드 및 Pod 통신의 경우 네트워크 보안 그룹 규칙이 해당 CIDR 범위를 제한하는 경우 다음 트래픽을 허용합니다.
| 목적지 | 출처 | 프로토콜 | 항구 | 사용 |
|---|---|---|---|---|
| 노드 CIDR | 노드 CIDR | 모든 프로토콜 | 모든 포트 | 노드 간 통신을 사용하도록 설정하는 데 필요합니다. |
| Pod CIDR | 노드 CIDR | 모든 프로토콜 | 모든 포트 | 서비스 트래픽 라우팅에 필요합니다. |
| Pod CIDR | Pod CIDR | 모든 프로토콜 | 모든 포트 | Pod 간 및 Pod에서 서비스로의 트래픽(DNS 포함)에 필요합니다. |
해당 노드 및 Pod CIDR 범위는 클러스터의 네트워크 모델에 따라 달라집니다. 자세한 내용은 AKS CNI 네트워킹 필수 구성 요소를 참조하세요.
DNS 확인
DNS 확인은 AKS의 서비스 검색 및 통신에 필수적입니다. 기본적으로 AKS는 CoreDNS 를 사용하여 Pod 및 서비스에 대한 내부 이름 확인을 제공합니다.
DNS 성능 및 안정성 향상을 위해 AKS는 각 노드에 DNS 프록시를 배포하는 LocalDNS를 제공합니다. LocalDNS는 로컬에서 쿼리를 해결하여 대기 시간을 줄이고 DNS 트래픽의 테이블 압력을 제거 conntrack 합니다. 업스트림 DNS 중단 중에 캐시된 응답을 제공하도록 LocalDNS를 구성할 수 있지만 부실 응답 캐싱은 최상의 방식으로 작동합니다. LocalDNS는 DNS 쿼리 볼륨이 높은 대규모 클러스터 또는 환경에서 특히 유용합니다.
LocalDNS는 AKS 자동에서 미리 구성됩니다. AKS 표준에서 LocalDNS는 선택 사항이며 노드 풀별로 구성됩니다. AKS Standard에서 사용하도록 설정하기 전에 Kubernetes 버전, 노드 운영 체제 및 VM SKU 필수 구성 요소를 확인합니다. 기존 노드 풀에서 LocalDNS를 사용하도록 설정하면 해당 노드 풀의 노드가 재이미징됩니다. 필수 구성 요소 및 롤아웃 계획은 LocalDNS 구성을 참조하세요.
네트워크 정책
기본적으로 AKS 클러스터의 모든 pod는 트래픽을 제한 없이 송수신할 수 있습니다. 보안 향상을 위해 다음과 같이 트래픽의 흐름을 제어하는 규칙을 정의할 수 있습니다.
- 백 엔드 애플리케이션은 필요한 프런트 엔드 서비스에만 노출됩니다.
- 데이터베이스 구성 요소에 연결하는 애플리케이션 계층에서만 해당 구성 요소에 액세스할 수 있습니다.
네트워크 정책은 AKS에서 사용 가능한 Kubernetes 기능으로서 사용자가 Pod 간의 트래픽 흐름을 제어하도록 돕습니다. 할당된 레이블, 네임스페이스 또는 트래픽 포트와 같은 설정에 따라 Pod에 대한 트래픽을 허용하거나 거부할 수 있습니다. 네트워크 보안 그룹은 AKS 노드에 더 적합하지만 네트워크 정책은 Pod에 대한 트래픽 흐름을 제어하는 데 더 적합한 클라우드 네이티브 방법입니다. Pod는 AKS 클러스터에서 동적으로 생성되므로 필요한 네트워크 정책을 자동으로 적용할 수 있습니다.
자세한 정보는 AKS(Azure Kubernetes Service)에서 네트워크 정책을 사용하여 Pod 간 트래픽을 보호합니다.를 참조하십시오.
다음 단계
AKS 네트워킹을 시작하려면 Azure CNI 오버레이 또는 Azure CNI 사용하여 고유한 IP 주소 범위로 AKS 클러스터를 만들고 구성합니다.
관련된 모범 사례에 대해서는 AKS의 네트워크 연결 및 보안에 대한 모범 사례를 참조하세요.
Kubernetes 및 AKS 핵심 개념에 대한 자세한 내용은 다음 문서를 참조하세요.