Contents
Kubernetes の基本概念と宣言的デプロイ
Kubernetes はコンテナ化されたアプリケーションを 統一的かつ自動的に 管理するオーケストレーション基盤です。このセクションでは、クラスタの主要構成要素と「望む状態」をコードで記述する宣言的デプロイ手法の全体像を把握します。まず概念を整理すれば、以降の CI/CD・GitOps の設計が格段にシンプルになります。
Kubernetes クラスタの構成要素
以下は Kubernetes が提供する主要コンポーネントです。各部品の役割と相互関係を理解することで、障害切り分けやスケールアウト時の設計指針が得られます。
- Control Plane – API Server、Scheduler、Controller Manager で構成され、クラスタ全体の状態管理・意思決定を行います。
- Node（ワーカーノード） – 実際に Pod を稼働させる物理または仮想マシンです。
kubeletがノード上のリソースと API Server の同期を、kube-proxyが Service のネットワーク抽象化を担います。 - Pod – 1 つ以上のコンテナとそれらが共有するネットワーク・ストレージを束ねた最小実行単位です。スケジューラは Pod を Node に割り当てます。
- Service – Pod の集合に対して永続的なアクセス入口（ClusterIP、NodePort、LoadBalancer 等）を提供し、Pod の IP が変わってもクライアントからの接続を安定させます。
- Deployment – ReplicaSet を自動生成し、Pod のローリングアップデート・ロールバック・スケーリングを宣言的に管理します。
宣言的デプロイとマニフェスト例
Kubernetes は「望む状態 (desired state)」を YAML/JSON で記述し、コントローラが実際のクラスタ状態と比較して差分を自動修正します。以下は最も基本的な Deployment のマニフェストです。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
apiVersion: apps/v1 kind: Deployment metadata: name: web-app spec: replicas: 3 # 期待する Pod 数 selector: matchLabels: app: web template: metadata: labels: app: web spec: containers: - name: nginx image: nginx:1.25 # 宣言したイメージが自動で取得・起動される ports: - containerPort: 80 |
- Git 管理 – 上記マニフェストをリポジトリでバージョン管理すると、変更履歴とコードレビューが CI/CD パイプラインに自然に組み込めます。
- 自己修復 –
kubectl apply -fを実行するだけで、Kubernetes が現在のクラスタ状態を期待通りに調整します。
CI/CD 全体フローと GitOps の位置付け
CI（継続的インテグレーション）から CD（継続的デリバリー／デプロイ）までの一連の自動化は、開発スピードと品質を同時に向上させます。ここでは GitOps がどのようにフロー全体に安全性と可観測性を付与するかを解説します。
GitOps がもたらすメリット
GitOps は「Git を単一真実源（single source of truth）として扱う」運用手法です。以下のポイントが主な利点となります。
- 宣言的管理 – インフラやマニフェストはコードとして保存され、差分が常に可視化されます。
- 自動ロールバック – 望まない変更が検知されたら Git の過去コミットへ即座に戻すことが可能です。
- 監査トレイル – PR/マージ履歴がそのままデプロイ履歴になるため、コンプライアンス要件を簡単に満たせます。
典型的な CI/CD パイプライン例
以下はコード変更から本番環境へリリースするまでの流れです。各ステップで GitOps が果たす役割も併記しています。
- ソースコード → コンテナビルド
- Docker/BuildKit でイメージを作成し、Artifact Registry（または ECR/GCR）へプッシュ。
- ユニット・統合テスト実行
- テストがすべて成功したら次ステップへ進む。失敗時はビルドを中断。
- マニフェスト更新 & Pull Request 作成
- CI が自動で
image:フィールドに新しいタグを書き換え、PR を生成。 - GitOps エージェントが PR マージを検知
- Argo CD や Flux が変更を取得し、
kubectl apply相当の操作でクラスタへ適用。 - ヘルスチェック & カナリア評価
- ステージング環境で自動的にモニタリングが走り、問題なければ本番へ昇格。
この流れを採用すると「コード＝インフラ」の一貫性が保たれ、手作業によるヒューマンエラーは大幅に削減されます。
Azure DevOps Pipelines と GitHub Actions を用いた AKS 自動デプロイ
Microsoft のマネージド Kubernetes である AKS は、Azure の認証基盤とシームレスに連携できる点が最大の魅力です。本節では、Azure DevOps と GitHub Actions の両方で安全かつスケーラブルなデプロイを実現する手順を詳述します。
Azure DevOps Pipelines の構成例
以下は AKS へデプロイするための最小構成です。シークレットは Azure Key Vault 経由で安全に注入し、az aks get-credentials によって kubeconfig を取得します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
trigger: - main variables: AKS_RESOURCE_GROUP: myResourceGroup AKS_CLUSTER_NAME: myAKSCluster stages: - stage: Deploy jobs: - job: AKS_Deploy pool: vmImage: 'ubuntu-latest' steps: - task: AzureCLI@2 inputs: azureSubscription: 'MyServiceConnection' scriptType: bash scriptLocation: inlineScript inlineScript: | # AKS の認証情報を取得（最小権限で実行） az aks get-credentials --resource-group $(AKS_RESOURCE_GROUP) \ --name $(AKS_CLUSTER_NAME) \ --file $HOME/.kube/config # Git 管理されたマニフェストをクラスタへ適用 kubectl apply -f manifests/ env: AZURE_CLIENT_ID: $(servicePrincipalId) AZURE_CLIENT_SECRET: $(servicePrincipalKey) |
- ポイント
--adminオプションは使用せず、サービスプリンシパルに最小権限（ClusterAdmin ロール）だけを付与。kubectl applyの対象ディレクトリはリポジトリ内のmanifests/とし、変更があれば自動で反映されます。
GitHub Actions での OIDC 認証とデプロイ手順
GitHub が提供する OIDC（OpenID Connect）連携を利用すれば、シークレットをコードに埋め込むことなく Azure に認証できます。以下はその実装例です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
name: Deploy to AKS on: push: branches: [ main ] permissions: id-token: write # OIDC トークン取得に必要 contents: read jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Azure Login with OIDC uses: azure/login@v1 with: client-id: ${{ secrets.AZURE_CLIENT_ID }} tenant-id: ${{ secrets.AZURE_TENANT_ID }} subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }} - name: Set AKS credentials run: | az aks get-credentials --resource-group ${{ secrets.AKS_RG }} \ --name ${{ secrets.AKS_NAME }} \ --overwrite-existing - name: Deploy manifests run: kubectl apply -f k8s/ |
- ポイント
permissionsにid-token: writeを明示し、GitHub が OIDC トークンを取得できるようにします。- シークレットはすべて GitHub Secrets に保存し、ランタイムでのみ利用されます。
Google Cloud Deploy と Skaffold による GKE デプロイ自動化
Google Cloud が提供する Cloud Deploy はリリースパイプラインの標準化に特化し、Skaffold はローカル開発から CI までをワンコマンドで統一します。本節ではそれぞれの設定例と、両者を組み合わせたフローを紹介します。
Cloud Deploy のパイプライン定義
Cloud Deploy は Git リポジトリの変更を検知し、ステージングから本番へ段階的にロールアウトできます。以下は最小構成の YAML です。
|
1 2 3 4 5 6 7 8 9 10 11 |
apiVersion: deploy.cloud.google.com/v1beta1 kind: DeliveryPipeline metadata: name: my-pipeline serialPipeline: stages: - targetId: gke-staging profiles: [dev] - targetId: gke-prod profiles: [prod] |
targetIdは事前に作成した Cloud Deploy Target（GKE クラスタ情報）を指します。profilesは Skaffold のプロファイル名と同一にすると、環境ごとのマニフェスト差分管理がシンプルになります。
Skaffold を活用したローカル開発フロー
Skaffold は コード変更 → ビルド → デプロイ を自動で繰り返すため、開発者は skaffold dev だけで即座にフィードバックを得られます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
apiVersion: skaffold/v4beta7 kind: Config metadata: name: my-app build: artifacts: - image: gcr.io/$PROJECT_ID/web-app deploy: kubectl: manifests: - k8s/*.yaml profiles: - name: dev activation: - command: dev deploy: helm: releases: - name: web-app-dev chartPath: charts/web-app valuesFiles: - values/dev.yaml - name: prod activation: - command: run deploy: helm: releases: - name: web-app-prod chartPath: charts/web-app valuesFiles: - values/prod.yaml |
skaffold dev→ ソースコードが変更されるたびに新しいイメージがビルドされ、devプロファイルのマニフェストへ自動適用。- 本番デプロイは
skaffold run -p prodで実行し、CI パイプラインからも同様に呼び出せます。
マルチクラウド対応パイプラインの設計とベストプラクティス
Terraform と CI/CD の統合例
インフラは Terraform でコード化し、単一の CI パイプラインから AKS・GKE 両方をプロビジョニングできます。以下は CircleCI のジョブ例です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
version: 2.1 jobs: terraform-plan-apply: docker: - image: hashicorp/terraform:latest steps: - checkout - run: name: Terraform Init & Plan command: | cd infra terraform init -backend-config="bucket=my-tf-state" terraform plan -out=tfplan.out - run: name: Post Plan to PR (if applicable) command: | if [ -n "$CIRCLE_PULL_REQUEST" ]; then terraform show -json tfplan.out | \ curl -X POST -H "Authorization: token $GITHUB_TOKEN" \ -d @- https://api.github.com/repos/${CIRCLE_PROJECT_USERNAME}/${CIRCLE_PROJECT_REPONAME}/issues/comments else terraform apply -auto-approve tfplan.out fi |
- ポイント
- PR が存在する場合は
terraform showの結果を GitHub コメントに投稿し、レビュー担当者がインフラ変更内容を即座に把握できます。 - マージ後の実行では自動的に
applyを走らせ、環境構築が完了します。
ブルーグリーン・カナリアデプロイの実装方法
本番環境でリスクを最小化するために、Service のラベル切り替え と Deployment の RollingUpdate 設定 を組み合わせます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 |
apiVersion: apps/v1 kind: Deployment metadata: name: web-app-blue spec: replicas: 3 selector: matchLabels: app: web version: blue template: metadata: labels: app: web version: blue spec: containers: - name: nginx image: nginx:1.25 --- apiVersion: apps/v1 kind: Deployment metadata: name: web-app-green spec: replicas: 3 selector: matchLabels: app: web version: green template: metadata: labels: app: web version: green spec: containers: - name: nginx image: nginx:1.26 # 新バージョン strategy: type: RollingUpdate rollingUpdate: maxSurge: 25% maxUnavailable: 0% |
- ブルーグリーン –
Serviceのselectorをversion: blue→version: greenに切り替えるだけでトラフィック全体を新バージョンへ移行。 - カナリア – RollingUpdate のパラメータでサーバー数の増減幅を制御し、段階的に負荷テストが可能です。
コンテナイメージスキャンと監視設定
セキュリティと可観測性は本番運用の根幹です。CI では Trivy による脆弱性スキャンを、デプロイ後は Prometheus + Grafana でメトリクスを収集します。
|
1 2 3 4 5 6 7 8 |
# GitHub Actions の Trivy スキャン例 - name: Scan image with Trivy uses: aquasecurity/trivy-action@master with: image-ref: gcr.io/${{ env.PROJECT_ID }}/web-app:${{ github.sha }} exit-code: '1' # 脆弱性が見つかればビルドを失敗させる ignore-unfixed: true |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
# Prometheus の ServiceMonitor 例（GKE 用） apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: web-app-monitor spec: selector: matchLabels: app: web endpoints: - port: http-metrics interval: 30s |
- アラート – Grafana の Alerting 機能で CPU 使用率 > 80% や Pod 再起動数が一定閾値を超えた場合に通知します。
トラブルシューティングとロギングのポイント
障害発生時は kubectl とクラウド提供の統合ログサービスを併用すると迅速に原因特定できます。
kubectl describe pod <pod>– イベント情報やスケジューリング失敗理由が確認できる。kubectl logs -p <pod>– 再起動したコンテナの過去ログを取得可能。- Azure Monitor / Google Cloud Operations – クラスタレベルのメトリクス・分散トレーシングを一元化。
共通エラー例
-ImagePullBackOff→ イメージ名やタグがリポジトリと不一致、または認証情報が不足している。
-RBAC: forbidden→ ServiceAccount に必要な RoleBinding が付与されていない。
これらは CI のシークレット注入や RoleBinding 定義で事前に防げます。
まとめ
本稿では、Kubernetes の基本概念から宣言的デプロイ、CI/CD・GitOps の全体像、主要クラウド（AKS・GKE）向けの自動デプロイ手法、そしてマルチクラウド環境で共通に適用できるベストプラクティスまでを網羅しました。
- 宣言的マニフェスト を Git で管理し、Control Plane が常に期待状態へ収束させます。
- GitOps によってインフラ変更がコードレビューと同様のプロセスで行われ、監査性・ロールバックが容易になります。
- Azure DevOps Pipelines / GitHub Actions は OIDC と Key Vault／Secrets の組み合わせで認証情報を安全に扱い、AKS へのデプロイを自動化します。
- Google Cloud Deploy + Skaffold は GKE 向けにステージング→本番の段階的リリースとローカル開発フローを統一し、開発者体験を向上させます。
- Terraform と CI の連携 によりインフラもアプリケーション同様にコード化し、マルチクラウドのプロビジョニングを一本化できます。
- ブルーグリーン／カナリア戦略、イメージスキャン、Prometheus/Grafana 監視 を標準装備すれば、本番環境の安定性とセキュリティが格段に向上します。
これらの手順とベストプラクティスを参考に、今すぐ マルチクラウド対応の Kubernetes デプロイパイプライン を構築し、継続的デリバリーの高速化と信頼性向上を実現してください。