Azure Kubernetes ServiceのKubernetes resources in environmentsを解説｜Azure Pipelinesの変更点と確認ポイント

Azure Kubernetes Service（AKS）へのデプロイで「どのパイプラインが、どの名前空間に、どの変更を反映したのか」を追跡しづらい場合は、Azure Pipelines の Kubernetes resources in environments を確認すべきです。これは AKS クラスターそのものの仕様変更というより、Azure Pipelines の「環境」をデプロイ先として管理し、Kubernetes リソースの状態・履歴・承認・PRレビューを見える化するための仕組みです。

結論から言うと、管理者は サービス接続、RBAC、名前空間、プライベート AKS への到達性、承認チェック を確認する必要があります。開発者は YAML の environment 指定、KubernetesManifest タスク、レビューアプリ用の動的リソース を理解しておくと、AKS への CI/CD を安全に運用しやすくなります。Microsoft Learn では、Azure Pipelines 環境の Kubernetes リソースは AKS を含む Kubernetes クラスターをデプロイ対象にでき、リソース状態やコミットへの追跡性を提供すると説明されています。 (Microsoft Learn)

Azure Pipelines の Kubernetes resources in environments とは

Azure Pipelines の Kubernetes resources in environments は、Azure Pipelines の「環境」に Kubernetes クラスターや名前空間をリソースとして登録し、デプロイジョブからそのリソースをターゲットにする機能です。

Azure DevOps の「環境」は、Dev、Test、Staging、Production など、パイプラインがソフトウェアをデプロイする論理的な対象を表します。環境には Kubernetes や仮想マシンのリソースを紐づけられ、デプロイ履歴、コミット、作業項目、リソース正常性、セキュリティ設定をまとめて管理できます。 (Microsoft Learn)

AKS へのデプロイでこの仕組みを使うと、単に kubectl apply を実行するだけでは見えにくかった情報を、Azure DevOps 上で確認しやすくなります。

たとえば、次のような運用課題に向いています。

本番環境に反映されたコミットをすぐ確認したい
複数のマイクロサービスが同じ AKS 環境へデプロイしており、変更元を追跡したい
PRごとに一時的なレビュー環境を作り、マージ前に画面やAPIの動作を確認したい
Production へのデプロイ前に承認を必須にしたい
ImagePullBackOff など、デプロイ後の失敗原因を早く特定したい

何が変わるのか：AKSの仕様変更ではなく「デプロイ管理の見え方」が変わる

今回のポイントは、AKS クラスターの実行仕様が突然変わるというより、Azure Pipelines から AKS を扱うときの管理単位が明確になることです。

従来のようにサービス接続とスクリプトだけで AKS にデプロイする構成では、成功・失敗のログは残りますが、「環境」という単位での履歴や承認、リソース状態の把握が弱くなりがちです。Kubernetes resources in environments を使うと、デプロイ先を Azure Pipelines の環境リソースとして扱えるため、運用チームが追跡しやすくなります。

観点	単純な `kubectl` / タスク実行中心	Kubernetes resources in environments 利用時
デプロイ先の管理	YAMLやサービス接続名を見ないと分かりにくい	環境とリソースとして確認できる
変更履歴	パイプライン実行ログ中心	環境単位でデプロイ履歴を確認できる
追跡性	コミットと実リソースの関係が分散しやすい	パイプライン、コミット、Kubernetesリソースを関連付けやすい
承認	YAMLや別運用で制御しがち	環境の承認とチェックで制御しやすい
PRレビュー	別途レビュー環境を作る必要がある	動的なレビューアプリを構成できる
障害調査	ログ、kubectl、監視ツールを横断しやすい	ワークロード状態ビューで初動確認しやすい

特に重要なのは、Azure Pipelines の Kubernetes Manifest タスクが追跡性を支援する注釈を追加し、どの Azure DevOps 組織、プロジェクト、パイプラインが名前空間内のオブジェクト更新に関与したかを確認できる点です。 (Microsoft Learn)

対象者：誰が確認すべきか

この情報の影響を受けるのは、AKS を使っているすべての担当者というより、Azure Pipelines で AKS へ継続的にデプロイしているチームです。

対象者	確認すべき内容
Azure DevOps 管理者	環境の作成権限、サービス接続、パイプライン権限、承認とチェック
AKS 管理者	名前空間設計、RBAC、ServiceAccount、RoleBinding、プライベートクラスター接続
開発者	YAML の `environment` 指定、PRレビューアプリ、KubernetesManifest タスク
セキュリティ担当者	本番環境への承認、ブランチ制御、不要なオープンアクセスの有無
SRE / 運用担当	デプロイ履歴、障害時の追跡、ワークロード状態確認

反対に、AKS を使っていても Azure Pipelines でデプロイしていない場合や、GitHub Actions、Argo CD、Flux などを主なデプロイ基盤にしている場合は、直接の影響は限定的です。ただし、Azure DevOps との併用や移行を検討しているなら、設計段階で確認しておく価値があります。

AKS リソース追加時に作成される ServiceAccount と RBAC に注意

AKS リソースを Azure Pipelines 環境に追加すると、AKS は選択したクラスターと名前空間に ServiceAccount を作成し、環境内の Kubernetes リソースを指定した名前空間にマップします。RBAC が有効なクラスターでは RoleBinding も作成され、ServiceAccount のスコープは選択した名前空間に制限されます。一方、Kubernetes RBAC が無効なクラスターでは、作成された ServiceAccount が名前空間をまたいだクラスター全体の権限を持つと説明されています。 (Microsoft Learn)

この違いは非常に重要です。RBAC が無効な AKS クラスターで安易に環境リソースを作ると、パイプラインが想定以上に広い範囲を操作できる可能性があります。

管理者が確認すべきRBACのポイント

AKS 管理者は、少なくとも次の点を確認してください。

確認項目	判断基準
AKS クラスターで RBAC が有効か	本番・共有環境では RBAC 有効を前提にする
パイプライン用 ServiceAccount の権限	対象名前空間に限定されているか
RoleBinding の対象	不要に `cluster-admin` 相当になっていないか
名前空間設計	dev、stg、prod、review などを分離しているか
サービス接続の利用範囲	すべてのパイプラインに許可していないか

失敗しやすいのは、「検証用だから」と広い権限を与えたサービス接続を、そのまま本番用パイプラインでも使い回すケースです。検証用、ステージング用、本番用で環境とサービス接続を分け、承認ルールも別に設定するのが安全です。

プライベート AKS クラスターではエージェントの配置が重要

プライベート AKS クラスターでは、API サーバーエンドポイントがパブリック IP アドレスで公開されません。そのため、Azure Pipelines からデプロイするには、クラスターの仮想ネットワークへ到達できる構成が必要です。Microsoft Learn では、プライベート AKS クラスターに対して、仮想ネットワーク内のセルフホステッドエージェント、または Managed DevOps Pools の利用が示されています。 (Microsoft Learn)

ここで誤解しやすいのは、「Azure DevOps から見えているサービス接続があるから、プライベート AKS にもそのままデプロイできる」と考えてしまうことです。実際には、パイプラインを実行するエージェントから AKS API サーバーに到達できなければ、検証やデプロイは失敗します。

プライベート AKS で確認するネットワーク項目

項目	確認内容
エージェントの配置	AKS の VNet または到達可能な VNet にあるか
DNS 解決	プライベート API サーバー名を解決できるか
ネットワーク経路	VNet ピアリング、VPN、ExpressRoute、Private Endpoint などが適切か
NSG / Firewall	エージェントから API サーバーへの通信を遮断していないか
エージェントプール	本番用と検証用を分けているか

Microsoft Learn のサービス接続ドキュメントでも、プライベートまたはネットワークから隠されたクラスターでは Kubernetes サービス接続オプションが機能しない場合があり、Azure Resource Manager ベースのサービス接続と、クラスターへ直接ネットワークアクセスできるエージェントの利用が示されています。 (Microsoft Learn)

Azure Pipelines 環境に AKS リソースを追加する基本手順

AKS リソースを Azure Pipelines の環境に追加する流れは、管理者が最初に押さえておくべき基本です。

手順	作業内容
1	Azure DevOps のプロジェクトで Pipelines > Environments を開く
2	対象の環境を選び、Add resource を選択する
3	リソース種類として Kubernetes を選択する
4	Provider に Azure Kubernetes Service を選択する
5	Azure サブスクリプション、AKS クラスター、名前空間を選択する
6	新しい名前空間を使う場合は名前を入力する
7	Validate and create で検証して作成する

公式ドキュメントでは、作成後に環境の Resources タブへ新しい Kubernetes リソースが表示されると説明されています。 (Microsoft Learn)

実務では、名前空間名をその場の思いつきで作るのではなく、次のようなルールを決めておくと後から混乱しません。

appname-dev
appname-stg
appname-prod
review-app-<pull-request-id>

名前空間名にアプリ名、環境名、用途を含めると、Azure DevOps、AKS、監視ツールの表示を突き合わせやすくなります。

YAML では `environment` の指定が運用の分かれ目になる

Kubernetes resources in environments を使う場合、YAML パイプラインではデプロイジョブの environment に環境名とリソース名を指定します。

例として、公式ドキュメントでは次のような形式で環境リソースをターゲットにしています。

jobs:
- deployment: Production
  displayName: Production
  environment: 'myenvironmentname.myresourcename'
  strategy:
    runOnce:
      deploy:
        steps:
        - task: KubernetesManifest@1
          displayName: Deploy to Kubernetes cluster
          inputs:
            action: deploy
            manifests: |
              $(Pipeline.Workspace)/manifests/deployment.yml
              $(Pipeline.Workspace)/manifests/service.yml
            imagePullSecrets: |
              $(imagePullSecret)
            containers: |
              $(containerRegistry)/$(imageRepository):$(tag)

ポイントは、単に KubernetesManifest タスクを使うだけではなく、デプロイジョブがどの環境リソースを対象にしているかを明示することです。環境リソースをターゲットにすると、デプロイ履歴や追跡性を環境単位で確認しやすくなります。

既存の YAML を見直す場合は、次の観点でチェックしてください。

確認箇所	見るべきポイント
`deployment` ジョブ	通常の `job` ではなくデプロイジョブとして定義しているか
`environment`	`環境名.リソース名` の形式で対象を明確にしているか
`condition`	PR、本番、ブランチ条件が意図どおりか
`namespace`	dev/stg/prod/review が混在していないか
`imagePullSecrets`	ACR などからイメージを取得できる設定か
`containers`	デプロイするイメージタグが `$(Build.BuildId)` などで追跡可能か

レビューアプリを使う場合は動的名前空間と権限を確認する

Kubernetes resources in environments の実用的な機能の一つが、レビューアプリです。レビューアプリは、Git リポジトリの各プルリクエストを環境内の動的な Kubernetes リソースへデプロイし、GitHub コメントにレビューアプリへのリンクを投稿できます。マージ前に画面や依存サービスとの連携を確認できるため、フロントエンド変更やAPI変更のレビューに向いています。 (Microsoft Learn)

典型的には、次のような名前空間を PR ごとに作ります。

variables:
  k8sNamespaceForPR: 'review-app-$(System.PullRequest.PullRequestId)'

PR 用のデプロイジョブでは、refs/pull/ で始まるブランチを条件にして、レビュー用の名前空間へデプロイします。

- deployment: DeployPullRequest
  displayName: Deploy Pull request
  condition: and(succeeded(), startsWith(variables['Build.SourceBranch'], 'refs/pull/'))
  environment: 'myenvironmentname.$(k8sNamespaceForPR)'

ただし、レビューアプリは便利な一方で、放置すると名前空間、Pod、Service、LoadBalancer、Secret が増え続ける可能性があります。PR がクローズされた後の削除処理、コスト、外部公開の範囲を必ず設計してください。

レビューアプリ導入時の注意点

注意点	対策
PRごとにリソースが増える	PRクローズ時の削除ジョブを用意する
LoadBalancer が増えてコスト化する	Ingress共有や内部公開を検討する
Secret が複製される	本番Secretをレビュー環境に流用しない
権限が広くなりやすい	review用名前空間に限定したRoleBindingにする
外部からアクセス可能になる	認証、IP制限、短期URLなどを検討する

公式ドキュメントでは、既存パイプラインにレビューアプリ用ジョブを追加する場合、通常の Kubernetes 環境リソースを支えるサービス接続がクラスター管理者資格情報を使う設定であること、またはレビューアプリ名前空間向けの RoleBinding が必要であることが示されています。 (Microsoft Learn)

サービス接続は「全パイプライン許可」にしない

Azure Pipelines で AKS にデプロイするには、サービス接続の設計も重要です。サービス接続は、Azure Pipelines と外部サービスまたはリモートサービスを認証付きでつなぐ設定です。Kubernetes クラスター、Docker レジストリ、Azure サブスクリプションなどへの接続に使われます。 (Microsoft Learn)

サービス接続作成時には「すべてのパイプラインにアクセス許可を付与する」という選択肢がありますが、Microsoft Learn ではこのオプションは推奨されず、各パイプラインを個別に承認する方法が示されています。 (Microsoft Learn)

本番 AKS へ接続できるサービス接続をすべてのパイプラインに許可すると、意図しない YAML から本番環境へアクセスできるリスクが高まります。

サービス接続の実務チェックリスト

本番用サービス接続は、利用できるパイプラインを個別承認する
dev、stg、prod でサービス接続を分ける
Docker レジストリ接続と Kubernetes 接続の権限を混同しない
退職者や不要な管理者がサービス接続を編集できないようにする
使用履歴を定期的に確認する
可能な限り、短命な認証方式や最小権限を検討する

Kubeconfig 方式を使う場合は、AKS によって発行されたユーザー証明書の有効期限にも注意が必要です。Microsoft Learn では、AKS によって発行されたユーザー証明書は2年間有効であり、kubeconfig を使う場合は2年後にサービス接続の再構成が必要と説明されています。 (Microsoft Learn)

承認とチェックで本番デプロイを制御する

Azure Pipelines の環境は、単なる表示用のグループではありません。環境やサービス接続などの保護されたリソースには、アクセス許可、チェック、承認を設定できます。Microsoft Learn では、環境やサービス接続などは保護されたリソースに含まれ、パイプラインがリソースを使う前に承認やチェックを要求できると説明されています。 (Microsoft Learn)

本番 AKS へのデプロイでは、少なくとも次のチェックを検討してください。

チェック	使いどころ
手動承認	Production 反映前に責任者の確認を必須にする
ブランチ制御	`main` や保護ブランチ以外からの本番反映を防ぐ
営業時間	深夜や休日の不用意な本番デプロイを避ける
必須テンプレート	組織標準のデプロイテンプレートを強制する
パイプライン権限	特定パイプラインだけに環境利用を許可する

特にブランチ制御は、PR 運用と組み合わせると効果的です。レビューアプリは PR で自由に作れても、本番環境へのデプロイは main ブランチの承認済み変更だけに限定できます。

既存パイプラインから移行する時の進め方

既存の Azure Pipelines で AKS にデプロイしている場合、いきなり本番 YAML を全面的に書き換えるのは避けた方が安全です。まずはステージング環境で Azure Pipelines 環境と Kubernetes リソースを作り、デプロイ履歴とリソース状態が期待どおりに見えるか確認しましょう。

おすすめの移行手順は次のとおりです。

ステップ	作業	成功条件
1	現在のサービス接続と権限を棚卸しする	どのパイプラインがAKSへ接続できるか分かる
2	dev または stg 用の環境を作成する	Azure DevOps上に環境が作成される
3	AKS の対象名前空間をリソースとして追加する	Resources タブに Kubernetes リソースが表示される
4	YAML の `environment` を追加・修正する	デプロイジョブが環境リソースをターゲットにする
5	KubernetesManifest タスクでデプロイする	マニフェスト反映と履歴記録が成功する
6	承認とチェックを設定する	本番環境で承認なしに進まない
7	レビューアプリを必要に応じて追加する	PRごとの一時環境が作成・削除できる
8	本番へ展開する	prod用環境・名前空間・権限が分離されている

移行時に最も多い失敗は、environment の名前やリソース名を間違えることです。Azure DevOps 上の環境名、リソース名、YAML の指定が一致しているかを確認してください。

デプロイ後に確認すべきポイント

Kubernetes resources in environments を導入したら、初回デプロイ後に次の点を確認します。

Azure DevOps 側

Environments に対象環境が表示されているか
Resources タブに AKS の Kubernetes リソースが表示されているか
Deployments タブにデプロイ履歴が残っているか
変更タブや作業項目からコミットを追跡できるか
承認とチェックが想定どおりに動作するか
本番環境が不要なパイプラインから利用できないか

AKS 側

対象名前空間にデプロイされているか
ServiceAccount と RoleBinding が想定どおりか
imagePullSecrets が作成され、イメージを取得できているか
Pod が Running になっているか
ImagePullBackOff、CrashLoopBackOff、Pending が発生していないか
レビューアプリ用名前空間が不要時に削除されるか

公式ドキュメントでも、ワークロードの状態ビューは新しいデプロイによって起きたミスや回帰のデバッグに役立ち、未構成の imagePullSecrets による ImagePullBackOff などの原因特定に役立つとされています。 (Microsoft Learn)

よくある失敗と対策

環境リソースを作ったのにパイプラインから使えない

原因として多いのは、パイプラインに環境やサービス接続を使う権限がないケースです。保護されたリソースには、ユーザー権限とパイプライン権限を設定できます。信頼できる特定のパイプラインにだけアクセスを明示的に付与するのが基本です。 (Microsoft Learn)

プライベート AKS へのデプロイだけ失敗する

Microsoft ホステッドエージェントからプライベート AKS の API サーバーへ到達できないことが原因になりがちです。AKS の VNet に到達できるセルフホステッドエージェント、Managed DevOps Pools、VNet ピアリング、DNS 解決を確認してください。

PRレビューアプリが作成できない

レビューアプリ用の名前空間を作成する権限が不足している可能性があります。既存パイプラインへ追加する場合は、サービス接続の権限やレビューアプリ名前空間への RoleBinding を確認します。

デプロイは成功したのにイメージが起動しない

imagePullSecrets が正しく作成されていない、ACR への認証が通っていない、イメージタグが存在しない、といった原因が考えられます。KubernetesManifest タスクで createSecret と deploy の順序、Docker レジストリサービス接続、イメージタグを確認してください。

本番環境に意図しないパイプラインがアクセスできる

サービス接続や環境で「すべてのパイプラインにアクセス許可」を有効にしている可能性があります。本番環境では原則として、利用可能なパイプラインを個別に承認し、承認チェックとブランチ制御を組み合わせてください。

管理者と開発者が今すぐ確認すべきチェックリスト

Kubernetes resources in environments を AKS 運用に取り入れる場合、まずは次の項目を確認してください。

役割	今すぐ確認すること
管理者	Azure Pipelines 環境の作成権限が適切か
管理者	本番環境に承認とチェックが設定されているか
管理者	サービス接続が全パイプラインに開放されていないか
AKS管理者	RBAC が有効で、ServiceAccount が名前空間に限定されているか
AKS管理者	プライベート AKS へ到達できるエージェント構成か
開発者	YAML の `environment` が正しい環境リソースを指しているか
開発者	KubernetesManifest タスクで Secret 作成とデプロイが分かれているか
開発者	PRレビューアプリの作成・削除ルールがあるか
運用担当	デプロイ履歴からコミットと作業項目を追跡できるか
セキュリティ担当	Production へのデプロイ経路が限定されているか

まとめ：AKSへのデプロイは「実行できる」だけでなく「追跡できる」状態にする

Azure Pipelines の Kubernetes resources in environments は、AKS へのデプロイを単なる自動実行から、履歴・権限・承認・状態確認まで含めた運用管理へ引き上げるための機能です。

特に確認すべきポイントは、次の5つです。

AKS リソースは環境と名前空間に紐づけて管理する
ServiceAccount と RoleBinding の権限を最小化する
プライベート AKS ではエージェントのネットワーク到達性を確認する
本番環境では承認、ブランチ制御、パイプライン権限を設定する
レビューアプリを使う場合は、動的名前空間の削除と権限管理まで設計する

まずは既存の Azure Pipelines がどの AKS クラスター、どの名前空間、どのサービス接続を使っているかを棚卸ししてください。そのうえで、dev または stg 環境から Kubernetes resources in environments を導入し、デプロイ履歴と追跡性が期待どおりに機能するか確認するのが安全な進め方です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。