AKSクラスター構成リファレンス

サブスクリプションIDを取得するには、左側のナビゲーションバーで*すべてのサービス*をクリックします。次に、*サブスクリプション*をクリックします。Kubernetesクラスターに関連付けたいサブスクリプションの名前に移動し、*サブスクリプションID*をコピーします。

クライアントIDを取得するには、Azureポータルに移動し、次に*Azure Active Directory*をクリックし、次に*アプリ登録*をクリックし、サービスプリンシパルの名前をクリックします。クライアントIDは、アプリ登録の詳細ページに*アプリケーション（クライアント）ID*として表示されます。

クライアントシークレット値は作成後に取得できないため、クライアントシークレット値をまだ持っていない場合は、新しいクライアントシークレットを作成する必要があります。

新しいクライアントシークレットを取得するには、Azureポータルに移動し、次に*Azure Active Directory*をクリックし、次に*アプリ登録*をクリックし、サービスプリンシパルの名前をクリックします。

次に、証明書とシークレット*をクリックし、*新しいクライアントシークレット*をクリックします。[追加]* をクリックします。次に、新しいクライアントシークレットの*値*をコピーします。

Microsoftは、地域の法律に準拠するために複数の クラウドを提供しており、利用可能です：

利用可能なKubernetesのバージョンは、Azure APIから動的に取得されます。

リソースグループは、Azureソリューションに関連するリソースを保持するコンテナです。リソースグループには、ソリューションのすべてのリソースを含めるか、またはグループとして管理するリソースのみを含めることができます。組織にとって最も理にかなった方法に基づいて、リソースをリソースグループに割り当てる方法を決定します。一般的に、同じライフサイクルを共有するリソースを同じリソースグループに追加することで、グループとして簡単にデプロイ、更新、削除できます。

既存のリソースグループを使用するか、リソースグループ名を入力すると、新しいリソースグループが作成されます。

既存のAKSクラスターを含むリソースグループを使用すると、新しいリソースグループが作成されます。Azure AKSは、リソースグループごとに1つのAKSクラスターのみを許可します。

リソースグループの管理に関する情報は、 Azureドキュメントをご覧ください。

LinuxノードへのSSH接続を作成するために使用されるユーザー名です。

AKSノードのデフォルトユーザー名は`azureuser`です。

LinuxノードへのSSH接続を作成するために使用される鍵です。

クラスタータグは、組織が複数のAzureサービスにわたってリソースを整理する方法としてタグを使用する場合に便利です。これらのタグは、クラスター内のリソースには適用されません。

Azureのロードバランサーは、標準SKUと基本SKUの両方をサポートしています。

標準と基本のロードバランサーの比較については、公式の Azureドキュメントを参照してください。Microsoftは標準ロードバランサーを推奨しています。

1つ以上の可用性ゾーンを選択した場合、またはノードプールが1つ以上ある場合、標準ロードバランサーが必要です。

AKSクラスター内のすべてのポッドは、デフォルトで制限なくトラフィックを送受信できます。セキュリティを向上させるために、トラフィックの流れを制御するルールを定義できます。Kubernetesのネットワークポリシー機能を使用すると、クラスター内のポッド間のインバウンドおよびアウトバウンドトラフィックに対するルールを定義できます。

Azureは、ネットワークポリシーを実装する2つの方法を提供しています。AKSクラスターを作成する際に、ネットワークポリシーオプションを選択します。クラスターが作成された後は、ポリシーオプションを変更することはできません。

ネットワークポリシーを持たないことを選択することもできます。

AzureとCalicoネットワークポリシーの違いやその機能についての詳細は、 AKS のドキュメントを参照してください。

クラスターのKubernetes APIサーバーのFQDN用に一意のDNSプレフィックスを入力してください。

ネットワークプラグインは2つあります：kubenetとAzure CNI。

kubenet Kubernetes プラグインは、AKSクラスター作成のデフォルト設定です。kubenetが使用されると、クラスター内の各ノードはルーティング可能なIPアドレスを受け取ります。ポッドは、AKSクラスターの外部にある他のリソースと通信するためにNATを使用します。このアプローチにより、ポッドが使用するためにネットワークスペースで予約する必要のあるIPアドレスの数が減少します。

Azure CNI（高度な）ネットワーキングプラグインを使用すると、ポッドは完全な仮想ネットワーク接続を得て、接続されたネットワークからプライベートIPアドレスで直接アクセスできます。このプラグインは、より多くのIPアドレススペースを必要とします。

kubenetとAzure CNIの違いについての詳細は、 AKSドキュメントを参照してください。

有効にすると、HTTPアプリケーションルーティング アドオンは、AKSクラスターにデプロイされたアプリケーションへのアクセスを容易にします。2つのコンポーネントをデプロイします： Kubernetes Ingress コントローラーと External-DNS コントローラー。

詳細については、 AKSドキュメントを参照してください。

承認されたIPアドレス範囲を使用して、Kubernetes APIサーバーへのアクセスを保護できます。

Kubernetes APIサーバーは、Kubernetes APIを公開します。このコンポーネントは、kubectlなどの管理ツールとのインタラクションを提供します。AKSは、専用のAPIサーバーを持つシングルテナントクラスター制御プレーンを提供します。デフォルトでは、APIサーバーにはパブリックIPアドレスが割り当てられ、KubernetesベースまたはAzureベースのRBACを使用してアクセスを制御する必要があります。

それ以外は公開アクセス可能なAKS制御プレーンとAPIサーバーへのアクセスを保護するために、承認されたIP範囲を有効にして使用できます。これらの承認されたIP範囲は、定義されたIPアドレス範囲のみがAPIサーバーと通信することを許可します。

ただし、認可されたIPアドレス範囲を使用しても、ユーザーと要求されたアクションを認可するためにKubernetes RBACまたはAzure RBACを使用する必要があります。

コンテナ監視は、KubernetesのMetrics APIを通じて、コントローラー、ノード、およびコンテナからメモリとプロセッサのメトリックを収集することにより、パフォーマンスの可視性を提供します。コンテナログも収集されます。監視を有効にすると、メトリックとログはLinux用のLog Analyticsエージェントのコンテナ化バージョンを通じて自動的に収集されます。メトリックはメトリックストアに書き込まれ、ログデータはあなたの Log Analyticsワークスペースに関連付けられたログストアに書き込まれます。

Log Analyticsワークスペースを含む リソースグループ。Azure Monitor Logsを使用するには、少なくとも1つのワークスペースを作成する必要があります。

Azure Monitor Logsによって収集されたデータは、1つ以上の Log Analyticsワークスペースに保存されます。ワークスペースはデータの地理的位置、どのユーザーがデータにアクセスできるかを定義するアクセス権、および価格帯やデータ保持などの設定を定義します。

Azure Monitor Logsを使用するには、少なくとも1つのワークスペースを作成する必要があります。単一のワークスペースは、すべての監視データに対して十分である場合もあれば、要件に応じて複数のワークスペースを作成することを選択する場合もあります。例えば、プロダクションデータ用のワークスペースとテスト用の別のワークスペースを持つことができます。

Azure Monitor Logsに関する詳細は、 Azureのドキュメントを参照してください。

通常、AKSワーカーノードは、クラスターがプライベートであるかどうかにかかわらず、パブリックIPを取得しません。プライベートクラスターでは、コントロールプレーンにパブリックエンドポイントはありません。

Rancherは、プライベートAKSクラスターに2つの方法のいずれかで接続できます。

RancherがAKSノードと同じ NAT上で実行されていることを確認する最初の方法です。

2番目の方法は、クラスターをRancherに登録するためのコマンドを実行することです。クラスターがプロビジョニングされると、クラスターのKubernetes APIに接続できる場所で表示されたコマンドを実行できます。このコマンドは、プライベートAPIエンドポイントが有効なAKSクラスターをプロビジョニングする際にポップアップで表示されます。

AKSプライベートクラスターへの接続に関する詳細は、 AKS ドキュメントをご覧ください。

Azureインターフェースでは、プライマリノードプールが`system`（通常はコントロールプレーン用）または`user`（Rancherで最も一般的に必要とされるもの）に依存するかどうかを指定できます。

プライマリノードプールでは、モード、OS、数、サイズを指定できます。

システムノードプールは常に稼働中のノードを必要とするため、1ノード未満にスケールダウンすることはできません。少なくとも1つのシステムノードプールが必要です。

その後のノードプールでは、Rancher UIによってデフォルトが「ユーザー」に設定されます。ユーザーノードプールは、ノード数をゼロまでスケールできます。ユーザーノードプールは、Kubernetesコントロールプレーンの一部を実行しません。

AKSは、Kubernetesコントロールプレーンコンポーネントを実行するノードを公開しません。

アベイラビリティゾーンは、地域内の一意の物理的な場所です。各ゾーンは、独立した電源、冷却、ネットワーキングを備えた1つ以上のデータセンターで構成されています。

すべての地域がアベイラビリティゾーンをサポートしているわけではありません。アベイラビリティゾーンを持つAzure地域のリストについては、 Azureのドキュメントをご覧ください。

ノードプール内の各VMのサイズを選択してください。各VMサイズの詳細については、 このページをご覧ください。

ノードプール内のノードは、管理ディスクまたは一時ディスクのいずれかを使用できます。

一時的なOSディスクは、ローカルの仮想マシンストレージに作成され、リモートのAzureストレージには保存されません。一時的なOSディスクは、アプリケーションが個々のVMの障害に耐性があるステートレスなワークロードに適しており、VMの展開時間や個々のVMインスタンスの再イメージにより影響を受けやすくなります。一時的なOSディスクを使用すると、OSディスクへの読み取り/書き込みのレイテンシが低く、VMの再イメージが速くなります。

Azure管理ディスクは、Azureによって管理され、Azure仮想マシンで使用されるブロックレベルのストレージボリュームです。管理ディスクは、99.999%の可用性を目指して設計されています。管理ディスクは、データの3つのレプリカを提供することでこれを実現し、高い耐久性を確保します。

各ノードのディスクのサイズ（GB単位）。

ノードプール内のノードの数。最大ノード数は、 Azureサブスクリプションによって制限される場合があります。

ノードあたりの最大ポッド数はデフォルトで110で、最大250です。

自動スケーリングが有効になっている場合、最小および最大のノード数を入力する必要があります。

自動スケーリングが有効になっている場合、ノードプールを手動でスケールすることはできません。スケールはAKSオートスケーラーによって制御されます。