▣ アプリ開発/2026-03-29上級

Antigravity × Kubernetes コンテナオーケストレーション — AIエージェントでクラウドネイティブ基盤を設計・運用する

Antigravity の AI エージェントを活用して Kubernetes マニフェスト生成、Helm チャート設計、デプロイ戦略、オートスケーリング、障害復旧までを体系的に解説するプレミアムガイドです。

antigravity⁴³⁵ kubernetes container cloud-native devops⁴ helm deployment⁵

取り組みの背景 — なぜ Kubernetes × AI IDE なのか

Kubernetes（K8s）はコンテナオーケストレーションのデファクトスタンダードとして、マイクロサービスアーキテクチャを支える中核技術です。しかし、その設定ファイルの複雑さは多くの開発者にとってハードルとなっています。YAML マニフェストの記述ミス、リソース設定の不備、ネットワークポリシーの見落としなど、Kubernetes の運用には膨大な知識と経験が求められます。

Antigravity の AI エージェントは、この複雑さを劇的に軽減します。自然言語で「3レプリカの Node.js アプリをデプロイして、HPA でスケーリングを設定して」と指示するだけで、本番品質のマニフェストを生成できるのです。ここで扱うのはAntigravity を活用した Kubernetes 開発の実践パターンを、基盤設計からプロダクション運用まで体系的に解説します。

この記事は以下の方を対象としています。

Kubernetes の基本概念は理解しているが、本番運用の設計パターンに不安がある方
マニフェストの記述を効率化し、AI と協調した Infrastructure as Code を実践したい方
Antigravity のマルチエージェント機能を活用してクラウドネイティブ開発を加速したい方

なお、Antigravity × Docker の基本的なコンテナ開発については「Docker × Antigravity で再現性のある開発環境を構築する完全ガイド」を、Dev Containers との連携については「Antigravity × Dev Containers で完全再現可能なAI開発環境を構築する」をあわせてご覧ください。

Kubernetes マニフェストの AI 自動生成 — 基本パターン

Antigravity のエージェントに Kubernetes マニフェストを生成させる際、最も重要なのは「コンテキストの提供」です。単に「Deployment を作って」と指示するだけでは汎用的なテンプレートが返ってきますが、プロジェクトの要件を具体的に伝えることで、本番品質のマニフェストが得られます。

Deployment + Service の生成

まず、基本的な Deployment と Service の生成パターンを見てみましょう。Antigravity のチャットパネルで以下のようにプロンプトを入力します。

# Antigravity が生成した Deployment マニフェスト
# プロンプト: "Node.js APIサーバーの Deployment を作成。
#   ポート3000、レプリカ3、リソース制限あり、
#   ヘルスチェック付きで本番向けに"
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  labels:
    app: api-server
    environment: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-server
  template:
    metadata:
      labels:
        app: api-server
        version: v1
    spec:
      containers:
        - name: api-server
          image: gcr.io/my-project/api-server:latest
          ports:
            - containerPort: 3000
              protocol: TCP
          # リソース制限（本番推奨値）
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          # Liveness Probe: コンテナが生存しているか
          livenessProbe:
            httpGet:
              path: /healthz
              port: 3000
            initialDelaySeconds: 15
            periodSeconds: 10
            failureThreshold: 3
          # Readiness Probe: トラフィックを受け入れ可能か
          readinessProbe:
            httpGet:
              path: /ready
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 5
          # Startup Probe: 起動完了を待つ
          startupProbe:
            httpGet:
              path: /healthz
              port: 3000
            failureThreshold: 30
            periodSeconds: 2
          env:
            - name: NODE_ENV
              value: "production"
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: api-secrets
                  key: database-url
      # Pod の安全な終了を保証
      terminationGracePeriodSeconds: 30

ここで注目すべきは、Antigravity が単なるテンプレートではなく、livenessProbe・readinessProbe・startupProbe の3種類のヘルスチェック、リソース制限、Secret 参照、graceful shutdown 設定まで含めた本番品質のマニフェストを生成している点です。

マニフェストの検証と最適化

生成されたマニフェストは、Antigravity のターミナルで即座に検証できます。

# マニフェストの構文チェック
kubectl apply --dry-run=client -f k8s/deployment.yaml
 
# kubeconform による詳細バリデーション
# （スキーマに基づく厳密な検証）
kubeconform -strict -summary k8s/deployment.yaml
 
# 期待出力:
# Summary: 1 resource found parsing "k8s/deployment.yaml" - Valid: 1, Invalid: 0, Errors: 0, Skipped: 0

Antigravity エージェントにバリデーション結果を共有すると、問題点の修正提案やベストプラクティスへの改善を自動的に行ってくれます。

Helm チャート設計 — 再利用可能なパッケージング

本番環境では、素の YAML マニフェストではなく Helm チャートとしてパッケージングすることが一般的です。Antigravity は Helm チャートの生成も得意としています。

チャート構造の自動生成

# Antigravity のターミナルから Helm チャートの雛形を作成
helm create my-api-chart
 
# 生成されるディレクトリ構造
# my-api-chart/
# ├── Chart.yaml        # チャートのメタデータ
# ├── values.yaml       # デフォルト設定値
# ├── templates/
# │   ├── deployment.yaml
# │   ├── service.yaml
# │   ├── ingress.yaml
# │   ├── hpa.yaml
# │   ├── serviceaccount.yaml
# │   └── _helpers.tpl   # テンプレートヘルパー
# └── charts/            # 依存チャート

values.yaml のカスタマイズ

Antigravity エージェントに「本番環境・ステージング環境・開発環境の3つの values ファイルを作って」と指示すると、環境ごとの差分を正確に反映した設定ファイルを生成します。

# values-production.yaml
# Antigravity が生成した本番環境用の設定
replicaCount: 3
 
image:
  repository: gcr.io/my-project/api-server
  tag: "1.2.0"
  pullPolicy: IfNotPresent
 
resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
  limits:
    cpu: "1000m"
    memory: "1Gi"
 
autoscaling:
  enabled: true
  minReplicas: 3
  maxReplicas: 10
  targetCPUUtilizationPercentage: 70
  targetMemoryUtilizationPercentage: 80
 
ingress:
  enabled: true
  className: "nginx"
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    nginx.ingress.kubernetes.io/rate-limit: "100"
  hosts:
    - host: api.example.com
      paths:
        - path: /
          pathType: Prefix
  tls:
    - secretName: api-tls
      hosts:
        - api.example.com
 
# Pod Disruption Budget（可用性保証）
podDisruptionBudget:
  enabled: true
  minAvailable: 2
 
# ネットワークポリシー
networkPolicy:
  enabled: true
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: ingress-nginx

この設定には PodDisruptionBudget によるローリングアップデート時の可用性保証、NetworkPolicy によるゼロトラスト設計、cert-manager との連携による自動TLS証明書管理が含まれています。これらは Antigravity に「本番環境のベストプラクティスに従って」と指示するだけで自動的に追加されます。

デプロイ戦略 — ローリングアップデートからカナリアリリースまで

デプロイ戦略の選択は、サービスの可用性とリリース速度のバランスを決定する重要な設計判断です。Antigravity はプロジェクトの要件に応じた最適な戦略を提案してくれます。

ローリングアップデート（標準）

# ローリングアップデート戦略
# 段階的にPodを入れ替え、ダウンタイムゼロを実現
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # 一度に追加できるPod数
      maxUnavailable: 0   # 同時に停止できるPod数（0 = ダウンタイムなし）

カナリアデプロイ（段階的リリース）

本番環境への新バージョンのリリースで最もリスクを低減できるのがカナリアデプロイです。Antigravity で Argo Rollouts を使ったカナリアデプロイを実装しましょう。

# Argo Rollouts を使用したカナリアデプロイ
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: api-server
spec:
  replicas: 5
  strategy:
    canary:
      # ステップ1: 20%のトラフィックを新バージョンに
      steps:
        - setWeight: 20
        - pause: { duration: 5m }
        # ステップ2: メトリクスを自動分析
        - analysis:
            templates:
              - templateName: success-rate
            args:
              - name: service-name
                value: api-server
        # ステップ3: 問題なければ50%に増加
        - setWeight: 50
        - pause: { duration: 10m }
        # ステップ4: 全トラフィックを新バージョンに
        - setWeight: 100
      # 自動ロールバック条件
      canaryMetadata:
        labels:
          role: canary
      stableMetadata:
        labels:
          role: stable
---
# カナリア分析テンプレート
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  metrics:
    - name: success-rate
      # Prometheus からメトリクスを取得
      interval: 30s
      successCondition: result[0] >= 0.95
      failureLimit: 3
      provider:
        prometheus:
          address: http://prometheus-server.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]))

このカナリアデプロイ設定では、新バージョンへのトラフィックを20%→50%→100%と段階的に増加させ、各ステップで Prometheus メトリクスに基づく自動分析を実行します。成功率が95%を下回った場合は自動的にロールバックされます。

HPA によるオートスケーリング設計

本番環境では、トラフィックの変動に応じて Pod 数を自動調整する Horizontal Pod Autoscaler（HPA）が不可欠です。

基本的な CPU/メモリベースのスケーリング

# HPA マニフェスト（CPU + メモリのマルチメトリクス）
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-server-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 3
  maxReplicas: 20
  metrics:
    # CPU 使用率ベース
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    # メモリ使用率ベース
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80
  behavior:
    # スケールアップ: 迅速に対応
    scaleUp:
      stabilizationWindowSeconds: 60
      policies:
        - type: Pods
          value: 4
          periodSeconds: 60
        - type: Percent
          value: 100
          periodSeconds: 60
      selectPolicy: Max
    # スケールダウン: 慎重に実行
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Pods
          value: 1
          periodSeconds: 120
      selectPolicy: Min

カスタムメトリクスによる高度なスケーリング

リクエストキューの深さや処理レイテンシなど、ビジネスロジックに基づいたスケーリングも実装できます。

# カスタムメトリクスによるスケーリング
# Prometheus Adapter を使用してキューの深さでスケール
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: worker-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: queue-worker
  minReplicas: 2
  maxReplicas: 50
  metrics:
    - type: Object
      object:
        describedObject:
          apiVersion: v1
          kind: Service
          name: rabbitmq
        metric:
          name: queue_messages_ready
        target:
          type: Value
          value: "100"  # キューに100メッセージ溜まるごとにスケール

Antigravity にアプリケーションのトラフィックパターン（たとえば「平日9-18時にピークがあり、夜間はほぼゼロ」）を伝えると、そのパターンに最適化されたスケーリング設定を提案してくれます。

セキュリティ設計 — ゼロトラストの実装

Kubernetes のセキュリティは多層防御が基本です。Antigravity を使って、Pod レベルからクラスタレベルまでのセキュリティ設定を構築しましょう。

Pod Security Standards の適用

# Pod Security Context（最小権限の原則）
spec:
  template:
    spec:
      securityContext:
        # root ユーザーでの実行を禁止
        runAsNonRoot: true
        runAsUser: 1000
        runAsGroup: 3000
        fsGroup: 2000
        # seccomp プロファイル
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: api-server
          securityContext:
            # 権限昇格を禁止
            allowPrivilegeEscalation: false
            # 読み取り専用ルートファイルシステム
            readOnlyRootFilesystem: true
            # すべての Linux Capabilities を除去
            capabilities:
              drop:
                - ALL
          # 書き込みが必要なパスだけ tmpfs でマウント
          volumeMounts:
            - name: tmp-dir
              mountPath: /tmp
            - name: cache-dir
              mountPath: /app/.cache
      volumes:
        - name: tmp-dir
          emptyDir:
            medium: Memory
            sizeLimit: "64Mi"
        - name: cache-dir
          emptyDir:
            sizeLimit: "128Mi"

NetworkPolicy によるゼロトラスト通信

# NetworkPolicy: API サーバーへのアクセスを制限
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-server-netpol
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-server
  policyTypes:
    - Ingress
    - Egress
  ingress:
    # Ingress Controller からのみ受信を許可
    - from:
        - namespaceSelector:
            matchLabels:
              name: ingress-nginx
        - podSelector:
            matchLabels:
              app: ingress-nginx
      ports:
        - protocol: TCP
          port: 3000
  egress:
    # データベースへの接続のみ許可
    - to:
        - podSelector:
            matchLabels:
              app: postgresql
      ports:
        - protocol: TCP
          port: 5432
    # DNS 解決を許可
    - to:
        - namespaceSelector: {}
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

このようなゼロトラスト設計を手動で書くのは非常に手間がかかりますが、Antigravity に「このサービスの通信要件は DB アクセスのみ。Ingress 経由でのみ外部リクエストを受ける」と伝えるだけで、適切な NetworkPolicy を生成してくれます。

障害復旧とオブザーバビリティ — 運用を見据えた設計

Kubernetes クラスタの安定運用には、障害の検知・対応・復旧を自動化する仕組みが欠かせません。

Prometheus + Grafana モニタリングスタック

# Antigravity のターミナルで kube-prometheus-stack をインストール
helm repo add prometheus-community \
  https://prometheus-community.github.io/helm-charts
helm repo update
 
helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set grafana.adminPassword=YOUR_GRAFANA_PASSWORD \
  --set prometheus.prometheusSpec.retention=30d \
  --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.resources.requests.storage=50Gi
 
# 期待出力:
# NAME: monitoring
# STATUS: deployed
# NOTES: kube-prometheus-stack has been installed.

アラートルールの設計

# PrometheusRule: Pod の異常検知
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: api-server-alerts
  namespace: monitoring
spec:
  groups:
    - name: api-server.rules
      rules:
        # 高エラーレート検知
        - alert: HighErrorRate
          expr: |
            sum(rate(http_requests_total{
              service="api-server",
              status=~"5.."
            }[5m])) /
            sum(rate(http_requests_total{
              service="api-server"
            }[5m])) > 0.05
          for: 2m
          labels:
            severity: critical
          annotations:
            summary: "API サーバーのエラーレートが 5% を超過"
            description: "過去5分間のエラーレートが {{ $value | humanizePercentage }} です"
 
        # Pod 再起動の異常検知
        - alert: PodCrashLooping
          expr: |
            rate(kube_pod_container_status_restarts_total{
              namespace="production"
            }[15m]) * 60 * 15 > 3
          for: 5m
          labels:
            severity: warning
          annotations:
            summary: "Pod {{ $labels.pod }} が頻繁に再起動しています"
 
        # レイテンシの異常検知
        - alert: HighLatency
          expr: |
            histogram_quantile(0.99,
              sum(rate(http_request_duration_seconds_bucket{
                service="api-server"
              }[5m])) by (le)
            ) > 2
          for: 5m
          labels:
            severity: warning
          annotations:
            summary: "API の P99 レイテンシが 2秒を超過しています"

Antigravity にアプリケーションの SLO（Service Level Objectives）を伝えると、その目標値に基づいたアラートルールを自動生成できます。たとえば「可用性 99.9%、P99 レイテンシ 500ms 以内」と指示すれば、エラーバジェットの消費率を監視するアラートまで含めて設計してくれます。

CI/CD パイプラインとの統合 — GitOps ワークフロー

Kubernetes への継続的デリバリーは、GitOps パターンで実現するのがベストプラクティスです。Antigravity を使って ArgoCD ベースの GitOps パイプラインを構築しましょう。

CI/CD パイプラインの基本設計については「GitHub Actions × Antigravity CI/CD 自動化ガイド」も参考になります。

ArgoCD Application の定義

# ArgoCD Application マニフェスト
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: api-server
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/my-org/k8s-manifests.git
    targetRevision: main
    path: apps/api-server/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true       # Git から削除されたリソースを自動削除
      selfHeal: true     # ドリフト検出時に自動修復
    syncOptions:
      - CreateNamespace=true
      - ServerSideApply=true
    retry:
      limit: 5
      backoff:
        duration: "5s"
        factor: 2
        maxDuration: "3m"

Kustomize によるマルチ環境管理

# ディレクトリ構造
# apps/api-server/
# ├── base/
# │   ├── kustomization.yaml
# │   ├── deployment.yaml
# │   ├── service.yaml
# │   └── hpa.yaml
# ├── overlays/
# │   ├── development/
# │   │   ├── kustomization.yaml
# │   │   └── patches/
# │   ├── staging/
# │   │   ├── kustomization.yaml
# │   │   └── patches/
# │   └── production/
# │       ├── kustomization.yaml
# │       └── patches/

# overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: production
resources:
  - ../../base
 
patches:
  # 本番用のレプリカ数とリソースを上書き
  - target:
      kind: Deployment
      name: api-server
    patch: |-
      - op: replace
        path: /spec/replicas
        value: 5
      - op: replace
        path: /spec/template/spec/containers/0/resources/requests/cpu
        value: "500m"
      - op: replace
        path: /spec/template/spec/containers/0/resources/requests/memory
        value: "512Mi"
      - op: replace
        path: /spec/template/spec/containers/0/resources/limits/cpu
        value: "1000m"
      - op: replace
        path: /spec/template/spec/containers/0/resources/limits/memory
        value: "1Gi"
 
commonLabels:
  environment: production
  managed-by: argocd

Antigravity の強みは、このような多層的な設定構造を一度に生成できる点です。「Kustomize で dev/staging/production の3環境を管理する構成を作って。本番はレプリカ5、リソース多め、ネットワークポリシーあり」と指示するだけで、ベースとオーバーレイの完全な構成が出力されます。

コスト最適化 — リソースの無駄を排除する

クラウド環境では、Kubernetes のリソース設定が直接コストに影響します。Antigravity を使ったコスト最適化の実践パターンを紹介します。

Vertical Pod Autoscaler（VPA）による適正リソース分析

# VPA で実際のリソース消費を分析
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: api-server-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  # まず「推奨値を観察するだけ」モードで運用
  updatePolicy:
    updateMode: "Off"
  resourcePolicy:
    containerPolicies:
      - containerName: api-server
        minAllowed:
          cpu: "100m"
          memory: "128Mi"
        maxAllowed:
          cpu: "2"
          memory: "4Gi"

# VPA の推奨値を確認
kubectl describe vpa api-server-vpa
 
# 期待出力例:
# Recommendation:
#   Container Recommendations:
#     Container Name: api-server
#     Lower Bound:
#       Cpu:     125m
#       Memory:  200Mi
#     Target:
#       Cpu:     250m
#       Memory:  350Mi
#     Upper Bound:
#       Cpu:     800m
#       Memory:  1Gi

この推奨値を Antigravity に渡し、「VPA の分析結果に基づいて resources を最適化して」と指示すれば、過剰なリソース割り当てを排除した設定に自動修正してくれます。

スポットインスタンスの活用

# スポットインスタンスを活用するノードアフィニティ設定
spec:
  template:
    spec:
      # ステートレスなワークロードはスポットノードを優先
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 80
              preference:
                matchExpressions:
                  - key: cloud.google.com/gke-spot
                    operator: In
                    values:
                      - "true"
      # スポットノードの Taint を許容
      tolerations:
        - key: cloud.google.com/gke-spot
          operator: Equal
          value: "true"
          effect: NoSchedule
      # Pod の中断に備えたグレースフル終了
      terminationGracePeriodSeconds: 60

スポットインスタンスの活用は最大60-90%のコスト削減効果がありますが、突然の停止に備える設計が必要です。Antigravity にアプリケーションの特性（ステートレス/ステートフル、バッチ処理/リアルタイム処理）を伝えると、適切なスポット活用パターンを提案してくれます。

マルチクラスタ管理 — 本番・DR環境の統合運用

エンタープライズ環境では、単一クラスタではなく複数のクラスタを横断的に管理する必要があります。Antigravity を活用すれば、マルチクラスタの設定管理も効率的に行えます。

クラスタフェデレーションの基本設計

複数クラスタ間でのワークロード分散とフェイルオーバーを実現する設計パターンを示します。

# KubeFed を使用したマルチクラスタ Deployment
apiVersion: types.kubefed.io/v1beta1
kind: FederatedDeployment
metadata:
  name: api-server
  namespace: production
spec:
  template:
    metadata:
      labels:
        app: api-server
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: api-server
      template:
        spec:
          containers:
            - name: api-server
              image: gcr.io/my-project/api-server:1.2.0
              resources:
                requests:
                  cpu: "250m"
                  memory: "256Mi"
  placement:
    clusters:
      # プライマリクラスタ（東京リージョン）
      - name: cluster-tokyo
      # DR クラスタ（大阪リージョン）
      - name: cluster-osaka
  overrides:
    # 大阪クラスタはレプリカ数を減らす（DR用）
    - clusterName: cluster-osaka
      clusterOverrides:
        - path: "/spec/replicas"
          value: 1

DNS ベースのトラフィック分散

# ExternalDNS による自動 DNS 管理
# プライマリクラスタ障害時に DR クラスタへ自動切替
apiVersion: externaldns.k8s.io/v1alpha1
kind: DNSEndpoint
metadata:
  name: api-global-dns
spec:
  endpoints:
    - dnsName: api.example.com
      recordType: A
      targets:
        - 203.0.113.10   # cluster-tokyo の Ingress IP
        - 203.0.113.20   # cluster-osaka の Ingress IP
      setIdentifier: primary
      providerSpecific:
        - name: aws/failover
          value: PRIMARY

Antigravity にマルチクラスタの要件を伝える際は、RTO（Recovery Time Objective）と RPO（Recovery Point Objective）を明確にすると、それに見合ったフェイルオーバー設計が得られます。「RTO 5分以内、RPO 0（データ損失ゼロ）」のように具体的な数値を指示しましょう。

トラブルシューティング — よくある問題と AI を使った診断

Kubernetes 運用で遭遇する典型的な問題と、Antigravity エージェントを活用した診断手法を紹介します。

Pod が起動しない場合の体系的な診断フロー

Antigravity のターミナルで以下のコマンドを順番に実行し、結果をエージェントに共有すると、根本原因の特定と修正案を得られます。

# 1. Pod の状態確認
kubectl get pods -n production -l app=api-server
 
# 2. Pod の詳細イベント確認
kubectl describe pod <pod-name> -n production
 
# 3. コンテナログの確認（前回クラッシュ時のログ含む）
kubectl logs <pod-name> -n production --previous
 
# 4. ノードのリソース状況確認
kubectl top nodes
kubectl describe node <node-name> | grep -A 5 "Allocated resources"
 
# 5. PersistentVolumeClaim の状態確認
kubectl get pvc -n production
 
# 期待出力例（正常時）:
# NAME         STATUS   VOLUME     CAPACITY   ACCESS MODES
# data-pvc     Bound    pv-001     10Gi       RWO

ImagePullBackOff の解決パターン

# レジストリの認証情報を Secret として作成
kubectl create secret docker-registry gcr-secret \
  --docker-server=gcr.io \
  --docker-username=_json_key \
  --docker-password="$(cat service-account.json)" \
  --namespace=production
 
# Deployment の ServiceAccount に Secret を関連付け
kubectl patch serviceaccount default -n production \
  -p '{"imagePullSecrets": [{"name": "gcr-secret"}]}'

OOMKilled の診断と対処

Pod が OOMKilled で頻繁に再起動する場合、メモリ制限の見直しが必要です。Antigravity に VPA の推奨値と現在の設定を伝え、「OOMKilled が発生しています。メモリ設定を最適化して」と指示すれば、適切な値を算出してくれます。

# OOMKilled の検出
kubectl get pods -n production -o json | \
  jq '.items[] | select(.status.containerStatuses[]?.lastState.terminated.reason == "OOMKilled") | .metadata.name'
 
# メモリ使用量のリアルタイム監視
kubectl top pods -n production --sort-by=memory
 
# 期待出力例:
# NAME                          CPU(cores)   MEMORY(bytes)
# api-server-7b9d8c6f5d-abc12   45m          487Mi
# api-server-7b9d8c6f5d-def34   52m          495Mi

Secrets 管理 — 機密情報の安全な取り扱い

Kubernetes の Secret は Base64 エンコードに過ぎず、暗号化ではありません。本番環境では外部のシークレット管理サービスとの統合が不可欠です。

External Secrets Operator の活用

# External Secrets Operator で Google Secret Manager と連携
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: api-secrets
  namespace: production
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: gcp-secret-store
    kind: ClusterSecretStore
  target:
    name: api-secrets
    creationPolicy: Owner
  data:
    - secretKey: database-url
      remoteRef:
        key: projects/my-project/secrets/database-url
        version: latest
    - secretKey: api-key
      remoteRef:
        key: projects/my-project/secrets/api-key
        version: latest
---
# ClusterSecretStore の定義
apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: gcp-secret-store
spec:
  provider:
    gcpsm:
      projectID: my-project
      auth:
        workloadIdentity:
          clusterLocation: asia-northeast1
          clusterName: production-cluster
          clusterProjectID: my-project
          serviceAccountRef:
            name: external-secrets-sa
            namespace: external-secrets

Antigravity に「Google Secret Manager に保存されている3つのシークレットを Kubernetes Pod に注入する設定を作って。Workload Identity で認証して」と指示すれば、ExternalSecret と ClusterSecretStore の両方を一度に生成してくれます。これは手動で書くと設定の整合性を保つのが難しい部分です。

個人開発者の視点から（実体験メモ）

まとめ — AI と協調するクラウドネイティブ開発の未来

Antigravity × Kubernetes の組み合わせは、クラウドネイティブ開発の生産性を飛躍的に向上させます。AI エージェントに YAML 生成の機械的な複雑さを任せ、エンジニアはアーキテクチャの判断に集中する — この協調モデルがスピードと正確性の両方を実現します。本記事で解説した内容を振り返ります。

マニフェスト自動生成: 自然言語からヘルスチェック・リソース制限・Secret管理を含む本番品質のYAMLを生成
Helm チャート設計: 環境別の values ファイルを含む再利用可能なパッケージを一括生成
デプロイ戦略: ローリングアップデートからカナリアデプロイまで、要件に応じた戦略を実装
オートスケーリング: CPU/メモリベースからカスタムメトリクスまで、最適なHPA設定を設計
セキュリティ設計: Pod Security Standards と NetworkPolicy によるゼロトラスト実装
GitOps: ArgoCD + Kustomize によるマルチ環境の宣言的管理
コスト最適化: VPA分析とスポットインスタンス活用による運用コスト削減