157 Views
September 27, 25
スライド概要
2025年9月27日の『.NETラボ 勉強会 2025年9月』で発表した資料です。
都内で働いているインフラエンジニアです。Azure を含むMicrosoft 製品、インフラ、CI/CD を強みとしています。Microsoft MVP 2025~
Azure Kubernetes Service における アプリケーション、インフラのデプロイ方法を理解する 2025/09/27 .NETラボ 勉強会 2025年9月 Kazuki Yamabe
アジェンダ • 自己紹介 • Kubernetes & Azure Kubernetes Service (AKS) • AKS のデプロイ • IaC による一元管理パターン • GitOps + IaC の分離パターン • まとめ • 参考資料 2
アジェンダ • 自己紹介 • Kubernetes & Azure Kubernetes Service (AKS) • AKS のデプロイ • IaC による一元管理パターン • GitOps + IaC の分離パターン • まとめ • 参考資料 3
自己紹介 名前:Kazuki Yamabe 所属:株式会社エーピーコミュニケーションズ 受賞歴:Microsoft MVP 2025 ~ (Azure Compute Infrastructure、Azure Networking) ◼ ブログ・SNS • ブログ:https://www.kdkwakaba.com/ • X:@kdk_wakaba • Linkedin:kdk-wakaba 4
注意事項 • 本内容は2025年9月27日現在の内容となります。今後のアップデートで仕様変更となる可能性もあ るためご了承ください 5
アジェンダ • 自己紹介 • Kubernetes & Azure Kubernetes Service (AKS) • AKS のデプロイ • IaC による一元管理パターン • GitOps + IaC の分離パターン • まとめ • 参考資料 6
Kubernetes & Azure Kubernetes Service (AKS) • コンテナ化したアプリケーションのデプロイ、スケーリン グ、管理・運用を自動化するオーケストレーション ツール - Google 社のBorg を前身とし、現在ではCNCF (Cloud Native Computing Foundation) で管 理 • クラスターの制御を行うコントロールプレーンとアプリ ケーションコンテナを起動するワーカーノードに分かれ る • マイクロサービスアーキテクチャや高可用性のシステ ム、スケーラビリティを求めるケースで利用される 画像引用元:Kubernetes Components 7
Kubernetes & Azure Kubernetes Service (AKS) • Azure 上でコンテナアプリケーションを利用できるマ ネージドなKubernetes サービス • マネージドサービスによるKubernetes の複雑な運 用・管理の負担削減、需要に応じたNode のス ケーリングにも対応 • 各種Azure サービスとの連携、サードパーティ製 OSS との統合による構築負担を削減 - Entra ID によるRBAC やAzure Monitor による Managed Prometheus、Managed Grafana の 連携 - KEDA、Dapr のようなKubernetes 拡張機能にも 対応 画像引用元:Azure Kubernetes Services (AKS) の中心概念 8
アジェンダ • 自己紹介 • Kubernetes & Azure Kubernetes Service (AKS) • AKS のデプロイ • IaC による一元管理パターン • GitOps + IaC の分離パターン • まとめ • 参考資料 9
AKS のデプロイ – 従来のオンプレミス、VM 上のKubernetes デプロイ オンプレミス、VM 上のKubernetes ではNode のプ ロビジョニングとKubernetes の2種類のデプロイが必 要だった。 • Node のプロビジョニングはChef、Ansible のよう なツールが利用されていた - 各ツールにもKubernetes 用の設定や拡張機能があ るため、一元管理もやろうと思えばできた • 場合によってはkubectl やhelm コマンドのような コマンド芸になることも… - デプロイ用のシェルスクリプト、コマンド芸によるデプロイ 用のパイプライン、など - 自動化が進んでいないところでは手動でコマンドを実 行、なんてことも 10
AKS のデプロイ – パブリッククラウドのKubernetes サービス デプロイ パブリッククラウドではマネージドなKubernetes サー ビスが中心なり、Node 管理からクラウドリソース管理 に変わる。 • IaC のプロビジョニングがクラウドリソースのプロビジョ ニングに変わる - Bicep、Terraform、Pulumi のようなクラウドサービ スのプロビジョニングに適したIaC ツールに置き換わる • Kubernetes のデプロイは従来と同様に必要 - Kubernetes クラスター作成後、クラスターへ接続す るための資格情報取得が必要となる - 一時的なPod でコマンドを実行する機能もある (AKS のRun command、など) ※ VM やVM イメージベースでNode をカスタマイズ可能 なサービスもあります (例:Amazon EKS やGoogle Kubernetes Engine など) 11
AKS のデプロイ – AKS の基本的なデプロイの流れ AKS でシステムを稼働するには以下のような流れでプロビジョニング、デプロイが必要。 1. Azure Portal、Azure CLI (Azure PowerShell)、IaC ツールでAKS クラスターと関連する Azure リソースを作成する 2. AKS クラスターに接続するため、AKS クラスターの資格情報を取得する 3. AKS クラスターにKubernetes マニフェストを適用する 4. 必要に応じAKS に関連するAzrue リソースをセットアップする (ネットワーク、監視、など) 12
AKS のデプロイ – デプロイ管理の種類 AKS ではアプリケーション、インフラの管理方法によってデプロイの管理が変わる。 • IaC による一元管理パターン • GitOps + IaC の管理分離パターン • スクリプト、コマンドによる手動デプロイパターン (非推奨) 今回はこちらの2種類を 説明します。 13
アジェンダ • 自己紹介 • Kubernetes & Azure Kubernetes Service • Azure Kubernetes Service のデプロイ • IaC による一元管理パターン • GitOps + IaC の分離パターン • まとめ • 参考資料 14
IaC による一元管理パターン – 概要 • IaC ツールでAKS のインフラとKubernetes をまとめて管理する方法 - デプロイをIaC ツールで管理するため、CI/CD パイプラインへ組み込みやすい - CI/CD の組み込みもIaC の適用一つで対応できるためパイプラインの簡素化にもなる • アプリケーションとインフラ (Azure リソース) をまとめて管理 or デプロイしたいケースに有効 - 管理するツールを減らすこともできるため、運用や学習コストの負担を減らせる • 大規模なシステムの場合はリポジトリの肥大化、IaC ツールの実行時間増加のような課題もある 15
IaC による一元管理パターン – 対応可能なIaC ツール • Azure リソース、Kubernetes の両方を管理する にはKubernetes マニフェストの適用に対応してい るIaC ツールが必要 - Terraform - Pulumi • Bicep のaks run command モジュールはAVM (Azure Verified Modules) に引き継がれず 2024年4月にアーカイブされたため非推奨 - Bicep を使う場合、パイプラインツールでAzure リソー スのプロビジョニング後にKubernetes のデプロイを行う 必要がある 16
IaC による一元管理パターン – Terraform を使ったデモ Terraform を使い、Azure Kubernetes Service のプロビジョニングからKubernetes マニフェストの デプロイまで実施する。 17
IaC による一元管理パターン – CI/CD パイプラインへの組み込み • IaC 一元管理の場合、CI/CD パイプライン からIaC の実行でAzure リソースのプロビジョ ニングからKubernetes のデプロイまで簡単に まとめられる - ただし、CI/CD パイプラインで管理する場合、 state ファイルの管理は適切な場所で管理する こと - コスト面で余裕がある場合はTerraform Cloud のような有償サービスを使うのも一つ 18
IaC による一元管理パターン – メリット・デメリット メリット デメリット •アプリケーション、インフラで構成の一貫性を担保で •アプリケーションのみ、インフラのみデプロイしたい場 きる 合も一連のデプロイが必要となるデプロイ時間が長く -Azure リソース、Kubernetes をまとめて管理、デ なる可能性がある プロイが可能 •CI/CD パイプラインによる自動化を行いやすい(コ ンテナイメージのビルド・公開、リソースのプロビジョニ ング、マニフェストのデプロイ、など) •部分的なデプロイによる不整合、環境差異のリス クを軽減できる -手作業によるエラーやデプロイ漏れ、のようなミスを 極力削減可能 -ただしIaC のコード、マニフェストもファイルのため修 正漏れやレビューの見逃しによるエラーには十分注 意する -Terraform やPulumi だと差分だけ適用すること も可能だが、規模の大きいシステムでは単純に時間 がかかることも -アプリケーション、インフラの責任分界点が曖昧にな りやすい -一つのチームでアプリケーション、インフラの両方を見 ることになるため対応者にある程度のスキルが求めら れる •Azure リソース、Kubernetes のデプロイを統合 するため、状況によってトラブルシューティングが難化 する •一部IaC ツールでは一元管理で対応できない (Bicep からKubernetes マニフェストを適用でき ない、など) 19
アジェンダ • 自己紹介 • Kubernetes & Azure Kubernetes Service • Azure Kubernetes Service のデプロイ • IaC による一元管理パターン • GitOps + IaC の分離パターン • まとめ • 参考資料 20
GitOps + IaC の分離パターン – 概要 • アプリケーション、Kubernetes マニフェストをGitOps ツールで、AKS と関連するAzure リソースをIaC ツールで管理する方法 - GitOps はGit リポジトリを信頼源とし、リポジトリの更新に合わせてシステムの状態を一致させる手法 - アプリケーションやKubernetes マニフェストのみ修正したい、AKS の設定のみ修正したい、のような部分的修正 を行いやすい • アプリケーション開発者とクラウドインフラ管理者を分担させたいケースに有効 - 大規模なチームの場合、開発専任、クラウドインフラ専任、みたいなケースで分けたいことも • GitOps 用の管理ツールが増える、複雑なデプロイを求められる場合にGitOps が適さないケースもあるため注意 - 導入に関してはKubernetes 拡張機能のGitOps ツールを使う方法もある (後述) 21
GitOps + IaC の分離パターン – どんなツールがあるか? • GitOps を行う場合、GitOps 用のツールを Kubernetes クラスターに導入する必要がある - Flux CD - Argo CD - Spacelift、など • AKS の場合、Flux CD を簡単に準備できる Kubernetes 拡張機能もあり - Argo CD のKubernetes 拡張機能はプライベートプレ ビュー中 • マルチステージの管理を行いたい場合はArgo CD + Kargo みたいな組み合わせもできる 22
GitOps + IaC の分離パターン – デプロイの流れ (アプリ) ① Push & Pull Request Application Developer ② Approve & Merge GitHub ③ Build & Test ⑤ Update Manifest ④ Push container image GitHub Actions Container Registry ⑥Sync ⑧Deploy argocd app ⑦ Pull container image AKS Cluster 23
GitOps + IaC の分離パターン – デプロイの流れ (インフラ) ① Push & Pull Request Cloud Infrastructure engineer ② Approve & Merge ③ IaC Deploy GitHub GitHub Actions Container Registry ③ IaC Deploy argocd app AKS Cluster 24
GitOps + IaC の分離パターン – メリット・デメリット メリット デメリット •アプリケーションとインフラで管理が分離されるため、 •アプリケーション、インフラが分離するため、全体の 各々のタイミングによるデプロイが可能 変更履歴を追跡しにくい -開発者はアプリケーションのコードに集中でき、クラ •GitOps に適した構成への修正が必要なため、適 ウドインフラ管理者はIaC、インフラに集中可能 した構成への移行、修正に時間がかかる可能性あ -各々のタイミングによるデプロイが可能 り -Pull Request のmerge でKubernetes マニ フェストのイメージタグ修正、アプリケーションのみデプ ロイ、も可能 •main/master ブランチへのPull Request マー ジによる管理で、手動の承認プロセスの削減も可 能 •権限分離によるセキュリティ向上に繋がる -Azure リソースはクラウドインフラ管理者で管理し、 Kubernetes マニフェストは開発者がGit で管理で きる -Flux CD やArgo CD のようなールのセットアップ も必要となる -Argo Rollouts のようなツールを使う場合、 Kubernetes マニフェストの種別変更や追加設定 も必要となる •ツールによってWeb UI への通信経路や管理用 端末が必要となる -セキュリティの厳しい環境の場合、追加可能かの確 認も必要 25
結局どのデプロイ方法がいいの? AKS のデプロイでこのデプロイ方法が必ず正解というものはない。システムや管理体制に応じて使い分ける。 • アプリケーションとクラウドインフラをある程度まとめて管理したい場合はIaC 一元管理 - デプロイ頻度が多くない、アプリケーションとクラウドインフラのまとまったデプロイが必要ならこちら - アプリ、インフラのチームがまとまっているケースもこちら - CI/CD パイプラインでアプリケーション、インフラのデプロイをまとめやすい • アプリケーションとクラウドインフラの管理を分離したい場合GitOps + IaC 分離パターン - アプリケーションの更新頻度が多く、アプリとインフラの権限を分離させたいケースはこちら - Kubernetes の構成やデプロイフローをシンプルにしたい場合もこちら - 複雑なデプロイを求められる場合、GitOps が適さないこともあるため注意 26
アジェンダ • 自己紹介 • Kubernetes & Azure Kubernetes Service • Azure Kubernetes Service のデプロイについて • IaC による一元管理パターン • GitOps + IaC の分離パターン • まとめ • 参考資料 27
まとめ • Azure を含むパブリッククラウドではクラウドリソースのプロビジョニングとKubernetes デプロイの2つが必 要となる • アプリケーションとインフラをある程度一元管理したい場合はIaC一元管理パターンがある • アプリケーションとインフラの管理を分離したい、デプロイを頻繁に行う場合はGitOps + IaC 分離パター ンもある 28
参考資料 • Overview | Kubernetes • Azure Kubernetes Service (AKS) とは • Azure Pipelines を使用した AKS アプリの CI/CD • Azure Kubernetes Service 向け GitOps • Azure Kubernetes Service (AKS) の DevSecOps • Azure 上の Terraform の概要 - Terraform とは • gavinbunney/kubectl - Terraform Registry • Bicep とは • Infrastructure as Code in Any Language – Pulumi IaC | Pulumi • Flux • Argo CD | Argo • Kargo 29
ご清聴ありがとうございました。 30