🍑 😷 ☝🏽 Kubernetes में RabbitMQ क्लस्टर का शुभारंभ 👩‍👧‍👧 🍻 🚆

आवेदन के माइक्रोसर्विस संगठन के मामले में, माइक्रोसर्विस के एकीकरण संचार के तंत्र पर पर्याप्त काम टिकी हुई है। इसके अलावा, यह एकीकरण उच्च उपलब्धता के साथ, दोषपूर्ण सहिष्णु होना चाहिए।

हमारे समाधानों में, हम काफ्का, जीआरपीसी और रैबिटएमक्यू के साथ एकीकरण का उपयोग करते हैं।

इस लेख में, हम खरगोशों के समूह के हमारे अनुभव को साझा करेंगे, जिनके नोड्स कुबेरनेट्स पर होस्ट किए गए हैं।

RabbitMQ संस्करण 3.7 से पहले, K8S में इसे क्लस्टर करना बहुत ही तुच्छ कार्य नहीं था, जिसमें कई हैक थे और बहुत सुंदर समाधान नहीं थे। संस्करण 3.6 में, RabbitMQ समुदाय से एक ऑटोक्लेस्टर प्लगइन का उपयोग किया गया था। और 3.7 कुबेरनेट्स पीर डिस्कवरी बैकेंड में दिखाई दिए। यह RabbitMQ की मूल डिलीवरी में प्लग-इन द्वारा बनाया गया है और इसे अलग-अलग विधानसभा और स्थापना की आवश्यकता नहीं है।

हम अंतिम कॉन्फ़िगरेशन का संपूर्ण वर्णन करेंगे, जबकि जो हो रहा है उस पर टिप्पणी करते हुए।

सिद्धांत रूप में

प्लगइन में जीथब पर एक रिपॉजिटरी है , जिसमें मूल उपयोग का एक उदाहरण है ।
यह उदाहरण उत्पादन के लिए अभिप्रेत नहीं है, जो इसके विवरण में स्पष्ट रूप से इंगित किया गया है, और इसके अलावा, इसमें कुछ सेटिंग्स को ठेस में उपयोग के तर्क के विपरीत सेट किया गया है। इसके अलावा, उदाहरण में, भंडारण की दृढ़ता का उल्लेख बिल्कुल नहीं किया गया है, इसलिए किसी भी आपातकालीन स्थिति में हमारा क्लस्टर एक झुंड में बदल जाएगा।

व्यवहार में

अब हम आपको बताएंगे कि आपने स्वयं क्या सामना किया और RabbitMQ को कैसे स्थापित और कॉन्फ़िगर किया जाए।

हमें K8s में एक सेवा के रूप में RabbitMQ के सभी भागों के विन्यास का वर्णन करते हैं। हम तुरंत स्पष्ट कर देंगे कि हमने K8s में एक स्टेटफुलसेट के रूप में RabbitMQ स्थापित किया है। K8s क्लस्टर के प्रत्येक नोड पर, RabbitMQ का एक उदाहरण हमेशा कार्य करेगा (शास्त्रीय क्लस्टर कॉन्फ़िगरेशन में एक नोड)। हम K8s में RabbitMQ कंट्रोल पैनल भी स्थापित करेंगे और क्लस्टर के बाहर इस पैनल को एक्सेस देंगे।

अधिकार और भूमिकाएँ:

rabbitmq_rbac.yaml

--- apiVersion: v1 kind: ServiceAccount metadata: name: rabbitmq --- kind: Role apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: endpoint-reader rules: - apiGroups: [""] resources: ["endpoints"] verbs: ["get"] --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: endpoint-reader subjects: - kind: ServiceAccount name: rabbitmq roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: endpoint-reader

RabbitMQ के लिए उपयोग के अधिकार पूरी तरह से उदाहरण से लिए गए हैं, उनमें कोई बदलाव की आवश्यकता नहीं है। हम अपने क्लस्टर के लिए एक ServiceAccount बनाते हैं और इसे समापन बिंदु K8s को पढ़ने की अनुमति देते हैं।

लगातार भंडारण:

rabbitmq_pv.yaml

 kind: PersistentVolume apiVersion: v1 metadata: name: rabbitmq-data-sigma labels: type: local annotations: volume.alpha.kubernetes.io/storage-class: rabbitmq-data-sigma spec: storageClassName: rabbitmq-data-sigma capacity: storage: 10Gi accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Recycle hostPath: path: "/opt/rabbitmq-data-sigma"

यहां हमने सबसे सरल मामले को लगातार भंडारण के रूप में लिया - hostPath (प्रत्येक K8s नोड पर एक नियमित फ़ोल्डर), लेकिन आप K8 द्वारा समर्थित कई प्रकार के लगातार संस्करणों का उपयोग कर सकते हैं।

rabbitmq_pvc.yaml

 kind: PersistentVolumeClaim apiVersion: v1 metadata: name: rabbitmq-data spec: storageClassName: rabbitmq-data-sigma accessModes: - ReadWriteMany resources: requests: storage: 10Gi

पिछले चरण में बनाए गए वॉल्यूम पर वॉल्यूम क्लेम बनाएं। यह दावा तब स्टेटफुलसेट में एक स्थायी डेटा स्टोर के रूप में उपयोग किया जाएगा।

सेवाएं:

rabbitmq_service.yaml

 kind: Service apiVersion: v1 metadata: name: rabbitmq-internal labels: app: rabbitmq spec: clusterIP: None ports: - name: http protocol: TCP port: 15672 - name: amqp protocol: TCP port: 5672 selector: app: rabbitmq

हम एक आंतरिक हेडलेस सेवा बनाते हैं जिसके माध्यम से पीयर डिस्कवरी प्लगइन काम करेगा।

rabbitmq_service_ext.yaml

 kind: Service apiVersion: v1 metadata: name: rabbitmq labels: app: rabbitmq type: LoadBalancer spec: type: NodePort ports: - name: http protocol: TCP port: 15672 targetPort: 15672 nodePort: 31673 - name: amqp protocol: TCP port: 5672 targetPort: 5672 nodePort: 30673 selector: app: rabbitmq

हमारे क्लस्टर के साथ काम करने के लिए K8s में एप्लिकेशन के लिए, हम एक बैलेंसर सेवा बनाते हैं।

चूँकि हमें K8s के बाहर RabbitMQ क्लस्टर तक पहुँच की आवश्यकता होती है, इसलिए हम NodePort के माध्यम से रोल करते हैं। RabbitMQ 3183 और 30673 बंदरगाहों पर K8s क्लस्टर के किसी भी नोड तक पहुँचने पर उपलब्ध होगा। वास्तविक कार्य में, इसके लिए कोई बहुत आवश्यकता नहीं है। RabbitMQ व्यवस्थापक पैनल का उपयोग करने की सुविधा का प्रश्न।

K8s में NodePort प्रकार के साथ एक सेवा बनाते समय, ClusterIP प्रकार के साथ एक सेवा भी इसे सेवा प्रदान करने के लिए बनाई गई है। इसलिए, K8s में हमारे RabbitMQ के साथ काम करने वाले अनुप्रयोगों को क्लस्टर को amqp पर एक्सेस करने में सक्षम होगा : // rabbitmq: 5672

विन्यास:

rabbitmq_configmap.yaml

 apiVersion: v1 kind: ConfigMap metadata: name: rabbitmq-config data: enabled_plugins: | [rabbitmq_management,rabbitmq_peer_discovery_k8s]. rabbitmq.conf: | cluster_formation.peer_discovery_backend = rabbit_peer_discovery_k8s cluster_formation.k8s.host = kubernetes.default.svc.cluster.local cluster_formation.k8s.port = 443 ### cluster_formation.k8s.address_type = ip cluster_formation.k8s.address_type = hostname cluster_formation.node_cleanup.interval = 10 cluster_formation.node_cleanup.only_log_warning = true cluster_partition_handling = autoheal queue_master_locator=min-masters cluster_formation.randomized_startup_delay_range.min = 0 cluster_formation.randomized_startup_delay_range.max = 2 cluster_formation.k8s.service_name = rabbitmq-internal cluster_formation.k8s.hostname_suffix = .rabbitmq-internal.our-namespace.svc.cluster.local

हम RabbitMQ विन्यास फाइल बनाते हैं। मुख्य जादू।

 enabled_plugins: | [rabbitmq_management,rabbitmq_peer_discovery_k8s].

डाउनलोड के लिए अनुमत लोगों के लिए आवश्यक प्लगइन्स जोड़ें। अब हम K8S में ऑटोमैटिक पीयर डिस्कवरी का उपयोग कर सकते हैं।

 cluster_formation.peer_discovery_backend = rabbit_peer_discovery_k8s

हम सहकर्मी खोज के बैकएंड के रूप में आवश्यक प्लगइन को उजागर करते हैं।

 cluster_formation.k8s.host = kubernetes.default.svc.cluster.local cluster_formation.k8s.port = 443

पता और पोर्ट निर्दिष्ट करें जिसके माध्यम से आप कुबेरनेट्स एपेसेवर तक पहुंच सकते हैं। यहां आप सीधे आईपी-पता निर्दिष्ट कर सकते हैं, लेकिन ऐसा करना अधिक सुंदर होगा।

नेमस्पेस डिफ़ॉल्ट में, एक सेवा आमतौर पर नाम kubernetes के साथ बनाई जाती है जो k8-apiserver के लिए होती है। विभिन्न K8S इंस्टॉलेशन विकल्पों में, नेमस्पेस, सर्विस नेम और पोर्ट अलग हो सकते हैं। यदि किसी विशेष स्थापना में कुछ अलग है, तो आपको इसे तदनुसार ठीक करने की आवश्यकता है।

उदाहरण के लिए, हमें इस तथ्य का सामना करना पड़ रहा है कि कुछ समूहों में सेवा पोर्ट 443 पर है, और कुछ में 6443 पर। यह समझना संभव होगा कि RabbitMQ प्रारंभ लॉग्स में कुछ गलत है, यहां निर्दिष्ट पते का कनेक्शन समय स्पष्ट रूप से वहां पर प्रकाश डाला गया है।

 ### cluster_formation.k8s.address_type = ip cluster_formation.k8s.address_type = hostname

डिफ़ॉल्ट रूप से, उदाहरण IP पते द्वारा RabbitMQ क्लस्टर नोड का पता प्रकार निर्दिष्ट करता है। लेकिन जब आप फली को पुनरारंभ करते हैं, तो उसे हर बार एक नया आईपी मिलता है। आश्चर्य! क्लस्टर पीड़ा में मर रहा है।

पता को होस्टनाम में बदलें। स्टेटफुलसेट हमें पूरे स्टेटफुलसेट के जीवन चक्र के भीतर होस्टनाम की अपरिहार्यता की गारंटी देता है, जो हमें पूरी तरह से सूट करता है।

 cluster_formation.node_cleanup.interval = 10 cluster_formation.node_cleanup.only_log_warning = true

चूंकि जब हम किसी एक नोड को खो देते हैं, तो हम मानते हैं कि यह जल्दी या बाद में ठीक हो जाएगा, हम दुर्गम नोड्स के एक क्लस्टर द्वारा स्व-विलोपन को अक्षम करते हैं। इस स्थिति में, जैसे ही नोड ऑनलाइन लौटता है, वह अपनी पिछली स्थिति को खोए बिना क्लस्टर में प्रवेश करेगा।

 cluster_partition_handling = autoheal

यह पैरामीटर कोरम के नुकसान के मामले में क्लस्टर की क्रियाओं को निर्धारित करता है। यहां आपको केवल इस विषय पर प्रलेखन पढ़ने और अपने लिए समझने की आवश्यकता है कि किसी विशिष्ट उपयोग के मामले के करीब क्या है।

 queue_master_locator=min-masters

नई कतारों के लिए विज़ार्ड का चयन निर्धारित करें। इस सेटिंग के साथ, विज़ार्ड कम से कम संख्याओं के साथ नोड का चयन करेगा, इसलिए कतारें क्लस्टर नोड्स में समान रूप से वितरित की जाएंगी।

 cluster_formation.k8s.service_name = rabbitmq-internal

हम हेडलेस K8s सेवा (पहले हमारे द्वारा बनाई गई) का नाम देते हैं, जिसके माध्यम से RabbitMQ नोड्स एक दूसरे के साथ संवाद करेंगे।

 cluster_formation.k8s.hostname_suffix = .rabbitmq-internal.our-namespace.svc.cluster.local

एक क्लस्टर में संबोधित करने के लिए एक महत्वपूर्ण चीज होस्टनाम है। K8s चूल्हा का FQDN एक संक्षिप्त नाम (rabbitmq-0, rabbitmq-1) + प्रत्यय (डोमेन भाग) के रूप में बनता है। यहाँ हम इस प्रत्यय का संकेत देते हैं। K8S में, यह ऐसा दिखता है । <सेवा का नाम>। <नाम का नाम>। Svc.cluster.l

kube-dns किसी भी अतिरिक्त कॉन्फ़िगरेशन के बिना किसी विशिष्ट पॉड के IP पते में फार्म rabbitmq-0.rabbitmq-internal.our-namespace.svc.cluster.local के नामों को हल करता है, जो होस्टनाम द्वारा क्लस्टरिंग के सभी जादू को संभव बनाता है।

StatefulSet RabbitMQ कॉन्फ़िगरेशन:

rabbitmq_statefulset.yaml

 apiVersion: apps/v1beta1 kind: StatefulSet metadata: name: rabbitmq spec: serviceName: rabbitmq-internal replicas: 3 template: metadata: labels: app: rabbitmq annotations: scheduler.alpha.kubernetes.io/affinity: > { "podAntiAffinity": { "requiredDuringSchedulingIgnoredDuringExecution": [{ "labelSelector": { "matchExpressions": [{ "key": "app", "operator": "In", "values": ["rabbitmq"] }] }, "topologyKey": "kubernetes.io/hostname" }] } } spec: serviceAccountName: rabbitmq terminationGracePeriodSeconds: 10 containers: - name: rabbitmq-k8s image: rabbitmq:3.7 volumeMounts: - name: config-volume mountPath: /etc/rabbitmq - name: rabbitmq-data mountPath: /var/lib/rabbitmq/mnesia ports: - name: http protocol: TCP containerPort: 15672 - name: amqp protocol: TCP containerPort: 5672 livenessProbe: exec: command: ["rabbitmqctl", "status"] initialDelaySeconds: 60 periodSeconds: 10 timeoutSeconds: 10 readinessProbe: exec: command: ["rabbitmqctl", "status"] initialDelaySeconds: 10 periodSeconds: 10 timeoutSeconds: 10 imagePullPolicy: Always env: - name: MY_POD_IP valueFrom: fieldRef: fieldPath: status.podIP - name: HOSTNAME valueFrom: fieldRef: fieldPath: metadata.name - name: NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace - name: RABBITMQ_USE_LONGNAME value: "true" - name: RABBITMQ_NODENAME value: "rabbit@$(HOSTNAME).rabbitmq-internal.$(NAMESPACE).svc.cluster.local" - name: K8S_SERVICE_NAME value: "rabbitmq-internal" - name: RABBITMQ_ERLANG_COOKIE value: "mycookie" volumes: - name: config-volume configMap: name: rabbitmq-config items: - key: rabbitmq.conf path: rabbitmq.conf - key: enabled_plugins path: enabled_plugins - name: rabbitmq-data persistentVolumeClaim: claimName: rabbitmq-data

दरअसल, स्टेटफुलसेट ही। हम दिलचस्प बिंदुओं पर ध्यान देते हैं।

 serviceName: rabbitmq-internal

हम हेडलेस सेवा का नाम लिखते हैं जिसके माध्यम से स्टेटफुलसेट में पॉड्स संवाद करते हैं।

 replicas: 3

क्लस्टर में प्रतिकृतियों की संख्या निर्धारित करें। हमारे देश में, यह K8s काम करने वाले नोड्स की संख्या के बराबर है।

 annotations: scheduler.alpha.kubernetes.io/affinity: > { "podAntiAffinity": { "requiredDuringSchedulingIgnoredDuringExecution": [{ "labelSelector": { "matchExpressions": [{ "key": "app", "operator": "In", "values": ["rabbitmq"] }] }, "topologyKey": "kubernetes.io/hostname" }] } }

जब K8s नोड्स में से एक गिरता है, तो स्टेटफुलसेट सेट में इंस्टेंस की संख्या को संरक्षित करने का प्रयास करता है, इसलिए, यह उसी K8s नोड पर कई हर्ट्स बनाता है। यह व्यवहार पूरी तरह से अवांछनीय है और सिद्धांत रूप में, व्यर्थ है। इसलिए, हम स्टेटफुलसेट से चूल्हा सेट के लिए एक एंटी-एफिनिटी नियम लिखते हैं। हम नियम को कठिन (आवश्यक) बनाते हैं ताकि पॉड्स की योजना बनाते समय क्यूब-शेड्यूलर इसे तोड़ न सकें।

सार सरल है: यह अनुसूचक के लिए (नेमस्पेस के भीतर) एप के साथ एक से अधिक पॉड रखने के लिए मना किया है: प्रत्येक नोड पर खरगोशबिट टैग । हम kubernetes.io/hostname लेबल के मान से नोड्स को अलग करते हैं । अब, यदि किसी कारण से काम करने वाले K8S नोड्स की संख्या स्टेटफुलसेट में प्रतिकृतियों की आवश्यक संख्या से कम है, तो नए प्रतिकृतियां तब तक नहीं बनाई जाएंगी जब तक कि एक मुक्त नोड फिर से प्रकट न हो।

 serviceAccountName: rabbitmq

हम ServiceAccount को पंजीकृत करते हैं, जिसके तहत हमारे पॉड काम करते हैं।

 image: rabbitmq:3.7

RabbitMQ की छवि पूरी तरह से मानक है और डॉकटर हब से ली गई है, इसमें किसी भी पुनर्निर्माण और फ़ाइल संशोधन की आवश्यकता नहीं है।

 - name: rabbitmq-data mountPath: /var/lib/rabbitmq/mnesia

RabbitMQ से लगातार डेटा को / var / lib / rabbitmq / mnesia में संग्रहीत किया जाता है। यहां हम इस फ़ोल्डर में अपना परसेंटेज वॉल्यूम क्लेम करते हैं ताकि चूल्हा / नोड्स या यहां तक कि पूरे स्टेटफुलसेट को रिस्टार्ट करते समय, डेटा (दोनों सर्विस, जिसमें असेंबल्ड क्लस्टर और यूजर डेटा सहित) सुरक्षित और साउंड हो। कुछ उदाहरण हैं जहां संपूर्ण / var / lib / rabbitmq / फ़ोल्डर को लगातार बनाया जाता है। हम इस निष्कर्ष पर पहुंचे कि यह सबसे अच्छा विचार नहीं है, क्योंकि एक ही समय में खरगोश कॉन्फ़िगरेशन द्वारा निर्धारित सभी जानकारी को याद किया जाना शुरू होता है। यही है, कॉन्फ़िगरेशन फ़ाइल में कुछ बदलने के लिए, आपको लगातार भंडारण को साफ करने की आवश्यकता है, जो ऑपरेशन में बहुत असुविधाजनक है।

  - name: HOSTNAME valueFrom: fieldRef: fieldPath: metadata.name - name: NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace - name: RABBITMQ_USE_LONGNAME value: "true" - name: RABBITMQ_NODENAME value: "rabbit@$(HOSTNAME).rabbitmq-internal.$(NAMESPACE).svc.cluster.local"

पर्यावरण चर के इस सेट के साथ, हम पहले RabbitMQ को क्लस्टर सदस्यों के लिए एक पहचानकर्ता के रूप में FQDN नाम का उपयोग करने के लिए कहते हैं, और दूसरी बात, हम इस नाम का प्रारूप निर्धारित करते हैं। प्रारूप को पार्स करते समय पहले वर्णित किया गया था।

 - name: K8S_SERVICE_NAME value: "rabbitmq-internal"

क्लस्टर सदस्यों के बीच संचार के लिए हेडलेस सेवा का नाम।

 - name: RABBITMQ_ERLANG_COOKIE value: "mycookie"

Erlang कुकी की सामग्री क्लस्टर के सभी नोड्स पर समान होनी चाहिए, आपको अपना स्वयं का मूल्य पंजीकृत करने की आवश्यकता है। भिन्न कुकी वाला नोड क्लस्टर में प्रवेश नहीं कर सकता है।

 volumes: - name: rabbitmq-data persistentVolumeClaim: claimName: rabbitmq-data

पहले से बनाए गए लगातार वॉल्यूम क्लेम से मैप किए गए वॉल्यूम को परिभाषित करें।

यह वह जगह है जहां हमें K8s में सेटअप के साथ किया जाता है। परिणाम एक RabbitMQ क्लस्टर है, जो समान रूप से नोड्स के बीच कतारों को वितरित करता है और रनटाइम वातावरण में समस्याओं के लिए प्रतिरोधी है।

यदि क्लस्टर नोड्स में से एक अनुपलब्ध है, तो उस पर मौजूद कतारों को सुलभ होना बंद हो जाएगा, बाकी सब काम करना जारी रखेगा। जैसे ही नोड ऑपरेशन पर लौटता है, यह क्लस्टर में वापस आ जाएगा, और जिन कतारों के लिए यह मास्टर था वह फिर से चालू हो जाएगा, उनमें निहित सभी डेटा को संरक्षित करना (यदि लगातार भंडारण टूट नहीं गया है, तो निश्चित रूप से)। ये सभी प्रक्रियाएं पूरी तरह से स्वचालित हैं और इसमें हस्तक्षेप की आवश्यकता नहीं है।

बोनस: HA को अनुकूलित करें

परियोजनाओं में से एक अति सूक्ष्म अंतर था। आवश्यकताओं ने क्लस्टर में निहित सभी डेटा का पूर्ण मिररिंग देखा। यह आवश्यक है ताकि ऐसी स्थिति में जहां कम से कम एक क्लस्टर नोड चालू हो, सब कुछ एप्लिकेशन के दृष्टिकोण से काम करना जारी रखता है। इस पल का K8 से कोई लेना-देना नहीं है, हम इसे केवल एक मिनी हाउ-टू के रूप में वर्णित करते हैं।

पूर्ण हा को सक्षम करने के लिए, आपको व्यवस्थापन -> नीतियां टैब पर RabbitMQ डैशबोर्ड में एक नीति बनाने की आवश्यकता है। नाम मनमाना है, पैटर्न खाली है (सभी कतारों), परिभाषाओं में दो मापदंडों को जोड़ते हैं: हा-मोड: सभी , हा-सिंक-मोड: स्वचालित ।

उसके बाद, क्लस्टर में बनाई गई सभी कतारें उच्च उपलब्धता मोड में होंगी: यदि मास्टर नोड अनुपलब्ध है, तो दास में से एक स्वचालित रूप से नए विज़ार्ड द्वारा चुना जाएगा। और कतार में आने वाले डेटा को क्लस्टर के सभी नोड्स पर प्रतिबिंबित किया जाएगा। जो, वास्तव में, प्राप्त करने के लिए आवश्यक था।

RabbitMQ में HA के बारे में और अधिक पढ़ें

उपयोगी साहित्य:

अ छा!

Kubernetes में RabbitMQ क्लस्टर का शुभारंभ