एक कंटेनर तैनात करणे सोपे आहे. दहा तैनात करणे व्यवस्थापित करण्यायोग्य आहे. परंतु एकदा तुम्ही डझनभर मशीनवर शेकडो कंटेनर चालवू लागलात की, मॅन्युअल व्यवस्थापन केवळ कठीण न राहता अशक्य होऊ लागते. कोणता कंटेनर कुठे आहे याचा मागोवा घेणे तुम्हाला कठीण जाते. एखादा सर्व्हर बंद पडला की, जोपर्यंत कोणीतरी तो पुन्हा सुरू करण्यासाठी जागा होत नाही, तोपर्यंत तुमचे ॲप्लिकेशन गायब होते. नवीन इन्स्टन्स तयार करण्यापूर्वीच ट्रॅफिक स्पाइक्स तुमच्या सेटअपवर ताण आणतात. नेमकी याच ठिकाणी Kubernetes ची भूमिका सुरू होते. हे केवळ आणखी एक DevOps टूल नाही. हे एक ऑर्केस्ट्रेशन लेयर आहे जे कंटेनर व्यवस्थापनाकडे स्क्रिप्टिंग करण्याऐवजी एक 'कंट्रोल प्रॉब्लेम' म्हणून पाहते.

स्क्रिप्ट्स शेवटी का निकामी ठरतात

बहुतेक टीम्स शेल स्क्रिप्ट्स किंवा बेसिक ऑटोमेशनने सुरुवात करतात. ते इमेजेस पुल करण्यासाठी, कंटेनर्स सुरू करण्यासाठी, लॉग्स पाहण्यासाठी आणि अयशस्वी प्रोसेस पुन्हा सुरू करण्यासाठी कमांड्स लिहितात. हा दृष्टिकोन 'प्रूफ ऑफ कन्सेप्ट'साठी काम करतो, परंतु प्रत्यक्ष कामाच्या लोडखाली तो कोलमडतो. मायक्रोसर्व्हिसेस वेगवेगळ्या होस्टवर एकमेकांशी संवाद साधतात, विशिष्ट एन्व्हायरमेंट व्हेरिएबल्सवर अवलंबून असतात, कंटेनर रीस्टार्ट झाल्यानंतरही टिकून राहणाऱ्या पर्सिस्टंट स्टोरेजची गरज असते आणि विविध व्हर्जनमध्ये सुसंगत नेटवर्किंगची अपेक्षा करतात. व्हर्च्युअल मशीन गायब झाल्यावर स्क्रिप्ट वर्कलोडचे आपोआप रीशेड्युलिंग करू शकत नाही. क्रॅश लूपमध्ये अडकलेल्या इन्स्टन्सेसना वगळून, ती हेल्दी इन्स्टन्सेसमध्ये नेटवर्क ट्रॅफिक वितरित करू शकत नाही. Kubernetes क्लस्टरलाच या निर्णयांसाठी जबाबदार बनवून ही समस्या सोडवते. तुम्हाला काय हवे आहे याचे वर्णन तुम्ही करता आणि सिस्टम सातत्याने ती स्थिती (state) लागू करते.

ते तुम्हाला देणाऱ्या तीन गोष्टी

Kubernetes तीन मुख्य क्षमता प्रदान करते ज्या मॅन्युअल फायरफाइटिंगच्या जागी ऑटोमेटेड रिलायबिलिटी (स्वयंचलित विश्वासार्हता) आणतात.

High availability (उच्च उपलब्धता) म्हणजे तुमच्या इन्फ्रास्ट्रक्चरचे काही भाग निकामी झाले तरी तुमचे ॲप्लिकेशन्स ऑनलाइन राहतात. जर एखादा कंटेनर क्रॅश झाला, तर Kubernetes काही सेकंदात त्याची जागा घेते. जर एखादा संपूर्ण वर्कर नोड बंद पडला, तर शेड्युलरला 'मिसिंग हार्टबीट'ची सूचना मिळते आणि तो प्रभावित वर्कलोड क्लस्टरमधील इतर हेल्दी मशीन्सवर हलवतो. सिस्टम तुम्ही परिभाषित केलेल्या अपेक्षित स्थितीवर (desired state) सतत लक्ष ठेवते आणि मानवी हस्तक्षेपाशिवाय त्रुटी सुधारते.

Scalability (स्केलेबिलिटी) म्हणजे तुमचे ॲप्लिकेशन्स तुमच्या वापरकर्त्यांसोबत वाढतात. केवळ दोन तासांच्या ट्रॅफिक पीकसाठी वीस सर्व्हर्स तैनात करण्याऐवजी, तुम्ही CPU वापर किंवा रिक्वेस्ट लेटन्सी यांसारखे महत्त्वाचे मेट्रिक्स परिभाषित करता आणि थ्रेशोल्ड ओलांडल्यावर क्लस्टरला अधिक कंटेनर इन्स्टन्सेस जोडू देता. जेव्हा मागणी कमी होते, तेव्हा रेप्लिका काउंट पुन्हा कमी होतो. तुम्हाला जेव्हा गरज असेल, तेव्हा तुम्ही फक्त आवश्यकतेनुसारच पैसे भरता.

Disaster recovery (आपत्ती निवारण) म्हणजे क्रॅश झाल्यानंतर तुमचा डेटा आणि कॉन्फिगरेशन पुन्हा प्राप्त होते. Kubernetes संपूर्ण क्लस्टरची स्थिती एका डिस्ट्रिब्युटेड की-व्हॅल्यू स्टोअरमध्ये साठवते. जर एखाद्या मोठ्या बिघाडामुळे वर्कर नोड्स किंवा कंट्रोल प्लेनचा काही भाग नष्ट झाला, तरीही साठवलेल्या स्थितीमुळे सिस्टम तुमचा वर्कलोड पूर्वीप्रमाणेच पुन्हा तयार करू शकते. तुमचा डेटा परत येतो कारण ऑर्केस्ट्रेटरला तो कसा असावा हे माहित असते.

सेटअप: मेंदू आणि स्नायू (Brains and Muscle)

Kubernetes क्लस्टरमध्ये दोन मूलभूत भूमिका असतात ज्यांचे वर्णन मेंदू आणि स्नायू असे केले आहे, आणि ही उपमा प्रत्यक्षात खूप प्रभावी ठरते.

Master Node हा मेंदू आहे. तो तुमच्या कस्टमर-फेसिंग ॲप्लिकेशन्स चालवत नाही. त्याऐवजी, तो कंट्रोल प्लेनचे घटक होस्ट करतो जे टास्क शेड्युल करतात, क्लस्टरची स्थिती व्यवस्थापित करतात आणि बदलांना प्रतिसाद देतात. जेव्हा तुम्ही एखादी कमांड देता किंवा कॉन्फिगरेशन फाईल सबमिट करता, तेव्हा मास्टर नोड ठरवतो की वर्कलोड कुठे असावा, तो हेल्दी आहे की नाही आणि तो नसेल तर काय करावे.

Worker Nodes हे स्नायू आहेत. प्रत्येक वर्कर एक हलका (lightweight) एजंट चालवतो जो मास्टरशी संवाद साधतो आणि प्रत्यक्ष Pods चालवण्यासाठी कंटेनर रनटाइमचा वापर करतो. या नोड्सवरच तुमचा ॲप्लिकेशन कोड CPU आणि मेमरी वापरतो. अधिक वर्कर नोड्स जोडल्यास तुमच्या क्लस्टरची क्षमता वाढते. रिडंडन्सीसाठी अधिक मास्टर नोड्स जोडल्यास, तुमचा कंट्रोल प्लेन हार्डवेअर फेल्युअरला तोंड देण्यासाठी अधिक सक्षम होतो.

Pods, Containers, आणि Services

Kubernetes सोबत काम करण्यासाठी, सॉफ्टवेअर कसे पॅकेज केले जाते आणि ते कसे वापरले जाते हे समजून घेण्यासाठी तुम्हाला तीन संज्ञा समजून घेणे आवश्यक आहे.

Containers हे असे पॅकेजेस आहेत जे तुमचे ॲप्लिकेशन त्याच्या डिपेंडन्सीज (dependencies), लायब्ररीज आणि कॉन्फिगरेशनसह एकत्र बांधतात. ते सॉफ्टवेअरला मूळ होस्टपासून वेगळे (isolate) करतात जेणेकरून ते डेव्हलपमेंट, स्टेजिंग आणि प्रोडक्शनमध्ये सारख्याच पद्धतीने चालेल.

Pods हे Kubernetes मधील सर्वात लहान deployable unit आहेत. एक pod एक किंवा अधिक containers ला एकत्र बांधून ठेवते ज्यांना संसाधने (resources) शेअर करण्याची गरज असते. ते एकच network namespace शेअर करतात आणि एकाच local storage volumes ला ॲक्सेस करू शकतात. हे महत्त्वाचे आहे: तुम्ही थेट एखादा container deploy करत नाही. तुम्ही त्या कंटेनरला धारण करणारा एक pod deploy करता. Pods हे मुद्दामहून ephemeral (अल्पजीवी) असतात. परिस्थिती बदलल्यानुसार ते तयार केले जातात, नष्ट केले जातात आणि बदलले जातात. त्यांचे आयुष्य डिझाइननुसार dynamic असते.

Services अस्तित्वात आहेत कारण pods हे transient (तात्पुरते) असतात. प्रत्येक वेळी जेव्हा एखादा pod restart होतो, तेव्हा त्याला बहुधा एक नवीन internal IP address मिळतो. जर तुमच्या ॲप्लिकेशनचे इतर भाग थेट त्या बदलणाऱ्या पत्त्यांशी (addresses) कनेक्ट करण्याचा प्रयत्न करत असतील, तर ते सतत बिघडतील. एक service तुमच्या pods ला एक fixed IP address आणि DNS name देते. ते एका स्थिर 'front door' प्रमाणे काम करते, जे त्याच्या selector शी जुळणाऱ्या सर्व healthy pods मध्ये येणाऱ्या requests चे load-balancing करते. यामुळे तुमचे clients हे वैयक्तिक container life cycles च्या गोंधळापासून decouple (वेगळे) होतात.

मोठ्या प्रमाणावरील Kubernetes: Netflix चे उदाहरण

Netflix त्याच्या content delivery network ला व्यवस्थापित करण्यासाठी Kubernetes वापरते. हे इन्फ्रास्ट्रक्चर जगभरातील लाखो प्रेक्षकांना एकाच वेळी व्हिडिओ स्ट्रीम्स पोहोचवते. जेव्हा एखादा लोकप्रिय शो रिलीज होतो आणि मागणी वाढते, तेव्हा cluster त्या cache nodes ला scale out करते जे व्हिडिओ सेगमेंट्स युजर्सच्या जवळ साठवतात. जर एखादा regional node फेल झाला, तर traffic आपोआप reroute होतो. परिणामी, इंजिनिअरला मॅन्युअली आपत्कालीन सूचना (emergency page) न देताही लाखो लोकांसाठी चित्रपट अखंडितपणे सुरू राहतात. Orchestrator स्केल आणि फेल्युअर हाताळतो जेणेकरून सेवा विनाअडथळा सुरू राहील.

सुरुवात: YAML, JSON, आणि API Server

Kubernetes सोबत सुरुवात करणे म्हणजे imperative click-ops सोडून declarative configuration स्वीकारणे होय. तुम्हाला जे हवे आहे ते तुम्ही YAML किंवा JSON फाइल्समध्ये लिहिता. हे manifests container image पासून ते replicas ची संख्या, exposed ports, environment variables आणि storage mounts पर्यंत सर्व काही वर्णन करतात. एकदा तुमची फाईल तयार झाली की, तुम्ही ती master node वरील API server कडे पाठवता. Control plane ती घोषणा (declaration) स्वीकारते, ती cluster state database मध्ये साठवते आणि त्यानंतर वास्तव तुमच्या वर्णनाशी जुळवण्यासाठी काम सुरू करते. तुम्ही Kubernetes ला त्याचे काम नेमके कसे करायचे हे सांगत नाही. तुम्ही त्याला अंतिम निकाल काय असावा हे सांगता, आणि ते स्वतः पायऱ्या (steps) शोधून काढते.

मुख्य निष्कर्ष

Kubernetes शिकण्यासाठी एक learning curve आहे. सुरुवातीला त्याची संज्ञा (terminology) कठीण वाटू शकते. यामध्ये अनेक घटक कार्यरत असतात आणि distributed system debug करणे हे single server debug करण्यापेक्षा मुळातच कठीण असते. पण याचे फळ म्हणजे 'operational calm' (कार्यक्षम शांतता) मिळते. तुम्ही वैयक्तिक मशीन्सची काळजी घेणे थांबवता. रात्री ३ च्या वेळी काही बिघाड (outage) झाल्यास तुमचे startup scripts काम करतील अशी प्रार्थना करणे थांबवता. तुम्ही 'failure' साठी डिझाइन करण्यास सुरुवात करता, nodes नष्ट होतील असे गृहीत धरता आणि तुमचे application सुरक्षित ठेवण्यासाठी orchestrator वर विश्वास ठेवता. 'काहीही बिघडू नये' अशी आशा करण्याऐवजी 'सिस्टम बिघाड हाताळू शकते' हे जाणून घेणे, या मानसिकतेतील बदलच या कष्टाचे सार्थक करतो.

Source: What Is Kubernetes? Kubernetes Explained in 15 Mins

Optional learning community: GyaanSetu AI on Telegram