कुबेरनेट्स की बढ़ती लोकप्रियता के बारे में

हे हबर!

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

पढ़ने का आनंद लें!

इस लेख को लिखने के समय, कुबेरनेट्स की उम्र लगभग है। छः वर्ष का, और पिछले दो वर्षों में इसकी लोकप्रियता इतनी बढ़ गई है कि इसे लगातार रैंकिंग में स्थान दिया जाता है सबसे पसंदीदा प्लेटफार्म. कुबेरनेट्स इस वर्ष तीसरे स्थान पर है। संक्षेप में: कुबेरनेट्स एक प्लेटफ़ॉर्म है जिसे कंटेनरीकृत वर्कलोड को चलाने और व्यवस्थित करने के लिए डिज़ाइन किया गया है।

लिनक्स में प्रक्रियाओं को अलग करने के लिए कंटेनरों की शुरुआत एक विशेष डिज़ाइन के रूप में हुई; कंटेनरों को 2007 से शामिल किया गया है सीग्रुप्स, और 2002 से - नामस्थान। 2008 में, जब यह उपलब्ध हुआ, कंटेनरों को और भी बेहतर ढंग से डिज़ाइन किया गया LXC, और Google ने अपना स्वयं का आंतरिक कॉर्पोरेट तंत्र विकसित किया जिसे कहा जाता है बोर्ग, где «вся работа ведется в контейнерах». Отсюда перенесемся в 2013, когда состоялся первый релиз Docker, и контейнеры окончательно перешли в разряд популярных массовых решений. На тот момент основным инструментом для оркестрации контейнеров был मेसो, हालाँकि वह बेतहाशा लोकप्रिय नहीं था। कुबेरनेट्स को पहली बार 2015 में जारी किया गया था, जिसके बाद यह उपकरण कंटेनर ऑर्केस्ट्रेशन के क्षेत्र में वास्तविक मानक बन गया।

यह समझने की कोशिश करने के लिए कि कुबेरनेट्स इतना लोकप्रिय क्यों है, आइए कुछ सवालों के जवाब देने की कोशिश करें। पिछली बार कब डेवलपर्स इस बात पर सहमत हो पाए थे कि उत्पादन में एप्लिकेशन को कैसे तैनात किया जाए? आप ऐसे कितने डेवलपर्स को जानते हैं जो बॉक्स से बाहर उपलब्ध कराए गए टूल का उपयोग करते हैं? आज ऐसे कितने क्लाउड प्रशासक हैं जो यह नहीं समझते कि एप्लिकेशन कैसे काम करते हैं? हम इस लेख में इन सवालों के जवाब देखेंगे।

YAML के रूप में बुनियादी ढाँचा

कठपुतली और शेफ से कुबेरनेट्स तक चली गई दुनिया में, सबसे बड़े बदलावों में से एक "कोड के रूप में बुनियादी ढांचे" से "डेटा के रूप में बुनियादी ढांचे" की ओर बढ़ना था - विशेष रूप से, वाईएएमएल की तरह। कुबेरनेट्स में सभी संसाधन, जिसमें पॉड्स, कॉन्फ़िगरेशन, तैनात इंस्टेंसेस, वॉल्यूम आदि शामिल हैं, को YAML फ़ाइल में आसानी से वर्णित किया जा सकता है। उदाहरण के लिए:

apiVersion: v1
kind: Pod
metadata:
  name: site
  labels:
    app: web
spec:
  containers:
    - name: front-end
      image: nginx
      ports:
        - containerPort: 80

यह दृश्य DevOps या SRE पेशेवरों के लिए पायथन या जावास्क्रिप्ट जैसी भाषाओं में कोड लिखे बिना अपने कार्यभार को पूरी तरह से व्यक्त करना आसान बनाता है।

डेटा के रूप में बुनियादी ढांचे को व्यवस्थित करने के अन्य लाभों में शामिल हैं:

• GitOps या Git ऑपरेशंस संस्करण नियंत्रण। यह दृष्टिकोण आपको सभी Kubernetes YAML फ़ाइलों को git रिपॉजिटरी में रखने की अनुमति देता है, ताकि आप सटीक रूप से ट्रैक कर सकें कि परिवर्तन कब किया गया, किसने किया और वास्तव में क्या बदला। इससे पूरे संगठन में परिचालन की पारदर्शिता बढ़ती है और अस्पष्टता को दूर करके परिचालन दक्षता में सुधार होता है, खासकर इस बारे में कि कर्मचारियों को उन संसाधनों की तलाश कहाँ करनी चाहिए जिनकी उन्हें आवश्यकता है। साथ ही, केवल पुल अनुरोध को मर्ज करके कुबेरनेट्स संसाधनों में स्वचालित रूप से परिवर्तन करना आसान हो जाता है।
• स्केलेबिलिटी। जब संसाधनों को YAML के रूप में परिभाषित किया जाता है, तो क्लस्टर ऑपरेटरों के लिए कुबेरनेट्स संसाधन में एक या दो नंबर बदलना बेहद आसान हो जाता है, जिससे इसके पैमाने में बदलाव होता है। कुबेरनेट्स पॉड्स के क्षैतिज ऑटोस्केलिंग के लिए एक तंत्र प्रदान करता है, जिसका उपयोग आसानी से यह निर्धारित करने के लिए किया जा सकता है कि ट्रैफ़िक के निम्न और उच्च स्तर को संभालने के लिए किसी विशेष परिनियोजन कॉन्फ़िगरेशन में पॉड्स की न्यूनतम और अधिकतम संख्या कितनी आवश्यक है। उदाहरण के लिए, यदि आपने कोई कॉन्फ़िगरेशन तैनात किया है जिसके लिए ट्रैफ़िक में अचानक वृद्धि के कारण अतिरिक्त क्षमता की आवश्यकता है, तो मैक्सरेप्लिकाज़ को 10 से 20 तक बदला जा सकता है:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp-deployment
  minReplicas: 1
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

• सुरक्षा एवं प्रबंधन. कुबेरनेट्स में चीजों को कैसे तैनात किया जाता है, इसका मूल्यांकन करने के लिए YAML बहुत अच्छा है। उदाहरण के लिए, एक प्रमुख सुरक्षा चिंता यह है कि क्या आपका कार्यभार गैर-व्यवस्थापक उपयोगकर्ता के रूप में चल रहा है। इस मामले में, हमें जैसे उपकरणों की आवश्यकता हो सकती है संघर्ष, валидатор YAML/JSON, плюс ओपन पॉलिसी एजेंट, संदर्भ सुनिश्चित करने के लिए एक नीति सत्यापनकर्ता सुरक्षा संदर्भ आपका कार्यभार कंटेनर को व्यवस्थापकीय विशेषाधिकारों के साथ चलने की अनुमति नहीं देता है। यदि यह आवश्यक है, तो उपयोगकर्ता एक सरल नीति लागू कर सकते हैं रेगो, इस कदर:

package main

deny[msg] {
  input.kind = "Deployment"
  not input.spec.template.spec.securityContext.runAsNonRoot = true
  msg = "Containers must not run as root"
}

• क्लाउड प्रदाता के साथ एकीकरण के विकल्प। आज की उच्च प्रौद्योगिकी में सबसे उल्लेखनीय रुझानों में से एक सार्वजनिक क्लाउड प्रदाताओं पर वर्कलोड चलाना है। घटक का उपयोग करना बादल-प्रदाता कुबेरनेट्स किसी भी क्लस्टर को उस क्लाउड प्रदाता के साथ एकीकृत करने की अनुमति देता है जिस पर वह चलता है। उदाहरण के लिए, यदि कोई उपयोगकर्ता AWS पर कुबेरनेट्स में एक एप्लिकेशन चलाता है और उस एप्लिकेशन को एक सेवा के माध्यम से प्रदर्शित करना चाहता है, तो क्लाउड प्रदाता स्वचालित रूप से सेवा बनाने में मदद करता है LoadBalancerजो स्वचालित रूप से लोड बैलेंसर प्रदान करेगा अमेज़ॅन इलास्टिक लोड बैलेंसरट्रैफ़िक को एप्लिकेशन पॉड्स पर पुनर्निर्देशित करने के लिए।

विस्तार

कुबेरनेट्स बहुत विस्तार योग्य है और डेवलपर्स इसे पसंद करते हैं। उपलब्ध संसाधनों का एक सेट है जैसे पॉड, परिनियोजन, StatefulSets, रहस्य, ConfigMaps, वगैरह। सच है, उपयोगकर्ता और डेवलपर फ़ॉर्म में अन्य संसाधन जोड़ सकते हैं कस्टम संसाधन परिभाषाएँ.

उदाहरण के लिए, यदि हम किसी संसाधन को परिभाषित करना चाहते हैं CronTab, तो आप ऐसा कुछ कर सकते हैं:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: crontabs.my.org
spec:
  group: my.org
  versions:
    - name: v1
      served: true
      storage: true
      Schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                cronSpec:
                  type: string
                  pattern: '^(d+|*)(/d+)?(s+(d+|*)(/d+)?){4}$'
                replicas:
                  type: integer
                  minimum: 1
                  maximum: 10
  scope: Namespaced
  names:
    plural: crontabs
    singular: crontab
    kind: CronTab
    shortNames:
    - ct

बाद में हम क्रोनटैब संसाधन कुछ इस तरह बना सकते हैं:

apiVersion: "my.org/v1"
kind: CronTab
metadata:
  name: my-cron-object
spec:
  cronSpec: "* * * * */5"
  image: my-cron-image
  replicas: 5

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

समुदाय में ऐसे कई उपकरण हैं जो डेवलपर्स के लिए अपने स्वयं के ऑपरेटर बनाना आसान बनाते हैं। उनमें से - ऑपरेटर ढाँचा और ऑपरेटर एसडीके. यह एसडीके एक आधार प्रदान करता है जिससे एक डेवलपर तुरंत एक ऑपरेटर बनाना शुरू कर सकता है। मान लीजिए कि आप कमांड लाइन से कुछ इस तरह से शुरुआत कर सकते हैं:

$ operator-sdk new my-operator --repo github.com/myuser/my-operator

यह आपके ऑपरेटर के लिए सभी बॉयलरप्लेट कोड बनाता है, जिसमें YAML फ़ाइलें और गोलांग कोड शामिल हैं:

.
|____cmd
| |____manager
| | |____main.go
|____go.mod
|____deploy
| |____role.yaml
| |____role_binding.yaml
| |____service_account.yaml
| |____operator.yaml
|____tools.go
|____go.sum
|____.gitignore
|____version
| |____version.go
|____build
| |____bin
| | |____user_setup
| | |____entrypoint
| |____Dockerfile
|____pkg
| |____apis
| | |____apis.go
| |____controller
| | |____controller.go

फिर आप इस तरह आवश्यक एपीआई और नियंत्रक जोड़ सकते हैं:

$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService

$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppService

फिर, अंत में, ऑपरेटर को इकट्ठा करें और इसे अपने कंटेनर की रजिस्ट्री में भेजें:

$ operator-sdk build your.container.registry/youruser/myapp-operator

Если разработчику требуется еще более полный контроль, то можно изменить стереотипный код в файлах на Go. Например, чтобы видоизменить специфику контроллера, можно внести изменения в файл controller.go.

एक और परियोजना हर जगह, आपको केवल घोषणात्मक YAML फ़ाइलों का उपयोग करके कथन बनाने की अनुमति देता है। उदाहरण के लिए, अपाचे काफ्का के लिए एक ऑपरेटर को लगभग परिभाषित किया जाएगा इसलिए. इसके साथ, आप केवल कुछ कमांड के साथ कुबेरनेट्स के शीर्ष पर काफ्का क्लस्टर स्थापित कर सकते हैं:

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

और फिर इसे किसी अन्य कमांड से कॉन्फ़िगर करें:

$ kubectl kudo install kafka --instance=my-kafka-name 
            -p ZOOKEEPER_URI=zk-zookeeper-0.zk-hs:2181 
            -p ZOOKEEPER_PATH=/my-path -p BROKER_CPUS=3000m 
            -p BROKER_COUNT=5 -p BROKER_MEM=4096m 
            -p DISK_SIZE=40Gi -p MIN_INSYNC_REPLICAS=3 
            -p NUM_NETWORK_THREADS=10 -p NUM_IO_THREADS=20

नवाचारों

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

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

समुदाय

कुबेरनेट्स की लोकप्रियता का एक अन्य प्रमुख पहलू इसके समुदाय की ताकत है। 2015 में, संस्करण 1.0 तक पहुंचने पर, कुबेरनेट्स को प्रायोजित किया गया था क्लाउड नेटिव कम्प्यूटिंग फाउंडेशन.

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

क्लाउड नेटिव फ़ाउंडेशन CloudNativeCon/KubeCon की भी मेजबानी करता है, जो लेखन के समय, दुनिया का सबसे बड़ा ओपन सोर्स सम्मेलन है। आम तौर पर साल में तीन बार आयोजित किया जाता है, यह उन हजारों पेशेवरों को एक साथ लाता है जो कुबेरनेट्स और इसके पारिस्थितिकी तंत्र में सुधार करना चाहते हैं, साथ ही हर तीन महीने में आने वाली नई सुविधाओं को सीखना चाहते हैं।

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

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

द फ्यूचर

भविष्य में डेवलपर्स को जिन मुख्य चुनौतियों से निपटना होगा उनमें से एक है कोड के विवरण पर ध्यान केंद्रित करने की क्षमता, न कि उस बुनियादी ढांचे पर जिसमें यह चलता है। यह इन रुझानों को पूरा करता है सर्वर रहित वास्तुशिल्प प्रतिमान, जो आज अग्रणी में से एक है। उन्नत ढाँचे पहले से मौजूद हैं, उदा. चाकू и ओपनफास, जो डेवलपर से बुनियादी ढांचे को अलग करने के लिए कुबेरनेट्स का उपयोग करते हैं।

इस लेख में, हमने केवल कुबेरनेट्स की वर्तमान स्थिति की सतह को खंगाला है - वास्तव में, यह सिर्फ हिमशैल का सिरा है। कुबेरनेट्स उपयोगकर्ताओं के पास अपने निपटान में कई अन्य संसाधन, क्षमताएं और कॉन्फ़िगरेशन हैं।

स्रोत: www.habr.com