Rook या नहीं - यह सवाल है

इस महीने की शुरुआत में, 3 मई, "कुबेरनेट्स में वितरित डेटा गोदामों के लिए प्रबंधन प्रणाली" की एक बड़ी रिलीज़ की घोषणा की गई थी - नुका 1.0.0 । एक साल से अधिक समय पहले, हमने पहले से ही रूक का एक सामान्य अवलोकन प्रकाशित किया था । फिर हमें अभ्यास में इसके उपयोग के अनुभव के बारे में बात करने के लिए कहा गया - और अब, परियोजना के इतिहास में इस तरह के एक महत्वपूर्ण मील के पत्थर के लिए, हम अपने संचित छापों को साझा करने की कृपा कर रहे हैं।

संक्षेप में, रूक कुबेरनेट्स के लिए ऑपरेटरों का एक सेट है जो कि सीफ, एजफास, मिनियो, कैसेंड्रा, कॉकरोचडीबी जैसे भंडारण समाधानों की तैनाती, प्रबंधन और स्वचालित वसूली का पूरा नियंत्रण लेते हैं।

फिलहाल, सबसे विकसित (और केवल एक स्थिर चरण में) समाधान रूक-सेफ-ऑपरेटर है ।

ध्यान दें : सेफ से संबंधित Rook 1.0.0 की रिलीज़ में महत्वपूर्ण परिवर्तनों के बीच, सेफ नॉटिलस समर्थन और सीएफएचएस या आरजीडब्ल्यू बाल्टी के लिए एनएफएस का उपयोग करने की क्षमता को नोट किया जा सकता है। दूसरों के बीच, बीटा स्तर के लिए एएफएफएस समर्थन का "परिपक्व" बाहर खड़ा है।

तो, इस लेख में हम:

• रूबर्न को कुबेरनेट्स क्लस्टर में तैनात करने के लिए रूक का उपयोग करने में हमें क्या फायदे मिलते हैं, इस सवाल का जवाब दें;
• उत्पादन में रूक का उपयोग करने का साझा अनुभव और इंप्रेशन;
• हम आपको बताएंगे कि हम क्यों रुके और उसके लिए हमारी योजनाएं "हां!" कहें।

आइए सामान्य अवधारणाओं और सिद्धांत के साथ शुरू करें।

"मुझे एक रूक में एक फायदा है!" (अज्ञात शतरंज खिलाड़ी)

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

- एक सीएचएफएफएस क्लस्टर में तैनात करना चाहते हैं? बस एक yaml फ़ाइल लिखें!
- क्या? S3 API के साथ ऑब्जेक्ट स्टोर परिनियोजित करना चाहते हैं? बस एक दूसरी yaml फ़ाइल लिखें!

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

आइए ऑब्जेक्ट स्टोर बनाने के उदाहरण का उपयोग करके बारीकियों को देखें, या CephObjectStoreUser ।

 apiVersion: ceph.rook.io/v1 kind: CephObjectStore metadata: name: {{ .Values.s3.crdName }} namespace: kube-rook spec: metadataPool: failureDomain: host replicated: size: 3 dataPool: failureDomain: host erasureCoded: dataChunks: 2 codingChunks: 1 gateway: type: s3 sslCertificateRef: port: 80 securePort: instances: 1 allNodes: false --- apiVersion: ceph.rook.io/v1 kind: CephObjectStoreUser metadata: name: {{ .Values.s3.crdName }} namespace: kube-rook spec: store: {{ .Values.s3.crdName }} displayName: {{ .Values.s3.username }} 

सूची में दिए गए पैरामीटर काफी मानक हैं और टिप्पणियों की आवश्यकता होने की संभावना नहीं है, लेकिन आपको उन लोगों पर विशेष ध्यान देना चाहिए जो टेम्पलेट चर में हाइलाइट किए गए हैं।

कार्य की सामान्य योजना इस तथ्य से नीचे आती है कि YAML फ़ाइल के माध्यम से हम "ऑर्डर" संसाधनों, जिसके लिए ऑपरेटर आवश्यक आदेशों को निष्पादित करता है और हमें "वास्तविक नहीं" रहस्य देता है, जिसके साथ हम काम करना जारी रख सकते हैं (नीचे देखें) । और जिन चरों को ऊपर दर्शाया गया है, उनमें से कमांड और सीक्रेट नाम की रचना होगी।

यह किस तरह की टीम है? ऑब्जेक्ट स्टोरेज के लिए एक उपयोगकर्ता बनाते समय, पॉड के अंदर Rook स्टेटमेंट निम्न कार्य करेगा:

 radosgw-admin user create --uid="rook-user" --display-name="{{ .Values.s3.username }}" 

इस आदेश का परिणाम एक JSON संरचना होगी:

 { "user_id": "rook-user", "display_name": "{{ .Values.s3.username }}", "keys": [ { "user": "rook-user", "access_key": "NRWGT19TWMYOB1YDBV1Y", "secret_key": "gr1VEGIV7rxcP3xvXDFCo4UDwwl2YoNrmtRlIAty" } ], ... } 

Keys वह है जो भविष्य के अनुप्रयोगों को एस 3 एपीआई के माध्यम से ऑब्जेक्ट स्टोरेज तक पहुंचने की आवश्यकता होगी। रूक ऑपरेटर कृपया उन्हें चुनता है और rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }} नाम के साथ एक गुप्त के रूप में अपने नामस्थान में डालता है।

इस रहस्य से डेटा का उपयोग करने के लिए, उन्हें पर्यावरण चर के रूप में कंटेनर में जोड़ें। एक उदाहरण के रूप में, मैं नौकरी के लिए एक खाका दूंगा, जिसमें हम प्रत्येक उपयोगकर्ता पर्यावरण के लिए स्वचालित रूप से बाल्टियाँ बनाते हैं:

 {{- range $bucket := $.Values.s3.bucketNames }} apiVersion: batch/v1 kind: Job metadata: name: create-{{ $bucket }}-bucket-job annotations: "helm.sh/hook": post-install "helm.sh/hook-weight": "2" spec: template: metadata: name: create-{{ $bucket }}-bucket-job spec: restartPolicy: Never initContainers: - name: waitdns image: alpine:3.6 command: ["/bin/sh", "-c", "while ! getent ahostsv4 rook-ceph-rgw-{{ $.Values.s3.crdName }}; do sleep 1; done" ] - name: config image: rook/ceph:v1.0.0 command: ["/bin/sh", "-c"] args: ["s3cmd --configure --access_key=$(ACCESS-KEY) --secret_key=$(SECRET-KEY) -s --no-ssl --dump-config | tee /config/.s3cfg"] volumeMounts: - name: config mountPath: /config env: - name: ACCESS-KEY valueFrom: secretKeyRef: name: rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }} key: AccessKey - name: SECRET-KEY valueFrom: secretKeyRef: name: rook-ceph-object-user-{{ $.Values.s3.crdName }}-{{ $.Values.s3.username }} key: SecretKey containers: - name: create-bucket image: rook/ceph:v1.0.0 command: - "s3cmd" - "mb" - "--host=rook-ceph-rgw-{{ $.Values.s3.crdName }}" - "--host-bucket= " - "s3://{{ $bucket }}" ports: - name: s3-no-sll containerPort: 80 volumeMounts: - name: config mountPath: /root volumes: - name: config emptyDir: {} --- {{- end }} 

इस जॉब में सूचीबद्ध सभी गतिविधियां कुबेरनेट्स से परे जाने के बिना की गई थीं। YAML फाइलों में वर्णित संरचनाएं गिट रिपॉजिटरी में बदल जाती हैं और बार-बार पुन: उपयोग की जाती हैं। इसमें हमें DevOps इंजीनियरों के लिए एक विशाल प्लस और संपूर्ण रूप से CI / CD प्रक्रिया दिखाई देती है।

रूक और रैडोस के साथ जॉय तक

सीएफएच + आरबीडी के एक गुच्छा का उपयोग फली को बढ़ते संस्करणों पर कुछ प्रतिबंध लगाता है।

विशेष रूप से, नामस्थान के पास सेफ तक पहुंचने के लिए एक रहस्य होना चाहिए ताकि राज्य के आवेदन कार्य कर सकें। यदि आपके नामस्थानों में 2-3 वातावरण हैं, तो यह ठीक है: आप गुप्त रूप से कॉपी करके जा सकते हैं। लेकिन क्या होगा यदि प्रत्येक डेवलपर सुविधा अपने नामस्थान के साथ एक अलग वातावरण बनाती है?

हमने शेल-ऑपरेटर की मदद से इस समस्या को हल किया, जिसने स्वचालित रूप से नए नामस्थान पर रहस्यों की प्रतिलिपि बनाई (इस तरह के हुक का एक उदाहरण इस लेख में वर्णित है)।

 #! /bin/bash if [[ $1 == “--config” ]]; then cat <<EOF {"onKubernetesEvent":[ {"name": "OnNewNamespace", "kind": "namespace", "event": ["add"] } ]} EOF else NAMESPACE=$(kubectl get namespace -o json | jq '.items | max_by( .metadata.creationTimestamp ) | .metadata.name') kubectl -n ${CEPH_SECRET_NAMESPACE} get secret ${CEPH_SECRET_NAME} -o json | jq ".metadata.namespace=\"${NAMESPACE}\"" | kubectl apply -f - fi 

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

रूक स्वचालित रूप से कई समस्याओं को हल करता है, जो हमें नई परियोजनाओं में इसका उपयोग करने के लिए प्रोत्साहित करता है।

रूक की घेराबंदी

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

 $ helm fetch rook-master/rook-ceph --untar --version 1.0.0 

rook-ceph/values.yaml में कई अलग rook-ceph/values.yaml अलग सेटिंग्स पा सकते हैं। फाइल। सबसे महत्वपूर्ण बात, एजेंटों और खोज के लिए सहिष्णुता निर्दिष्ट करें। आप taints / tolerations तंत्र का उपयोग क्यों कर सकते हैं, हमने इस लेख में विस्तार से वर्णित किया है।

संक्षेप में, हम नहीं चाहते हैं कि क्लाइंट एप्लिकेशन के साथ पॉड्स उसी नोड्स पर स्थित हों जहां डेटा स्टोरेज के लिए डिस्क स्थित हैं। कारण सरल है: इस तरह से रूक एजेंटों का काम आवेदन को प्रभावित नहीं करेगा।

तो, rook-ceph/values.yaml पसंदीदा संपादक के rook-ceph/values.yaml फ़ाइल rook-ceph/values.yaml । निम्नलिखित को अंत में जोड़ें:

 discover: toleration: NoExecute tolerationKey: node-role/storage agent: toleration: NoExecute tolerationKey: node-role/storage mountSecurityMode: Any 

डेटा भंडारण के लिए आरक्षित प्रत्येक नोड के लिए, संबंधित टेंट जोड़ें:

 $ kubectl taint node ${NODE_NAME} node-role/storage="":NoExecute 

फिर कमांड के साथ हेलम-चार्ट स्थापित करें:

 $ helm install --namespace ${ROOK_NAMESPACE} ./rook-ceph 

अब आपको एक क्लस्टर बनाने और ओएसडी के स्थान को इंगित करने की आवश्यकता है:

 apiVersion: ceph.rook.io/v1 kind: CephCluster metadata: clusterName: "ceph" finalizers: - cephcluster.ceph.rook.io generation: 1 name: rook-ceph spec: cephVersion: image: ceph/ceph:v13 dashboard: enabled: true dataDirHostPath: /var/lib/rook/osd mon: allowMultiplePerNode: false count: 3 network: hostNetwork: true rbdMirroring: workers: 1 placement: all: tolerations: - key: node-role/storage operator: Exists storage: useAllNodes: false useAllDevices: false config: osdsPerDevice: "1" storeType: filestore resources: limits: memory: "1024Mi" requests: memory: "1024Mi" nodes: - name: host-1 directories: - path: "/mnt/osd" - name: host-2 directories: - path: "/mnt/osd" - name: host-3 directories: - path: "/mnt/osd" 

HEALTH_OK स्थिति जांचें - HEALTH_OK देखने की HEALTH_OK :

 $ kubectl -n ${ROOK_NAMESPACE} exec $(kubectl -n ${ROOK_NAMESPACE} get pod -l app=rook-ceph-operator -o name -o jsonpath='{.items[0].metadata.name}') -- ceph -s 

उसी समय, जाँचें कि क्लाइंट एप्लिकेशन के साथ पॉड्स सेफ के लिए आरक्षित नोड्स में नहीं मिलता है:

 $ kubectl -n ${APPLICATION_NAMESPACE} get pods -o custom-columns=NAME:.metadata.name,NODE:.spec.nodeName 

इसके अलावा वैकल्पिक घटक कॉन्फ़िगर किए गए हैं। उनके बारे में अधिक जानकारी प्रलेखन में इंगित की गई है। प्रशासन के लिए, हम दृढ़ता से डैशबोर्ड और टूलबॉक्स स्थापित करने की सलाह देते हैं।

Rooks and Hooks: क्या हर चीज के लिए पर्याप्त है?

जैसा कि आप देख सकते हैं, रूक का विकास जोरों पर है। लेकिन फिर भी ऐसी समस्याएं हैं जो हमें सिफ के मैनुअल कॉन्फ़िगरेशन को पूरी तरह से त्यागने की अनुमति नहीं देते हैं:

• कोई भी रूक चालक घुड़सवार ब्लॉकों के उपयोग पर मेट्रिक्स का निर्यात नहीं कर सकता है , जो हमें निगरानी से वंचित करता है।
• Flexvolume और CSI वॉल्यूम (समान RBD के विपरीत) का आकार बदलना नहीं जानते हैं , इसलिए Rook एक उपयोगी (और कभी-कभी गंभीर रूप से आवश्यक!) टूल खो देता है।
• रूक अभी भी नियमित रूप से सिफ के रूप में लचीला नहीं है। अगर हम SSD पर संग्रहीत होने वाले CephFS मेटाडेटा के लिए पूल को कॉन्फ़िगर करना चाहते हैं, और स्वयं HDD पर डेटा, हमें मैन्युअल रूप से CRUSH मानचित्रों में अलग डिवाइस समूहों को पंजीकृत करने की आवश्यकता होगी।
• इस तथ्य के बावजूद कि रूक-सेफ-ऑपरेटर को स्थिर माना जाता है, फिलहाल सीएफएच को संस्करण 13 से 14 तक अपडेट करते समय कुछ समस्याएं हैं।

निष्कर्ष

"अब रूक को बाहरी दुनिया से मोहरे द्वारा बंद कर दिया गया है, लेकिन हमें विश्वास है कि एक दिन वह पार्टी में निर्णायक भूमिका निभाएगा!" (इस लेख के लिए विशेष रूप से एक उद्धरण का आविष्कार किया गया था)

रूक परियोजना ने निस्संदेह हमारे दिलों को जीत लिया है - हम मानते हैं कि [अपने सभी पेशेवरों और विपक्षों के साथ] यह निश्चित रूप से आपके ध्यान का हकदार है।

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

पुनश्च

हमारे ब्लॉग में भी पढ़ें:

• " रूब एक" स्व-सेवा "कुबेरनेट्स के लिए डेटा वेयरहाउस " है;
• " हम सिफ के आधार पर कुबेरनेट्स में प्रावधान के साथ लगातार भंडारण बनाते हैं ";
• " डेटाबेस और कुबेरनेट्स (समीक्षा और वीडियो रिपोर्ट) ";
• " शेल-ऑपरेटर का परिचय: कुबेरनेट्स के लिए ऑपरेटर बनाना और भी आसान ";
• " कुबेरनेट्स के लिए ऑपरेटर: स्टेटफुल एप्लिकेशन कैसे चलाएं ।"