ProHoster > Օրագիր > Վարչակազմը > Վավերացրեք Kubernetes YAML-ը լավագույն փորձի և քաղաքականության դեմ

Վավերացրեք Kubernetes YAML-ը լավագույն փորձի և քաղաքականության դեմ

Նշում. թարգմ.K8s միջավայրերի համար YAML կոնֆիգուրացիաների աճող թվով, դրանց ավտոմատացված ստուգման անհրաժեշտությունը դառնում է ավելի ու ավելի հրատապ: Այս վերանայման հեղինակը ոչ միայն ընտրել է առկա լուծումներն այս առաջադրանքի համար, այլ նաև օգտագործել է Deployment-ը որպես օրինակ՝ տեսնելու, թե ինչպես են դրանք աշխատում: Պարզվեց, որ շատ ինֆորմատիվ էր այս թեմայով հետաքրքրվողների համար։

Վավերացրեք Kubernetes YAML-ը լավագույն փորձի և քաղաքականության դեմ

TL. DRԱյս հոդվածը համեմատում է վեց ստատիկ գործիքներ՝ Kubernetes YAML ֆայլերը վավերացնելու և գնահատելու լավագույն փորձի և պահանջների համեմատ:

Kubernetes-ի ծանրաբեռնվածությունը սովորաբար սահմանվում է YAML փաստաթղթերի տեսքով: YAML-ի հետ կապված խնդիրներից մեկը մանիֆեստի ֆայլերի միջև սահմանափակումներ կամ հարաբերություններ նշելու դժվարությունն է:

Ի՞նչ անել, եթե մենք պետք է համոզվենք, որ կլաստերի վրա տեղադրված բոլոր պատկերները գալիս են վստահելի ռեեստրից:

Ինչպե՞ս կարող եմ կանխել այն տեղակայումները, որոնք չունեն PodDisruptionBudgets, ուղարկվել կլաստերին:

Ստատիկ թեստավորման ինտեգրումը թույլ է տալիս բացահայտել սխալներն ու քաղաքականության խախտումները մշակման փուլում: Սա մեծացնում է երաշխիքը, որ ռեսուրսների սահմանումները ճիշտ են և ապահով, և ավելի հավանական է դարձնում, որ արտադրական ծանրաբեռնվածությունը կհետևի լավագույն փորձին:

Kubernetes ստատիկ YAML ֆայլերի ստուգման էկոհամակարգը կարելի է բաժանել հետևյալ կատեգորիաների.

  • API վավերացնողներ. Այս կատեգորիայի գործիքները ստուգում են YAML մանիֆեստը Kubernetes API սերվերի պահանջներին համապատասխան:
  • Պատրաստ փորձարկիչներ. Այս կատեգորիայի գործիքները գալիս են անվտանգության, լավագույն փորձին համապատասխանության համար պատրաստի թեստերով և այլն:
  • Պատվերով վավերացնողներ. Այս կատեգորիայի ներկայացուցիչները թույլ են տալիս ստեղծել հատուկ թեստեր տարբեր լեզուներով, օրինակ՝ Rego և Javascript:

Այս հոդվածում մենք նկարագրելու և համեմատելու ենք վեց տարբեր գործիքներ.

  1. կուբեվալ;
  2. kube-score;
  3. config-lint;
  4. պղինձ;
  5. մրցույթ;
  6. Բեւեռային

Դե, եկեք սկսենք:

Տեղակայումների ստուգում

Նախքան գործիքների համեմատությունը սկսելը, եկեք ստեղծենք որոշակի ֆոն, որի վրա դրանք փորձարկելու ենք:

Ստորև բերված մանիֆեստը պարունակում է մի շարք սխալներ և լավագույն փորձին չհամապատասխանելը. դրանցից քանի՞սը կարող եք գտնել:

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

(base-valid.yaml)

Մենք կօգտագործենք այս YAML-ը՝ տարբեր գործիքներ համեմատելու համար:

Վերոնշյալ մանիֆեստը base-valid.yaml և այս հոդվածի այլ մանիֆեստներ կարելի է գտնել այստեղ Git պահոցներ.

Մանիֆեստը նկարագրում է վեբ հավելված, որի հիմնական խնդիրն է պատասխանել «Բարև աշխարհ» հաղորդագրությունով 5678 նավահանգիստին: Այն կարող է տեղակայվել հետևյալ հրամանով.

kubectl apply -f hello-world.yaml

Եվ այսպես, ստուգեք աշխատանքը.

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

Հիմա գնացեք http://localhost:8080 և հաստատեք, որ հավելվածն աշխատում է: Բայց արդյո՞ք այն հետևում է լավագույն փորձին: Եկեք ստուգենք.

1. Կուբեվալ

Սրտում կուբեվալ Գաղափարն այն է, որ Kubernetes-ի հետ ցանկացած փոխազդեցություն տեղի է ունենում նրա REST API-ի միջոցով: Այլ կերպ ասած, դուք կարող եք օգտագործել API սխեման՝ ստուգելու համար, թե արդյոք տվյալ YAML-ը համապատասխանում է դրան: Դիտարկենք մի օրինակ։

Տեղադրման հրահանգներ kubeval-ը հասանելի է նախագծի կայքում:

Բնօրինակ հոդվածը գրելու պահին հասանելի էր 0.15.0 տարբերակը։

Տեղադրվելուց հետո եկեք այն կերակրենք վերը նշված մանիֆեստով.

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

Եթե ​​հաջողվի, kubeval-ը դուրս կգա 0 ելքի կոդով: Կարող եք ստուգել այն հետևյալ կերպ.

$ echo $?
0

Եկեք հիմա փորձենք kubeval-ը այլ մանիֆեստով.

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

(kubeval-invalid.yaml)

Կարո՞ղ եք նկատել խնդիրը աչքով: Եկեք գործարկենք.

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

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

Ռեսուրսը չի ստուգվում:

Տեղակայումներ՝ օգտագործելով API տարբերակը apps/v1, պետք է ներառի ընտրիչ, որը համապատասխանում է պատի պիտակին: Վերևի մանիֆեստը չի ներառում ընտրիչը, ուստի kubeval-ը հայտնել է սխալի մասին և դուրս է եկել ոչ զրոյական կոդով:

Հետաքրքիր է, թե ինչ կլինի, եթե անեմ kubectl apply -f այս մանիֆեստով?

Դե, եկեք փորձենք.

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

Սա հենց այն սխալն է, որի մասին նախազգուշացրել է Կուբեվալը։ Դուք կարող եք շտկել այն՝ ավելացնելով ընտրիչ.

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

(base-valid.yaml)

Kubeval-ի նման գործիքների առավելությունն այն է, որ նման սխալները կարող են հայտնաբերվել տեղակայման ցիկլի սկզբում:

Բացի այդ, այս ստուգումները չեն պահանջում մուտք դեպի կլաստեր, դրանք կարող են իրականացվել անցանց:

Լռելյայնորեն, kubeval-ը ստուգում է ռեսուրսները վերջին Kubernetes API սխեմայի համեմատ: Այնուամենայնիվ, շատ դեպքերում ձեզ հարկավոր է ստուգել Kubernetes-ի հատուկ թողարկումը: Դա կարելի է անել՝ օգտագործելով դրոշը --kubernetes-version:

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

Խնդրում ենք նկատի ունենալ, որ տարբերակը պետք է նշված լինի ձևաչափով Major.Minor.Patch.

Այն տարբերակների ցանկի համար, որոնց համար հաստատումը աջակցվում է, խնդրում ենք դիմել JSON սխեման GitHub-ում, որը kubeval-ն օգտագործում է վավերացման համար։ Եթե ​​Ձեզ անհրաժեշտ է գործարկել kubeval-ը անցանց, ներբեռնեք սխեմաները և նշեք դրանց տեղական գտնվելու վայրը՝ օգտագործելով դրոշը --schema-location.

Բացի անհատական ​​YAML ֆայլերից, kubeval-ը կարող է աշխատել նաև դիրեկտորիաների և stdin-ի հետ:

Բացի այդ, Kubeval-ը հեշտությամբ ինտեգրվում է CI խողովակաշարին: Նրանք, ովքեր ցանկանում են թեստեր կատարել նախքան մանիֆեստները կլաստեր ուղարկելը, ուրախ կլինեն իմանալ, որ kubeval-ն աջակցում է երեք ելքային ձևաչափեր.

  1. Պարզ տեքստ;
  2. JSON;
  3. Test Anything Protocol (TAP):

Եվ ցանկացած ձևաչափ կարող է օգտագործվել ելքի հետագա վերլուծության համար՝ ցանկալի տեսակի արդյունքների ամփոփում ստեղծելու համար:

Kubeval-ի թերություններից մեկն այն է, որ այն ներկայումս չի կարող ստուգել համապատասխանությունը Պատվերով ռեսուրսների սահմանումներին (CRD): Այնուամենայնիվ, հնարավոր է կարգավորել kubeval-ը անտեսել դրանք.

Kubeval-ը հիանալի գործիք է ռեսուրսները ստուգելու և գնահատելու համար. Այնուամենայնիվ, պետք է ընդգծել, որ թեստն անցնելը չի ​​երաշխավորում, որ ռեսուրսը համապատասխանում է լավագույն փորձին:

Օրինակ՝ օգտագործելով պիտակը latest կոնտեյներով չի հետևում լավագույն փորձին: Այնուամենայնիվ, kubeval-ը սա սխալ չի համարում և չի հայտնում: Այսինքն, նման YAML-ի ստուգումը կավարտվի առանց նախազգուշացման:

Բայց ինչ, եթե ցանկանում եք գնահատել YAML-ը և բացահայտել պիտակի նման խախտումները latest? Ինչպե՞ս կարող եմ ստուգել YAML ֆայլը լավագույն փորձի դեմ:

2. Կուբե-սկոր

Kube-score վերլուծում է YAML-ի դրսևորումները և գնահատում դրանք ներկառուցված թեստերի համեմատ: Այս թեստերն ընտրվում են անվտանգության ուղեցույցների և լավագույն փորձի հիման վրա, ինչպիսիք են՝

  • Աշխատում է բեռնարկղը ոչ որպես արմատ:
  • Պոդերի առողջության ստուգումների առկայությունը:
  • Ռեսուրսների հարցումների և սահմանափակումների սահմանում:

Թեստի արդյունքների հիման վրա տրվում է երեք արդյունք. OK, ԶԳՈՒՇԱՑՈՒՄ и ՔՐԻՏԱԼ.

Դուք կարող եք փորձել Kube-score առցանց կամ տեղադրել այն տեղական:

Բնօրինակ հոդվածը գրելու պահին kube-score-ի վերջին տարբերակը 1.7.0 էր։

Եկեք փորձենք դա մեր մանիֆեստում base-valid.yaml:

$ kube-score score base-valid.yaml

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

YAML-ն անցնում է kubeval թեստերը, մինչդեռ kube-score-ը մատնանշում է հետևյալ թերությունները.

  • Պատրաստության ստուգումները կազմաձևված չեն:
  • Պրոցեսորի ռեսուրսների և հիշողության հարցումներ կամ սահմանափակումներ չկան:
  • Պոդի խափանումների բյուջեները նշված չեն:
  • Բաժանման կանոններ չկան (հակամերձություն) հասանելիությունը առավելագույնի հասցնելու համար:
  • Բեռնարկղը աշխատում է որպես արմատ:

Սրանք բոլորը վավեր կետեր են թերությունների վերաբերյալ, որոնք պետք է շտկվեն՝ տեղակայումն ավելի արդյունավետ և հուսալի դարձնելու համար:

Թիմ kube-score ցուցադրում է տեղեկատվությունը մարդու համար ընթեռնելի ձևով, ներառյալ բոլոր տեսակի խախտումները ԶԳՈՒՇԱՑՈՒՄ и ՔՐԻՏԱԼ, որը շատ է օգնում զարգացման ընթացքում։

Նրանք, ովքեր ցանկանում են օգտագործել այս գործիքը CI խողովակաշարում, կարող են թույլ տալ ավելի սեղմված ելք՝ օգտագործելով դրոշը --output-format ci (այս դեպքում ցուցադրվում են նաև արդյունքներով թեստեր OK):

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

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

Kubeval-ի նման, kube-score-ը վերադարձնում է ոչ զրոյական ելքի կոդը, երբ կա փորձարկում, որը ձախողվում է ՔՐԻՏԱԼ. Կարող եք նաև միացնել նմանատիպ մշակումը ԶԳՈՒՇԱՑՈՒՄ.

Բացի այդ, հնարավոր է ստուգել ռեսուրսները API-ի տարբեր տարբերակների համապատասխանության համար (ինչպես kubeval-ում): Այնուամենայնիվ, այս տեղեկատվությունը կոշտ կոդավորված է հենց kube-score-ում. դուք չեք կարող ընտրել Kubernetes-ի այլ տարբերակ: Այս սահմանափակումը կարող է մեծ խնդիր լինել, եթե դուք մտադիր եք թարմացնել ձեր կլաստերը կամ եթե ունեք բազմաթիվ կլաստերներ՝ K8-ի տարբեր տարբերակներով:

Խնդրում ենք նկատի ունենալ, որ արդեն խնդիր կա այս հնարավորությունն իրացնելու առաջարկով։

Kube-score-ի մասին լրացուցիչ տեղեկություններ կարելի է գտնել այստեղ պաշտոնական կայքը.

Kube-score թեստերը հիանալի գործիք են լավագույն փորձի իրականացման համար, բայց ի՞նչ, եթե ձեզ անհրաժեշտ է փոփոխություններ կատարել թեստում կամ ավելացնել ձեր սեփական կանոնները: Ավաղ, դա հնարավոր չէ անել։

Kube-score-ը ընդարձակելի չէ. դուք չեք կարող դրան կանոններ ավելացնել կամ հարմարեցնել դրանք:

Եթե ​​Ձեզ անհրաժեշտ է գրել անհատական ​​թեստեր՝ ստուգելու ընկերության քաղաքականության համապատասխանությունը, կարող եք օգտագործել հետևյալ չորս գործիքներից մեկը՝ config-lint, copper, confest կամ polaris:

3.Config-lint

Config-lint-ը YAML, JSON, Terraform, CSV կազմաձևման ֆայլերի և Kubernetes մանիֆեստների վավերացման գործիք է:

Դուք կարող եք տեղադրել այն օգտագործելով հրահանգներ ծրագրի կայքում:

Ընթացիկ թողարկումը բնօրինակ հոդվածը գրելու պահին 1.5.0 է:

Config-lint-ը չունի ներկառուցված թեստեր Kubernetes մանիֆեստները վավերացնելու համար:

Ցանկացած թեստեր անցկացնելու համար անհրաժեշտ է ստեղծել համապատասխան կանոններ։ Դրանք գրված են YAML ֆայլերում, որոնք կոչվում են «կանոնակարգեր» (կանոնակարգեր)և ունեն հետևյալ կառուցվածքը.

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

(rule.yaml)

Եկեք ավելի մանրամասն ուսումնասիրենք.

  • Դաշտ type նշում է, թե ինչ տեսակի կոնֆիգուրացիա կօգտագործի config-lint: K8s դրսևորումների համար սա է միշտ Kubernetes.
  • Ի դաշտում files Բացի բուն ֆայլերից, դուք կարող եք նշել գրացուցակ:
  • Դաշտ rules նախատեսված է օգտագործողի թեստերը սահմանելու համար:

Ենթադրենք, ուզում եք համոզվել, որ Deployment-ի պատկերները միշտ ներբեռնվում են վստահելի պահոցից, ինչպիսին է. my-company.com/myapp:1.0. Config-lint կանոնը, որն իրականացնում է նման ստուգում, կունենա հետևյալ տեսքը.

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

(rule-trusted-repo.yaml)

Յուրաքանչյուր կանոն պետք է ունենա հետևյալ հատկանիշները.

  • id — կանոնի եզակի նույնացուցիչ.
  • severity - Միգուցե ՁԱԽՏՈՒՄ, ԶԳՈՒՇԱՑՈՒՄ и ԱՆՀԱՄԱՊԱՏԱՍԽԱՆԱԿԱՆ;
  • message — եթե կանոնը խախտվում է, ցուցադրվում է այս տողի բովանդակությունը.
  • resource - ռեսուրսի տեսակը, որի վրա կիրառվում է այս կանոնը.
  • assertions — պայմանների ցանկ, որոնք կգնահատվեն այս ռեսուրսի հետ կապված:

Վերը նշված կանոնում assertion անվանել every ստուգում է, որ բոլոր կոնտեյներները տեղակայման մեջ են (key: spec.templates.spec.containers) օգտագործել վստահելի պատկերներ (այսինքն՝ սկսած my-company.com/).

Ամբողջական կանոնակարգն ունի հետևյալ տեսքը.

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

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

(ruleset.yaml)

Թեստը փորձելու համար պահենք այն որպես check_image_repo.yaml. Եկեք ստուգենք ֆայլը base-valid.yaml:

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

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

Ստուգումը ձախողվեց: Այժմ եկեք ստուգենք հետևյալ մանիֆեստը ճիշտ պատկերի պահոցով.

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

(image-valid-mycompany.yaml)

Մենք նույն թեստն ենք անցկացնում վերը նշված մանիֆեստով: Խնդիրներ չեն հայտնաբերվել.

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

Config-lint-ը խոստումնալից շրջանակ է, որը թույլ է տալիս ստեղծել ձեր սեփական թեստերը՝ վավերացնելու Kubernetes YAML մանիֆեստները՝ օգտագործելով YAML DSL:

Բայց ի՞նչ անել, եթե ձեզ ավելի բարդ տրամաբանություն և թեստեր է պետք: Արդյո՞ք YAML-ը չափազանց սահմանափակ չէ դրա համար: Իսկ եթե կարողանայիք թեստեր ստեղծել ամբողջական ծրագրավորման լեզվով:

4. Պղինձ

Պղինձ V2 Մաքսային թեստերի միջոցով մանիֆեստների վավերացման շրջանակ է (նման է config-lint):

Այնուամենայնիվ, այն տարբերվում է վերջինից նրանով, որ այն չի օգտագործում YAML թեստերը նկարագրելու համար: Փոխարենը թեստերը կարող են գրվել JavaScript-ով: Copper-ը գրադարան է տրամադրում մի քանի հիմնական գործիքներով, որոնք օգնում են ձեզ կարդալ Kubernetes-ի օբյեկտների մասին տեղեկատվություն և հայտնել սխալների մասին:

Պղնձի տեղադրման քայլերը կարելի է գտնել այստեղ պաշտոնական փաստաթղթեր.

2.0.1-ը այս օգտակար ծրագրի վերջին թողարկումն է բնօրինակ հոդվածը գրելու պահին:

Ինչպես config-lint-ը, Copper-ը չունի ներկառուցված թեստեր: Մի հատ գրենք. Թույլ տվեք ստուգել, ​​որ տեղակայումները օգտագործում են կոնտեյների պատկերներ բացառապես վստահելի պահոցներից, ինչպիսիք են my-company.com.

Ստեղծեք ֆայլ check_image_repo.js հետևյալ բովանդակությամբ.

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

Այժմ ստուգելու մեր մանիֆեստը base-valid.yaml, օգտագործեք հրամանը copper validate:

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

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

Հասկանալի է, որ պղնձի օգնությամբ դուք կարող եք կատարել ավելի բարդ թեստեր, օրինակ՝ ստուգել տիրույթի անունները Ingress մանիֆեստներում կամ մերժել արտոնյալ ռեժիմով աշխատող փոդերը։

Պղնձը ունի իր մեջ ներկառուցված տարբեր օգտակար գործառույթներ.

  • DockerImage կարդում է նշված մուտքային ֆայլը և ստեղծում օբյեկտ հետևյալ հատկանիշներով.
    • name - պատկերի անվանումը,
    • tag - պատկերի պիտակ,
    • registry - պատկերների ռեեստր,
    • registry_url - արձանագրություն (https://) և պատկերների ռեեստր,
    • fqin - պատկերի ամբողջական գտնվելու վայրը:
  • Ֆունկցիա findByName օգնում է գտնել ռեսուրս ըստ տվյալ տեսակի (kind) և անունը (name) մուտքագրված ֆայլից:
  • Ֆունկցիա findByLabels օգնում է գտնել ռեսուրս ըստ նշված տեսակի (kind) և պիտակներ (labels).

Դուք կարող եք դիտել բոլոր հասանելի սպասարկման գործառույթները այստեղ.

Լռելյայնորեն այն բեռնում է ամբողջ մուտքային YAML ֆայլը փոփոխականի մեջ $$ և այն հասանելի է դարձնում սկրիպտավորման համար (ծանոթ տեխնիկա jQuery-ի փորձ ունեցողների համար):

Copper-ի հիմնական առավելությունն ակնհայտ է՝ ձեզ հարկավոր չէ տիրապետել մասնագիտացված լեզվին և կարող եք օգտագործել JavaScript-ի տարբեր հնարավորություններ՝ ստեղծելու ձեր սեփական թեստերը, ինչպիսիք են տողերի ինտերպոլացիա, ֆունկցիաներ և այլն:

Հարկ է նաև նշել, որ Copper-ի ներկայիս տարբերակը աշխատում է JavaScript շարժիչի ES5 տարբերակով, այլ ոչ թե ES6:

Մանրամասները հասանելի են ծրագրի պաշտոնական կայքը.

Այնուամենայնիվ, եթե դուք իսկապես չեք հավանում JavaScript-ը և նախընտրում եք այնպիսի լեզու, որը հատուկ ստեղծված է հարցումներ ստեղծելու և քաղաքականությունը նկարագրելու համար, ապա պետք է ուշադրություն դարձնեք կոնֆեստին:

5.Մրցույթ

Confest-ը կոնֆիգուրացիայի տվյալների փորձարկման շրջանակ է: Հարմար է նաև Kubernetes մանիֆեստների փորձարկման/ստուգման համար: Թեստերը նկարագրվում են հարցման մասնագիտացված լեզվով Ռեգո.

Դուք կարող եք տեղադրել մրցույթ՝ օգտագործելով հրահանգներնշված է նախագծի կայքում:

Բնօրինակ հոդվածը գրելու պահին վերջին հասանելի տարբերակը 0.18.2-ն էր:

Config-lint-ի և պղնձի նման, confest-ը գալիս է առանց ներկառուցված թեստերի: Եկեք փորձենք և գրենք մեր քաղաքականությունը: Ինչպես նախորդ օրինակներում, մենք կստուգենք՝ արդյոք կոնտեյների պատկերները վերցված են հուսալի աղբյուրից:

Ստեղծեք գրացուցակ conftest-checks, և դրա մեջ կա ֆայլ անունով check_image_registry.rego հետևյալ բովանդակությամբ.

package main

deny[msg] {

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

Հիմա եկեք փորձարկենք base-valid.yaml միջոցով conftest:

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

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

Թեստը կանխատեսելիորեն ձախողվեց, քանի որ նկարները ստացվել են անվստահելի աղբյուրից:

Rego ֆայլում մենք սահմանում ենք բլոկը deny. Դրա ճշմարտացիությունը համարվում է խախտում։ Եթե ​​արգելափակում է deny մի քանիսը, կոնֆեստը ստուգում է դրանք միմյանցից անկախ, և բլոկներից որևէ մեկի ճշմարտացիությունը դիտվում է որպես խախտում:

Ի լրումն լռելյայն արդյունքի, confest-ը աջակցում է JSON, TAP և աղյուսակի ձևաչափին՝ չափազանց օգտակար հատկություն, եթե անհրաժեշտ է հաշվետվություններ տեղադրել գոյություն ունեցող CI խողովակաշարում: Դուք կարող եք սահմանել ցանկալի ձևաչափը՝ օգտագործելով դրոշը --output.

Քաղաքականությունների վրիպազերծումը հեշտացնելու համար մրցույթն ունի դրոշակ --trace. Այն ցույց է տալիս, թե ինչպես է confest-ը վերլուծում նշված քաղաքականության ֆայլերը:

Մրցույթի քաղաքականությունը կարող է հրապարակվել և տարածվել OCI (Open Container Initiative) գրանցամատյաններում՝ որպես արտեֆակտ:

Հրամաններ push и pull թույլ է տալիս հրապարակել արտեֆակտ կամ առբերել գոյություն ունեցող արտեֆակտը հեռավոր ռեեստրից: Փորձենք հրապարակել մեր ստեղծած քաղաքականությունը տեղական Docker ռեգիստրում՝ օգտագործելով conftest push.

Սկսեք ձեր տեղական Docker ռեեստրը.

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

Մեկ այլ տերմինալում անցեք նախկինում ստեղծված գրացուցակ conftest-checks և գործարկել հետևյալ հրամանը.

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

Եթե ​​հրամանը հաջողվեց, դուք կտեսնեք այսպիսի հաղորդագրություն.

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

Այժմ ստեղծեք ժամանակավոր գրացուցակ և գործարկեք հրամանը դրանում conftest pull. Այն կներբեռնի նախորդ հրամանով ստեղծված փաթեթը.

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

Ժամանակավոր գրացուցակում կհայտնվի ենթատեղեկատու policyորը պարունակում է մեր քաղաքականության ֆայլը՝

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

Թեստերը կարող են իրականացվել անմիջապես պահեստից.

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

Ցավոք, DockerHub-ը դեռ չի աջակցվում: Այսպիսով, ձեզ հաջողակ համարեք, եթե օգտագործում եք Azure բեռնարկղերի գրանցամատյան (ACR) կամ ձեր սեփական ռեգիստրը:

Արտեֆակտի ձևաչափը նույնն է, ինչ Բացեք քաղաքականության գործակալի փաթեթները (OPA), որը թույլ է տալիս օգտագործել կոնֆեստ՝ առկա OPA փաթեթներից թեստեր իրականացնելու համար:

Դուք կարող եք ավելին իմանալ քաղաքականության համօգտագործման և մրցույթի այլ առանձնահատկությունների մասին այստեղ ծրագրի պաշտոնական կայքը.

6: Polaris

Վերջին գործիքը, որը կքննարկվի այս հոդվածում Polaris. (Նրա անցյալ տարվա հայտարարությունը մենք արդեն թարգմանվել է - մոտ. թարգմանություն)

Polaris-ը կարող է տեղադրվել կլաստերում կամ օգտագործվել հրամանի տողի ռեժիմում: Ինչպես կռահեցիք, այն թույլ է տալիս ստատիկ կերպով վերլուծել Kubernetes մանիֆեստները:

Հրամանի տողի ռեժիմում աշխատելիս հասանելի են ներկառուցված թեստերը, որոնք ներառում են այնպիսի ոլորտներ, ինչպիսիք են անվտանգությունը և լավագույն փորձը (նման kube-score): Բացի այդ, դուք կարող եք ստեղծել ձեր սեփական թեստերը (ինչպես config-lint, copper և confest):

Այլ կերպ ասած, Polaris-ը համատեղում է երկու կատեգորիաների գործիքների առավելությունները՝ ներկառուցված և մաքսային թեստերով:

Polaris հրամանի տողի ռեժիմում տեղադրելու համար օգտագործեք հրահանգներ ծրագրի կայքում.

Բնօրինակ հոդվածը գրելու պահին հասանելի է 1.0.3 տարբերակը։

Տեղադրումն ավարտվելուց հետո դուք կարող եք գործարկել polaris-ը մանիֆեստի վրա base-valid.yaml հետևյալ հրամանով.

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

Այն կթողարկի JSON ձևաչափով տող՝ կատարված թեստերի և դրանց արդյունքների մանրամասն նկարագրությամբ: Արդյունքը կունենա հետևյալ կառուցվածքը.

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

Ամբողջական արտադրանքը հասանելի է այստեղ.

Ինչպես kube-score-ը, Polaris-ը բացահայտում է խնդիրները այն ոլորտներում, որտեղ մանիֆեստը չի համապատասխանում լավագույն փորձին.

  • Չկան առողջական ստուգումներ պատիճների համար:
  • Կոնտեյների պատկերների պիտակները նշված չեն:
  • Բեռնարկղը աշխատում է որպես արմատ:
  • Հիշողության և պրոցեսորի հարցումները և սահմանափակումները նշված չեն:

Յուրաքանչյուր թեստ, կախված իր արդյունքներից, նշանակվում է կրիտիկականության աստիճան. նախազգուշացում կամ վտանգ. Ներկառուցված թեստերի մասին ավելին իմանալու համար խնդրում ենք դիմել փաստաթղթավորում.

Եթե ​​մանրամասները անհրաժեշտ չեն, կարող եք նշել դրոշը --format score. Այս դեպքում, Polaris-ը կթողարկի 1-ից մինչև 100 − թիվ միավոր (այսինքն գնահատում):

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

Որքան միավորը մոտ է 100-ին, այնքան բարձր է համաձայնության աստիճանը: Եթե ​​ստուգեք հրամանի ելքի կոդը polaris audit, ստացվում է, որ այն հավասար է 0-ի։

Ուժ polaris audit Դուք կարող եք դադարեցնել աշխատանքը ոչ զրոյական կոդով՝ օգտագործելով երկու դրոշ.

  • Դրոշ --set-exit-code-below-score որպես փաստարկ ընդունում է շեմային արժեք 1-100 միջակայքում: Այս դեպքում հրամանը դուրս կգա ելքի 4 կոդով, եթե միավորը ցածր է շեմից: Սա շատ օգտակար է, երբ դուք ունեք որոշակի շեմային արժեք (ասենք 75), և դուք պետք է ստանաք ահազանգ, եթե միավորը ցածր է:
  • Դրոշ --set-exit-code-on-danger կհանգեցնի հրամանի ձախողմանը 3 կոդով, եթե վտանգի փորձարկումներից մեկը ձախողվի:

Այժմ եկեք փորձենք ստեղծել հատուկ թեստ, որը ստուգում է, թե արդյոք պատկերը վերցված է վստահելի պահոցից: Հատուկ թեստերը նշված են YAML ձևաչափով, և թեստն ինքնին նկարագրվում է JSON Schema-ի միջոցով:

Հետևյալ YAML կոդի հատվածը նկարագրում է նոր թեստ, որը կոչվում է checkImageRepo:

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

Եկեք մանրամասն նայենք դրան.

  • successMessage — այս տողը կտպվի, եթե թեստը հաջողությամբ ավարտվի.
  • failureMessage — այս հաղորդագրությունը կցուցադրվի ձախողման դեպքում.
  • category — ցույց է տալիս կատեգորիաներից մեկը. Images, Health Checks, Security, Networking и Resources;
  • target--- որոշում է, թե ինչ տեսակի օբյեկտ (spec) կիրառվում է թեստ: Հնարավոր արժեքներ. Container, Pod կամ Controller;
  • Թեստի ինքնին նշված է օբյեկտում schema օգտագործելով JSON սխեման: Այս թեստի հիմնական բառն է pattern օգտագործվում է պատկերի աղբյուրը պահանջվողի հետ համեմատելու համար:

Վերոնշյալ թեստը գործարկելու համար անհրաժեշտ է ստեղծել Polaris-ի հետևյալ կոնֆիգուրացիան.

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

(polaris-conf.yaml)

Եկեք վերլուծենք ֆայլը.

  • Ի դաշտում checks սահմանվում են թեստեր և դրանց կրիտիկականության աստիճանը: Քանի որ ցանկալի է նախազգուշացում ստանալ, երբ նկարը վերցված է անվստահելի աղբյուրից, մենք մակարդակը սահմանել ենք այստեղ danger.
  • Թեստի ինքնին checkImageRepo այնուհետև գրանցվել է օբյեկտում customChecks.

Պահպանեք ֆայլը որպես custom_check.yaml. Այժմ դուք կարող եք վազել polaris audit YAML մանիֆեստով, որը պահանջում է ստուգում:

Եկեք փորձարկենք մեր մանիֆեստը base-valid.yaml:

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

Թիմ polaris audit գործարկեց միայն վերը նշված օգտվողի թեստը, և այն ձախողվեց:

Եթե ​​դուք ուղղում եք պատկերը my-company.com/http-echo:1.0, Polaris-ը հաջողությամբ դուրս կգա: Փոփոխություններով մանիֆեստն արդեն կա պահոցներայնպես որ կարող եք ստուգել մանիֆեստի նախորդ հրամանը image-valid-mycompany.yaml.

Հիմա հարց է առաջանում՝ ինչպե՞ս վարել ներկառուցված թեստերը մաքսայինի հետ միասին։ Հեշտությամբ! Դուք պարզապես պետք է ավելացնեք ներկառուցված թեստի նույնացուցիչները կազմաձևման ֆայլում: Արդյունքում, այն կունենա հետևյալ ձևը.

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

(config_with_custom_check.yaml)

Հասանելի է ամբողջական կազմաձևման ֆայլի օրինակ այստեղ.

Ստուգեք մանիֆեստը base-valid.yamlօգտագործելով ներկառուցված և հատուկ թեստեր, կարող եք օգտագործել հրամանը.

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

Polaris-ը լրացնում է ներկառուցված թեստերը սովորական թեստերով՝ դրանով իսկ համատեղելով երկու աշխարհների լավագույնը:

Մյուս կողմից, ավելի հզոր լեզուներ օգտագործելու անկարողությունը, ինչպիսիք են Rego-ն կամ JavaScript-ը, կարող է սահմանափակող գործոն լինել, որը կանխում է ավելի բարդ թեստերի ստեղծումը:

Polaris-ի մասին լրացուցիչ տեղեկություններ հասանելի են այստեղ նախագծի կայքը.

Ամփոփում

Թեև կան բազմաթիվ գործիքներ Kubernetes YAML ֆայլերը ստուգելու և գնահատելու համար, Կարևոր է հստակ պատկերացում ունենալ, թե ինչպես են նախագծվելու և իրականացվելու թեստերը.

Օրինակ, եթե վերցնեք Kubernetes մանիֆեստները, որոնք անցնում են խողովակաշարով, Kubeval-ը կարող է լինել առաջին քայլը նման խողովակաշարի մեջ. Այն կվերահսկի, թե արդյոք օբյեկտների սահմանումները համապատասխանում են Kubernetes API սխեմային:

Նման վերանայումն ավարտվելուց հետո կարելի է անցնել ավելի բարդ թեստերի, ինչպիսիք են ստանդարտ լավագույն փորձի և հատուկ քաղաքականության համապատասխանությունը: Հենց այստեղ էլ օգտակար կլինեին kube-score-ը և Polaris-ը:

Նրանց համար, ովքեր ունեն բարդ պահանջներ և պետք է մանրամասնորեն հարմարեցնեն թեստերը, պղինձը, կոնֆիգուրը և կոնֆեստը հարմար կլինեն:.

Conftest-ը և config-lint-ը օգտագործում են YAML-ը՝ հատուկ թեստեր սահմանելու համար, իսկ պղինձը հնարավորություն է տալիս մուտք գործել ծրագրավորման ամբողջական լեզու՝ դարձնելով այն բավականին գրավիչ ընտրություն:

Մյուս կողմից, արժե՞ օգտագործել այս գործիքներից մեկը և, հետևաբար, ձեռքով ստեղծել բոլոր թեստերը, թե՞ գերադասել Polaris-ը և ավելացնել միայն այն, ինչ անհրաժեշտ է: Այս հարցին հստակ պատասխան չկա.

Ստորև բերված աղյուսակը տալիս է յուրաքանչյուր գործիքի համառոտ նկարագրությունը.

Գործիք
Նպատակը
Սահմանափակումները
Օգտագործողի թեստեր

կուբեվալ
Վավերացնում է YAML դրսևորումները API սխեմայի որոշակի տարբերակի դեմ
Չի կարող աշխատել CRD-ի հետ
Ոչ

kube-score
Վերլուծում է YAML-ի դրսևորումները լավագույն փորձի դեմ
Հնարավոր չէ ընտրել ձեր Kubernetes API տարբերակը՝ ռեսուրսները ստուգելու համար
Ոչ

պղինձ
YAML մանիֆեստների համար հատուկ JavaScript թեստեր ստեղծելու ընդհանուր շրջանակ
Ներկառուցված թեստեր չկան: Վատ փաստաթղթեր
Այո

config-lint
Ընդհանուր շրջանակ՝ YAML-ում ներկառուցված տիրույթին հատուկ լեզվով թեստեր ստեղծելու համար: Աջակցում է տարբեր կազմաձևման ձևաչափերին (օրինակ՝ Terraform)
Պատրաստի թեստեր չկան։ Ներկառուցված պնդումներն ու գործառույթները կարող են բավարար չլինել
Այո

մրցույթ
Շրջանակ՝ Rego-ի միջոցով (հարցումների մասնագիտացված լեզու) օգտագործելով ձեր սեփական թեստերը ստեղծելու համար: Թույլ է տալիս համօգտագործել քաղաքականությունները OCI փաթեթների միջոցով
Ներկառուցված թեստեր չկան: Ես պետք է սովորեմ Ռեգո. Docker Hub-ը չի աջակցվում կանոնները հրապարակելիս
Այո

Polaris
Կարծիքներ YAML դրսևորվում է ստանդարտ լավագույն փորձի դեմ: Թույլ է տալիս ստեղծել ձեր սեփական թեստերը՝ օգտագործելով JSON Schema
JSON Schema-ի վրա հիմնված փորձարկման հնարավորությունները կարող են բավարար չլինել
Այո

Քանի որ այս գործիքները չեն հիմնվում Kubernetes կլաստերի հասանելիության վրա, դրանք հեշտ է տեղադրել: Նրանք թույլ են տալիս զտել սկզբնաղբյուր ֆայլերը և արագ արձագանքել նախագծերում ձգվող հարցումների հեղինակներին:

PS թարգմանչից

Կարդացեք նաև մեր բլոգում.

Source: www.habr.com

Добавить комментарий