次の方法で共有

AKS に関してよく寄せられる質問

この記事では、Azure Kubernetes Service (AKS) について最も頻繁に寄せられる質問にお答えします。

サポート

AKS でサービス レベル アグリーメントは提供されますか?

AKS は、 アップタイム SLA 機能を使用して Standard 価格レベルでサービス レベル アグリーメント (SLA) の保証を提供します。

プラットフォーム サポートとは何ですか、また何が含まれますか?

プラットフォームサポートは、サポートされていない n-3 バージョンのクラスターのサポートプランを減らしたものです。 プラットフォームのサポートには、Azure インフラストラクチャのサポートのみが含まれます。

詳細については、「プラットフォーム サポート ポリシー」をご覧ください。

AKS は、サポートされていないクラスターを自動的にアップグレードしますか?

はい。AKS は、サポートされていないクラスターの自動アップグレードを開始します。 n-3 バージョンのクラスター ( n は一般提供されている最新のサポートされている AKS マイナー バージョン) が n から 4 にドロップされようとしている場合、AKS は自動的にクラスターを n-2 にアップグレードして、AKS サポート ポリシーに残ります。

詳細については、「サポートされている Kubernetes バージョン、「計画メンテナンス期間」、「自動アップグレード」を参照してください。

AKS で Windows Server コンテナーを実行できますか?

はい、AKS では、Windows Server コンテナーがサポートされています。 詳細については、「AKS 上の Windows Server に関する FAQ」を参照してください。

自分の AKS エージェント ノードに Azure の予約割引を適用できますか?

AKS エージェント ノードは、標準の Azure 仮想マシン (VM) として課金されます。 AKS で使用している VM サイズに対して Azure の予約を購入している場合、それらの割引が自動的に適用されます。

操作

Azure テナント間でクラスターを移動または移行することはできますか?

いいえ。 テナント間での AKS クラスターの移動は現在サポートされていません。

サブスクリプション間でクラスターを移動または移行できますか?

いいえ。 サブスクリプション間での AKS クラスターの移動は、現在サポートされていません。

AKS クラスターまたは AKS インフラストラクチャ リソースをその他のリソース グループに移動したり、名前を変更したりできますか。

いいえ。 AKS クラスターやその関連リソースの移動と名前変更はサポートされていません。

クラスターを削除した後に復元できますか?

いいえ。 クラスターを削除した後は復元できません。 クラスターを削除すると、ノード リソース グループとそのすべてのリソースも削除されます。

いずれかのリソースを保持する場合は、クラスターを削除する前に、それらを別のリソース グループに移動します。 誤った削除から保護する場合は、ノード リソース グループのロックダウンを使用して、クラスター リソースをホストしている AKS マネージド リソース グループをロックできます。

AKS クラスターを 0 (ゼロ) にスケーリングできますか?

完全に実行中の AKS クラスターを停止するか、すべてまたは特定の User ノード プールをスケールまたはオートスケールしてゼロにします。

システム ノード プールをゼロに直接スケーリングすることはできません。

仮想マシン スケール セット API を使用して手動でスケーリングすることはできますか?

いいえ。 仮想マシン スケール セット API を使用するスケール操作はサポートされていません。 AKS API (az aks scale) を使用してください。

仮想マシン スケール セットを使用して手動で 0 ノードにスケールすることはできますか?

いいえ。 仮想マシン スケール セット API を使用するスケール操作はサポートされていません。 AKS API を使用して、システム以外のノード プールをゼロにスケーリングしたり、 クラスターを停止 したりできます。

すべての VM を停止または割り当て解除することはできますか?

いいえ。 この構成はサポートされていません。 代わりに、クラスターを停止してください。

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

AKS は、仮想マシン スケール セット、仮想ネットワーク、マネージド ディスクなど、多くの Azure インフラストラクチャ リソースに基づいています。 これらの統合により、AKS によって提供されるマネージド Kubernetes 環境内で、Azure プラットフォームのコア機能の多くを適用できます。 たとえば、ほとんどの Azure VM の種類を AKS で直接使用でき、Azure Reservations を使用してそれらのリソースの割引を自動的に受けることができます。

このアーキテクチャを有効にするため、各 AKS デプロイは、2 つのリソース グループにまたがっています。

  1. 最初のリソース グループを作成します。 このグループには、Kubernetes サービスのリソースのみが含まれます。 AKS リソース プロバイダーにより、デプロイの間に 2 番目のリソース グループが自動的に作成されます。 2 番目のリソース グループの例は、MC_myResourceGroup_myAKSCluster_eastus です。 この 2 つ目のリソース グループの名前を指定する方法については、次のセクションをご覧ください。
  2. ノード リソース グループと呼ばれる 2 つ目のリソース グループには、クラスターに関連付けられたインフラストラクチャ リソースがすべて含まれます。 これらのリソースには、Kubernetes ノードの VM、仮想ネットワー キング、およびストレージが含まれます。 既定では、ノード リソース グループには MC_myResourceGroup_myAKSCluster_eastus のような名前が付いています。 AKS は、ユーザーがクラスターを削除するたびにノード リソースを自動的に削除します。 このリソース グループは、クラスターのライフサイクルを共有するリソースにのみ使用します。

注

AKS クラスター内のノード リソース グループにあるリソースの変更はサポートされていないアクションであり、クラスター操作エラーが発生します。 ノード リソース グループに変更が加えられるのを防ぐことができます。 AKS クラスターが管理するリソースをユーザーが変更できないようにします。

AKS ノード リソース グループに独自の名前を指定できますか?

既定では、AKS によってノード リソース グループに MC_resourcegroupname_clustername_location という名前が設定されますが、独自の名前を指定することもできます。

独自のリソース グループ名を指定するには、aks-preview Azure CLI 拡張機能バージョン 0.3.2 以降をインストールします。 az aks create コマンドを使用して AKS クラスターを作成する場合は、--node-resource-group パラメーターを使用し、リソース グループの名前を指定します。 Azure Resource Manager テンプレートを使用して AKS クラスターをデプロイする場合は、nodeResourceGroup プロパティを使用してリソース グループ名を定義できます。

  • Azure リソース プロバイダーにより、セカンダリ リソース グループが自動的に作成されます。
  • カスタム リソース グループ名は、クラスターの作成時にのみ指定できます。

ノード リソース グループを操作する際に、次の操作を行うことはできません。

  • ノード リソース グループに対して既存のリソース グループを指定すること。
  • ノード リソース グループに対して異なるサブスクリプションを指定すること。
  • クラスターの作成後にノード リソース グループ名を変更します。
  • ノード リソース グループ内の管理対象リソースに名前を指定すること。
  • ノード リソース グループ内の管理対象リソースの Azure で作成されたタグを変更または削除すること。

ノード リソース グループ内の AKS リソースのタグや他のプロパティを変更できますか?

ノード リソース グループ内の Azure で作成されたタグや他のリソース プロパティを変更または削除する場合、予期しないスケーリングやアップグレードのエラーが発生する可能性があります。 AKS を使用すると、エンド ユーザーによって作成されたカスタム タグを作成および変更でき、 ノード プールを作成するときにそれらのタグを追加できます。 たとえばビジネス単位やコスト センターを割り当てるために、カスタム タグを作成または変更することがあります。 もう 1 つのオプションは、マネージド リソース グループのスコープを持つ Azure ポリシーを作成することです。

Azure で作成されたタグは、それぞれの Azure サービス用に作成されるため、常に許可する必要があります。 AKS には、aks-managed および k8s-azure タグがあります。 AKS クラスター内のノード リソース グループにあるリソース上で Azure によって作成されたタグを変更することは、サポートされていないアクションであり、サービス レベル目標 (SLO) が損なわれます。

注

以前は、 Owner タグ名は、ロード バランサーのフロントエンド IP に割り当てられているパブリック IP を管理するために AKS 用に予約されていました。 サービスでは、 aks-managed プレフィックスが使用されるようになりました。 レガシ リソースの場合は、Azure ポリシーを使用して Owner タグ名を適用しないでください。 そうしないと、AKS クラスターのデプロイと更新操作のすべてのリソースが中断されます。 この制限は、新しく作成されたリソースには適用されません。

クラスターに aks で管理されるプレフィックス付き Helm リリースが表示される理由と、そのリビジョン数が増加し続けるのはなぜですか?

AKS では Helm を使用して、クラスターにコンポーネントを配信します。 プレフィックス付き Helm リリース aks-managed 無視しても問題ありません。 これらの Helm リリースのリビジョンは継続的に増加することが予想され、安全です。

クォータ、制限、利用可能なリージョン

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

利用可能なリージョンの完全な一覧については、AKS の利用可能なリージョンに関するページを参照してください。

AKS クラスターを複数のリージョンに広げることはできますか?

いいえ。 AKS クラスターはリージョン リソースであり、複数のリージョンに広げることはできません。 複数のリージョンを含むアーキテクチャを作成する方法のガイダンスについては、 ビジネス継続性とディザスター リカバリーのベスト プラクティスを参照してください。

AKS クラスターを複数の可用性ゾーンに広げることはできますか?

はい。Availability Zones をサポートしているリージョン内の 1 つ以上の Availability Zones に AKS クラスターをデプロイできます。

1 つのクラスター内で、異なる VM サイズを設定できますか?

はい。 複数のノード プールを作成することで、AKS クラスターで異なる VM サイズを使用できます。

AKS のコンテナー イメージのサイズ制限はいくつですか?

AKS では、コンテナー イメージのサイズに制限は設定されません。 ただし、イメージが大きいほど、メモリの需要は高くなります。 サイズが大きいため、リソースの制限またはワーカー ノードで使用可能なメモリ全体を超過する可能性があります。 既定では、AKS クラスターの VM サイズ Standard_DS2_v2 のメモリは 7 GiB に設定されます。

テラバイト (TB) の範囲のようにコンテナー イメージが過度に大きい場合、ディスク領域がないため、kubelet がコンテナー レジストリからノードにプルできない可能性があります。

Windows Server ノードの場合、Windows Update によって最新の更新プログラムが実行されて適用されるわけではありません。 AKS クラスター内のクラスターと Windows Server ノード プールでアップグレードを実行する必要があります。 Windows Update のリリース サイクルと独自の検証プロセスに基づいて、定期的なスケジュールに従います。 このアップグレード プロセスでは、最新の Windows Server イメージとパッチを実行するノードが作成され、古いノードが削除されます。 このプロセスの詳細については、AKS でのノード プールのアップグレードに関するページを参照してください。

AKS イメージはルートとして実行する必要がありますか?

次のイメージには、root として実行するための機能要件があり、すべてのポリシーに対して例外を提出する必要があります。

  • mcr.microsoft.com/oss/kubernetes/coredns
  • mcr.microsoft.com/azuremonitor/containerinsights/ciprod
  • mcr.microsoft.com/oss/calico/node
  • mcr.microsoft.com/oss/kubernetes-csi/azuredisk-csi

セキュリティ、アクセス、ID

Kubernetes API サーバーにアクセスできるユーザーを制限できますか?

はい。API サーバーへのアクセスを制限するためのオプションは 2 つあります。

  • API サーバーのパブリック エンドポイントを維持し、一連の信頼できる IP 範囲へのアクセスを制限する場合は、API サーバーの 承認された IP 範囲を使用します。
  • 仮想ネットワーク内からのみアクセスできるように API サーバーを制限する場合は、プライベート クラスターを使用します。

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

AKS は、ベンダーが毎週修正する CVE に パッチを適用 します。 修正のない CVE は、修復する前にベンダーの修正を待機しています。 AKS イメージは、30 日以内に自動的に更新されます。 更新されたノード イメージを定期的に適用して、パッチが適用された最新のイメージと OS パッチがすべて適用され、最新であることを確認することをお勧めします。 次のタスクを実行できます。

注意する必要がある AKS を対象とするセキュリティ上の脅威はありますか?

Microsoft では、 Microsoft Defender for Containers などのサービスを通じてワークロードをセキュリティで保護するために実行できるその他のアクションに関するガイダンスを提供しています。 AKS と Kubernetes に関連するセキュリティ上の脅威については、「 新しい大規模キャンペーンターゲット Kubeflow (2021 年 6 月 8 日)」を参照してください。

AKS はクラスターのリージョン外に顧客データを格納しますか?

いいえ。 すべてのデータは、クラスターのリージョンに格納されます。

ボリュームに大量のファイルがある場合に、アクセス許可の所有権の設定が遅くなる問題を回避する方法を教えてください。

従来、ポッドが非ルート ユーザー (そうする必要があります) として実行されている場合は、ポッドのセキュリティ コンテキスト内で fsGroup パラメーターを指定して、ボリュームがポッドによって読み取りおよび書き込み可能になるようにする必要があります。 この要件の詳細については、「 ポッドまたはコンテナーのセキュリティ コンテキストを構成する」を参照してください。

fsGroupを設定すると、ボリュームがマウントされるたびに、Kubernetes はボリューム内のすべてのファイルとディレクトリに対してchown()コマンドとchmod() コマンドを再帰的に使用する必要があります (いくつかの例外があります)。 このシナリオは、ボリュームのグループ所有権が、要求された fsGroup パラメーターと既に一致している場合でも発生します。 この構成は、多数の小さなファイルを含む大規模なボリュームではコストがかかる可能性があり、ポッドの起動に時間がかかる可能性があります。 このシナリオは、v1.20 より前の既知の問題でした。 回避策は、ポッドを root として実行するように設定することです。

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    fsGroup: 0

この問題は、Kubernetes バージョン 1.20 で解決されました。 詳細については、「 Kubernetes 1.20: ボリュームのアクセス許可の変更をきめ細かく制御する」を参照してください。

ネットワーク

マネージド コントロール プレーンはノードとどのように通信しますか?

AKS では、セキュリティで保護されたトンネル通信を使用して、 api-server と個々のノード の kubelets が個別の仮想ネットワーク上でも通信できるようにします。 トンネルは、相互トランスポート層セキュリティ暗号化によって保護されます。 AKS で使用されている現在のメイン トンネルは Konnectivity であり、以前は apiserver-network-proxy と呼ばれています。 すべてのネットワーク 規則が 、Azure で必要なネットワーク規則と完全修飾ドメイン名 (FQDN) に従っていることを確認します。

ポッドでは、クラスター IP の代わりに API サーバー FQDN を使用できますか?

はい。ポッドに注釈 kubernetes.azure.com/set-kube-service-host-fqdn を追加して、KUBERNETES_SERVICE_HOST 変数をクラスター内サービス IP ではなく API サーバーのドメイン名に設定できます。 この変更は、クラスターエグレスがレイヤー 7 ファイアウォール経由で行われる場合に役立ちます。 たとえば、アプリケーションルールで Azure Firewall を使用する場合です。

AKS で NSG を構成できますか?

AKS は、そのサブネットにネットワーク セキュリティ グループ (NSG) を適用せず、そのサブネットに関連付けられている NSG を変更しません。 AKS は、ネットワーク インターフェイスの NSG 設定のみを変更します。 コンテナー ネットワーク インターフェイス (CNI) を使用している場合は、NSG のセキュリティ規則で、ノードとポッドのクラスレスドメイン間ルーティング (CIDR) 範囲間のトラフィックが許可されるようにする必要もあります。 kubenet を使用している場合は、NSG のセキュリティ規則でノードとポッド CIDR の間のトラフィックが許可されていることを確認する必要もあります。 詳細については、「ネットワーク セキュリティ グループ」を参照してください。

AKS での時刻同期のしくみ

AKS ノードは、ローカル ホストから時間をプルする chrony サービスを実行します。 ポッドで実行されるコンテナーは、AKS ノードから時刻を取得します。 コンテナー内で開くアプリケーションは、ポッドのコンテナーからの時間を使用します。

アドオン、拡張機能、統合

カスタム VM 拡張機能を使用できますか?

いいえ。 AKS はマネージド サービスです。 サービスとしてのインフラストラクチャ (IaaS) リソースの操作はサポートされていません。 カスタム コンポーネントをインストールするには、Kubernetes API とメカニズムを使用します。 たとえば、DaemonSets を使用して、必要なコンポーネントをインストールします。

AKS ではどのような Kubernetes アドミッション コントローラーがサポートされますか? アドミッション コントローラーの追加や削除はできますか?

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

  • NamespaceLifecycle
  • LimitRanger
  • ServiceAccount
  • DefaultIngressClass
  • DefaultStorageClass
  • DefaultTolerationSeconds
  • MutatingAdmissionWebhook
  • ValidatingAdmissionWebhook
  • ResourceQuota
  • PodNodeSelector
  • PodTolerationRestriction
  • ExtendedResourceToleration

現在は、AKS でアドミッション コントローラーの一覧を変更することはできません。

AKS でアドミッション コントローラー Webhook を使用できますか?

はい、AKS でアドミッション コントローラー Webhook を使用できます。 control-plane ラベルでマークされている内部 AKS 名前空間は除外することをお勧めします。 次に例を示します。

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

AKS は API サーバーエグレスをファイアウォールして、アドミッション コントローラーの Webhook にクラスター内からアクセスできるようにする必要があります。

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

システムの安定性を保護し、カスタム アドミッション コントローラーが kube-system 名前空間内の内部サービスに影響を与えないようにするために、AKS には、 kube-system および AKS 内部名前空間を自動的に除外するアドミッションエンフォーサがあります。 このサービスにより、カスタム アドミッション コントローラーが、 kube-systemで実行されるサービスに影響を与えないようにします。

カスタム アドミッション Webhook をサポートする kube-system (推奨されません) に何かをデプロイするための重要なユース ケースがある場合は、次のラベルまたは注釈を追加して、アドミッションの適用者が無視するようにすることができます。

  • ラベル: "admissions.enforcer/disabled": "true"
  • 注釈： "admissions.enforcer/disabled": true

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

シークレット ストア CSI ドライバー用の Azure Key Vault プロバイダー は、AKS への Azure Key Vault のネイティブ統合を提供します。

AKS へのデプロイで FIPS 暗号化ライブラリを使用できますか?

Federal Information Processing Standards (FIPS) で有効になっているノードが、Linux ベースのノード プールでサポートされるようになりました。 詳細については、「FIPS 対応ノード プールを追加する」を参照してください。

AKS アドオンはどのように更新されますか?

セキュリティ パッチを含むすべてのパッチは、AKS クラスターに自動的に適用されます。 メジャー バージョンやマイナー バージョンの変更 (デプロイされたオブジェクトに重大な変更が加わる可能性がある) など、パッチよりも大きいものは、新しいリリースが利用可能な場合にクラスターを更新すると更新されます。 新しいリリースが利用可能なタイミングについては、 AKS リリース ノートを参照してください。

Linux 仮想マシン スケール セット インスタンスにインストールされている AKS Linux 拡張機能の目的は何ですか?

AKS Linux 拡張機能は、Kubernetes ワーカー ノードに監視ツールをインストールして構成する Azure VM 拡張機能です。 拡張機能は、新規と既存の Linux ノードにすべてインストールされます。 次の監視ツールが構成されます。

  • ノード エクスポーター: VM からハードウェア テレメトリを収集し、メトリック エンドポイントを使用して利用できるようにします。 その後、Prometheus などの監視ツールで、これらのメトリックを破棄できます。
  • Node-problem-detector: クラスター管理スタック内のアップストリーム レイヤーに対してさまざまなノードの問題を表示することを目的としています。 これは、各ノードで実行され、ノードの問題を検出し、 Events と NodeConditionsを使用してクラスターの API サーバーに報告する systemd ユニットです。
  • ig: Linux および Kubernetes システムをデバッグおよび監視するための eBPF を利用したオープン ソース フレームワークです。 これは、パフォーマンスの問題、クラッシュ、またはその他の異常の原因を特定するためにユーザーが使用できる関連情報を収集する一連のツール (またはガジェット) を提供します。 特に、Kubernetes から独立しているので、ユーザーはコントロール プレーンの問題のデバッグにもそれを使用できます。

これらのツールは、次のような多くのノードの正常性関連の問題を監視するのに役立ちます。

  • インフラストラクチャ デーモンの問題: NTP サービスの停止
  • ハードウェアの問題: CPU、メモリ、またはディスクが正しくありません
  • カーネルの問題: カーネルのデッドロック、ファイル システムの破損
  • コンテナー ランタイムの問題: 応答しないランタイム デーモン

この拡張機能では、文書化されている AKS エグレス要件を超える URL、IP アドレス、またはポートへの追加の送信アクセスは必要ありません。 Azure で付与される特別なアクセス許可は必要ありません。 kubeconfigを使用して API サーバーに接続し、収集された監視データを送信します。

クラスターの問題のトラブルシューティング

クラスターの削除に時間がかかるのはなぜですか?

ほとんどのクラスターはユーザーの要求に応じて削除されます。 場合によっては、特に独自のリソース グループを持ち込んだり、リソース グループ間のタスクを実行したりする場合、削除に時間がかかる場合や失敗する場合があります。 削除に問題がある場合は、リソース グループにロックがないことを再確認してください。 また、リソース グループ外のすべてのリソースがリソース グループとの関連付けを解除していることを確認します。

クラスターの作成または更新に時間がかかるのはなぜですか?

クラスターの作成と更新に問題がある場合は、AKS クラスターが VM、ロード バランサー、タグなどのリソースを管理できないようにする可能性のあるポリシーまたはサービス制約が割り当てされていないことを確認してください。

NodeLost または不明な状態にポッドまたはデプロイがある場合、クラスターをアップグレードすることはできますか?

できます。ただし、お勧めできません。 クラスターの状態が既知で正常な場合は、更新を実行します。

1 つ以上のノードが異常な状態のクラスターがある場合、またはシャットダウンされている場合は、アップグレードを実行できますか?

いいえ。 アップグレードする前に、障害が発生した状態のノードを削除するか、クラスターから削除します。

クラスターを削除しようとしましたが、"[Errno 11001] getaddrinfo が失敗しました" というエラーが表示されます。

最も一般的に、このエラーは、クラスターにまだ関連付けられている 1 つ以上の NSG が使用中の場合に発生します。 それらを削除し、もう一度クラスターの削除を試みます。

アップグレードを実行しましたが、ポッドがクラッシュ ループに入り、準備プローブが失敗しました。

サービス プリンシパルの有効期限が切れていないことを確認します。 詳細については、 AKS サービス プリンシパル と AKS 更新資格情報に関する記事を参照してください。

クラスターは動作していましたが、突然、ロード バランサーをプロビジョニングしたり、永続ボリューム要求をマウントしたりできません。

サービス プリンシパルの有効期限が切れていないことを確認します。 詳細については、 AKS サービス プリンシパル と AKS 更新資格情報に関する記事を参照してください。