Kubernetes 101، بخش سوم، کنترل‌کننده‌ها و خوددرمانی

قسمت دوم این مجموعه توضیح داده شد Pods چگونه کار می کند در حالی که یک Pod ساخته می شود که دارای دو کانتینر است که با استفاده از FIFO و یک حجم مشترک با یکدیگر ارتباط برقرار می کنند.

در این پست با این موضوع آشنا خواهیم شد سیستم های خود ترمیمی و آنچه که ما می توانیم با استفاده از مدیریت Pod بدست آوریم منابع حجم کار Kubernetes بنابراین آنها می توانند Pods را از طرف ما مدیریت کنند.

🚂 حوادث رخ خواهد داد

فرض کنید یک تک داریم سالم گره و چند پاد در حال اجرا در آن. اگر گره با a مواجه شود چه می شود شکست سخت افزاری حیاتی، ساختنش ناسالم? یاد آوردن: یک گره Kubernetes توسط یک ماشین مجازی نشان داده می شود.

از آنجا که چرخه زندگی دارندغلاف در یک ناسالم گره خواهد شد شروع به شکست.

⬇️ توقف برنامه

یک گره جدید مورد نیاز است. اما تامین سخت افزار یک است هزینه بر عمل، طول می کشد.

در همین حال، پاد شکست خورده است در گره ناسالم و برنامه در رنج است خرابی.

یک بار گره جدید پیوسته و آماده پذیرش است Pods جدید، ما می توانیم شروع کنیم تمام غلاف ها به صورت دستی استفاده كردن kubectl به عنوان مثال در گره تازه سالم:

$ kubectl apply -f ./pod.yml

تا زمانی که غلاف باشد آماده و در حال اجرا، برنامه باقی می ماند خراب، مثلا:

مدیریت غلاف مستقیم کارآمد نیست، نمی توان گفت که برنامه ما با چندین بار از کار افتادن مواجه می شود، کار دشواری است.

ما باید سیستمی بسازیم که توانایی آن را داشته باشد تشخیص شکست و همچنین راه اندازی مجدد اجزاء یا برنامه های کاربردی بطور خودکار بدون دخالت انسان

ما به یک سیستم خود درمانی نیاز داریم.

🤖 خود درمانی و رباتیک

ساختن یک سیستم خود درمانی برای مشاغل بسیار مهم است. هر زمان که زیرساخت ما دچار اختلال، شبکه یا خرابی سخت افزاری شود، سیستم باید بتواند “خود را درمان کند”.

اتوماسیون کلیدی است. و یک راه حل بالقوه برای خوددرمانی از آن می آید رباتیک.

در رباتیک، ما معمولا a ایجاد می کنیم کنترل کننده که یک می شود وضعیت مطلوب و با استفاده از نوعی حلقه کنترل، به طور مداوم بررسی می کند که آیا وضعیت فعلی با وضعیت مطلوب مطابقت دارد، تلاش برای آمدن تا حد امکان نزدیک تر.

آ ترموستات دقیقاً با استفاده از چنین چیزی کار می کند الگوی کنترلر: به طور مداوم بررسی می کند که آیا دمای فعلی با دمای مورد نظر مطابقت دارد یا خیر بیا نزدیکتر. هنگامی که یک مسابقه بدست می آید، کنترل کننده تجهیزات را خاموش می کند و این روند تکرار می شود دوباره و دوباره.

خوشبختانه، Kubernetes به ارمغان می آورد الگوی کنترلر که مشکل ما را حل می کند تا نیازی به مدیریت مستقیم Pods نداشته باشیم.

ما در مورد کنترلرهای Kubernetes صحبت می کنیم.

کنترل کننده ها

کنترلرهای Kubernetes هستند حلقه های کنترل که وضعیت خوشه را تماشا می کنند، سپس اقداماتی را انجام می دهند با حالت مورد نظر مطابقت داشته باشد تا حد امکان.

اما چگونه از آن استفاده کنیم کنترل کننده ها? Kubernetes چندین منبع بار کاری فراهم می کند تا بتوانیم به آنها اعتماد کنیم Pods را از طرف ما مدیریت کنید.

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

ReplicaSet

با استفاده از یک کنترلر ReplicaSet، می توانیم تعدادی Pod یکسان را مشخص کنیم.

### The kind of the Kubernetes object
kind: ReplicaSet
apiVersion: apps/v1
metadata:
  name: nginx
spec:
  ### The number of replicas of nginx Pod
  ### The controller will manage the Pods on our behalf
  ### Anytime a Pod goes down, the controller will restart a new one to guarantee that at least 2 nginx Pods are running
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx

پس از اعمال فایل YAML، باید نمایشی از a داشته باشیم replicaset موضوع به شرح زیر است:

$ kubectl get replicasets
NAME    DESIRED   CURRENT   READY   AGE
nginx   2         2         2       13m

همچنین، چک کردن Pods:

$ kubectl get pods
NAME          READY   STATUS    RESTARTS   AGE
nginx-r5kmn   1/1     Running   0          15m
nginx-k87fz   1/1     Running   0          15m

توجه داشته باشید که هر Pod یک عدد دارد شناسه تصادفی در خوشه به عنوان پسوند <podLabelMatcher>-<uniqueID>.

علاوه بر این، می توانیم ReplicaSet را در یک تصویر توصیف کنیم:

در تصویر بالا، توجه به این نکته مهم است که ممکن است کنترل کننده تصمیم به حفظ آن بگیرد هر پاد در یک گره متفاوت. این دقیقا همان انعطاف پذیری و قابلیت خوددرمانی است که ما می خواهیم!

هر زمان که یک Node دریافت شود ناسالم، ما هنوز یک را نگه می داریم گره سالم، بنابراین برنامه ما خرابی را به راحتی تحمل نمی کند.

حذف یک Pod از ReplicaSet

در صورتی که یک Pod را که توسط ReplicaSet ایجاد شده است حذف کنیم، کنترلر a را شروع می کند جدید به صورت خودکار:

$ kubectl delete pod nginx-r5kmn
pod nginx-r5kmn deleted

بررسی مجدد Pods:

$ kubectl get pods
NAME          READY   STATUS    RESTARTS   AGE
nginx-k87fz   1/1     Running   0          29m

### The new Pod
nginx-mr2rd   1/1     Running   0          28s

حذف ReplicaSet

اما در صورتی که بخواهیم تمام Pods یک ReplicaSet را حذف کنیم، باید آن را حذف کنیم replicaset بجای:

$ kubectl delete replicaset nginx
replicaset.apps "nginx" deleted

و غلاف ها بالاخره از بین رفتند:

$ kubectl get pods
No resources found in default namespace.

بسته بندی

در این پست دیدیم که چگونه خرابی های شبکه یا سخت افزار می تواند بر برنامه ما تأثیر بگذارد، از این رو اهمیت سیستم خود درمانی.

علاوه بر آن، ما در مورد آن یاد گرفتیم کنترلرهای Kubernetes و چگونه آنها حل مشکل خود درمانی، با معرفی یکی از مهمترین منابع حجم کار در Kubernetes: ReplicaSet.

پست های بعدی همچنان بر روی آنها تمرکز خواهند کرد منابع حجم کار، به طور دقیق تر در مورد نحوه عملکرد ما استقرارهای عرضه، Pods حالت دار، Pods تک گره و Pods را تعریف کنید که یک کار را اجرا می کنند و سپس متوقف می شوند (Jobs).

به سلامتی!