クバネティス(Kubernetes) 環境での Redis 構築ガイド ③

Redis 構築準備

☸️ Redis Docker イメージ準備方法 (オンライン vs クローズドネットワーク)

1) インターネット接続環境 (Online)

クバネティスマニフェスト(YAML)内に 'image: redis:8.8.2' を明示し 'imagePullPolicy: IfNotPresent' を与えると、自動で Docker Hub から最新イメージをダウンロードします。

2) クローズドネットワーク環境 (Air-Gapped) - Rocky Linux 9.5 適用方式

外部インターネット接続が不可能なクローズドネットワークサーバーでは、イメージパッケージおよび K3s 手動ロード作業を行う必要があります。

[1段階] インターネット可能な PC/サーバーでイメージ抽出
# Docker を利用して保存
$ docker pull redis:8.8.2
$ docker save -o redis-8.8.2.tar redis:8.8.2
[2段階] クローズドネットワーク Rocky Linux 9.5 サーバーへファイル移管および K3s イメージロード
# 方法 A: k3s ctr(containerd CLI) で直接インポート (推奨)
$ sudo k3s ctr images import redis-8.8.2.tar
# 方法 B: K3s 自動エージェントイメージディレクトリへコピー
$ cp redis-8.8.2.tar /var/lib/rancher/k3s/agent/images/
⚠️ 注意: StatefulSet YAML ファイル作成時に 'imagePullPolicy: IfNotPresent' に設定し、クバネティスが外部インターネットへイメージを再び引こうとして失敗するエラー('ErrImagePull')を防ぐ必要があります。

構築およびテスト環境の仕様

本ガイドシリーズのすべてのテストは、以下の仕様の環境で実証検証されました。

OS: Rocky Linux 9.5 (Blue Onyx) - 64bit
Kubernetes: K3s (v1.x, CNCF Certified Lightweight Kubernetes)
Redis Version: Redis 8.8.2 (Latest Open Source Release)
StorageClass: local-path (K3s 内蔵 Persistent Volume)
Service Ports: Redis Port: 18504, Sentinel Port: 28504, Cluster Bus Port: 28504
Network: Headless Service Dynamic DNS Resolution

クバネティス Redis 構成およびテスト目次

本ガイドは 3 つの詳細構成ページと 1 つの総合結論ページへ続きます。以下のリンクから、各アーキテクチャ別の構築方法、YAML 設定、そして実際の Failover 検証ログを確認できます。

💻 Redis-Cluster (6pods) 構成およびテスト

概要: 3 Master + 3 Replica 構造の高性能シャーディングアーキテクチャ。
コア要素: StatefulSet + Headless Service ベース構成、'cluster-announce-hostname' を使った IP 変動対応、'create-redis-cluster.sh' 自動化スクリプト提供。
🔗 [Redis-Cluster (6pods) 詳細構築ガイドへ]

💻 Redis-Sentinel (6pods) 構成およびテスト

概要: Redis 専用 Pod 3 個と Sentinel 専用 Pod 3 個を完全に分離した高可用性(HA) 構成。
コア要素: Sentinel 間の Pub/Sub 対話による自動 Failover、'replica-priority' 制御による優先順位ベースのマスター昇格。
🔗 [Redis-Sentinel (6pods) 詳細構築ガイドへ]

💻 Redis-Sentinel Sidecar パターン (3pods) 構成およびテスト

概要: 1 Pod 内に [Redis + Sentinel] コンテナを一緒に束ね、合計 3 個 Pod で実装
コア要素: 資源節約、同一 Pod IP/ボリューム共有、メイン Redis と Sentinel 間の完全なプロセス隔離検証。
🔗 [Redis-Sentinel Sidecar パターン (3pods) 詳細構築ガイドへ]

💻 Redis-Cluster 用 Java(Spring) App 実装/テスト

概要: App 実装時にどの設定をすればクバネティス Redis-Cluster 環境に適するかを実装/テスト
🔗 [Redis-Cluster 用 Java(Spring) App 実装/テストへ]

💻 Redis-Sentinel 用 Java(Spring) App 実装/テスト

概要: App 実装時にどの設定をすればクバネティス Redis-Sentinel 環境に適するかを実装/テスト
🔗 [Redis-Sentinel 用 Java(Spring) App 実装/テストへ]

💻 結び: どのアーキテクチャを選ぶか？

概要: プロジェクト規模、資源制約(Pod 個数)、データ容量、Read/Write 負荷分散要件に応じた最終アーキテクチャ選択ガイド。
🔗 [クバネティス Redis アーキテクチャ選択ガイドへ]

⚠️ Spring(Java) 環境で必ず注意すべき点(JVM DNS キャッシュ)📍

ここで Redis 開発者が必ず知っておくべき、とても重要な Java/Spring 特性が一つあります。 Java Virtual Machine(JVM)は性能向上のため、一度照会した DNS 結果を基本的に一定時間メモリにキャッシュ(Caching)しておきます。

💥 発生し得る問題シナリオ

1. Redis/Sentinel ポッドが死んで再起動し、IP が '10.244.1.20' → '10.244.2.35' に変わりました。
2. K8s CoreDNS は新しい IP('10.244.2.35')を知っています。
3. しかし Spring App の JVM が古い IP('10.244.1.20')をずっとキャッシュしていると、CoreDNS に尋ねることなく古い IP へ接続を試み続け、コネクションエラー('UnknownHostException' または 'Connection Refused')が起きる可能性があります。

💡 解決方法 (JVM DNS TTL 設定)

Spring App が起動するとき、JVM の DNS キャッシュ保持時間(TTL)を短く(例: 1秒〜3秒)設定する必要があります。
ここでは 1秒に設定しました。1秒では短すぎないか？毎秒再び照会して設定すると JVM に負荷をかけるのではないか？こう考えることもできます。しかし、次のように総障害復旧(Failover)時間を考えると決して短くありません。
① Redis 自身の Failover 所要時間: 'cluster-node-timeout' を 3秒に設定しても 4〜5秒程度かかります。
② Java(Spring Lettuce): Redis-Cluster 情報更新時間: 2秒
③ JVM DNS キャッシュ保持時間を 10秒にすると 5秒+2秒+10秒 = 17秒かかります。
17秒の間コマンドを処理できないのは小さな問題ではありません。したがって 'JVM DNS キャッシュ保持時間' を 1秒に設定し、合計 8秒以内に完全復旧すべきです。

Java オプション(JVM オプション)追加(deployment.yaml): -Dsun.net.inetaddr.ttl=1 📍
(DNS 照会成功結果を 1秒だけキャッシュし、以降は CoreDNS に再び尋ねるという設定です。)
Spring App 開始コード(Java)に追加:
java.security.Security.setProperty("networkaddress.cache.ttl", "1"); 📍

<< クバネティス k3s ②	K8s Redis-Cluster 準備 ① >>

Email 返事がかかってなれば、メールでお知らせします。