🥇Penghijrahan lancar RabbitMQ ke Kubernetes

RabbitMQ ialah broker mesej yang ditulis dalam Erlang yang membolehkan anda mengatur kluster failover dengan replikasi data penuh merentas berbilang nod, di mana setiap nod boleh melayani permintaan baca dan tulis. Mempunyai banyak kluster Kubernetes dalam operasi pengeluaran, kami menyokong sejumlah besar pemasangan RabbitMQ dan berhadapan dengan keperluan untuk memindahkan data dari satu kluster ke kluster yang lain tanpa masa henti.

Kami memerlukan operasi ini dalam sekurang-kurangnya dua kes:

Memindahkan data daripada kluster RabbitMQ yang tidak terletak di Kubernetes kepada kluster baharu – sudah "dikubernetkan" (iaitu beroperasi dalam pod K8s) -.
Penghijrahan RabbitMQ dalam Kubernetes dari satu ruang nama ke ruang nama yang lain (contohnya, jika litar dihadkan oleh ruang nama, kemudian untuk memindahkan infrastruktur dari satu litar ke litar lain).

Resipi yang dicadangkan dalam artikel itu tertumpu pada situasi (tetapi tidak terhad kepada mereka sama sekali) di mana terdapat kluster RabbitMQ lama (contohnya, daripada 3 nod), terletak sama ada dalam K8 atau pada beberapa pelayan lama. Aplikasi yang dihoskan pada Kubernetes (sudah ada atau pada masa hadapan) berfungsi dengannya:

... dan kami berhadapan dengan tugas untuk memindahkannya ke pengeluaran baharu di Kubernetes.

Pertama, pendekatan umum kepada migrasi itu sendiri akan diterangkan, dan selepas itu butiran teknikal pelaksanaannya akan diterangkan.

Algoritma migrasi

Peringkat pertama, awal, sebelum sebarang tindakan adalah untuk memastikan mod ketersediaan tinggi didayakan dalam pemasangan RabbitMQ lama (HA). Sebabnya jelas - kami tidak mahu kehilangan sebarang data. Untuk menjalankan semakan ini, anda boleh pergi ke panel pentadbir RabbitMQ dan dalam tab Admin → Polisi pastikan nilai ditetapkan ha-mode: all:

Langkah seterusnya ialah menaikkan kluster RabbitMQ baharu dalam pod Kubernetes (dalam kes kami, contohnya, terdiri daripada 3 nod, tetapi bilangannya mungkin berbeza).

Selepas ini, kami menggabungkan kluster RabbitMQ lama dan baharu, mendapatkan satu kluster (daripada 6 nod):

Proses penyegerakan data antara kelompok RabbitMQ lama dan baharu dimulakan. Setelah semua data disegerakkan antara semua nod dalam kluster, kita boleh menukar aplikasi untuk menggunakan kluster baharu:

Selepas operasi ini, sudah cukup untuk mengalih keluar nod lama daripada kelompok RabbitMQ, dan langkah itu boleh dianggap selesai:

Kami telah menggunakan skim ini berkali-kali dalam pengeluaran. Walau bagaimanapun, untuk kemudahan kami sendiri, kami melaksanakannya dalam sistem khusus yang mengedarkan konfigurasi RMQ standard merentas berbilang kluster Kubernetes (bagi mereka yang ingin tahu: kita bercakap tentang pengendali tambahantentang yang kita baru diberitahu). Di bawah ini kami akan membentangkan arahan individu yang boleh digunakan oleh sesiapa sahaja pada pemasangan mereka untuk mencuba penyelesaian yang dicadangkan dalam tindakan.

Mari cuba dalam amalan

Keperluan

Butirannya sangat mudah:

Kelompok Kubernetes (minikube juga akan berfungsi);
Kelompok RabbitMQ (boleh digunakan pada logam kosong, dan dibuat seperti kelompok biasa dalam Kubernetes daripada carta Helm rasmi).

Untuk contoh di bawah, saya menggunakan RMQ ke Kubernetes dan memanggilnya rmq-old.

Persediaan berdiri

1. Muat turun carta Helm dan editnya sedikit:

helm fetch --untar stable/rabbitmq-ha

Untuk kemudahan, kami menetapkan kata laluan, ErlangCookie dan berpolitik ha-allsupaya secara lalai baris gilir disegerakkan antara semua nod kelompok RMQ:

rabbitmqPassword: guest
rabbitmqErlangCookie: mae9joopaol7aiVu3eechei2waiGa2we
definitions:
policies: |-
  {
    "name": "ha-all",
    "pattern": ".*",
    "vhost": "/",
    "definition": {
      "ha-mode": "all",
      "ha-sync-mode": "automatic",
      "ha-sync-batch-size": 81920
    }
  }

2. Pasang carta:

helm install . --name rmq-old --namespace rmq-old

3. Pergi ke panel pentadbir RabbitMQ, buat baris gilir baharu dan tambah beberapa mesej. Mereka akan diperlukan supaya selepas penghijrahan kami dapat memastikan bahawa semua data disimpan dan kami tidak kehilangan apa-apa:

Bangku ujian sudah sedia: kami mempunyai RabbitMQ "lama" dengan data yang perlu dipindahkan.

Menghijrahkan kelompok RabbitMQ

1. Mula-mula, mari gunakan RabbitMQ baharu kawan ruang nama dengan sama ErlangCookie dan kata laluan untuk pengguna. Untuk melakukan ini, kami akan melaksanakan operasi yang diterangkan di atas, menukar arahan akhir untuk memasang RMQ kepada yang berikut:

helm install . --name rmq-new --namespace rmq-new

2. Sekarang anda perlu menggabungkan kluster baharu dengan kluster lama. Untuk melakukan ini, pergi ke setiap pod baru RabbitMQ dan laksanakan arahan:

export OLD_RMQ=rabbit@rmq-old-rabbitmq-ha-0.rmq-old-rabbitmq-ha-discovery.rmq-old.svc.cluster.local && 
  rabbitmqctl stop_app && 
  rabbitmqctl join_cluster $OLD_RMQ && 
  rabbitmqctl start_app

Dalam pembolehubah OLD_RMQ alamat salah satu nod ditemui tua Kelompok RMQ.

Perintah ini akan menghentikan nod semasa baru Kluster RMQ, pasangkannya pada kluster lama dan lancarkan semula.

3. Kelompok RMQ 6 nod sedia:

Anda mesti menunggu sementara mesej disegerakkan antara semua nod. Tidak sukar untuk meneka bahawa masa penyegerakan mesej bergantung pada kapasiti perkakasan di mana kluster digunakan dan pada bilangan mesej. Dalam senario yang diterangkan, terdapat hanya 10 daripadanya, jadi data disegerakkan serta-merta, tetapi dengan bilangan mesej yang cukup besar, penyegerakan boleh bertahan selama berjam-jam.

Jadi, status penyegerakan:

ia adalah +5 bermakna mesej sudah masuk lebih lagi pada 5 nod (kecuali apa yang ditunjukkan dalam medan Node). Oleh itu, penyegerakan berjaya.

4. Yang tinggal hanyalah menukar alamat RMQ dalam aplikasi kepada kluster baharu (tindakan khusus di sini bergantung pada tindanan teknologi yang anda gunakan dan khusus aplikasi lain), selepas itu anda boleh mengucapkan selamat tinggal kepada yang lama.

Untuk operasi terakhir (iaitu sudah selepas menukar aplikasi kepada kluster baharu) pergi ke setiap nod tua cluster dan laksanakan arahan:

rabbitmqctl stop_app
rabbitmqctl reset

Kelompok "terlupa" tentang nod lama: anda boleh memadamkan RMQ lama, di mana langkah itu akan selesai.

Nota: Jika anda menggunakan RMQ dengan sijil, maka tiada apa-apa perubahan pada asasnya - proses pemindahan akan dijalankan sama.

Penemuan

Skim yang diterangkan sesuai untuk hampir semua kes apabila kita perlu memindahkan RabbitMQ atau hanya berpindah ke kluster baharu.

Dalam kes kami, kesukaran timbul hanya sekali, apabila RMQ diakses dari banyak tempat, dan kami tidak mempunyai peluang untuk menukar alamat RMQ kepada yang baru di mana-mana. Kemudian kami melancarkan RMQ baharu dalam ruang nama yang sama dengan label yang sama supaya ia akan berada di bawah perkhidmatan sedia ada dan Ingress, dan apabila melancarkan pod kami memanipulasi label dengan tangan, mengalih keluarnya pada permulaan supaya permintaan tidak jatuh pada RMQ kosong, dan tambahkannya semula selepas mesej disegerakkan.

Kami menggunakan strategi yang sama apabila mengemas kini RabbitMQ kepada versi baharu dengan konfigurasi yang diubah - semuanya berfungsi seperti jam.

PS

Sebagai kesinambungan logik bahan ini, kami sedang menyediakan artikel tentang MongoDB (penghijrahan daripada pelayan perkakasan ke Kubernetes) dan MySQL (cara kami menyediakan DBMS ini di dalam Kubernetes). Mereka akan diterbitkan dalam beberapa bulan akan datang.

Penghijrahan RabbitMQ yang lancar ke Kubernetes