🥇Kubernetes YAML-ді ең жақсы тәжірибелер мен саясаттарға қарсы тексеру

Ескерту. аударма: K8s орталары үшін YAML конфигурацияларының санының өсуімен оларды автоматтандырылған тексеру қажеттілігі барған сайын өзекті бола түседі. Осы шолудың авторы осы тапсырма үшін бар шешімдерді таңдап қана қоймай, олардың қалай жұмыс істейтінін көру үшін мысал ретінде Орналастыруды пайдаланды. Бұл тақырыпқа қызығушылық танытқандар үшін өте мазмұнды болды.

TL; DR: Бұл мақала Kubernetes YAML файлдарын ең жақсы тәжірибелер мен талаптарға сәйкес тексеру және бағалау үшін алты статикалық құралды салыстырады.

Kubernetes жұмыс жүктемелері әдетте YAML құжаттары түрінде анықталады. YAML проблемаларының бірі манифест файлдары арасындағы шектеулерді немесе қатынастарды анықтау қиындығы болып табылады.

Кластерге орналастырылған барлық кескіндердің сенімді тізілімнен алынғанына көз жеткізу қажет болса ше?

PodDisruptionBudgets жоқ орналастыруларды кластерге жіберуді қалай болдырмауға болады?

Статикалық тестілеудің интеграциясы әзірлеу сатысында қателер мен саясаттың бұзылуын анықтауға мүмкіндік береді. Бұл ресурс анықтамаларының дұрыс және қауіпсіз екендігіне кепілдікті арттырады және өндірістік жұмыс жүктемелерінің ең жақсы тәжірибелерге сәйкес келуі ықтималдығын арттырады.

Kubernetes статикалық YAML файлды тексеру экожүйесін келесі санаттарға бөлуге болады:

API валидаторлары. Осы санаттағы құралдар YAML манифестін Kubernetes API серверінің талаптарына сәйкес тексереді.
Дайын тестерлер. Осы санаттағы құралдар қауіпсіздік, озық тәжірибелерге сәйкестік және т.б. бойынша дайын сынақтармен бірге келеді.
Арнаулы валидаторлар. Бұл санаттың өкілдері әртүрлі тілдерде теңшелетін сынақтарды жасауға мүмкіндік береді, мысалы, Rego және Javascript.

Бұл мақалада біз алты түрлі құралды сипаттаймыз және салыстырамыз:

кубевальді;
куб балл;
config-lint;
мыс;
жарыс;
Поларис.

Ал, бастайық!

Орналастыруларды тексеру

Құралдарды салыстыруды бастамас бұрын, оларды сынау үшін кейбір фон жасайық.

Төмендегі манифестте бірқатар қателер және ең жақсы тәжірибелерге сәйкес келмеу бар: олардың қаншасын таба аласыз?

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

(base-valid.yaml)

Біз әртүрлі құралдарды салыстыру үшін осы YAML қолданамыз.

Жоғарыдағы манифест base-valid.yaml және осы мақаланың басқа манифесттерін мына жерден табуға болады Git репозиторийлері.

Манифест негізгі міндеті 5678 портына «Сәлем әлемі» хабарымен жауап беру болып табылатын веб-бағдарламаны сипаттайды. Оны келесі пәрменмен орналастыруға болады:

kubectl apply -f hello-world.yaml

Сонымен - жұмысты тексеріңіз:

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

Енді барыңыз http://localhost:8080 және қолданбаның жұмыс істеп тұрғанын растаңыз. Бірақ ол ең жақсы тәжірибелерді сақтайды ма? Тексерейік.

1. Кубевал

жүрегінде кубевальды Идея Kubernetes-пен кез келген әрекеттесу оның REST API арқылы жүзеге асады. Басқаша айтқанда, берілген YAML оған сәйкес келетінін тексеру үшін API схемасын пайдалануға болады. Мысал қарастырайық.

Орнату нұсқаулары kubeval жобаның веб-сайтында қол жетімді.

Бастапқы мақаланы жазу кезінде 0.15.0 нұсқасы қол жетімді болды.

Орнатқаннан кейін оны жоғарыдағы манифестпен берейік:

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

Сәтті болса, kubeval шығу коды 0 арқылы шығады. Оны келесідей тексеруге болады:

$ echo $?
0

Енді кубевалды басқа манифестпен қолданып көрейік:

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

(kubeval-invalid.yaml)

Мәселені көзбен байқай аласыз ба? Іске кірісейік:

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

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

Ресурс тексерілмейді.

API нұсқасын қолданатын орналастырулар apps/v1, қосқыш белгісіне сәйкес келетін селекторды қамтуы керек. Жоғарыдағы манифест селекторды қамтымайды, сондықтан kubeval қате туралы хабарлады және нөлдік емес кодпен шықты.

Олай болсам не болар екен деп ойлаймын kubectl apply -f осы манифестпен?

Ал, тырысайық:

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

Бұл Кубевал ескерткен қате. Мұны селекторды қосу арқылы түзете аласыз:

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

(base-valid.yaml)

Kubeval сияқты құралдардың артықшылығы - мұндай қателерді орналастыру циклінің басында анықтауға болады.

Сонымен қатар, бұл тексерулер кластерге кіруді талап етпейді, олар офлайн режимде орындалуы мүмкін.

Әдепкі бойынша, kubeval ресурстарды соңғы Kubernetes API схемасымен тексереді. Дегенмен, көп жағдайда арнайы Kubernetes шығарылымын тексеру қажет болуы мүмкін. Мұны жалаушаның көмегімен жасауға болады --kubernetes-version:

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

Нұсқа форматта көрсетілуі керек екенін ескеріңіз Major.Minor.Patch.

Тексеруге қолдау көрсетілетін нұсқалар тізімін қараңыз GitHub жүйесіндегі JSON схемасы, валидация үшін қандай kubeval пайдаланады. Егер сізге kubeval бағдарламасын желіден тыс іске қосу қажет болса, схемаларды жүктеп алыңыз және жалаушаны пайдаланып олардың жергілікті орнын көрсетіңіз --schema-location.

Жеке YAML файлдарынан басқа, kubeval каталогтармен және stdin-мен де жұмыс істей алады.

Сонымен қатар, Кубевал CI құбырына оңай біріктіріледі. Манифесттерді кластерге жібермес бұрын сынақтарды орындағысы келетіндер kubeval үш шығыс пішімін қолдайтынын білуге қуанышты болады:

Қарапайым мәтін;
JSON;
Кез келген нәрсені тексеру протоколы (TAP).

Ал кез келген пішім қажетті түрдегі нәтижелердің қысқаша мазмұнын жасау үшін нәтижені одан әрі талдау үшін пайдаланылуы мүмкін.

Kubeval кемшіліктерінің бірі қазіргі уақытта пайдаланушы ресурс анықтамаларына (CRDs) сәйкестігін тексере алмайды. Дегенмен, kubeval конфигурациялауға болады оларды елемеу.

Kubeval - ресурстарды тексеру және бағалау үшін тамаша құрал; Дегенмен, тестілеуден өту ресурстың озық тәжірибелерге сәйкес келетініне кепілдік бермейтінін атап өткен жөн.

Мысалы, тегті пайдалану latest контейнерде ең жақсы тәжірибелерді сақтамайды. Дегенмен, kubeval мұны қате деп санамайды және ол туралы хабарламайды. Яғни, мұндай YAML тексеру ескертусіз аяқталады.

Бірақ YAML-ді бағалап, тег сияқты бұзушылықтарды анықтағыңыз келсе ше latest? YAML файлын ең жақсы тәжірибелерге қарсы қалай тексеруге болады?

2. Куб-балл

Кубе балл YAML манифесттерін талдайды және оларды кірістірілген сынақтарға қарсы бағалайды. Бұл сынақтар қауіпсіздік нұсқаулары мен ең жақсы тәжірибелер негізінде таңдалады, мысалы:

Контейнерді түбір ретінде емес іске қосу.
Қаптаманың денсаулығын тексерудің болуы.
Ресурстар үшін сұраулар мен шектеулерді орнату.

Тест нәтижелері бойынша үш нәтиже беріледі: OK, ЕСКЕРТУ и МАҢЫЗДЫ.

Сіз Kube-score онлайн режимінде қолданып көруге немесе оны жергілікті түрде орнатуға болады.

Түпнұсқа мақаланы жазу кезінде kube-score бағдарламасының соңғы нұсқасы 1.7.0 болды.

Оны манифестімізде сынап көрейік base-valid.yaml:

$ kube-score score base-valid.yaml

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

YAML kubeval сынақтарынан өтеді, ал kube баллы келесі кемшіліктерді көрсетеді:

Дайындық тексерулері конфигурацияланбаған.
CPU ресурстары мен жады үшін сұраулар немесе шектеулер жоқ.
Подты бұзу бюджеттері көрсетілмеген.
Бөлу ережелері жоқ (антифинитті) қолжетімділігін арттыру үшін.
Контейнер түбір ретінде жұмыс істейді.

Бұлардың барлығы Орналастыруды тиімдірек және сенімді ету үшін шешілуі қажет кемшіліктер туралы дұрыс нүктелер.

команда kube-score ақпаратты адам оқи алатын пішінде, соның ішінде барлық түрдегі бұзушылықтарды көрсетеді ЕСКЕРТУ и МАҢЫЗДЫ, бұл даму кезінде көп көмектеседі.

Бұл құралды CI құбырында пайдаланғысы келетіндер жалауша арқылы көбірек қысылған шығысты қоса алады --output-format ci (бұл жағдайда нәтижесі бар сынақтар да көрсетіледі OK):

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

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

Kubeval сияқты, kube-score сынақ сәтсіз болған кезде нөлден тыс шығу кодын қайтарады. МАҢЫЗДЫ. үшін ұқсас өңдеуді қосуға болады ЕСКЕРТУ.

Сонымен қатар, ресурстардың әртүрлі API нұсқаларына сәйкестігін тексеруге болады (kubeval сияқты). Дегенмен, бұл ақпарат kube ұпайының өзінде қатты кодталған: сіз Kubernetes бағдарламасының басқа нұсқасын таңдай алмайсыз. Егер сіз кластерді жаңартқыңыз келсе немесе 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 пайдаланушы сынақтарын орнатуға арналған.

Орналастырудағы кескіндердің әрқашан сенімді репозиторийден жүктелетініне көз жеткізгіңіз келеді делік. my-company.com/myapp:1.0. Осындай тексеруді орындайтын конфигурациялау ережесі келесідей болады:

- 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 - мүмкін FAILURE, ЕСКЕРТУ и НОН_СӘЙКЕСТІК;
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 – YAML DSL көмегімен Kubernetes YAML манифесттерін тексеру үшін өзіңіздің жеке сынақтарыңызды жасауға мүмкіндік беретін перспективалы құрылым.

Бірақ сізге күрделі логика мен сынақтар қажет болса ше? YAML бұл үшін тым шектеулі емес пе? Толық бағдарламалау тілінде тесттер жасай алсаңыз ше?

4. Мыс

Мыс V2 теңшелетін сынақтарды қолдану арқылы манифесттерді тексеруге арналған құрылым (config-lint сияқты).

Дегенмен, оның соңғысынан айырмашылығы, ол сынақтарды сипаттау үшін YAML қолданбайды. Оның орнына тесттер JavaScript тілінде жазылуы мүмкін. Мыс кітапхананы бірнеше негізгі құралдармен қамтамасыз етеді, ол 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 тәжірибесі бар адамдар үшін таныс әдіс).

Мыстың басты артықшылығы айқын: сізге арнайы тілді меңгерудің қажеті жоқ және сіз өзіңіздің тесттеріңізді жасау үшін әртүрлі JavaScript мүмкіндіктерін пайдалана аласыз, мысалы, жол интерполяциясы, функциялар және т.б.

Сондай-ақ, Copper-тің қазіргі нұсқасы ES5 емес, JavaScript қозғалтқышының ES6 нұсқасымен жұмыс істейтінін атап өткен жөн.

Толық ақпаратты мына жерден алуға болады жобаның ресми сайты.

Дегенмен, егер сізге JavaScript шынымен ұнамаса және сұраулар жасау және саясаттарды сипаттау үшін арнайы жасалған тілді ұнатсаңыз, confest-ке назар аудару керек.

5.Бәйге

Confest – конфигурация деректерін сынауға арналған құрылым. Сондай-ақ Kubernetes манифесттерін сынау/тексеру үшін қолайлы. Тесттер арнайы сұрау тілі арқылы сипатталады Рего.

пайдаланып confest орнатуға болады нұсқауларжобаның веб-сайтында көрсетілген.

Түпнұсқа мақаланы жазу кезінде қол жетімді соңғы нұсқасы 0.18.2 болды.

Config-lint және copper сияқты, 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 оларды бір-бірінен тәуелсіз тексереді және блоктардың кез келгенінің ақиқаттығы бұзушылық ретінде қарастырылады.

Әдепкі шығысқа қоса, confest JSON, TAP және кесте пішімін қолдайды – есептерді бар CI құбырына ендіру қажет болса, өте пайдалы мүмкіндік. Жалаушаның көмегімен қажетті пішімді орнатуға болады --output.

Саясаттарды түзетуді жеңілдету үшін confest жалаушасы бар --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 бумаларынан сынақтарды іске қосу үшін confest пайдалануға мүмкіндік береді.

Саясатты бөлісу және конкурстың басқа мүмкіндіктері туралы толығырақ мына жерден біле аласыз жобаның ресми сайты.

6. Polaris

Осы мақалада талқыланатын соңғы құрал Поляр. (Оның өткен жылғы хабарландыруы біз қазірдің өзінде аударылған - шамамен. аударма)

Polaris кластерінде орнатылуы немесе пәрмен жолы режимінде пайдаланылуы мүмкін. Сіз болжағандай, ол Kubernetes манифесттерін статикалық талдауға мүмкіндік береді.

Пәрмен жолы режимінде іске қосылған кезде қауіпсіздік және ең жақсы тәжірибелер (kube-score сияқты) сияқты аймақтарды қамтитын кіріктірілген сынақтар қол жетімді. Бұған қоса, сіз өзіңіздің сынақтарыңызды жасай аласыз (config-lint, copper және confest сияқты).

Басқаша айтқанда, Polaris екі санаттағы құралдардың артықшылықтарын біріктіреді: кірістірілген және пайдаланушы сынақтарымен.

Polaris пәрмен жолы режимінде орнату үшін пайдаланыңыз жобаның веб-сайтындағы нұсқаулар.

Түпнұсқа мақаланы жазу кезінде 1.0.3 нұсқасы қолжетімді.

Орнату аяқталғаннан кейін манифестте полярды іске қосуға болады base-valid.yaml келесі пәрменмен:

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

Ол орындалған сынақтардың және олардың нәтижелерінің егжей-тегжейлі сипаттамасымен JSON пішіміндегі жолды шығарады. Шығару келесі құрылымға ие болады:

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

Толық шығару қол жетімді осында.

Kube-score сияқты, Polaris манифест ең жақсы тәжірибелерге сәйкес келмейтін аймақтардағы мәселелерді анықтайды:

Бұршақтардың денсаулығы тексерілмейді.
Контейнер кескіндері үшін тегтер көрсетілмеген.
Контейнер түбір ретінде жұмыс істейді.
Жад пен CPU үшін сұраулар мен шектеулер көрсетілмеген.

Әрбір сынаққа оның нәтижелеріне байланысты сыни дәрежесі беріледі: ескерту немесе Қауіп. Қол жетімді кірістірілген сынақтар туралы қосымша ақпарат алу үшін мына сілтемені қараңыз құжаттама.

Мәліметтер қажет болмаса, жалаушаны көрсетуге болады --format score. Бұл жағдайда Polaris 1 мен 100 − аралығындағы санды шығарады Гол (яғни бағалау):

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

Балл 100-ге жақындаған сайын келісім дәрежесі жоғары болады. Пәрменнің шығу кодын тексерсеңіз polaris audit, ол 0-ге тең болып шығады.

Күш polaris audit Екі жалаушаны пайдаланып нөлдік емес кодпен жұмысты тоқтатуға болады:

Ту --set-exit-code-below-score аргумент ретінде 1-100 аралығындағы шекті мәнді қабылдайды. Бұл жағдайда, егер балл шекті мәннен төмен болса, пәрмен 4 шығу коды арқылы шығады. Бұл белгілі бір шекті мәнге (айталық 75) ие болған кезде өте пайдалы және балл төмен түссе, ескерту алу қажет.
Ту --set-exit-code-on-danger қауіп сынақтарының бірі сәтсіз аяқталса, пәрмен 3-кодпен сәтсіздікке ұшырайды.

Енді кескіннің сенімді репозиторийден алынғанын тексеретін теңшелетін сынақты жасауға тырысайық. Теңшелетін сынақтар YAML пішімінде көрсетіледі және сынақтың өзі JSON схемасы арқылы сипатталады.

Келесі YAML код үзіндісі деп аталатын жаңа сынақты сипаттайды checkImageRepo:

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

Оны толығырақ қарастырайық:

successMessage — сынақ сәтті аяқталса, бұл жол басып шығарылады;
failureMessage — бұл хабарлама сәтсіз болған жағдайда көрсетіледі;
category - категориялардың бірін көрсетеді: Images, Health Checks, Security, Networking и Resources;
target--- объектінің қандай түрін анықтайды (spec) сынақ қолданылады. Мүмкін мәндер: Container, Pod немесе Controller;
Сынақтың өзі нысанда көрсетілген schema JSON схемасын пайдалану. Бұл сынақтағы негізгі сөз pattern сурет көзін қажеттімен салыстыру үшін қолданылады.

Жоғарыдағы сынақты орындау үшін келесі Polaris конфигурациясын жасау керек:

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

(polaris-conf.yaml)

Файлды талдап көрейік:

Алаңда checks сынақтар және олардың критикалық деңгейі белгіленеді. Кескін сенімсіз дереккөзден алынған кезде ескерту алу қажет болғандықтан, біз деңгейді осында орнаттық. danger.
Тесттің өзі checkImageRepo кейін нысанда тіркеледі customChecks.

Файлды басқаша сақтаңыз custom_check.yaml. Енді сіз жүгіре аласыз polaris audit тексеруді қажет ететін YAML манифестімен.

Манифестімізді сынап көрейік base-valid.yaml:

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

команда polaris audit жоғарыда көрсетілген пайдаланушы сынағы ғана орындалды және ол сәтсіз аяқталды.

Егер сіз кескінді түзетсеңіз my-company.com/http-echo:1.0, Polaris сәтті аяқталады. Өзгерістері бар манифест қазірдің өзінде бар репозиторийлерсондықтан манифесттегі алдыңғы пәрменді тексеруге болады image-valid-mycompany.yaml.

Енді сұрақ туындайды: кірістірілген сынақтарды пайдаланушылармен бірге қалай іске қосу керек? Оңай! Тек конфигурация файлына кірістірілген сынақ идентификаторларын қосу керек. Нәтижесінде ол келесі пішінді алады:

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

(config_with_custom_check.yaml)

Толық конфигурация файлының мысалы қол жетімді осында.

Манифестті тексеріңіз base-valid.yamlкірістірілген және теңшелетін сынақтарды пайдалана отырып, сіз пәрменді пайдалана аласыз:

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

Polaris кірістірілген сынақтарды реттелетін сынақтармен толықтырады, осылайша екі әлемнің ең жақсысын біріктіреді.

Екінші жағынан, Rego немесе JavaScript сияқты күшті тілдерді пайдалану мүмкін еместігі күрделі сынақтарды жасауға кедергі келтіретін шектеуші фактор болуы мүмкін.

Polaris туралы қосымша ақпаратты мына жерден алуға болады жобаның сайты.

Резюме

Kubernetes YAML файлдарын тексеру және бағалау үшін көптеген құралдар бар болса да, сынақтардың қалай әзірленетінін және орындалатынын нақты түсіну маңызды.

Мысалы, Егер сіз Кубернетес манифестерін құбыр арқылы өтетін алсаңыз, кубеваль мұндай құбырдағы алғашқы қадам болуы мүмкін. Ол нысан анықтамаларының Kubernetes API схемасына сәйкес келетінін бақылайды.

Мұндай шолу аяқталғаннан кейін стандартты озық тәжірибелерге және арнайы саясаттарға сәйкестік сияқты күрделірек сынақтарға көшуге болады. Бұл жерде kube-score және Polaris пайдалы болады.

Күрделі талаптары бар және сынақтарды егжей-тегжейлі теңшеуді қажет ететіндер үшін мыс, конфигурация және конфест қолайлы болар еді..

Confest және config-lint реттелетін сынақтарды анықтау үшін YAML пайдаланады, ал мыс толық бағдарламалау тіліне қол жеткізуге мүмкіндік береді, бұл оны өте тартымды таңдау етеді.

Екінші жағынан, осы құралдардың бірін пайдаланып, сондықтан барлық сынақтарды қолмен жасау керек пе, әлде Polaris-ті таңдап, оған тек қажет нәрсені қосу керек пе? Бұл сұраққа нақты жауап жоқ.

Төмендегі кестеде әрбір құралдың қысқаша сипаттамасы берілген:

Құрал
Мақсаты
кемшіліктер
Пайдаланушы сынақтары

кубевальды
YAML манифесттерін API схемасының нақты нұсқасына қарсы тексереді
CRD-мен жұмыс істеу мүмкін емес
жоқ

куб ұпай
Ең жақсы тәжірибелерге қарсы YAML көріністерін талдайды
Ресурстарды тексеру үшін Kubernetes API нұсқасын таңдау мүмкін емес
жоқ

мыс
YAML манифесттері үшін пайдаланушы JavaScript сынақтарын жасауға арналған жалпы құрылым
Кірістірілген сынақтар жоқ. Нашар құжаттама
сол

config-lint
YAML ішіне енгізілген доменге тән тілде сынақтарды жасауға арналған жалпы құрылым. Әр түрлі конфигурация пішімдерін қолдайды (мысалы, Terraform)
Дайын сынақтар жоқ. Кірістірілген бекітулер мен функциялар жеткіліксіз болуы мүмкін
сол

сайыс
Rego (арнайы сұрау тілі) арқылы өз сынақтарыңызды жасауға арналған құрылым. OCI бумалары арқылы саясаттарды ортақ пайдалануға мүмкіндік береді
Кірістірілген сынақтар жоқ. Мен Регоды үйренуім керек. Саясаттарды жариялау кезінде Docker Hub қолданбасына қолдау көрсетілмейді
сол

Поляр
YAML шолулары стандартты ең жақсы тәжірибелерге қарсы. JSON схемасын пайдаланып өз сынақтарыңызды жасауға мүмкіндік береді
JSON схемасына негізделген сынақ мүмкіндіктері жеткіліксіз болуы мүмкін
сол

Бұл құралдар Kubernetes кластеріне кіруге сенбейтіндіктен, оларды орнату оңай. Олар бастапқы файлдарды сүзуге және жобалардағы тарту сұрауларының авторларына жылдам кері байланысты қамтамасыз етуге мүмкіндік береді.

Аудармашыдан PS

Біздің блогта да оқыңыз:

Ақпарат көзі: www.habr.com

Kubernetes YAML нұсқасын ең жақсы тәжірибелер мен саясаттарға қарсы растаңыз