დაადასტურეთ Kubernetes YAML საუკეთესო პრაქტიკისა და პოლიტიკის წინააღმდეგ

Შენიშვნა. თარგმნა: K8s გარემოსთვის YAML კონფიგურაციების მზარდი რაოდენობის გამო, მათი ავტომატური გადამოწმების საჭიროება უფრო და უფრო აქტუალური ხდება. ამ მიმოხილვის ავტორმა არა მხოლოდ შეარჩია არსებული გადაწყვეტილებები ამ ამოცანისთვის, არამედ გამოიყენა Deployment, როგორც მაგალითი, რათა ენახა, როგორ მუშაობენ ისინი. ძალიან ინფორმატიული აღმოჩნდა ამ თემით დაინტერესებულთათვის.

TL; DR: ეს სტატია ადარებს ექვს სტატიკური ინსტრუმენტს Kubernetes YAML ფაილების დასადასტურებლად და შესაფასებლად საუკეთესო პრაქტიკისა და მოთხოვნების შესაბამისად.

Kubernetes-ის დატვირთვები, როგორც წესი, განისაზღვრება YAML დოკუმენტების სახით. YAML-ის ერთ-ერთი პრობლემა არის მანიფესტის ფაილებს შორის შეზღუდვების ან ურთიერთობების დაზუსტების სირთულე.

რა მოხდება, თუ უნდა დავრწმუნდეთ, რომ კლასტერში განთავსებული ყველა სურათი სანდო რეესტრიდან მოდის?

როგორ შემიძლია თავიდან ავიცილოთ განლაგება, რომლებსაც არ აქვთ PodDisruptionBudgets კლასტერში გაგზავნა?

სტატიკური ტესტირების ინტეგრაცია საშუალებას გაძლევთ გამოავლინოთ შეცდომები და პოლიტიკის დარღვევები განვითარების ეტაპზე. ეს ზრდის გარანტიას, რომ რესურსების განმარტებები სწორი და უსაფრთხოა, და უფრო სავარაუდოა, რომ წარმოების დატვირთვა საუკეთესო პრაქტიკას მიჰყვება.

Kubernetes სტატიკური YAML ფაილის ინსპექტირების ეკოსისტემა შეიძლება დაიყოს შემდეგ კატეგორიებად:

• API ვალიდატორები. ამ კატეგორიის ხელსაწყოები ამოწმებენ YAML მანიფესტს Kubernetes API სერვერის მოთხოვნების შესაბამისად.
• მზა ტესტერები. ამ კატეგორიის ხელსაწყოებს მოჰყვება უსაფრთხოების მზა ტესტები, საუკეთესო პრაქტიკასთან შესაბამისობა და ა.შ.
• მორგებული ვალიდატორები. ამ კატეგორიის წარმომადგენლები საშუალებას გაძლევთ შექმნათ საბაჟო ტესტები სხვადასხვა ენაზე, მაგალითად, Rego და Javascript.

ამ სტატიაში ჩვენ აღვწერთ და შევადარებთ ექვს სხვადასხვა ინსტრუმენტს:

1. კუბევალი;
2. კუბე-ქულა;
3. კონფიგურაცია-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 საცავები.

მანიფესტი აღწერს ვებ აპლიკაციას, რომლის მთავარი ამოცანაა პასუხის გაცემა „Hello World“ პორტ 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, უნდა შეიცავდეს ამომრჩეველს, რომელიც ემთხვევა პოდის ეტიკეტს. ზემოთ მოყვანილი მანიფესტი არ შეიცავს ამომრჩეველს, ამიტომ კუბევალმა შეატყობინა შეცდომა და გავიდა არანულოვანი კოდით.

მაინტერესებს რა მოხდება, თუ გავაკეთებ 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 ამოწმებს რესურსებს უახლესი Kubernetes API სქემის მიხედვით. თუმცა, უმეტეს შემთხვევაში შეიძლება დაგჭირდეთ კუბერნეტის კონკრეტული გამოშვების შემოწმება. ეს შეიძლება გაკეთდეს დროშის გამოყენებით --kubernetes-version:

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

გთხოვთ გაითვალისწინოთ, რომ ვერსია უნდა იყოს მითითებული ფორმატში Major.Minor.Patch.

ვერსიების სიისთვის, რომლებისთვისაც დადასტურება მხარდაჭერილია, გთხოვთ, იხილოთ JSON სქემა GitHub-ზე, რომელსაც Kubeval იყენებს ვალიდაციისთვის. თუ თქვენ გჭირდებათ kubeval-ის ოფლაინ გაშვება, ჩამოტვირთეთ სქემები და მიუთითეთ მათი ლოკალური მდებარეობა დროშის გამოყენებით --schema-location.

ცალკეული YAML ფაილების გარდა, kubeval-ს ასევე შეუძლია იმუშაოს დირექტორიებთან და stdin-თან.

გარდა ამისა, კუბევალი ადვილად ინტეგრირდება CI მილსადენში. ვისაც სურს ტესტების გაშვება მანიფესტების კლასტერში გაგზავნამდე მოხარული იქნება იცოდეს, რომ kubeval მხარს უჭერს სამ გამომავალ ფორმატს:

1. Ჩვეულებრივი ტექსტი;
2. JSON;
3. შეამოწმეთ რაიმე პროტოკოლი (TAP).

და ნებისმიერი ფორმატი შეიძლება გამოყენებულ იქნას გამომავალი შემდგომი ანალიზისთვის სასურველი ტიპის შედეგების შეჯამების შესაქმნელად.

kubeval-ის ერთ-ერთი ნაკლი არის ის, რომ ამჟამად მას არ შეუძლია შეამოწმოს შესაბამისობა მორგებული რესურსების განმარტებებთან (CRD). თუმცა, შესაძლებელია kubeval-ის კონფიგურაცია იგნორირება მათ.

Kubeval არის შესანიშნავი ინსტრუმენტი რესურსების შემოწმებისა და შეფასებისთვის; თუმცა, ხაზგასმით უნდა აღინიშნოს, რომ ტესტის ჩაბარება არ იძლევა გარანტიას, რომ რესურსი შეესაბამება საუკეთესო პრაქტიკას.

მაგალითად, ტეგის გამოყენებით latest კონტეინერში არ შეესაბამება საუკეთესო პრაქტიკას. თუმცა, კუბევალი ამას შეცდომად არ მიიჩნევს და არ აცნობებს. ანუ, ასეთი 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 გადის კუბევალის ტესტებს, ხოლო kube-score მიუთითებს შემდეგ ხარვეზებზე:

• მზადყოფნის შემოწმება არ არის კონფიგურირებული.
• არ არსებობს მოთხოვნები ან შეზღუდვები 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-score-ში: თქვენ არ შეგიძლიათ აირჩიოთ Kubernetes-ის სხვა ვერსია. ეს შეზღუდვა შეიძლება იყოს დიდი პრობლემა, თუ თქვენ აპირებთ თქვენი კლასტერის განახლებას ან თუ გაქვთ მრავალი კლასტერი K8-ის სხვადასხვა ვერსიით.

გთხოვთ გაითვალისწინოთ, რომ უკვე არის პრობლემა ამ შესაძლებლობის რეალიზაციის წინადადებით.

დამატებითი ინფორმაცია kube-score-ის შესახებ შეგიძლიათ იხილოთ აქ ოფიციალურ საიტზე.

Kube-score ტესტები შესანიშნავი ინსტრუმენტია საუკეთესო პრაქტიკის განსახორციელებლად, მაგრამ რა მოხდება, თუ ტესტში ცვლილებების შეტანა ან საკუთარი წესების დამატება გჭირდებათ? სამწუხაროდ, ამის გაკეთება შეუძლებელია.

Kube-score არ არის გაფართოებული: თქვენ არ შეგიძლიათ დაამატოთ მასში პოლიტიკა ან შეცვალოთ ისინი.

თუ თქვენ გჭირდებათ პერსონალური ტესტების დაწერა კომპანიის პოლიტიკებთან შესაბამისობის შესამოწმებლად, შეგიძლიათ გამოიყენოთ შემდეგი ოთხი ხელსაწყოდან ერთ-ერთი: config-lint, სპილენძი, 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. კონფიგურაციის წესი, რომელიც ასრულებს ასეთ შემოწმებას, ასე გამოიყურება:

- 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 არის ჩარჩო მანიფესტების დასადასტურებლად საბაჟო ტესტების გამოყენებით (კონფიგურაციის მსგავსი).

თუმცა, ის განსხვავდება ამ უკანასკნელისგან იმით, რომ ის არ იყენებს 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 გამოცდილების მქონეთათვის).

Copper-ის მთავარი უპირატესობა აშკარაა: თქვენ არ გჭირდებათ სპეციალიზებული ენის დაუფლება და შეგიძლიათ გამოიყენოთ JavaScript-ის სხვადასხვა ფუნქციები საკუთარი ტესტების შესაქმნელად, როგორიცაა სიმებიანი ინტერპოლაცია, ფუნქციები და ა.შ.

ასევე უნდა აღინიშნოს, რომ Copper-ის ამჟამინდელი ვერსია მუშაობს JavaScript ძრავის ES5 ვერსიით და არა ES6.

დეტალები ხელმისაწვდომია მისამართზე პროექტის ოფიციალური საიტი.

თუმცა, თუ ნამდვილად არ მოგწონთ JavaScript და უპირატესობას ანიჭებთ ენას, რომელიც სპეციალურად არის შემუშავებული მოთხოვნების შესაქმნელად და პოლიტიკის აღწერისთვის, ყურადღება უნდა მიაქციოთ კონკურსს.

5.კონკურსი

Conftest არის ჩარჩო კონფიგურაციის მონაცემების შესამოწმებლად. ასევე შესაფერისია Kubernetes-ის მანიფესტების შესამოწმებლად/შემოწმებისთვის. ტესტები აღწერილია სპეციალიზებული შეკითხვის ენის გამოყენებით Rego.

შეგიძლიათ დააინსტალიროთ კონკურსი გამოყენებით ინსტრუქციებიჩამოთვლილია პროექტის ვებსაიტზე.

ორიგინალური სტატიის დაწერის დროს, უახლესი ვერსია იყო 0.18.2.

კონფიგურაციისა და სპილენძის მსგავსად, კონფესტი მოდის ყოველგვარი ჩაშენებული ტესტების გარეშე. მოდით ვცადოთ და დავწეროთ ჩვენი საკუთარი პოლიტიკა. როგორც წინა მაგალითებში, ჩვენ შევამოწმებთ, არის თუ არა კონტეინერის სურათები აღებული სანდო წყაროდან.

შექმენით დირექტორია 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 Container Registry (ACR) ან თქვენი საკუთარი რეესტრი.

არტეფაქტის ფორმატი იგივეა, რაც გახსენით პოლიტიკის აგენტის პაკეტები (OPA), რომელიც საშუალებას გაძლევთ გამოიყენოთ კონფესტი ტესტების გასაშვებად არსებული OPA პაკეტებიდან.

თქვენ შეგიძლიათ გაიგოთ მეტი პოლიტიკის გაზიარებისა და კონკურსის სხვა მახასიათებლების შესახებ აქ პროექტის ოფიციალური საიტი.

6. Polaris

ბოლო ინსტრუმენტი, რომელიც ამ სტატიაში იქნება განხილული, არის Polaris. (მისი შარშანდელი განცხადება ჩვენ უკვე ნათარგმნი - დაახლ. თარგმანი)

Polaris შეიძლება დამონტაჟდეს კლასტერში ან გამოიყენოთ ბრძანების ხაზის რეჟიმში. როგორც თქვენ ალბათ მიხვდით, ის საშუალებას გაძლევთ სტატიკურად გააანალიზოთ Kubernetes მანიფესტები.

ბრძანების ხაზის რეჟიმში მუშაობისას, ხელმისაწვდომია ჩაშენებული ტესტები, რომლებიც მოიცავს ისეთ სფეროებს, როგორიცაა უსაფრთხოება და საუკეთესო პრაქტიკა (კუბე-ქულის მსგავსი). გარდა ამისა, თქვენ შეგიძლიათ შექმნათ თქვენი საკუთარი ტესტები (როგორც 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 სქემის გამოყენებით.

შემდეგი 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 წარმატებით დაასრულებს. ცვლილებების მანიფესტი უკვე შევიდა საცავებიასე რომ თქვენ შეგიძლიათ შეამოწმოთ წინა ბრძანება manifest-ზე 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 სქემას.

ასეთი განხილვის დასრულების შემდეგ, შეიძლება გადავიდეს უფრო დახვეწილ ტესტებზე, როგორიცაა სტანდარტული საუკეთესო პრაქტიკისა და კონკრეტული პოლიტიკის შესაბამისობა. სწორედ აქ გამოდგება კუბე-სკორი და პოლარისი.

მათთვის, ვისაც აქვს რთული მოთხოვნები და სჭირდება ტესტების დეტალურად მორგება, სპილენძი, კონფიგურაცია და კონფესტი შესაფერისი იქნება.

Conftest და config-lint იყენებს YAML-ს მორგებული ტესტების დასადგენად, ხოლო სპილენძი გაძლევთ წვდომას პროგრამირების სრულ ენაზე, რაც მას საკმაოდ მიმზიდველ არჩევანს ხდის.

მეორეს მხრივ, ღირს თუ არა რომელიმე ამ ხელსაწყოს გამოყენება და, შესაბამისად, ყველა ტესტის ხელით შექმნა, ან უპირატესობა მიანიჭეთ Polaris-ს და დაამატეთ მხოლოდ ის, რაც საჭიროა? ამ კითხვაზე მკაფიო პასუხი არ არსებობს.

ქვემოთ მოცემულ ცხრილში მოცემულია თითოეული ინსტრუმენტის მოკლე აღწერა:

Tool
მიზანი
შეზღუდვები
მომხმარებლის ტესტები

კუბევალი
ამოწმებს YAML მანიფესტებს API სქემის კონკრეტული ვერსიის მიხედვით
CRD-თან მუშაობა არ შეიძლება
არარის

კუბე-ქულა
აანალიზებს YAML მანიფესტებს საუკეთესო პრაქტიკის წინააღმდეგ
რესურსების შესამოწმებლად თქვენი Kubernetes API ვერსიის არჩევა შეუძლებელია
არარის

სპილენძის
ზოგადი ჩარჩო YAML მანიფესტებისთვის JavaScript ტესტების შესაქმნელად
არ არის ჩაშენებული ტესტები. ცუდი დოკუმენტაცია
დიახ

კონფიგურაცია-lint
ზოგადი ჩარჩო ტესტების შესაქმნელად დომენის სპეციფიკურ ენაზე, რომელიც ჩაშენებულია YAML-ში. მხარს უჭერს სხვადასხვა კონფიგურაციის ფორმატს (მაგ. Terraform)
მზა ტესტები არ არსებობს. ჩაშენებული მტკიცებები და ფუნქციები შეიძლება არ იყოს საკმარისი
დიახ

შეჯიბრი
ჩარჩო Rego-ს გამოყენებით (შეკითხვის სპეციალიზებული ენის) გამოყენებით საკუთარი ტესტების შესაქმნელად. საშუალებას აძლევს პოლიტიკის გაზიარებას OCI პაკეტების მეშვეობით
არ არის ჩაშენებული ტესტები. რეგო უნდა ვისწავლო. Docker Hub არ არის მხარდაჭერილი წესების გამოქვეყნებისას
დიახ

Polaris
მიმოხილვები YAML გამოიხატება სტანდარტული საუკეთესო პრაქტიკის წინააღმდეგ. საშუალებას გაძლევთ შექმნათ თქვენი საკუთარი ტესტები JSON სქემის გამოყენებით
JSON Schema-ზე დაფუძნებული ტესტის შესაძლებლობები შეიძლება არ იყოს საკმარისი
დიახ

იმის გამო, რომ ეს ხელსაწყოები არ ეყრდნობა კუბერნეტის კლასტერზე წვდომას, მათი ინსტალაცია მარტივია. ისინი საშუალებას გაძლევთ გაფილტროთ წყარო ფაილები და მიაწოდოთ სწრაფი გამოხმაურება პროექტებში მოთხოვნის ავტორებს.

PS მთარგმნელისგან

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «Polaris დაინერგა Kubernetes-ის კლასტერების ჯანმრთელობის შესანარჩუნებლად";
• «Vim YAML მხარდაჭერით Kubernetes-ისთვის";
• «კონტეინერების გამოყენების 7 საუკეთესო პრაქტიკა Google-ის მიხედვით".

წყარო: www.habr.com