ProHoster > Blog > Ma'muriyat > Kubernetes YAMLni eng yaxshi amaliyot va siyosatlarga muvofiq tasdiqlang

Kubernetes YAMLni eng yaxshi amaliyot va siyosatlarga muvofiq tasdiqlang

Eslatma. tarjima.: K8s muhitlari uchun YAML konfiguratsiyalarining soni ortib borishi bilan ularni avtomatlashtirilgan tekshirish zarurati tobora dolzarb bo'lib bormoqda. Ushbu sharh muallifi nafaqat ushbu vazifa uchun mavjud echimlarni tanlabgina qolmay, balki ularning qanday ishlashini ko'rish uchun Deploymentdan ham foydalangan. Ushbu mavzuga qiziquvchilar uchun juda ma'lumotli bo'lib chiqdi.

Kubernetes YAMLni eng yaxshi amaliyot va siyosatlarga muvofiq tasdiqlang

TP; DR: Ushbu maqola Kubernetes YAML fayllarini eng yaxshi amaliyot va talablarga muvofiq tekshirish va baholash uchun oltita statik vositalarni taqqoslaydi.

Kubernetes ish yuklari odatda YAML hujjatlari ko'rinishida aniqlanadi. YAML bilan bog'liq muammolardan biri manifest fayllari orasidagi cheklovlar yoki munosabatlarni belgilashning qiyinligi.

Klasterga joylashtirilgan barcha tasvirlar ishonchli registrdan olinganligiga ishonch hosil qilishimiz kerak bo'lsa-chi?

PodDisruptionBudgets bo'lmagan joylashtirishlarni klasterga yuborishni qanday oldini olishim mumkin?

Statik testlarning integratsiyasi ishlab chiqish bosqichida xatolar va siyosat buzilishini aniqlash imkonini beradi. Bu manba ta'riflarining to'g'ri va xavfsiz ekanligi kafolatini oshiradi va ishlab chiqarish ish yuklarining eng yaxshi amaliyotlarga amal qilish ehtimolini oshiradi.

Kubernetes statik YAML fayllarni tekshirish ekotizimini quyidagi toifalarga bo'lish mumkin:

  • API tekshiruvchilari. Ushbu turkumdagi vositalar YAML manifestini Kubernetes API serveri talablariga muvofiq tekshiradi.
  • Tayyor sinovchilar. Ushbu toifadagi vositalar xavfsizlik, eng yaxshi amaliyotlarga muvofiqlik va boshqalar uchun tayyor testlar bilan birga keladi.
  • Maxsus tekshiruvchilar. Ushbu toifa vakillari sizga turli tillarda, masalan, Rego va Javascript kabi maxsus testlarni yaratishga imkon beradi.

Ushbu maqolada biz olti xil vositalarni tasvirlab beramiz va solishtiramiz:

  1. kubeval;
  2. kub bal;
  3. config-lint;
  4. mis;
  5. bellashuv;
  6. polaris.

Xo'sh, boshlaylik!

Joylashtirishlarni tekshirish

Asboblarni solishtirishni boshlashdan oldin, keling, ularni sinab ko'rish uchun fon yarataylik.

Quyidagi manifestda bir qator xatolar va eng yaxshi amaliyotlarga rioya qilmaslik mavjud: ulardan qanchasini topishingiz mumkin?

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)

Turli vositalarni solishtirish uchun biz ushbu YAML dan foydalanamiz.

Yuqoridagi manifest base-valid.yaml va ushbu maqoladagi boshqa manifestlarni topishingiz mumkin Git omborlari.

Manifest veb-ilovani tasvirlaydi, uning asosiy vazifasi 5678-portga β€œSalom dunyo” xabari bilan javob berishdir. Uni quyidagi buyruq bilan joylashtirish mumkin:

kubectl apply -f hello-world.yaml

Va shuning uchun - ishni tekshiring:

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

Endi o'ting http://localhost:8080 va ilova ishlayotganligini tasdiqlang. Lekin u eng yaxshi amaliyotlarga amal qiladimi? Keling, tekshiramiz.

1. Kubeval

Bazasida kubeval G'oya shundan iboratki, Kubernetes bilan har qanday shovqin uning REST API orqali amalga oshiriladi. Boshqacha qilib aytganda, berilgan YAML unga mos kelishini tekshirish uchun API sxemasidan foydalanishingiz mumkin. Keling, bir misolni ko'rib chiqaylik.

O'rnatish bo'yicha ko'rsatmalar kubeval loyiha veb-saytida mavjud.

Asl maqolani yozish vaqtida 0.15.0 versiyasi mavjud edi.

O'rnatilgandan so'ng, keling, uni yuqoridagi manifest bilan ta'minlaylik:

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

Muvaffaqiyatli bo'lsa, kubeval chiqish kodi 0 bilan chiqadi. Uni quyidagicha tekshirishingiz mumkin:

$ echo $?
0

Keling, kubevalni boshqa manifest bilan sinab ko'raylik:

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)

Muammoni ko'z bilan aniqlay olasizmi? Keling, ishga tushiramiz:

$ 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

Resurs tekshirilmayapti.

API versiyasidan foydalangan holda joylashtirish apps/v1, pod yorlig'iga mos keladigan selektorni o'z ichiga olishi kerak. Yuqoridagi manifest selektorni o'z ichiga olmaydi, shuning uchun kubeval xato haqida xabar berdi va nolga teng bo'lmagan kod bilan chiqdi.

Agar shunday qilsam nima bo'ladi, deb o'ylayman kubectl apply -f bu manifest bilan?

Xo'sh, harakat qilaylik:

$ 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

Bu kubeval haqida ogohlantirgan xato. Buni selektor qo'shish orqali tuzatishingiz mumkin:

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 kabi vositalarning afzalligi shundaki, bu kabi xatolar joylashtirish siklining boshida aniqlanishi mumkin.

Bundan tashqari, ushbu tekshiruvlar klasterga kirishni talab qilmaydi, ular oflayn rejimda amalga oshirilishi mumkin.

Odatiy bo'lib, kubeval resurslarni eng so'nggi Kubernetes API sxemasi bilan tekshiradi. Biroq, aksariyat hollarda siz Kubernetesning ma'lum bir versiyasini tekshirishingiz kerak bo'lishi mumkin. Buni bayroq yordamida amalga oshirish mumkin --kubernetes-version:

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

Iltimos, versiya formatda ko'rsatilishi kerakligini unutmang Major.Minor.Patch.

Tekshirish qo'llab-quvvatlanadigan versiyalar ro'yxati uchun qarang GitHub'da JSON sxemasi, qaysi kubeval tekshirish uchun foydalanadi. Agar siz kubevalni oflayn rejimda ishga tushirishingiz kerak bo'lsa, sxemalarni yuklab oling va bayroq yordamida ularning mahalliy joylashuvini belgilang --schema-location.

Shaxsiy YAML fayllariga qo'shimcha ravishda kubeval kataloglar va stdin bilan ham ishlashi mumkin.

Bundan tashqari, Kubeval CI quvur liniyasiga osongina integratsiyalashgan. Klasterga manifestlarni yuborishdan oldin testlarni o'tkazmoqchi bo'lganlar kubeval uchta chiqish formatini qo'llab-quvvatlashini bilishdan mamnun bo'lishadi:

  1. Oddiy matn;
  2. JSON;
  3. Har qanday narsani sinab ko'rish protokoli (TAP).

Va har qanday formatdan istalgan turdagi natijalarning xulosasini yaratish uchun chiqishni keyingi tahlil qilish uchun foydalanish mumkin.

Kubevalning kamchiliklaridan biri shundaki, u hozirda Custom Resource Definitions (CRDs) ga muvofiqligini tekshira olmaydi. Biroq, kubevalni sozlash mumkin ularga e'tibor bermang.

Kubeval - resurslarni tekshirish va baholash uchun ajoyib vosita; Ammo shuni ta'kidlash kerakki, testdan o'tish resurs eng yaxshi amaliyotlarga mos kelishini kafolatlamaydi.

Masalan, teg yordamida latest konteynerda eng yaxshi amaliyotlarga amal qilmaydi. Biroq, kubeval buni xato deb hisoblamaydi va bu haqda xabar bermaydi. Ya'ni, bunday YAMLni tekshirish ogohlantirishlarsiz yakunlanadi.

Ammo YAMLni baholash va teg kabi buzilishlarni aniqlashni istasangiz nima bo'ladi latest? YAML faylini eng yaxshi amaliyotlar bilan qanday tekshirish mumkin?

2. Kube-ball

Kube ball YAML manifestlarini tahlil qiladi va ularni o'rnatilgan testlarga nisbatan baholaydi. Ushbu testlar xavfsizlik qoidalari va eng yaxshi amaliyotlar asosida tanlanadi, masalan:

  • Idish sifatida emas, konteynerni ishga tushirish.
  • Pod sog'lig'ini tekshirishning mavjudligi.
  • Resurslar uchun so'rovlar va cheklovlarni o'rnatish.

Sinov natijalariga ko'ra uchta natija beriladi: OK, OGOHLANTIRISH ΠΈ CRITICAL.

Siz Kube-score-ni onlayn tarzda sinab ko'rishingiz yoki uni mahalliy sifatida o'rnatishingiz mumkin.

Asl maqolani yozish paytida kube-scorening so'nggi versiyasi 1.7.0 edi.

Keling, buni manifestimizda sinab ko'raylik 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 sinovlaridan o'tadi, kube-score esa quyidagi kamchiliklarga ishora qiladi:

  • Tayyorlik tekshiruvlari sozlanmagan.
  • CPU resurslari va xotira uchun hech qanday so'rov yoki cheklovlar yo'q.
  • Podni buzish byudjetlari aniqlanmagan.
  • Ajratish qoidalari yo'q (yaqinlikka qarshi) mavjudligini maksimal darajada oshirish uchun.
  • Konteyner ildiz sifatida ishlaydi.

Bularning barchasi Joylashtirishni yanada samarali va ishonchli qilish uchun hal qilinishi kerak bo'lgan kamchiliklar haqida to'g'ri fikrlardir.

komanda kube-score ma'lumotlarni inson o'qishi mumkin bo'lgan shaklda, shu jumladan barcha turdagi qoidabuzarliklarni ko'rsatadi OGOHLANTIRISH ΠΈ CRITICAL, bu rivojlanish jarayonida juda ko'p yordam beradi.

Ushbu vositani CI quvur liniyasida ishlatmoqchi bo'lganlar bayroq yordamida ko'proq siqilgan chiqishni yoqishlari mumkin --output-format ci (bu holda, natijasi bo'lgan testlar ham ko'rsatiladi 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

Kubevalga o'xshab, kube-score sinovdan o'tmaganda nolga teng bo'lmagan chiqish kodini qaytaradi. CRITICAL. Shu kabi ishlov berishni ham yoqishingiz mumkin OGOHLANTIRISH.

Bundan tashqari, resurslarning turli xil API versiyalariga muvofiqligini tekshirish mumkin (kubevalda bo'lgani kabi). Biroq, bu ma'lumot kube-skorning o'zida qattiq kodlangan: siz Kubernetesning boshqa versiyasini tanlay olmaysiz. Agar siz klasteringizni yangilamoqchi bo'lsangiz yoki K8-ning turli versiyalariga ega bir nechta klasteringiz bo'lsa, bu cheklov katta muammo bo'lishi mumkin.

E'tibor bering allaqachon muammo bor ushbu imkoniyatni amalga oshirish taklifi bilan.

Kube-score haqida batafsil ma'lumotni quyidagi manzilda topishingiz mumkin rasmiy veb-sayti.

Kube-score testlari eng yaxshi amaliyotlarni amalga oshirish uchun ajoyib vositadir, ammo agar siz testga o'zgartirishlar kiritishingiz yoki o'z qoidalaringizni qo'shishingiz kerak bo'lsa-chi? Afsuski, buni amalga oshirish mumkin emas.

Kube-skorni kengaytirib bo'lmaydi: siz unga siyosat qo'sha olmaysiz yoki ularni o'zgartira olmaysiz.

Agar siz kompaniya siyosatlariga muvofiqligini tekshirish uchun maxsus testlarni yozishingiz kerak bo'lsa, quyidagi to'rtta vositadan birini qo'llashingiz mumkin: config-lint, mis, confest yoki polaris.

3.Config-lint

Config-lint bu YAML, JSON, Terraform, CSV konfiguratsiya fayllari va Kubernetes manifestlarini tekshirish uchun vositadir.

Uni yordamida o'rnatishingiz mumkin ko'rsatmalar loyiha veb-saytida.

Asl maqolani yozish vaqtidagi joriy nashr 1.5.0.

Config-lint-da Kubernetes manifestlarini tekshirish uchun o'rnatilgan testlar mavjud emas.

Har qanday testlarni o'tkazish uchun siz tegishli qoidalarni yaratishingiz kerak. Ular "qoidalar to'plami" deb nomlangan YAML fayllarida yozilgan. (qoidalar to'plami), va quyidagi tuzilishga ega:

version: 1
description: Rules for Kubernetes spec files
type: Kubernetes
files:
  - "*.yaml"
rules:
   # список ΠΏΡ€Π°Π²ΠΈΠ»

(rule.yaml)

Keling, buni batafsil o'rganamiz:

  • dala type config-lint qanday konfiguratsiya turidan foydalanishini belgilaydi. K8s uchun bu shunday har doim Kubernetes.
  • Dalada files Fayllarning o'ziga qo'shimcha ravishda siz katalogni belgilashingiz mumkin.
  • dala rules foydalanuvchi testlarini o'rnatish uchun mo'ljallangan.

Aytaylik, siz Deployment ilovasidagi tasvirlar doimo ishonchli ombordan yuklab olinishiga ishonch hosil qilmoqchisiz. my-company.com/myapp:1.0. Bunday tekshirishni amalga oshiradigan konfiguratsiya qoidasi quyidagicha ko'rinadi:

- 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)

Har bir qoida quyidagi atributlarga ega bo'lishi kerak:

  • id β€” qoidaning yagona identifikatori;
  • severity - balkim Xato, OGOHLANTIRISH ΠΈ MOS_MUOFIQ EMAS;
  • message β€” qoida buzilgan bo'lsa, ushbu qatorning mazmuni ko'rsatiladi;
  • resource β€” ushbu qoida amal qiladigan resurs turi;
  • assertions β€” ushbu resursga nisbatan baholanadigan shartlar roβ€˜yxati.

Yuqoridagi qoidada assertion nom ostida every barcha konteynerlar joylashtirishda ekanligini tekshiradi (key: spec.templates.spec.containers) ishonchli tasvirlardan foydalaning (ya'ni my-company.com/).

To'liq qoidalar to'plami quyidagicha ko'rinadi:

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)

Sinovni sinab ko'rish uchun uni shunday saqlaylik check_image_repo.yaml. Keling, faylni tekshirishni amalga oshiramiz 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"
  }
]

Tekshirish amalga oshmadi. Endi to'g'ri tasvirlar ombori bilan quyidagi manifestni ko'rib chiqamiz:

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)

Yuqoridagi manifest bilan bir xil testni o'tkazamiz. Hech qanday muammo topilmadi:

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

Config-lint - bu YAML DSL yordamida Kubernetes YAML manifestlarini tekshirish uchun o'z testlaringizni yaratishga imkon beruvchi istiqbolli ramka.

Ammo sizga murakkabroq mantiq va testlar kerak bo'lsa-chi? YAML buning uchun juda cheklangan emasmi? To'liq dasturlash tilida testlar yaratsangiz nima bo'ladi?

4. Mis

Mis V2 maxsus testlar (config-lintga o'xshash) yordamida manifestlarni tekshirish uchun asosdir.

Biroq, u testlarni tasvirlash uchun YAML dan foydalanmasligi bilan ikkinchisidan farq qiladi. Testlar o'rniga JavaScript-da yozilishi mumkin. Mis kutubxonani bir nechta asosiy vositalar bilan ta'minlaydi, bu sizga Kubernetes ob'ektlari haqidagi ma'lumotlarni o'qish va xatolar haqida xabar berishga yordam beradi.

Misni o'rnatish bosqichlarini bo'limda topish mumkin rasmiy hujjatlar.

2.0.1 asl maqolani yozish vaqtida ushbu yordamchi dasturning so'nggi versiyasidir.

Config-lint singari, Copper ham o'rnatilgan testlarga ega emas. Keling, bittasini yozaylik. O'rnatishlar konteyner tasvirlarini faqat ishonchli omborlar kabi ishlatishini tekshirishga ruxsat bering my-company.com.

Fayl yarating check_image_repo.js quyidagi tarkib bilan:

$$.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)
            }
        });
    }
});

Endi manifestimizni sinab ko'rish uchun base-valid.yaml, buyrug'idan foydalaning 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

Mis yordamida siz murakkabroq testlarni amalga oshirishingiz mumkinligi aniq - masalan, Ingress manifestlarida domen nomlarini tekshirish yoki imtiyozli rejimda ishlaydigan podlarni rad etish.

Mis o'z ichiga turli xil foydali funktsiyalarga ega:

  • DockerImage belgilangan kirish faylini o'qiydi va quyidagi atributlarga ega ob'ektni yaratadi:
    • name - rasmning nomi,
    • tag - rasm yorlig'i,
    • registry - tasvirlar reestri,
    • registry_url - protokol (https://) va tasvirlar ro'yxati,
    • fqin β€” tasvirning toΚ»liq joylashuvi.
  • vazifa findByName ma'lum turdagi manbani topishga yordam beradi (kind) va nomi (name) kirish faylidan.
  • vazifa findByLabels ma'lum turdagi manbani topishga yordam beradi (kind) va teglar (labels).

Siz barcha mavjud xizmat funktsiyalarini ko'rishingiz mumkin shu yerda.

Odatiy bo'lib, u butun kirish YAML faylini o'zgaruvchiga yuklaydi $$ va uni skript yaratish uchun mavjud qiladi (jQuery tajribasiga ega bo'lganlar uchun tanish texnika).

Misning asosiy afzalligi aniq: ixtisoslashgan tilni o'zlashtirish shart emas va siz o'zingizning testlaringizni yaratish uchun JavaScript-ning turli xususiyatlaridan foydalanishingiz mumkin, masalan, qatorlar interpolyatsiyasi, funktsiyalar va boshqalar.

Shuni ham ta'kidlash kerakki, Misning joriy versiyasi ES5 emas, balki JavaScript dvigatelining ES6 versiyasi bilan ishlaydi.

Tafsilotlar quyidagi manzilda mavjud loyiha rasmiy veb-sayti.

Biroq, agar siz JavaScript-ni yoqtirmasangiz va so'rovlar yaratish va siyosatlarni tavsiflash uchun maxsus mo'ljallangan tilni afzal ko'rsangiz, konfestga e'tibor berishingiz kerak.

5. Musobaqa

Confest - bu konfiguratsiya ma'lumotlarini sinab ko'rish uchun ramka. Kubernetes manifestlarini sinash/tasdiqlash uchun ham javob beradi. Testlar ixtisoslashtirilgan so'rovlar tilidan foydalangan holda tavsiflanadi Rego.

Confest-dan foydalanib o'rnatishingiz mumkin ko'rsatmalarloyiha veb-saytida keltirilgan.

Asl maqolani yozish vaqtida mavjud bo'lgan so'nggi versiya 0.18.2 edi.

Config-lint va misga o'xshab, confest hech qanday o'rnatilgan testlarsiz keladi. Keling, buni sinab ko'raylik va o'z siyosatimizni yozamiz. Oldingi misollarda bo'lgani kabi, konteyner tasvirlari ishonchli manbadan olinganligini tekshiramiz.

Katalog yarating conftest-checks, va unda nomli fayl mavjud check_image_registry.rego quyidagi tarkib bilan:

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])
}

Endi sinov qilaylik base-valid.yaml ichidan 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

Tasvirlar ishonchsiz manbadan olingani uchun sinov taxminiy ravishda muvaffaqiyatsiz tugadi.

Rego faylida biz blokni aniqlaymiz deny. Uning haqiqati buzilish deb hisoblanadi. Agar bloklar bo'lsa deny bir nechta, confest ularni bir-biridan mustaqil ravishda tekshiradi va har qanday blokning haqiqati buzilish sifatida qabul qilinadi.

Standart chiqishga qo'shimcha ravishda, confest JSON, TAP va jadval formatlarini qo'llab-quvvatlaydi - agar siz hisobotlarni mavjud CI quvur liniyasiga joylashtirishingiz kerak bo'lsa, juda foydali xususiyatdir. Siz bayroq yordamida kerakli formatni o'rnatishingiz mumkin --output.

Siyosatlarni disk raskadrovka qilishni osonlashtirish uchun confest bayrog'iga ega --trace. U konfestning belgilangan siyosat fayllarini qanday tahlil qilishini ko'rsatadi.

Tanlov siyosatlari artefakt sifatida OCI (Open Container Initiative) registrlarida chop etilishi va baham ko'rilishi mumkin.

Buyruqlar push ΠΈ pull artefaktni nashr qilish yoki mavjud artefaktni masofaviy registrdan olish imkonini beradi. Keling, biz yaratgan siyosatni mahalliy Docker registrida nashr qilishga harakat qilaylik conftest push.

Mahalliy Docker registrini ishga tushiring:

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

Boshqa terminalda avval yaratgan katalogga o'ting conftest-checks va quyidagi buyruqni bajaring:

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

Agar buyruq muvaffaqiyatli bo'lsa, siz quyidagi xabarni ko'rasiz:

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

Endi vaqtinchalik katalog yarating va undagi buyruqni bajaring conftest pull. U oldingi buyruq bilan yaratilgan paketni yuklab oladi:

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

Vaqtinchalik katalogda pastki katalog paydo bo'ladi policysiyosat faylimizni o'z ichiga oladi:

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

Sinovlar to'g'ridan-to'g'ri ombordan o'tkazilishi mumkin:

$ 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

Afsuski, DockerHub hali qo'llab-quvvatlanmaydi. Agar foydalansangiz, o'zingizni omadli deb hisoblang Azure konteyner registri (ACR) yoki shaxsiy reestringiz.

Artifakt formati bir xil Policy agent paketlarini oching (OPA), bu sizga mavjud OPA paketlaridan testlarni ishga tushirish uchun confest dan foydalanish imkonini beradi.

Siz siyosat almashish va konfestning boshqa xususiyatlari haqida koΚ»proq maΚΌlumot olishingiz mumkin loyiha rasmiy veb-sayti.

6. Polaris

Ushbu maqolada muhokama qilinadigan oxirgi vosita Polaris. (Uning o'tgan yilgi e'lon biz allaqachon tarjima qilingan - taxminan. tarjima)

Polaris klasterga o'rnatilishi yoki buyruq qatori rejimida ishlatilishi mumkin. Siz taxmin qilganingizdek, bu sizga Kubernetes manifestlarini statik tahlil qilish imkonini beradi.

Buyruqlar qatori rejimida ishlayotganda, xavfsizlik va eng yaxshi amaliyotlar (kube-scorega o'xshash) kabi sohalarni qamrab oluvchi o'rnatilgan testlar mavjud. Bundan tashqari, siz o'zingizning testlaringizni yaratishingiz mumkin (config-lint, mis va confest kabi).

Boshqacha qilib aytganda, Polaris ikkala toifadagi vositalarning afzalliklarini birlashtiradi: o'rnatilgan va maxsus testlar bilan.

Polarisni buyruq qatori rejimida o'rnatish uchun foydalaning loyiha veb-saytidagi ko'rsatmalar.

Asl maqolani yozish vaqtida 1.0.3 versiyasi mavjud.

O'rnatish tugallangandan so'ng siz manifestda polarisni ishga tushirishingiz mumkin base-valid.yaml quyidagi buyruq bilan:

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

U o'tkazilgan testlar va ularning natijalarining batafsil tavsifi bilan JSON formatidagi qatorni chiqaradi. Chiqish quyidagi tuzilishga ega bo'ladi:

{
  "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": [
    /* Π΄Π»ΠΈΠ½Π½Ρ‹ΠΉ список */
  ]
}

To'liq chiqish mavjud shu yerda.

Kube-score singari, Polaris manifest eng yaxshi amaliyotlarga mos kelmaydigan sohalardagi muammolarni aniqlaydi:

  • Po'choqlar uchun sog'liq tekshiruvi yo'q.
  • Konteyner tasvirlari uchun teglar belgilanmagan.
  • Konteyner ildiz sifatida ishlaydi.
  • Xotira va CPU uchun so'rovlar va cheklovlar belgilanmagan.

Har bir test, uning natijalariga qarab, tanqidiylik darajasiga ega: ogohlantirish yoki Xavf. Mavjud o'rnatilgan testlar haqida ko'proq ma'lumot olish uchun qarang hujjatlar.

Agar tafsilotlar kerak bo'lmasa, siz bayroqni belgilashingiz mumkin --format score. Bunday holda, Polaris 1 dan 100 gacha bo'lgan raqamni chiqaradi - Hisob (ya'ni baholash):

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

Ballar 100 ga qanchalik yaqin bo'lsa, kelishuv darajasi shunchalik yuqori bo'ladi. Agar siz buyruqning chiqish kodini tekshirsangiz polaris audit, u 0 ga teng ekanligi ma'lum bo'ldi.

Kuch polaris audit Ikkita bayroq yordamida nolga teng bo'lmagan kod bilan ishni tugatishingiz mumkin:

  • Bayroq --set-exit-code-below-score argument sifatida 1-100 oralig'idagi chegara qiymatini oladi. Bunday holda, agar ball chegaradan past bo'lsa, buyruq chiqish kodi 4 bilan chiqadi. Bu sizda ma'lum bir chegara qiymatiga (aytaylik, 75) ega bo'lganingizda juda foydali va agar ball pastroq bo'lsa, ogohlantirish olishingiz kerak.
  • Bayroq --set-exit-code-on-danger agar xavf testlaridan biri muvaffaqiyatsiz bo'lsa, buyruq 3-kod bilan bajarilmasligiga olib keladi.

Keling, rasmning ishonchli ombordan olinganligini tekshiradigan maxsus test yaratishga harakat qilaylik. Maxsus testlar YAML formatida ko'rsatilgan va testning o'zi JSON sxemasi yordamida tasvirlangan.

Quyidagi YAML kod parchasi deb nomlangan yangi testni tavsiflaydi 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/.+$

Keling, buni batafsil ko'rib chiqaylik:

  • successMessage β€” agar test muvaffaqiyatli yakunlansa, bu qator chop etiladi;
  • failureMessage β€” bu xabar ishlamay qolganda ko'rsatiladi;
  • category β€” toifalardan birini bildiradi: Images, Health Checks, Security, Networking ΠΈ Resources;
  • target--- qanday turdagi ob'ektni aniqlaydi (spec) test qo'llaniladi. Mumkin qiymatlar: Container, Pod yoki Controller;
  • Sinovning o'zi ob'ektda ko'rsatilgan schema JSON sxemasidan foydalanish. Ushbu testdagi kalit so'z pattern tasvir manbasini kerakli bilan solishtirish uchun ishlatiladi.

Yuqoridagi testni bajarish uchun siz quyidagi Polaris konfiguratsiyasini yaratishingiz kerak:

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)

Faylni tahlil qilaylik:

  • Dalada checks testlar va ularning kritiklik darajasi belgilanadi. Ishonchsiz manbadan rasm olinganda ogohlantirish olish ma'qul bo'lgani uchun biz bu erda darajani o'rnatamiz. danger.
  • Sinovning o'zi checkImageRepo keyin ob'ektda ro'yxatdan o'tgan customChecks.

Faylni shunday saqlang custom_check.yaml. Endi siz yugurishingiz mumkin polaris audit tekshirishni talab qiladigan YAML manifestiga ega.

Keling, manifestimizni sinab ko'raylik base-valid.yaml:

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

komanda polaris audit faqat yuqorida ko'rsatilgan foydalanuvchi testini o'tkazdi va u muvaffaqiyatsiz tugadi.

Agar siz rasmni tuzatsangiz my-company.com/http-echo:1.0, Polaris muvaffaqiyatli yakunlanadi. O'zgarishlar bilan manifest allaqachon kiritilgan omborlarshuning uchun manifestdagi oldingi buyruqni tekshirishingiz mumkin image-valid-mycompany.yaml.

Endi savol tug'iladi: o'rnatilgan testlarni maxsus testlar bilan qanday o'tkazish kerak? Osonlik bilan! Siz faqat konfiguratsiya fayliga o'rnatilgan test identifikatorlarini qo'shishingiz kerak. Natijada, u quyidagi shaklni oladi:

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)

To'liq konfiguratsiya faylining namunasi mavjud shu yerda.

Manifestni tekshiring base-valid.yamlo'rnatilgan va maxsus testlardan foydalanib, siz quyidagi buyruqdan foydalanishingiz mumkin:

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

Polaris o'rnatilgan testlarni maxsus testlar bilan to'ldiradi va shu bilan ikkala dunyoning eng yaxshisini birlashtiradi.

Boshqa tomondan, Rego yoki JavaScript kabi kuchliroq tillardan foydalana olmaslik yanada murakkab testlarni yaratishga xalaqit beradigan cheklovchi omil bo'lishi mumkin.

Polaris haqida ko'proq ma'lumotni quyidagi manzilda olishingiz mumkin loyiha sayti.

Xulosa

Kubernetes YAML fayllarini tekshirish va baholash uchun ko'plab vositalar mavjud bo'lsa-da, testlar qanday ishlab chiqilishi va bajarilishi haqida aniq tushunchaga ega bo'lish muhimdir.

Misol uchun, Agar siz Kubernetes manifestini quvur orqali o'tayotgan bo'lsangiz, kubeval bunday quvur liniyasidagi birinchi qadam bo'lishi mumkin.. U ob'ekt ta'riflari Kubernetes API sxemasiga mos kelishini nazorat qiladi.

Bunday ko'rib chiqish tugallangandan so'ng, eng yaxshi standart amaliyotlar va maxsus siyosatlarga muvofiqlik kabi murakkabroq testlarga o'tish mumkin. Bu erda kube-skor va Polaris yordam beradi.

Murakkab talablarga ega bo'lganlar va testlarni batafsil sozlashlari kerak bo'lganlar uchun mis, config-lint va confest mos keladi..

Confest va config-lint maxsus testlarni aniqlash uchun YAML-dan foydalanadi va mis sizga to'liq dasturlash tiliga kirish imkonini beradi va bu juda jozibali tanlovdir.

Boshqa tomondan, ushbu vositalardan birini ishlatishga arziydimi va shuning uchun barcha testlarni qo'lda yaratish yoki Polarisni afzal ko'rish va unga faqat kerakli narsani qo'shish kerakmi? Bu savolga aniq javob yo'q.

Quyidagi jadvalda har bir vositaning qisqacha tavsifi keltirilgan:

asbob
Maqsad
kamchiliklar
Foydalanuvchi testlari

kubeval
YAML manifestlarini API sxemasining ma'lum bir versiyasiga nisbatan tasdiqlaydi
CRD bilan ishlash mumkin emas
yo'q

kub bal
YAML manifestlarini eng yaxshi amaliyotlarga qarshi tahlil qiladi
Resurslarni tekshirish uchun Kubernetes API versiyasini tanlab boβ€˜lmadi
yo'q

Mis
YAML manifestlari uchun maxsus JavaScript testlarini yaratish uchun umumiy asos
O'rnatilgan testlar yo'q. Yomon hujjatlar
ekan

config-lint
YAML ichiga kiritilgan domenga xos tilda testlar yaratish uchun umumiy asos. Turli xil konfiguratsiya formatlarini qo'llab-quvvatlaydi (masalan, Terraform)
Tayyor testlar yo'q. O'rnatilgan tasdiqlar va funktsiyalar etarli bo'lmasligi mumkin
ekan

bellashuv
Rego (maxsus so'rovlar tili) yordamida o'z testlaringizni yaratish uchun ramka. OCI paketlari orqali siyosatlarni almashish imkonini beradi
O'rnatilgan testlar yo'q. Men Regoni o'rganishim kerak. Siyosatlarni nashr qilishda Docker Hub qo'llab-quvvatlanmaydi
ekan

Polaris
Ko'rib chiqish YAML standart eng yaxshi amaliyotlarga nisbatan namoyon bo'ladi. JSON sxemasidan foydalanib, o'z testlaringizni yaratishga imkon beradi
JSON sxemasiga asoslangan test imkoniyatlari etarli bo'lmasligi mumkin
ekan

Ushbu vositalar Kubernetes klasteriga kirishga tayanmasligi sababli ularni o'rnatish oson. Ular sizga manba fayllarini filtrlash va loyihalardagi tortishish so'rovlari mualliflariga tezkor fikr-mulohazalarni taqdim etish imkonini beradi.

Tarjimondan PS

Shuningdek, bizning blogimizda o'qing:

Manba: www.habr.com

a Izoh qo'shish