🥇اپراتورهای Kubernetes: نحوه اجرای برنامه های حالت دار

مشکل برنامه های حالت دار در Kubernetes

پیکربندی، راه‌اندازی و مقیاس‌بندی بیشتر برنامه‌ها و سرویس‌ها در مواردی که به‌عنوان مواردی که به‌عنوان «بدون وضعیت» طبقه‌بندی می‌شوند، آسان است. بدون ذخیره داده ها اجرای چنین خدماتی در Kubernetes با استفاده از APIهای استاندارد آن راحت است، زیرا همه چیز "خارج از جعبه" اتفاق می افتد: طبق پیکربندی های استاندارد، بدون هیچ گونه خاص یا جادو.

به زبان ساده، برای راه اندازی پنج نسخه دیگر از باطن در PHP/Ruby/Python در دسته ای از کانتینرها، فقط باید 5 بار یک سرور جدید راه اندازی کنید و منابع را کپی کنید. از آنجایی که هم کد منبع و هم اسکریپت init در تصویر هستند، مقیاس‌بندی یک برنامه بدون حالت کاملاً ابتدایی می‌شود. همانطور که طرفداران کانتینرها و معماری میکروسرویس به خوبی می دانند، دشواری از آنجا شروع می شود برنامه های دولتی، یعنی با ماندگاری داده‌ها مانند پایگاه‌های داده و حافظه پنهان (MySQL، PostgreSQL، Redis، ElasticSearch، Cassandra...). این هم برای نرم افزارهایی که به طور مستقل یک خوشه حد نصاب را پیاده سازی می کنند (به عنوان مثال Percona XtraDB و Cassandra) و هم برای نرم افزارهایی که به ابزارهای مدیریتی جداگانه نیاز دارند (مانند Redis، MySQL، PostgreSQL...) صدق می کند.

مشکلات به این دلیل پیش می‌آیند که کد منبع و راه‌اندازی سرویس دیگر کافی نیست - باید چند مرحله دیگر را انجام دهید. حداقل، داده ها را کپی کنید و/یا به خوشه بپیوندید. به طور دقیق‌تر، این سرویس‌ها نیاز به درک درستی از نحوه مقیاس‌بندی، به‌روزرسانی و پیکربندی مجدد آنها بدون از دست دادن داده یا عدم دسترسی موقت دارند. در نظر گرفتن این نیازها "دانش عملیاتی" نامیده می شود.

اپراتورهای CoreOS

به منظور "برنامه ریزی" دانش عملیاتی، اواخر سال گذشته پروژه CoreOS معرفی شده "یک کلاس جدید از نرم افزار" برای پلت فرم Kubernetes - اپراتورها (از انگلیسی "عملیات"، یعنی "عملیات").

اپراتورهایی که از قابلیت های اصلی Kubernetes استفاده می کنند و آن را گسترش می دهند (شامل StatefulSets، تفاوت را در زیر ببینید) به متخصصان DevOps اجازه دهید دانش عملیاتی را به کد برنامه اضافه کنند.

هدف اپراتور - یک API در اختیار کاربر قرار دهید که به شما امکان می‌دهد چندین موجودیت برنامه stateful را در یک خوشه Kubernetes مدیریت کنید، بدون اینکه به آنچه در زیر سرپوش وجود دارد فکر کنید (چه داده‌هایی و چه باید کرد، چه دستوراتی هنوز برای حفظ خوشه باید اجرا شوند. ). در واقع، اپراتور طراحی شده است تا کار با برنامه را تا حد امکان در کلاستر ساده کند، و اجرای وظایف عملیاتی را که قبلاً باید به صورت دستی حل می شد، خودکار می کند.

اپراتورها چگونه کار می کنند

ReplicaSets Kubernetes به شما امکان می دهد تعداد مورد نظر پادهای در حال اجرا را مشخص کنید و کنترلرها از حفظ تعداد آنها (با ایجاد و حذف پادها) اطمینان حاصل می کنند. یک اپراتور به روشی مشابه کار می کند و مجموعه ای از دانش عملیاتی را به یک منبع و کنترل کننده استاندارد Kubernetes اضافه می کند که به شما امکان می دهد اقدامات اضافی را برای پشتیبانی از تعداد مورد نیاز موجودیت های برنامه انجام دهید.

این با چه فرقی دارد StatefulSets، برای برنامه هایی طراحی شده است که به خوشه نیاز دارند تا منابع حالتی مانند ذخیره سازی داده ها یا IP های ثابت را در اختیار آنها قرار دهد؟ برای چنین برنامه هایی، اپراتورها می توانند استفاده کنند StatefulSets (بجای ReplicaSets) به عنوان مبنا، ارائه اتوماسیون اضافی: انجام اقدامات لازم در صورت خرابی، پشتیبان گیری، به روز رسانی تنظیمات و غیره.

بنابراین، این همه چگونه کار می کند؟ اپراتور یک دیمون مدیر است که:

مشترک API رویداد در Kubernetes.
اطلاعات مربوط به سیستم را از آن دریافت می کند (در مورد آن ReplicaSets, غلاف, خدمات و غیره.)؛
اطلاعاتی در مورد دریافت می کند منابع شخص ثالث (نمونه های زیر را ببینید)؛
به ظاهر/تغییر واکنش نشان می دهد منابع شخص ثالث (به عنوان مثال، برای تغییر اندازه، تغییر نسخه، و غیره)؛
به تغییرات در وضعیت سیستم واکنش نشان می دهد (در مورد آن ReplicaSets, غلاف, خدمات و غیره.)؛
مهمترین:
1. از Kubernetes API فرا می‌خواند تا هر چیزی را که نیاز دارد ایجاد کند (باز هم، خودش ReplicaSets, غلاف, خدمات) ،
2. برخی جادوها را انجام می دهد (برای ساده کردن، می توانید فکر کنید که اپراتور به خود پادها می رود و دستوراتی را فراخوانی می کند، به عنوان مثال، برای پیوستن به یک خوشه یا برای ارتقای قالب داده هنگام به روز رسانی یک نسخه).

در واقع، همانطور که از تصویر مشخص است، یک برنامه جداگانه به سادگی به Kubernetes اضافه شده است (یک برنامه معمولی گسترش с ReplicaSet) که اپراتور نامیده می شود. در یک غلاف معمولی (معمولاً فقط یک) زندگی می کند و به عنوان یک قاعده فقط مسئول آن است فضای نام. این برنامه اپراتور API خود را پیاده سازی می کند - البته نه به طور مستقیم، اما از طریق منابع شخص ثالث در Kubernetes

بنابراین، پس از ایجاد در فضای نام اپراتور، ما می توانیم به آن اضافه کنیم منابع شخص ثالث.

مثال برای etcd (برای جزئیات به زیر مراجعه کنید):

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 الگوهای اصلی بدست آمده توسط مهندسان در حین کار بر روی اپراتورها را فرموله کرد. علیرغم این واقعیت که همه اپراتورها فردی هستند (برای یک برنامه خاص با ویژگی ها و نیازهای خاص خود ایجاد شده اند)، ایجاد آنها باید بر اساس نوعی چارچوب باشد که الزامات زیر را تحمیل می کند:

نصب باید از طریق تک انجام شود گسترش: kubectl -f SOME_OPERATOR_URL/deployment.yaml را ایجاد کنید - و نیازی به اقدامات اضافی ندارند.
هنگام نصب یک اپراتور در Kubernetes، یک نوع شخص ثالث جدید باید ایجاد شود (ThirdPartyResource). برای راه اندازی نمونه های برنامه (نمونه های خوشه ای) و مدیریت بیشتر آنها (به روز رسانی نسخه ها، تغییر اندازه و غیره)، کاربر از این نوع استفاده می کند.
در صورت امکان، باید از ابتدایی های ساخته شده در Kubernetes استفاده کنید، مانند خدمات и ReplicaSetsبرای استفاده از کدهای تست شده و قابل فهم.
به سازگاری عقب مانده اپراتورها و پشتیبانی از نسخه های قدیمی منابع ساخته شده توسط کاربر نیاز دارد.
اگر اپراتور حذف شود، خود برنامه باید بدون تغییر به کار خود ادامه دهد.
کاربران باید بتوانند نسخه برنامه مورد نظر را تعریف کرده و به روز رسانی نسخه برنامه را هماهنگ کنند. عدم به روز رسانی نرم افزار منبع رایج مشکلات عملیاتی و امنیتی است، بنابراین اپراتورها باید در این مورد به کاربران کمک کنند.
اپراتورها باید با ابزاری مانند Chaos Monkey آزمایش شوند که خرابی های بالقوه را در پادها، پیکربندی ها و شبکه شناسایی می کند.

اپراتور etcd

مثال پیاده سازی اپراتور - اپراتور etcd، تهیه شده در روز اعلام این مفهوم. پیکربندی خوشه etcd به دلیل نیاز به حفظ حد نصاب، نیاز به پیکربندی مجدد عضویت در خوشه، ایجاد پشتیبان‌گیری و غیره می‌تواند پیچیده باشد. به عنوان مثال، مقیاس بندی دستی یک خوشه etcd به این معنی است که شما باید یک نام DNS برای یک عضو جدید خوشه ایجاد کنید، یک موجودیت etcd جدید راه اندازی کنید و به خوشه درباره عضو جدید هشدار دهید (عضو etcdctl اضافه کنید). در مورد اپراتور، کاربر فقط باید اندازه خوشه را تغییر دهد - همه چیز به طور خودکار اتفاق می افتد.

و از آنجایی که etcd در CoreOS نیز ایجاد شد، کاملاً منطقی بود که ابتدا اپراتور آن ظاهر شود. او چگونه کار می کند؟ منطق اپراتور و غیره توسط سه جزء تعیین می شود:

رعایت کنید. اپراتور با استفاده از Kubernetes API وضعیت خوشه را نظارت می کند.
تحلیل و بررسی. تفاوت بین وضعیت فعلی و مورد نظر (تعریف شده توسط پیکربندی کاربر) را پیدا می کند.
عمل. تفاوت های شناسایی شده را با استفاده از API های سرویس etcd و/یا Kubernetes حل می کند.

برای پیاده سازی این منطق، توابعی در Operator آماده شده است ایجاد / نابود کردن (ایجاد و حذف اعضای خوشه etcd) و تغییر اندازه (تغییر تعداد اعضای خوشه). صحت عملکرد آن با استفاده از ابزاری که شبیه Chaos Monkey از Netflix ایجاد شده بود بررسی شد، یعنی. کشتن غلاف etcd به طور تصادفی.

برای عملکرد کامل 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 ایجاد شده است - اپراتور پرومتئوس، اما هنوز در نسخه آلفا است (همه ویژگی های برنامه ریزی شده پیاده سازی نشده اند).

وضعیت و چشم انداز

5 ماه از معرفی اپراتورهای Kubernetes می گذرد. هنوز تنها دو پیاده سازی در مخزن رسمی CoreOS (برای etcd و Prometheus) موجود است. هر دو هنوز به نسخه پایدار خود نرسیده اند، اما تعهدات به صورت روزانه رعایت می شود.

توسعه‌دهندگان آینده‌ای را متصور می‌شوند که در آن کاربران Operators Postgres، Cassandra Operators یا Redis Operators را روی خوشه‌های Kubernetes خود نصب می‌کنند و با موجودیت‌های مقیاس‌پذیر این برنامه‌ها به آسانی کار می‌کنند، به همان راحتی که امروز استقرار کپی‌های برنامه‌های کاربردی وب بدون حالت است. اولین اپراتورها از توسعه دهندگان شخص ثالث واقعاً شروع به ظاهر شدن کرد:

اپراتور Elasticsearch از UPMC Enterprises؛
اپراتور PostgreSQL از داده های کرانچی (اعلام شده در اواخر مارس 2017)؛
اپراتور روک از نویسندگان یک سیستم ذخیره سازی داده توزیع شده بر اساس Ceph (روک در وضعیت آلفا قرار دارد).
اپراتورهای Openstack از SAP CCloud.

در بزرگترین کنفرانس نرم افزار آزاد اروپایی FOSDEM که در فوریه 2017 در بروکسل برگزار شد، جاش وود از CoreOS اپراتورها در گزارش (یک ویدیو در لینک موجود است!)، که باید به رشد محبوبیت این مفهوم در جامعه گسترده تر منبع باز کمک کند.

PS با تشکر از علاقه شما به مقاله! در مرکز ما مشترک شوید، برای اینکه مواد و دستور العمل های جدید را در DevOps و مدیریت سیستم گنو/لینوکس از دست ندهید - ما آنها را به طور مرتب منتشر خواهیم کرد!

منبع: www.habr.com

اپراتورهای Kubernetes: نحوه اجرای برنامه های حالت دار