애플리케이션에 대한 AKS(Azure Kubernetes Service)의 네트워크 개념Network concepts for applications in Azure Kubernetes Service (AKS)

애플리케이션 개발에 대한 컨테이너 기반 마이크로 서비스 접근 방식에서 애플리케이션 구성 요소는 함께 작동하여 해당 작업을 처리해야 합니다.In a container-based microservices approach to application development, application components must work together to process their tasks. Kubernetes는 이 애플리케이션 통신을 사용할 수 있게 하는 다양한 리소스를 제공합니다.Kubernetes provides various resources that enable this application communication. 애플리케이션을 내부 또는 외부에 연결하고 공개할 수 있습니다.You can connect to and expose applications internally or externally. 고가용성 애플리케이션을 빌드하기 위해 애플리케이션의 부하를 분산시킬 수 있습니다.To build highly available applications, you can load balance your applications. 더 복잡한 애플리케이션에는 SSL/TLS 종료 또는 여러 구성 요소의 라우팅에 대한 수신 트래픽 구성이 필요할 수 있습니다.More complex applications may require configuration of ingress traffic for SSL/TLS termination or routing of multiple components. 보안상의 이유로 Pod, 노드 또는 서로 간의 네트워크 트래픽 흐름을 제한해야 할 수도 있습니다.For security reasons, you may also need to restrict the flow of network traffic into or between pods and nodes.

이 문서에서는 AKS에서 네트워킹을 애플리케이션에 제공하는 핵심 개념을 소개합니다.This article introduces the core concepts that provide networking to your applications in AKS:

Kubernetes 기본 사항Kubernetes basics

애플리케이션에 액세스하거나 애플리케이션 구성 요소가 서로 통신할 수 있도록 Kubernetes에서 추상화 계층을 가상 네트워킹에 제공합니다.To allow access to your applications, or for application components to communicate with each other, Kubernetes provides an abstraction layer to virtual networking. Kubernetes 노드는 가상 네트워크에 연결되고, Pod에 대한 인바운드 및 아웃바운드 연결을 제공할 수 있습니다.Kubernetes nodes are connected to a virtual network, and can provide inbound and outbound connectivity for pods. kube-proxy 구성 요소가 각 노드에서 실행되어 이러한 네트워크 기능을 제공합니다.The kube-proxy component runs on each node to provide these network features.

Kubernetes에서 Services는 IP 주소 또는 DNS 이름을 통해 특정 포트에서 직접 액세스할 수 있도록 Pod를 논리적으로 그룹화합니다.In Kubernetes, Services logically group pods to allow for direct access via an IP address or DNS name and on a specific port. 트래픽은 부하 분산 장치를 사용하여 분산시킬 수도 있습니다.You can also distribute traffic using a load balancer. 더 복잡한 애플리케이션 트래픽 라우팅은 수신 컨트롤러를 사용하여 수행할 수도 있습니다.More complex routing of application traffic can also be achieved with Ingress Controllers. Pod에 대한 네트워크 트래픽의 보안 및 필터링은 Kubernetes 네트워크 정책을 사용하여 수행할 수 있습니다.Security and filtering of the network traffic for pods is possible with Kubernetes network policies.

또한 Azure 플랫폼은 AKS 클러스터에 대한 가상 네트워킹을 간소화하는 데에도 도움이 됩니다.The Azure platform also helps to simplify virtual networking for AKS clusters. Kubernetes 부하 분산 장치를 만들면 기본 Azure 부하 분산 장치 리소스가 만들어지고 구성됩니다.When you create a Kubernetes load balancer, the underlying Azure load balancer resource is created and configured. Pod에서 네트워크 포트를 열면 해당 Azure 네트워크 보안 그룹 규칙이 구성됩니다.As you open network ports to pods, the corresponding Azure network security group rules are configured. HTTP 애플리케이션 라우팅의 경우 새 수신 경로가 구성될 때 Azure에서 외부 DNS를 구성할 수도 있습니다.For HTTP application routing, Azure can also configure external DNS as new ingress routes are configured.

ServicesServices

애플리케이션 워크로드에 대한 네트워크 구성을 간소화하기 위해 Kubernetes는 Service를 사용하여 일단의 Pod를 논리적으로 그룹화하고 네트워크 연결을 제공합니다.To simplify the network configuration for application workloads, Kubernetes uses Services to logically group a set of pods together and provide network connectivity. 사용할 수 있는 Service 유형은 다음과 같습니다.The following Service types are available:

  • 클러스터 IP - AKS 클러스터 내에서 사용할 내부 IP 주소를 만듭니다.Cluster IP - Creates an internal IP address for use within the AKS cluster. 클러스터 내의 다른 워크로드를 지원하는 내부 전용 애플리케이션에 적합합니다.Good for internal-only applications that support other workloads within the cluster.

    AKS 클러스터의 클러스터 IP 트래픽 흐름을 보여 주는 다이어그램

  • NodePort - 노드 IP 주소와 포트를 사용하여 애플리케이션에 직접 액세스할 수 있도록 포트 매핑을 기본 노드에 만듭니다.NodePort - Creates a port mapping on the underlying node that allows the application to be accessed directly with the node IP address and port.

    AKS 클러스터의 NodePort 트래픽 흐름을 보여 주는 다이어그램

  • LoadBalancer - Azure 부하 분산 장치 리소스를 만들고, 외부 IP 주소를 구성하고, 요청된 Pod를 부하 분산 장치 백 엔드 풀에 연결합니다.LoadBalancer - Creates an Azure load balancer resource, configures an external IP address, and connects the requested pods to the load balancer backend pool. 고객의 트래픽이 응용 프로그램에 도달 하도록 허용 하기 위해 원하는 포트에서 부하 분산 규칙이 생성 됩니다.To allow customers' traffic to reach the application, load balancing rules are created on the desired ports.

    AKS 클러스터의 Load Balancer 트래픽 흐름을 보여 주는 다이어그램

    인바운드 트래픽을 추가로 제어하고 라우팅하려면 수신 컨트롤러를 대신 사용할 수 있습니다.For additional control and routing of the inbound traffic, you may instead use an Ingress controller.

  • ExternalName - 애플리케이션에 쉽게 액세스하기 위한 특정 DNS 항목을 만듭니다.ExternalName - Creates a specific DNS entry for easier application access.

부하 분산 장치 및 서비스에 대한 IP 주소는 동적으로 할당하거나 사용할 기존 고정 IP 주소를 지정할 수 있습니다.The IP address for load balancers and services can be dynamically assigned, or you can specify an existing static IP address to use. 내부 및 외부 고정 IP 주소를 모두 할당할 수 있습니다.Both internal and external static IP addresses can be assigned. 이 기존 고정 IP 주소는 종종 DNS 항목에 연결됩니다.This existing static IP address is often tied to a DNS entry.

내부외부 부하 분산 장치를 모두 만들 수 있습니다.Both internal and external load balancers can be created. 내부 부하 분산 장치는 개인 IP 주소만 할당 하므로 인터넷에서 액세스할 수 없습니다.Internal load balancers are only assigned a private IP address, so they can't be accessed from the Internet.

Azure 가상 네트워크Azure virtual networks

AKS에서는 다음 두 가지 네트워크 모델 중 하나를 사용하는 클러스터를 배포할 수 있습니다.In AKS, you can deploy a cluster that uses one of the following two network models:

  • Kubenet 네트워킹 - 네트워크 리소스는 일반적으로 AKS 클러스터가 배포될 때 만들어지고 구성됩니다.Kubenet networking - The network resources are typically created and configured as the AKS cluster is deployed.
  • Azure CNI(컨테이너 네트워킹 인터페이스) 네트워킹 - AKS 클러스터가 기존 가상 네트워크 리소스 및 구성에 연결됩니다.Azure Container Networking Interface (CNI) networking - The AKS cluster is connected to existing virtual network resources and configurations.

Kubenet(기본) 네트워킹Kubenet (basic) networking

kubenet 네트워킹 옵션은 AKS 클러스터 만들기에 대한 기본 구성입니다.The kubenet networking option is the default configuration for AKS cluster creation. kubenet을 사용하면 노드는 Azure Virtual Network 서브넷의 IP 주소를 얻습니다.With kubenet, nodes get an IP address from the Azure virtual network subnet. Pod는 논리적으로 다른 주소 공간에서 노드의 Azure 가상 네트워크 서브넷으로 IP 주소를 수신합니다.Pods receive an IP address from a logically different address space to the Azure virtual network subnet of the nodes. 그러면 Pod가 Azure 가상 네트워크의 리소스에 연결할 수 있도록 NAT(Network Address Translation)가 구성됩니다.Network address translation (NAT) is then configured so that the pods can reach resources on the Azure virtual network. 트래픽의 원본 IP 주소는 노드의 기본 IP 주소로 NAT됩니다.The source IP address of the traffic is NAT'd to the node's primary IP address.

노드는 kubenet Kubernetes 플러그인을 사용합니다.Nodes use the kubenet Kubernetes plugin. Azure 플랫폼에서 가상 네트워크를 만들고 구성하거나 기존 가상 네트워크 서브넷에 AKS 클러스터를 배포하도록 선택할 수 있습니다.You can let the Azure platform create and configure the virtual networks for you, or choose to deploy your AKS cluster into an existing virtual network subnet. 다시 말해, 노드만 라우팅할 수 있는 IP 주소를 받으며 pod는 NAT를 사용 하 여 AKS 클러스터 외부의 다른 리소스와 통신 합니다.Again, only the nodes receive a routable IP address, and the pods use NAT to communicate with other resources outside the AKS cluster. 이 방법을 사용하면 네트워크 공간에서 Pod가 사용하도록 예약해야 하는 IP 주소의 수가 크게 줄어듭니다.This approach greatly reduces the number of IP addresses that you need to reserve in your network space for pods to use.

자세한 내용은 AKS 클러스터에 대한 kubenet 네트워킹 구성을 참조하세요.For more information, see Configure kubenet networking for an AKS cluster.

Azure CNI(고급) 네트워킹Azure CNI (advanced) networking

Azure CNI를 사용하면 모든 Pod가 서브넷에서 IP 주소를 가져오고 직접 액세스가 가능합니다.With Azure CNI, every pod gets an IP address from the subnet and can be accessed directly. 이러한 IP 주소는 네트워크 공간에서 고유해야 하며 미리 계획되어야 합니다.These IP addresses must be unique across your network space, and must be planned in advance. 각 노드에는 지원하는 최대 Pod 수에 대한 구성 매개 변수가 있습니다.Each node has a configuration parameter for the maximum number of pods that it supports. 그러면 노드당 동일한 IP 주소 수가 해당 노드에 대해 미리 예약됩니다.The equivalent number of IP addresses per node are then reserved up front for that node. 이 접근 방식에는 추가 계획이 필요 합니다. 그렇지 않으면 IP 주소 고갈 또는 응용 프로그램 요구가 증가 함에 따라 더 큰 서브넷에서 클러스터를 다시 작성 해야 합니다.This approach requires more planning, as can otherwise lead to IP address exhaustion or the need to rebuild clusters in a larger subnet as your application demands grow.

Kubenet와 달리 동일한 가상 네트워크의 끝점에 대 한 트래픽은 노드의 기본 IP에 대 한 NAT가 아닙니다.Unlike kubenet, traffic to endpoints in the same virtual network isn't NAT'd to the node's primary IP. 가상 네트워크 내의 트래픽에 대 한 원본 주소는 pod IP입니다.The source address for traffic inside the virtual network is the pod IP. 가상 네트워크 외부의 트래픽은 여전히 노드의 기본 IP로 Nat 합니다.Traffic that's external to the virtual network still NATs to the node's primary IP.

노드는 Azure CNI(컨테이너 네트워킹 인터페이스) Kubernetes 플러그인을 사용합니다.Nodes use the Azure Container Networking Interface (CNI) Kubernetes plugin.

각 노드를 단일 Azure VNet에 연결하는 브리지가 있는 두 노드를 보여주는 다이어그램

자세한 내용은 AKS 클러스터에 대한 Azure CNI 구성을 참조하세요.For more information, see Configure Azure CNI for an AKS cluster.

네트워크 모델 비교Compare network models

Kubenet와 Azure CNI 모두 AKS 클러스터에 대 한 네트워크 연결을 제공 합니다.Both kubenet and Azure CNI provide network connectivity for your AKS clusters. 그러나 각각에는 장점과 단점이 있습니다.However, there are advantages and disadvantages to each. 개략적인 수준에서 다음과 같은 고려 사항이 적용 됩니다.At a high level, the following considerations apply:

  • kubenetkubenet
    • IP 주소 공간을 절약 합니다.Conserves IP address space.
    • Kubernetes 내부 또는 외부 부하 분산 장치를 사용 하 여 클러스터 외부에서 pod에 연결 합니다.Uses Kubernetes internal or external load balancer to reach pods from outside of the cluster.
    • 수동으로 UDRs (사용자 정의 경로)를 관리 하 고 유지 관리 해야 합니다.You must manually manage and maintain user-defined routes (UDRs).
    • 클러스터 당 최대 400 노드 수Maximum of 400 nodes per cluster.
  • Azure CNIAzure CNI
    • Pod는 전체 가상 네트워크 연결을 가져오고 연결 된 네트워크에서 개인 IP 주소를 통해 직접 연결할 수 있습니다.Pods get full virtual network connectivity and can be directly reached via their private IP address from connected networks.
    • 에 더 많은 IP 주소 공간이 필요 합니다.Requires more IP address space.

Kubenet와 Azure CNI 간에는 다음과 같은 동작 차이가 있습니다.The following behavior differences exist between kubenet and Azure CNI:

기능Capability KubenetKubenet Azure CNIAzure CNI
기존 또는 새 가상 네트워크에 클러스터 배포Deploy cluster in existing or new virtual network 지원 됨-UDRs 수동 적용 됨Supported - UDRs manually applied 지원됨Supported
Pod-pod 연결Pod-pod connectivity 지원됨Supported 지원됨Supported
Pod-VM 연결 동일한 가상 네트워크의 VMPod-VM connectivity; VM in the same virtual network Pod에 의해 시작 된 경우 작동 합니다.Works when initiated by pod 두 가지 방식으로 작동 합니다.Works both ways
Pod-VM 연결 피어 링 가상 네트워크의 VMPod-VM connectivity; VM in peered virtual network Pod에 의해 시작 된 경우 작동 합니다.Works when initiated by pod 두 가지 방식으로 작동 합니다.Works both ways
VPN 또는 Express 경로를 사용 하 여 온-프레미스 액세스On-premises access using VPN or Express Route Pod에 의해 시작 된 경우 작동 합니다.Works when initiated by pod 두 가지 방식으로 작동 합니다.Works both ways
서비스 끝점으로 보호 되는 리소스에 대 한 액세스Access to resources secured by service endpoints 지원됨Supported 지원됨Supported
부하 분산 장치 서비스, 앱 게이트웨이 또는 수신 컨트롤러를 사용 하 여 Kubernetes services 노출Expose Kubernetes services using a load balancer service, App Gateway, or ingress controller 지원됨Supported 지원됨Supported
기본 Azure DNS 및 개인 영역Default Azure DNS and Private Zones 지원됨Supported 지원됨Supported

Kubenet 및 Azure CNI 플러그 인 DNS를 모두 사용 하는 DNS와 관련 하 여 AKS에서 실행 되는 배포 인 CoreDNS는 자체 autoscaler를 통해 제공 됩니다.Regarding DNS, with both kubenet and Azure CNI plugins DNS is offered by CoreDNS, a deployment running in AKS with its own autoscaler. CoreDNS on Kubernetes에 대 한 자세한 내용은 DNS 서비스 사용자 지정을 참조 하세요.For more information on CoreDNS on Kubernetes see Customizing DNS Service. CoreDNS는 AKS 클러스터가 배포 되는 Azure Virtual Network의 DNS 기능에 대 한 알 수 없는 도메인을 노드 DNS 서버로 전달 하기 위해 기본적으로 구성 됩니다.CoreDNS is configured per default to forward unknown domains to the node DNS servers, in other words, to the DNS functionality of the Azure Virtual Network where the AKS cluster is deployed. 따라서 Azure DNS 및 개인 영역은 AKS에서 실행 되는 pod에 대해 작동 합니다.Hence, Azure DNS and Private Zones will work for pods running in AKS.

네트워크 모델 간의 범위 지원Support scope between network models

사용 하는 네트워크 모델에 관계 없이 kubenet와 Azure CNI는 다음 중 한 가지 방법으로 배포할 수 있습니다.Regardless of the network model you use, both kubenet and Azure CNI can be deployed in one of the following ways:

  • Azure 플랫폼은 AKS 클러스터를 만들 때 가상 네트워크 리소스를 자동으로 만들고 구성할 수 있습니다.The Azure platform can automatically create and configure the virtual network resources when you create an AKS cluster.
  • AKS 클러스터를 만들 때 가상 네트워크 리소스를 수동으로 만들고 구성 하 고 해당 리소스에 연결할 수 있습니다.You can manually create and configure the virtual network resources and attach to those resources when you create your AKS cluster.

서비스 엔드포인트 나 UDRs와 같은 기능이 kubenet 및 Azure CNI 모두에서 지원 되기는 하지만 AKS에 대 한 지원 정책은 어떤 변경 작업을 수행할 수 있는지를 정의 합니다.Although capabilities like service endpoints or UDRs are supported with both kubenet and Azure CNI, the support policies for AKS define what changes you can make. 예를 들면 다음과 같습니다.For example:

  • AKS 클러스터에 대 한 가상 네트워크 리소스를 수동으로 만드는 경우 고유한 UDRs 또는 서비스 끝점을 구성할 때 지원 됩니다.If you manually create the virtual network resources for an AKS cluster, you're supported when configuring your own UDRs or service endpoints.
  • Azure 플랫폼에서 AKS 클러스터에 대 한 가상 네트워크 리소스를 자동으로 만드는 경우 해당 AKS 관리 리소스를 수동으로 변경 하 여 사용자 고유의 UDRs 또는 서비스 끝점을 구성할 수 없습니다.If the Azure platform automatically creates the virtual network resources for your AKS cluster, it isn't supported to manually change those AKS-managed resources to configure your own UDRs or service endpoints.

수신 컨트롤러Ingress controllers

LoadBalancer 유형 Service를 만들면 기본 Azure 부하 분산 장치 리소스가 만들어집니다.When you create a LoadBalancer type Service, an underlying Azure load balancer resource is created. 부하 분산 장치는 지정된 포트의 Service에 있는 Pod에 트래픽을 분산하도록 구성됩니다.The load balancer is configured to distribute traffic to the pods in your Service on a given port. LoadBalancer는 계층 4에서만 작동합니다. 즉 Service에서 실제 애플리케이션을 인식하지 못하고, 라우팅 고려 사항을 추가로 만들 수 없습니다.The LoadBalancer only works at layer 4 - the Service is unaware of the actual applications, and can't make any additional routing considerations.

수신 컨트롤러는 계층 7에서 작동하며, 더 지능적인 규칙을 사용하여 애플리케이션 트래픽을 분산시킬 수 있습니다.Ingress controllers work at layer 7, and can use more intelligent rules to distribute application traffic. 수신 컨트롤러의 일반적인 용도는 인바운드 URL에 따라 HTTP 트래픽을 다른 애플리케이션으로 라우팅하는 것입니다.A common use of an Ingress controller is to route HTTP traffic to different applications based on the inbound URL.

AKS 클러스터의 수신 트래픽 흐름을 보여 주는 다이어그램

AKS에서는 NGINX와 같은 도구를 사용하여 수신 리소스를 만들거나 AKS HTTP 애플리케이션 라우팅 기능을 사용할 수 있습니다.In AKS, you can create an Ingress resource using something like NGINX, or use the AKS HTTP application routing feature. AKS 클러스터에 대한 HTTP 애플리케이션 라우팅을 사용하도록 설정하면 Azure 플랫폼에서 수신 컨트롤러와 External-DNS 컨트롤러를 만듭니다.When you enable HTTP application routing for an AKS cluster, the Azure platform creates the Ingress controller and an External-DNS controller. Kubernetes에서 새 수신 리소스가 만들어지면 필요한 DNS A 레코드가 클러스터별 DNS 영역에 만들어집니다.As new Ingress resources are created in Kubernetes, the required DNS A records are created in a cluster-specific DNS zone. 자세한 내용은 HTTP 애플리케이션 라우팅 배포를 참조하세요.For more information, see deploy HTTP application routing.

AGIC (Application Gateway 수신 컨트롤러) 추가 기능을 통해 AKS 고객은 Azure의 기본 Application Gateway 수준 7 부하 분산 장치를 활용 하 여 클라우드 소프트웨어를 인터넷에 노출할 수 있습니다.The Application Gateway Ingress Controller (AGIC) add-on allows AKS customers to leverage Azure's native Application Gateway level 7 load-balancer to expose cloud software to the Internet. AGIC는 호스트 되는 Kubernetes 클러스터를 모니터링 하 고 Application Gateway를 지속적으로 업데이트 하 여 선택 된 서비스가 인터넷에 노출 되도록 합니다.AGIC monitors the Kubernetes cluster it is hosted on and continuously updates an Application Gateway, so that selected services are exposed to the Internet. AKS의 AGIC 추가 기능에 대 한 자세한 내용은 Application Gateway 수신 컨트롤러 란? 을 참조 하세요.To learn more about the AGIC add-on for AKS, see What is Application Gateway Ingress Controller?

수신의 또 다른 일반적인 기능은 SSL/TLS 종료입니다.Another common feature of Ingress is SSL/TLS termination. HTTPS를 통해 액세스되는 대규모 웹 애플리케이션에서 TLS 종료는 애플리케이션 자체 내에서가 아니라 수신 리소스에서 처리할 수 있습니다.On large web applications accessed via HTTPS, the TLS termination can be handled by the Ingress resource rather than within the application itself. 자동 TLS 인증 생성 및 구성을 제공하기 위해 Let's Encrypt와 같은 공급자를 사용하도록 수신 리소스를 구성할 수 있습니다.To provide automatic TLS certification generation and configuration, you can configure the Ingress resource to use providers such as Let's Encrypt. Let 's Encrypt를 사용하여 NGINX 수신 컨트롤러를 구성하는 방법에 대한 자세한 내용은 수신 및 TLS를 참조하세요.For more information on configuring an NGINX Ingress controller with Let's Encrypt, see Ingress and TLS.

AKS 클러스터의 컨테이너에 대 한 요청에 클라이언트 원본 IP를 유지 하도록 수신 컨트롤러를 구성할 수도 있습니다.You can also configure your ingress controller to preserve the client source IP on requests to containers in your AKS cluster. 클라이언트의 요청이 수신 컨트롤러를 통해 AKS 클러스터의 컨테이너에 라우팅되는 경우 해당 요청의 원래 원본 IP를 대상 컨테이너에서 사용할 수 없습니다.When a client's request is routed to a container in your AKS cluster via your ingress controller, the original source IP of that request won't be available to the target container. 클라이언트 원본 ip 유지를 사용 하도록 설정 하면 클라이언트에 대 한 원본 Ip가 X로 전달 된의요청 헤더에서 사용할 수 있습니다.When you enable client source IP preservation, the source IP for the client is available in the request header under X-Forwarded-For. 수신 컨트롤러에서 클라이언트 원본 IP 유지를 사용 하는 경우 TLS 통과를 사용할 수 없습니다.If you're using client source IP preservation on your ingress controller, you can't use TLS pass-through. 클라이언트 원본 IP 유지 및 TLS 통과는 LoadBalancer 유형과 같은 다른 서비스와 함께 사용할 수 있습니다.Client source IP preservation and TLS pass-through can be used with other services, such as the LoadBalancer type.

네트워크 보안 그룹Network security groups

네트워크 보안 그룹은 AKS 노드와 같은 VM의 트래픽을 필터링합니다.A network security group filters traffic for VMs, such as the AKS nodes. LoadBalancer와 같은 Service를 만들 때 Azure 플랫폼은 필요한 모든 네트워크 보안 그룹 규칙을 자동으로 구성합니다.As you create Services, such as a LoadBalancer, the Azure platform automatically configures any network security group rules that are needed. AKS 클러스터의 Pod에 대한 트래픽을 필터링하는 네트워크 보안 그룹 규칙은 수동으로 구성하지 않습니다.Don't manually configure network security group rules to filter traffic for pods in an AKS cluster. Kubernetes Service 매니페스트의 일부로 필요한 포트 및 전달을 정의하고, Azure 플랫폼에서 적절한 규칙을 만들거나 업데이트하도록 합니다.Define any required ports and forwarding as part of your Kubernetes Service manifests, and let the Azure platform create or update the appropriate rules. 다음 섹션에 설명 된 대로 네트워크 정책을 사용 하 여 pod에 트래픽 필터 규칙을 자동으로 적용할 수도 있습니다.You can also use network policies, as discussed in the next section, to automatically apply traffic filter rules to pods.

네트워크 정책Network policies

기본적으로 AKS 클러스터의 모든 pod는 트래픽을 제한 없이 송수신할 수 있습니다.By default, all pods in an AKS cluster can send and receive traffic without limitations. 보안 향상을 위해 트래픽의 흐름을 제어하는 규칙을 정의할 수도 있습니다.For improved security, you may want to define rules that control the flow of traffic. 보통 백 엔드 애플리케이션은 필요한 프런트 엔드 서비스에만 제공되고, 데이터베이스 구성 요소는 연결된 애플리케이션 계층에서만 액세스할 수 있습니다.Backend applications are often only exposed to required frontend services, or database components are only accessible to the application tiers that connect to them.

네트워크 정책은 AKS에서 pod 간의 트래픽 흐름을 제어할 수 있는 Kubernetes 기능입니다.Network policy is a Kubernetes feature available in AKS that lets you control the traffic flow between pods. 할당된 레이블, 네임스페이스 또는 트래픽 포트와 같은 설정에 따라 트래픽을 허용하거나 거부하도록 선택할 수 있습니다.You can choose to allow or deny traffic based on settings such as assigned labels, namespace, or traffic port. 네트워크 보안 그룹은 pod가 아닌 AKS 노드에 더 적합합니다.Network security groups are more for the AKS nodes, not pods. 네트워크 정책을 통해 트래픽 흐름을 제어하기 위한 더 적합한 클라우드 네이티브 방법을 사용할 수 있습니다.The use of network policies is a more suitable, cloud-native way to control the flow of traffic. Pod는 AKS 클러스터에서 동적으로 생성되므로 필요한 네트워크 정책을 자동으로 적용할 수 있습니다.As pods are dynamically created in an AKS cluster, the required network policies can be automatically applied.

자세한 내용은 AKS(Azure Kubernetes Service)에서 네트워크 정책을 사용하여 pod 간 트래픽 보호를 참조하세요.For more information, see Secure traffic between pods using network policies in Azure Kubernetes Service (AKS).

다음 단계Next steps

AKS 네트워킹을 시작하려면 kubenet이나 Azure CNI를 사용하여 자체 IP 주소 범위로 AKS 클러스터를 만들고 구성합니다.To get started with AKS networking, create and configure an AKS cluster with your own IP address ranges using kubenet or Azure CNI.

관련 모범 사례는 AKS의 네트워크 연결 및 보안에 대 한 모범 사례를 참조 하세요.For associated best practices, see Best practices for network connectivity and security in AKS.

Kubernetes 및 AKS 핵심 개념에 대한 자세한 내용은 다음 문서를 참조하세요.For additional information on core Kubernetes and AKS concepts, see the following articles: