xDev Asia

HelmパッケージマネージャーArgo CDによるGitOps、KubernetesのCI/CDパイプライン。デプロイ戦略：ローリングアップデート、カナリア、ブルーグリーン。

1. Helm — Kubernetesパッケージマネージャー

HelmはKubernetes用のパッケージマネージャーです。ChartはYAMLテンプレートで、再利用とパラメータ化が可能です。

Helm Concepts:
  Chart     = Package (templates + default values)
  Release   = Installed instance of a chart in a cluster
  Repository = Collection of charts (ArtifactHub.io)
  Values    = Parameters to customize a chart

$ helm install my-nginx bitnami/nginx --set service.type=LoadBalancer
  └── Release: my-nginx
      ├── templates/deployment.yaml
      ├── templates/service.yaml
      └── values.yaml (overridden)

Helmコマンド	機能
`helm install`	新しいChartをデプロイ（Releaseを作成）
`helm upgrade`	新しいChart/Valuesでリリースを更新
`helm rollback`	以前のリビジョンに復元
`helm list`	すべてのリリースを一覧表示
`helm uninstall`	リリースを削除
`helm template`	デプロイせずにテンプレートをレンダリング

試験のポイント： HelmはリリースヒストリをKubernetes Secrets（ConfigMapではない）に保存します。これによりhelm rollbackが機能します。デフォルトで10リビジョンのヒストリを保持します。

2. GitOps

GitOpsはGitをコードとインフラ設定の両方の唯一の信頼できるソース（Single Source of Truth）として使用するオペレーションフレームワークです。

GitOps Flow:
  Developer ──push──► Git Repo (desired state)
                          │
                    GitOps Operator (Argo CD / Flux)
                    - Watches Git repo
                    - Compares with cluster state
                    - Syncs if diff found
                          │
                       K8s Cluster (actual state)

GitOpsの原則	意味
Declarative	システム状態をGit内のYAMLで記述
Versioned & immutable	Gitヒストリ = 監査証跡
Pulled automatically	エージェントが変更をプル、クラスターへのpushアクセス不要
Continuously reconciled	ドリフト検出 — クラスターがGitと異なる場合に自動修正

Argo CD

Argo CDはKubernetesで最も人気のあるGitOpsコントローラーです（CNCF Incubating → Graduated 2022）。

試験のポイント： GitOpsはpushではなくプルベースのデプロイを使用します。利点：クラスターがAPIを外部に公開する必要がなく、CIパイプラインにkubeconfig資格情報が不要です。

3. KubernetesのCI/CD

CI/CD Pipeline:
  Code Push
      │
  ┌───▼───┐  CI Phase (Build)
  │ Build  │── Unit tests ── Integration tests
  │ Image  │── Security scan (Trivy, Snyk)
  └───┬───┘── Push to Registry (ECR, GCR)
      │
  ┌───▼───┐  CD Phase (Deploy)
  │ Update │── Update Helm values / K8s manifest
  │ Manifest│── Push to GitOps repo
  └───┬───┘── Argo CD picks up and syncs
      │
  ┌───▼────────────────────┐
  │ Kubernetes Cluster     │
  │  Rolling Update        │
  └────────────────────────┘

4. デプロイ戦略

戦略	動作方法	ダウンタイム	ロールバック	使用場面
Rolling Update	Podを段階的に置換（デフォルト）	なし	kubectl rollout undo	ステートレスアプリ、段階的
Recreate	v1を全停止後にv2をデプロイ	あり	v1を再デプロイ	破壊的変更、シンプル
Blue-Green	v1（Blue）とv2（Green）を並行稼働し、トラフィックを切り替え	なし	即座に切り戻し	重要なアプリ、高速ロールバック
Canary	トラフィックの少量%を新バージョンにルーティング	なし	トラフィックをリダイレクト	段階的ロールアウト、A/Bテスト

Canary in Kubernetes (Ingress weight):
  ┌─────────────────────────────────┐
  │  Ingress (canary annotation)     │
  │  90% ──────► Deployment v1.0    │
  │  10% ──────► Deployment v1.1    │
  └─────────────────────────────────┘
  → Monitor v1.1 errors → promote to 100% or rollback

5. チートシート

試験の質問	回答
Helmはリリースヒストリをどこに保存する？	Kubernetes Secrets
GitOpsの唯一の信頼できるソースは？	Gitリポジトリ
GitOpsはプルベースかプッシュベースか？	プルベース（エージェントがプル）
ダウンタイムなしのデプロイは？	RollingまたはBlue-Green
5%のトラフィックで新バージョンをテストするには？	Canaryデプロイ
問題発生時の高速ロールバックは？	Blue-Green（即座に切り替え）

6. 練習問題

Q1: チームがアプリの新バージョンをまず10%のユーザーにデプロイし、エラーを監視してから徐々にトラフィックを増やしたいと考えています。どのデプロイ戦略を使用すべきですか？

A) Recreate
B) Rolling Update
C) Blue-Green
D) Canary ✓

解説：Canaryデプロイはトラフィックの少量を新バージョンにルーティングし、完全ロールアウト前に実際のトラフィックで検証できます。これにより新バージョンにバグがある場合の影響範囲を最小限に抑えます。

Q2: GitOpsモデルを最もよく説明しているのはどれですか？

A) CI/CDパイプラインがテスト通過後にKubernetesに直接プッシュする
B) Gitリポジトリが唯一の信頼できるソースであり、コントローラーがクラスター状態をGitと継続的に照合する ✓
C) 開発者がワークステーションから手動でkubectlコマンドを適用する
D) インフラストラクチャが一貫性のためにリレーショナルデータベースで定義される

解説：GitOpsはコントローラー（Argo CD、Flux）がGitリポジトリを監視し、クラスターがGitで宣言された内容と一致することを保証するプルベースモデルを使用します。これにより監査証跡、ドリフト検出、安全なデプロイが提供されます。

Q3: Helmはロールバック機能を有効にするためにリリースヒストリをどこに保存しますか？

A) Helmのローカルファイルシステム（~/.helm）
B) ターゲットnamespace内のConfigMap
C) ターゲットnamespace内のSecret ✓
D) 別のetcdデータベース

解説：Helm v3以降、リリースメタデータ（ヒストリ、値、チャート情報）はリリースのnamespace内のSecretsとして保存されます。これにより前のリビジョンデータを読み取ることでhelm rollbackが可能になり、複数のユーザー/システムが同じリリースを管理できます。