🥇 اعتبار سنجی Kubernetes YAML در برابر بهترین شیوه ها و سیاست ها

توجه داشته باشید. ترجمه: با افزایش تعداد پیکربندی‌های YAML برای محیط‌های K8s، نیاز به تأیید خودکار آنها بیش از پیش ضروری می‌شود. نویسنده این بررسی نه تنها راه حل های موجود را برای این کار انتخاب کرده است، بلکه از Deployment به عنوان مثالی برای مشاهده نحوه عملکرد آنها استفاده کرده است. معلوم شد برای کسانی که به این موضوع علاقه مند هستند بسیار آموزنده است.

TL؛ DR: این مقاله شش ابزار ثابت را برای اعتبارسنجی و ارزیابی فایل‌های Kubernetes YAML در برابر بهترین شیوه‌ها و الزامات مقایسه می‌کند.

بارهای کاری Kubernetes معمولاً در قالب اسناد YAML تعریف می شوند. یکی از مشکلات YAML مشکل تعیین محدودیت ها یا روابط بین فایل های مانیفست است.

اگر لازم باشد مطمئن شویم که همه تصاویر مستقر شده در خوشه از یک رجیستری قابل اعتماد هستند، چه؟

چگونه می توانم از ارسال برنامه هایی که PodDisruptionBudgets ندارند به کلاستر جلوگیری کنم؟

ادغام تست استاتیک به شما امکان می دهد خطاها و نقض سیاست ها را در مرحله توسعه شناسایی کنید. این تضمین درست و ایمن بودن تعاریف منابع را افزایش می‌دهد و این احتمال را افزایش می‌دهد که حجم کاری تولید از بهترین شیوه‌ها پیروی کند.

اکوسیستم بازرسی فایل YAML ایستا Kubernetes را می توان به دسته های زیر تقسیم کرد:

اعتبار سنجی API. ابزارهای این دسته مانیفست YAML را در برابر الزامات سرور API Kubernetes بررسی می کنند.
آزمایش کننده های آماده. ابزارهای این دسته با تست های آماده برای امنیت، مطابقت با بهترین شیوه ها و غیره ارائه می شوند.
اعتبار سنجی سفارشی. نمایندگان این دسته به شما اجازه می دهند تا تست های سفارشی را به زبان های مختلف ایجاد کنید، به عنوان مثال، Rego و Javascript.

در این مقاله شش ابزار مختلف را شرح و مقایسه خواهیم کرد:

کوبوال;
امتیاز کوبه
config-lint;
مس؛
رقابت؛
قطبی

خوب، بیایید شروع کنیم!

بررسی استقرارها

قبل از شروع مقایسه ابزارها، اجازه دهید پس‌زمینه‌ای ایجاد کنیم تا آنها را آزمایش کنیم.

مانیفست زیر حاوی تعدادی خطا و عدم انطباق با بهترین شیوه ها است: چند تا از آنها را می توانید پیدا کنید؟

apiVersion: apps/v1
kind: Deployment
metadata:
  name: http-echo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: http-echo
  template:
    metadata:
      labels:
        app: http-echo
    spec:
      containers:
      - name: http-echo
        image: hashicorp/http-echo
        args: ["-text", "hello-world"]
        ports:
        - containerPort: 5678
---
apiVersion: v1
kind: Service
metadata:
  name: http-echo
spec:
  ports:
  - port: 5678
    protocol: TCP
    targetPort: 5678
  selector:
    app: http-echo

(base-valid.yaml)

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

مانیفست فوق base-valid.yaml و سایر مانیفست های این مقاله را می توان در اینجا یافت مخازن Git.

مانیفست یک برنامه وب را توصیف می کند که وظیفه اصلی آن پاسخ دادن با پیام "Hello World" به پورت 5678 است. می توان آن را با دستور زیر مستقر کرد:

kubectl apply -f hello-world.yaml

و بنابراین - کار را بررسی کنید:

kubectl port-forward svc/http-echo 8080:5678

حالا برو به http://localhost:8080 و تأیید کنید که برنامه کار می کند. اما آیا از بهترین شیوه ها پیروی می کند؟ بیایید بررسی کنیم.

1. کوبوال

در پایه کوبوال ایده این است که هر گونه تعامل با Kubernetes از طریق REST API آن رخ می دهد. به عبارت دیگر، شما می توانید از یک طرحواره API برای بررسی اینکه آیا YAML داده شده با آن مطابقت دارد یا خیر استفاده کنید. بیایید به یک مثال نگاه کنیم.

دستورالعمل نصب و راه اندازی kubeval در وب سایت پروژه موجود است.

در زمان نگارش مقاله اصلی، نسخه 0.15.0 موجود بود.

پس از نصب، اجازه دهید آن را در مانیفست بالا تغذیه کنیم:

$ kubeval base-valid.yaml
PASS - base-valid.yaml contains a valid Deployment (http-echo)
PASS - base-valid.yaml contains a valid Service (http-echo)

در صورت موفقیت آمیز بودن، kubeval با کد خروج 0 خارج می شود. می توانید آن را به صورت زیر بررسی کنید:

$ echo $?
0

بیایید اکنون کوبوال را با مانیفست متفاوت امتحان کنیم:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: http-echo
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: http-echo
    spec:
      containers:
      - name: http-echo
        image: hashicorp/http-echo
        args: ["-text", "hello-world"]
        ports:
        - containerPort: 5678
---
apiVersion: v1
kind: Service
metadata:
  name: http-echo
spec:
  ports:
  - port: 5678
    protocol: TCP
    targetPort: 5678
  selector:
    app: http-echo

(kubeval-invalid.yaml)

آیا می توانید مشکل را با چشم تشخیص دهید؟ راه اندازی کنیم:

$ kubeval kubeval-invalid.yaml
WARN - kubeval-invalid.yaml contains an invalid Deployment (http-echo) - selector: selector is required
PASS - kubeval-invalid.yaml contains a valid Service (http-echo)

# проверим код возврата
$ echo $?
1

منبع در حال تایید نیست.

استقرار با استفاده از نسخه API apps/v1، باید دارای انتخابگری باشد که با برچسب غلاف مطابقت داشته باشد. مانیفست بالا شامل انتخابگر نمی شود، بنابراین kubeval یک خطا را گزارش کرد و با یک کد غیر صفر خارج شد.

من تعجب می کنم که اگر انجام دهم چه اتفاقی می افتد kubectl apply -f با این مانیفست؟

خوب بیایید سعی کنیم:

$ kubectl apply -f kubeval-invalid.yaml
error: error validating "kubeval-invalid.yaml": error validating data: ValidationError(Deployment.spec):
missing required field "selector" in io.k8s.api.apps.v1.DeploymentSpec; if you choose to ignore these errors,
turn validation off with --validate=false

این دقیقا همان خطایی است که کوبوال درباره آن هشدار داده است. می توانید با اضافه کردن یک انتخابگر آن را برطرف کنید:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: http-echo
spec:
  replicas: 2
  selector:          # !!!
    matchLabels:     # !!!
      app: http-echo # !!!
  template:
    metadata:
      labels:
        app: http-echo
    spec:
      containers:
      - name: http-echo
        image: hashicorp/http-echo
        args: ["-text", "hello-world"]
        ports:
        - containerPort: 5678
---
apiVersion: v1
kind: Service
metadata:
  name: http-echo
spec:
  ports:
  - port: 5678
    protocol: TCP
    targetPort: 5678
  selector:
    app: http-echo

(base-valid.yaml)

مزیت ابزارهایی مانند kubeval این است که خطاهایی مانند این را می توان در اوایل چرخه استقرار کشف کرد.

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

به‌طور پیش‌فرض، kubeval منابع را در برابر آخرین طرح Kubernetes API بررسی می‌کند. با این حال، در بیشتر موارد ممکن است لازم باشد نسخه خاصی از Kubernetes را بررسی کنید. این را می توان با استفاده از پرچم انجام داد --kubernetes-version:

$ kubeval --kubernetes-version 1.16.1 base-valid.yaml

لطفا توجه داشته باشید که نسخه باید در قالب مشخص شود Major.Minor.Patch.

برای لیست نسخه هایی که تأیید برای آنها پشتیبانی می شود، لطفاً به آن مراجعه کنید طرحواره JSON در GitHub، که Kubeval از آن برای اعتبار سنجی استفاده می کند. اگر نیاز به اجرای آفلاین kubeval دارید، طرحواره ها را دانلود کنید و مکان محلی آنها را با استفاده از پرچم مشخص کنید --schema-location.

علاوه بر فایل های YAML فردی، kubeval می تواند با دایرکتوری ها و stdin نیز کار کند.

علاوه بر این، Kubeval به راحتی در خط لوله CI ادغام می شود. کسانی که مایل به اجرای آزمایش‌ها قبل از ارسال مانیفست به خوشه هستند، خوشحال خواهند شد که بدانند kubeval از سه فرمت خروجی پشتیبانی می‌کند:

متن ساده؛
JSON;
تست هر چیزی پروتکل (TAP).

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

یکی از اشکالات kubeval این است که در حال حاضر نمی تواند مطابقت با تعاریف منابع سفارشی (CRD) را بررسی کند. با این حال، پیکربندی kubeval امکان پذیر است آنها را نادیده بگیر.

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

مثلا با استفاده از تگ latest در یک ظرف از بهترین شیوه ها پیروی نمی کند. با این حال، kubeval این را یک خطا نمی داند و آن را گزارش نمی کند. یعنی تأیید چنین YAML بدون اخطار کامل می شود.

اما اگر بخواهید YAML را ارزیابی کنید و تخلفاتی مانند برچسب را شناسایی کنید، چه؟ latest? چگونه می توانم فایل YAML را در برابر بهترین شیوه ها بررسی کنم؟

2. امتیاز کوبه

امتیاز کوبه تجزیه و تحلیل YAML آشکار و ارزیابی آنها در برابر تست های داخلی. این تست ها بر اساس دستورالعمل های امنیتی و بهترین شیوه ها انتخاب می شوند، مانند:

اجرای ظرف نه به عنوان ریشه.
در دسترس بودن بررسی های سلامت غلاف.
تنظیم درخواست ها و محدودیت ها برای منابع.

بر اساس نتایج آزمایش، سه نتیجه داده می شود: OK, هشدار и بحرانی.

می توانید Kube-score را به صورت آنلاین امتحان کنید یا آن را به صورت محلی نصب کنید.

در زمان نوشتن مقاله اصلی، آخرین نسخه kube-score 1.7.0 بود.

بیایید آن را در مانیفست خود امتحان کنیم base-valid.yaml:

$ kube-score score base-valid.yaml

apps/v1/Deployment http-echo
[CRITICAL] Container Image Tag
  · http-echo -> Image with latest tag
      Using a fixed tag is recommended to avoid accidental upgrades
[CRITICAL] Pod NetworkPolicy
  · The pod does not have a matching network policy
      Create a NetworkPolicy that targets this pod
[CRITICAL] Pod Probes
  · Container is missing a readinessProbe
      A readinessProbe should be used to indicate when the service is ready to receive traffic.
      Without it, the Pod is risking to receive traffic before it has booted. It is also used during
      rollouts, and can prevent downtime if a new version of the application is failing.
      More information: https://github.com/zegl/kube-score/blob/master/README_PROBES.md
[CRITICAL] Container Security Context
  · http-echo -> Container has no configured security context
      Set securityContext to run the container in a more secure context.
[CRITICAL] Container Resources
  · http-echo -> CPU limit is not set
      Resource limits are recommended to avoid resource DDOS. Set resources.limits.cpu
  · http-echo -> Memory limit is not set
      Resource limits are recommended to avoid resource DDOS. Set resources.limits.memory
  · http-echo -> CPU request is not set
      Resource requests are recommended to make sure that the application can start and run without
      crashing. Set resources.requests.cpu
  · http-echo -> Memory request is not set
      Resource requests are recommended to make sure that the application can start and run without crashing.
      Set resources.requests.memory
[CRITICAL] Deployment has PodDisruptionBudget
  · No matching PodDisruptionBudget was found
      It is recommended to define a PodDisruptionBudget to avoid unexpected downtime during Kubernetes
      maintenance operations, such as when draining a node.
[WARNING] Deployment has host PodAntiAffinity
  · Deployment does not have a host podAntiAffinity set
      It is recommended to set a podAntiAffinity that stops multiple pods from a deployment from
      being scheduled on the same node. This increases availability in case the node becomes unavailable.

YAML تست‌های kubeval را پشت سر می‌گذارد، در حالی که نمره kube به نقص‌های زیر اشاره می‌کند:

بررسی های آمادگی پیکربندی نشده اند.
هیچ درخواست یا محدودیتی برای منابع و حافظه CPU وجود ندارد.
بودجه اختلال پاد مشخص نشده است.
هیچ قانون جدایی وجود ندارد (ضد قرابت) برای به حداکثر رساندن در دسترس بودن
ظرف به صورت ریشه اجرا می شود.

اینها همه نکات معتبری در مورد کاستی هایی هستند که باید برای کارآمدتر و قابل اعتمادتر کردن استقرار برطرف شوند.

تیم kube-score اطلاعات را به شکل قابل خواندن توسط انسان از جمله انواع نقض ها نمایش می دهد هشدار и بحرانی، که در طول توسعه کمک زیادی می کند.

کسانی که مایل به استفاده از این ابزار در خط لوله CI هستند می توانند خروجی فشرده تر را با استفاده از پرچم فعال کنند --output-format ci (در این مورد، آزمایشات با نتیجه نیز نمایش داده می شود OK):

$ kube-score score base-valid.yaml --output-format ci

[OK] http-echo apps/v1/Deployment
[OK] http-echo apps/v1/Deployment
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) CPU limit is not set
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) Memory limit is not set
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) CPU request is not set
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) Memory request is not set
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) Image with latest tag
[OK] http-echo apps/v1/Deployment
[CRITICAL] http-echo apps/v1/Deployment: The pod does not have a matching network policy
[CRITICAL] http-echo apps/v1/Deployment: Container is missing a readinessProbe
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) Container has no configured security context
[CRITICAL] http-echo apps/v1/Deployment: No matching PodDisruptionBudget was found
[WARNING] http-echo apps/v1/Deployment: Deployment does not have a host podAntiAffinity set
[OK] http-echo v1/Service
[OK] http-echo v1/Service
[OK] http-echo v1/Service
[OK] http-echo v1/Service

مشابه kubeval، kube-score یک کد خروج غیر صفر را زمانی که آزمایشی با شکست مواجه می شود، برمی گرداند. بحرانی. همچنین می توانید پردازش مشابه را برای هشدار.

علاوه بر این، بررسی منابع برای مطابقت با نسخه های مختلف API (مانند kubeval) امکان پذیر است. با این حال، این اطلاعات در خود امتیاز kube کدگذاری شده است: شما نمی توانید نسخه دیگری از Kubernetes را انتخاب کنید. اگر قصد دارید کلاستر خود را ارتقا دهید یا اگر چندین خوشه با نسخه های مختلف K8s دارید، این محدودیت می تواند مشکل بزرگی باشد.

لطفا توجه داشته باشید که در حال حاضر یک مسئله وجود دارد با پیشنهادی برای تحقق این فرصت.

اطلاعات بیشتر در مورد kube-score را می‌توانید در اینجا پیدا کنید سایت رسمی.

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

Kube-score قابل توسعه نیست: شما نمی توانید خط مشی هایی را به آن اضافه کنید یا آنها را تنظیم کنید.

اگر نیاز به نوشتن تست‌های سفارشی برای تأیید انطباق با خط‌مشی‌های شرکت دارید، می‌توانید از یکی از چهار ابزار زیر استفاده کنید: config-lint، copper، conftest یا polaris.

3.Config-lint

Config-lint ابزاری برای اعتبارسنجی YAML، JSON، Terraform، فایل‌های پیکربندی CSV و مانیفست‌های Kubernetes است.

می توانید با استفاده از آن نصب کنید دستورالعمل ها در وب سایت پروژه

نسخه فعلی تا زمان نگارش مقاله اصلی 1.5.0 است.

Config-lint تست‌های داخلی برای تایید مانیفست‌های Kubernetes ندارد.

برای انجام هر آزمایشی، باید قوانین مناسبی را ایجاد کنید. آنها در فایل های YAML به نام "قوانین" نوشته شده اند. (مجموعه قوانین)، و ساختار زیر را دارند:

version: 1
description: Rules for Kubernetes spec files
type: Kubernetes
files:
  - "*.yaml"
rules:
   # список правил

(rule.yaml)

بیایید آن را دقیق تر مطالعه کنیم:

رشته type مشخص می کند که config-lint از چه نوع پیکربندی استفاده خواهد کرد. برای K8s manifests این است همیشه Kubernetes.
در این زمینه files علاوه بر خود فایل ها، می توانید یک دایرکتوری نیز مشخص کنید.
رشته rules برای تنظیم تست های کاربر در نظر گرفته شده است.

فرض کنید می‌خواهید مطمئن شوید که تصاویر در Deployment همیشه از یک مخزن مطمئن دانلود می‌شوند. my-company.com/myapp:1.0. یک قانون config-lint که چنین چکی را انجام می دهد به شکل زیر است:

- id: MY_DEPLOYMENT_IMAGE_TAG
  severity: FAILURE
  message: Deployment must use a valid image tag
  resource: Deployment
  assertions:
    - every:
        key: spec.template.spec.containers
        expressions:
          - key: image
            op: starts-with
            value: "my-company.com/"

(rule-trusted-repo.yaml)

هر قانون باید دارای ویژگی های زیر باشد:

id - شناسه منحصر به فرد قانون؛
severity - شاید شکست, هشدار и NON_COMPLIANT;
message - در صورت نقض یک قانون، محتوای این خط نمایش داده می شود.
resource - نوع منبعی که این قانون در مورد آن اعمال می شود.
assertions - فهرستی از شرایطی که در رابطه با این منبع ارزیابی خواهند شد.

در قاعده بالا assertion نامیده می شود every بررسی می کند که همه کانتینرها در حالت Deployment هستند (key: spec.templates.spec.containers) از تصاویر قابل اعتماد استفاده کنید (یعنی با شروع my-company.com/).

مجموعه قوانین کامل به شکل زیر است:

version: 1
description: Rules for Kubernetes spec files
type: Kubernetes
files:
  - "*.yaml"
rules:

 - id: DEPLOYMENT_IMAGE_REPOSITORY # !!!
    severity: FAILURE
    message: Deployment must use a valid image repository
    resource: Deployment
    assertions:
      - every:
          key: spec.template.spec.containers
          expressions:
            - key: image
              op: starts-with
              value: "my-company.com/"

(ruleset.yaml)

برای امتحان کردن تست، اجازه دهید آن را به عنوان ذخیره کنیم check_image_repo.yaml. بیایید یک بررسی روی فایل اجرا کنیم base-valid.yaml:

$ config-lint -rules check_image_repo.yaml base-valid.yaml

[
  {
  "AssertionMessage": "Every expression fails: And expression fails: image does not start with my-company.com/",
  "Category": "",
  "CreatedAt": "2020-06-04T01:29:25Z",
  "Filename": "test-data/base-valid.yaml",
  "LineNumber": 0,
  "ResourceID": "http-echo",
  "ResourceType": "Deployment",
  "RuleID": "DEPLOYMENT_IMAGE_REPOSITORY",
  "RuleMessage": "Deployment must use a valid image repository",
  "Status": "FAILURE"
  }
]

چک ناموفق بود. حال بیایید مانیفست زیر را با مخزن تصویر صحیح بررسی کنیم:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: http-echo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: http-echo
  template:
    metadata:
      labels:
        app: http-echo
    spec:
      containers:
      - name: http-echo
         image: my-company.com/http-echo:1.0 # !!!
         args: ["-text", "hello-world"]
         ports:
         - containerPort: 5678

(image-valid-mycompany.yaml)

ما همین آزمایش را با مانیفست بالا اجرا می کنیم. هیچ مشکلی پیدا نشد:

$ config-lint -rules check_image_repo.yaml image-valid-mycompany.yaml
[]

Config-lint یک چارچوب امیدوارکننده است که به شما امکان می‌دهد با استفاده از YAML DSL، آزمایش‌های خود را برای تأیید مانیفست‌های Kubernetes YAML ایجاد کنید.

اما اگر به منطق و آزمون‌های پیچیده‌تری نیاز دارید، چه؟ آیا YAML برای این خیلی محدود نیست؟ اگر بتوانید تست هایی را در یک زبان برنامه نویسی کامل ایجاد کنید چه؟

4. مس

مس V2 چارچوبی برای اعتبارسنجی مانیفست ها با استفاده از تست های سفارشی (شبیه به config-lint).

با این حال، تفاوت آن با دومی در این است که از YAML برای توصیف آزمایش ها استفاده نمی کند. به جای آن می توان تست ها را با جاوا اسکریپت نوشت. مس یک کتابخانه را با چندین ابزار اساسی فراهم می کند، که به شما کمک می کند اطلاعات مربوط به اشیاء Kubernetes را بخوانید و خطاها را گزارش کنید.

مراحل نصب مس را می توان در این قسمت مشاهده کرد اسناد رسمی.

2.0.1 آخرین نسخه از این ابزار در زمان نوشتن مقاله اصلی است.

مانند config-lint، Copper دارای تست های داخلی نیست. یکی بنویسیم اجازه دهید بررسی کند که استقرارها از تصاویر کانتینر منحصراً از مخازن مورد اعتماد مانند استفاده می‌کنند my-company.com.

یک فایل ایجاد کنید check_image_repo.js با محتوای زیر:

$$.forEach(function($){
    if ($.kind === 'Deployment') {
        $.spec.template.spec.containers.forEach(function(container) {
            var image = new DockerImage(container.image);
            if (image.registry.lastIndexOf('my-company.com/') != 0) {
                errors.add_error('no_company_repo',"Image " + $.metadata.name + " is not from my-company.com repo", 1)
            }
        });
    }
});

اکنون برای آزمایش مانیفست خود base-valid.yaml، از دستور استفاده کنید copper validate:

$ copper validate --in=base-valid.yaml --validator=check_image_tag.js

Check no_company_repo failed with severity 1 due to Image http-echo is not from my-company.com repo
Validation failed

واضح است که با کمک مس می‌توانید آزمایش‌های پیچیده‌تری را انجام دهید - به عنوان مثال، بررسی نام دامنه در مانیفست‌های Ingress یا رد کردن پادهای در حال اجرا در حالت ممتاز.

مس دارای عملکردهای مفید مختلفی است که در آن تعبیه شده است:

DockerImage فایل ورودی مشخص شده را می خواند و یک شی با ویژگی های زیر ایجاد می کند:
- name - نام تصویر،
- tag - برچسب تصویر،
- registry - رجیستری تصویر،
- registry_url - پروتکل (https://) و رجیستری تصویر،
- fqin - مکان کامل تصویر
تابع findByName به یافتن یک منبع با یک نوع معین کمک می کند (kind) و نام (name) از فایل ورودی.
تابع findByLabels به یافتن یک منبع با یک نوع مشخص کمک می کند (kind) و برچسب ها (labels).

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

به طور پیش فرض کل فایل YAML ورودی را در یک متغیر بارگذاری می کند $$ و آن را برای اسکریپت نویسی در دسترس قرار می دهد (یک تکنیک آشنا برای کسانی که تجربه jQuery دارند).

مزیت اصلی Copper واضح است: شما نیازی به تسلط بر زبان تخصصی ندارید و می توانید از ویژگی های مختلف جاوا اسکریپت برای ایجاد تست های خود مانند درون یابی رشته ها، توابع و غیره استفاده کنید.

همچنین لازم به ذکر است که نسخه فعلی Copper با نسخه ES5 موتور جاوا اسکریپت کار می کند نه ES6.

جزئیات موجود در وب سایت رسمی پروژه.

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

5. مسابقه

Conftest چارچوبی برای آزمایش داده های پیکربندی است. همچنین برای آزمایش/تأیید مانیفست های Kubernetes مناسب است. تست ها با استفاده از یک زبان پرس و جو تخصصی توصیف می شوند رگو.

شما می توانید مسابقه را با استفاده از دستورالعمل هادر وب سایت پروژه ذکر شده است.

در زمان نگارش مقاله اصلی، آخرین نسخه موجود 0.18.2 بود.

مشابه config-lint و copper، conftest بدون هیچ آزمایش داخلی ارائه می شود. بیایید آن را امتحان کنیم و خط مشی خود را بنویسیم. مانند نمونه های قبلی، بررسی خواهیم کرد که آیا تصاویر کانتینر از یک منبع قابل اعتماد گرفته شده اند یا خیر.

یک دایرکتوری ایجاد کنید conftest-checks، و در آن فایلی به نام وجود دارد check_image_registry.rego با محتوای زیر:

package main

deny[msg] {

  input.kind == "Deployment"
  image := input.spec.template.spec.containers[_].image
  not startswith(image, "my-company.com/")
  msg := sprintf("image '%v' doesn't come from my-company.com repository", [image])
}

حالا بیایید تست کنیم base-valid.yaml از طریق conftest:

$ conftest test --policy ./conftest-checks base-valid.yaml

FAIL - base-valid.yaml - image 'hashicorp/http-echo' doesn't come from my-company.com repository
1 tests, 1 passed, 0 warnings, 1 failure

آزمایش به طور قابل پیش بینی شکست خورد زیرا تصاویر از یک منبع نامعتبر تهیه شده بودند.

در فایل Rego ما بلوک را تعریف می کنیم deny. حقیقت آن تخلف محسوب می شود. اگر بلوک deny چندین، conftest آنها را مستقل از یکدیگر بررسی می کند و صحت هر یک از بلوک ها به عنوان یک نقض تلقی می شود.

علاوه بر خروجی پیش‌فرض، conftest از فرمت JSON، TAP و جدول پشتیبانی می‌کند - یک ویژگی بسیار مفید در صورت نیاز به جاسازی گزارش‌ها در خط لوله CI موجود. با استفاده از پرچم می توانید فرمت مورد نظر را تنظیم کنید --output.

برای آسان‌تر کردن اشکال‌زدایی خط‌مشی‌ها، conftest یک پرچم دارد --trace. این خروجی یک ردی از نحوه تجزیه و تحلیل فایل های خط مشی مشخص شده توسط conftest است.

خط‌مشی‌های مسابقه را می‌توان در ثبت‌های OCI (ابتکار کانتینر باز) به عنوان مصنوع منتشر کرد و به اشتراک گذاشت.

تیم push и pull به شما امکان می دهد یک مصنوع را منتشر کنید یا یک مصنوع موجود را از یک رجیستری راه دور بازیابی کنید. بیایید سعی کنیم سیاستی را که ایجاد کردیم در رجیستری محلی Docker با استفاده از آن منتشر کنیم conftest push.

رجیستری Docker محلی خود را راه اندازی کنید:

$ docker run -it --rm -p 5000:5000 registry

در ترمینال دیگری به دایرکتوری که قبلا ایجاد کرده اید بروید conftest-checks و دستور زیر را اجرا کنید:

$ conftest push 127.0.0.1:5000/amitsaha/opa-bundle-example:latest

در صورت موفقیت آمیز بودن دستور، پیامی مانند زیر مشاهده خواهید کرد:

2020/06/10 14:25:43 pushed bundle with digest: sha256:e9765f201364c1a8a182ca637bc88201db3417bacc091e7ef8211f6c2fd2609c

حالا یک دایرکتوری موقت ایجاد کنید و دستور را در آن اجرا کنید conftest pull. بسته ایجاد شده توسط دستور قبلی را دانلود می کند:

$ cd $(mktemp -d)
$ conftest pull 127.0.0.1:5000/amitsaha/opa-bundle-example:latest

یک زیر شاخه در فهرست موقت ظاهر می شود policyحاوی فایل خط مشی ما:

$ tree
.
└── policy
  └── check_image_registry.rego

آزمایش ها را می توان مستقیماً از مخزن اجرا کرد:

$ conftest test --update 127.0.0.1:5000/amitsaha/opa-bundle-example:latest base-valid.yaml
..
FAIL - base-valid.yaml - image 'hashicorp/http-echo' doesn't come from my-company.com repository
2 tests, 1 passed, 0 warnings, 1 failure

متاسفانه DockerHub هنوز پشتیبانی نمی شود. پس در صورت استفاده خود را خوش شانس در نظر بگیرید رجیستری کانتینر لاجورد (ACR) یا رجیستری خودتان.

قالب مصنوع همان است بسته های عامل سیاست را باز کنید (OPA)، که به شما امکان می دهد از conftest برای اجرای آزمایش های بسته های OPA موجود استفاده کنید.

می‌توانید در مورد اشتراک‌گذاری خط‌مشی و سایر ویژگی‌های رقابت اطلاعات بیشتری کسب کنید وب سایت رسمی پروژه.

6. ستاره قطبی

آخرین ابزاری که در این مقاله مورد بحث قرار خواهد گرفت این است ستاره قطبی. (اعلان سال گذشته او ما قبلا ترجمه شده است - تقریبا ترجمه)

Polaris را می توان در یک کلاستر نصب کرد یا در حالت خط فرمان استفاده کرد. همانطور که ممکن است حدس زده باشید، به شما امکان می دهد به طور ایستا مانیفست های Kubernetes را تجزیه و تحلیل کنید.

هنگام اجرا در حالت خط فرمان، تست‌های داخلی در دسترس هستند که حوزه‌هایی مانند امنیت و بهترین شیوه‌ها را پوشش می‌دهند (شبیه به نمره kube). علاوه بر این، شما می توانید تست های خود را ایجاد کنید (مانند config-lint، copper و conftest).

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

برای نصب Polaris در حالت خط فرمان، استفاده کنید دستورالعمل ها در وب سایت پروژه.

در زمان نگارش مقاله اصلی، نسخه 1.0.3 موجود است.

پس از اتمام نصب، می توانید Polaris را روی مانیفست اجرا کنید base-valid.yaml با دستور زیر:

$ polaris audit --audit-path base-valid.yaml

یک رشته با فرمت JSON با شرح دقیق تست های انجام شده و نتایج آنها خروجی می دهد. خروجی ساختار زیر را خواهد داشت:

{
  "PolarisOutputVersion": "1.0",
  "AuditTime": "0001-01-01T00:00:00Z",
  "SourceType": "Path",
  "SourceName": "test-data/base-valid.yaml",
  "DisplayName": "test-data/base-valid.yaml",
  "ClusterInfo": {
    "Version": "unknown",
    "Nodes": 0,
    "Pods": 2,
    "Namespaces": 0,
    "Controllers": 2
  },
  "Results": [
    /* длинный список */
  ]
}

خروجی کامل موجود است اینجا.

مانند Kube-score، Polaris مسائلی را در مناطقی که مانیفست با بهترین شیوه‌ها مطابقت ندارد شناسایی می‌کند:

هیچ بررسی بهداشتی برای غلاف وجود ندارد.
برچسب برای تصاویر کانتینر مشخص نشده است.
ظرف به صورت ریشه اجرا می شود.
درخواست ها و محدودیت های حافظه و CPU مشخص نشده است.

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

اگر جزئیات مورد نیاز نیست، می توانید پرچم را مشخص کنید --format score. در این حالت، Polaris عددی در محدوده 1 تا 100- را خروجی می دهد نمره (یعنی ارزیابی):

$ polaris audit --audit-path test-data/base-valid.yaml --format score
68

هر چه امتیاز به 100 نزدیکتر باشد، میزان توافق بیشتر است. اگر کد خروج از دستور را بررسی کنید polaris audit، معلوم می شود که برابر با 0 است.

زور polaris audit با استفاده از دو پرچم می توانید کار را با کد غیر صفر خاتمه دهید:

فلگ --set-exit-code-below-score یک مقدار آستانه در محدوده 1-100 را به عنوان آرگومان می گیرد. در این حالت اگر امتیاز زیر آستانه باشد، دستور با کد خروجی 4 خارج می شود. این زمانی بسیار مفید است که مقدار آستانه مشخصی دارید (مثلا 75) و در صورت پایین آمدن امتیاز باید یک هشدار دریافت کنید.
فلگ --set-exit-code-on-danger اگر یکی از تست های خطر ناموفق باشد، فرمان با کد 3 از کار می افتد.

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

قطعه کد YAML زیر آزمایش جدیدی به نام را تشریح می کند checkImageRepo:

checkImageRepo:
  successMessage: Image registry is valid
  failureMessage: Image registry is not valid
  category: Images
  target: Container
  schema:
    '$schema': http://json-schema.org/draft-07/schema
    type: object
    properties:
      image:
        type: string
        pattern: ^my-company.com/.+$

بیایید نگاهی دقیق تر به آن بیندازیم:

successMessage - اگر آزمون با موفقیت به پایان برسد، این خط چاپ خواهد شد.
failureMessage - این پیام در صورت خرابی نشان داده می شود.
category - یکی از دسته ها را نشان می دهد: Images, Health Checks, Security, Networking и Resources;
target--- تعیین می کند که چه نوع شی (spec) آزمون اعمال می شود. مقادیر ممکن: Container, Pod یا Controller;
خود تست در شی مشخص شده است schema با استفاده از طرحواره JSON کلمه کلیدی در این آزمون این است pattern برای مقایسه منبع تصویر با منبع مورد نیاز استفاده می شود.

برای اجرای تست فوق، باید پیکربندی Polaris زیر را ایجاد کنید:

checks:
  checkImageRepo: danger
customChecks:
  checkImageRepo:
    successMessage: Image registry is valid
    failureMessage: Image registry is not valid
    category: Images
    target: Container
    schema:
      '$schema': http://json-schema.org/draft-07/schema
      type: object
      properties:
        image:
          type: string
          pattern: ^my-company.com/.+$

(polaris-conf.yaml)

بیایید فایل را تجزیه کنیم:

در این زمینه checks تست ها و سطح بحرانی بودن آنها تجویز می شود. از آنجایی که هنگام گرفتن یک تصویر از منبع نامعتبر، دریافت اخطار مطلوب است، سطح را در اینجا تنظیم می کنیم. danger.
خود آزمون checkImageRepo سپس در شی ثبت شد customChecks.

فایل را به عنوان ذخیره کنید custom_check.yaml. حالا می توانید بدوید polaris audit با مانیفست YAML که نیاز به تأیید دارد.

بیایید مانیفست خود را آزمایش کنیم base-valid.yaml:

$ polaris audit --config custom_check.yaml --audit-path base-valid.yaml

تیم polaris audit فقط تست کاربر مشخص شده در بالا را اجرا کرد و ناموفق بود.

اگر تصویر را به my-company.com/http-echo:1.0، Polaris با موفقیت تکمیل خواهد شد. مانیفست با تغییرات در حال حاضر وارد شده است مخازنبنابراین می توانید دستور قبلی را در مانیفست بررسی کنید image-valid-mycompany.yaml.

حال این سوال مطرح می شود: چگونه تست های داخلی را با تست های سفارشی اجرا کنیم؟ به آسانی! فقط باید شناسه های تست داخلی را به فایل پیکربندی اضافه کنید. در نتیجه به شکل زیر خواهد بود:

checks:
  cpuRequestsMissing: warning
  cpuLimitsMissing: warning
  # Other inbuilt checks..
  # ..
  # custom checks
  checkImageRepo: danger # !!!
customChecks:
  checkImageRepo:        # !!!
    successMessage: Image registry is valid
    failureMessage: Image registry is not valid
    category: Images
    target: Container
    schema:
      '$schema': http://json-schema.org/draft-07/schema
      type: object
      properties:
        image:
          type: string
          pattern: ^my-company.com/.+$

(config_with_custom_check.yaml)

نمونه ای از یک فایل پیکربندی کامل موجود است اینجا.

مانیفست را بررسی کنید base-valid.yamlبا استفاده از تست های داخلی و سفارشی، می توانید از دستور استفاده کنید:

$ polaris audit --config config_with_custom_check.yaml --audit-path base-valid.yaml

Polaris تست های داخلی را با تست های سفارشی تکمیل می کند و در نتیجه بهترین های هر دو جهان را با هم ترکیب می کند.

از سوی دیگر، ناتوانی در استفاده از زبان‌های قدرتمندتر مانند Rego یا جاوا اسکریپت می‌تواند عامل محدودکننده‌ای باشد که از ایجاد تست‌های پیچیده‌تر جلوگیری می‌کند.

اطلاعات بیشتر در مورد Polaris در اینجا موجود است وب سایت پروژه.

خلاصه

در حالی که ابزارهای زیادی برای بررسی و ارزیابی فایل های Kubernetes YAML وجود دارد، مهم است که درک روشنی از نحوه طراحی و اجرای آزمون ها داشته باشید.

برای مثال، اگر مانیفست های Kubernetes را که از طریق یک خط لوله عبور می کنند، در نظر بگیرید، کوبوال می تواند اولین قدم در چنین خط لوله ای باشد.. این برنامه نظارت می کند که آیا تعاریف شی با طرح API Kubernetes مطابقت دارد یا خیر.

پس از تکمیل چنین بازبینی، می‌توان به سراغ آزمایش‌های پیچیده‌تر، مانند انطباق با بهترین شیوه‌های استاندارد و سیاست‌های خاص رفت. اینجا جایی است که امتیاز کوبه و پولاریس به کار می آیند.

برای کسانی که الزامات پیچیده ای دارند و نیاز به سفارشی کردن تست ها با جزئیات دارند، مس، پیکربندی و کانفت مناسب هستند..

Conftest و config-lint از YAML برای تعریف تست های سفارشی استفاده می کنند و مس به شما امکان دسترسی به یک زبان برنامه نویسی کامل را می دهد و آن را به یک انتخاب بسیار جذاب تبدیل می کند.

از طرف دیگر، آیا ارزش استفاده از یکی از این ابزارها و ایجاد تمام تست ها به صورت دستی را دارد یا Polaris را ترجیح می دهید و فقط آنچه را که لازم است به آن اضافه کنید؟ پاسخ روشنی برای این سوال وجود ندارد.

در جدول زیر توضیح مختصری از هر ابزار ارائه شده است:

ابزار
هدف
محدودیت ها
تست های کاربر

کوبوال
مانیفست های YAML را در برابر نسخه خاصی از طرحواره API تأیید می کند
نمی توان با CRD کار کرد
بدون

امتیاز کوبه
تظاهرات YAML را در برابر بهترین شیوه ها تجزیه و تحلیل می کند
نمی‌توان نسخه Kubernetes API خود را برای بررسی منابع انتخاب کرد
بدون

مس
یک چارچوب کلی برای ایجاد تست های جاوا اسکریپت سفارشی برای YAML
بدون تست داخلی مستندات ضعیف
بله

config-lint
یک چارچوب کلی برای ایجاد آزمون ها در یک زبان دامنه خاص که در YAML تعبیه شده است. پشتیبانی از فرمت های پیکربندی مختلف (به عنوان مثال Terraform)
هیچ آزمایش آماده ای وجود ندارد. ادعاها و عملکردهای داخلی ممکن است کافی نباشند
بله

رقابت
چارچوبی برای ایجاد آزمون های خود با استفاده از Rego (یک زبان پرس و جو تخصصی). به اشتراک گذاری خط مشی ها از طریق بسته های OCI اجازه می دهد
بدون تست داخلی من باید Rego را یاد بگیرم. Docker Hub هنگام انتشار خط‌مشی‌ها پشتیبانی نمی‌شود
بله

ستاره قطبی
بررسی ها YAML در برابر بهترین شیوه های استاندارد ظاهر می شود. به شما امکان می دهد با استفاده از JSON Schema آزمایش های خود را ایجاد کنید
قابلیت‌های تست مبتنی بر طرحواره JSON ممکن است کافی نباشد
بله

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