よく寄せられる質問 - Azure Arc 対応 Kubernetes と GitOps

  • [アーティクル]

この記事では、Azure Arc 対応 Kubernetes と GitOps についてよく寄せられる質問を記載します。

Azure Arc 対応 Kubernetes と Azure Kubernetes Service (AKS) の違いは何ですか?

AKS は、Azure によるマネージド Kubernetes オファリングです。 AKS は、複雑さと運用上のオーバーヘッドの多くを Azure にオフロードすることで、Azure でのマネージド Kubernetes クラスターのデプロイを簡素化します。 Kubernetes マスターは Azure によって管理されるので、お客様はエージェント ノードの管理と保守のみを行います。

Azure Arc 対応 Kubernetes を使用すると、Kubernetes クラスターを Azure に接続することで、Azure の管理機能 (Azure Monitor や Azure Policy など) を拡張できます。 ユーザーは、基になる Kubernetes クラスター自体を管理します。

Azure で実行されている AKS クラスターを Azure Arc に接続する必要はありますか?

現時点では、ほとんどのシナリオで、Azure Kubernetes Service (AKS) クラスターを Azure Arc に接続する必要はありません。 クラスターを接続して、App Services や Data Services などの特定の Azure Arc 対応サービスをクラスター上で実行できます。 これは、Azure Arc 対応 Kubernetes のカスタムの場所の機能を使って行うことができます。

Azure Stack Edge 上の AKS-HCI クラスターと Kubernetes クラスターを Azure Arc に接続する必要がありますか?

Azure Stack Edge 上の AKS-HCI クラスターまたは Kubernetes クラスターを Azure Arc に接続することで、Azure Resource Manager のリソース表現がクラスターに提供されます。 このリソースの表現により、クラスターの構成、Azure Monitor、Azure Policy (Gatekeeper) などの機能が、接続された Kubernetes クラスターに拡張されます。

Azure Arc 対応 Kubernetes クラスターが Azure Stack Edge、AKS on Azure Stack HCI (2021 年 4 月以降の更新プログラム)、または AKS on Windows Server 2019 Datacenter (2021 年 4 月以降の更新プログラム) 上にある場合、Kubernetes の構成は無料で提供されます。

期限切れの Azure Arc 対応 Kubernetes リソースを処理するにはどうすればよいですか?

Azure Arc 対応の Kubernetes のクラスターに関連付けられているシステム割り当てのマネージド ID は、Azure Arc サービスと通信するために Azure Arc エージェントによってのみ使用されます。 このシステム割り当てのマネージド ID に関連付けられている証明書の有効期限は 90 日間で、エージェントはこの証明書の更新を 46 日目から 90 日目の間で試行します。 マネージド ID 証明書の有効期限が切れないようにするため、クラスターが 46 日目から 90 日目の間に少なくとも 1 回オンラインになるようにします。こうすることで、証明書の更新が行われます。

マネージド ID 証明書の有効期限が切れると、リソースは Expired とみなされ、すべての Azure Arc 機能 (構成、監視、ポリシーなど) がクラスターでの動作を停止します。

任意のクラスターについてマネージド ID 証明書の有効期限が切れるかを確認するには、次のコマンドを実行します。

az connectedk8s show -n <name> -g <resource-group>

この出力では、managedIdentityCertificateExpirationTime の値は、マネージド ID 証明書がいつ期限切れになるか (その証明書の 90 日目のマーク) を示しています。

managedIdentityCertificateExpirationTime の値が過去のタイムスタンプを示している場合、上記の出力における connectivityStatus フィールドは Expired に設定されます。 そのような場合に、Kubernetes クラスターが Azure Arc でもう一度機能するようにするには

  1. クラスター上の Azure Arc 対応 Kubernetes リソースとエージェントを削除します。

    az connectedk8s delete -n <name> -g <resource-group>

  2. クラスターにエージェントをデプロイして、Azure Arc 対応 Kubernetes リソースを再作成します。

    az connectedk8s connect -n <name> -g <resource-group>

Note

az connectedk8s delete では、クラスター上の構成とクラスター拡張も削除されます。 az connectedk8s connect を実行した後に、手動で、または Azure Policy を使用して、クラスター上で構成とクラスター拡張機能を再作成します。

CI/CD パイプラインを既に使用している場合でも、Azure Arc 対応 Kubernetes または AKS と GitOps 構成を使用できますか?

はい。その場合でも CI/CD パイプラインを介してデプロイを受け取るクラスターで構成を使用できます。 従来の CI/CD パイプラインと比較すると、GitOps 構成でいくつかの追加メリットが得られます。

ドリフト調整

CI/CD パイプラインでは、パイプラインの実行中に変更が 1 回だけ適用されます。 ただし、クラスター上の Kubernetes リソースの望ましい状態を取得するために、クラスター上の GitOps オペレーターによって Git リポジトリが継続的にポーリングされます。 GitOps オペレーターによって、リソースの望ましい状態がクラスター上のリソースの実際の状態とは異なることが検出されると、このドリフトが調整されます。

GitOps が全体的に適用される

CI/CD パイプラインは、Kubernetes クラスターへのイベント ドリブン デプロイ (Git リポジトリへのプッシュなど) に役立ちます。 ただし、すべての Kubernetes クラスターに同じ構成をデプロイするには、各 Kubernetes クラスターの資格情報を CI/CD パイプラインに手動で構成する必要があります。

Azure Arc 対応 Kubernetes の場合、Azure Resource Manager によって GitOps 構成が管理されるので、Azure Policy を使用して、サブスクリプションまたはリソース グループのスコープ内のすべての Azure Arc 対応 Kubernetes と AKS リソースで同じ構成の作成を自動化することができます。 この機能は、ポリシーの割り当て後に作成された Azure Arc 対応 Kubernetes と AKS リソースにも適用できます。

この機能は、コンプライアンスとガバナンスの要件を満たすために、Kubernetes クラスターのインベントリ全体でベースライン構成 (ネットワーク ポリシー、ロール バインド、ポッド セキュリティ ポリシーなど) に適用されます。

クラスターのコンプライアンス

各 GitOps 構成のコンプライアンスの状態は、Azure に報告されます。 これにより、失敗したデプロイを追跡できます。

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

現在、顧客データを 1 つのリージョンに格納できるようにする機能は、アジア太平洋地域の東南アジア リージョン (シンガポール) と、ブラジル地域のブラジル南部リージョン (サンパウロ州) でのみ使用できます。 その他のすべてのリージョンでは、顧客データは geo 内に格納されます。 これは、Azure Arc 対応 Kubernetes でサポートされている Azure Arc 対応 Open Service Mesh および Azure Key Vault シークレット プロバイダー拡張機能に適用されます。 その他のクラスター拡張機能で顧客データを格納する方法については、そのドキュメントを参照してください。 詳細については、セキュリティ センターに関するページを参照してください。

次のステップ