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

[アーティクル]
10/05/2022

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Windows Server ノード

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

顧客が知っておく必要がある、AKS をターゲットとしたセキュリティ上の脅威はありますか?

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

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

マネージドコントロールプレーンとノードの通信方法

AKS では、セキュリティで保護されたトンネル通信を使用して、API サーバーと個々のノード kubelets が個別の仮想ネットワーク上でも通信できるようにします。トンネルは TLS 暗号化によって保護されます。 AKS によって使用される現在のメイントンネルは Konnectivity (旧称 apiserver-network-proxy) です。すべてのネットワーク規則が、Azure で必要なネットワーク規則と FQDN に従っていることを確認してください。

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

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

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

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

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

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

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

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

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

ノードリソースグループに対して既存のリソースグループを指定すること。
ノードリソースグループに対して異なるサブスクリプションを指定すること。
クラスターが作成された後で、ノードリソースグループ名を変更すること。
ノードリソースグループ内の管理対象リソースに名前を指定すること。
ノードリソースグループ内の管理対象リソースの Azure で作成されたタグを変更または削除すること。 (詳しくは、次のセクションで追加の情報を参照してください。)

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

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

ただし、AKS クラスター内のノードリソースグループにあるリソース上で Azure によって作成されたタグを変更することは、サポートされていないアクションであり、サービスレベル目標 (SLO) が損なわれます。詳細については、「AKS でサービスレベルアグリーメントは提供されますか?」を参照してください。

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

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

NamespaceLifecycle
LimitRanger
ServiceAccount
DefaultStorageClass
DefaultTolerationSeconds
MutatingAdmissionWebhook
ValidatingAdmissionWebhook
ResourceQuota
PodNodeSelector
PodTolerationRestriction
ExtendedResourceToleration

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

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

はい、AKS でアドミッションコントローラー Webhook を使用できます。 コントロールプレーンラベルでマークされている内部 AKS 名前空間を除外することをお勧めします。たとえば、以下を Webhook 構成に追加します。

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

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

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

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

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

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

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

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

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

はい、Windows Server コンテナーは AKS で利用できます。 AKS で Windows Server コンテナーを実行するには、Windows Server をゲスト OS として実行するノードプールを作成します。 Windows Server コンテナーでは、Windows Server 2019 のみを使用できます。開始するには、Windows Server ノードプールでの AKS クラスターの作成に関するページを参照してください。

Windows Server によるノードプールのサポートには、Kubernetes プロジェクトの上流の Windows Server の一部であるいくつかの制限が含まれます。これらの制限の詳細については、AKS での Windows Server コンテナーの制限事項に関するページを参照してください。

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

AKS では、オプション機能としてアップタイム SLA で SLA が保証されます。

既定で提供される Free SKU にはサービスレベル "アグリーメント" は関連付けられていませんが、サービスレベル "目標" は 99.5% です。アップグレード、異常なアンダーレイノード、プラットフォームのメンテナンス、アプリケーションによる API サーバーへの過剰な要求などで、一時的な接続の問題が見られる場合があります。ワークロードで API サーバーの再起動を許容できない場合は、アップタイム SLA を使用することをお勧めします。

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

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

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

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

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

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

AKS クラスターを現在の Azure サブスクリプションから別のサブスクリプションへ移動することはできますか?

Azure サブスクリプション間での AKS クラスターおよびその関連リソースの移動はサポートされていません。

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

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

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

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

'NodeLost' または 'Unknown' の状態のポッドまたはデプロイがある場合でも、クラスターをアップグレードできますか?

可能ですが、AKS ではこれをお勧めしていません。アップグレードは、クラスターの状態がわかっており正常な場合に実行する必要があります。

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

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

クラスターの削除を実行しましたが、`[Errno 11001] getaddrinfo failed` のエラーが表示されます

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

アップグレードを実行しましたが、ポッドがクラッシュループの状態になりました。準備プローブが失敗していますか?

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

クラスターは動作していましたが、突然、LoadBalancers のプロビジョニングや PVC のマウントなどができなくなりました。

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

実行中の AKS クラスターを完全に停止して、それぞれのコンピューティングコストを節約できます。さらに、必要なクラスター構成のみを維持しながら、すべてまたは特定のノードプールを 0 にスケーリングまたは自動スケーリングすることもできます。システムノードプールをゼロに直接スケーリングすることはできません。

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

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

仮想マシンスケールセットを使用して、ゼロノードに手動でスケーリングできますか?

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

すべての VM を停止したり、その割り当てを解除したりできますか?

AKS には、このような構成に耐え、そこから復旧するための回復性メカニズムがありますが、これはサポートされている構成ではありません。代わりに、クラスターを停止してください。

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

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

AKS によって、クラスターのリージョン外に格納される顧客データはありますか?

現在、顧客データを 1 つのリージョンに格納できるようにする機能は、アジア太平洋地域の東南アジアリージョン (シンガポール) と、ブラジル地域のブラジル南部リージョン (サンパウロ州) でのみ使用できます。その他のすべてのリージョンでは、顧客データは geo 内に格納されます。

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

Azure CNI の透過モードとブリッジモードとは

バージョン 1.2.0 以降、Azure CNI では、シングルテナント Linux CNI デプロイには既定値として透過モードが設定されます。透過モードは、ブリッジモードに代わるものです。このセクションでは、両方のモードの違いと、Azure CNI で透過モードを使用する場合の利点と制限事項について説明します。

ブリッジモード

その名前が示すように、ブリッジモードの Azure CNI は "Just In Time" 方式で、"azure0" という名前の L2 ブリッジを作成します。ホスト側ポッド veth ペアインターフェイスはすべて、このブリッジに接続されます。そのため、ポッド間 VM 内通信とその残りのトラフィックは、このブリッジを通過します。対象となるブリッジはレイヤー 2 仮想デバイスです。これは、1 つ以上の実際のデバイスをそれにバインドしない限り、それ自体では何も受信したり、送信したりできません。このため、Linux VM の eth0 を "azure0" ブリッジの配下に変換する必要があります。これにより、Linux VM 内に複雑なネットワークトポロジが作成され、その結果として、CNI で DNS サーバーの更新などの他のネットワーク機能を処理する必要がありました。

ブリッジモードのトポロジ

下に、ブリッジモードでの IP ルートセットアップの例を示します。ノードに含まれるポッドの数に関係なく、ルートは常に 2 つだけになります。最初のものは、azure0 上のローカルを除くすべてのトラフィックが、IP "src 10.240.0.4" (これはノードのプライマリ IP です) を持つインターフェイスを介してサブネットの既定のゲートウェイに送られることを示し、2 番目のものは、カーネルが決定する、カーネルに対する "10.20.x.x" ポッドスペースを示しています。

default via 10.240.0.1 dev azure0 proto dhcp src 10.240.0.4 metric 100
10.240.0.0/12 dev azure0 proto kernel scope link src 10.240.0.4
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
root@k8s-agentpool1-20465682-1:/#

透過モード

透過モードでは、Linux ネットワークを設定するために簡単な方法が採られます。このモードでは、Linux VM の eth0 インターフェイスのプロパティは Azure CNI によって変更されません。 Linux ネットワークのプロパティを変更するこの最小限の方法は、クラスターがブリッジモードで直面する可能性のある複雑でやっかいなケースの問題を軽減するのに役立ちます。透過モードでは、Azure CNI によって、ホストネットワークに追加されるホスト側ポッド veth ペアインターフェイスが作成および追加されます。 VM 内ポッド間通信は、CNI によって追加される IP ルート経由で行われます。基本的には、ポッド間通信はレイヤー 3 を経由し、ポッドトラフィックは L3 ルーティング規則によってルーティングされます。

透過モードのトポロジ

下に、透過モードの IP ルートセットアップの例を示します。ポッドとして接続先 IP を持つトラフィックがポッドのホスト側の veth ペアインターフェイスに直接送信されるように、各ポッドのインターフェイスでは静的ルートが接続されます。

10.240.0.216 dev azv79d05038592 proto static
10.240.0.218 dev azv8184320e2bf proto static
10.240.0.219 dev azvc0339d223b9 proto static
10.240.0.222 dev azv722a6b28449 proto static
10.240.0.223 dev azve7f326f1507 proto static
10.240.0.224 dev azvb3bfccdd75a proto static
168.63.129.16 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
169.254.169.254 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

透過モードの利点

ノードローカル DNS を設定することなく、conntrack DNS 並列競合状態の軽減策と、5 秒間の DNS 待機時間の問題の回避策を提供します (パフォーマンス上の理由から、ノードローカル DNS を使用することもできます)。
"Just In Time" ブリッジのセットアップによって、CNI ブリッジモードで現在発生する 5 秒間の初期 DNS 待機時間が無くなります。
ブリッジモードでのやっかいなケースの 1 つは、ユーザーが VNET または NIC に追加するカスタム DNS サーバーの一覧を Azure CNI で更新し続けることができないことです。この結果、CNI は DNS サーバーの一覧の最初のインスタンスのみを取得します。透過モードでは解決されました。どの eth0 プロパティも CNI で変更されないためです。詳細については、こちらを参照してください。
ARP がタイムアウトになったときに、UDP トラフィックをより適切に処理し、UDP フラッドストームの軽減策を提供します。ブリッジモードでは、ブリッジが VM 内ポッド間通信で送信先ポッドの MAC アドレスを認識しない場合、設計上、すべてのポートに大量のパケットが送信されます。透過モードでは解決されました。パスに L2 デバイスがないためです。詳細については、こちらを参照してください。
透過モードは、ブリッジモードと比較した場合、スループットと待機時間の観点から VM 内ポッド間通信においてより優れたパフォーマンスを提供します。

ボリュームに大量のファイルがある場合に、権限の所有権の設定による低速化の問題を回避するには、どのようにしますか?

従来、ポッドが 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 へのデプロイで FIPS 暗号化ライブラリを使用できますか?

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

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

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

AKS での時刻はどのようになっていますか?

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