کوبرنیٹس کے آپریٹرز: اسٹیٹفول ایپلی کیشنز کو کیسے چلایا جائے۔

Kubernetes میں ریاستی ایپلی کیشنز کے ساتھ مسئلہ

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

سیدھے الفاظ میں، کنٹینرز کے جھرمٹ میں PHP/Ruby/Python میں بیک اینڈ کی مزید پانچ کاپیاں لانچ کرنے کے لیے، آپ کو صرف 5 بار ایک نیا سرور ترتیب دینے اور ذرائع کو کاپی کرنے کی ضرورت ہے۔ چونکہ سورس کوڈ اور init اسکرپٹ دونوں تصویر میں ہیں، اس لیے اسٹیٹ لیس ایپلی کیشن کو اسکیل کرنا مکمل طور پر ابتدائی ہو جاتا ہے۔ جیسا کہ کنٹینرز اور مائیکرو سروس فن تعمیر کے پرستار اچھی طرح جانتے ہیں، مشکل اس سے شروع ہوتی ہے۔ ریاستی ایپس، یعنی ڈیٹا کی استقامت کے ساتھ جیسے ڈیٹا بیس اور کیچز (MySQL، PostgreSQL، Redis، ElasticSearch، Cassandra...)۔ یہ دونوں سافٹ ویئر پر لاگو ہوتا ہے جو آزادانہ طور پر کورم کلسٹر (مثال کے طور پر، Percona XtraDB اور Cassandra) کو لاگو کرتا ہے، اور ایسے سافٹ ویئر پر ہوتا ہے جس کے لیے علیحدہ انتظامی افادیت کی ضرورت ہوتی ہے (جیسے Redis, MySQL, PostgreSQL...)۔

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

CoreOS آپریٹرز

آپریشنل علم "پروگرام" کرنے کے لئے، گزشتہ سال کے آخر میں CoreOS پروجیکٹ متعارف کرایا Kubernetes پلیٹ فارم کے لیے "سافٹ ویئر کی ایک نئی کلاس" - آپریٹرز (انگریزی "آپریشن" سے، یعنی "آپریشن")۔

آپریٹرز Kubernetes کی بنیادی صلاحیتوں کا استعمال اور توسیع کرتے ہیں (بشمول۔ اسٹیٹفول سیٹس، نیچے فرق دیکھیں) DevOps ماہرین کو ایپلیکیشن کوڈ میں آپریشنل علم شامل کرنے کی اجازت دیں۔

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

آپریٹرز کیسے کام کرتے ہیں۔

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

یہ اس سے کیسے مختلف ہے۔ اسٹیٹفول سیٹس, ایسی ایپلی کیشنز کے لیے ڈیزائن کیا گیا ہے جن کے لیے کلسٹر کو اسٹیٹفول وسائل جیسے ڈیٹا اسٹوریج یا سٹیٹک آئی پی فراہم کرنے کی ضرورت ہوتی ہے؟ ایسی ایپلی کیشنز کے لیے آپریٹرز استعمال کر سکتے ہیں۔ اسٹیٹفول سیٹس (اس کے بجائے) ریپلی سیٹس) ایک بنیاد کے طور پر، پیشکش اضافی آٹومیشن: کریش ہونے کی صورت میں ضروری کارروائیاں کریں، بیک اپ بنائیں، کنفیگریشن کو اپ ڈیٹ کریں وغیرہ۔

اس طرح، یہ سب کیسے کام کرتا ہے؟ آپریٹر ایک مینیجر ڈیمون ہے جو:

1. Kubernetes میں ایونٹ API کو سبسکرائب کرتا ہے۔
2. اس سے سسٹم کے بارے میں ڈیٹا حاصل کرتا ہے (اس کے بارے میں ریپلی سیٹس, pods کے, سروسز اور اسی طرح.)؛
3. کے بارے میں ڈیٹا حاصل کرتا ہے۔ فریق ثالث کے وسائل (ذیل میں مثالیں دیکھیں)؛
4. ظاہری شکل / تبدیلی پر رد عمل فریق ثالث کے وسائل (مثال کے طور پر، سائز تبدیل کرنا، ورژن تبدیل کرنا، وغیرہ)؛
5. نظام کی حالت میں تبدیلیوں پر ردعمل ظاہر کرتا ہے (اس کے بارے میں ریپلی سیٹس, pods کے, سروسز اور اسی طرح.)؛
6. سب سے اہم:
   1. Kubernetes API کو اپنی ضرورت کی ہر چیز بنانے کے لیے کال کرتا ہے (دوبارہ، اس کا اپنا ریپلی سیٹس, pods کے, سروسز…)،
   2. کچھ جادو کرتا ہے (آسان بنانے کے لیے، آپ سوچ سکتے ہیں کہ آپریٹر خود پوڈ میں جاتا ہے اور کمانڈز کو کال کرتا ہے، مثال کے طور پر، کسی کلسٹر میں شامل ہونا یا ورژن کو اپ ڈیٹ کرتے وقت ڈیٹا فارمیٹ کو اپ گریڈ کرنا)۔

درحقیقت، جیسا کہ تصویر سے دیکھا جا سکتا ہے، ایک علیحدہ ایپلی کیشن کوبرنیٹس (ایک باقاعدہ تعیناتی с ریپلیکا سیٹ)، جسے آپریٹر کہا جاتا ہے۔ یہ ایک عام پھلی میں رہتا ہے (عام طور پر صرف ایک) اور، ایک اصول کے طور پر، صرف اس کے لیے ذمہ دار ہے۔ نیس اسپیس. یہ آپریٹر ایپلیکیشن اپنے API کو لاگو کرتی ہے - اگرچہ براہ راست نہیں، لیکن اس کے ذریعے فریق ثالث کے وسائل Kubernetes میں

اس طرح، ہم میں پیدا کرنے کے بعد نیس اسپیس آپریٹر، ہم اس میں شامل کر سکتے ہیں۔ فریق ثالث کے وسائل.

وغیرہ کی مثال (تفصیلات کے لیے نیچے ملاحظہ کریں):

apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
  name: example-etcd-cluster
spec:
  size: 3
  version: 3.1.0

Elasticsearch کی مثال:

apiVersion: enterprises.upmc.com/v1
kind: ElasticsearchCluster
metadata:
  name: example-es-cluster
spec:
  client-node-replicas: 3
  master-node-replicas: 2
  data-node-replicas: 3
  zones:
  - us-east-1c
  - us-east-1d
  - us-east-1e
  data-volume-size: 10Gi
  java-options: "-Xms1024m -Xmx1024m"
  snapshot:
    scheduler-enabled: true
    bucket-name: elasticsnapshots99
    cron-schedule: "@every 2m"
  storage:
    type: gp2
    storage-class-provisioner: kubernetes.io/aws-ebs

آپریٹرز کے لیے تقاضے

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

1. تنصیب ایک سنگل کے ذریعے کی جانی چاہیے۔ تعیناتی: kubectl تخلیق -f SOME_OPERATOR_URL/deployment.yaml - اور اضافی اقدامات کی ضرورت نہیں ہے۔
2. Kubernetes میں آپریٹر انسٹال کرتے وقت، ایک نئی تھرڈ پارٹی قسم کی تخلیق ہونی چاہیے۔ (تھرڈ پارٹی ریسورس). ایپلیکیشن انسٹینس (کلسٹر انسٹینس) کو شروع کرنے اور ان کا مزید انتظام کرنے کے لیے (ورژن کو اپ ڈیٹ کرنا، سائز تبدیل کرنا وغیرہ)، صارف اس قسم کا استعمال کرے گا۔
3. جب بھی ممکن ہو، آپ کو Kubernetes میں بنائے گئے پرائمیٹوز کا استعمال کرنا چاہیے، جیسے سروسز и ریپلی سیٹساچھی طرح سے تجربہ شدہ اور قابل فہم کوڈ استعمال کرنے کے لیے۔
4. آپریٹرز کی پسماندہ مطابقت اور صارف کے تخلیق کردہ وسائل کے پرانے ورژن کے لیے تعاون کی ضرورت ہے۔
5. اگر آپریٹر کو ہٹا دیا جاتا ہے، تو ایپلیکیشن کو بغیر کسی تبدیلی کے کام کرنا جاری رکھنا چاہیے۔
6. صارفین کو مطلوبہ ایپلیکیشن ورژن کی وضاحت کرنے اور ایپلیکیشن ورژن کی اپ ڈیٹس کو آرکیسٹریٹ کرنے کے قابل ہونا چاہیے۔ سافٹ ویئر اپ ڈیٹس کی کمی آپریشنل اور سیکیورٹی کے مسائل کا ایک عام ذریعہ ہے، لہذا آپریٹرز کو اس معاملے میں صارفین کی مدد کرنی چاہیے۔
7. آپریٹرز کو Chaos Monkey جیسے ٹول سے ٹیسٹ کیا جانا چاہیے، جو پوڈز، کنفیگریشنز اور نیٹ ورک میں ممکنہ ناکامیوں کی نشاندہی کرتا ہے۔

etcd آپریٹر

آپریٹر کے نفاذ کی مثال - etcd آپریٹر، تیار اس تصور کے اعلان کے دن۔ ای سی ڈی کلسٹر کنفیگریشن کورم برقرار رکھنے کی ضرورت، کلسٹر ممبرشپ کو دوبارہ ترتیب دینے، بیک اپ بنانے وغیرہ کی ضرورت کی وجہ سے پیچیدہ ہو سکتی ہے۔ مثال کے طور پر، ایک etcd کلسٹر کو دستی طور پر اسکیل کرنے کا مطلب یہ ہے کہ آپ کو ایک نئے کلسٹر ممبر کے لیے DNS نام بنانے، ایک نئی etcd ہستی شروع کرنے، اور کلسٹر کو نئے ممبر کے بارے میں الرٹ کرنے کی ضرورت ہے (etcdctl ممبر شامل کریں۔)۔ آپریٹر کے معاملے میں، صارف کو صرف کلسٹر کا سائز تبدیل کرنے کی ضرورت ہوگی - باقی سب کچھ خود بخود ہو جائے گا۔

اور چونکہ etcd بھی CoreOS میں بنایا گیا تھا، اس لیے اس کے آپریٹر کو پہلے ظاہر ہونا کافی منطقی تھا۔ وہ کیسے کام کرتا ہے؟ آپریٹر منطق وغیرہ تین اجزاء کی طرف سے مقرر کیا جاتا ہے:

1. مشاہدہ. آپریٹر Kubernetes API کا استعمال کرتے ہوئے کلسٹر کی حالت کی نگرانی کرتا ہے۔
2. تجزیہ۔ موجودہ حیثیت اور مطلوبہ کے درمیان فرق تلاش کرتا ہے (صارف کی ترتیب کے ذریعہ بیان کیا گیا ہے)۔
3. عمل. etcd اور/یا Kubernetes سروس APIs کا استعمال کرتے ہوئے پائے جانے والے اختلافات کو حل کرتا ہے۔

اس منطق کو لاگو کرنے کے لیے، آپریٹر میں فنکشنز تیار کیے گئے ہیں۔ بنائیں/تباہ کریں۔ (etcd کلسٹر ممبرز بنانا اور ڈیلیٹ کرنا) اور نیا سائز کریں (کلسٹر ممبران کی تعداد میں تبدیلی)۔ Netflix سے Chaos Monkey کی مشابہت میں بنائی گئی یوٹیلیٹی کا استعمال کرتے ہوئے اس کے آپریشن کی درستگی کی جانچ کی گئی۔ تصادفی طور پر etcd pods کو مارنا۔

etcd کے مکمل آپریشن کے لیے، آپریٹر اضافی خصوصیات فراہم کرتا ہے: بیک اپ (بیک اپ کاپیاں بنانے کے لیے صارفین کے لیے خودکار اور پوشیدہ - کنفیگریشن میں یہ طے کرنے کے لیے کافی ہے کہ انھیں کتنی بار بنانا ہے اور کتنی ذخیرہ کرنا ہے - اور اس کے بعد ان سے ڈیٹا کی بحالی) اور اپ ڈیٹ کریں (ڈاؤن ٹائم کے بغیر etcd تنصیبات کو اپ ڈیٹ کرنا)۔

آپریٹر کے ساتھ کام کرنا کیسا لگتا ہے؟

$ kubectl create -f https://coreos.com/operators/etcd/latest/deployment.yaml
$ kubectl create -f https://coreos.com/operators/etcd/latest/example-etcd-cluster.yaml
$ kubectl get pods
NAME                             READY     STATUS    RESTARTS   AGE
etcd-cluster-0000                1/1       Running   0          23s
etcd-cluster-0001                1/1       Running   0          16s
etcd-cluster-0002                1/1       Running   0          8s
etcd-cluster-backup-tool-rhygq   1/1       Running   0          18s

etcd آپریٹر کی موجودہ حیثیت ایک بیٹا ورژن ہے، جس کو چلانے کے لیے Kubernetes 1.5.3+ اور etcd 3.0+ کی ضرورت ہوتی ہے۔ ماخذ کوڈ اور دستاویزات (استعمال کے لیے ہدایات سمیت) پر دستیاب ہیں۔ GitHub کے.

CoreOS سے ایک اور مثال کے نفاذ کو بنایا گیا ہے۔ پرومیتھیس آپریٹر، لیکن یہ اب بھی الفا ورژن میں ہے (تمام منصوبہ بند خصوصیات کو نافذ نہیں کیا گیا ہے)۔

حیثیت اور امکانات

Kubernetes آپریٹرز کے اعلان کو 5 ماہ گزر چکے ہیں۔ ابھی بھی سرکاری CoreOS ذخیرے میں صرف دو نفاذ دستیاب ہیں (etcd اور Prometheus کے لیے)۔ دونوں ابھی تک اپنے مستحکم ورژن تک نہیں پہنچے ہیں، لیکن روزانہ کی بنیاد پر کمٹ کا مشاہدہ کیا جاتا ہے۔

ڈویلپرز "ایک ایسے مستقبل کا تصور کرتے ہیں جس میں صارفین پوسٹگریس آپریٹرز، کیسینڈرا آپریٹرز یا ریڈیس آپریٹرز کو اپنے Kubernetes کلسٹرز پر انسٹال کرتے ہیں اور ان ایپلی کیشنز کے توسیع پذیر اداروں کے ساتھ اتنی آسانی سے کام کرتے ہیں جتنا کہ آج کل اسٹیٹ لیس ویب ایپلیکیشنز کی نقلیں تعینات کرنا ہے۔" پہلا تھرڈ پارٹی ڈویلپرز کے آپریٹرز واقعی ظاہر ہونا شروع ہوا:

• لچکدار تلاش آپریٹر UPMC انٹرپرائزز سے؛
• PostgreSQL آپریٹر کرنچی ڈیٹا سے (مارچ 2017 کے آخر میں اعلان کیا گیا)؛
• روک آپریٹر Ceph پر مبنی تقسیم شدہ ڈیٹا اسٹوریج سسٹم کے مصنفین سے (Rook الفا کی حیثیت میں ہے)؛
• اوپن اسٹیک آپریٹرز SAP CCloud سے۔

سب سے بڑی یورپی فری سافٹ ویئر کانفرنس FOSDEM میں، جو فروری 2017 میں برسلز میں ہوئی، CoreOS سے جوش ووڈ نے آپریٹرز کا اعلان کیا۔ رپورٹ (ایک ویڈیو لنک پر دستیاب ہے!)، جو وسیع اوپن سورس کمیونٹی میں اس تصور کی مقبولیت میں اضافے میں معاون ثابت ہوگی۔

PS مضمون میں آپ کی دلچسپی کا شکریہ! ہمارے مرکز کو سبسکرائب کریں۔، تاکہ DevOps اور GNU/Linux سسٹم ایڈمنسٹریشن پر نئے مواد اور ترکیبوں سے محروم نہ ہوں - ہم انہیں باقاعدگی سے شائع کریں گے!

ماخذ: www.habr.com