Kubernetesを活用した
マイクロサービス管理

Kubernetesはマイクロサービスアーキテクチャの実行基盤として事実上の標準となりました。しかし「とりあえずKubernetesを使う」から「Kubernetesで効率的に運用する」へのシフトには、多くの知識と経験が必要です。本記事では、Dev Stack BaseのVP of Engineeringとして培った実践知識をもとに、Kubernetesを活用したマイクロサービス管理のベストプラクティスを解説します。

Kubernetes マイクロサービス設計の基礎

マイクロサービスをKubernetesで管理する際、最初に決定すべきはサービス境界の設計です。各サービスは単一のビジネス機能に責任を持ち、独立してデプロイ可能であることが基本です。

NamespaceはKubernetesのリソース分離の基本単位です。環境（dev/staging/prod）ごと、またはチームごとにNamespaceを分割することで、リソースクォータ管理、RBAC設定、NetworkPolicyによるトラフィック制御が容易になります。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
  namespace: production
  labels:
    app: order-service
    version: v2.1.0
spec:
  replicas: 3
  selector:
    matchLabels:
      app: order-service
  template:
    spec:
      containers:
      - name: order-service
        image: registry.dsb.io/order-service:v2.1.0
        resources:
          requests:
            cpu: "250m"
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 30

HPA（Horizontal Pod Autoscaler）の設定

HPAはCPU・メモリ使用率に基づいてPod数を自動調整します。2026年現在、カスタムメトリクスやExternalメトリクス（Prometheusやキューの長さなど）に基づいたHPAが広く使われています。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: order-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-service
  minReplicas: 3
  maxReplicas: 50
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Pods
    pods:
      metric:
        name: order_queue_length
      target:
        type: AverageValue
        averageValue: "100"

サービスメッシュ（Istio）の導入

マイクロサービス数が増加すると、サービス間通信の管理が複雑になります。サービスメッシュ（Istio/Linkerd）を導入することで、mTLS通信の自動設定、トラフィック管理、サーキットブレーカー、詳細なテレメトリ収集を透過的に実現できます。

可観測性（Observability）の実装

Kubernetes環境での可観測性は、メトリクス（Prometheus）、ログ（Loki/Elasticsearch）、トレース（Jaeger/Tempo）の「三本柱」が基本です。OpenTelemetryを活用することで、アプリケーションコードから統一的なテレメトリデータを収集できます。

GitOpsによる宣言的デプロイメント

ArgoCDを使ったGitOpsワークフローでは、Gitリポジトリの状態がKubernetesクラスターの「あるべき姿」を定義します。コード変更がGitにプッシュされると、ArgoCDが自動的に差分を検知し、クラスターに適用します。

実践Tips：よくあるアンチパターン

• リソースリクエスト/リミットを設定しない：ノードのリソース枯渇を引き起こす。必ず設定すること。
• 1つのNamespaceに全サービスを詰め込む：RBAC設定が困難になる。チーム・環境ごとに分離。
• ヘルスチェックを設定しない：障害Pod にトラフィックが流れ続ける。liveness/readinessProbeは必須。
• PodDisruptionBudgetを設定しない：ノードメンテナンス時に全Podが落ちる可能性。