🥇Kubernetes YAML-ийг шилдэг туршлага, бодлогын дагуу баталгаажуулж байна

Анхаарна уу. орчуулга.: K8s орчны YAML тохиргооны тоо өсөхийн хэрээр тэдгээрийг автоматаар баталгаажуулах хэрэгцээ улам бүр нэн чухал болж байна. Энэхүү тоймыг зохиогч нь энэ даалгаврын хувьд одоо байгаа шийдлүүдийг сонгоод зогсохгүй, тэдгээрийн хэрхэн ажилладагийг харахын тулд Deployment-ийг жишээ болгон ашигласан. Энэ сэдвийг сонирхож буй хүмүүст маш их мэдээлэлтэй болсон.

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-ээр дамждаг. Өөрөөр хэлбэл, та 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

Одоо кубевалыг өөр манифестээр туршиж үзье:

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, pod-ийн шошготой таарах сонгогчийг оруулах ёстой. Дээрх манифест нь сонгогчийг агуулаагүй тул 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-ийн сул талуудын нэг нь одоогоор Custom Resource Definitions (CRDs)-тай нийцэж байгаа эсэхийг шалгаж чадахгүй байгаа явдал юм. Гэсэн хэдий ч, kubeval-ийг тохируулах боломжтой тэднийг үл тоомсорло.

Кубевал бол нөөцийг шалгах, үнэлэх гайхалтай хэрэгсэл юм; Гэсэн хэдий ч шалгалтанд тэнцсэн нь нөөц нь шилдэг туршлагыг дагаж мөрддөг гэсэн баталгаа биш гэдгийг онцлон тэмдэглэх нь зүйтэй.

Жишээлбэл, шошгыг ашиглах latest саванд хийх нь хамгийн сайн туршлагыг дагаж мөрддөггүй. Гэсэн хэдий ч kubeval үүнийг алдаа гэж үзэхгүй бөгөөд үүнийг мэдээлдэггүй. Өөрөөр хэлбэл, ийм YAML-ийн шалгалтыг анхааруулгагүйгээр дуусгах болно.

Гэхдээ та YAML-ийг үнэлж, шошго гэх мэт зөрчлийг тодорхойлохыг хүсвэл яах вэ latest? Би YAML файлыг шилдэг туршлагын эсрэг хэрхэн шалгах вэ?

2. Кубе оноо

Кубе оноо YAML манифестийг задлан шинжилж, суурилуулсан тестийн эсрэг үнэлдэг. Эдгээр туршилтуудыг аюулгүй байдлын удирдамж, шилдэг туршлагууд дээр үндэслэн сонгоно, тухайлбал:

Савыг root хэлбэрээр биш ажиллуулж байна.
Под эрүүл мэндийн үзлэг хийх боломжтой.
Нөөцийн хүсэлт, хязгаарлалтыг тогтоох.

Туршилтын үр дүнд үндэслэн гурван үр дүн гарна. 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-ийн нөөц болон санах ойд ямар ч хүсэлт, хязгаарлалт байхгүй.
Pod тасалдлын төсвийг тодорхой заагаагүй байна.
Тусгаарлах дүрэм байхгүй (харилцааны эсрэг) хүртээмжийг нэмэгдүүлэх.
Контейнер нь root хэлбэрээр ажилладаг.

Эдгээр нь Байршлыг илүү үр дүнтэй, найдвартай болгохын тулд засах шаардлагатай дутагдлуудын талаархи хүчинтэй цэгүүд юм.

баг 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-ийн талаарх дэлгэрэнгүй мэдээллийг эндээс авах боломжтой албан ёсны вэбсайт.

Кубе онооны тест нь шилдэг туршлагыг хэрэгжүүлэх гайхалтай хэрэгсэл боловч хэрэв та шалгалтанд өөрчлөлт оруулах эсвэл өөрийн дүрмээ нэмэх шаардлагатай бол яах вэ? Харамсалтай нь үүнийг хийх боломжгүй юм.

Куб оноог өргөтгөх боломжгүй: та түүнд бодлого нэмэх эсвэл тэдгээрийг тохируулах боломжгүй.

Хэрэв та компанийн бодлогод нийцэж байгаа эсэхийг шалгахын тулд захиалгат тест бичих шаардлагатай бол дараах дөрвөн хэрэгслийн аль нэгийг ашиглаж болно: 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. Ийм шалгалтыг гүйцэтгэдэг 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 нь YAML DSL ашиглан Kubernetes YAML манифестуудыг баталгаажуулахын тулд өөрийн тестийг үүсгэх боломжийг олгодог ирээдүйтэй хүрээ юм.

Гэхдээ танд илүү төвөгтэй логик, тест хэрэгтэй бол яах вэ? YAML үүнд хэтэрхий хязгаарлагдмал биш гэж үү? Хэрэв та бүрэн програмчлалын хэлээр тест үүсгэж чадвал яах вэ?

4. Зэс

Зэс V2 нь захиалгат тест (config-lint-тэй төстэй) ашиглан манифестуудыг баталгаажуулах хүрээ юм.

Гэсэн хэдий ч энэ нь тестийг тайлбарлахдаа YAML ашигладаггүй гэдгээрээ сүүлийнхээс ялгаатай. Тестийг оронд нь JavaScript дээр бичиж болно. Зэс нь номын санг хэд хэдэн үндсэн хэрэгслээр хангадаг, энэ нь Kubernetes объектын талаарх мэдээллийг уншиж, алдааг мэдээлэхэд тусална.

Зэсийг суулгах алхмуудыг эндээс олж болно албан ёсны баримт бичиг.

2.0.1 нь нийтлэлийг бичиж байх үеийн энэ хэрэгслийн хамгийн сүүлийн хувилбар юм.

Config-lint-тэй адил Зэс нь суурилуулсан тестгүй. Нэг бичье. Байрлуулалт нь зөвхөн итгэмжлэгдсэн хадгалах сангаас агуулах дүрсийг ашиглаж байгаа эсэхийг шалгахыг зөвшөөрнө үү 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 манифест дахь домэйн нэрийг шалгах эсвэл давуу эрхтэй горимд ажиллаж байгаа pods-аас татгалзах.

Зэс нь дотроо янз бүрийн ашигтай функцуудтай:

DockerImage заасан оролтын файлыг уншиж, дараах шинж чанаруудтай объект үүсгэдэг:
- name - зургийн нэр,
- tag - зургийн шошго,
- registry - зургийн бүртгэл,
- registry_url - протокол (https://) болон зургийн бүртгэл,
- fqin - зургийн бүрэн байршил.
үйл ажиллагаа findByName тухайн төрлийн нөөцийг олоход тусалдаг (kind) болон нэр (name) оролтын файлаас.
үйл ажиллагаа findByLabels тодорхой төрлийн нөөцийг олоход тусалдаг (kind) болон шошго (labels).

Та боломжтой бүх үйлчилгээний функцийг үзэх боломжтой энд.

Анхдагч байдлаар энэ нь бүх оролтын YAML файлыг хувьсагч руу ачаалдаг $$ мөн үүнийг скрипт хийхэд ашиглах боломжтой болгодог (jQuery туршлагатай хүмүүст зориулсан танил техник).

Зэсийн гол давуу тал нь мэдээжийн хэрэг: та тусгай хэл эзэмших шаардлагагүй бөгөөд та мөрийн интерполяци, функц гэх мэт янз бүрийн JavaScript функцуудыг ашиглан өөрийн тест үүсгэх боломжтой.

Зэсийн одоогийн хувилбар нь 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. (Түүний өнгөрсөн жилийн мэдэгдэл бид аль хэдийн орчуулсан - ойролцоогоор. орчуулга)

Polaris-ийг кластерт суулгаж эсвэл командын мөрийн горимд ашиглаж болно. Таны таамаглаж байсанчлан энэ нь Кубернетес манифестийг статик байдлаар шинжлэх боломжийг танд олгоно.

Тушаалын мөрийн горимд ажиллаж байх үед аюулгүй байдал, шилдэг туршлагууд (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 нь манифест нь шилдэг туршлагыг хангаагүй газруудад асуудлуудыг тодорхойлдог:

Буурцагны эрүүл мэндийн үзлэг байхгүй.
Контейнерын зургийн шошгыг заагаагүй байна.
Контейнер нь root хэлбэрээр ажилладаг.
Санах ой болон CPU-ийн хүсэлт, хязгаарлалтыг заагаагүй болно.

Туршилт бүрийг үр дүнгээс нь хамааруулан эгзэгтэй байдлын зэрэгтэй болгодог. анхааруулах буюу аюул. Боломжтой суурилуулсан тестүүдийн талаар илүү ихийг мэдэхийг хүсвэл эндээс үзнэ үү баримт бичиг.

Хэрэв дэлгэрэнгүй мэдээлэл шаардлагагүй бол та тугийг зааж өгч болно --format score. Энэ тохиолдолд Polaris нь 1-ээс 100 − хүртэлх тоог гаргана Оноо (жишээ нь үнэлгээ):

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

Оноо 100-д ойртох тусам зөвшилцлийн зэрэг өндөр болно. Хэрэв та тушаалын гарах кодыг шалгана уу polaris audit, энэ нь 0-тэй тэнцүү байна.

Хүч polaris audit Та хоёр туг ашиглан тэгээс өөр кодтой ажлыг дуусгаж болно:

Flag --set-exit-code-below-score 1-100 хүртэлх хязгаарын утгыг аргумент болгон авна. Энэ тохиолдолд оноо босгоос доогуур байвал тушаал 4-р гарах кодоор гарна. Энэ нь танд тодорхой босго утга (75 гэж хэлье) байгаа үед маш хэрэгтэй бөгөөд онооноос доош орвол анхааруулга авах шаардлагатай.
Flag --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 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-г дэмждэггүй
Тийм

Polaris
Шүүмж YAML нь стандарт шилдэг туршлагуудын эсрэг илэрдэг. JSON схемийг ашиглан өөрийн тестийг үүсгэх боломжийг танд олгоно
JSON схем дээр суурилсан туршилтын чадвар хангалтгүй байж магадгүй
Тийм

Эдгээр хэрэгслүүд нь Kubernetes кластерт хандах хандалтад тулгуурладаггүй тул суулгахад хялбар байдаг. Эдгээр нь эх файлуудыг шүүж, төсөл дэх татах хүсэлтийн зохиогчдод хурдан санал хүсэлт өгөх боломжийг олгодог.

Орчуулагчийн жич

Мөн манай блог дээрээс уншина уу:

Эх сурвалж: www.habr.com

Kubernetes YAML-ийг шилдэг туршлага, бодлоготой нийцүүлэн баталгаажуулна уу