GitOps 2025 - Kubernetesデプロイの標準手法

GitOpsとは何か

GitOpsは、Gitリポジトリを「Single Source of Truth（唯一の信頼できる情報源）」として、インフラストラクチャとアプリケーションのデプロイメントを管理する運用モデルです。2017年にWeaveworks社によって提唱されたこの概念は、2025年現在、Kubernetes環境におけるデプロイメントの事実上の標準となっています。

従来のCI/CDパイプラインでは、CIツールがクラスターに直接プッシュする「Push型」のデプロイが主流でした。一方、GitOpsでは、クラスター内のエージェントがGitリポジトリを監視し、変更を検知して自動的に同期する「Pull型」のアプローチを採用します。

GitOpsの4つの原則

1. 宣言的構成（Declarative）

システムの望ましい状態を宣言的に記述します。Kubernetesマニフェスト、Helmチャート、Kustomizeなどを使用して、インフラストラクチャをコードとして定義します。

# deployment.yaml - 宣言的な状態定義
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-application
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-application
  template:
    metadata:
      labels:
        app: web-application
    spec:
      containers:
      - name: app
        image: myregistry/web-app:v2.1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10

2. バージョン管理（Versioned and Immutable）

すべての構成変更はGitにコミットされ、完全な変更履歴が保持されます。これにより、監査証跡の確保、ロールバックの容易化、変更の追跡が可能になります。

3. 自動適用（Pulled Automatically）

承認された変更は自動的にシステムに適用されます。手動での介入は不要で、人的ミスのリスクを大幅に削減できます。

4. 継続的調整（Continuously Reconciled）

エージェントは常にクラスターの実際の状態とGitリポジトリの望ましい状態を比較し、ドリフト（乖離）を検出して自動的に修正します。

ArgoCD vs Flux CD：主要ツールの比較

2025年現在、GitOpsツールの二大巨頭はArgoCDとFlux CDです。それぞれの特徴を詳しく見ていきましょう。

ArgoCD

ArgoCDは、CNCF（Cloud Native Computing Foundation）の卒業プロジェクトであり、豊富なUIと直感的な操作性が特徴です。

# ArgoCD Application定義
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: web-application
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/kubernetes-manifests
    targetRevision: main
    path: apps/web-application
    helm:
      valueFiles:
        - values-production.yaml
      parameters:
        - name: image.tag
          value: "v2.1.0"
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
      allowEmpty: false
    syncOptions:
      - CreateNamespace=true
      - PrunePropagationPolicy=foreground
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

ArgoCDの主な特徴:

• リッチなWeb UIとCLI
• Application of Applications パターンのサポート
• 複数のマニフェスト形式対応（Helm、Kustomize、Jsonnet、plain YAML）
• RBAC（役割ベースアクセス制御）の詳細な設定
• SSO統合（OIDC、SAML、LDAP）
• マルチテナンシー対応

Flux CD

Flux CDは、よりKubernetesネイティブなアプローチを採用し、CRD（Custom Resource Definitions）を活用したモジュラーな設計が特徴です。

# Flux GitRepository定義
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: web-application
  namespace: flux-system
spec:
  interval: 1m
  url: https://github.com/myorg/kubernetes-manifests
  ref:
    branch: main
  secretRef:
    name: git-credentials
---
# Flux Kustomization定義
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: web-application
  namespace: flux-system
spec:
  interval: 10m
  targetNamespace: production
  sourceRef:
    kind: GitRepository
    name: web-application
  path: ./apps/web-application
  prune: true
  healthChecks:
    - apiVersion: apps/v1
      kind: Deployment
      name: web-application
      namespace: production
  timeout: 3m
  retryInterval: 2m

Flux CDの主な特徴:

• Kubernetes CRDベースの設計
• 軽量でモジュラーなアーキテクチャ
• イメージ自動更新機能（Image Automation Controller）
• 通知システム（Notification Controller）
• OCI（Open Container Initiative）レジストリサポート
• Terraformとの統合

比較表

実装パターン

パターン1: Mono-repoアプローチ

すべての環境のマニフェストを単一のリポジトリで管理します。

kubernetes-manifests/
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
├── overlays/
│   ├── development/
│   │   ├── kustomization.yaml
│   │   └── patches/
│   │       └── replicas.yaml
│   ├── staging/
│   │   ├── kustomization.yaml
│   │   └── patches/
│   │       └── replicas.yaml
│   └── production/
│       ├── kustomization.yaml
│       └── patches/
│           ├── replicas.yaml
│           └── resources.yaml
└── apps/
    ├── app-a/
    ├── app-b/
    └── app-c/

# overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: production
resources:
  - ../../base
patches:
  - path: patches/replicas.yaml
  - path: patches/resources.yaml
images:
  - name: myregistry/web-app
    newTag: v2.1.0

パターン2: Multi-repoアプローチ

アプリケーションコードとインフラ構成を別々のリポジトリで管理します。

# ArgoCD ApplicationSet for Multi-repo
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: cluster-apps
  namespace: argocd
spec:
  generators:
    - git:
        repoURL: https://github.com/myorg/app-of-apps
        revision: main
        directories:
          - path: apps/*
  template:
    metadata:
      name: '{{path.basename}}'
    spec:
      project: default
      source:
        repoURL: 'https://github.com/myorg/{{path.basename}}-manifests'
        targetRevision: main
        path: overlays/production
      destination:
        server: https://kubernetes.default.svc
        namespace: '{{path.basename}}'
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

パターン3: Progressive Delivery

ArgoCDのRolloutsやFlaggerを使用した段階的デプロイメント。

# Argo Rollouts - Canary Deployment
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: web-application
  namespace: production
spec:
  replicas: 10
  selector:
    matchLabels:
      app: web-application
  template:
    metadata:
      labels:
        app: web-application
    spec:
      containers:
      - name: app
        image: myregistry/web-app:v2.1.0
        ports:
        - containerPort: 8080
  strategy:
    canary:
      steps:
      - setWeight: 10
      - pause: {duration: 5m}
      - setWeight: 30
      - pause: {duration: 5m}
      - setWeight: 50
      - pause: {duration: 5m}
      - setWeight: 80
      - pause: {duration: 5m}
      analysis:
        templates:
        - templateName: success-rate
        startingStep: 1
        args:
        - name: service-name
          value: web-application
---
# Analysis Template
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  args:
  - name: service-name
  metrics:
  - name: success-rate
    interval: 1m
    successCondition: result[0] >= 0.95
    failureLimit: 3
    provider:
      prometheus:
        address: http://prometheus.monitoring:9090
        query: |
          sum(rate(http_requests_total{service="{{args.service-name}}",status=~"2.*"}[5m])) /
          sum(rate(http_requests_total{service="{{args.service-name}}"}[5m]))

マルチクラスター管理

ArgoCD ApplicationSet

複数のクラスターに対して一貫したデプロイメントを実現します。

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: multi-cluster-app
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            environment: production
        values:
          revision: main
    - clusters:
        selector:
          matchLabels:
            environment: staging
        values:
          revision: develop
  template:
    metadata:
      name: '{{name}}-web-app'
    spec:
      project: default
      source:
        repoURL: https://github.com/myorg/kubernetes-manifests
        targetRevision: '{{values.revision}}'
        path: apps/web-application
        helm:
          valueFiles:
            - 'values-{{metadata.labels.environment}}.yaml'
      destination:
        server: '{{server}}'
        namespace: web-application
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

Flux マルチテナンシー

# Flux Multi-tenancy構成
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: tenants
  namespace: flux-system
spec:
  interval: 10m
  sourceRef:
    kind: GitRepository
    name: flux-system
  path: ./tenants
  prune: true
  patches:
    - patch: |
        - op: add
          path: /spec/serviceAccountName
          value: tenant-reconciler
      target:
        kind: Kustomization
        labelSelector: tenant=true

セキュリティ考慮点

1. シークレット管理

GitOpsでは、シークレットをGitリポジトリに直接保存することは避けるべきです。以下のソリューションを検討してください。

# Sealed Secrets
apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: database-credentials
  namespace: production
spec:
  encryptedData:
    username: AgBy3i4OJSWK+PiTySYZZA9rO43cGDEq...
    password: AgBy3i4OJSWK+PiTySYZZA9rO43cGDEq...
  template:
    type: Opaque
    metadata:
      name: database-credentials
      namespace: production
---
# External Secrets Operator
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
  namespace: production
spec:
  refreshInterval: 1h
  secretStoreRef:
    kind: ClusterSecretStore
    name: aws-secrets-manager
  target:
    name: database-credentials
    creationPolicy: Owner
  data:
    - secretKey: username
      remoteRef:
        key: production/database
        property: username
    - secretKey: password
      remoteRef:
        key: production/database
        property: password

2. RBAC設定

# ArgoCD Project with RBAC
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: production-apps
  namespace: argocd
spec:
  description: Production applications
  sourceRepos:
    - 'https://github.com/myorg/*'
  destinations:
    - namespace: 'production-*'
      server: https://kubernetes.default.svc
  clusterResourceWhitelist:
    - group: ''
      kind: Namespace
  namespaceResourceBlacklist:
    - group: ''
      kind: ResourceQuota
    - group: ''
      kind: LimitRange
  roles:
    - name: developer
      description: Developer access
      policies:
        - p, proj:production-apps:developer, applications, get, production-apps/*, allow
        - p, proj:production-apps:developer, applications, sync, production-apps/*, allow
      groups:
        - developers

3. ネットワークポリシー

# GitOpsツール用NetworkPolicy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: argocd-network-policy
  namespace: argocd
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/part-of: argocd
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: ingress-nginx
      ports:
        - protocol: TCP
          port: 8080
  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
      ports:
        - protocol: TCP
          port: 443
        - protocol: TCP
          port: 22

4. 監査ログと監視

# ArgoCD Notifications
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-notifications-cm
  namespace: argocd
data:
  service.slack: |
    token: $slack-token
  template.app-sync-status: |
    message: |
      Application {{.app.metadata.name}} sync status: {{.app.status.sync.status}}
      Health: {{.app.status.health.status}}
      Revision: {{.app.status.sync.revision}}
  trigger.on-sync-status-unknown: |
    - when: app.status.sync.status == 'Unknown'
      send: [app-sync-status]
  trigger.on-health-degraded: |
    - when: app.status.health.status == 'Degraded'
      send: [app-sync-status]

2025年の動向

1. AI/ML統合

GitOps環境におけるAI/ML統合が進んでいます。異常検知、自動スケーリング推奨、デプロイメントリスク予測などにAIが活用されています。

# AI-powered Analysis Template
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: ai-anomaly-detection
spec:
  metrics:
  - name: anomaly-score
    interval: 2m
    successCondition: result < 0.7
    provider:
      web:
        url: "http://ml-service.ai-ops:8080/analyze"
        jsonPath: "{$.anomaly_score}"
        headers:
          - key: Content-Type
            value: application/json

2. Policy as Code

Open Policy Agent（OPA）やKyvernoとの統合が標準化されています。

# Kyverno Policy for GitOps
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-gitops-labels
spec:
  validationFailureAction: enforce
  background: true
  rules:
  - name: check-gitops-labels
    match:
      any:
      - resources:
          kinds:
          - Deployment
          - StatefulSet
    validate:
      message: "All deployments must have GitOps labels"
      pattern:
        metadata:
          labels:
            argocd.argoproj.io/instance: "?*"
            app.kubernetes.io/managed-by: "argocd"

3. プラットフォームエンジニアリング

Internal Developer Platform（IDP）の構築においてGitOpsが中心的な役割を果たしています。

# Backstage Integration with ArgoCD
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: web-application
  annotations:
    argocd/app-name: web-application
    github.com/project-slug: myorg/web-application
spec:
  type: service
  lifecycle: production
  owner: platform-team
  system: e-commerce
  dependsOn:
    - resource:default/postgres-database
    - resource:default/redis-cache

4. サステナビリティ

環境負荷を考慮したデプロイメント戦略が重要視されています。

# Carbon-aware Scheduling
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: carbon-aware-app
  annotations:
    sustainability.io/carbon-intensity-threshold: "200"
    sustainability.io/preferred-regions: "eu-north-1,us-west-2"
spec:
  # 低炭素地域への優先デプロイ

まとめ

GitOpsは2025年において、Kubernetesデプロイメントの標準的なアプローチとして確立されています。ArgoCDとFlux CDはそれぞれ異なる強みを持ち、組織のニーズに応じて選択できます。

重要なポイントは以下の通りです：

1. 宣言的な構成管理: すべてのインフラをコードとして管理
2. 自動化された同期: 手動作業を最小化し、一貫性を確保
3. 監査可能性: Gitの履歴がすべての変更を追跡
4. セキュリティ: シークレット管理とRBACの適切な設計
5. スケーラビリティ: マルチクラスター、マルチテナンシーへの対応

GitOpsを導入することで、開発チームはより迅速かつ安全にアプリケーションをデプロイし、運用の効率化と信頼性の向上を実現できます。2025年以降も、AI統合やサステナビリティといった新しい要素を取り込みながら、GitOpsはさらに進化していくでしょう。