Kubernetes کی بڑھتی ہوئی مقبولیت کے بارے میں

ارے حبر!

موسم گرما کے اختتام پر، ہم آپ کو یاد دلانا چاہتے ہیں کہ ہم اس موضوع پر کام جاری رکھیں گے۔ Kubernetes اور جون کے آغاز میں اس پراجیکٹ میں حالات کی صورتحال کو ظاہر کرنے والے Stackoverflow سے ایک مضمون شائع کرنے کا فیصلہ کیا۔

پڑھنے کا لطف اٹھائیں!

یہ مضمون لکھنے کے وقت، Kubernetes کی عمر لگ بھگ ہے۔ چھ سال کی عمر، اور پچھلے دو سالوں میں اس کی مقبولیت اتنی بڑھ گئی ہے کہ اسے مسلسل درجہ بندی میں رکھا جاتا ہے۔ سب سے زیادہ پسندیدہ پلیٹ فارمز Kubernetes اس سال تیسرے نمبر پر ہے۔ دوبارہ حاصل کرنے کے لیے: Kubernetes ایک پلیٹ فارم ہے جو کنٹینرائزڈ کام کے بوجھ کو چلانے اور ترتیب دینے کے لیے ڈیزائن کیا گیا ہے۔

کنٹینرز لینکس میں عمل کو الگ کرنے کے لیے ایک خاص ڈیزائن کے طور پر شروع ہوئے تھے۔ کنٹینرز 2007 سے شامل ہیں۔ سی گروپس، اور 2002 سے - نام کی جگہیں۔ کنٹینرز کو 2008 تک اور بھی بہتر ڈیزائن کیا گیا تھا، جب یہ دستیاب ہوا تھا۔ ایل ایکس سی، اور گوگل نے اپنا اندرونی کارپوریٹ میکانزم تیار کیا جسے کہا جاتا ہے۔ بورگ، جہاں "تمام کام کنٹینرز میں کیا جاتا ہے۔" یہاں سے ہم تیزی سے آگے 2013 تک پہنچ گئے، جب ڈوکر کی پہلی ریلیز ہوئی، اور آخر کار کنٹینرز ایک مقبول بڑے پیمانے پر حل بن گئے۔ اس وقت، کنٹینر آرکیسٹریشن کا بنیادی آلہ تھا میسوساگرچہ وہ بے حد مقبول نہیں تھا۔ Kubernetes کو پہلی بار 2015 میں ریلیز کیا گیا تھا، جس کے بعد یہ ٹول کنٹینر آرکیسٹریشن کے میدان میں ڈی فیکٹو سٹینڈرڈ بن گیا۔

یہ سمجھنے کی کوشش کریں کہ کبرنیٹ اتنا مقبول کیوں ہے، آئیے چند سوالوں کے جواب دینے کی کوشش کریں۔ آخری بار کب ڈویلپرز اس بات پر متفق ہوئے تھے کہ پروڈکشن میں ایپلیکیشنز کو کیسے تعینات کیا جائے؟ آپ کتنے ڈویلپرز کو جانتے ہیں جو ٹولز کا استعمال کرتے ہیں جیسا کہ وہ باکس سے باہر فراہم کیے جاتے ہیں؟ آج کل کتنے کلاؤڈ ایڈمنسٹریٹرز ہیں جو نہیں سمجھتے کہ ایپلی کیشنز کیسے کام کرتی ہیں؟ ہم اس مضمون میں ان سوالات کے جوابات دیکھیں گے۔

بنیادی ڈھانچہ بطور YAML

دنیا میں جو کٹھ پتلی اور شیف سے 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 پیشہ ور افراد کے لیے Python یا Javascript جیسی زبانوں میں کوڈ لکھے بغیر اپنے کام کے بوجھ کو مکمل طور پر ظاہر کرنا آسان بناتا ہے۔

ڈیٹا کے طور پر انفراسٹرکچر کو منظم کرنے کے دیگر فوائد میں شامل ہیں:

• GitOps یا Git آپریشنز ورژن کنٹرول۔ یہ نقطہ نظر آپ کو تمام Kubernetes YAML فائلوں کو گٹ ریپوزٹریز میں رکھنے کی اجازت دیتا ہے، تاکہ آپ بالکل ٹریک کر سکیں کہ تبدیلی کب ہوئی، کس نے کی، اور بالکل کیا تبدیلی آئی۔ اس سے پوری تنظیم میں کارروائیوں کی شفافیت میں اضافہ ہوتا ہے اور ابہام کو ختم کرکے آپریشنل کارکردگی کو بہتر بنایا جاتا ہے، خاص طور پر جہاں ملازمین کو اپنی ضرورت کے وسائل تلاش کرنے چاہئیں۔ ایک ہی وقت میں، بس پل کی درخواست کو ضم کر کے Kubernetes کے وسائل میں خود بخود تبدیلیاں کرنا آسان ہو جاتا ہے۔
• توسیع پذیری جب وسائل کی تعریف YAML کے طور پر کی جاتی ہے، تو کلسٹر آپریٹرز کے لیے Kubernetes ریسورس میں ایک یا دو نمبروں کو تبدیل کرنا انتہائی آسان ہو جاتا ہے، اس طرح یہ تبدیل ہو جاتا ہے کہ اس کے پیمانے کیسے ہوتے ہیں۔ Kubernetes پوڈز کی افقی آٹو اسکیلنگ کے لیے ایک طریقہ کار فراہم کرتا ہے، جس کا استعمال آسانی سے یہ تعین کرنے کے لیے کیا جا سکتا ہے کہ کم اور زیادہ ٹریفک کو سنبھالنے کے لیے مخصوص تعیناتی کنفیگریشن میں پوڈز کی کم از کم اور زیادہ سے زیادہ تعداد کی کیا ضرورت ہے۔ مثال کے طور پر، اگر آپ نے ایک ایسی کنفیگریشن تعینات کی ہے جس کے لیے ٹریفک میں اچانک اضافے کی وجہ سے اضافی صلاحیت کی ضرورت ہے، تو 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 اس بات کا جائزہ لینے کے لیے بہت اچھا ہے کہ Kubernetes میں چیزوں کو کیسے تعینات کیا جاتا ہے۔ مثال کے طور پر، سیکیورٹی کی ایک بڑی تشویش یہ ہے کہ آیا آپ کے کام کے بوجھ ایک غیر منتظم صارف کے طور پر چل رہے ہیں۔ اس صورت میں، ہمیں اس طرح کے اوزار کی ضرورت ہوسکتی ہے مقابلہ، 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

بعد میں ہم ایک CronTab وسیلہ کچھ اس طرح بنا سکتے ہیں:

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

Kubernetes میں توسیع پذیری کا دوسرا آپشن یہ ہے کہ ڈویلپر اپنے بیانات خود لکھ سکتا ہے۔ آپریٹر۔ 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

اگر ڈویلپر مزید کنٹرول چاہتا ہے تو گو فائلوں میں بوائلر پلیٹ کوڈ کو تبدیل کیا جا سکتا ہے۔ مثال کے طور پر، کنٹرولر کی تفصیلات میں ترمیم کرنے کے لیے، آپ فائل میں تبدیلیاں کر سکتے ہیں۔ 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

انوویشن

پچھلے کچھ سالوں میں، ہر چند مہینوں میں کبرنیٹس کی بڑی ریلیز سامنے آ رہی ہیں - یعنی ہر سال تین سے چار بڑی ریلیزز۔ ان میں سے ہر ایک میں متعارف کرائے گئے نئے فیچرز کی تعداد کم نہیں ہوتی۔ مزید یہ کہ ان مشکل وقتوں میں بھی سست روی کے آثار نظر نہیں آرہے - دیکھئے اب کیا صورتحال ہے۔ گتھب پر کبرنیٹس پروجیکٹ کی سرگرمی.

نئی صلاحیتیں آپ کو مختلف کام کے بوجھ میں زیادہ لچکدار طریقے سے کلسٹر آپریشنز کرنے کی اجازت دیتی ہیں۔ اس کے علاوہ، پروگرامرز براہ راست پروڈکشن میں ایپلی کیشنز کو تعینات کرتے وقت زیادہ کنٹرول سے لطف اندوز ہوتے ہیں۔

کمیونٹی

Kubernetes کی مقبولیت کا ایک اور بڑا پہلو اس کی کمیونٹی کی طاقت ہے۔ 2015 میں، ورژن 1.0 تک پہنچنے پر، Kubernetes کو سپانسر کیا گیا۔ کلاؤڈ آبائی کمپیوٹنگ فاؤنڈیشن.

مختلف کمیونٹیز بھی ہیں۔ SIG (خصوصی دلچسپی کے گروپ) نے پروجیکٹ کے تیار ہونے کے ساتھ ہی کبرنیٹس کے مختلف شعبوں پر کام کرنے پر توجہ دی۔ یہ گروپس مسلسل نئی خصوصیات شامل کر رہے ہیں، جس سے Kubernetes کے ساتھ کام کرنا زیادہ آسان اور آسان ہے۔

Cloud Native Foundation CloudNativeCon/KubeCon کی میزبانی بھی کرتا ہے، جو لکھنے کے وقت، دنیا کی سب سے بڑی اوپن سورس کانفرنس ہے۔ عام طور پر سال میں تین بار منعقد کیا جاتا ہے، یہ ہزاروں پیشہ ور افراد کو اکٹھا کرتا ہے جو Kubernetes اور اس کے ماحولیاتی نظام کو بہتر بنانے کے ساتھ ساتھ ہر تین ماہ بعد ظاہر ہونے والی نئی خصوصیات سیکھنا چاہتے ہیں۔

مزید برآں، کلاؤڈ مقامی فاؤنڈیشن کے پاس ہے۔ تکنیکی نگرانی کمیٹی، جو SIGs کے ساتھ مل کر نئے اور موجودہ کا جائزہ لیتا ہے۔ .ы کلاؤڈ ماحولیاتی نظام پر مرکوز فنڈز۔ ان میں سے زیادہ تر پروجیکٹ کبرنیٹس کی طاقت کو بہتر بنانے میں مدد کرتے ہیں۔

آخر میں، میں سمجھتا ہوں کہ Kubernetes اتنی کامیاب نہیں ہو گی جیسا کہ پوری کمیونٹی کی شعوری کوششوں کے بغیر ہوتا ہے، جہاں لوگ ایک دوسرے کے ساتھ جڑے رہتے ہیں لیکن ساتھ ہی ساتھ نئے آنے والوں کو بھی خوش آمدید کہتے ہیں۔

مستقبل

ایک اہم چیلنج جس سے ڈویلپرز کو مستقبل میں نمٹنا پڑے گا وہ کوڈ کی تفصیلات پر توجہ مرکوز کرنے کی صلاحیت ہے، نہ کہ اس انفراسٹرکچر پر جس میں یہ چلتا ہے۔ یہ ان رجحانات کو پورا کرتا ہے۔ سرور کے بغیر تعمیراتی نمونہ, جو آج سرکردہ میں سے ایک ہے۔ جدید فریم ورک پہلے سے موجود ہیں، جیسے آبائی и اوپن فاس، جو ڈویلپر سے بنیادی ڈھانچے کو خلاصہ کرنے کے لئے Kubernetes کا استعمال کرتے ہیں۔

اس مضمون میں، ہم نے صرف کوبرنیٹس کی موجودہ حالت کی سطح کو کھرچ دیا ہے — درحقیقت، یہ صرف برفانی تودے کا سرہ ہے۔ Kubernetes کے صارفین کے پاس بہت سے دوسرے وسائل، صلاحیتیں اور کنفیگریشنز ہیں۔

ماخذ: www.habr.com