🥇Kubernetes YAML-nin ən yaxşı təcrübə və siyasətlərə qarşı doğrulanması

Qeyd. tərcümə.: K8s mühitləri üçün artan YAML konfiqurasiyaları ilə onların avtomatlaşdırılmış yoxlanılması ehtiyacı getdikcə daha aktuallaşır. Bu icmalın müəllifi təkcə bu tapşırıq üçün mövcud həlləri seçməyib, həm də onların necə işlədiyini görmək üçün Yerləşdirmədən nümunə kimi istifadə edib. Bu mövzu ilə maraqlananlar üçün çox məlumatlı olduğu ortaya çıxdı.

TL; DR: Bu məqalə Kubernetes YAML fayllarını ən yaxşı təcrübələrə və tələblərə uyğun yoxlamaq və qiymətləndirmək üçün altı statik aləti müqayisə edir.

Kubernetes iş yükləri adətən YAML sənədləri şəklində müəyyən edilir. YAML ilə bağlı problemlərdən biri manifest faylları arasında məhdudiyyətlərin və ya əlaqələrin müəyyənləşdirilməsinin çətinliyidir.

Klasterə yerləşdirilən bütün şəkillərin etibarlı reyestrdən gəldiyinə əmin olmaq lazımdırsa nə etməli?

PodDisruptionBudgets olmayan Yerləşdirmələrin klasterə göndərilməsinin qarşısını necə ala bilərəm?

Statik testin inteqrasiyası inkişaf mərhələsində səhvləri və siyasət pozuntularını müəyyən etməyə imkan verir. Bu, resurs təriflərinin düzgün və təhlükəsiz olmasına zəmanəti artırır və istehsal iş yüklərinin ən yaxşı təcrübələrə əməl etməsi ehtimalını artırır.

Kubernetes statik YAML fayl təftiş ekosistemi aşağıdakı kateqoriyalara bölünə bilər:

API təsdiqləyiciləri. Bu kateqoriyadakı alətlər YAML manifestini Kubernetes API serverinin tələblərinə uyğun yoxlayır.
Hazır testerlər. Bu kateqoriyadan olan alətlər təhlükəsizlik, ən yaxşı təcrübələrə uyğunluq və s. üçün hazır testlərlə gəlir.
Xüsusi təsdiqləyicilər. Bu kateqoriyanın nümayəndələri müxtəlif dillərdə, məsələn, Rego və Javascript kimi xüsusi testlər yaratmağa imkan verir.

Bu yazıda altı fərqli aləti təsvir edəcəyik və müqayisə edəcəyik:

kubeval;
kub bal;
config-lint;
mis;
yarışma;
Qütb.

Yaxşı, başlayaq!

Yerləşdirmələrin yoxlanılması

Alətləri müqayisə etməyə başlamazdan əvvəl, onları sınamaq üçün bəzi fon yaradaq.

Aşağıdakı manifestdə bir sıra səhvlər və ən yaxşı təcrübələrə uyğunsuzluq var: onlardan neçəsini tapa bilərsiniz?

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)

Müxtəlif alətləri müqayisə etmək üçün bu YAML-dən istifadə edəcəyik.

Yuxarıdakı manifest base-valid.yaml və bu məqalənin digər manifestləri ilə tanış ola bilərsiniz Git depoları.

Manifest əsas vəzifəsi 5678-ci porta “Salam Dünya” mesajı ilə cavab vermək olan veb tətbiqini təsvir edir. O, aşağıdakı əmrlə yerləşdirilə bilər:

kubectl apply -f hello-world.yaml

Və beləliklə - işi yoxlayın:

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

İndi get http://localhost:8080 və tətbiqin işlədiyini təsdiqləyin. Ancaq ən yaxşı təcrübələrə əməl edirmi? yoxlayaq.

1. Kubeval

Kalbinde kubeval İdeya ondan ibarətdir ki, Kubernetes ilə hər hansı qarşılıqlı əlaqə onun REST API vasitəsilə baş verir. Başqa sözlə, verilmiş YAML-in ona uyğun olub olmadığını yoxlamaq üçün API sxemindən istifadə edə bilərsiniz. Bir nümunəyə baxaq.

Quraşdırma təlimatları kubeval layihə saytında mövcuddur.

Orijinal məqaləni yazarkən 0.15.0 versiyası mövcud idi.

Quraşdırıldıqdan sonra onu yuxarıdakı manifestlə qidalandıraq:

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

Uğurlu olarsa, kubeval çıxış kodu 0 ilə çıxacaq. Bunu aşağıdakı kimi yoxlaya bilərsiniz:

$ echo $?
0

İndi kubevalı fərqli bir manifestlə sınayaq:

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)

Problemi gözdən görə bilərsinizmi? Başlayaq:

$ 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 yoxlanılmır.

API versiyasını istifadə edərək yerləşdirmələr apps/v1, podun etiketinə uyğun gələn seçici daxil etməlidir. Yuxarıdakı manifest selektoru əhatə etmir, ona görə də kubeval xəta haqqında məlumat verdi və sıfırdan fərqli kodla çıxdı.

Etsəm nə olacaq görəsən kubectl apply -f bu manifestlə?

Yaxşı, cəhd edək:

$ 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ın xəbərdar etdiyi səhvdir. Seçici əlavə etməklə onu düzəldə bilərsiniz:

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 kimi vasitələrin üstünlüyü ondan ibarətdir ki, bu kimi səhvlər yerləşdirmə dövründə erkən tutula bilər.

Bundan əlavə, bu yoxlamalar klasterə giriş tələb etmir, onlar oflayn həyata keçirilə bilər.

Varsayılan olaraq, kubeval resursları ən son Kubernetes API sxemi ilə yoxlayır. Bununla belə, əksər hallarda xüsusi Kubernetes buraxılışını yoxlamalı ola bilərsiniz. Bu bayraqdan istifadə etməklə edilə bilər --kubernetes-version:

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

Nəzərə alın ki, versiya formatda göstərilməlidir Major.Minor.Patch.

Doğrulamanın dəstəkləndiyi versiyaların siyahısı üçün müraciət edin GitHub-da JSON sxemi, doğrulama üçün hansı kubeval istifadə edir. Əgər kubeval-ı oflayn işlətmək lazımdırsa, sxemləri yükləyin və bayraqdan istifadə edərək onların yerli yerini göstərin --schema-location.

Fərdi YAML fayllarına əlavə olaraq kubeval kataloqlar və stdin ilə də işləyə bilər.

Bundan əlavə, Kubeval asanlıqla CI boru kəmərinə inteqrasiya edir. Klasterə manifest göndərməzdən əvvəl testlər keçirmək istəyənlər kubevalın üç çıxış formatını dəstəklədiyini bilməkdən məmnun olacaqlar:

Sadə mətn;
JSON;
Hər şeyi sınayın Protokolu (TAP).

İstənilən növdə nəticələrin xülasəsini yaratmaq üçün formatların hər hansı biri çıxışın sonrakı təhlili üçün istifadə edilə bilər.

Kubevalın çatışmazlıqlarından biri odur ki, o, hazırda Xüsusi Resurs Təriflərinə (CRDs) uyğunluğu yoxlaya bilmir. Bununla belə, kubeval konfiqurasiya etmək mümkündür onlara məhəl qoyma.

Kubeval resursları yoxlamaq və qiymətləndirmək üçün əla vasitədir; Bununla belə, vurğulamaq lazımdır ki, testdən keçmək resursun ən yaxşı təcrübələrə uyğun olmasına zəmanət vermir.

Məsələn, etiketdən istifadə etməklə latest konteynerdə ən yaxşı təcrübələrə əməl etmir. Lakin kubeval bunu səhv hesab etmir və bildirmir. Yəni, belə YAML-nin yoxlanılması xəbərdarlıqsız başa çatacaq.

Bəs YAML-i qiymətləndirmək və etiket kimi pozuntuları müəyyən etmək istəyirsinizsə nə etməli latest? YAML faylını ən yaxşı təcrübələrlə necə yoxlaya bilərəm?

2. Kube-bal

Kube xal YAML manifestlərini təhlil edir və onları daxili testlərə qarşı qiymətləndirir. Bu testlər təhlükəsizlik qaydalarına və ən yaxşı təcrübələrə əsasən seçilir, məsələn:

Konteyneri kök kimi deyil.
Pod sağlamlıq yoxlamalarının mövcudluğu.
Resurslar üçün sorğu və məhdudiyyətlərin təyin edilməsi.

Test nəticələrinə əsasən üç nəticə verilir: OK, XƏBƏRDARLIQ и Kritik.

Kube-score-u onlayn olaraq sınaya və ya yerli olaraq quraşdıra bilərsiniz.

Orijinal məqaləni yazarkən kube-score-un ən son versiyası 1.7.0 idi.

Gəlin bunu manifestimizdə sınayaq 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 testlərindən keçir, kube isə aşağıdakı qüsurlara işarə edir:

Hazırlıq yoxlamaları konfiqurasiya edilməyib.
CPU resursları və yaddaş üçün heç bir sorğu və ya məhdudiyyət yoxdur.
Pod pozuntusu büdcələri müəyyən edilməyib.
Ayrılıq qaydaları yoxdur (anti-yaxınlıq) əlçatanlığı maksimuma çatdırmaq üçün.
Konteyner kök kimi işləyir.

Bunların hamısı Yerləşdirməni daha səmərəli və etibarlı etmək üçün aradan qaldırılmalı olan çatışmazlıqlar haqqında etibarlı məqamlardır.

Komanda kube-score bütün növ pozuntular daxil olmaqla, insan tərəfindən oxuna bilən formada məlumatları göstərir XƏBƏRDARLIQ и Kritik, inkişaf zamanı çox kömək edir.

Bu aləti CI boru kəməri daxilində istifadə etmək istəyənlər bayraqdan istifadə edərək daha sıxlaşdırılmış çıxışı təmin edə bilərlər --output-format ci (bu halda nəticə ilə testlər də göstərilir 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 kimi, kube-score uğursuz bir test olduqda sıfırdan fərqli çıxış kodu qaytarır Kritik. Siz həmçinin oxşar emal üçün aktivləşdirə bilərsiniz XƏBƏRDARLIQ.

Bundan əlavə, resursların müxtəlif API versiyalarına uyğunluğunu yoxlamaq mümkündür (kubevalda olduğu kimi). Bununla belə, bu məlumat kube-skorun özündə sərt kodlaşdırılıb: siz Kubernetes-in fərqli versiyasını seçə bilməzsiniz. Əgər siz klasterinizi təkmilləşdirmək niyyətindəsinizsə və ya K8-lərin müxtəlif versiyaları olan bir neçə klasteriniz varsa, bu məhdudiyyət böyük problem ola bilər.

Qeyd edin ki, artıq bir məsələ var bu fürsəti reallaşdırmaq təklifi ilə.

Kube-score haqqında ətraflı məlumatı burada tapa bilərsiniz rəsmi sayt.

Kube-score testləri ən yaxşı təcrübələri həyata keçirmək üçün əla vasitədir, lakin siz testə dəyişiklik etmək və ya öz qaydalarınızı əlavə etmək lazımdırsa nə etməli? Təəssüf ki, bunu etmək olmaz.

Kube-balı genişləndirilə bilməz: siz ona siyasətlər əlavə edə və ya onları tənzimləyə bilməzsiniz.

Əgər şirkət siyasətlərinə uyğunluğu yoxlamaq üçün fərdi testlər yazmalısınızsa, aşağıdakı dörd alətdən birini istifadə edə bilərsiniz: config-lint, copper, confest və ya polaris.

3. Config-lint

Config-lint YAML, JSON, Terraform, CSV konfiqurasiya faylları və Kubernetes manifestlərini yoxlamaq üçün bir vasitədir.

istifadə edərək quraşdıra bilərsiniz təlimatlar layihənin veb saytında.

Orijinal məqalənin yazıldığı anda hazırkı buraxılış 1.5.0-dır.

Config-lint-də Kubernetes manifestlərini yoxlamaq üçün daxili testlər yoxdur.

Hər hansı bir test aparmaq üçün müvafiq qaydalar yaratmalısınız. Onlar "qaydalar" adlanan YAML fayllarında yazılmışdır. (qaydalar toplusu), və aşağıdakı quruluşa malikdir:

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

(rule.yaml)

Gəlin bunu daha yaxından öyrənək:

Sahə type config-lint-in hansı növ konfiqurasiyadan istifadə edəcəyini müəyyən edir. K8s üçün bu, təzahür edir həmişə Kubernetes.
sahəsində files Faylların özlərinə əlavə olaraq, bir kataloq təyin edə bilərsiniz.
Sahə rules istifadəçi testlərini təyin etmək üçün nəzərdə tutulmuşdur.

Deyək ki, siz Yerləşdirmədəki şəkillərin həmişə etibarlı bir depodan endirilməsinə əmin olmaq istəyirsiniz. my-company.com/myapp:1.0. Belə bir yoxlamanı həyata keçirən konfiqurasiya qaydası belə görünür:

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

Hər bir qayda aşağıdakı xüsusiyyətlərə malik olmalıdır:

id — qaydanın unikal identifikatoru;
severity - Ola bilər XƏTAS, XƏBƏRDARLIQ и UYĞUN OLMAYIR;
message — qayda pozularsa, bu sətirin məzmunu göstərilir;
resource — bu qaydanın tətbiq olunduğu resursun növü;
assertions — bu resursla bağlı qiymətləndiriləcək şərtlərin siyahısı.

Yuxarıdakı qaydada assertion deyilən every bütün konteynerlərin Yerləşdirmədə olduğunu yoxlayır (key: spec.templates.spec.containers) etibarlı şəkillərdən istifadə edin (yəni my-company.com/).

Tam qaydalar dəsti belə görünür:

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)

Testi sınamaq üçün onu qeyd edək check_image_repo.yaml. Faylı yoxlayaq 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"
  }
]

Çek uğursuz oldu. İndi düzgün şəkil anbarı ilə aşağıdakı manifestə baxaq:

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)

Yuxarıdakı manifestlə eyni testi həyata keçiririk. Heç bir problem tapılmadı:

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

Config-lint, YAML DSL-dən istifadə edərək Kubernetes YAML manifestlərini yoxlamaq üçün öz testlərinizi yaratmağa imkan verən perspektivli çərçivədir.

Bəs sizə daha mürəkkəb məntiq və testlər lazımdırsa? YAML bunun üçün çox məhdud deyilmi? Tam proqramlaşdırma dilində testlər yarada bilsəniz nə olacaq?

4. Mis

Mis V2 xüsusi testlərdən (config-lint-ə bənzər) istifadə edərək manifestləri təsdiqləmək üçün çərçivədir.

Lakin testləri təsvir etmək üçün YAML-dən istifadə etməməsi ilə sonuncudan fərqlənir. Testlər əvəzinə JavaScript-də yazıla bilər. Mis kitabxananı bir neçə əsas alətlə təmin edir, bu, Kubernetes obyektləri haqqında məlumatları oxumağa və xətaları bildirməyə kömək edir.

Mis quraşdırma addımlarını burada tapa bilərsiniz rəsmi sənədlər.

2.0.1 orijinal məqalənin yazıldığı vaxt bu yardım proqramının ən son buraxılışıdır.

Config-lint kimi, Mis də daxili testlərə malik deyil. Birini yazaq. Yerləşdirmələrin yalnız kimi etibarlı depolardan konteyner şəkillərindən istifadə etdiyini yoxlamasına icazə verin my-company.com.

Fayl yaradın check_image_repo.js aşağıdakı məzmunla:

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

İndi manifestimizi sınamaq üçün base-valid.yaml, əmrindən istifadə edin 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

Aydındır ki, misin köməyi ilə daha mürəkkəb testlər həyata keçirə bilərsiniz - məsələn, Ingress manifestlərində domen adlarını yoxlamaq və ya imtiyazlı rejimdə işləyən podları rədd etmək.

Mis özündə müxtəlif faydalı funksiyalara malikdir:

DockerImage göstərilən giriş faylını oxuyur və aşağıdakı atributlara malik obyekt yaradır:
- name - şəklin adı,
- tag - şəkil etiketi,
- registry - şəkil reyestri,
- registry_url - protokol (https://) və şəkil reyestri,
- fqin — şəklin tam yeri.
Function findByName müəyyən bir növ üzrə resurs tapmağa kömək edir (kind) və adı (name) giriş faylından.
Function findByLabels müəyyən bir növdə resurs tapmağa kömək edir (kind) və etiketlər (labels).

Siz bütün mövcud xidmət funksiyalarına baxa bilərsiniz burada.

Varsayılan olaraq, bütün giriş YAML faylını dəyişənə yükləyir $$ və onu skript üçün əlçatan edir (jQuery təcrübəsi olanlar üçün tanış texnika).

Mis-in əsas üstünlüyü göz qabağındadır: xüsusi bir dil öyrənməyə ehtiyac yoxdur və siz öz testlərinizi yaratmaq üçün müxtəlif JavaScript funksiyalarından istifadə edə bilərsiniz, məsələn, sətir interpolasiyası, funksiyalar və s.

Onu da qeyd etmək lazımdır ki, Copper-ın hazırkı versiyası ES5 deyil, JavaScript mühərrikinin ES6 versiyası ilə işləyir.

Təfərrüatlar burada mövcuddur layihənin rəsmi saytı.

Bununla belə, əgər JavaScript-i həqiqətən sevmirsinizsə və sorğular yaratmaq və siyasətləri təsvir etmək üçün xüsusi olaraq hazırlanmış bir dilə üstünlük verirsinizsə, konfestə diqqət yetirməlisiniz.

5. Müsabiqə

Confest konfiqurasiya məlumatlarının sınaqdan keçirilməsi üçün çərçivədir. Kubernetes manifestlərini sınamaq/yoxlamaq üçün də uyğundur. Testlər xüsusi sorğu dili ilə təsvir edilir Rego.

Confest istifadə edərək quraşdıra bilərsiniz təlimatlarlayihənin saytında qeyd olunub.

Orijinal məqaləni yazarkən mövcud olan ən son versiya 0.18.2 idi.

Config-lint və mis kimi, confest heç bir daxili test olmadan gəlir. Gəlin bunu sınayaq və öz siyasətimizi yazaq. Əvvəlki nümunələrdə olduğu kimi, konteyner şəkillərinin etibarlı mənbədən götürülüb-götürülmədiyini yoxlayacağıq.

Kataloq yaradın conftest-checks, və orada adlı bir fayl var check_image_registry.rego aşağıdakı məzmunla:

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

İndi test edək base-valid.yaml vasitəsilə 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

Şəkillər etibarsız mənbədən gəldiyi üçün sınaq proqnozlaşdırıla bilər ki, uğursuz oldu.

Rego faylında bloku müəyyən edirik deny. Onun həqiqəti pozuntu hesab olunur. bloklar varsa deny bir neçə, confest onları bir-birindən asılı olmayaraq yoxlayır və bloklardan hər hansı birinin həqiqəti pozuntu kimi qəbul edilir.

Defolt çıxışa əlavə olaraq, confest JSON, TAP və cədvəl formatını dəstəkləyir - hesabatları mövcud CI boru kəmərinə daxil etmək lazımdırsa, son dərəcə faydalı xüsusiyyətdir. Bayraqdan istifadə edərək istədiyiniz formatı təyin edə bilərsiniz --output.

Siyasətlərin sazlanmasını asanlaşdırmaq üçün confest-in bayrağı var --trace. Konfestin göstərilən siyasət fayllarını necə təhlil etdiyinə dair bir iz çıxarır.

Müsabiqə siyasətləri artefakt kimi OCI (Open Container Initiative) reyestrlərində dərc oluna və paylaşıla bilər.

Komanda push и pull artefaktı dərc etməyə və ya uzaq reyestrdən mövcud artefaktı əldə etməyə imkan verir. Yaratdığımız siyasəti yerli Docker reyestrində dərc etməyə çalışaq conftest push.

Yerli Docker reyestrinizi işə salın:

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

Başqa bir terminalda əvvəllər yaratdığınız kataloqa keçin conftest-checks və aşağıdakı əmri yerinə yetirin:

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

Əmr uğurlu olarsa, belə bir mesaj görəcəksiniz:

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

İndi müvəqqəti qovluq yaradın və içindəki əmri işə salın conftest pull. Əvvəlki əmrlə yaradılmış paketi yükləyəcək:

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

Müvəqqəti kataloqda alt kataloq görünəcək policysiyasət faylımızı ehtiva edir:

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

Testlər birbaşa depodan aparıla bilər:

$ 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

Təəssüf ki, DockerHub hələ dəstəklənmir. Odur ki, istifadə edirsinizsə, özünüzü şanslı sayın Azure Konteyner Qeydiyyatı (ACR) və ya öz reyestriniz.

Artefakt formatı ilə eynidir Siyasət Agent paketlərini açın (OPA), mövcud OPA paketlərindən testlər aparmaq üçün konfestdən istifadə etməyə imkan verir.

Siyasət paylaşımı və konfestin digər xüsusiyyətləri haqqında ətraflı öyrənə bilərsiniz layihənin rəsmi saytı.

6. Polaris

Bu məqalədə müzakirə ediləcək son vasitə Polaris. (Onun keçən ilki elanı biz artıq tərcümə olunub - təqribən. tərcümə.)

Polaris bir klasterdə quraşdırıla bilər və ya əmr satırı rejimində istifadə edilə bilər. Təxmin etdiyiniz kimi, bu, Kubernetes manifestlərini statik təhlil etməyə imkan verir.

Komanda xətti rejimində işləyərkən təhlükəsizlik və ən yaxşı təcrübələr (kube-score-a bənzər) kimi sahələri əhatə edən daxili testlər mövcuddur. Bundan əlavə, siz öz testlərinizi yarada bilərsiniz (config-lint, copper və confest-də olduğu kimi).

Başqa sözlə, Polaris alətlərin hər iki kateqoriyasının üstünlüklərini birləşdirir: quraşdırılmış və xüsusi testlərlə.

Polaris-i komanda xətti rejimində quraşdırmaq üçün istifadə edin layihənin saytında təlimatlar.

Orijinal məqalənin yazılması zamanı 1.0.3 versiyası mövcuddur.

Quraşdırma tamamlandıqdan sonra manifestdə polaris işlədə bilərsiniz base-valid.yaml aşağıdakı əmrlə:

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

O, yerinə yetirilən testlərin və onların nəticələrinin ətraflı təsviri ilə JSON formatında sətir çıxaracaq. Çıxış aşağıdakı quruluşa sahib olacaq:

{
  "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": [
    /* длинный список */
  ]
}

Tam çıxış mövcuddur burada.

Kube-score kimi, Polaris də manifestin ən yaxşı təcrübələrə cavab vermədiyi sahələrdə problemləri müəyyən edir:

Podlar üçün sağlamlıq yoxlamaları yoxdur.
Konteyner şəkilləri üçün etiketlər göstərilməyib.
Konteyner kök kimi işləyir.
Yaddaş və CPU üçün sorğular və məhdudiyyətlər göstərilməyib.

Hər bir test, nəticələrindən asılı olaraq, kritiklik dərəcəsi ilə təyin olunur: xəbərdarlıq və ya təhlükə. Mövcud daxili testlər haqqında daha çox məlumat əldə etmək üçün müraciət edin sənədləşdirmə.

Təfərrüatlar lazım deyilsə, bayrağı təyin edə bilərsiniz --format score. Bu halda, Polaris 1-dən 100-ə qədər rəqəm çıxaracaq hesab (yəni qiymətləndirmə):

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

Hesab 100-ə nə qədər yaxındırsa, razılıq dərəcəsi bir o qədər yüksəkdir. Komandanın çıxış kodunu yoxlasanız polaris audit, 0-a bərabər olduğu məlum olur.

güc polaris audit Siz iki bayraqdan istifadə edərək sıfırdan fərqli kodla işi dayandıra bilərsiniz:

Bayraq --set-exit-code-below-score arqument kimi 1-100 aralığında həddi qiymət alır. Bu halda, xal həddən aşağı olarsa, komanda çıxış kodu 4 ilə çıxacaq. Müəyyən bir hədd dəyəriniz olduqda (məsələn, 75) bu çox faydalıdır və xal aşağı düşərsə, xəbərdarlıq almalısınız.
Bayraq --set-exit-code-on-danger təhlükə testlərindən biri uğursuz olarsa, əmrin kod 3 ilə uğursuz olmasına səbəb olacaq.

İndi gəlin şəklin etibarlı depodan götürülüb-götürülmədiyini yoxlayan fərdi test yaratmağa çalışaq. Xüsusi testlər YAML formatında müəyyən edilir və testin özü JSON Schema istifadə edərək təsvir edilir.

Aşağıdakı YAML kod parçası adlı yeni testi təsvir edir 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/.+$

Gəlin buna daha yaxından nəzər salaq:

successMessage — test uğurla başa çatarsa, bu sətir çap olunacaq;
failureMessage — uğursuzluq halında bu mesaj göstəriləcək;
category — kateqoriyalardan birini göstərir: Images, Health Checks, Security, Networking и Resources;
target--- hansı növ obyekti müəyyənləşdirir (spec) test tətbiq edilir. Mümkün dəyərlər: Container, Pod və ya Controller;
Testin özü obyektdə göstərilmişdir schema JSON sxemindən istifadə etməklə. Bu testdə əsas sözdür pattern şəkil mənbəyini tələb olunan ilə müqayisə etmək üçün istifadə olunur.

Yuxarıdakı testi yerinə yetirmək üçün aşağıdakı Polaris konfiqurasiyasını yaratmalısınız:

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)

Faylı təhlil edək:

sahəsində checks testlər və onların kritiklik səviyyəsi təyin edilir. Etibarsız mənbədən şəkil çəkildikdə xəbərdarlıq almaq arzuolunan olduğundan səviyyəni burada təyin edirik danger.
Testin özü checkImageRepo sonra obyektdə qeydiyyata alınır customChecks.

Faylı qeyd edin custom_check.yaml. İndi qaça bilərsiniz polaris audit doğrulama tələb edən YAML manifest ilə.

Gəlin manifestimizi sınaqdan keçirək base-valid.yaml:

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

Komanda polaris audit yalnız yuxarıda göstərilən istifadəçi testini keçirdi və uğursuz oldu.

Şəkili düzəltsəniz my-company.com/http-echo:1.0, Polaris uğurla tamamlanacaq. Dəyişiklikləri ehtiva edən manifest artıq hazırdır depolarmanifestdə əvvəlki əmri yoxlaya bilərsiniz image-valid-mycompany.yaml.

İndi sual yaranır: xüsusi testlərlə birlikdə daxili testləri necə aparmaq olar? Asanlıqla! Siz sadəcə olaraq konfiqurasiya faylına daxili test identifikatorlarını əlavə etməlisiniz. Nəticədə aşağıdakı formanı alacaq:

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)

Tam konfiqurasiya faylının nümunəsi mövcuddur burada.

Manifest yoxlayın base-valid.yamldaxili və xüsusi testlərdən istifadə edərək, əmrdən istifadə edə bilərsiniz:

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

Polaris daxili testləri fərdi testlərlə tamamlayır və bununla da hər iki dünyanın ən yaxşılarını birləşdirir.

Digər tərəfdən, Rego və ya JavaScript kimi daha güclü dillərdən istifadə edə bilməmək daha mürəkkəb testlərin yaradılmasına mane olan məhdudlaşdırıcı amil ola bilər.

Polaris haqqında ətraflı məlumatı burada əldə etmək olar layihə saytı.

Xülasə

Kubernetes YAML fayllarını yoxlamaq və qiymətləndirmək üçün bir çox vasitə mövcud olsa da, testlərin necə tərtib ediləcəyi və icra ediləcəyi barədə aydın anlayışa malik olmaq vacibdir.

Məsələn, bir boru kəmərindən keçən Kubernetes təzahürlərini götürsəniz, kubeval belə bir boru kəmərində ilk addım ola bilər.. O, obyekt təriflərinin Kubernetes API sxeminə uyğun olub-olmamasına nəzarət edəcək.

Belə bir baxış başa çatdıqdan sonra standart ən yaxşı təcrübələrə və xüsusi siyasətlərə uyğunluq kimi daha mürəkkəb testlərə keçə bilərsiniz. Kube-score və Polaris lazımlı olacağı yer budur.

Mürəkkəb tələbləri olan və testləri ətraflı şəkildə fərdiləşdirməyə ehtiyacı olanlar üçün mis, konfiqurasiya və konfest uyğun olacaq..

Confest və config-lint xüsusi testləri müəyyən etmək üçün YAML-dən istifadə edir və mis sizə tam proqramlaşdırma dilinə giriş imkanı verir və onu olduqca cəlbedici seçim edir.

Digər tərəfdən, bu vasitələrdən birini istifadə etməyə və buna görə də bütün testləri əl ilə yaratmağa dəyərmi, yoxsa Polaris-ə üstünlük verib ona yalnız lazım olanı əlavə etməyə dəyərmi? Bu suala aydın cavab yoxdur.

Aşağıdakı cədvəldə hər bir alətin qısa təsviri verilmişdir:

Alət
Məqsəd
Məhdudiyyətlər
İstifadəçi testləri

kubeval
YAML manifestlərini API sxeminin xüsusi versiyası ilə təsdiqləyir
CRD ilə işləmək mümkün deyil
Heç bir

kub bal
YAML təzahürlərini ən yaxşı təcrübələrə qarşı təhlil edir
Resursları yoxlamaq üçün Kubernetes API versiyanızı seçmək mümkün deyil
Heç bir

mis
YAML manifestləri üçün xüsusi JavaScript testləri yaratmaq üçün ümumi çərçivə
Daxili testlər yoxdur. Zəif sənədlər
Bəli

config-lint
YAML-ə daxil edilmiş domenə xas dildə testlər yaratmaq üçün ümumi çərçivə. Müxtəlif konfiqurasiya formatlarını dəstəkləyir (məsələn, Terraform)
Hazır testlər yoxdur. Daxili təsdiqləmələr və funksiyalar kifayət olmaya bilər
Bəli

yarış
Rego (xüsusi sorğu dili) istifadə edərək öz testlərinizi yaratmaq üçün çərçivə. OCI paketləri vasitəsilə siyasətlərin paylaşılmasına imkan verir
Daxili testlər yoxdur. Mən Reqonu öyrənməliyəm. Siyasətləri dərc edərkən Docker Hub dəstəklənmir
Bəli

Polaris
YAML standart ən yaxşı təcrübələrə qarşı təzahür edir. JSON Schema istifadə edərək öz testlərinizi yaratmağa imkan verir
JSON Şemasına əsaslanan test imkanları yetərli olmaya bilər
Bəli

Bu alətlər Kubernetes klasterinə girişə etibar etmədiyi üçün onları quraşdırmaq asandır. Onlar sizə mənbə fayllarını süzgəcdən keçirməyə və layihələrdə çəkmə sorğularının müəlliflərinə tez rəy bildirməyə imkan verir.

Tərcüməçidən PS

Bloqumuzda da oxuyun:

Mənbə: www.habr.com

Kubernetes YAML-ni ən yaxşı təcrübələrə və siyasətlərə uyğun yoxlayın