🥇कुबर्नेट्सच्या वाढत्या लोकप्रियतेबद्दल

अहो हाब्र!

उन्हाळ्याच्या शेवटी, आम्ही तुम्हाला आठवण करून देऊ इच्छितो की आम्ही या विषयावर काम करणे सुरू ठेवतो कुबेरनेट्स आणि जूनच्या सुरुवातीला या प्रकल्पातील घडामोडींची स्थिती दर्शविणारा एक लेख स्टॅकओव्हरफ्लोमधून प्रकाशित करण्याचा निर्णय घेतला.

वाचन आनंद घ्या!

हा लेख लिहिताना, कुबर्नेट्सचे वय अंदाजे आहे. सहा वर्षांचा, आणि गेल्या दोन वर्षांत त्याची लोकप्रियता इतकी वाढली आहे की ती सातत्याने क्रमवारीत आहे सर्वात आवडते प्लॅटफॉर्म कुबरनेटेस या वर्षी तिसऱ्या क्रमांकावर आहे. रीकॅप करण्यासाठी: Kubernetes हे कंटेनरीकृत वर्कलोड्स चालवण्यासाठी आणि ऑर्केस्ट्रेट करण्यासाठी डिझाइन केलेले प्लॅटफॉर्म आहे.

लिनक्समधील प्रक्रिया अलग ठेवण्यासाठी कंटेनरची सुरुवात विशेष रचना म्हणून झाली; 2007 पासून कंटेनर समाविष्ट आहेत cgroups, आणि 2002 पासून - नेमस्पेसेस. 2008 मध्ये जेव्हा ते उपलब्ध झाले तेव्हा कंटेनरची रचना आणखी चांगली झाली एलएक्ससी, आणि Google ने स्वतःची अंतर्गत कॉर्पोरेट यंत्रणा विकसित केली बोर्ग, जेथे "सर्व काम कंटेनरमध्ये केले जाते." येथून आम्ही 2013 पर्यंत फास्ट फॉरवर्ड केले, जेव्हा डॉकरचे पहिले प्रकाशन झाले आणि कंटेनर शेवटी एक लोकप्रिय मास सोल्यूशन बनले. त्या वेळी कंटेनर ऑर्केस्ट्रेशनचे मुख्य साधन होते मेसोस, जरी तो अत्यंत लोकप्रिय नव्हता. Kubernetes प्रथम 2015 मध्ये रिलीझ करण्यात आले होते, त्यानंतर हे साधन कंटेनर ऑर्केस्ट्रेशनच्या क्षेत्रात वास्तविक मानक बनले.

कुबर्नेट्स इतके लोकप्रिय का आहे हे समजून घेण्याचा प्रयत्न करण्यासाठी, चला काही प्रश्नांची उत्तरे देण्याचा प्रयत्न करूया. उत्पादनासाठी ऍप्लिकेशन्स कसे उपयोजित करायचे यावर शेवटच्या वेळी विकासक कधी सहमत झाले होते? तुम्हाला किती डेव्हलपर माहित आहेत जे साधने वापरतात कारण ते बॉक्सच्या बाहेर दिले जातात? आज किती क्लाउड प्रशासक आहेत ज्यांना अनुप्रयोग कसे कार्य करतात हे समजत नाही? या प्रश्नांची उत्तरे आपण या लेखात पाहू.

YAML म्हणून पायाभूत सुविधा

कठपुतळी आणि शेफपासून कुबेरनेट्सपर्यंत गेलेल्या जगात, सर्वात मोठा बदल म्हणजे “कोड म्हणून पायाभूत सुविधा” वरून “डेटा म्हणून पायाभूत सुविधा” - विशेषत: YAML प्रमाणे. कुबर्नेट्स मधील सर्व संसाधने, ज्यामध्ये पॉड्स, कॉन्फिगरेशन, उपयोजित उदाहरणे, व्हॉल्यूम इत्यादींचा समावेश आहे, YAML फाइलमध्ये सहजपणे वर्णन केले जाऊ शकते. उदाहरणार्थ:

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

या दृश्यामुळे DevOps किंवा SRE व्यावसायिकांना Python किंवा Javascript सारख्या भाषांमध्ये कोड न लिहिता त्यांचे वर्कलोड पूर्णपणे व्यक्त करणे सोपे होते.

डेटा म्हणून पायाभूत सुविधा आयोजित करण्याच्या इतर फायद्यांमध्ये हे समाविष्ट आहे:

GitOps किंवा Git ऑपरेशन्स आवृत्ती नियंत्रण. हा दृष्टिकोन तुम्हाला सर्व Kubernetes YAML फाइल्स git रिपॉझिटरीजमध्ये ठेवण्याची परवानगी देतो, ज्यामुळे तुम्ही बदल केव्हा झाला, कोणी केला आणि नेमका काय बदल झाला याचा मागोवा घेऊ शकता. यामुळे संपूर्ण संस्थेतील ऑपरेशन्सची पारदर्शकता वाढते आणि संदिग्धता दूर करून ऑपरेशनल कार्यक्षमता सुधारते, विशेषत: जिथे कर्मचाऱ्यांनी त्यांना आवश्यक संसाधने शोधली पाहिजेत. त्याच वेळी, फक्त पुल विनंती विलीन करून कुबर्नेट्स संसाधनांमध्ये आपोआप बदल करणे सोपे होते.
स्केलेबिलिटी. जेव्हा संसाधनांची YAML म्हणून व्याख्या केली जाते, तेव्हा क्लस्टर ऑपरेटरसाठी कुबर्नेट्स रिसोर्समध्ये एक किंवा दोन संख्या बदलणे अत्यंत सोपे होते, ज्यामुळे ते कसे स्केल होते ते बदलते. कुबर्नेट्स पॉड्सच्या क्षैतिज ऑटोस्केलिंगसाठी एक यंत्रणा प्रदान करते, ज्याचा वापर कमी आणि उच्च स्तरावरील रहदारी हाताळण्यासाठी विशिष्ट तैनाती कॉन्फिगरेशनमध्ये किमान आणि कमाल किती पॉड्स आवश्यक आहेत हे सोयीस्करपणे निर्धारित करण्यासाठी वापरला जाऊ शकतो. उदाहरणार्थ, जर तुम्ही एखादे कॉन्फिगरेशन उपयोजित केले असेल ज्यासाठी रहदारीमध्ये अचानक वाढ झाल्यामुळे अतिरिक्त क्षमतेची आवश्यकता असेल, तर maxReplicas 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

सुरक्षा आणि व्यवस्थापन. Kubernetes मध्ये गोष्टी कशा तैनात केल्या जातात याचे मूल्यांकन करण्यासाठी 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"
}

क्लाउड प्रदात्यासह एकत्रीकरणासाठी पर्याय. आजच्या उच्च तंत्रज्ञानातील सर्वात लक्षणीय ट्रेंड म्हणजे सार्वजनिक क्लाउड प्रदात्यांवर वर्कलोड चालवणे. घटक वापरणे क्लाउड-प्रदाता Kubernetes कोणत्याही क्लस्टरला क्लाउड प्रदात्यासह समाकलित करण्यास अनुमती देते ज्यावर ते चालते. उदाहरणार्थ, जर वापरकर्ता AWS वर Kubernetes मध्ये ऍप्लिकेशन चालवतो आणि तो ऍप्लिकेशन एखाद्या सेवेद्वारे उघड करू इच्छित असल्यास, क्लाउड प्रदाता आपोआप सेवा तयार करण्यात मदत करतो LoadBalancerजे स्वयंचलितपणे लोड बॅलन्सर प्रदान करेल ऍमेझॉन लवचिक लोड बॅलेंसरअॅप्लिकेशन पॉड्सवर रहदारी पुनर्निर्देशित करण्यासाठी.

विस्तारक्षमता

Kubernetes खूप विस्तारण्यायोग्य आहे आणि विकसकांना ते आवडते. उपलब्ध संसाधनांचा एक संच आहे जसे की शेंगा, उपयोजन, 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

Kubernetes मधील विस्तारक्षमतेचा दुसरा पर्याय म्हणजे विकसक स्वतःची विधाने लिहू शकतो. ऑपरेटर कुबर्नेट्स क्लस्टरमधील एक विशेष प्रक्रिया आहे जी "नियंत्रण सर्किट" ऑपरेटरच्या मदतीने, वापरकर्ता कुबर्नेट्स API सोबत माहितीची देवाणघेवाण करून CRDs (कस्टम रिसोर्स डेफिनिशन) चे व्यवस्थापन स्वयंचलित करू शकतो.

समुदायामध्ये अशी अनेक साधने आहेत जी विकासकांना त्यांचे स्वतःचे ऑपरेटर तयार करणे सोपे करतात. त्यापैकी - ऑपरेटर फ्रेमवर्क आणि त्याचे ऑपरेटर SDK. हा SDK एक पाया प्रदान करतो ज्यामधून विकसक त्वरीत ऑपरेटर तयार करण्यास सुरवात करू शकतो. समजा तुम्ही कमांड लाइनवरून यासारखे काहीतरी सुरू करू शकता:

$ 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

मग आपण आवश्यक API आणि नियंत्रक जोडू शकता, जसे की:

$ 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 फायली वापरून विधाने तयार करण्याची परवानगी देते. उदाहरणार्थ, Apache Kafka साठी ऑपरेटर अंदाजे परिभाषित केले जाईल त्यामुळे. त्यासह, तुम्ही कुबर्नेट्सच्या शीर्षस्थानी फक्त दोन कमांडसह काफ्का क्लस्टर स्थापित करू शकता:

$ 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

नाविन्य

गेल्या काही वर्षांमध्ये, दर काही महिन्यांनी प्रमुख कुबर्नेट्स रिलीझ येत आहेत - म्हणजेच वर्षाला तीन ते चार प्रमुख रिलीझ. त्या प्रत्येकामध्ये सादर केलेल्या नवीन वैशिष्ट्यांची संख्या कमी होत नाही. शिवाय, या कठीण काळातही गती कमी होण्याची चिन्हे नाहीत - आता काय परिस्थिती आहे ते पहा Github वर Kubernetes प्रकल्प क्रियाकलाप.

नवीन क्षमता तुम्हाला विविध वर्कलोडमध्ये अधिक लवचिकपणे क्लस्टर ऑपरेशन्स करण्याची परवानगी देतात. याव्यतिरिक्त, प्रोग्रॅमर थेट उत्पादनावर अनुप्रयोग तैनात करताना अधिक नियंत्रणाचा आनंद घेतात.

समुदाय

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

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

क्लाउड नेटिव्ह फाउंडेशन CloudNativeCon/KubeCon चे आयोजन देखील करते, जे लेखनाच्या वेळी जगातील सर्वात मोठी मुक्त स्रोत परिषद आहे. सामान्यत: वर्षातून तीन वेळा आयोजित केले जाते, ते हजारो व्यावसायिकांना एकत्र आणते ज्यांना कुबर्नेट्स आणि त्याची इकोसिस्टम सुधारायची आहे, तसेच दर तीन महिन्यांनी दिसणारी नवीन वैशिष्ट्ये शिकायची आहेत.

शिवाय, क्लाउड नेटिव्ह फाउंडेशनकडे आहे तांत्रिक पर्यवेक्षण समिती, जे, SIGs सह, नवीन आणि विद्यमान पुनरावलोकने प्रकल्प क्लाउड इकोसिस्टमवर केंद्रित निधी. यापैकी बहुतेक प्रकल्प कुबर्नेट्सची ताकद सुधारण्यास मदत करतात.

शेवटी, माझा विश्वास आहे की कुबर्नेट्स हे संपूर्ण समुदायाच्या जाणीवपूर्वक प्रयत्नांशिवाय तितके यशस्वी होणार नाही, जिथे लोक एकत्र राहतात परंतु त्याच वेळी नवीन लोकांचे स्वागत करतात.

भविष्य

विकासकांना भविष्यात ज्या मुख्य आव्हानांना सामोरे जावे लागेल ते म्हणजे कोडच्या तपशीलांवर लक्ष केंद्रित करण्याची क्षमता, आणि तो ज्या पायाभूत सुविधांमध्ये चालतो त्यावर नाही. हे या ट्रेंडची पूर्तता करते सर्व्हरलेस आर्किटेक्चरल नमुना, जे आज अग्रगण्यांपैकी एक आहे. प्रगत फ्रेमवर्क आधीपासूनच अस्तित्वात आहेत, उदा. जन्मजात и OpenFaas, जे डेव्हलपरकडून पायाभूत सुविधांचे अ‍ॅबस्ट्रॅक्ट करण्यासाठी कुबर्नेट्स वापरतात.

या लेखात, आम्ही कुबर्नेट्सच्या सद्य स्थितीचा फक्त पृष्ठभाग स्क्रॅच केला आहे—खरेतर, ते फक्त हिमखंडाचे टोक आहे. Kubernetes वापरकर्त्यांकडे इतर अनेक संसाधने, क्षमता आणि कॉन्फिगरेशन आहेत.

स्त्रोत: www.habr.com

कुबर्नेट्सच्या वाढत्या लोकप्रियतेबद्दल

YAML म्हणून पायाभूत सुविधा

विस्तारक्षमता

नाविन्य

समुदाय

भविष्य

एक टिप्पणी जोडा Отменить ответ