チュートリアル: Azure Kubernetes Service (AKS) でのアプリケーションに対するネットワークの概念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. セキュリティ上の理由で、ポッドとノードに対するネットワーク トラフィックまたはポッドとノード間でのネットワーク トラフィックのフロー制限が必要な場合もあります。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 ノードは、ポッドに対して受信接続と送信接続を実行できます。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 では、特定のポートで IP アドレスまたは DNS 名を使用した直接アクセスを許可するように、"サービス" によってポッドが論理的にグループ化されます。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. ポッドに対するネットワーク トラフィックのセキュリティ保護とフィルター処理は、Kubernetes の "ネットワーク ポリシー" (AKS ではプレビュー段階) によって実行できます。Security and filtering of the network traffic for pods is possible with Kubernetes network policies (in preview in AKS).

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. ポッドへのネットワーク ポートを開くと、対応する 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.

サービスServices

アプリケーション ワークロードのネットワーク構成を簡素化するため、Kubernetes では、"サービス" を使用して、一連のポッドを論理的にグループ化してネットワーク接続を行います。To simplify the network configuration for application workloads, Kubernetes uses Services to logically group a set of pods together and provide network connectivity. 次の種類のサービスを使用できます。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 アドレスを構成し、要求されたポッドをロード バランサーのバックエンド プールに接続します。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 クラスター内の負荷分散トラフィック フローを示す図

    制御と受信トラフィックのルーティングを追加するため、イングレス コントローラーを代わりに使用できます。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 can't be accessed from the Internet.

Azure 仮想ネットワークAzure virtual networks

AKS では、次の 2 つのネットワーク モデルのいずれかを使用するクラスターをデプロイできます。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 Container Networking Interface (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 仮想ネットワーク サブネットから IP アドレスを取得します。With kubenet, nodes get an IP address from the Azure virtual network subnet. ポッドでは、ノードの Azure 仮想ネットワーク サブネットとは論理的に異なるアドレス空間から IP アドレスを受け取ります。Pods receive an IP address from a logically different address space to the Azure virtual network subnet of the nodes. その後、ポッドで Azure 仮想ネットワークのリソースに到達できるように、ネットワーク アドレス変換 (NAT) が構成されます。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 アドレスを受信するのはノードのみであり、ポッドでは 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. この方法では、ポッド用にネットワーク空間で予約する必要がある 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 を使用して、すべてのポッドでサブネットから 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. 各ノードには、サポートされるポッドの最大数に対する構成パラメーターがあります。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.

ノードでは Azure Container Networking Interface (CNI) Kubernetes プラグインが使用されます。Nodes use the Azure Container Networking Interface (CNI) Kubernetes plugin.

各ブリッジが 1 つの Azure VNet に接続している 2 つのノードを示す図

詳細については、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 の内部または外部ロード バランサーを使用します。Uses Kubernetes internal or external load balancer to reach pods from outside of the cluster.
    • ユーザー定義のルート (UDR) は、手動で管理および保守する必要があります。You must manually manage and maintain user-defined routes (UDRs).
    • クラスターあたり最大 400 ノード。Maximum of 400 nodes per cluster.
  • Azure CNIAzure CNI
    • ポッドは完全な仮想ネットワーク接続を取得するため、クラスターの外部から直接アクセスできます。Pods get full virtual network connectivity and can be directly reached from outside of the cluster.
    • より多くの 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 サポートされています - UDR は手動で適用されますSupported - UDRs manually applied サポートされていますSupported
ポッド間接続Pod-pod connectivity サポートされていますSupported サポートされていますSupported
ポッドと VM の接続。同一仮想ネットワーク内の VMPod-VM connectivity; VM in the same virtual network ポッドによって開始されたときに動作しますWorks when initiated by pod 両方の方法で動作しますWorks both ways
ポッドと VM の接続。ピアリングされた仮想ネットワーク内の VMPod-VM connectivity; VM in peered virtual network ポッドによって開始されたときに動作しますWorks when initiated by pod 両方の方法で動作しますWorks both ways
VPN または Express Route を使用したオンプレミスへのアクセスOn-premises access using VPN or Express Route ポッドによって開始されたときに動作しますWorks when initiated by pod 両方の方法で動作しますWorks both ways
サービス エンドポイントによって保護されているリソースへのアクセスAccess to resources secured by service endpoints サポートされていますSupported サポートされていますSupported
ロード バランサー サービス、App Gateway、またはイングレス コントローラーを使用して、Kubernetes サービスを公開する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

ネットワーク モデル間のサポート範囲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.

サービス エンドポイントや UDR のような機能は 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 クラスターの仮想ネットワーク リソースを手動で作成する場合は、独自の UDR またはサービス エンドポイントを構成するときにサポートされます。If you manually create the virtual network resources for an AKS cluster, you are supported when configuring your own UDRs or service endpoints.
  • Azure プラットフォームが AKS クラスター用の仮想ネットワーク リソースを自動的に作成する場合、それらの AKS 管理対象リソースを手動で変更して独自の UDR またはサービスエンドポイントを構成することはサポートされていません。If the Azure platform automatically creates the virtual network resources for your AKS cluster, it is not supported to manually change those AKS-managed resources to configure your own UDRs or service endpoints.

イングレス コントローラーIngress controllers

LoadBalancer 型のサービスを作成すると、基になる Azure ロード バランサー リソースが作成されます。When you create a LoadBalancer type Service, an underlying Azure load balancer resource is created. ロード バランサーは、特定のポートでサービス内のポッドにトラフィックを分散するように構成されます。The load balancer is configured to distribute traffic to the pods in your Service on a given port. LoadBalancer はレイヤー 4 でのみ動作します。サービスは実際のアプリケーションを認識せず、追加のルーティングを考慮することはできません。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.

イングレスのもう 1 つの一般的な機能は、SSL/TLS 終端です。Another common feature of Ingress is SSL/TLS termination. HTTPS 経由でアクセスされる大規模な Web アプリケーションでは、アプリケーション自体の中ではなく、イングレス リソースによって 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.

イングレス コントローラーを構成して、クライアント ソース IP を AKS クラスター内のコンテナーへの要求上で保持することもできます。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 will not be available to the target container. クライアント ソース IP の保持を有効にすると、クライアントに対するソース IP は、X-Forwarded-For 下にある要求ヘッダー内で利用できます。When you enable client source IP preservation, the source IP for the client is available in the request header under X-Forwarded-For. クライアント ソース IP の保持機能をイングレス コントローラー上で使用している場合は、SSL パススルーを使用することはできません。If you are using client source IP preservation on your ingress controller, you cannot use SSL pass-through. クライアント ソース IP の保持と SSL パススルーは、LoadBalancer 型など、他のサービスによって使用できます。Client source IP preservation and SSL 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 などのサービスを作成すると、必要なネットワーク セキュリティ グループ規則が Azure プラットフォームによって自動的に構成されます。As you create Services, such as a LoadBalancer, the Azure platform automatically configures any network security group rules that are needed. AKS クラスター内のポッドに対するトラフィックをフィルター処理するネットワーク セキュリティ グループ規則は手動で構成しないでください。Don't manually configure network security group rules to filter traffic for pods in an AKS cluster. Kubernetes サービス マニフェストの一部として必要なポートと転送を定義し、適切なルールの作成または更新は 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. 次のセクションで説明するように、ネットワーク ポリシーを使用し、ポッドにトラフィックのフィルター規則を自動的に適用することもできます。You can also use network policies, as discussed in the next section, to automatically apply traffic filter rules to pods.

ネットワーク ポリシーNetwork policies

既定では、AKS クラスター内のすべてのポッドは制限なしにトラフィックを送受信できます。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 で使用可能な 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. ネットワーク セキュリティ グループは、ポッドではなく、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. ポッドは AKS クラスター内で動的に作成されるため、必要なネットワーク ポリシーを自動的に適用できます。As pods are dynamically created in an AKS cluster, the required network policies can be automatically applied.

詳細については、「Azure Kubernetes Service (AKS) のネットワーク ポリシーを使用したポッド間のトラフィックの保護」を参照してください。For more information, see Secure traffic between pods using network policies in Azure Kubernetes Service (AKS).

次の手順Next steps

AKS ネットワークの使用を開始するために、kubenet or 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: