Kebolehpercayaan Redis, RabbitMQ, dan Kafka dalam Kubernetes: Panduan Medan

Senario

Aplikasi anda bergantung pada Redis untuk caching, RabbitMQ untuk baris tugas, dan Kafka untuk streaming peristiwa. Tiba-tiba, pasukan platform melaporkan gelombang amaran: penggunaan memori Redis meningkat, baris RabbitMQ bertimbun, dan kelewatan pengguna Kafka semakin meningkat. Pengguna mengadu tentang pembayaran yang perlahan dan pemberitahuan yang hilang. Anda perlu bertindak pantas tanpa membuat keadaan lebih buruk.

Gejala

• Redis: Lonjakan kependaman, kematian OOM, ribut pengusiran, ralat READONLY semasa failover.
• RabbitMQ: Kedalaman baris meningkat, sambungan pengguna terputus, CPU tinggi pada nod broker, channel.error dalam log.
• Kafka: Kelewatan kumpulan pengguna, ISR mengecut, pengecualian NotLeaderForPartition, partition kurang replika.

Diagnosis

Mula dengan pemeriksaan peringkat Kubernetes: penggunaan sumber, kesihatan pod, dan rangkaian. Kemudian selidiki setiap middleware.

1. Peringkat Kubernetes: - kubectl get pods -n <namespace> - lihat but semula atau CrashLoopBackOff. - kubectl top pods -n <namespace> - semak CPU/memori. - kubectl describe pod <pod> - periksa peristiwa, probe, had.

2. Diagnosis Redis: - redis-cli info memory - semak used_memory, maxmemory, evicted_keys. - redis-cli info stats - lihat sambungan yang ditolak dan ralat. - redis-cli latency doctor - kenal pasti punca kependaman. - redis-cli --bigkeys - cari kunci besar yang menyebabkan partition.

3. Diagnosis RabbitMQ: - rabbitmqctl list_queues name messages consumers - perhatikan kedalaman baris. - rabbitmqctl list_channels - periksa keadaan saluran. - rabbitmq-diagnostics -q ping - semak denyut broker. - rabbitmq-diagnostics runtime - semak memori, deskriptor fail, dan butiran proses.

4. Diagnosis Kafka: - kafka-consumer-groups.sh --bootstrap-server <broker> --describe --group <group> - semak kelewatan. - kafka-topics.sh --describe --topic <topic> - lihat pemimpin partition dan ISR. - kafka-broker-api-versions.sh --bootstrap-server <broker> - sahkan sambungan. - Dari dalam pod Kafka, periksa log untuk ralat seperti "NotLeaderForPartition".

Arahan

Redis

# Semak memori dan nisbah hit ruang kunci
redis-cli info memory | grep -E "used_memory_human|maxmemory_human|mem_fragmentation_ratio"

# Pantau pengusiran dan kematian OOM
redis-cli info stats | grep -E "evicted_keys|rejected_connections"

# Log pertanyaan perlahan
redis-cli slowlog get 10

# Status simpanan RDB
redis-cli info persistence | grep rdb_last_save

RabbitMQ

# Senarai baris dengan bilangan mesej dan pengguna
rabbitmqctl list_queues name messages consumers

# Semak bilangan sambungan dan saluran
rabbitmqctl list_connections state recv_oct discards

# Dapatkan status memori dan amaran
rabbitmqctl status | grep -A 10 "Memory"

# Dayakan/lumpuhkan API pengurusan? Tidak perlu.

Kafka

# Senarai topik dengan partition dan replika
kafka-topics.sh --describe --bootstrap-server localhost:9092

# Semak kelewatan kumpulan pengguna
kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group my-group

# Ubah pengekalan mesej jika perlu (kecemasan sahaja)
kafka-configs.sh --bootstrap-server localhost:9092 --alter --entity-type topics --entity-name my-topic --add-config retention.ms=3600000

Kawalan Risiko

• Tetapkan permintaan dan had sumber untuk CPU/memori pada semua pod middleware. Lebih peruntukan boleh menyebabkan jiran bising; kurang peruntukan menyebabkan kematian OOM.
• Konfigurasikan probe liveness dan readiness Kubernetes dengan betul. Untuk Redis, gunakan redis-cli ping; untuk RabbitMQ, gunakan titik akhir semakan kesihatan atau rabbitmq-diagnostics ping; untuk Kafka, gunakan kafka-broker-api-versions.sh atau JMX exporter terbina dalam.
• Gunakan PodDisruptionBudgets untuk mengelakkan semua broker diusir semasa penyelenggaraan nod.
• Dayakan kekekalan: Redis AOF (dengan appendfsync everysec), baris RabbitMQ dengan bendera tahan lama, Kafka dengan log.dirs pada volum kekal.
• Gunakan Redis Cluster, baris kuorum RabbitMQ, dan kesedaran rak Kafka untuk ketersediaan tinggi.
• Tetapkan amaran dan papan pemuka untuk metrik utama: penggunaan memori, bilangan sambungan, kelewatan mesej, penggunaan CPU.

Rollback

• Redis: Jika CONFIG SET baru-baru ini menyebabkan ketidakstabilan, pulihkan dengan redis-cli CONFIG REWRITE selepas memulihkan konfigurasi sebelumnya daripada sandaran. Untuk Kubernetes, rollback ConfigMap dan lakukan but semula bergilir.
• RabbitMQ: Jika perubahan plugin atau kemas kini dasar menyebabkan masalah, lumpuhkan plugin atau pulihkan dasar. Gunakan rabbitmqctl set_policy dengan nilai lama. Untuk isu versi, tukar kembali kepada versi imej sebelumnya dan lakukan kemas kini bergilir.
• Kafka: Jika perubahan konfigurasi topik (seperti pengekalan atau bilangan partition) menjadi bumerang, gunakan kafka-configs.sh untuk memulihkan timpaan topik. Jika isu datang dari naik taraf versi broker, rollback versi imej sambil mengekalkan penyimpanan yang sama.

Sentiasa uji rollback dalam persekitaran pementasan dahulu. Jangan sekali-kali rollback kluster berstatus tanpa menggantung trafik klien.

Pengesahan

• Redis: Semak redis-cli info stats untuk evicted_keys menurun dan nisbah hit stabil. Jalankan redis-cli ping dari klien.
• RabbitMQ: Sahkan kedalaman baris menurun dan sambungan pengguna stabil. Gunakan rabbitmqctl list_queues sekali lagi.
• Kafka: Sahkan kelewatan pengguna turun ke julat normal dan kafka-topics.sh --describe menunjukkan semua ISR dalam sinkron.

Juga pantau kadar ralat dan persentil kependaman peringkat aplikasi untuk memastikan pengalaman pengguna dipulihkan.

Bila Menghantar Tiket OpsGlobal

Hantar tiket jika: - Punca akar tidak jelas atau kegagalan yang sama berulang selepas banyak campur tangan. - Anda perlu memulihkan fail RDB/AOF Redis yang rosak atau melakukan penugasan semula partition Kafka secara manual. - Versi middleware melebihi hayat dan memerlukan strategi naik taraf. - Anda memerlukan bantuan untuk merancang penggunaan berbilang wilayah yang komprehensif atau menala parameter kernel tahap rendah.