前提は以下で固定します。

• Python 3.12 以降
• Django 4.x 以上
• Kubernetes（Ingress + Service + Deployment）
• SRE ＋ セキュリティ考慮

― Kubernetes で「安全に生かし続ける」ための実践ガイド ―

はじめに

Kubernetes に Django を載せたとき、
最も多い事故原因はこれです。

「起動していない Django にトラフィックが流れる」

この事故は readiness / liveness を正しく実装するだけで防げます。

本記事では、

• Django 4.x
• Python 3.12+
• 本番運用を前提

として、
SRE 視点・セキュリティ考慮込みの実装例を解説します。

readiness / liveness とは何か（超要約）

重要な違い

• liveness が死ぬ → Pod 再起動
• readiness が死ぬ → 通信停止（再起動しない）

👉 Django では 両方必要です。

なぜ Django では分ける必要があるのか

Django は起動後でも以下が起こります。

• DB未接続
• migration未完了
• 外部API未接続
• キャッシュ未初期化

これを liveness で落とすと事故になります。

全体構成図（Kubernetes視点）

実装方針（SRE的正解）

Django 健康チェック設計

エンドポイント設計

Django 側の実装例

① URL 定義

# project/urls.py
from django.urls import path
from health import views

urlpatterns = [
    path("health/live/", views.liveness),
    path("health/ready/", views.readiness),
]

② View 実装（Python 3.12 / Django 4）

# health/views.py
from django.http import JsonResponse
from django.db import connections
from django.db.utils import OperationalError

def liveness(request):
    return JsonResponse({"status": "alive"}, status=200)


def readiness(request):
    try:
        db_conn = connections["default"]
        db_conn.cursor()
    except OperationalError:
        return JsonResponse(
            {"status": "db not ready"},
            status=503
        )

    return JsonResponse({"status": "ready"}, status=200)

ポイント

• 例外は必ず捕まえる
• timeout や retry は入れない（K8sに任せる）

Kubernetes Deployment 定義例

readiness / liveness 設定

livenessProbe:
  httpGet:
    path: /health/live/
    port: 8000
  initialDelaySeconds: 30
  periodSeconds: 10

readinessProbe:
  httpGet:
    path: /health/ready/
    port: 8000
  initialDelaySeconds: 20
  periodSeconds: 5

タイミング設計（重要）

推奨値

• liveness：遅め
• readiness：早め & 厳しめ

migration との正しい関係

❌ やってはいけない例

• Pod起動時に migrate 自動実行

✅ 正解

• Job として先行実行
• readiness は migration 完了後のみ OK

@startuml
Job(migrate) -> DB
Deployment -> readiness check
readiness -> OK
Ingress -> Traffic
@enduml

セキュリティ観点の注意点

① 認証を付けない

• health endpoint は 内部専用
• Ingress で外部非公開にする

② 情報を出しすぎない

// NG
{
  "db_host": "xxx",
  "error": "password incorrect"
}

// OK
{
  "status": "not ready"
}

よくある事故パターン

監視との連携（SRE視点）

• readiness NG 回数
• Pod Restart 回数
• readiness → OK までの時間

👉 「死んだ」より「遅い」を見る

まとめ

Django × Kubernetes では、

• liveness = 生存確認
• readiness = 業務可能判定

を明確に分けることで、

• 無停止デプロイ
• 障害の局所化
• セキュリティ事故防止

が実現できます。