SREのトイルを30%削減！KubernetesでのPod自動再起動スクリプト実践ガイド

日々の運用業務の中で、特定のPodが応答しなくなる、あるいはパフォーマンスが低下するといった問題に直面することは少なくありません。

この記事では、そのような場合に手動でPodを再起動するという反復的で時間のかかる作業、いわゆる「トイル」を削減するための具体的な方法を解説します。

Kubernetesの自己修復機能、特にLiveness ProbeとReadiness Probeを活用し、さらにそれを補完する自動化スクリプトを導入することで、運用負荷を大幅に軽減し、SREがより価値の高い業務に集中できる環境を構築する方法を、実践的なスクリプト例とともに紹介します。

この記事を読み終える頃には、あなたのKubernetes運用がより効率的で信頼性の高いものになる具体的なイメージが湧いているはずです。

手動でのPod再起動がもたらす「トイル」という課題

システム運用において、Podの再起動は一般的な対応策の一つです。しかし、これが手動で行われる場合、SRE（サイトリライアビリティエンジニア）にとって大きな負担、すなわち「トイル」となります。トイルとは、手作業で繰り返し行われ、長期的な価値を生まない作業を指します。

手動での再起動作業は、以下のような問題点を抱えています。

課題	説明
時間的コスト	障害発生の検知、原因の特定、そして再起動コマンドの実行といった一連のプロセスには、たとえ数分であっても貴重なエンジニアリング時間を消費します。
対応の遅延	深夜や休日に障害が発生した場合、担当者が気づき対応するまでに時間がかかり、サービスのダウンタイムが長引く可能性があります。
ヒューマンエラー	手動操作には、誤ったPodを再起動してしまう、コマンドを間違えるといったヒューマンエラーのリスクが常に伴います。
スケールへの追従困難	サービスの成長に伴いPodの数が増加すると、手動での管理は非現実的になり、運用負荷はサービス規模に比例して増大します。

これらの課題は、SREが本来注力すべき、システムの信頼性向上や自動化といった、より戦略的で価値の高い業務から時間を奪うことになります。

Kubernetesの標準機能「Probe」による自己修復

Kubernetesには、コンテナの状態を監視し、自己修復を行うための強力な仕組みとして「Probe（プローブ）」が標準で備わっています。 Probeは主に以下の3種類があり、これらを活用することで基本的なPodのヘルスチェックと自動復旧が可能です。

Liveness Probe コンテナの動作を定期確認

Liveness Probe コンテナが正常に動作しているか（生きているか）を定期的に確認します。もしProbeが失敗すると、kubeletはコンテナを終了させ、Podの再起動ポリシーに従ってコンテナを再起動します。これにより、デッドロックなどで応答不能になったアプリケーションを自動的に復旧させることができます。

Readiness Probe コンテナのリクエスト受付準備を確認

Readiness Probe コンテナがリクエストを受け付ける準備ができているかを確認します。 Probeが失敗した場合、そのPodはサービスのエンドポイントから切り離され、トラフィックが送られなくなります。準備が整うと再びトラフィックの受信を開始します。これにより、起動に時間がかかるアプリケーションが、準備が整う前にリクエストを受け取ってしまう事態を防ぎます。

Startup Probe コンテナ内アプリの起動確認

Startup Probe コンテナ内のアプリケーションが起動したことを確認するためのProbeです。特に起動に時間がかかるコンテナで有効です。Startup Probeが成功するまで、Liveness ProbeとReadiness Probeは無効化されるため、起動が遅いアプリケーションがLiveness Probeによって不必要に再起動されるのを防ぎます。

これらのProbeは、Pod定義のYAMLファイル内で設定します。 HTTPリクエスト、TCPソケット接続、コンテナ内でのコマンド実行という3つの方法でヘルスチェックを行うことができます。

Pod自動再起動スクリプトの実例

Probeだけでは対応しきれない、より複雑な条件での再起動を実現するためには、自動化スクリプトが有効です。ここでは、特定の条件（例: エラーログの頻発）を検知して、該当するDeploymentのPodを自動的にローリングリスタートするシェルスクリプトの例を紹介します。

このスクリプトは、kubectl コマンドを利用して指定されたDeploymentのPodを安全に再起動します。

スクリプト本体

#!/bin/bash

# --- 設定項目 ---
# 対象とするKubernetesのNamespace
NAMESPACE="your-namespace"
# 対象とするDeploymentの名前
DEPLOYMENT_NAME="your-deployment"
# 監視するログに出力されるエラー文言
ERROR_PATTERN="critical error"
# 監視間隔（秒）
CHECK_INTERVAL=60
# エラー検知の閾値（この回数以上エラーを検知したら再起動）
ERROR_THRESHOLD=5
# 監視期間（秒）：この期間内に閾値を超えた場合に再起動
TIME_WINDOW=300

# --- スクリプト本体 ---
echo "Podの自動再起動スクリプトを開始します。"
echo "監視対象: Namespace=${NAMESPACE}, Deployment=${DEPLOYMENT_NAME}"

error_count=0
last_check_time=$(date +%s)

while true; do
  # 現在のPodリストを取得
  pods=$(kubectl get pods -n ${NAMESPACE} -l app=${DEPLOYMENT_NAME} -o jsonpath='{.items[*].metadata.name}')
  
  if [[ -z "$pods" ]]; then
    echo "対象のPodが見つかりません。1分後に再試行します。"
    sleep 60
    continue
  fi

  # 各Podのログをチェック
  for pod in $pods; do
    # TIME_WINDOW内に絞ってログをチェック
    new_errors=$(kubectl logs --since=${TIME_WINDOW}s -n ${NAMESPACE} ${pod} | grep "${ERROR_PATTERN}" | wc -l)
    error_count=$((error_count + new_errors))
  done

  echo "$(date '+%Y-%m-%d %H:%M:%S') - 過去${TIME_WINDOW}秒間のエラー数: ${error_count}"

  # エラー数が閾値を超えたかチェック
  if [ ${error_count} -ge ${ERROR_THRESHOLD} ]; then
    echo "エラー閾値を超えました。Deploymentのローリングリスタートを実行します。"
    
    # ローリングリスタートを実行
    kubectl rollout restart deployment/${DEPLOYMENT_NAME} -n ${NAMESPACE}
    
    if [ $? -eq 0 ]; then
      echo "ローリングリスタートが正常にトリガーされました。スクリプトを終了します。"
      exit 0
    else
      echo "ローリングリスタートの実行に失敗しました。10分後に再試行します。"
      sleep 600
    fi
  fi
  
  # カウントをリセットして次の監視へ
  error_count=0
  sleep ${CHECK_INTERVAL}
done

実行方法と注意点

権限設定: このスクリプトを実行する環境には、対象のNamespaceでPodのログ取得 (logs) とDeploymentの再起動 (rollout restart) が可能なkubectlの権限が必要です。 CronJobとしてクラスター内で実行する場合は、専用のServiceAccountを作成し、適切なRole/ClusterRoleを割り当てることを推奨します。
カスタマイズ: スクリプト冒頭の「設定項目」を、ご自身の環境に合わせて変更してください。特に NAMESPACE, DEPLOYMENT_NAME, ERROR_PATTERN は重要です。
実行: スクリプトを保存し（例: auto_restart.sh）、実行権限を与えて (chmod +x auto_restart.sh)、バックグラウンドで実行します (./auto_restart.sh &)。本番環境で利用する場合は、KubernetesのCronJobとしてデプロイするのが一般的です。

このスクリプトはあくまで一例です。より高度な要件、例えば「特定のメトリクスが閾値を超えた場合」に対応するには、Prometheusなどの監視ツールと連携する必要があるでしょう。

自動化によって得られる3つの大きなメリット

Pod再起動の自動化は、単に手間を省くだけでなく、SRE活動全体に多大な好影響をもたらします。

メリット	説明
トイルの大幅な削減	最も直接的な効果は、反復的な手動作業からの解放です。これにより、エンジニアは疲弊することなく、より創造的で価値の高い業務に集中できます。ある事例では、同様の自動化によって運用負荷が30%削減されたという報告もあります。
平均修復時間（MTTR）の短縮	システムが自動的に異常を検知し、即座に自己修復を開始するため、人間が介在する場合に比べて障害からの回復時間が劇的に短縮されます。これは、サービスの可用性を高め、エラーバジェットの消費を抑えることに直結します。
信頼性と予測可能性の向上	自動化されたプロセスは、常に一貫した手順で実行されるため、ヒューマンエラーを排除し、システムの信頼性を高めます。また、いつ、どのような条件で再起動が行われるかが明確になるため、システムの挙動が予測しやすくなります。