ProHoster > Blog > Administrazioa > Baliozkotu Kubernetes YAML praktika onen eta politiken arabera

Baliozkotu Kubernetes YAML praktika onen eta politiken arabera

Ohar. itzul.: K8s inguruneetarako YAML konfigurazio kopurua gero eta handiagoa denez, haien egiaztapen automatizatuaren beharra gero eta premiazkoago bihurtzen da. Berrikuspen honen egileak zeregin honetarako lehendik zeuden soluzioak hautatu ez ezik, Deployment ere erabili zuen adibide gisa nola funtzionatzen duten ikusteko. Oso informagarria izan da gai honetan interesa dutenentzat.

Baliozkotu Kubernetes YAML praktika onen eta politiken arabera

TL; DR: Artikulu honek sei tresna estatiko konparatzen ditu Kubernetes YAML fitxategiak praktika onen eta eskakizunekin balioztatzeko eta ebaluatzeko.

Kubernetesen lan-kargak normalean YAML dokumentuen moduan definitzen dira. YAMLren arazoetako bat manifestu fitxategien arteko mugak edo erlazioak zehazteko zailtasuna da.

Zer gertatuko da klusterrean zabaldutako irudi guztiak erregistro fidagarri batetik datozela ziurtatu behar badugu?

Nola ekidin dezaket PodDisruptionBudgets ez duten inplementazioak klusterera bidaltzea?

Proba estatikoen integrazioak garapen-fasean akatsak eta politika-urraketak identifikatzea ahalbidetzen du. Horrek baliabideen definizioak zuzenak eta seguruak izateko bermea handitzen du, eta ekoizpen-lan-kargak praktika onak jarraitzea litekeena da.

Kubernetes YAML fitxategi estatikoak ikuskatzeko ekosistema kategoria hauetan bana daiteke:

  • API baliozkotzaileak. Kategoria honetako tresnek YAML manifestua Kubernetes API zerbitzariaren eskakizunekin egiaztatzen dute.
  • Probatzaileak prest. Kategoria honetako tresnek prest dauden probak dituzte segurtasuna, praktika onak betetzea, etab.
  • Baliozkotzaile pertsonalizatuak. Kategoria honetako ordezkariek hainbat hizkuntzatan proba pertsonalizatuak sortzeko aukera ematen dute, adibidez, Rego eta Javascript.

Artikulu honetan sei tresna ezberdin deskribatu eta alderatuko ditugu:

  1. kubeval;
  2. kube-score;
  3. konfigurazio-lint;
  4. kobrea;
  5. lehiaketa;
  6. polaris.

Tira, has gaitezen!

Inplementazioak egiaztatzea

Tresnak konparatzen hasi aurretik, sor ditzagun probatzeko atzeko plano bat.

Beheko manifestuak hainbat akats eta jardunbide egokien ez-betetzea jasotzen ditu: horietako zenbat aurki ditzakezu?

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 hau tresna desberdinak alderatzeko erabiliko dugu.

Goiko manifestua base-valid.yaml eta artikulu honetako beste manifestuak atalean aurki daitezke Git biltegiak.

Manifestak web-aplikazio bat deskribatzen du, zeinaren zeregin nagusia "Kaixo Mundua" mezu batekin erantzutea 5678 atakarako. Komando honekin inplementa daiteke:

kubectl apply -f hello-world.yaml

Eta horrela - egiaztatu lana:

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

Orain joan http://localhost:8080 eta baieztatu aplikazioa funtzionatzen ari dela. Baina praktika onak jarraitzen al ditu? Egiazta dezagun.

1. Kubeval

Bihotzean kubeval Ideia da Kubernetesekin edozein interakzioa bere REST APIaren bidez gertatzen dela. Beste era batera esanda, API eskema bat erabil dezakezu YAML jakin bat harekin bat datorren egiaztatzeko. Ikus dezagun adibide bat.

Instalazio argibideak kubeval proiektuaren webgunean daude eskuragarri.

Jatorrizko artikulua idazteko unean, 0.15.0 bertsioa zegoen eskuragarri.

Instalatu ondoren, elikatu dezagun goiko manifestua:

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

Arrakasta izanez gero, kubeval 0 irteera-kodearekin irtengo da. Honela egiaztatu dezakezu:

$ echo $?
0

Proba dezagun orain kubeval manifestu ezberdin batekin:

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)

Arazoa begiz antzeman dezakezu? Abiarazi dezagun:

$ 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

Baliabidea ez da egiaztatzen ari.

Inplementazioak API bertsioa erabiliz apps/v1, podaren etiketarekin bat datorren hautatzailea sartu behar du. Goiko manifestuak ez du hautatzailea, beraz, kubeval-ek errore bat jakinarazi du eta zero ez den kode batekin irten da.

Nik galdetzen diot zer gertatuko den egiten badut kubectl apply -f manifestu honekin?

Tira, saiatu gaitezen:

$ 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

Hauxe da kubevalek ohartarazi zuen errorea. Hau konpon dezakezu hautatzaile bat gehituz:

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 bezalako tresnen abantaila da horrelako akatsak hedapen-zikloaren hasieran atzeman daitezkeela.

Gainera, egiaztapen hauek ez dute klustererako sarbidea behar; lineaz kanpo egin daitezke.

Lehenespenez, kubeval-ek baliabideak Kubernetes APIaren azken eskemarekin egiaztatzen ditu. Hala ere, kasu gehienetan Kubernetes bertsio zehatz batekin egiaztatu beharko duzu. Bandera erabiliz egin daiteke --kubernetes-version:

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

Kontuan izan bertsioa formatuan zehaztu behar dela Major.Minor.Patch.

Egiaztapena onartzen den bertsioen zerrenda ikusteko, kontsultatu JSON eskema GitHub-en, kubeval-ek baliozkotzeko erabiltzen duena. Kubeval lineaz kanpo exekutatu behar baduzu, deskargatu eskemak eta zehaztu tokiko kokapena bandera erabiliz --schema-location.

YAML fitxategi indibidualez gain, kubeval-ek direktorioekin eta stdinekin ere lan egin dezake.

Horrez gain, Kubeval erraz integratzen da CI kanalizazioan. Klusterera manifestuak bidali aurretik probak egin nahi dituztenak pozik egongo dira kubeval-ek hiru irteera formatu onartzen dituela jakitea:

  1. Testu arrunta;
  2. JSON;
  3. Test Anything Protokoloa (TAP).

Eta edozein formatu erabil daiteke irteeraren azterketa gehiago egiteko, nahi den motako emaitzen laburpena sortzeko.

Kubevalen eragozpenetako bat gaur egun ezin duela egiaztatu Baliabideen Definizio Pertsonalizatuak (CRD) betetzen diren. Hala ere, posible da kubeval konfiguratzea alde batera utzi.

Kubeval baliabideak egiaztatzeko eta ebaluatzeko tresna bikaina da; Hala ere, azpimarratu behar da proba gainditzeak ez duela bermatzen baliabideak praktika onak betetzen dituenik.

Adibidez, etiketa erabiliz latest edukiontzi batean ez ditu praktika onak jarraitzen. Hala ere, kubevalek ez du akatstzat hartzen eta ez du horren berri ematen. Hau da, YAML horren egiaztapena abisurik gabe amaituko da.

Baina zer gertatzen da YAML ebaluatu eta etiketa bezalako urraketak identifikatu nahi badituzu latest? Nola egiaztatzen dut YAML fitxategi bat praktika onenekin?

2. Kube-score

Kube-puntuazioa YAML manifestuak analizatzen ditu eta barneko proben arabera ebaluatzen ditu. Proba hauek segurtasun-jarraibideetan eta praktika onen arabera hautatzen dira, hala nola:

  • Ontzia ez root gisa exekutatzen.
  • Lekaren osasun egiaztapenen erabilgarritasuna.
  • Baliabideen eskaerak eta mugak ezartzea.

Proben emaitzen arabera, hiru emaitza ematen dira: OK, ABISUA ΠΈ CRITICAL.

Kube-score online proba dezakezu edo lokalean instalatu.

Jatorrizko artikulua idazteko unean, kube-score-ren azken bertsioa 1.7.0 zen.

Proba dezagun gure manifestuan 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-k kubeval probak gainditzen ditu, eta kube-score-k akats hauek adierazten ditu:

  • Prestakuntza-egiaztapenak ez daude konfiguratuta.
  • Ez dago PUZaren baliabideetarako eta memoriarako eskaerarik edo mugarik.
  • Ez dira zehazten ontzien etenaren aurrekontuak.
  • Ez dago bereizketa araurik (afinitatearen aurkakoa) erabilgarritasuna maximizatzeko.
  • Edukiontzia root gisa exekutatzen da.

Hauek guztiak baliozko puntuak dira Inplementazioa eraginkorragoa eta fidagarriagoa izan dadin konpondu behar diren gabeziei buruz.

Team kube-score informazioa gizakiek irakur daitekeen moduan erakusten du mota guztietako urraketak barne ABISUA ΠΈ CRITICAL, eta horrek asko laguntzen du garapenean.

Tresna hau CI kanalizazioan erabili nahi dutenek irteera konprimituagoa gaitu dezakete bandera erabiliz --output-format ci (kasu honetan, emaitza duten probak ere bistaratzen dira 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-en antzera, kube-score-k zero ez den irteera-kode bat itzultzen du huts egiten duen proba bat dagoenean CRITICAL. Antzeko prozesamendua ere gaitu dezakezu ABISUA.

Horrez gain, baliabideak egiaztatzeko aukera dago API bertsio desberdinak betetzen direla (kubeval-en bezala). Hala ere, informazio hori kube-score-n bertan kodetuta dago: ezin duzu Kubernetes-en beste bertsio bat hautatu. Muga hau arazo handia izan daiteke zure klusterra berritu nahi baduzu edo K8s-en bertsio desberdinak dituzten hainbat kluster badituzu.

Kontuan izan arazo bat dago jada aukera hau gauzatzeko proposamen batekin.

Kube-score-ri buruzko informazio gehiago hemen aurki daiteke webgune ofiziala.

Kube-score probak tresna bikainak dira praktika onak ezartzeko, baina zer gertatzen da proban aldaketak egin edo zure arauak gehitu behar badituzu? Ai, hau ezin da egin.

Kube-score ez da hedagarria: ezin dituzu politikak gehitu edo egokitu.

Enpresaren politikak betetzen direla egiaztatzeko proba pertsonalizatuak idatzi behar badituzu, lau tresna hauetako bat erabil dezakezu: config-lint, copper, conftest edo polaris.

3.Config-lint

Config-lint YAML, JSON, Terraform, CSV konfigurazio fitxategiak eta Kubernetes manifestuak baliozkotzeko tresna da.

Erabiliz instala dezakezu argibideak proiektuaren webgunean.

Jatorrizko artikulua idazten den unean uneko bertsioa 1.5.0 da.

Config-lint-ek ez du Kubernetes manifestuak baliozkotzeko proba integraturik.

Edozein proba egiteko, arau egokiak sortu behar dituzu. "arau multzoak" izeneko YAML fitxategietan idatzita daude (arauak), eta egitura hau dute:

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

(rule.yaml)

Azter dezagun zehatzago:

  • Field type konfig-lint-ek zer konfigurazio mota erabiliko duen zehazten du. K8s manifestetarako hau da beti Kubernetes.
  • eremuan files Fitxategiez gain, direktorio bat zehaztu dezakezu.
  • Field rules erabiltzaile-probak ezartzeko pentsatua.

Demagun ziurtatu nahi duzula Deployment-eko irudiak beti deskargatzen direla fidagarri den biltegitik, esaterako. my-company.com/myapp:1.0. Egiaztapen hori egiten duen konfigurazio-lint arau batek honela izango luke:

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

Arau bakoitzak ezaugarri hauek izan behar ditu:

  • id β€” arauaren identifikatzaile bakarra;
  • severity - Agian HUTSALDIA, ABISUA ΠΈ EZ_BETETZEA;
  • message β€” Arau bat urratzen bada, lerro honen edukia bistaratzen da;
  • resource β€” Arau hau zein baliabideri aplikatzen zaion;
  • assertions β€” Baliabide honi dagokionez ebaluatuko diren baldintzen zerrenda.

Goiko arauan assertion izeneko every edukiontzi guztiak hedapenean daudela egiaztatzen du (key: spec.templates.spec.containers) fidagarriak diren irudiak erabili (hau da, hasieratik my-company.com/).

Arau multzo osoa honelakoa da:

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)

Proba probatzeko, gorde dezagun honela check_image_repo.yaml. Egin dezagun egiaztapena fitxategia 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"
  }
]

Egiaztapenak huts egin du. Ikus dezagun hurrengo manifestua irudi-biltegi egokiarekin:

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)

Goiko manifestuarekin proba bera egiten dugu. Ez da arazorik aurkitu:

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

Config-lint esparru itxaropentsua da, eta zure probak sortzeko aukera ematen dizu Kubernetes YAML manifestuak YAML DSL erabiliz baliozkotzeko.

Baina zer gertatzen da logika eta proba konplexuagoak behar badituzu? Ez al da YAML mugatuegia horretarako? Zer gertatzen da probak programazio-lengoaia oso batean sortuko bazenitu?

4. Kobrea

Kobrea V2 Manifestuak baliozkotzeko markoa da proba pertsonalizatuak erabiliz (config-lint-en antzekoa).

Dena den, bigarrenarengandik desberdina da, ez duelako YAML erabiltzen probak deskribatzeko. Horren ordez, probak JavaScript-en idatz daitezke. Copper-ek liburutegi bat eskaintzen du oinarrizko hainbat tresnarekin, Kubernetes-eko objektuei buruzko informazioa irakurtzen eta erroreen berri ematen laguntzen dizuna.

Kobrea instalatzeko urratsak atalean aurki daitezke dokumentazio ofiziala.

2.0.1 erabilgarritasun honen azken bertsioa da jatorrizko artikulua idazteko unean.

Config-lint bezala, Copper-ek ez du barneko probarik. Idatz dezagun bat. Egiaztatu dezala inplementazioek edukiontzien irudiak soilik erabiltzen dituztela fidagarrien biltegietatik my-company.com.

Sortu fitxategi bat check_image_repo.js eduki honekin:

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

Orain gure manifestua probatzeko base-valid.yaml, erabili komandoa 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

Argi dago kobrearen laguntzaz proba konplexuagoak egin ditzakezula - adibidez, domeinu-izenak egiaztatzea Ingress manifestuetan edo modu pribilegiatuan exekutatzen diren pod-ak baztertzea.

Kobreak erabilgarritasun-funtzio ezberdinak ditu barnean:

  • DockerImage zehaztutako sarrera-fitxategia irakurtzen du eta atributu hauek dituen objektu bat sortzen du:
    • name - irudiaren izena,
    • tag - irudi etiketa,
    • registry - irudien erregistroa,
    • registry_url - protokoloa (https://) eta irudien erregistroa,
    • fqin β€” Irudiaren kokapen osoa.
  • Funtzioa findByName mota jakin baten arabera baliabide bat aurkitzen laguntzen du (kind) eta izena (name) sarrerako fitxategitik.
  • Funtzioa findByLabels Mota zehatz baten arabera baliabide bat aurkitzen laguntzen du (kind) eta etiketak (labels).

Eskuragarri dauden zerbitzu-funtzio guztiak ikus ditzakezu Hemen.

Lehenespenez, sarrerako YAML fitxategi osoa aldagai batean kargatzen du $$ eta scriptetarako eskuragarri jartzen du (jQuery esperientzia dutenentzat teknika ezaguna).

Copper-en abantaila nagusia begi-bistakoa da: ez duzu hizkuntza espezializatu bat menperatu behar eta JavaScript-en hainbat funtzio erabil ditzakezu zure probak sortzeko, hala nola kateen interpolazioa, funtzioak, etab.

Kontuan izan behar da, halaber, Copper-en egungo bertsioak JavaScript motorearen ES5 bertsioarekin funtzionatzen duela, ez ES6rekin.

Xehetasunak helbidean eskuragarri proiektuaren webgune ofiziala.

Hala ere, JavaScript ez bazaizu gustatzen eta kontsultak sortzeko eta politikak deskribatzeko bereziki diseinatutako hizkuntza nahiago baduzu, lehiaketari arreta jarri behar diozu.

5.Lehiaketa

Conftest konfigurazio datuak probatzeko esparru bat da. Kubernetesen manifestuak probatzeko/egiaztatzeko ere egokia. Probak kontsulta-lengoaia espezializatu bat erabiliz deskribatzen dira Errego.

Lehiaketa erabiliz instala dezakezu argibideakproiektuaren webgunean zerrendatuta.

Jatorrizko artikulua idazteko unean, eskuragarri zegoen azken bertsioa 0.18.2 zen.

Config-lint eta kobrearen antzera, lehiaketa barneko probarik gabe dator. Proba dezagun eta idatzi gure politika. Aurreko adibideetan bezala, edukiontzien irudiak iturri fidagarri batetik hartutakoak diren egiaztatuko dugu.

Sortu direktorio bat conftest-checks, eta bertan izeneko fitxategi bat dago check_image_registry.rego eduki honekin:

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

Orain proba dezagun base-valid.yaml bidez 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

Probak huts egin zuen, irudiak konfiantzarik gabeko iturri batetik zetozelako.

Rego fitxategian blokea definitzen dugu deny. Bere egia urraketatzat hartzen da. Blokeak bada deny hainbat, lehiaketak elkarrengandik independentean egiaztatzen ditu, eta blokeetako edozein egia urraketa gisa hartzen da.

Irteera lehenetsiaz gain, lehiaketak JSON, TAP eta taula formatuak onartzen ditu - funtzio oso erabilgarria da txostenak lehendik dagoen CI kanalizazio batean txertatu behar badituzu. Bandera erabiliz nahi duzun formatua ezar dezakezu --output.

Politikak arazketa errazteko, lehiaketak bandera bat du --trace. Conftest-ek zehaztutako politika-fitxategiak aztertzen dituenaren arrastoa ematen du.

Lehiaketaren gidalerroak OCI (Open Container Initiative) erregistroetan argitaratu eta parteka daitezke artefaktu gisa.

ΠšΠΎΠΌΠ°Π½Π΄Ρ‹ push ΠΈ pull artefaktu bat argitaratzeko edo lehendik dagoen artefaktu bat berreskuratzeko aukera ematen dizu urruneko erregistro batetik. Saia gaitezen sortu dugun politika tokiko Docker erregistroan argitaratzen erabiliz conftest push.

Hasi zure tokiko Docker erregistroa:

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

Beste terminal batean, joan lehenago sortu duzun direktoriora conftest-checks eta exekutatu komando hau:

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

Komandoa arrakastatsua izan bada, honelako mezu bat ikusiko duzu:

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

Orain sortu aldi baterako direktorio bat eta exekutatu komandoa bertan conftest pull. Aurreko komandoak sortutako paketea deskargatuko du:

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

Behin-behineko direktorioan azpidirektorio bat agertuko da policygure politika-fitxategia daukana:

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

Probak zuzenean exekutatu daitezke biltegitik:

$ 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

Zoritxarrez, DockerHub oraindik ez dago onartzen. Beraz, kontuan hartu zortea erabiltzen baduzu Azure Container Erregistroa (ACR) edo zure erregistroa.

Artefaktuaren formatua bera da Ireki Policy Agent paketeak (OPA), lehendik dauden OPA paketeetatik probak egiteko lehiaketa erabiltzeko aukera ematen duena.

Politika partekatzeari eta lehiaketaren beste eginbideei buruzko informazio gehiago aurki dezakezu hemen proiektuaren webgune ofiziala.

6. Polariak

Artikulu honetan eztabaidatuko den azken tresna da Polaris. (Bere iazko iragarkia dugu dagoeneko itzulita - gutxi gorabehera. itzulpena)

Polaris kluster batean instalatu daiteke edo komando lerroko moduan erabil daiteke. Asmatu zenuten bezala, Kubernetesen manifestuak estatikoki aztertzeko aukera ematen du.

Komando-lerroko moduan exekutatzen ari zarenean, barne-probak eskuragarri daude segurtasuna eta jardunbide egokiak (kube-score-ren antzekoak) arloak estaltzen dituztenak. Horrez gain, zure probak sor ditzakezu (config-lint, copper eta conftest-en bezala).

Beste era batera esanda, Polaris-ek bi tresnen kategorien onurak konbinatzen ditu: proba integratuak eta pertsonalizatuak.

Polaris komando-lerroko moduan instalatzeko, erabili argibideak proiektuaren webgunean.

Jatorrizko artikulua idazteko unean, 1.0.3 bertsioa dago eskuragarri.

Instalazioa amaitutakoan, polaris exekutatu dezakezu manifestuan base-valid.yaml komando honekin:

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

JSON formatuan kate bat aterako du egindako proben eta haien emaitzen deskribapen zehatzarekin. Irteerak egitura hau izango du:

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

Irteera osoa eskuragarri Hemen.

Kube-score-k bezala, Polaris-ek manifestuak praktika onenak betetzen ez dituen eremuetako arazoak identifikatzen ditu:

  • Ez dago osasun-kontrolik leketarako.
  • Edukiontzien irudietarako etiketak ez daude zehaztuta.
  • Edukiontzia root gisa exekutatzen da.
  • Memoria eta CPUrako eskaerak eta mugak ez dira zehazten.

Proba bakoitzari, bere emaitzen arabera, kritikotasun maila bat esleitzen zaio: abisua edo arriskuan. Eskuragarri dauden integratutako probei buruz gehiago jakiteko, kontsultatu dokumentazioa.

Xehetasunak behar ez badira, bandera zehaztu dezakezu --format score. Kasu honetan, Polaris-ek 1 eta 100 - bitarteko zenbaki bat aterako du puntuazioa (hau da, ebaluazioa):

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

Puntuazioa zenbat eta 100etik gertuago egon, orduan eta adostasun maila handiagoa izango da. Komandoaren irteera kodea egiaztatzen baduzu polaris audit, 0-ren berdina dela ematen du.

Indarra polaris audit Zero ez den kode batekin lana amaitu dezakezu bi bandera erabiliz:

  • bandera --set-exit-code-below-score argumentu gisa 1-100 tarteko atalase-balioa hartzen du. Kasu honetan, komandoa 4 irteera kodearekin aterako da puntuazioa atalasearen azpitik badago. Hau oso erabilgarria da atalase-balio jakin bat duzunean (esan 75) eta puntuazioa beherago jaisten bada alerta bat jaso behar duzunean.
  • bandera --set-exit-code-on-danger komandoak 3 kodearekin huts egitea eragingo du arrisku-probaren batek huts egiten badu.

Orain saia gaitezen irudia biltegi fidagarri batetik hartu den egiaztatzen duen proba pertsonalizatu bat sortzen. Proba pertsonalizatuak YAML formatuan zehazten dira, eta proba bera JSON eskema erabiliz deskribatzen da.

Ondorengo YAML kode zatiak izeneko proba berri bat deskribatzen du 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/.+$

Ikus dezagun hurbilagotik:

  • successMessage β€” lerro hau inprimatuko da proba behar bezala amaitzen bada;
  • failureMessage β€” mezu hau hutsegite kasuan erakutsiko da;
  • category β€” Kategorietako bat adierazten du: Images, Health Checks, Security, Networking ΠΈ Resources;
  • target--- zer objektu mota zehazten du (spec) proba aplikatzen da. Balio posibleak: Container, Pod edo Controller;
  • Proba bera objektuan zehazten da schema JSON eskema erabiliz. Proba honetako hitz gakoa da pattern irudiaren iturria behar denarekin alderatzeko erabiltzen da.

Goiko proba egiteko, Polaris konfigurazio hau sortu behar duzu:

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)

Analisi dezagun fitxategia:

  • eremuan checks probak eta haien kritikotasun maila agintzen dira. Irudi bat fidagarria ez den iturri batetik ateratzen denean abisua jasotzea komeni denez, hemen ezarri dugu maila. danger.
  • Proba bera checkImageRepo gero objektuan erregistratu customChecks.

Gorde fitxategia honela custom_check.yaml. Orain korrika egin dezakezu polaris audit egiaztatzea eskatzen duen YAML manifestu batekin.

Proba dezagun gure manifestua base-valid.yaml:

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

Team polaris audit Goian zehaztutako erabiltzaile-proba bakarrik egin zuen eta huts egin zuen.

Irudia konpontzen baduzu my-company.com/http-echo:1.0, Polaris arrakastaz osatuko da. Dagoeneko sartuta dago aldaketak dituen manifestua biltegiakberaz, aurreko komandoa egiaztatu dezakezu manifestuan image-valid-mycompany.yaml.

Orain galdera sortzen da: nola exekutatu barneko probak pertsonalizatuekin batera? Erraz! Konfigurazio-fitxategian integratutako proba-identifikatzaileak gehitu besterik ez duzu behar. Ondorioz, forma hau hartuko du:

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)

Konfigurazio fitxategi oso baten adibide bat dago eskuragarri Hemen.

Egiaztatu manifestua base-valid.yamlproba integratuak eta pertsonalizatuak erabiliz, komandoa erabil dezakezu:

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

Polaris-ek barneko probak pertsonalizatuekin osatzen ditu, horrela bi munduetako onena konbinatuz.

Bestalde, Rego edo JavaScript bezalako hizkuntza indartsuagoak erabiltzeko ezintasuna faktore mugatzaile bat izan daiteke proba sofistikatuagoak sortzea eragozten duena.

Polaris-i buruzko informazio gehiago hemen dago eskuragarri proiektuaren webgunea.

Laburpena

Kubernetes YAML fitxategiak ikuskatzeko eta ebaluatzeko tresna asko dauden arren, garrantzitsua da probak nola diseinatu eta gauzatuko diren argi ulertzea.

Esate baterako, Kubernetes-en manifestuak kanalizazio batetik igarotzen badituzu, kubeval izan daiteke kanalizazio baten lehen urratsa. Objektuen definizioak Kubernetes API eskemarekin bat datozen ala ez kontrolatuko luke.

Berrikuspen hori amaitutakoan, proba sofistikatuagoetara pasa daiteke, hala nola, praktika onen estandarrak eta politika zehatzak betetzea. Hau da kube-score eta Polaris ondo etorriko lirateke.

Baldintza konplexuak dituztenentzat eta probak xehetasunez pertsonalizatu behar dituztenentzat, kobrea, konfig-lint eta lehiaketa egokiak lirateke..

Conftest-ek eta config-lint-ek YAML erabiltzen dute proba pertsonalizatuak definitzeko, eta kobreak programazio-lengoaia oso baterako sarbidea ematen dizu, nahiko aukera erakargarria bihurtuz.

Bestalde, merezi al du tresna horietako bat erabiltzeak eta, beraz, proba guztiak eskuz sortzea, ala Polaris hobestea eta horri behar dena soilik gehitzea? Ez dago galdera honi erantzun argirik.

Beheko taulak tresna bakoitzaren deskribapen laburra eskaintzen du:

Tool
patu
Mugak
Erabiltzaileen probak

kubeval
YAML manifestuak API eskemaren bertsio zehatz baten aurka balioztatzen ditu
Ezin da CRDrekin lan egin
No

kube-score
YAML manifestuak praktika onen aurka aztertzen ditu
Ezin da hautatu Kubernetes APIaren bertsioa baliabideak egiaztatzeko
No

kobrea
YAML manifestuetarako JavaScript proba pertsonalizatuak sortzeko esparru orokorra
Ez dago barneko probarik. Dokumentazio eskasa
Bai

konfigurazio-lint
YAML-n txertatutako domeinu espezifikoko hizkuntza batean probak sortzeko esparru orokorra. Hainbat konfigurazio formatu onartzen ditu (adibidez, Terraform)
Ez dago prest egindako probarik. Baliteke integratutako baieztapenak eta funtzioak nahikoak ez izatea
Bai

lehiaketa
Rego (kontsulta-lengoaia espezializatua) erabiliz zure probak sortzeko esparrua. Politikak partekatzeko aukera ematen du OCI sorten bidez
Ez dago barneko probarik. Rego ikasi behar dut. Docker Hub ez da onartzen politikak argitaratzerakoan
Bai

Polaris
YAML manifestuak praktika onen estandarren aurka berrikusten ditu. JSON eskema erabiliz zure probak sortzeko aukera ematen dizu
Baliteke JSON eskeman oinarritutako proba-gaitasunak nahikoak ez izatea
Bai

Tresna hauek Kubernetes klustererako sarbidean oinarritzen ez direnez, erraz instalatzen dira. Iturburu-fitxategiak iragazteko eta proiektuetako tira-eskaeren egileei feedback azkarra emateko aukera ematen dute.

PS itzultzailetik

Irakurri ere gure blogean:

Iturria: www.habr.com

Gehitu iruzkin berria