📄 آشنایی با سرویس

کلاستر کوبرنتیز

در کوبرنتیز ابری، کلاستر مجموعه‌ای از نودها (سرورها) است که با هم برای اجرای اپلیکیشن‌ها همکاری می‌کنند. هر کلاستر شامل سه ماشین کنترلگر (control-plane) برای مدیریت و چندین نود کارگر (worker) برای اجرای پادها است.

نودپول کوبرنتیز (NodePool)

در کوبرنتیز ابری (Cloud Kubernetes)، به یک گروه از ماشین‌های کارگر (Worker)، نودپول (NodePool) گفته می‌شود. کوبرنتیز ستون نیز با تبعیت از این استاندارد مفهوم SotoonNodePool را تعریف کرده که در ادامه به مزیت‌های اساسی آن اشاره می‌شود.

مدیریت ماشین‌های کارگر با ساختن نودپول

با استفاده از این دسته‌بندی، می‌توانید انواع مختلفی از ماشین‌ها را داشته باشید. مثلا فرض کنید در یک سناریو به کلاستری با ۶ ماشین کارگر احتیاج داریم. بعضی از این پادها نیازمند حافظه‌ی بالا (Memory) و بعضی از پادها نیازمند ظرفیت پردازشی بالا (CPU) هستند. در این سناریو می‌توان از طریق پنل کوبرنتیز ستون، یک نودپول از نوع High Memory با تعداد ۳ ماشین و یک نودپول از نوع Balanced با تعداد ۳ ماشین ساخت و با تنظیم Label مناسب روی ماشین‌ها (Node) و تنظیم Affinity مناسب روی پادهای مربوطه، پادهای پردازشی را روی ماشین‌های Balanced و پادهای با مصرف حافظه‌ی بالا را روی ماشین‌های High Memory اجرا کرد.

از سوی دیگر، این دسته‌بندی در فرایندهایی مانند به‌روزرسانی (Upgrade) قابلیت مدیریت بیشتری به شما می‌دهد به طوری که هر نودپول را می‌توانید در فرایندی جداگانه به‌روزرسانی کنید.

هشدار

در تنظیمات Affinity، هیچگاه روی نام Node ها اتکا نکنید چرا که این مشخصه توسط سرویس ابری تنظیم می‌شود و در فرایندهایی مثل به روزرسانی کلاستر تغییر می‌کند. توصیه می‌شود از Labelها برای این کار استفاده کنید. برچسب (Label)هایی که هنگام ساخت نودپول از طریق پنل می‌سازید، به طور خودکار به Worker Node ها اختصاص می‌یابد.

اتکاپذیری بیشتر با دسته‌بندی ماشین‌ها در نودپول‌ها

سرویس کوبرنتیز ابری ستون، برای فراهم‌آوری ماشین‌های کارگر، در لایه‌ی پایین‌تر از سرویس رایانش ابری ستون (Compute) استفاده می‌کند به طوری که به ازای هر Node یک Compute Instance ساخته می‌شود. این Instance ها در دیتاسنتر، روی ماشین‌های فیزیکی (Bare-metal Servers) به خودکار جاگذاری (Schedule) می‌شوند. هر SotoonNodePool برای جانمایی روی ماشین‌های فیزیکی،‌ یک کلید مشابهت (Affinity) دارد که باعث می‌شود تا حد امکان روی ماشین‌های فیزیکی متفاوتی جانمایی شود در نتیجه با ساختن نودپول‌های متعدد، ماشین‌های هر نودپول روی ماشین‌های فیزیکی متفاوتی جانمایی شده و از اتکاپذیری بیشتری بهرمند می‌شوند چرا که با این روش اطمینان حاصل می‌شود یک نودپول به یک ماشین فیزیکی وابسته نیست.

ستون برای انتشار هر نسخه‌ی کوبرنتیز همه‌ی آزمون‌های سازگاری (Conformance Tests) استاندارد کوبرنتیز مانند Sonobuoy را اجرا می‌کند و از کارکرد درست تمامی سرویس‌های استاندارد کوبرنتیز مانند Deployment، Statefulset و … اطمینان حاصل می‌کند. در ادامه‌ی این مستند، به چندی از این مولفه‌های کوبرنتیز می‌پردازیم هر چند سرویس‌های پشتیبانی شده در کوبرنتیز ستون، به این موارد محدود نمی‌شود.

Statefulset

StatefulSet یک آبجکت از workload API است که برای مدیریت اپلیکیشن‌های Stateful استفاده می‌شود. StatefulSet استقرار (deployment) و مقیاس‌پذیری یک مجموعه از پادها را مدیریت می‌کند و نظم و منحصربه‌فرد بودن این پادها را تضمین می‌کند.

اگر می‌خواهید از ظرفیت استوریج برای ایجاد پایداری برای workload خود استفاده کنید می‌توانید از StatefulSet به‌عنوان بخشی از راه حل استفاده کنید.

استفاده از StatefulSet

StatefulSetها برای اپلیکیشن‌هایی که به یک یا چند مورد زیر نیاز دارند، ارزشمند هستند.

• شناسه‌های ثابت و منحصربه‌فرد شبکه.
• استوریج ثابت و پایدار.
• استقرار (deployment) و مقیاس‌پذیری منظم.
• به‌روزرسانی‌های سفارشی اتوماتیک و منظم

کامپوننت‌های StatefulSet

مثال زیر کامپوننت‌های StatefulSet را نمایش می‌دهد.

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx # has to match .spec.template.metadata.labels
  serviceName: "nginx"
  replicas: 3 # by default is 1
  template:
    metadata:
      labels:
        app: nginx # has to match .spec.selector.matchLabels
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "my-storage-class"
      resources:
        requests:
          storage: 1Gi

برای اطلاعات بیشتر در مورد کامپوننت‌های StatefulSet می‌توانید به این مستند مراجعه کنید.

Deployment

Deployment به‌روزرسانی‌های اعلام‌شده را برای Podها و ReplicaSetها فراهم می‌کند.

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

ایجاد یک Deployment

در زیر نمونه‌ای از Deployment آورده شده است. در این نمونه یک ReplicaSet برای سه پاد nginx ایجاد شده است:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

برای اطلاعات بیشتر در مورد کامپوننت‌های StatefulSet می‌توانید به این مستند مراجعه کنید.

Jobs

یک Job یک یا چند پاد ایجاد می‌کند و اجرای موفق پادها را تا زمانی که تعداد مشخصی از آنها با موفقیت خاتمه یابند، ادامه خواهد داد. با تکمیل موفقیت‌آمیز Podها، Job آن‌ها را دنبال می‌کند. با حذف یک Job، پادهای ایجاد شده پاک‌سازی می‌شوند. تعلیق یک Job، پادهای فعال آن را تا زمانی که Job دوباره از سر گرفته شود، حذف می‌کند.

می‌توانید از Job برای اجرای چند پاد به‌صورت موازی استفاده کنید.

اجرای یک Job به‌عنوان نمونه

در ادامه یک مثال از پیکربندی Job آورده شده است. این نمونه، عدد π را با تقریب ۲۰۰۰ محاسبه و چاپ می‌کند. این کار حدود ۱۰ ثانیه طول می‌کشد تا کامل شود.

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

می‌توانید این مثال را با دستور زیر اجرا کنید:

kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml

خروجی مانند زیر خواهد بود:

job.batch/pi created

می‌توانید وضعیت Job را با Kubectl بررسی کنید:

kubectl describe jobs/pi

خروجی مانند زیر خواهد بود:

Name:           pi
Namespace:      default
Selector:       controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c
Labels:         controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c
                job-name=pi
Annotations:    kubectl.kubernetes.io/last-applied-configuration:
                  {"apiVersion":"batch/v1","kind":"Job","metadata":{"annotations":{},"name":"pi","namespace":"default"},"spec":{"backoffLimit":4,"template":...
Parallelism:    1
Completions:    1
Start Time:     Mon, 02 Dec 2019 15:20:11 +0200
Completed At:   Mon, 02 Dec 2019 15:21:16 +0200
Duration:       65s
Pods Statuses:  0 Running / 1 Succeeded / 0 Failed
Pod Template:
  Labels:  controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c
           job-name=pi
  Containers:
   pi:
    Image:      perl
    Port:       <none>
    Host Port:  <none>
    Command:
      perl
      -Mbignum=bpi
      -wle
      print bpi(2000)
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Events:
  Type    Reason            Age   From            Message
  ----    ------            ----  ----            -------
  Normal  SuccessfulCreate  14m   job-controller  Created pod: pi-5rwd7

برای اینکه پادهای کامل یک Job را ببینید می‌توانید از kubectl get pods استفاده کنید.

برای لیست کردن همه‌ی پادهای مرتبط با یک Job در یک ماشین می‌توانید، از دستوری مانند دستور زیر استفاده کنید.

pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}')
echo $pods

برای اطلاعات بیشتر می‌توانید در مورد Job می‌توانید به این مستند مراجعه کنید.