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

AKS はアップタイム SLA 機能を備えた Standard 価格レベルで SLA 保証を提供します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

いいえ。仮想マシン スケール セット API を使用したスケール操作はサポートされていません。 AKS API (az aks scale) を使用してください。 AKS は、Virtual Machine Scale Sets、仮想ネットワーク、マネージド ディスクなど、多くの Azure インフラストラクチャ リソースに基づいて構築されています。 これらの統合により、AKS によって提供されるマネージド Kubernetes 環境内で、Azure プラットフォームのコア機能の多くを適用できます。 たとえば、ほとんどの種類の Azure 仮想マシンは 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 によってノード リソース グループに MC_resourcegroupname_clustername_location という名前が設定されますが、独自の名前を指定することもできます。

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

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

ノード リソース グループを使うときは、次のことができないので注意してください。

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

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

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

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

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

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

はい。複数のノード プールを作成することにより、AKS クラスターで異なる仮想マシン サイズを使用できます。

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

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

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

次のイメージは、"ルートとして実行" するための機能要件を持ち、すべてのポリシーに対して例外を登録する必要があります。

• 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

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

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

AKS では、毎週 "ベンダー修正" がある CVE に修正プログラムが適用されます。 修正プログラムがない CVE は、修復できるようになるまで "ベンダーの修正プログラム" を待機しています。 AKS イメージは、30 日以内に自動的に更新されます。 更新されたノード イメージを定期的に適用することで、最新の修正プログラムが適用されたイメージと OS パッチをすべて適用し、最新にすることを推奨します。 これは、次のいずれか方法で実行できます:

• Azure Portal または Azure CLI から手動で行います。
• AKS クラスターをアップグレードします。 クラスターでは、cordon ノードと drain ノードが自動的にアップグレードされてから、最新の Ubuntu イメージと、新しいパッチ バージョンまたは Kubernetes のマイナー バージョンで、新しいノードがオンラインにされます。 詳細については、「AKS クラスターのアップグレード」を参照してください。
• ノード イメージのアップグレードを使用します。

Microsoft では、Microsoft Defender for Containers などのサービスを通じて、ワークロードをセキュリティで保護するために実行できるその他のアクションに関するガイダンスを提供しています。 AKS と Kubernetes に関連するセキュリティ上の脅威で、知っておく必要があるものについては、以下をご覧ください:

• Kubeflow を標的とした新たな大規模キャンペーン (2021 年 6 月 8 日)。

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

従来、ポッドが root 以外のユーザーとして実行されている場合 (ここではそうする必要があります)、ポッドによるボリュームの読み取りと書き込みを可能にするために、ポッドのセキュリティ コンテキスト内で fsGroup を指定する必要があります。 この要件の詳細については、こちらを参照してください。

fsGroup を設定することの副作用の 1 つとして、ボリュームがマウントされるたびに、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 サーバーと個々のノード kubelets が個別の仮想ネットワーク上でも通信できるようにします。 トンネルは mTLS 暗号化によって保護されます。 AKS によって使用される現在のメイン トンネルは Konnectivity (旧称 apiserver-network-proxy) です。 すべてのネットワーク規則が、Azure で必要なネットワーク規則と FQDN に従っていることを確認してください。

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

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

AKS ノードは、localhost から時間をプルする "chrony" サービスを実行します。 ポッドで実行されているコンテナーは、AKS ノードから時刻を取得します。 コンテナー内で起動されたアプリケーションは、ポッドのコンテナーの時刻を使用します。

いいえ。AKS はマネージド サービスであり、IaaS リソースの操作はサポートされていません。 カスタム コンポーネントをインストールするには、Kubernetes API とメカニズムを使用します。 たとえば、必要なコンポーネントをインストールするには、デーモンセットを使用します。

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

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

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

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

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

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

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

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

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

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

現在、FIPS 対応ノードは、Linux ベースのノード プールでサポートされるようになっています。 詳細については、「FIPS 対応ノード プールを追加する」を参照してください。

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

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

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

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

• インフラストラクチャ デーモンの問題: NTP サービス ダウン
• ハードウェアの問題: CPU、メモリ、ディスクの不良
• カーネルの問題: カーネル デッドロック、ファイル システムの破損
• コンテナーのランタイムの問題: 応答しないランタイム デーモン

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

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

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

できます。ただし、お勧めできません。 アップグレードは、クラスターの状態がわかっており、正常である場合に実行する必要があります。

いいえ。エラー状態であるノードや、それ以外の場合はクラスターから取り除かれているノードはすべて、アップグレード前に削除してください。

この問題の最も一般的な原因は、まだ使用中でクラスターに関連付けられている 1 つ以上のネットワーク セキュリティ グループ (NSG) をユーザーが保持していることです。 これらを取り除いてから、もう一度削除を試してください。

サービス プリンシパルの有効期限が切れていないことを確認してください。 「AKS サービス プリンシパル」および「AKS の資格情報の更新」を参照してください。

サービス プリンシパルの有効期限が切れていないことを確認してください。 「AKS サービス プリンシパル」および「AKS の資格情報の更新」を参照してください。