क्लाउडफ़ाउंड्री (भूतकाल) और कुबेरनेट्स (वर्तमान) कमिटेटर दोनों के रूप में, मैं शायद इस उत्तर के लिए विशिष्ट रूप से योग्य हूं।
PaaS की तरह
मुझे CloudFoundry को "Application Paa" और Kubernetes को "कंटेनर PaS" कहना पसंद है, लेकिन यह अंतर काफी सूक्ष्म और तरल है, यह देखते हुए कि दोनों परियोजनाएं समान बाजारों में प्रतिस्पर्धा करने के लिए समय के साथ बदलती हैं।
दोनों के बीच अंतर यह है कि सीएफ में एक मचान परत होती है जो एक (12-कारक) उपयोगकर्ता ऐप (जैसे जार या मणि) और एक हेरोकू-शैली बिल्डपैक (जैसे जावा + टॉमकैट या रूबी) लेती है और एक छोटी बूंद पैदा करती है (एक के अनुरूप) डॉकर छवि)। CF उपयोगकर्ता के लिए कंटेनरीकरण इंटरफ़ेस को उजागर नहीं करता है, लेकिन कुबेरनेट करता है।
दर्शक
CloudFoundry के प्राथमिक ऑडियंस एंटरप्राइज़ एप्लिकेशन देव हैं जो 12-कारक स्टेटलेस ऐप्स को Heroku- स्टाइल बिल्डपैक का उपयोग करके तैनात करना चाहते हैं।
कुबेरनेट्स के दर्शक थोड़े व्यापक हैं, जिसमें स्टेटलेस एप्लिकेशन और स्टेटफुल सर्विस डेवलपर्स दोनों शामिल हैं जो अपने कंटेनर प्रदान करते हैं।
यह भेद भविष्य में बदल सकता है:
सुविधा तुलना
जैसे-जैसे दोनों परियोजनाएँ परिपक्व होती हैं और प्रतिस्पर्धा होती है, उनकी समानताएं और अंतर बदल जाएंगे। तो नमक के एक दाने के साथ निम्नलिखित सुविधा की तुलना करें।
CF और K8 दोनों कई समान विशेषताओं को साझा करते हैं, जैसे कंटेनरीकरण, नाम स्थान, प्रमाणीकरण,
Kubernetes प्रतिस्पर्धात्मक लाभ:
- कंटेनरों का समूह और स्केल पॉड्स जो एक नेटवर्क स्टैक को साझा करते हैं, बजाय स्वतंत्र रूप से स्केलिंग के
- अपने खुद के कंटेनर ले आओ
- स्टेटफुल कंसिस्टेंस लेयर
- बड़ा, अधिक सक्रिय ओएसएस समुदाय
- बदली घटकों और 3 पार्टी प्लगइन्स के साथ अधिक एक्स्टेंसिबल आर्किटेक्चर
- मुफ्त वेब जीयूआई
CloudFoundry प्रतिस्पर्धी लाभ:
- परिपक्व प्रमाणीकरण, उपयोगकर्ता समूहन और बहु-किरायेदारी समर्थन [x]
- अपना खुद का ऐप लाओ
- शामिल लोड बैलेंसर
- तैनात, बढ़े हुए और BOSH [x] द्वारा जीवित रखा गया
- मजबूत लॉगिंग और मैट्रिक्स एकत्रीकरण [x]
- एंटरप्राइज़ वेब GUI [x]
[x] ये विशेषताएं डिएगो का हिस्सा नहीं हैं या जाली में शामिल हैं।
तैनाती
CloudFoundry के प्रतिस्पर्धी लाभों में से एक यह है कि इसमें एक परिपक्व तैनाती इंजन, BOSH है, जो मुख्य CF घटकों के स्केलिंग, पुनरुत्थान और निगरानी जैसी सुविधाओं को सक्षम करता है। बीओएसएच कई आईएएएस परतों का समर्थन करता है, जो एक प्लग करने योग्य क्लाउड प्रदाता अमूर्तता के साथ है। दुर्भाग्य से, बीओएसएच के सीखने की अवस्था और तैनाती विन्यास प्रबंधन बुरे सपने हैं। (एक बॉस कमिटेटर के रूप में, मुझे लगता है कि मैं इसे सटीकता के साथ कह सकता हूं।)
कुबेरनेट्स की तैनाती अमूर्तता अभी भी अपनी प्रारंभिक अवस्था में है। कोर रेपो में कई लक्ष्य वातावरण उपलब्ध हैं, लेकिन वे सभी काम नहीं कर रहे हैं, अच्छी तरह से परीक्षण किए गए हैं, या प्राथमिक डेवलपर्स द्वारा समर्थित हैं। यह ज्यादातर मैच्योरिटी वाली चीज है। किसी को समय के साथ सुधार और अमूर्तता में वृद्धि की उम्मीद हो सकती है। उदाहरण के लिए, DCOS पर Kubernetes , Kubernetes को एक मौजूदा DCOS क्लस्टर में एकल कमांड के साथ तैनात करने की अनुमति देता है ।
ऐतिहासिक संदर्भ
डिएगो सीएफ के ड्रिपलेट एक्जेकशन एजेंट का पुनर्लेखन है। कुबेरनेट्स की घोषणा होने से पहले इसे मूल रूप से विकसित किया गया था और प्रतिस्पर्धी परिदृश्य के विकसित होने के साथ-साथ इसे और अधिक फीचर दायरे में ले लिया गया है। इसका मूल लक्ष्य बूंदों को उत्पन्न करना (उपयोगकर्ता अनुप्रयोग + सीएफ बिल्डपैक) था और उन्हें वार्डन (बदला हुआ उद्यान जब गो में फिर से लिखा गया था) में चलाना था। इसकी स्थापना के बाद से इसे लैटिस के रूप में भी रद्द कर दिया गया है , जो कुछ हद तक CloudFoundry-lite है (हालांकि उस नाम को एक मौजूदा परियोजना द्वारा लिया गया था)। उस कारण से, लैटिस कुछ खिलौना-जैसा है, इसमें उसने जानबूझकर उपयोगकर्ता के दर्शकों और गुंजाइश को कम कर दिया है, स्पष्ट रूप से लापता विशेषताएं जो इसे "उद्यम-तैयार" कर देंगी। सीएफ पहले से ही प्रदान करता है कि सुविधाएँ। यह आंशिक रूप से है क्योंकि जाली का उपयोग मुख्य घटकों का परीक्षण करने के लिए किया जाता है, अधिक जटिल सीएफ से कुछ ओवरहेड के बिना, लेकिन आप आंतरिक उच्च विश्वास वाले वातावरण में जाली का उपयोग भी कर सकते हैं जहां सुरक्षा और बहु-किरायेदारी एक चिंता का विषय नहीं है। ।
यह भी उल्लेखनीय है कि CloudFoundry और Warden (इसका कंटेनर इंजन) Docker के साथ-साथ एक-दो साल से पहले का है।
दूसरी ओर कुबेरनेट्स, एक अपेक्षाकृत नई परियोजना है जिसे BORG और ओमेगा के साथ कंटेनर के उपयोग के वर्षों के आधार पर Google द्वारा विकसित किया गया था। कुबेरनेट्स को Google पर तीसरी पीढ़ी के कंटेनर ऑर्केस्ट्रेशन के रूप में सोचा जा सकता है, उसी तरह डिएगो Pivotal / VMware में v1 पीढ़ी का कंटेनर ऑर्केस्ट्रेशन है (VMware में V2 लिखा है; V2 के साथ VMware एट Pivotal Labs मदद; v3 के बाद Pivotal इस परियोजना को संभालने के बाद) ।
