Postgres मंगलबार नम्बर 5: "PostgreSQL र Kubernetes। CI/CD। परीक्षण स्वचालन"

गत वर्षको अन्त्यमा, रूसी PostgreSQL समुदायको अर्को प्रत्यक्ष प्रसारण भयो #RuPostgres, जसको समयमा यसको सह-संस्थापक निकोलाई समोख्भालोभले फ्ल्यान्ट प्राविधिक निर्देशक दिमित्री स्टोल्यारोभसँग कुबेरनेटेसको सन्दर्भमा यस DBMS बारे कुरा गरे।

हामी यस छलफलको मुख्य भागको ट्रान्सक्रिप्ट प्रकाशित गर्दैछौं, र मा सामुदायिक YouTube च्यानल पूरा भिडियो पोस्ट गरिएको छ:

डाटाबेस र Kubernetes

NS: हामी आज भ्याकुम र चेकपोइन्टहरूको बारेमा कुरा गर्दैनौं। हामी Kubernetes को बारेमा कुरा गर्न चाहन्छौं। मलाई थाहा छ तपाईसँग धेरै वर्षको अनुभव छ। मैले तपाइँका भिडियोहरू हेरेँ र ती मध्ये केही पुन: हेरेँ... सीधा कुरामा जाऔं: किन Postgres वा MySQL K8s मा?

DC: यस प्रश्नको निश्चित जवाफ छैन र हुन सक्दैन। तर सामान्यतया, यो सादगी र सुविधा हो... सम्भाव्यता। सबैले व्यवस्थित सेवाहरू चाहन्छन्।

NS: कसरी RDSघरमा मात्र ?

DC: हो: RDS जस्तै, जहाँ पनि।

NS: "कहीँ पनि" राम्रो बिन्दु हो। ठूला कम्पनीहरूमा, सबै चीजहरू विभिन्न ठाउँहरूमा अवस्थित छन्। त्यसोभए, यदि यो ठूलो कम्पनी हो भने, किन तयार समाधान लिनुहुन्न? उदाहरण को लागी, Nutanix को आफ्नै विकास छ, अन्य कम्पनीहरु (VMware...) को समान "RDS, केवल घर मा" छ।

DC: तर हामी छुट्टै कार्यान्वयनको बारेमा कुरा गर्दैछौं जुन केहि सर्तहरूमा मात्र काम गर्दछ। र यदि हामी Kubernetes को बारे मा कुरा गर्दै हुनुहुन्छ भने, त्यहाँ पूर्वाधार को एक विशाल विविधता छ (जो K8s मा हुन सक्छ)। अनिवार्य रूपमा यो क्लाउडमा API को लागि मानक हो ...

NS: यो पनि नि: शुल्क छ!

DC: यो त्यति महत्त्वपूर्ण छैन। बजारको धेरै ठूलो खण्डको लागि स्वतन्त्रता महत्त्वपूर्ण छ। अरू केही महत्त्वपूर्ण छ... तपाईंले रिपोर्ट सम्झनु भएको छ "डाटाबेस र Kubernetes"?

NS: हो।

DC: मैले बुझें कि यो धेरै अस्पष्ट रूपमा प्राप्त भएको थियो। केही मानिसहरूले सोचेका थिए कि मैले भनेको थिएँ: "साथीहरू, सबै डाटाबेसहरू Kubernetes मा लैजाऔं!", जबकि अरूले निर्णय गरे कि यी सबै भयानक साइकलहरू थिए। तर म पूर्णतया फरक कुरा भन्न चाहन्थे: "हेर्नुहोस् के भइरहेको छ, त्यहाँ के समस्याहरू छन् र तिनीहरूलाई कसरी समाधान गर्न सकिन्छ। के हामीले अब Kubernetes डाटाबेसहरू प्रयोग गर्नुपर्छ? उत्पादन? ठिक छ, यदि तपाईलाई मनपर्छ ... केहि चीजहरू गर्न। तर एक देवको लागि, म भन्न सक्छु कि म यसलाई सिफारिस गर्छु। एक dev को लागि, वातावरण सिर्जना / मेटाउने गतिशीलता धेरै महत्त्वपूर्ण छ।"

NS: dev द्वारा, के तपाईको मतलब उत्पादन नभएका सबै वातावरण हो? स्टेजिङ, QA…

DC: यदि हामी perf स्ट्यान्डको बारेमा कुरा गर्दैछौं, तब सायद होइन, किनभने त्यहाँ आवश्यकताहरू विशिष्ट छन्। यदि हामी विशेष केसहरूको बारेमा कुरा गर्दैछौं जहाँ स्टेजिंगको लागि धेरै ठूलो डाटाबेस चाहिन्छ, तब सायद छैन... यदि यो स्थिर, लामो समयसम्म रहने वातावरण हो भने, K8s मा डाटाबेस राखेर के फाइदा हुन्छ?

NS: कुनै पनि छैन। तर हामीले स्थिर वातावरण कहाँ देख्छौं? एक स्थिर वातावरण भोलि अप्रचलित हुनेछ।

DC: स्टेजिङ स्थिर हुन सक्छ। हामीसँग ग्राहकहरू छन् ...

NS: हो, मसँग पनि छ। यदि तपाईंसँग 10 TB डाटाबेस र 200 GB स्टेजिङ छ भने यो ठूलो समस्या हो...

DC: मसँग धेरै राम्रो केस छ! स्टेजिङमा त्यहाँ उत्पादन डाटाबेस छ जसमा परिवर्तनहरू गरिन्छ। र त्यहाँ एक बटन छ: "उत्पादनमा रोल आउट"। यी परिवर्तनहरू - डेल्टाहरू - थपिएका छन् (यस्तो देखिन्छ कि तिनीहरू केवल एपीआई मार्फत सिंक्रोनाइज गरिएको छ) उत्पादनमा। यो एक धेरै विदेशी विकल्प छ।

NS: मैले उपत्यकाका स्टार्टअपहरू देखेको छु जो आरडीएस वा हेरोकुमा पनि बसिरहेका छन् - यी २-३ वर्ष अघिका कथाहरू हुन् - र उनीहरूले आफ्नो ल्यापटपमा डम्प डाउनलोड गर्छन्। किनभने डाटाबेस अझै 2 GB मात्र छ, र ल्यापटपमा ठाउँ छ। त्यसपछि तिनीहरू सबैका लागि अतिरिक्त डिस्कहरू किन्छन् ताकि तिनीहरूसँग विभिन्न विकासहरू पूरा गर्न 3 डाटाबेसहरू छन्। यस्तो पनि हुने गर्छ । मैले यो पनि देखे कि तिनीहरू स्टेजिङमा उत्पादन प्रतिलिपि गर्न डराउँदैनन् - यो धेरै कम्पनीमा निर्भर गर्दछ। तर मैले यो पनि देखें कि तिनीहरू धेरै डराउँछन्, र तिनीहरूसँग प्रायः पर्याप्त समय र हात हुँदैन। तर हामी यस विषयमा जानु अघि, म कुबेरनेटको बारेमा सुन्न चाहन्छु। के म सही रूपमा बुझ्छु कि कोही पनि उत्पादनमा छैन?

DC: हामीसँग उत्पादनमा साना डाटाबेसहरू छन्। हामी दसौं गिगाबाइट र गैर-महत्वपूर्ण सेवाहरूको भोल्युमको बारेमा कुरा गर्दैछौं जसको लागि हामी प्रतिकृतिहरू बनाउन अल्छी थियौं (र त्यहाँ त्यस्तो कुनै आवश्यकता छैन)। र Kubernetes अन्तर्गत सामान्य भण्डारण छ कि प्रदान गरियो। यो डाटाबेसले भर्चुअल मेसिनमा काम गर्‍यो - सशर्त रूपमा VMware मा, भण्डारण प्रणालीको शीर्षमा। हामीले यसलाई भित्र राख्यौं PV र अब हामी यसलाई मेसिनबाट मेसिनमा स्थानान्तरण गर्न सक्छौं।

NS: यस साइजको डाटाबेसहरू, 100 GB सम्म, राम्रो डिस्क र राम्रो नेटवर्कमा केही मिनेटमा रोल आउट गर्न सकिन्छ, हैन? 1 GB प्रति सेकेन्डको गति अब विदेशी छैन।

DC: हो, रैखिक सञ्चालनका लागि यो समस्या होइन।

NS: ठीक छ, हामीले उत्पादनको बारेमा मात्र सोच्नु पर्छ। र यदि हामी गैर-उत्पादन वातावरणको लागि Kubernetes विचार गर्दैछौं, हामीले के गर्नुपर्छ? म त्यो Zalando मा देख्छु अपरेटर गर्नुहोस्, क्रन्ची मा काट्ने, त्यहाँ केहि अन्य विकल्पहरू छन्। र त्यहाँ छ OnGres - यो स्पेनबाट हाम्रो असल साथी अल्भारो हो: तिनीहरूले के गर्छन् अनिवार्य रूपमा मात्र होइन अपरेटरर सम्पूर्ण वितरण (StackGres), जसमा, पोस्टग्रेस आफैं बाहेक, तिनीहरूले ब्याकअप, दूत प्रोक्सी पनि भर्ने निर्णय गरे।

DC: केका लागि राजदूत ? Postgres ट्राफिक सन्तुलन विशेष गरी?

NS: हो। त्यो हो, तिनीहरूले यसलाई यसरी हेर्छन्: यदि तपाईंले लिनक्स वितरण र कर्नेल लिनुभयो भने, त्यसपछि नियमित PostgreSQL कर्नेल हो, र तिनीहरू क्लाउड-अनुकूल र Kubernetes मा चल्ने वितरण गर्न चाहन्छन्। तिनीहरूले कम्पोनेन्टहरू (ब्याकअप, आदि) सँगै राख्छन् र तिनीहरूलाई डिबग गर्छन् ताकि तिनीहरूले राम्रोसँग काम गर्छन्।

DC: अति उत्तम! अनिवार्य रूपमा यो तपाइँको आफ्नै व्यवस्थित Postgres सिर्जना गर्न सफ्टवेयर हो।

NS: लिनक्स वितरणमा अनन्त समस्याहरू छन्: कसरी ड्राइभरहरू बनाउने ताकि सबै हार्डवेयर समर्थित छ। र उनीहरूले कुबेरनेटमा काम गर्ने विचार छ। मलाई थाहा छ Zalando अपरेटरमा हामीले भर्खरै AWS मा जडान देख्यौं र यो अब धेरै राम्रो छैन। त्यहाँ एक विशिष्ट पूर्वाधारमा टाई हुनु हुँदैन - त्यसोभए के हो?

DC: मलाई थाहा छैन Zalando कुन अवस्थामा पुग्यो, तर Kubernetes भण्डारणमा अब यस्तो तरिकाले बनाइएको छ कि सामान्य विधि प्रयोग गरेर डिस्क ब्याकअप लिन असम्भव छ। भर्खरै मानकमा - नवीनतम संस्करणमा CSI विशिष्टताहरू - हामीले स्न्यापसटहरू सम्भव बनायौं, तर यो कहाँ लागू हुन्छ? इमानदारीपूर्वक, सबै कुरा अझै कच्चा छ... हामी AWS, GCE, Azure, vSphere को शीर्षमा CSI कोसिस गर्दैछौं, तर तपाईंले यसलाई प्रयोग गर्न थाल्ने बित्तिकै, तपाईंले यो अझै तयार भएको छैन भनेर देख्न सक्नुहुन्छ।

NS: त्यसैले कहिलेकाहीं हामीले पूर्वाधारमा भर पर्नु पर्ने हुन्छ । मलाई लाग्छ यो अझै प्रारम्भिक चरण हो - बढ्दो पीडा। प्रश्न: K8s मा PgSQL प्रयास गर्न चाहने नयाँ व्यक्तिहरूलाई तपाइँ के सल्लाह दिनुहुन्छ? के अपरेटर हुन सक्छ?

DC: समस्या यो हो कि Postgres हाम्रो लागि 3% हो। हामीसँग Kubernetes मा विभिन्न सफ्टवेयर को एक धेरै ठूलो सूची छ, म पनि सबै सूचीबद्ध गर्दिन। उदाहरण को लागी, Elasticsearch। त्यहाँ धेरै अपरेटरहरू छन्: केही सक्रिय रूपमा विकास गर्दै छन्, अरूहरू छैनन्। हामीले आफैंका लागि आवश्यकताहरू बनाएका छौं, अपरेटरमा के हुनुपर्छ ताकि हामी यसलाई गम्भीरतापूर्वक लिन्छौं। विशेष गरी कुबर्नेट्सका लागि अपरेटरमा - "अमेजनको अवस्थाहरूमा केहि गर्न अपरेटर" मा होइन... वास्तवमा, हामी व्यापक रूपमा (= लगभग सबै ग्राहकहरू) एकल अपरेटर प्रयोग गर्छौं - Redis को लागी (हामी छिट्टै उनको बारेमा एक लेख प्रकाशित गर्नेछौं).

NS: र MySQL को लागि पनि होइन? मलाई थाहा छ Percona... किनकि तिनीहरू अहिले MySQL, MongoDB, र Postgres मा काम गरिरहेका छन्, तिनीहरूले केही प्रकारको विश्वव्यापी समाधान सिर्जना गर्नुपर्नेछ: सबै डाटाबेसहरूको लागि, सबै क्लाउड प्रदायकहरूको लागि।

DC: हामीसँग MySQL को लागि अपरेटरहरू हेर्नको लागि समय थिएन। यो अहिले हाम्रो मुख्य फोकस होइन। MySQL ले स्ट्यान्डअलोनमा राम्रो काम गर्दछ। यदि तपाइँ भर्खरै डाटाबेस सुरु गर्न सक्नुहुन्छ भने किन अपरेटर प्रयोग गर्नुहोस्... तपाइँ Postrges को साथ एक डकर कन्टेनर सुरु गर्न सक्नुहुन्छ, वा तपाइँ यसलाई सरल तरिकामा सुरु गर्न सक्नुहुन्छ।

NS: यसबारे पनि प्रश्न उठेको थियो । कुनै पनि अपरेटर छैन?

DC: हो, हामी मध्ये १००%सँग PostgreSQL अपरेटर बिना चलिरहेको छ। हालसम्म। हामी सक्रिय रूपमा Prometheus र Redis को लागी अपरेटर प्रयोग गर्दछौं। हामीसँग Elasticsearch को लागी एक अपरेटर खोज्ने योजना छ - यो एक हो जुन सबैभन्दा "आगोमा" छ, किनकि हामी यसलाई 100% केसहरूमा Kubernetes मा स्थापना गर्न चाहन्छौं। जसरी हामी यो सुनिश्चित गर्न चाहन्छौं कि MongoDB पनि सधैं Kubernetes मा स्थापित छ। यहाँ केहि इच्छाहरू देखा पर्दछ - त्यहाँ एक भावना छ कि यी अवस्थामा केहि गर्न सकिन्छ। र हामीले पोस्टग्रेसलाई पनि हेरेनौं। अवश्य पनि, हामीलाई थाहा छ कि त्यहाँ विभिन्न विकल्पहरू छन्, तर वास्तवमा हामीसँग स्ट्यान्डअलोन छ।

Kubernetes मा परीक्षणको लागि DB

NS: परीक्षणको विषयतिर लागौं। कसरी डाटाबेसमा परिवर्तनहरू रोल आउट गर्ने - DevOps परिप्रेक्ष्यबाट। त्यहाँ माइक्रोसर्विसेसहरू छन्, धेरै डाटाबेसहरू छन्, केही न केही समय कतै परिवर्तन भइरहेको छ। सामान्य CI/CD कसरी सुनिश्चित गर्ने कि सबै कुरा DBMS परिप्रेक्ष्यबाट क्रमबद्ध छ। तपाईको दृष्टिकोण के छ?

DC: त्यहाँ एउटा जवाफ हुन सक्दैन। त्यहाँ धेरै विकल्पहरू छन्। पहिलो आधारको आकार हो जुन हामी रोल आउट गर्न चाहन्छौं। तपाइँ आफैले उल्लेख गर्नुभयो कि कम्पनीहरु को dev र चरण मा उत्पादन डाटाबेस को एक प्रतिलिपि को लागी फरक दृष्टिकोण छ।

NS: र GDPR को सर्तहरूमा, मलाई लाग्छ कि तिनीहरू अधिक र अधिक सावधानीपूर्वक भइरहेका छन्... म भन्न सक्छु कि युरोपमा उनीहरूले पहिले नै जरिवाना लगाउन थालेका छन्।

DC: तर प्रायः तपाईले सफ्टवेयर लेख्न सक्नुहुन्छ जसले उत्पादनबाट डम्प लिन्छ र यसलाई अस्पष्ट बनाउँछ। उत्पादन डेटा प्राप्त गरिएको छ (स्न्यापसट, डम्प, बाइनरी प्रतिलिपि ...), तर यो अज्ञात छ। यसको सट्टा, त्यहाँ जेनरेशन लिपिहरू हुन सक्छ: यी फिक्स्चर वा केवल एक लिपि हुन सक्छ जसले ठूलो डाटाबेस उत्पन्न गर्दछ। समस्या यो हो: आधार छवि बनाउन कति समय लाग्छ? र इच्छित वातावरणमा यसलाई तैनात गर्न कति समय लाग्छ?

हामी एउटा योजनामा ​​आएका छौं: यदि ग्राहकसँग निश्चित डेटा सेट छ (डेटाबेसको न्यूनतम संस्करण), त्यसपछि हामी तिनीहरूलाई पूर्वनिर्धारित रूपमा प्रयोग गर्छौं। यदि हामी समीक्षा वातावरणको बारेमा कुरा गर्दैछौं भने, हामीले एउटा शाखा सिर्जना गर्दा, हामीले अनुप्रयोगको एउटा उदाहरण तैनाथ गर्यौं - हामी त्यहाँ एउटा सानो डाटाबेस रोल आउट गर्छौं। तर राम्रो निस्कियो विकल्प, जब हामी दिनमा एक पटक उत्पादनबाट डम्प लिन्छौं (रातमा) र PostgreSQL र MySQL सँग यो लोड गरिएको डाटामा आधारित डकर कन्टेनर बनाउँछौं। यदि तपाइँ यस छविबाट डाटाबेस 50 पटक विस्तार गर्न आवश्यक छ भने, यो एकदम सरल र छिटो गरिन्छ।

NS: साधारण प्रतिलिपि गरेर?

DC: डाटा सिधै डकर छविमा भण्डार गरिएको छ। ती। हामीसँग 100 GB भए पनि तयार छवि छ। डकरमा तहहरूका लागि धन्यवाद, हामी यस छविलाई जति पटक आवश्यक छ त्यसलाई द्रुत रूपमा प्रयोग गर्न सक्छौं। विधि बेवकूफ छ, तर यो राम्रो काम गर्दछ।

NS: त्यसोभए, जब तपाइँ परीक्षण गर्नुहुन्छ, यो सही डकर भित्र परिवर्तन हुन्छ, हैन? डकर भित्र प्रतिलिपि-अन-लेख्नुहोस् - यसलाई फ्याँक्नुहोस् र फेरि जानुहोस्, सबै ठीक छ। कक्षा! र के तपाइँ पहिले नै यसलाई पूर्ण रूपमा प्रयोग गर्दै हुनुहुन्छ?

DC: धेरै समय सम्म।

NS: हामी धेरै समान चीजहरू गर्छौं। केवल हामी डकरको प्रतिलिपि-अन-राइट प्रयोग गर्दैनौं, तर केहि अन्य।

DC: यो सामान्य होइन। र डकर जताततै काम गर्दछ।

NS: सिद्धान्तमा, हो। तर हामीसँग त्यहाँ मोड्युलहरू पनि छन्, तपाईं फरक मोड्युलहरू बनाउन र विभिन्न फाइल प्रणालीहरूसँग काम गर्न सक्नुहुन्छ। यहाँ कस्तो पल। पोस्टग्रेस पक्षबाट, हामी यी सबैलाई फरक रूपमा हेर्छौं। अब मैले डकर साइडबाट हेरेँ र देखे कि सबै कुरा तपाईंको लागि काम गर्दछ। तर यदि डाटाबेस ठूलो छ, उदाहरणका लागि, 1 TB, तब यो सबै धेरै समय लाग्छ: रातमा सञ्चालन, र डकरमा सबै चीज भर्ने... र यदि 5 TB डकरमा भरिएको छ भने... वा सबै ठीक छ?

DC: के फरक छ: यी ब्लबहरू, केवल बिट र बाइटहरू हुन्।

NS: भिन्नता यो हो: के तपाइँ यसलाई डम्प र पुनर्स्थापना मार्फत गर्नुहुन्छ?

DC: आवश्यक छैन। यो छवि उत्पन्न गर्ने तरिका फरक हुन सक्छ।

NS: केही क्लाइन्टहरूका लागि, हामीले यसलाई नियमित रूपमा आधार छवि उत्पन्न गर्नुको सट्टा, यसलाई निरन्तर अद्यावधिक राखेका छौं। यो अनिवार्य रूपमा एक प्रतिकृति हो, तर यसले मास्टरबाट सीधै डेटा प्राप्त गर्दैन, तर अभिलेख मार्फत। एक बाइनरी अभिलेख जहाँ WAL हरू हरेक दिन डाउनलोड गरिन्छ, जहाँ ब्याकअपहरू लिइन्छ... यी WAL हरू थोरै ढिलाइमा (शाब्दिक रूपमा 1-2 सेकेन्ड) आधार छविमा पुग्छन्। हामी यसलाई कुनै पनि तरिकाले क्लोन गर्छौं - अब हामीसँग पूर्वनिर्धारित रूपमा ZFS छ।

DC: तर ZFS को साथ तपाईं एक नोडमा सीमित हुनुहुन्छ।

NS: हो। तर ZFS सँग पनि जादुई छ पठाउन: यसको साथ तपाईले स्न्यापसट पठाउन सक्नुहुन्छ र पनि (मैले वास्तवमै यो परीक्षण गरेको छैन, तर...) तपाईले दुई बीचको डेल्टा पठाउन सक्नुहुन्छ। PGDATA। वास्तवमा, हामीसँग अर्को उपकरण छ जुन हामीले वास्तवमा त्यस्ता कार्यहरूको लागि विचार गरेका छैनौं। PostgreSQL छ pg_rewind, जसले "स्मार्ट" rsync जस्तै काम गर्दछ, तपाईले हेर्नु नपर्ने धेरै कुरा छोडेर, किनकि त्यहाँ केहि परिवर्तन भएको छैन। हामी दुई सर्भरहरू बीच द्रुत सिंक्रोनाइजेसन गर्न सक्छौं र उही तरीकाले रिवाइन्ड गर्न सक्छौं।

त्यसोभए, यसबाट, थप DBA पक्षमा, हामी एउटा उपकरण सिर्जना गर्ने प्रयास गर्दैछौं जसले हामीलाई तपाईंले भन्नुभएको कुरा गर्न अनुमति दिन्छ: हामीसँग एउटा डाटाबेस छ, तर हामी लगभग 50 पटक, लगभग एकै साथ परीक्षण गर्न चाहन्छौं।

DC: 50 पटकको मतलब तपाईंले 50 Spot उदाहरणहरू अर्डर गर्न आवश्यक छ।

NS: होइन, हामी सबै कुरा एउटै मेसिनमा गर्छौं।

DC: तर यदि यो एउटा डाटाबेस टेराबाइट हो भने तपाइँ कसरी ५० पटक विस्तार गर्नुहुन्छ। सम्भवतः उसलाई सशर्त 50 GB RAM चाहिन्छ?

NS: हो, कहिलेकाहीँ तपाईंलाई धेरै मेमोरी चाहिन्छ - यो सामान्य हो। तर यो जीवनको उदाहरण हो। उत्पादन मेसिनमा 96 कोर र 600 GB छ। एकै समयमा, डाटाबेसको लागि 32 कोर (अहिले 16 कोर पनि) र 100-120 GB मेमोरी प्रयोग गरिन्छ।

DC: र त्यहाँ 50 प्रतिहरू फिट छन्?

NS: त्यसोभए त्यहाँ एउटा मात्र प्रतिलिपि छ, त्यसपछि प्रतिलिपि-अन-राइट (ZFS) काम गर्दछ ... म तपाईंलाई थप विस्तारमा बताउनेछु।

उदाहरणका लागि, हामीसँग 10 TB डाटाबेस छ। तिनीहरूले यसको लागि एक डिस्क बनाए, ZFS ले यसको आकार 30-40 प्रतिशतले संकुचित गर्यो। हामी लोड परीक्षण नगर्ने हुनाले, सही प्रतिक्रिया समय हाम्रो लागि महत्त्वपूर्ण छैन: यसलाई २ गुणा ढिलो हुन दिनुहोस् - यो ठीक छ।

हामी प्रोग्रामरहरू, QA, DBA, आदिलाई अवसर दिन्छौं। 1-2 थ्रेडहरूमा परीक्षण गर्नुहोस्। उदाहरणका लागि, तिनीहरूले कुनै प्रकारको माइग्रेसन चलाउन सक्छन्। यसलाई एकै पटकमा १० कोर आवश्यक पर्दैन - यसलाई १ पोस्टग्रेस ब्याकइन्ड, १ कोर चाहिन्छ। माइग्रेसन सुरु हुनेछ - हुनसक्छ autovacuum अझै सुरु हुनेछ, त्यसपछि दोस्रो कोर प्रयोग गरिनेछ। हामीसँग 16-32 कोरहरू आवंटित छन्, त्यसैले 10 जनाले एकै समयमा काम गर्न सक्छन्, कुनै समस्या छैन।

किनभने शारीरिक रूपमा PGDATA उस्तै, यो बाहिर जान्छ कि हामी वास्तवमा Postgres लाई धोका दिइरहेका छौं। चाल यो हो: उदाहरण को लागी, 10 Postgres एकै साथ सुरु गरिन्छ। सामान्यतया के समस्या छ? राखे साझा_बफरहरू25% भनौं। तदनुसार, यो 200 GB छ। तपाईं यी मध्ये तीन भन्दा बढी सुरु गर्न सक्षम हुनुहुने छैन, किनभने मेमोरी समाप्त हुनेछ।

तर केहि बिन्दुमा हामीले महसुस गर्यौं कि यो आवश्यक छैन: हामीले साझा_बफरहरू 2 GB मा सेट गर्यौं। PostgreSQL छ प्रभावकारी_cache_size, र वास्तवमा यो मात्र एक हो जसले प्रभाव पार्छ योजनाहरू। हामीले यसलाई 0,5 TB मा सेट गर्यौं। र यो पनि फरक पर्दैन कि तिनीहरू वास्तवमा अवस्थित छैनन्: उसले योजनाहरू बनाउँछ जस्तो कि तिनीहरू अवस्थित छन्।

तदनुसार, जब हामी कुनै प्रकारको माइग्रेसन परीक्षण गर्छौं, हामी सबै योजनाहरू सङ्कलन गर्न सक्छौं - हामी उत्पादनमा यो कसरी हुनेछ भनेर देख्नेछौं। त्यहाँ सेकेन्डहरू फरक (ढिलो) हुनेछन्, तर हामीले वास्तवमा पढेको डेटा, र योजनाहरू आफैं (के त्यहाँ जोडिएका छन्, आदि) उत्पादनमा जस्तै ठ्याक्कै उस्तै हुन्छन्। र तपाईले एउटै मेसिनमा समानान्तरमा धेरै यस्ता जाँचहरू चलाउन सक्नुहुन्छ।

DC: यहाँ केही समस्या छन् जस्तो लाग्दैन ? पहिलो एक समाधान हो जुन केवल PostgreSQL मा काम गर्दछ। यो दृष्टिकोण धेरै निजी हो, यो सामान्य छैन। दोस्रो कुबर्नेट्स (र क्लाउड टेक्नोलोजीहरू अब जाँदैछन्) मा धेरै नोडहरू समावेश छन्, र यी नोडहरू अल्पकालिक छन्। र तपाइँको मामला मा यो एक स्टेटफुल, लगातार नोड हो। यी कुराहरूले मलाई विवादित बनाउँछ।

NS: पहिलो, म सहमत छु, यो एक विशुद्ध Postgres कथा हो। मलाई लाग्छ यदि हामीसँग कुनै प्रकारको प्रत्यक्ष IO र लगभग सबै मेमोरीको लागि बफर पूल छ भने, यो दृष्टिकोणले काम गर्दैन - योजनाहरू फरक हुनेछन्। तर अहिलेको लागि हामी पोस्टग्रेससँग मात्र काम गर्छौं, हामी अरूको बारेमा सोच्दैनौं।

Kubernetes को बारेमा तपाईं आफैले हामीलाई जताततै भन्नुहुन्छ कि हामीसँग निरन्तर डाटाबेस छ। यदि उदाहरण असफल भएमा, मुख्य कुरा डिस्क बचत गर्न हो। यहाँ हामीसँग Kubernetes मा सम्पूर्ण प्लेटफर्म पनि छ, र Postgres को साथ कम्पोनेन्ट अलग छ (यद्यपि यो एक दिन त्यहाँ हुनेछ)। त्यसकारण, सबै कुरा यस्तो छ: उदाहरण खस्यो, तर हामीले यसको PV बचत गर्यौं र यसलाई अर्को (नयाँ) उदाहरणमा जडान गर्यौं, मानौं केही भएको थिएन।

DC: मेरो दृष्टिकोणबाट, हामी Kubernetes मा पोडहरू सिर्जना गर्छौं। K8s - लोचदार: गाँठहरू आवश्यकता अनुसार अर्डर गरिएका छन्। कार्य भनेको केवल पोड सिर्जना गर्नु हो र भन्नु हो कि यसलाई X मात्राको स्रोत चाहिन्छ, र त्यसपछि K8 ले यसलाई आफैले पत्ता लगाउनेछ। तर Kubernetes मा भण्डारण समर्थन अझै पनि अस्थिर छ: 1.16भित्र 1.17 (यो विमोचन जारी गरिएको थियो हप्ताको पहिले) यी सुविधाहरू केवल बीटा हुन्छन्।

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

NS: यो सबै इन्जिनहरू (Amazon, Google...) लाई यो संस्करण समर्थन गर्न सुरु गर्न पनि आवश्यक छ - यसले पनि केही समय लिन्छ।

DC: हामीले तिनीहरूलाई अझै प्रयोग गर्दैनौं। हामी हाम्रो प्रयोग गर्छौं।

Kubernetes को लागि स्थानीय विकास

NS: के तपाईंले एउटै मेसिनमा सबै पोडहरू स्थापना गर्न र यस्तो सानो परीक्षण गर्न आवश्यक हुँदा यस्तो इच्छा भेट्नुभयो। चाँडै अवधारणाको प्रमाण प्राप्त गर्नको लागि, हेर्नुहोस् कि अनुप्रयोग Kubernetes मा चल्छ, यसको लागि मिसिनहरूको गुच्छा समर्पित नगरी। त्यहाँ Minikube छ, हैन?

DC: मलाई लाग्छ कि यो केस - एक नोडमा तैनात - स्थानीय विकासको बारेमा मात्र हो। वा यस्तो ढाँचा को केहि अभिव्यक्तिहरु। खानुहोस् Minikube, त्यहाँ छ k3s, तरिका। हामी डकरमा Kubernetes प्रयोग गर्न तिर लागिरहेका छौं। अब हामीले यसको परीक्षणको लागि काम गर्न थाल्यौं।

NS: मलाई लाग्थ्यो कि यो सबै पोडहरू एउटै डकर छविमा लपेट्ने प्रयास हो। तर यो बाहिर निस्कियो कि यो पूर्णतया फरक कुरा हो। जे भए पनि, त्यहाँ छुट्टै कन्टेनरहरू छन्, अलग पोडहरू - केवल डकरमा।

DC: हो। र त्यहाँ एक बरु हास्यास्पद नक्कल बनाइएको छ, तर अर्थ यो हो... हामीसँग प्रयोगको लागि उपयोगिता छ - वाफ। हामी यसलाई सशर्त मोड बनाउन चाहन्छौं werf up: "मलाई स्थानीय Kubernetes पाउनुहोस्।" र त्यसपछि त्यहाँ सशर्त चलाउनुहोस् werf follow। त्यसपछि विकासकर्ताले IDE सम्पादन गर्न सक्षम हुनेछ, र प्रणालीमा एउटा प्रक्रिया सुरु हुनेछ जसले परिवर्तनहरू देख्छ र छविहरू पुनर्निर्माण गर्दछ, तिनीहरूलाई स्थानीय K8s मा पुन: प्रयोग गर्दछ। स्थानीय विकासको समस्यालाई यसरी नै समाधान गर्ने प्रयास गर्न चाहन्छौं ।

K8s वास्तविकतामा स्न्यापशटहरू र डाटाबेस क्लोनिङ

NS: यदि हामी प्रतिलिपि-अन-राइटमा फर्कन्छौं। मैले याद गरे कि बादलमा पनि स्न्यापसटहरू छन्। तिनीहरू फरक काम गर्छन्। उदाहरणका लागि, GCP मा: तपाईंसँग संयुक्त राज्यको पूर्वी तटमा बहु-टेराबाइट उदाहरण छ। तपाईंले आवधिक रूपमा स्न्यापसटहरू लिनुहुन्छ। तपाईंले स्न्यापशटबाट पश्चिम तटमा डिस्कको प्रतिलिपि लिनुभयो - केहि मिनेटमा सबै तयार छ, यो धेरै छिटो काम गर्दछ, केवल क्यास मेमोरीमा भर्न आवश्यक छ। तर यी क्लोनहरू (स्न्यापशटहरू) नयाँ भोल्युम 'प्रोभिजन' गर्नका लागि हुन्। यो राम्रो छ जब तपाइँ धेरै उदाहरणहरू सिर्जना गर्न आवश्यक छ।

तर परीक्षणको लागि, यो मलाई लाग्छ कि स्न्यापशटहरू, जुन तपाईं डकरमा कुरा गर्नुहुन्छ वा म ZFS, btrfs र LVM मा पनि कुरा गर्छु... - तिनीहरूले तपाईंलाई एउटा मेसिनमा वास्तवमै नयाँ डाटा सिर्जना गर्न अनुमति दिँदैनन्। क्लाउडमा, तपाईंले अझै पनि तिनीहरूको लागि प्रत्येक पटक तिर्नुहुनेछ र सेकेन्ड होइन, तर मिनेट पर्खनुहोस् (र केसमा अल्छी लोड, सम्भवतः एक घडी)।

यसको सट्टा, तपाइँ यो डेटा एक वा दुई सेकेन्डमा प्राप्त गर्न सक्नुहुन्छ, परीक्षण चलाउनुहोस् र यसलाई फ्याँक्नुहोस्। यी स्न्यापशटहरूले विभिन्न समस्याहरू समाधान गर्छन्। पहिलो अवस्थामा - मापन गर्न र नयाँ प्रतिकृतिहरू प्राप्त गर्न, र दोस्रोमा - परीक्षणहरूको लागि।

DC: म सहमत छैन। भोल्युम क्लोनिङको काम ठीकसँग बनाउनु क्लाउडको काम हो। मैले तिनीहरूको कार्यान्वयनलाई हेरेको छैन, तर मलाई थाहा छ कि हामी यसलाई हार्डवेयरमा कसरी गर्छौं। हामीसँग Ceph छ, यसले कुनै पनि भौतिक मात्रालाई अनुमति दिन्छ (आरबीडी) भन्नुहोस् क्लोन र दसौं मिलिसेकेन्डमा समान विशेषताहरूसँग दोस्रो भोल्युम प्राप्त गर्नुहोस्, IOPSअमी, आदि। तपाईंले बुझ्नु आवश्यक छ कि त्यहाँ एक मुश्किल प्रतिलिपि-अन-राइट भित्र छ। बादलले किन त्यसै गर्नु हुँदैन? म पक्का छु कि तिनीहरूले यो एक तरिका वा अर्को गर्न कोशिस गर्दै छन्।

NS: तर यसले तिनीहरूलाई अझै सेकेन्ड, दशौं सेकेन्ड एक उदाहरण उठाउन, डकरलाई त्यहाँ ल्याउन, इत्यादि लिन सक्छ।

DC: पुरै उदाहरण उठाउनु किन आवश्यक छ ? हामीसँग 32 कोर, 16... भएको उदाहरण छ र यो यसमा फिट हुन सक्छ - उदाहरणका लागि, चार। जब हामी पाँचौं अर्डर गर्छौं, उदाहरण पहिले नै उठाइनेछ, र त्यसपछि यसलाई मेटाइनेछ।

NS: हो, चाखलाग्दो कुरा, कुबर्नेट्स फरक कथा हो। हाम्रो डाटाबेस K8s मा छैन, र हामीसँग एउटा उदाहरण छ। तर बहु-टेराबाइट डाटाबेस क्लोन गर्न दुई सेकेन्ड भन्दा बढी लाग्दैन।

DC: धेरै राम्रो। तर मेरो प्रारम्भिक बिन्दु यो एक सामान्य समाधान होइन। हो, यो राम्रो छ, तर यो पोस्टग्रेसको लागि मात्र उपयुक्त छ र केवल एक नोडमा।

NS: यो पोस्टग्रेसको लागि मात्र उपयुक्त छैन: यी योजनाहरू, मैले वर्णन गरे अनुसार, यसमा मात्र काम गर्नेछ। तर यदि हामी योजनाहरूको बारेमा चिन्ता गर्दैनौं, र हामीलाई केवल कार्यात्मक परीक्षणको लागि सबै डाटा चाहिन्छ, तब यो कुनै पनि DBMS को लागी उपयुक्त छ।

DC: धेरै वर्ष पहिले हामीले LVM स्न्यापशटहरूमा यस्तै गर्यौं। यो एक क्लासिक छ। यो दृष्टिकोण धेरै सक्रिय रूपमा प्रयोग गरिएको थियो। स्टेटफुल नोड्स मात्र एक दुखाइ हो। किनकि तपाईंले तिनीहरूलाई छोड्नु हुँदैन, तपाईंले तिनीहरूलाई सधैं सम्झनु पर्छ ...

NS: के तपाइँ यहाँ हाइब्रिडको कुनै सम्भावना देख्नुहुन्छ? मानौं स्टेटफुल कुनै प्रकारको पोड हो, यसले धेरै मानिसहरू (धेरै परीक्षकहरू) को लागि काम गर्छ। हामीसँग एउटा भोल्युम छ, तर फाइल प्रणालीलाई धन्यवाद, क्लोनहरू स्थानीय हुन्। यदि पोड खस्यो, तर डिस्क रह्यो भने, पोड उठ्नेछ, सबै क्लोनहरूको बारेमा जानकारी गणना गर्नुहोस्, सबै कुरा फेरि उठाउनुहोस् र भन्नुहोस्: "यहाँ यी पोर्टहरूमा तपाईंको क्लोनहरू चलिरहेका छन्, तिनीहरूसँग काम जारी राख्नुहोस्।"

DC: प्राविधिक रूपमा यसको मतलब यो हो कि Kubernetes भित्र यो एउटा पोड हो जसमा हामी धेरै Postgres चलाउँछौं।

NS: हो। उसको एक सीमा छ: मानौं कि उहाँसँग एकै समयमा 10 भन्दा बढी मानिसहरू काम गर्दैनन्। यदि तपाईंलाई २० चाहिन्छ भने, हामी दोस्रो यस्तो पोड सुरु गर्नेछौं। हामी यसलाई पूर्ण रूपमा क्लोन गर्नेछौं, दोस्रो पूर्ण भोल्युम प्राप्त गरेपछि, यसमा समान 20 "पातलो" क्लोनहरू हुनेछन्। के तपाईंले यो अवसर देख्नुभएको छैन?

DC: हामीले यहाँ सुरक्षा समस्याहरू थप्न आवश्यक छ। यस प्रकारको संगठनले यो पोडसँग उच्च विशेषाधिकारहरू (क्षमताहरू) छन् भन्ने संकेत गर्दछ, किनभने यसले फाइल प्रणालीमा गैर-मानक कार्यहरू गर्न सक्छ... तर म दोहोर्याउँछु: मलाई विश्वास छ कि मध्यम अवधिमा उनीहरूले कुबर्नेट्समा भण्डारण ठीक गर्नेछन्, र क्लाउडहरू तिनीहरूले भोल्युमहरूको साथ सम्पूर्ण कथा ठीक गर्नेछन् - सबै कुरा "केवल काम गर्नेछ"। त्यहाँ रिसाइज, क्लोनिङ हुनेछ... त्यहाँ एक भोल्युम छ - हामी भन्छौं: "त्यसको आधारमा एउटा नयाँ सिर्जना गर्नुहोस्," र एक सेकेन्ड र आधा पछि हामीले हामीलाई चाहिएको कुरा प्राप्त गर्छौं।

NS: म धेरै टेराबाइटको लागि डेढ सेकेन्डमा विश्वास गर्दिन। Ceph मा तपाईं आफैले यो गर्नुहुन्छ, तर तपाईं बादलको बारेमा कुरा गर्नुहुन्छ। क्लाउडमा जानुहोस्, EC2 मा बहु-टेराबाइट EBS भोल्युमको क्लोन बनाउनुहोस् र प्रदर्शन कस्तो हुनेछ हेर्नुहोस्। यसले केहि सेकेन्ड लिने छैन। तिनीहरू यो स्तरमा कहिले पुग्छन् भन्नेमा म धेरै चासो राख्छु। म बुझ्छु तपाईले के भन्नु भएको छ, तर म फरक गर्न आग्रह गर्दछु।

DC: ठीक छ, तर मैले मध्यम अवधिमा भनेँ, छोटो अवधिमा होइन। धेरै वर्षको लागि।

Zalando बाट PostgreSQL को लागी अपरेटर को बारे मा

यस बैठकको बीचमा, जालान्डोका पूर्व विकासकर्ता एलेक्सी क्ल्युकिन पनि सामेल भए र PostgreSQL अपरेटरको इतिहासको बारेमा कुरा गरे:

यो राम्रो छ कि यो विषय सामान्य मा छोएको छ: दुबै Postgres र Kubernetes। जब हामीले यसलाई 2017 मा Zalando मा गर्न थाल्यौं, यो सबैले गर्न चाहेको विषय थियो, तर कसैले गरेन। सबैसँग पहिले नै Kubernetes थियो, तर जब तिनीहरूले डाटाबेससँग के गर्ने भनेर सोधे, मानिसहरू पनि मन पराउँछन् केल्सी हाइटावर, जसले K8s प्रचार गर्यो, यस्तो केहि भन्यो:

"व्यवस्थित सेवाहरूमा जानुहोस् र तिनीहरूलाई प्रयोग गर्नुहोस्, Kubernetes मा डाटाबेस नचलाउनुहोस्। अन्यथा, तपाईंको K8 ले निर्णय गर्नेछ, उदाहरणका लागि, अपग्रेड गर्न, सबै नोडहरू बन्द गर्नुहोस्, र तपाईंको डाटा धेरै टाढा, टाढा उड्नेछ।"

हामीले एक अपरेटर बनाउने निर्णय गर्यौं कि, यो सल्लाहको विपरीत, Kubernetes मा Postgres डाटाबेस सुरु गर्नेछ। र हामीसँग राम्रो कारण थियो - संरक्षक। यो PostgreSQL को लागि स्वचालित फेलओभर हो, सही तरिकाले गरियो, अर्थात्। क्लस्टरको बारेमा जानकारीको भण्डारणको रूपमा etcd, कन्सुल वा ZooKeeper प्रयोग गर्दै। यस्तो भण्डार जसले सोध्ने सबैलाई दिनेछ, उदाहरणका लागि, वर्तमान नेता के हो, उही जानकारी - हामीसँग सबै कुरा बाँडफाँड भएको तथ्यको बावजुद - कुनै विभाजित मस्तिष्क छैन। प्लस हामीसँग थियो डकर छवि उसको लागि।

सामान्यतया, कम्पनीको अटो फेलओभरको आवश्यकता आन्तरिक हार्डवेयर डाटा सेन्टरबाट क्लाउडमा माइग्रेट गरेपछि देखा पर्‍यो। क्लाउड एक स्वामित्व PaaS (प्लेटफर्म-ए-सेवा) समाधानमा आधारित थियो। यो खुला स्रोत हो, तर यसलाई उठाउन र चलाउन धेरै काम भयो। बोलाइएको थियो STUPS.

सुरुमा, त्यहाँ कुबेरनेटहरू थिएनन्। अझ स्पष्ट रूपमा, जब हाम्रो आफ्नै समाधान तैनात गरिएको थियो, K8s पहिले नै अवस्थित थियो, तर यो यति कच्चा थियो कि यो उत्पादनको लागि उपयुक्त थिएन। यो, मेरो विचारमा, 2015 वा 2016 थियो। 2017 सम्म, Kubernetes कम वा कम परिपक्व भइसकेका थिए - त्यहाँ बसाइँ सर्ने आवश्यकता थियो।

र हामीसँग पहिले नै डकर कन्टेनर थियो। त्यहाँ एक PaaS थियो जसले डकर प्रयोग गर्यो। किन K8s प्रयास नगर्ने? किन आफ्नै अपरेटर लेख्नुहुन्न? एविटोबाट हामीकहाँ आएका मुरात काबिलोभले यसलाई आफ्नै पहलमा एउटा परियोजनाको रूपमा सुरु गरेका थिए - "खेल्नु" - र यो परियोजना "लगाइएको थियो।"

तर सामान्यतया, म AWS को बारेमा कुरा गर्न चाहन्थें। किन त्यहाँ ऐतिहासिक AWS सम्बन्धित कोड थियो ...

जब तपाइँ Kubernetes मा केहि चलाउनुहुन्छ, तपाइँले K8s प्रगति मा यस्तो काम हो भनेर बुझ्न आवश्यक छ। यो निरन्तर विकास, सुधार र समय-समयमा बिग्रन्छ। तपाईंले Kubernetes मा भएका सबै परिवर्तनहरूमा नजिकबाट नजर राख्नु आवश्यक छ, तपाईं यसमा डुब्न तयार हुन आवश्यक छ यदि केहि भयो भने र यसले कसरी काम गर्छ भनेर विस्तृत रूपमा जान्नुहोस् - सायद तपाईंले चाहनुहुने भन्दा बढी। यो, सिद्धान्तमा, कुनै पनि प्लेटफर्ममा लागू हुन्छ जसमा तपाईंले आफ्नो डाटाबेस चलाउनुहुन्छ ...

त्यसोभए, जब हामीले कथन गर्‍यौं, हामीसँग पोष्टग्रेस बाह्य भोल्युममा चलिरहेको थियो (यस अवस्थामा EBS, किनकि हामी AWS मा काम गरिरहेका थियौं)। डाटाबेस बढ्यो, केहि बिन्दुमा यसलाई पुन: आकार दिन आवश्यक थियो: उदाहरण को लागी, EBS को प्रारम्भिक आकार 100 TB थियो, डाटाबेस यो बढ्यो, अब हामी EBS 200 TB बनाउन चाहन्छौं। कसरी? मानौं कि तपाइँ नयाँ उदाहरणमा डम्प / रिस्टोर गर्न सक्नुहुन्छ, तर यसले लामो समय लिनेछ र डाउनटाइम समावेश गर्दछ।

त्यसकारण, म एउटा रिसाइज चाहन्थें जसले EBS विभाजनलाई ठूलो पार्छ र त्यसपछि फाइल प्रणालीलाई नयाँ ठाउँ प्रयोग गर्न भन्नुहोस्। र हामीले यो गर्यौं, तर त्यस समयमा कुबर्नेट्ससँग रिसाइज अपरेशनको लागि कुनै एपीआई थिएन। हामीले AWS मा काम गरेकोले, हामीले यसको API को लागी कोड लेख्यौं।

कसैले तपाईंलाई अन्य प्लेटफर्महरूको लागि त्यसै गर्नबाट रोकेको छैन। कथनमा कुनै सङ्केत छैन कि यो AWS मा मात्र चलाउन सकिन्छ, र यसले अरू सबैमा काम गर्दैन। सामान्यतया, यो एक खुला स्रोत परियोजना हो: यदि कसैले नयाँ API को प्रयोगको उदयलाई गति दिन चाहन्छ भने, तपाईंलाई स्वागत छ। खानुहोस् GitHub, अनुरोधहरू तान्नुहोस् - Zalando टोलीले तिनीहरूलाई छिटो प्रतिक्रिया दिन र अपरेटरलाई बढावा दिन प्रयास गर्दछ। जहाँसम्म मलाई थाहा छ, परियोजना सहभागी भयो Google समर अफ कोड र केही अन्य समान पहलहरूमा। Zalando यसमा धेरै सक्रिय रूपमा काम गरिरहेको छ।

PS बोनस!

यदि तपाइँ PostgreSQL र Kubernetes को विषयमा रुचि राख्नुहुन्छ भने, त्यसपछि कृपया यो पनि याद गर्नुहोस् कि अर्को Postgres मंगलबार गत हप्ता भएको थियो, जहाँ मैले निकोलाईसँग कुरा गरें। Zalando बाट अलेक्जेंडर कुकुशकिन। यसबाट भिडियो उपलब्ध छ यहाँ.

पीपीएस

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «डाटाबेस र Kubernetes (समीक्षा र भिडियो रिपोर्ट)»;
• «कुबेरनेटमा क्यासान्ड्राको माइग्रेसन: सुविधाहरू र समाधानहरू»;
• «MongoDB को Kubernetes मा सिमलेस माइग्रेसन»;
• «RabbitMQ को Kubernetes मा सिमलेस माइग्रेसन"।

स्रोत: www.habr.com