redis education kubernetes k8s_intro_1

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

クバネティス(Kubernetes) の紹介

2014年から Redis 専用サーバー(Bare-Metal, VM) および Docker 環境での Redis インストール/運用ノウハウを 共有してきた RedisGate(redisGate)です。
最近のエンタープライズプロジェクトの現場では、アプリケーションだけでなく Redis のような In-Memory データベースも クバネティス(Kubernetes) ポッド(Pod) で構成してほしいという要件が急速に増えています。   既存の Redis エンジニアや DBA の視点では「Stateful なデータベースを変動の大きいクバネティス ポッドに 載せても安全か？」という疑問が先に浮かぶかもしれません。
本ガイドは、こうした悩みを解決するために Rocky Linux 9.5 (クローズドネットワーク) 環境で K3s および最新 Redis 8.8.2 を活用して Redis-Cluster、Redis-Sentinel を自ら構築し、障害対策(Failover) まで完全に検証した実戦記録です。     (📝 クバネティス-Redis インストール/テスト: 2026年 7〜9月)

☸️ 運用環境の変化

上の画像がデプロイメント(Deployment) 環境が一律的(一律的)に変わるという意味ではありません。   ポッド(Pod) の特徴の一つが ephemeral(寿命が短い、一回限り)です。   しかしここで扱う DB は寿命が短くもなく、一回限りでもありません。   MySQL、PostgreSQL のような Disk-Base DB は permanent(永続的、不変)です。   Redis も状態が変わると変更内容を conf ファイルに記録します。   そしてデータもほぼリアルタイムで AOF ファイルに記録します。   したがって In-Memory DB である Redis もまた 'permanent' です。

クバネティスでも 'permanent' なソフトウェアを支えるために 'statefulset' をサポートしています。   そしてプロジェクトを企画するとき、デプロイメント(Deployment) アーキテクチャをクバネティスにするのを基本とする ケースが増えています。   Redis でも redis-sentinel は 2021年 2月に発表された Redis-6.2.0 から、 redis-cluster は 2022年 4月に発表された Redis-7.0.0 からクバネティス ポッドをサポートしています。

当社 RedisGate の経験では、10% は物理サーバー、80% は VM、10% は Docker/クバネティスで構築します。 いま Redis もクバネティス環境で構築すべき時期になりました。

☸️ クバネティス(*Kubernetes) は何か？ (簡潔な説明)

クバネティス(Kubernetes, *K8s)は、コンテナ化したアプリケーションの自動デプロイ、スケーリング、管理を調整する オープンソースのコンテナ *オーケストレーション(Orchestration) プラットフォームです。
従来のサーバー環境では Redis が落ちるとエンジニアが手動でプロセスを起こす必要がありましたが、 クバネティスは『望む状態(Desired State)』を 設定ファイル(YAML)に宣言しておけば、プロセス異常(down) 検知時に自動で再起動(Self-healing)し 可用性を維持してくれます。

Google は 2003年頃から内部で 'Borg' という大規模クラスター管理システムを運用し、Google 検索、 Gmail、YouTube などのインフラを管理してきました。   1週間に *20億個以上のコンテナデプロイを処理し 蓄積した経験をもとに、2014年 6月にクバネティスをオープンソースとして公開しました。 翌年の 2015年 7月に v1.0 がリリースされ、現在は *CNCF(Cloud Native Computing Foundation) に よって管理されています。

コア機能

• 自動復旧(Self-healing): プログラムが入っているコンテナが突然止まると(down) 自ら元の状態に生き返らせるか、新しいものに置き換えます。
• 自動拡張(Auto-scaling): ユーザーが急に集まるとプログラムの数を自動で増やし、 人が減ると再び減らします。 ➡ Redis の特性上、自動拡張機能は使いません。
• 負荷分散(Load Balancing): 一方に仕事が偏らないよう、複数箇所へ均等に振り分けて届けます。 ➡ Redis の特性上、Redis 自身の負荷分散機能を使います。

☸️ ポッド(Pod) は何か？

クバネティスで生成し管理できる最小デプロイ単位が、まさにポッド(Pod)です。

ポッドのコア特徴 4つ

• 資源共有 (ネットワーク & ストレージ)
  • ① IP アドレス共有: ポッドは固有の単一 IP アドレスを与えられます。ポッド内のすべてのコンテナはこの IP を共有し、 互いに 'localhost' を通じて非常に速く通信できます。
  • ボリューム共有: ポッドに割り当てられたストレージ(ボリューム)を内部コンテナが一緒に読み書きできます。
• ② 同一ノードスケジューリング: 一つのポッドに属するコンテナは常にクバネティスクラスター内の同一の ワーカーノード(Worker Node)に一緒にデプロイされ、一緒に実行されます。
• ③ 揮発性(Ephemeral) ライフサイクルと固有性:
  • ポッドは永続的ではありません。エラーが発生するかノードがダウンするとポッドは削除され、新たに生成されます。 このときポッドの IP アドレスも変わります。
  • Redis 構成時、ポッドの固有識別名を維持してくれる 'StatefulSet' と 'Headless Service' の組み合わせが必須です。   Redis は 7.0 からポッド IP が変わっても運用できるようサポートしています。
  • Ephemeral(エフェメラル)は『寿命が短い』『短命の』『はかない』という意味です。 ある現象や物体がごく短時間だけ存在し、瞬時に消えるときに主に使います。
  • Permanent: 永続的、不変
• ④ 1 ポッド = 1 コンテナが基本
  • 一般的には 1 個のポッドに 1 個のアプリケーションコンテナを実行する構成を最も多く使います。
  • しかし目的に応じて付属コンテナ(サイドカー(Sidecar))を一緒に束ねてデプロイできます。
    

クバネティス Pod で Redis を構成するときの注意点

クバネティスは基本的に揮発性(Stateless) 特性を持ちますが、Redis は状態維持(Stateful) アプリケーションです。 したがって Pod で運用するとき、次の 5 点を必ず注意してください。

• ① ワークロードオブジェクトの選択 (StatefulSet 必須)
  • Deployment の代わりに必ず 📍'StatefulSet' を使う必要があります。
  • Redis クラスターや Sentinel は各ノードが固定されたネットワーク識別子(Pod 名および DNS)を持たなければ、障害対策および 再接続が正常に動作します。
• ② AOF 永続性のための Storage(PV) および IOPS(Input/Output Operations Per Second) 管理
  • AOF が有効になっているため、Pod が再起動してもデータが維持されるよう 📍PersistentVolumeClaim(PVC) を マウントする必要があります。
  • AOF 書き込み作業(fsync)が頻繁に起きるため、ディスク I/O ボトルネックが発生すると Redis 全体の性能(メモリ処理)が 低下します。速度の速い NVMe/SSD ベースの StorageClass を割り当てることを推奨します。
• ③ ポッド アンチアフィニティ(Pod Anti-Affinity) 設定
  • Master と Replica Pod がクバネティスの同一物理ワーカーノード(Node)に配置されると、当該ノード障害時に Master と Replica が同時に死に、高可用性が壊れます。
  • 'podAntiAffinity' 構成により Master/Replica Pod が互いに異なる Node に分散配置されるよう強制する必要があります。
• ④ メモリ設定 (Memory Limit & maxmemory)
  • クバネティス resource limit メモリと Redis の maxmemory 設定の間に余裕が必要です。
  • Redis 'maxmemory' を Pod メモリ Limit と同一にすると、AOF 子プロセス生成(fork) やメモリ 断片化によりクバネティス OOMKilled(Out Of Memory Killer) によって Pod が直ちに強制終了されます。
  • 推奨: Redis 'maxmemory' は Pod メモリ Limit の 📍50%〜90% 水準に設定してください。
    • メモリ使用量が 10GB 以上で入力/修正/削除が多い場合: 50%〜60%
    • メモリ使用量が 10GB 以上だがほぼ参照の場合: 70%〜80%
    • メモリ使用量が 1GB 以下で入力/修正/削除が少ない場合: 80%〜90%
    • 最も安全に運用するには maxmemory 1GB の場合、Pod メモリは 2GB に設定します。
        (maxmemory の 2 倍)
• ⑤ カーネルパラメータおよびホスト環境設定
  • Redis が AOF rewrite や BGSAVE を実行するとき 'fork()' システムコールを使います。
  • このときホストノードの 'vm.overcommit_memory' 値が '1' に設定されていなければ、バックグラウンド保存作業が 失敗することがあります。
  • 📍ホストノード(OS) レベルで事前にカーネルパラメータを設定しておく必要があります。
  • m.overcommit_memory = 1, net.core.somaxconn=8192, Transparent Huge Pages(THP) Disable などの設定

📦 なぜコンテナを直接実行せず『ポッド』で包むのでしょうか？

単一コンテナだけでは解決しにくい、密に結合した協調構造を扱うためです。 例えば、メイン Web サーバーコンテナの横にログ収集機やセキュリティプロキシコンテナを付ける必要があるときがあります。 これをサイドカー(Sidecar) パターンと呼びます。

この 2 つのコンテナはローカルファイルシステムや 'localhost' ネットワークを共有しなければ正常動作しません。 クバネティスはこれを『ポッド』という単位で束ね、2 つのコンテナが常に同じノードで生死を共にするよう管理します。
Redis 構築時に 'Redis + Sentinel' を一つのポッドで構成するサイドカーパターンは あまり推奨しません。   'Sentinel' は独立したインスタンス(オブジェクト)です。したがって別のポッドに構築するのが正しいです。
🔗 詳しい内容は "Kubernetes Redis-Sentinel Sidecar" ページをご覧ください。

ポッドを直接生成するよりコントローラーを使う理由

実務ではポッドを個別に直接生成することは稀です。ポッドは簡単に消えて再生成される特性があるため、 通常はデプロイメント(Deployment)、ステートフルセット(StatefulSet) のようなコントローラーオブジェクトを使い、ポッドの個数維持、 ローリングアップデート、復旧などを自動化します。

☸️ 'Deployment' と 'StatefulSet' の違いは？

クバネティスでデプロイメント(Deployment)とステートフルセット(StatefulSet)は、どちらもポッド(Pod)を 複数束ねて管理し、個数を維持してくれるワークロードコントローラーです。 二つの概念の最も決定的な違いは「ポッドに状態(State)と固有の識別子(名前/IP/デバイス)が必要か？」です。

• 1. デプロイメント(Deployment)
  デプロイメントは状態維持が不要なアプリケーション(Stateless)を管理するための標準コントローラーです。
  
  • 特徴: ポッドたちは完全に同一で、代替可能です。
  • ポッド名: 後ろに無作為なハッシュ値が付きます。 (例: `my-web-58997b6b96-abc12`)
  • 生成/削除の順序: 順序なく複数ポッドが同時に生成されたり削除されたりします。
  • 主な用途: Web サーバー、API サーバー、フロントエンドなど、ポッド一つが死んで別のポッドが新たに生まれても何の問題も ないアプリケーション。
• 2. ステートフルセット (StatefulSet)
  ステートフルセットは状態維持が必要なアプリケーション(Stateful)を管理するための専用コントローラーです。
  📍Redis は StatefulSet を使います。
  • 特徴: 各ポッドが固有で継続的な識別子(名前、ネットワーク、ストレージ)を持ちます。
  • ポッド名: 0 から始まる順次の固定インデックスが付きます。 (例: `redis-0`, `redis-1`, `redis-2`)
    - ポッドが死んで再起動しても名前(`redis-0`)と固定 DNS アドレスは決して変わらず維持されます。
  • 生成/削除の順序: 指定された順序どおり一つずつ生成され(`0` -> `1` -> `2`)、 削除されるときは逆順で除去されます。
  • 独立したストレージ (PVC Templating): ポッドごとに専用永続ディスク(PV)が 1:1 でマッピングされます。 ポッドが別のノードへ移っても自分のディスクを探して再びマウントします。
  • 主な用途: Redis、データベース(MySQL, PostgreSQL)、カフカ(Kafka) など、ノード間の順序や 固定された識別子が必須の分散システム。

一目で見る比較 (Deployment vs StatefulSet)

☸️ PersistentVolumeClaim(PVC) は何ですか？

クバネティスで PVC (PersistentVolumeClaim、永続ボリューム要求)は、ユーザー(ポッド)がクバネティスに 「この程度のスペックの保存領域(ディスク)をください」と要求する申請書/チケットです。 この概念を理解するには、Redis データが保存される実際のディスク(PV)と PVC の関係を一緒に見るのが最も簡単です。

• 1. PV と PVC の比喩 (不動産契約)
  クバネティスはインフラ(ディスク)管理と開発者(ポッド)要求をきれいに分離するため、PV と PVC という概念を分けています。
  • PV (PersistentVolume - 永続ボリューム):
  
  • インフラ管理者がクラスターにあらかじめ用意した実際のディスク資源 (例: AWS EBS 100GB、NVMe SSD 500GB、 SAN ストレージなど)です。
  • 比喩: 不動産市場に出ている「実際の建物/部屋」
  • PVC (PersistentVolumeClaim - 永続ボリューム要求):
  • 開発者やポッドが「容量 20GB が必要で、読み書きが速く永続的に保存されるディスクを一つください」と 提出する要求書です。
  • 比喩: 入居者が提出する「部屋探し条件表 (ワンルーム、容量 20GB、入居リクエスト)
  クバネティスはポッドが提出した PVC(申請書)の条件に合う PV(実際のディスク)を探し、二者を賃貸/接続(Binding)します。
  
• 2. なぜ Redis のような状態維持アプリに PVC が必須なのでしょうか？
  先に説明したとおり、クバネティス ポッド(Pod) 内部のファイルシステムは揮発性です。ポッドが再起動したり別のノードへ 移ると、内部データ(redis.conf、AOF ファイル)はすべて消えます。
  ① データ永続性の確保: AOF ファイルをポッド内部ではなく PVC を通じて接続した外部 PV(ディスク)に書きます。
  ② ポッド再起動/移動時の復旧: ノード障害で `redis-0` ポッドが死んで別のノードで新たに起動しても、既存に接続されていた PVC(ディスク)を 新しいポッドにそのまま再びマウントします。そのおかげで AOF データ損失なく Redis がそのまま復元されます。
• 3. StatefulSet と PVC の見事な組み合わせ (VolumeClaimTemplate)
  一般のデプロイメントはすべてのポッドが一つのディスクを見ようとして衝突します。
  一方、Redis に使うステートフルセット(StatefulSet)は 'volumeClaimTemplates' という機能を提供します。
  この機能を使うと、ポッドが生成されるたびに専用 PVC が 1:1 で自動発行されます。
  o 'redis-0' 生成 → 'data-redis-0' という PVC(ディスク) 自動割り当ておよび接続
  o 'redis-1' 生成 → 'data-redis-1' という PVC(ディスク) 自動割り当ておよび接続
  o 'redis-2' 生成 → 'data-redis-2' という PVC(ディスク) 自動割り当ておよび接続

結果として各 Redis ノードが自分だけの独自の conf ファイル、AOF/RDB 保存領域を安全に持つことになります。