Kubernetes جي وڌندڙ مقبوليت بابت

اي حبر!

اونهاري جي آخر ۾، اسان توهان کي ياد ڏيارڻ چاهيون ٿا ته اسان موضوع تي ڪم جاري رکون ٿا ڪوبنيٿس ۽ اسٽيڪ اوور فلو مان هڪ مضمون شايع ڪرڻ جو فيصلو ڪيو جيڪو جون جي شروعات ۾ هن منصوبي ۾ معاملن جي حالت جو مظاهرو ڪندي.

پڙهڻ جو مزو

هن مضمون لکڻ جي وقت، ڪبرنيٽس جي عمر تقريبن آهي. ڇهه سال پراڻي، ۽ گذريل ٻن سالن ۾ ان جي مقبوليت ايتري وڌي وئي آهي جو ان جي وچ ۾ مسلسل درجه بندي ڪئي وئي آهي سڀ کان وڌيڪ پسنديده پليٽ فارم ڪبرنيٽس هن سال ٽئين نمبر تي آهي. ٻيهر حاصل ڪرڻ لاءِ: ڪبرنيٽس هڪ پليٽ فارم آهي جيڪو هلائڻ ۽ ترتيب ڏيڻ لاءِ ٺهيل آهي ڪنٽينر ٿيل ڪم لوڊ.

ڪنٽينر لينڪس ۾ الڳ ڪرڻ واري عمل لاءِ خاص ڊزائين جي طور تي شروع ٿيا. ڪنٽينر 2007 کان شامل آهن گروپ، ۽ 2002 کان وٺي - نالي جي جڳھ. ڪنٽينر 2008 تائين اڃا به بهتر ٺهيل هئا، جڏهن اهو دستياب ٿيو LXC، ۽ گوگل پنهنجو اندروني ڪارپوريٽ ميڪانيزم تيار ڪيو جنهن کي سڏيو ويندو آهي بور، جتي "سڀ ڪم ڪنٽينر ۾ ڪيو ويندو آهي." هتان کان اسان 2013 تائين تيزيء سان اڳتي وڌو، جڏهن ڊاکر جي پهرين رليز ٿي وئي، ۽ ڪنٽينر آخرڪار هڪ مشهور ڪاميٽي حل بڻجي ويا. ان وقت ڪنٽينر آرڪيسٽريشن جو مکيه اوزار هو ميسوجيتوڻيڪ هو بيحد مقبول نه هو. Kubernetes پهريون ڀيرو 2015 ۾ جاري ڪيو ويو، جنهن کان پوء هي اوزار ڪنٽينر آرڪيسٽريشن جي ميدان ۾ حقيقي معيار بڻجي ويو.

سمجھڻ جي ڪوشش ڇو ڪبرنيٽس ايترو مشهور آهي، اچو ته ڪجھ سوالن جا جواب ڏيڻ جي ڪوشش ڪريو. آخري وقت جڏهن ڊولپرز ان ڳالهه تي اتفاق ڪرڻ جي قابل هئا ته ايپليڪيشنن کي پيداوار ۾ ڪيئن لڳايو وڃي؟ توهان ڪيترا ڊولپر ڄاڻو ٿا جيڪي اوزار استعمال ڪندا آهن جيئن اهي دٻي مان مهيا ڪيا ويا آهن؟ اڄ ڪيترا ڪلائوڊ ايڊمنسٽريٽر آهن جيڪي نٿا سمجهن ته ايپليڪيشنون ڪيئن ڪم ڪن ٿيون؟ اسان هن مضمون ۾ انهن سوالن جا جواب نظر ايندا.

انفراسٹرڪچر YAML طور

دنيا ۾ جيڪا Puppet ۽ Chef کان Kubernetes ڏانهن وئي، هڪ وڏي تبديلي هئي ”انفراسٽرڪچر ايز ڪوڊ“ کان ”انفراسٽرڪچر ايز ڊيٽا“ ڏانهن - خاص طور تي، YAML وانگر. Kubernetes ۾ سڀئي وسيلا، جن ۾ پوڊ، ترتيب، ترتيب ڏنل مثال، حجم، وغيره شامل آهن، آساني سان 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 آپريشن نسخو ڪنٽرول. اهو طريقو توهان کي اجازت ڏئي ٿو ته سڀني ڪبرنيٽس YAML فائلن کي گٽ ريپوزٽريز ۾ رکڻ لاءِ، تنهن ڪري توهان ٽريڪ ڪري سگهو ٿا صحيح طور تي جڏهن تبديلي ڪئي وئي هئي، ڪنهن ڪئي، ۽ ڇا واقعي تبديل ٿيو. اهو سڄي تنظيم ۾ عملن جي شفافيت کي وڌائي ٿو ۽ ابهام کي ختم ڪندي آپريشنل ڪارڪردگي کي بهتر بڻائي ٿو، خاص طور تي جتي ملازمن کي گهربل وسيلن کي ڳولڻ گهرجي. ساڳئي وقت، اهو آسان ٿي ويندو آهي خودڪار طريقي سان تبديلين کي Kubernetes وسيلن ۾ صرف هڪ پل جي درخواست کي ضم ڪندي.
• اسڪاليبلٽي. جڏهن وسيلن کي 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

• سيڪيورٽي ۽ انتظام. YAML اهو جائزو وٺڻ لاءِ وڏو آهي ته ڪبرنيٽس ۾ شيون ڪيئن ٺهيون آهن. مثال طور، هڪ وڏي سيڪيورٽي خدشن جو خدشو آهي ته ڇا توهان جو ڪم لوڊ هڪ غير منتظم صارف جي طور تي هلائي رهيا آهن. انهي حالت ۾، اسان کي شايد اوزار جي ضرورت هجي جهڙوڪ مقابلو، YAML/JSON تصديق ڪندڙ، پلس اوپن پاليسي ايجنٽ, هڪ پاليسي validator کي يقيني بڻائڻ لاء ته حوالي سان سيڪيورٽي جو حوالو توهان جو ڪم لوڊ ڪنٽينر کي منتظم جي استحقاق سان هلائڻ جي اجازت نٿو ڏئي. جيڪڏھن اھو گھربل آھي، صارف ھڪڙي سادي پاليسي لاڳو ڪري سگھن ٿا مان دعا ڪريان ٿو، هن وانگر:

package main

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

• بادل فراهم ڪندڙ سان انضمام جا اختيار. اڄ جي اعلي ٽيڪنالاجي ۾ سڀ کان وڌيڪ قابل ذڪر رجحانات مان هڪ آهي عوامي ڪلائوڊ فراهم ڪندڙن تي ڪم لوڊ هلائڻ. جزو استعمال ڪندي بادل مهيا ڪندڙ ڪبرنيٽس ڪنهن به ڪلستر کي بادل فراهم ڪندڙ سان ضم ڪرڻ جي اجازت ڏئي ٿو جنهن تي اهو هلندو آهي. مثال طور، جيڪڏهن ڪو صارف AWS تي Kubernetes ۾ هڪ ايپليڪيشن هلائي ٿو ۽ انهي ايپليڪيشن کي ڪنهن سروس ذريعي بي نقاب ڪرڻ چاهي ٿو، ڪلائوڊ فراهم ڪندڙ خودڪار طريقي سان خدمت ٺاهڻ ۾ مدد ڪري ٿو LoadBalancerجيڪو خودڪار طور تي لوڊ بيلنس فراهم ڪندو Amazon لچڪدار لوڊ بيلنسٽريفڪ کي ايپليڪيشن پوڊز ڏانهن منتقل ڪرڻ لاءِ.

وسعت

ڪبرنيٽس تمام وسيع آهي ۽ ڊولپر ان کي پسند ڪن ٿا. اتي موجود وسيلن جو هڪ سيٽ آهي جهڙوڪ پوڊ، ڊيپلائيشن، 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

بعد ۾ اسان ٺاهي سگهون ٿا هڪ CronTab وسيلو ڪجهه هن طرح:

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

Kubernetes ۾ وڌائڻ لاء هڪ ٻيو اختيار اهو آهي ته ڊولپر پنهنجو بيان لکي سگهي ٿو. آپريٽر 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

پوء توهان گهربل APIs ۽ ڪنٽرولر شامل ڪري سگھو ٿا، جهڙوڪ:

$ 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 تي.

نيون صلاحيتون توهان کي وڌيڪ لچڪدار طريقي سان ڪلسٽر آپريشنز جي مختلف ڪم لوڊ لوڊ ڪرڻ جي اجازت ڏين ٿيون. ان کان علاوه، پروگرامر وڌيڪ ڪنٽرول حاصل ڪن ٿا جڏهن ايپليڪيشنن کي سڌو سنئون پيداوار تي ترتيب ڏيو.

برادري

ڪبرنيٽس جي مقبوليت جو هڪ ٻيو اهم پاسو ان جي ڪميونٽي جي طاقت آهي. 2015 ۾، ورزن 1.0 تائين پهچڻ تي، ڪبرنيٽس پاران اسپانسر ڪيو ويو ڪلائوڊ اصلي ڪمپيوٽنگ فائونڊيشن.

اتي پڻ مختلف برادريون آهن SIG (خاص دلچسپي گروپ) ڪبرنيٽس جي مختلف علائقن تي ڪم ڪرڻ تي ڌيان ڏنو جيئن پروجيڪٽ ترقي ڪري ٿو. اهي گروپ مسلسل نيون خاصيتون شامل ڪري رهيا آهن، Kubernetes سان ڪم ڪرڻ کي وڌيڪ آسان ۽ آسان بڻائي رهيا آهن.

Cloud Native فائونڊيشن پڻ CloudNativeCon/KubeCon جي ميزباني ڪري ٿي، جيڪا لکڻ جي وقت تي، دنيا ۾ سڀ کان وڏي اوپن سورس ڪانفرنس آهي. عام طور تي سال ۾ ٽي ڀيرا منعقد ڪيو ويندو آهي، اهو هزارين پروفيسر گڏ ڪري ٿو جيڪي ڪبرنيٽس ۽ ان جي ماحولياتي نظام کي بهتر بڻائڻ چاهيندا آهن، انهي سان گڏ نئين خاصيتون سکڻ چاهيندا آهن جيڪي هر ٽن مهينن ۾ ظاهر ٿيندا آهن.

ان کان علاوه، Cloud Native فائونڊيشن آهي ٽيڪنيڪل نگراني ڪميٽي، جيڪو، SIGs سان گڏ، نئين ۽ موجوده جو جائزو وٺندو آهي منصوبا فنڊ ڪلائوڊ ايڪو سسٽم تي مرکوز. انهن مان گهڻا منصوبا ڪبرنيٽس جي طاقت کي بهتر بنائڻ ۾ مدد ڪن ٿا.

آخرڪار، مان سمجهان ٿو ته ڪبرنيٽس ايترو ڪامياب نه ٿي سگهندو جيترو اهو سڄي ڪميونٽي جي شعوري ڪوششن کان سواءِ آهي، جتي ماڻهو گڏ هوندا آهن پر ساڳئي وقت نون ايندڙن کي ڀليڪار ڪندا آهن.

مستقبل

هڪ اهم چئلينجن مان هڪ آهي جيڪو ڊولپرز کي مستقبل ۾ منهن ڏيڻو پوندو ڪوڊ جي تفصيل تي ڌيان ڏيڻ جي صلاحيت آهي، ۽ نه ته انفراسٽرڪچر تي جنهن ۾ اهو هلندو آهي. اهو انهن رجحانن کي پورو ڪري ٿو بي سرور تعميراتي نمونو، جيڪو اڄ جي اڳواڻن مان هڪ آهي. ترقي يافته فريم ورڪ اڳ ۾ ئي موجود آهن، مثال طور اصلي и OpenFaas، جيڪي ڊولپر کان انفراسٽرڪچر کي ختم ڪرڻ لاءِ ڪبرنيٽس استعمال ڪندا آهن.

هن آرٽيڪل ۾، اسان صرف ڪبرنيٽس جي موجوده حالت جي مٿاڇري کي ڇڪايو آهي- حقيقت ۾، اهو صرف برفاني ٽڪر جو ٽپ آهي. Kubernetes استعمال ڪندڙن وٽ ڪيترائي ٻيا وسيلا، صلاحيتون، ۽ ٺاھ جوڙ سندن اختيار ۾ آھي.

جو ذريعو: www.habr.com