Azure Kubernetes Service (AKS) についてよく寄せられる質問Frequently asked questions about Azure Kubernetes Service (AKS)

この記事では、Azure Kubernetes Service (AKS) についてよく寄せられる質問にお答えします。This article addresses frequent questions about Azure Kubernetes Service (AKS).

現在はどの Azure リージョンで AKS が提供されていますか?Which Azure regions currently provide AKS?

利用可能なリージョンの完全な一覧については、AKS の利用可能なリージョンに関するページを参照してください。For a complete list of available regions, see AKS regions and availability.

AKS クラスターを複数のリージョンに広げることはできますか?Can I spread an AKS cluster across regions?

いいえ。No. AKS クラスターはリージョン リソースであり、複数のリージョンに広げることはできません。AKS clusters are regional resources and cannot span regions. 複数のリージョンを含むアーキテクチャを作成する方法については、ビジネス継続性とディザスター リカバリーのベストプラクティスに関する記事を参照してください。See best practices for business continuity and disaster recovery for guidance on how to create an architecture that includes multiple regions.

AKS クラスターを複数の可用性ゾーンに広げることはできますか?Can I spread an AKS cluster across availability zones?

はい。Yes. 可用性ゾーンをサポートしているリージョン内の 1 つ以上の可用性ゾーンに AKS クラスターをデプロイできます。You can deploy an AKS cluster across one or more availability zones in regions that support them.

Kubernetes API サーバーにアクセスできるユーザーを制限できますか?Can I limit who has access to the Kubernetes API server?

はい。Yes. API サーバーへのアクセスを制限するためのオプションは 2 つあります。There are two options for limiting access to the API server:

  • API サーバーのパブリック エンドポイントを維持するが、信頼できる IP 範囲へのアクセスを制限する場合は、API サーバーの承認済み IP 範囲を使用します。Use API Server Authorized IP Ranges if you want to maintain a public endpoint for the API server but restrict access to a set of trusted IP ranges.
  • API サーバーへのアクセスを仮想ネットワーク内から " のみ " に制限する場合は、 プライベート クラスターを使用します。Use a private cluster if you want to limit the API server to only be accessible from within your virtual network.

1 つのクラスター内で、異なる VM サイズを設定できますか?Can I have different VM sizes in a single cluster?

はい。複数のノード プールを作成することにより、AKS クラスターで異なる仮想マシン サイズを使用できます。Yes, you can use different virtual machine sizes in your AKS cluster by creating multiple node pools.

AKS エージェント ノードにセキュリティ更新プログラムは適用されますか?Are security updates applied to AKS agent nodes?

Azure では、セキュリティ更新プログラムが夜間スケジュールでご利用のクラスター内の Linux ノードに自動的に適用されます。Azure automatically applies security patches to the Linux nodes in your cluster on a nightly schedule. ただし、必要な場合は、それらの Linux ノードが確実に再起動されるようにする必要があります。However, you are responsible for ensuring that those Linux nodes are rebooted as required. ノードを再起動するにはいくつかのオプションがあります。You have several options for rebooting nodes:

  • Azure Portal または Azure CLI から手動で行います。Manually, through the Azure portal or the Azure CLI.
  • AKS クラスターをアップグレードします。By upgrading your AKS cluster. クラスターでは、cordon ノードと drain ノードが自動的にアップグレードされてから、最新の Ubuntu イメージと、新しいパッチ バージョンまたは Kubernetes のマイナー バージョンで、新しいノードがオンラインにされます。The cluster upgrades cordon and drain nodes automatically and then bring a new node online with the latest Ubuntu image and a new patch version or a minor Kubernetes version. 詳細については、「AKS クラスターのアップグレード」を参照してください。For more information, see Upgrade an AKS cluster.
  • Kubernetes 用のオープン ソースの再起動デーモンである Kured を使用します。By using Kured, an open-source reboot daemon for Kubernetes. Kured は DaemonSet として実行され、再起動が必要であることを示すファイルの存在が各ノードで監視されます。Kured runs as a DaemonSet and monitors each node for the presence of a file that indicates that a reboot is required. クラスター全体で、クラスターのアップグレードと同じ cordon および drain プロセスによって OS の再起動が管理されます。Across the cluster, OS reboots are managed by the same cordon and drain process as a cluster upgrade.

Kured の使用の詳細については、AKS 上のノードへのセキュリティおよびカーネルの更新プログラムの適用に関する記事を参照してください。For more information about using kured, see Apply security and kernel updates to nodes in AKS.

Windows Server ノードWindows Server nodes

Windows Server ノードでは、Windows Update が自動的に実行され、最新の更新プログラムが適用されることはありません。For Windows Server nodes, Windows Update does not automatically run and apply the latest updates. Windows Update のリリース サイクルと独自の検証プロセス前後の定期的スケジュールで、AKS クラスター内のクラスターと Windows Server ノード プールでアップグレードを実行する必要があります。On a regular schedule around the Windows Update release cycle and your own validation process, you should perform an upgrade on the cluster and the Windows Server node pool(s) in your AKS cluster. このアップグレード プロセスでは、最新の Windows Server イメージと修正プログラムを実行するノードが作成されて、古いノードが削除されます。This upgrade process creates nodes that run the latest Windows Server image and patches, then removes the older nodes. このプロセスの詳細については、AKS でのノード プールのアップグレードに関するページを参照してください。For more information on this process, see Upgrade a node pool in AKS.

AKS と一緒にリソース グループが 2 つ作成されるのはなぜでしょうか?Why are two resource groups created with AKS?

AKS は、仮想マシン スケール セット、仮想ネットワーク、マネージド ディスクなど、さまざまな Azure インフラストラクチャ リソースに基づいて構築されています。AKS builds upon a number of Azure infrastructure resources, including virtual machine scale sets, virtual networks, and managed disks. これにより、AKS によって提供されるマネージド Kubernetes 環境内で、Azure プラットフォームのコア機能の多くを活用できます。This enables you to leverage many of the core capabilities of the Azure platform within the managed Kubernetes environment provided by AKS. たとえば、ほとんどの種類の Azure 仮想マシンは AKS で直接使用できます。また Azure Reservations を使用して、それらのリソースに対する割引を自動的に受け取ることができます。For example, most Azure virtual machine types can be used directly with AKS and Azure Reservations can be used to receive discounts on those resources automatically.

このアーキテクチャを有効にするため、各 AKS デプロイは、2 つのリソース グループにまたがっています。To enable this architecture, each AKS deployment spans two resource groups:

  1. 最初のリソース グループを作成します。You create the first resource group. このグループには、Kubernetes サービスのリソースのみが含まれます。This group contains only the Kubernetes service resource. AKS リソース プロバイダーにより、デプロイの間に 2 番目のリソース グループが自動的に作成されます。The AKS resource provider automatically creates the second resource group during deployment. 2 番目のリソース グループの例は、 MC_myResourceGroup_myAKSCluster_eastus です。An example of the second resource group is MC_myResourceGroup_myAKSCluster_eastus . この 2 つ目のリソース グループの名前を指定する方法については、次のセクションをご覧ください。For information on how to specify the name of this second resource group, see the next section.
  2. ノード リソース グループ と呼ばれる 2 つ目のリソース グループには、クラスターに関連付けられたインフラストラクチャ リソースがすべて含まれます。The second resource group, known as the node resource group , contains all of the infrastructure resources associated with the cluster. これらのリソースには、Kubernetes ノードの VM、仮想ネットワー キング、およびストレージが含まれます。These resources include the Kubernetes node VMs, virtual networking, and storage. 既定では、ノード リソース グループには MC_myResourceGroup_myAKSCluster_eastus のような名前が付いています。By default, the node resource group has a name like MC_myResourceGroup_myAKSCluster_eastus . AKS は、クラスターが削除されるたびにノード リソースを自動的に削除するため、クラスターのライフサイクルを共有するリソースにのみ使用する必要があります。AKS automatically deletes the node resource whenever the cluster is deleted, so it should only be used for resources which share the cluster's lifecycle.

AKS ノード リソース グループに独自の名前を指定できますか?Can I provide my own name for the AKS node resource group?

はい。Yes. 既定では、AKS によってノード リソース グループに MC_resourcegroupname_clustername_location という名前が設定されますが、独自の名前を指定することもできます。By default, AKS will name the node resource group MC_resourcegroupname_clustername_location , but you can also provide your own name.

独自のリソース グループ名を指定するには、 aks-preview Azure CLI 拡張機能バージョン 0.3.2 以降をインストールします。To specify your own resource group name, install the aks-preview Azure CLI extension version 0.3.2 or later. az aks create コマンドを使用して AKS クラスターを作成するときに、 --node-resource-group パラメーターを使用してリソース グループの名前を指定します。When you create an AKS cluster by using the az aks create command, use the --node-resource-group parameter and specify a name for the resource group. Azure Resource Manager テンプレートを使用して AKS クラスターをデプロイする場合は、 nodeResourceGroup プロパティを使用してリソース グループ名を定義できます。If you use an Azure Resource Manager template to deploy an AKS cluster, you can define the resource group name by using the nodeResourceGroup property.

  • セカンダリ リソース グループは、自分のサブスクリプションの Azure リソース プロバイダーによって自動的に作成されます。The secondary resource group is automatically created by the Azure resource provider in your own subscription.
  • カスタム リソース グループの名前を指定できるのは、クラスターを作成するときだけです。You can specify a custom resource group name only when you're creating the cluster.

ノード リソース グループを使うときは、次のことができないので注意してください。As you work with the node resource group, keep in mind that you cannot:

  • ノード リソース グループに対して既存のリソース グループを指定すること。Specify an existing resource group for the node resource group.
  • ノード リソース グループに対して異なるサブスクリプションを指定すること。Specify a different subscription for the node resource group.
  • クラスターが作成された後で、ノード リソース グループ名を変更すること。Change the node resource group name after the cluster has been created.
  • ノード リソース グループ内の管理対象リソースに名前を指定すること。Specify names for the managed resources within the node resource group.
  • ノード リソース グループ内の管理対象リソースの Azure で作成されたタグを変更または削除すること。Modify or delete Azure-created tags of managed resources within the node resource group. (詳しくは、次のセクションで追加の情報を参照してください。)(See additional information in the next section.)

ノード リソース グループ内の AKS リソースのタグや他のプロパティを変更できますか?Can I modify tags and other properties of the AKS resources in the node resource group?

ノード リソース グループ内の Azure で作成されたタグや他のリソース プロパティを変更または削除する場合、スケーリングやアップグレードのエラーなど、予期しない結果になる可能性があります。If you modify or delete Azure-created tags and other resource properties in the node resource group, you could get unexpected results such as scaling and upgrading errors. AKS を使用すると、エンドユーザーが作成したカスタム タグを作成および変更できます。また、ノード プールを作成するときにそれらのタグを追加できます。AKS allows you to create and modify custom tags created by end-users, and you can add those tags when creating a node pool. たとえばビジネス単位やコスト センターを割り当てるために、カスタム タグを作成または変更することがあります。You might want to create or modify custom tags, for example, to assign a business unit or cost center. これは、マネージド リソース グループにスコープを指定して Azure ポリシーを作成することによっても実現できます。This can also be achieved by creating Azure Policies with a scope on the managed resource group.

ただし、AKS クラスター内のノード リソース グループにあるリソース上で Azure によって作成されたタグ を変更することは、サポートされていないアクションであり、サービス レベル目標 (SLO) が損なわれます。However, modifying any Azure-created tags on resources under the node resource group in the AKS cluster is an unsupported action which breaks the service-level objective (SLO). 詳細については、「AKS でサービス レベル アグリーメントは提供されますか?」を参照してください。For more information, see Does AKS offer a service-level agreement?

AKS ではどのような Kubernetes アドミッション コントローラーがサポートされますか?What Kubernetes admission controllers does AKS support? アドミッション コントローラーの追加や削除はできますか?Can admission controllers be added or removed?

AKS では、以下のアドミッション コントローラーがサポートされています。AKS supports the following admission controllers:

  • NamespaceLifecycleNamespaceLifecycle
  • LimitRangerLimitRanger
  • ServiceAccountServiceAccount
  • DefaultStorageClassDefaultStorageClass
  • DefaultTolerationSecondsDefaultTolerationSeconds
  • MutatingAdmissionWebhookMutatingAdmissionWebhook
  • ValidatingAdmissionWebhookValidatingAdmissionWebhook
  • ResourceQuotaResourceQuota

現在は、AKS でアドミッション コントローラーの一覧を変更することはできません。Currently, you can't modify the list of admission controllers in AKS.

AKS でアドミッション コントローラー Webhook を使用できますか?Can I use admission controller webhooks on AKS?

はい、AKS でアドミッション コントローラー Webhook を使用できます。Yes, you may use admission controller webhooks on AKS. control-plane ラベル でマークされた内部 AKS 名前空間を除外することをお勧めします。It is recommended you exclude internal AKS namespaces which are marked with the control-plane label. たとえば、以下を Webhook 構成に追加します。For example, by adding the below to the webhook configuration:

namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist

アドミッション コントローラー Webhook は kube-system と内部 AKS 名前空間に影響しますか?Can admission controller webhooks impact kube-system and internal AKS namespaces?

システムの安定性を保護し、カスタムのアドミッション コントローラーが kube-system の内部サービスに影響を与えないようにするために、名前空間 AKS には Admissions Enforcer があります。これにより、kube-system と AKS の内部名前空間が自動的に除外されます。To protect the stability of the system and prevent custom admission controllers from impacting internal services in the kube-system, namespace AKS has an Admissions Enforcer , which automatically excludes kube-system and AKS internal namespaces. このサービスにより、カスタムのアドミッション コントローラーは、kube-system で実行されているサービスに影響しなくなります。This service ensures the custom admission controllers don't affect the services running in kube-system.

カスタムのアドミッション webhook の対象にする必要のある kube-system (推奨されません) に、何かをデプロイするための重要なユースケースがある場合は、次のラベルまたは注釈を追加して、Admissions Enforcer によってそれが無視されるようにすることができます。If you have a critical use case for having something deployed on kube-system (not recommended) which you require to be covered by your custom admission webhook, you may add the below label or annotation so that Admissions Enforcer ignores it.

ラベル: "admissions.enforcer/disabled": "true" または注釈: "admissions.enforcer/disabled": trueLabel: "admissions.enforcer/disabled": "true" or Annotation: "admissions.enforcer/disabled": true

AKS には Azure Key Vault が統合されているのですか?Is Azure Key Vault integrated with AKS?

AKS は現在、Azure Key Vault とネイティブに統合されていません。AKS isn't currently natively integrated with Azure Key Vault. ただし、CSI シークレット ストア用の Azure Key Vault プロバイダー を使用して、Kubernetes ポッドから Key Vault のシークレットに直接統合することはできます。However, the Azure Key Vault provider for CSI Secrets Store enables direct integration from Kubernetes pods to Key Vault secrets.

AKS で Windows Server コンテナーを実行できますか?Can I run Windows Server containers on AKS?

はい、Windows Server コンテナーは AKS で利用できます。Yes, Windows Server containers are available on AKS. AKS で Windows Server コンテナーを実行するには、Windows Server をゲスト OS として実行するノード プールを作成します。To run Windows Server containers in AKS, you create a node pool that runs Windows Server as the guest OS. Windows Server コンテナーでは、Windows Server 2019 のみを使用できます。Windows Server containers can use only Windows Server 2019. 開始するには、Windows Server ノード プールでの AKS クラスターの作成に関するページを参照してください。To get started, see Create an AKS cluster with a Windows Server node pool.

Windows Server によるノード プールのサポートには、Kubernetes プロジェクトの上流の Windows Server の一部であるいくつかの制限が含まれます。Windows Server support for node pool includes some limitations that are part of the upstream Windows Server in Kubernetes project. これらの制限の詳細については、AKS での Windows Server コンテナーの制限事項に関するページを参照してください。For more information on these limitations, see Windows Server containers in AKS limitations.

AKS でサービス レベル アグリーメントは提供されますか?Does AKS offer a service-level agreement?

AKS では、アップタイム SLA のオプションのアドオン機能として SLA 保証が用意されています。AKS provides SLA guarantees as an optional add on feature with Uptime SLA.

自分の AKS エージェント ノードに Azure の予約割引を適用できますか?Can I apply Azure reservation discounts to my AKS agent nodes?

AKS エージェント ノードは、標準の Azure 仮想マシンとして課金されます。したがって、AKS で使用している VM サイズに対して Azure の予約を購入している場合、それらの割引が自動的に適用されます。AKS agent nodes are billed as standard Azure virtual machines, so if you've purchased Azure reservations for the VM size that you are using in AKS, those discounts are automatically applied.

Azure テナント間でクラスターを移動/移行することはできますか?Can I move/migrate my cluster between Azure tenants?

テナント間での AKS クラスターの移動は現在サポートされていません。Moving your AKS cluster between tenants is currently unsupported.

サブスクリプション間でクラスターを移動/移行することはできますか?Can I move/migrate my cluster between subscriptions?

サブスクリプション間でのクラスターの移動は現在サポートされていません。Movement of clusters between subscriptions is currently unsupported.

AKS クラスターを現在の Azure サブスクリプションから別のサブスクリプションへ移動することはできますか?Can I move my AKS clusters from the current Azure subscription to another?

Azure サブスクリプション間での AKS クラスターおよびそれに関連付けられているリソースの移動はサポートされていません。Moving your AKS cluster and its associated resources between Azure subscriptions is not supported.

AKS クラスターまたは AKS インフラストラクチャ リソースをその他のリソース グループに移動したり、名前を変更したりできますか。Can I move my AKS cluster or AKS infrastructure resources to other resource groups or rename them?

AKS クラスターやその関連リソースを移動したり、名前を変更したりすることはできません。Moving or renaming your AKS cluster and its associated resources is not supported.

クラスターの削除に時間がかかるのはなぜですか?Why is my cluster delete taking so long?

ほとんどのクラスターはユーザーの要求に応じて削除されます。場合によっては、特に顧客が独自のリソース グループを持ち込んでいたり、リソース グループ間のタスクの削除を行っている場合に、さらに時間がかかったり、失敗することがあります。Most clusters are deleted upon user request; in some cases, especially where customers are bringing their own Resource Group, or doing cross-RG tasks deletion can take additional time or fail. 削除に関する問題が発生した場合は、リソース グループをロックしていないこと、リソース グループ外のリソースのリソース グループとの関連付けが解除されていることなどを再確認してください。If you have an issue with deletes, double-check that you do not have locks on the RG, that any resources outside of the RG are disassociated from the RG, etc.

'NodeLost' または 'Unknown' の状態のポッドまたはデプロイがある場合でも、クラスターをアップグレードできますか?If I have pod / deployments in state 'NodeLost' or 'Unknown' can I still upgrade my cluster?

可能ですが、AKS ではお勧めしていません。You can, but AKS does not recommend this. アップグレードは、クラスターの状態がわかっており正常な場合に実行することが理想的です。Upgrades should ideally be performed when the state of the cluster is known and healthy.

異常な状態のノードやシャットダウンしているノードを 1 つ以上含むクラスターがある場合に、アップグレードを実行できますか?If I have a cluster with one or more nodes in an Unhealthy state or shut down, can I perform an upgrade?

できません。エラー状態や、それ以外にクラスターから取り除かれているノードはすべて、アップグレード前に削除/除去してください。No, please delete/remove any nodes in a failed state or otherwise removed from the cluster prior to upgrading.

クラスターの削除を実行しましたが、[Errno 11001] getaddrinfo failed のエラーが表示されますI ran a cluster delete, but see the error [Errno 11001] getaddrinfo failed

最も一般的な原因は、まだ使用中でクラスターに関連付けられている 1 つ以上のネットワーク セキュリティ グループ (NSG) をユーザーが保持していることです。Most commonly, this is caused by users having one or more Network Security Groups (NSGs) still in use and associated with the cluster. これらのグループを取り除いてから、もう一度削除を試してください。Please remove them and attempt the delete again.

アップグレードを実行しましたが、ポッドがクラッシュ ループの状態になりました。準備プローブが失敗していますか?I ran an upgrade, but now my pods are in crash loops, and readiness probes fail?

サービス プリンシパルの有効期限が切れていないことを確認してください。Please confirm your service principal has not expired. 詳細については、AKS サービス プリンシパルAKS の資格情報の更新に関するページを参照してください。Please see: AKS service principal and AKS update credentials.

クラスターは動作していましたが、突然、LoadBalancers のプロビジョニングや PVC のマウントなどができなくなりました。My cluster was working, but suddenly cannot provision LoadBalancers, mount PVCs, etc.?

サービス プリンシパルの有効期限が切れていないことを確認してください。Please confirm your service principal has not expired. 詳細については、AKS サービス プリンシパルAKS の資格情報の更新に関するページを参照してください。Please see: AKS service principal and AKS update credentials.

AKS クラスターを 0 (ゼロ) にスケーリングできますか?Can I scale my AKS cluster to zero?

実行中の AKS クラスターを完全に停止して、それぞれのコンピューティング コストを節約できます。You can completely stop a running AKS cluster, saving on the respective compute costs. さらに、必要なクラスター構成のみを維持しながら、すべてまたは特定の User ノード プールのスケーリングまたは自動スケーリングを 0 (ゼロ) に向けて行うこともできます。Additionally, you may also choose to scale or auto-scale all or specific User node pools to 0, maintaining only the necessary cluster configuration. システム ノード プールを 0 (ゼロ) に直接スケーリングすることはできません。You cannot directly scale system node pools to 0.

仮想マシン スケール セット API を使用して手動でスケーリングできますか?Can I use the virtual machine scale set APIs to scale manually?

いいえ、仮想マシン スケール セット API を使用したスケール操作はサポートされていません。No, scale operations by using the virtual machine scale set APIs aren't supported. AKS API (az aks scale) を使用してください。Use the AKS APIs (az aks scale).

仮想マシン スケール セットを使用して、0 ノードに手動でスケーリングできますか?Can I use virtual machine scale sets to manually scale to 0 nodes?

いいえ、仮想マシン スケール セット API を使用したスケール操作はサポートされていません。No, scale operations by using the virtual machine scale set APIs aren't supported.

すべての VM を停止したり、その割り当てを解除したりできますか?Can I stop or de-allocate all my VMs?

AKS には、このような構成に耐え、そこから復旧するための回復性メカニズムがありますが、これは推奨する構成ではありません。While AKS has resilience mechanisms to withstand such a config and recover from it, this is not a recommended configuration.

カスタム VM 拡張機能を使用できますか?Can I use custom VM extensions?

いいえ。AKS はマネージド サービスであり、IaaS リソースの操作はサポートされていません。No, AKS is a managed service, and manipulation of the IaaS resources is not supported. カスタム コンポーネントなどをインストールするには、To install custom components, etc. Kubernetes の API およびメカニズムを活用してください。please leverage the Kubernetes APIs and mechanisms. たとえば、必要なコンポーネントをインストールするには、DaemonSet を活用します。For example, leverage DaemonSets to install required components.

AKS によって、クラスターのリージョン外に格納される顧客データはありますか?Does AKS store any customer data outside of the cluster's region?

顧客データを 1 つのリージョンに格納できるようにする機能は、現在のところ、アジア太平洋地域の東南アジア リージョン (シンガポール) でのみ使用できます。The feature to enable storing customer data in a single region is currently only available in the Southeast Asia Region (Singapore) of the Asia Pacific Geo. その他のすべてのリージョンでは、顧客データは geo 内に格納されます。For all other regions, customer data is stored in Geo.