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

[アーティクル]
11/06/2023

この記事では、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 が個別の仮想ネットワーク上でも通信できるようにします。トンネルは mTLS 暗号化によって保護されます。 AKS によって使用される現在のメイントンネルは Konnectivity (旧称 apiserver-network-proxy) です。すべてのネットワーク規則が、Azure で必要なネットワーク規則と FQDN に従っていることを確認してください。

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

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

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

AKS は、Virtual Machine Scale Sets、仮想ネットワーク、マネージドディスクなど、多くの 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 は、ユーザーがクラスターを削除するたびにノードリソースを自動的に削除します。このクラスターは、クラスターのライフサイクルを共有するリソースにのみ使用する必要があります。

Note

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 ポリシーを作成することです。

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

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 には 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 機能を備えた Standard 価格レベルで SLA 保証を提供します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kubernetes の機能とコンポーネント
クラスターまたはノードプールの作成
修正プログラム
バグの修正
セキュリティパッチ
廃止されたコンポーネント

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

AKS は、Kubernetes からのリリースとパッチに依存しています。これは、3 つのマイナーバージョンのスライディングウィンドウのみをサポートするオープンソースプロジェクトです。 AKS は、これらのバージョンがアップストリームでサービスされている場合にのみ、完全なサポートを保証できます。アップストリームで生成されるパッチはこれ以上ないため、AKS はそれらのバージョンをパッチなしのままにするか、フォークすることができます。この制限により、プラットフォームサポートでは、アップストリームの Kubernetes に依存するものをいっさいサポートしません。

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

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

たとえば、Kubernetes v1.25 は、v1.29 GA リリース中に v1.26 にアップグレードされます。中断を最小限に抑えるには、メンテナンス期間を設定します。自動アップグレードチャネルの詳細については、自動アップグレードに関する記事を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

Virtual Machine Scale Set API を使用して手動でスケーリングできますか?

いいえ、Virtual Machine Scale Set API を使用したスケール操作はサポートされていません。 AKS API (az aks scale) を使用してください。

Virtual Machine Scale Sets を使用して、ゼロノードに手動でスケーリングできますか?

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

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

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

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

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

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

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

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 サーバーの更新などの他のネットワーク機能を処理する必要がありました。

Bridge mode topology

次の例は、ブリッジモードでの IP ルートのセットアップを示しています。ノードに含まれるポッドの数に関係なく、ルートは常に 2 つだけになります。 1 つ目のルートは、トラフィック (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 ルーティング規則によってポッドトラフィックがルーティングされます。

Transparent mode topology

次の例は、透過モードの 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" サービスを実行します。ポッドで実行されているコンテナーは、AKS ノードから時刻を取得します。コンテナー内で起動されたアプリケーションは、ポッドのコンテナーの時刻を使用します。

AKS アドオンの更新方法

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

Linux Virtual Machine Scale Sets インスタンスにインストールされている AKS Linux 拡張機能の目的は何ですか?

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

Node-exporter: 仮想マシンからハードウェアテレメトリを収集し、メトリックエンドポイントを使用して使用できるようにします。その後、Prometheus などの監視ツールによってこれらのメトリックをスクレイピングできます。
Node-problem-detector: クラスター管理スタック内のアップストリームレイヤーに対してさまざまなノードの問題を表示することを目的としています。これは、各ノードで実行され、ノードの問題を検出し、Events と NodeConditions を使用してクラスターの API サーバーに報告する systemd ユニットです。
Local-gadget: カーネル内 eBPF ヘルパープログラムを使用して、ポッド内のユーザースペースプログラムからの syscall に関連するイベントを監視します。

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

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

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