EmptyDirボリューム付きRedisキャッシュDeployment
emptyDirボリュームによるオプションのRDB永続化とTCPソケットヘルスプローブを使用して、KubernetesにインメモリキャッシュとしてのRedisをデプロイします。
Databases
詳細な説明
KubernetesでのRedisキャッシュ
キャッシュとしてのRedisには永続ストレージは不要です — ポッドが再起動してもキャッシュは再構築できます。ただし、RedisのRDBダンプにemptyDirボリュームを使用すると、ダンプファイルが存在する場合の再起動が高速になります。
主要な設定
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis
labels:
app: "redis"
role: "cache"
spec:
replicas: 1
template:
spec:
containers:
- name: redis
image: redis:7-alpine
ports:
- name: redis
containerPort: 6379
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "250m"
memory: "256Mi"
volumeMounts:
- name: redis-data
mountPath: /data
volumes:
- name: redis-data
emptyDir: {}
EmptyDir vs PVC
| 機能 | emptyDir | PVC |
|---|---|---|
| コンテナ再起動後も保持 | はい | はい |
| ポッド再起動後も保持 | いいえ | はい |
| パフォーマンス | RAMスピード(tmpfs)またはディスク | ストレージクラスに依存 |
| ユースケース | キャッシュ、一時データ | 永続キュー、セッションストア |
純粋なキャッシュとしてのRedisにはemptyDirが適切です。ポッドのリスケジュール後もデータを保持する必要がある場合(例:セッションストアとしてのRedis)はPVCを使用してください。
メモリ管理
Redisのmaxmemoryディレクティブをコンテナメモリ制限よりわずかに少なく設定し(例:制限が256Miの場合は200Mi)、allkeys-lruなどの退避ポリシーを設定します。これにより、RedisがコンテナランタイムによってOOMキルされるのを防ぎます。
ユースケース
ポッドのリスケジュール後の永続データを必要とせず、Webアプリケーションのキャッシュレイヤー、セッションストレージ、レートリミティングとしてRedisをデプロイ。