🥇Επικύρωση του Kubernetes YAML έναντι των βέλτιστων πρακτικών και πολιτικών

Σημείωση. μετάφρ.: Με τον αυξανόμενο αριθμό των διαμορφώσεων YAML για περιβάλλοντα K8s, η ανάγκη για την αυτοματοποιημένη επαλήθευσή τους γίνεται όλο και πιο επιτακτική. Ο συντάκτης αυτής της κριτικής όχι μόνο επέλεξε υπάρχουσες λύσεις για αυτήν την εργασία, αλλά χρησιμοποίησε επίσης την Ανάπτυξη ως παράδειγμα για να δει πώς λειτουργούν. Αποδείχθηκε πολύ κατατοπιστικό για όσους ενδιαφέρονται για αυτό το θέμα.

TL? DR: Αυτό το άρθρο συγκρίνει έξι στατικά εργαλεία για την επικύρωση και την αξιολόγηση των αρχείων YAML Kubernetes σε σχέση με τις βέλτιστες πρακτικές και απαιτήσεις.

Οι φόρτοι εργασίας του Kubernetes συνήθως ορίζονται με τη μορφή εγγράφων YAML. Ένα από τα προβλήματα με το YAML είναι η δυσκολία καθορισμού περιορισμών ή σχέσεων μεταξύ αρχείων δήλωσης.

Τι γίνεται αν πρέπει να βεβαιωθούμε ότι όλες οι εικόνες που αναπτύσσονται στο σύμπλεγμα προέρχονται από ένα αξιόπιστο μητρώο;

Πώς μπορώ να αποτρέψω την αποστολή στο σύμπλεγμα αναπτύξεων που δεν έχουν PodDisruptionBudgets;

Η ενσωμάτωση στατικών δοκιμών σάς επιτρέπει να εντοπίζετε σφάλματα και παραβιάσεις πολιτικής στο στάδιο ανάπτυξης. Αυτό αυξάνει την εγγύηση ότι οι ορισμοί των πόρων είναι σωστοί και ασφαλείς και καθιστά πιο πιθανό ότι ο φόρτος εργασίας παραγωγής θα ακολουθήσει τις βέλτιστες πρακτικές.

Το οικοσύστημα επιθεώρησης αρχείων Kubernetes στατικού YAML μπορεί να χωριστεί στις ακόλουθες κατηγορίες:

Επαληθευτές API. Τα εργαλεία αυτής της κατηγορίας ελέγχουν το μανιφέστο YAML σε σχέση με τις απαιτήσεις του διακομιστή API Kubernetes.
Έτοιμοι δοκιμαστές. Τα εργαλεία αυτής της κατηγορίας συνοδεύονται από έτοιμα τεστ ασφάλειας, συμμόρφωσης με βέλτιστες πρακτικές κ.λπ.
Προσαρμοσμένοι επικυρωτές. Οι εκπρόσωποι αυτής της κατηγορίας σάς επιτρέπουν να δημιουργείτε προσαρμοσμένα τεστ σε διάφορες γλώσσες, για παράδειγμα, Rego και Javascript.

Σε αυτό το άρθρο θα περιγράψουμε και θα συγκρίνουμε έξι διαφορετικά εργαλεία:

kubeval;
kube-score?
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.

Το μανιφέστο περιγράφει μια εφαρμογή Ιστού της οποίας το κύριο καθήκον είναι να απαντήσει με ένα μήνυμα "Hello World" στη θύρα 5678. Μπορεί να αναπτυχθεί με την ακόλουθη εντολή:

kubectl apply -f hello-world.yaml

Και έτσι - ελέγξτε την εργασία:

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

Τώρα πηγαίνετε στο http://localhost:8080 και επιβεβαιώστε ότι η εφαρμογή λειτουργεί. Αλλά ακολουθεί τις βέλτιστες πρακτικές; Ας ελέγξουμε.

1. Kubeval

Στην καρδιά kubeval Η ιδέα είναι ότι οποιαδήποτε αλληλεπίδραση με το Kubernetes λαμβάνει χώρα μέσω του REST API του. Με άλλα λόγια, μπορείτε να χρησιμοποιήσετε ένα σχήμα API για να ελέγξετε εάν ένα δεδομένο YAML συμμορφώνεται με αυτό. Ας δούμε ένα παράδειγμα.

Οδηγίες Εγκατάστασης kubeval είναι διαθέσιμα στον ιστότοπο του έργου.

Κατά τη σύνταξη του αρχικού άρθρου, ήταν διαθέσιμη η έκδοση 0.15.0.

Μόλις εγκατασταθεί, ας το τροφοδοτήσουμε με το μανιφέστο παραπάνω:

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

Εάν είναι επιτυχής, το kubeval θα βγει με κωδικό εξόδου 0. Μπορείτε να το ελέγξετε ως εξής:

$ echo $?
0

Ας δοκιμάσουμε τώρα το kubeval με ένα διαφορετικό μανιφέστο:

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

(kubeval-invalid.yaml)

Μπορείτε να εντοπίσετε το πρόβλημα με το μάτι; Ας ξεκινήσουμε:

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

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

Ο πόρος δεν επαληθεύεται.

Αναπτύξεις που χρησιμοποιούν την έκδοση API apps/v1, πρέπει να περιλαμβάνει έναν επιλογέα που ταιριάζει με την ετικέτα του 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

Αυτό ακριβώς είναι το λάθος για το οποίο προειδοποίησε η kubeval. Μπορείτε να το διορθώσετε προσθέτοντας έναν επιλογέα:

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 ελέγχει τους πόρους έναντι του πιο πρόσφατου σχήματος API Kubernetes. Ωστόσο, στις περισσότερες περιπτώσεις μπορεί να χρειαστεί να ελέγξετε για μια συγκεκριμένη έκδοση του Kubernetes. Αυτό μπορεί να γίνει χρησιμοποιώντας τη σημαία --kubernetes-version:

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

Λάβετε υπόψη ότι η έκδοση πρέπει να προσδιορίζεται στη μορφή Major.Minor.Patch.

Για μια λίστα εκδόσεων για τις οποίες υποστηρίζεται η επαλήθευση, ανατρέξτε στο Σχήμα JSON στο GitHub, το οποίο χρησιμοποιεί το kubeval για επικύρωση. Εάν πρέπει να εκτελέσετε το kubeval εκτός σύνδεσης, κατεβάστε τα σχήματα και καθορίστε την τοπική τους τοποθεσία χρησιμοποιώντας τη σημαία --schema-location.

Εκτός από μεμονωμένα αρχεία YAML, το kubeval μπορεί επίσης να λειτουργήσει με καταλόγους και stdin.

Επιπλέον, το Kubeval ενσωματώνεται εύκολα στον αγωγό CI. Όσοι επιθυμούν να εκτελέσουν δοκιμές πριν στείλουν δηλώσεις στο σύμπλεγμα θα χαρούν να γνωρίζουν ότι το kubeval υποστηρίζει τρεις μορφές εξόδου:

Απλό κείμενο;
JSON;
Test Anything Protocol (TAP).

Και οποιαδήποτε από τις μορφές μπορεί να χρησιμοποιηθεί για περαιτέρω ανάλυση της εξόδου για τη δημιουργία μιας σύνοψης των αποτελεσμάτων του επιθυμητού τύπου.

Ένα από τα μειονεκτήματα του kubeval είναι ότι επί του παρόντος δεν μπορεί να ελέγξει τη συμμόρφωση με τους Προσαρμοσμένους Ορισμούς Πόρων (CRD). Ωστόσο, είναι δυνατή η διαμόρφωση του kubeval αγνόησέ τους.

Το Kubeval είναι ένα εξαιρετικό εργαλείο για τον έλεγχο και την αξιολόγηση των πόρων. Ωστόσο, πρέπει να τονιστεί ότι η επιτυχία του τεστ δεν εγγυάται ότι ο πόρος συμμορφώνεται με τις βέλτιστες πρακτικές.

Για παράδειγμα, χρησιμοποιώντας την ετικέτα latest σε δοχείο δεν ακολουθεί τις βέλτιστες πρακτικές. Ωστόσο, η kubeval δεν το θεωρεί σφάλμα και δεν το αναφέρει. Δηλαδή, η επαλήθευση αυτού του YAML θα ολοκληρωθεί χωρίς προειδοποιήσεις.

Τι γίνεται όμως αν θέλετε να αξιολογήσετε το YAML και να εντοπίσετε παραβιάσεις όπως η ετικέτα latest? Πώς μπορώ να ελέγξω ένα αρχείο YAML σε σχέση με τις βέλτιστες πρακτικές;

2. Kube-score

Kube-score αναλύει τις εκδηλώσεις YAML και τις αξιολογεί έναντι ενσωματωμένων δοκιμών. Αυτές οι δοκιμές επιλέγονται με βάση τις οδηγίες ασφαλείας και τις βέλτιστες πρακτικές, όπως:

Λειτουργία του δοχείου όχι ως root.
Διαθεσιμότητα υγειονομικών ελέγχων λοβών.
Ορισμός αιτημάτων και ορίων για πόρους.

Με βάση τα αποτελέσματα των δοκιμών, δίνονται τρία αποτελέσματα: OK, ΠΡΟΕΙΔΟΠΟΙΗΣΗ и ΚΡΙΣΙΜΟΣ.

Μπορείτε να δοκιμάσετε το Kube-score online ή να το εγκαταστήσετε τοπικά.

Τη στιγμή της συγγραφής του αρχικού άρθρου, η τελευταία έκδοση του kube-score ήταν 1.7.0.

Ας το δοκιμάσουμε στο μανιφέστο μας base-valid.yaml:

$ kube-score score base-valid.yaml

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

Το YAML περνά τις δοκιμές kubeval, ενώ το kube-score δείχνει τα ακόλουθα ελαττώματα:

Οι έλεγχοι ετοιμότητας δεν έχουν διαμορφωθεί.
Δεν υπάρχουν αιτήματα ή όρια για πόρους και μνήμη 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 μπορείτε να βρείτε στο επίσημη ιστοσελίδα.

Τα τεστ Kube-score είναι ένα εξαιρετικό εργαλείο για την εφαρμογή βέλτιστων πρακτικών, αλλά τι γίνεται αν χρειαστεί να κάνετε αλλαγές στο τεστ ή να προσθέσετε τους δικούς σας κανόνες; Αλίμονο, αυτό δεν μπορεί να γίνει.

Το Kube-score δεν είναι επεκτάσιμο: δεν μπορείτε να προσθέσετε πολιτικές σε αυτό ή να τις προσαρμόσετε.

Εάν χρειάζεται να γράψετε προσαρμοσμένες δοκιμές για να επαληθεύσετε τη συμμόρφωση με τις πολιτικές της εταιρείας, μπορείτε να χρησιμοποιήσετε ένα από τα ακόλουθα τέσσερα εργαλεία: config-lint, copper, conftest ή 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 manifests αυτό είναι πάντα Kubernetes.
Στο πεδίο files Εκτός από τα ίδια τα αρχεία, μπορείτε να καθορίσετε έναν κατάλογο.
Πεδίο rules προορίζεται για τη ρύθμιση δοκιμών χρήστη.

Ας υποθέσουμε ότι θέλετε να βεβαιωθείτε ότι οι εικόνες στο Deployment λαμβάνονται πάντα από ένα αξιόπιστο χώρο αποθήκευσης όπως my-company.com/myapp:1.0. Ένας κανόνας config-lint που εκτελεί έναν τέτοιο έλεγχο θα μοιάζει με αυτό:

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

(rule-trusted-repo.yaml)

Κάθε κανόνας πρέπει να έχει τα ακόλουθα χαρακτηριστικά:

id — μοναδικό αναγνωριστικό του κανόνα·
severity - Μπορεί ΑΠΟΤΥΧΙΑ, ΠΡΟΕΙΔΟΠΟΙΗΣΗ и ΜΗ ΣΥΜΒΑΤΟ;
message — εάν παραβιαστεί ένας κανόνας, εμφανίζεται το περιεχόμενο αυτής της γραμμής.
resource — τον τύπο του πόρου για τον οποίο εφαρμόζεται αυτός ο κανόνας·
assertions — μια λίστα συνθηκών που θα αξιολογηθούν σε σχέση με αυτόν τον πόρο.

Στον παραπάνω κανόνα assertion καλείται every ελέγχει ότι όλα τα κοντέινερ είναι σε ανάπτυξη (key: spec.templates.spec.containers) χρησιμοποιήστε αξιόπιστες εικόνες (δηλαδή ξεκινώντας από my-company.com/).

Το πλήρες σύνολο κανόνων μοιάζει με αυτό:

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

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

(ruleset.yaml)

Για να δοκιμάσουμε το τεστ, ας το αποθηκεύσουμε ως check_image_repo.yaml. Ας κάνουμε έναν έλεγχο στο αρχείο base-valid.yaml:

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

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

Ο έλεγχος απέτυχε. Τώρα ας δούμε το παρακάτω μανιφέστο με το σωστό χώρο αποθήκευσης εικόνων:

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

(image-valid-mycompany.yaml)

Εκτελούμε το ίδιο τεστ με το παραπάνω μανιφέστο. Δεν βρέθηκαν προβλήματα:

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

Το Config-lint είναι ένα πολλά υποσχόμενο πλαίσιο που σας επιτρέπει να δημιουργήσετε τις δικές σας δοκιμές για την επικύρωση των εκδηλώσεων YAML Kubernetes χρησιμοποιώντας το YAML DSL.

Τι γίνεται όμως αν χρειάζεστε πιο περίπλοκη λογική και δοκιμές; Δεν είναι το YAML πολύ περιορισμένο για αυτό; Τι θα γινόταν αν μπορούσατε να δημιουργήσετε τεστ σε μια πλήρη γλώσσα προγραμματισμού;

4. Χαλκός

Χαλκός V2 είναι ένα πλαίσιο για την επικύρωση δηλώσεων χρησιμοποιώντας προσαρμοσμένες δοκιμές (παρόμοιο με το config-lint).

Ωστόσο, διαφέρει από το τελευταίο στο ότι δεν χρησιμοποιεί YAML για την περιγραφή των δοκιμών. Αντίθετα, οι δοκιμές μπορούν να γραφτούν σε JavaScript. Το Copper παρέχει μια βιβλιοθήκη με πολλά βασικά εργαλεία, που σας βοηθούν να διαβάσετε πληροφορίες σχετικά με αντικείμενα Kubernetes και να αναφέρετε σφάλματα.

Μπορείτε να βρείτε τα βήματα για την εγκατάσταση του Copper επίσημη τεκμηρίωση.

Το 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 ή απορρίπτοντας τα pod που εκτελούνται σε προνομιακή λειτουργία.

Ο χαλκός έχει διάφορες χρηστικές λειτουργίες ενσωματωμένες σε αυτόν:

DockerImage διαβάζει το καθορισμένο αρχείο εισόδου και δημιουργεί ένα αντικείμενο με τα ακόλουθα χαρακτηριστικά:
- name - όνομα της εικόνας,
- tag - ετικέτα εικόνας,
- registry - μητρώο εικόνων,
- registry_url - πρωτόκολλο (https://) και μητρώο εικόνων,
- fqin — πλήρης θέση της εικόνας.
Λειτουργία findByName βοηθά στην εύρεση ενός πόρου ανά συγκεκριμένο τύπο (kind) και όνομα (name) από το αρχείο εισόδου.
Λειτουργία findByLabels βοηθά στην εύρεση ενός πόρου ανά συγκεκριμένο τύπο (kind) και ετικέτες (labels).

Μπορείτε να δείτε όλες τις διαθέσιμες λειτουργίες υπηρεσίας εδώ.

Από προεπιλογή, φορτώνει ολόκληρο το αρχείο εισόδου YAML σε μια μεταβλητή $$ και το καθιστά διαθέσιμο για scripting (μια οικεία τεχνική για όσους έχουν εμπειρία jQuery).

Το κύριο πλεονέκτημα του Copper είναι προφανές: δεν χρειάζεται να κατέχετε μια εξειδικευμένη γλώσσα και μπορείτε να χρησιμοποιήσετε διάφορες λειτουργίες JavaScript για να δημιουργήσετε τα δικά σας τεστ, όπως παρεμβολή συμβολοσειρών, συναρτήσεις κ.λπ.

Θα πρέπει επίσης να σημειωθεί ότι η τρέχουσα έκδοση του Copper λειτουργεί με την έκδοση ES5 της μηχανής JavaScript και όχι με την έκδοση ES6.

Λεπτομέρειες διαθέσιμες στο την επίσημη ιστοσελίδα του έργου.

Ωστόσο, εάν δεν σας αρέσει πολύ η JavaScript και προτιμάτε μια γλώσσα ειδικά σχεδιασμένη για τη δημιουργία ερωτημάτων και την περιγραφή πολιτικών, θα πρέπει να δώσετε προσοχή στη διαμάχη.

5.Διαγωνισμός

Το Conftest είναι ένα πλαίσιο για τη δοκιμή δεδομένων διαμόρφωσης. Κατάλληλο επίσης για δοκιμή/επαλήθευση εκδηλώσεων Kubernetes. Οι δοκιμές περιγράφονται χρησιμοποιώντας μια εξειδικευμένη γλώσσα ερωτημάτων Rego.

Μπορείτε να εγκαταστήσετε το contest χρησιμοποιώντας οδηγίεςαναφέρονται στον ιστότοπο του έργου.

Τη στιγμή της συγγραφής του αρχικού άρθρου, η τελευταία διαθέσιμη έκδοση ήταν η 0.18.2.

Παρόμοια με το config-lint και το copper, το conftest έρχεται χωρίς ενσωματωμένες δοκιμές. Ας το δοκιμάσουμε και ας γράψουμε τη δική μας πολιτική. Όπως και στα προηγούμενα παραδείγματα, θα ελέγξουμε εάν οι εικόνες του κοντέινερ έχουν ληφθεί από αξιόπιστη πηγή.

Δημιουργήστε έναν κατάλογο 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 πολλά, το conftest τα ελέγχει ανεξάρτητα το ένα από το άλλο και η αλήθεια οποιουδήποτε από τα μπλοκ αντιμετωπίζεται ως παραβίαση.

Εκτός από την προεπιλεγμένη έξοδο, το conftest υποστηρίζει μορφή JSON, TAP και πίνακα - μια εξαιρετικά χρήσιμη δυνατότητα εάν χρειάζεται να ενσωματώσετε αναφορές σε μια υπάρχουσα διοχέτευση CI. Μπορείτε να ορίσετε την επιθυμητή μορφή χρησιμοποιώντας τη σημαία --output.

Για να διευκολυνθεί ο εντοπισμός σφαλμάτων πολιτικών, το conftest έχει μια σημαία --trace. Παράγει ένα ίχνος του τρόπου με τον οποίο το conftest αναλύει τα καθορισμένα αρχεία πολιτικής.

Οι πολιτικές του διαγωνισμού μπορούν να δημοσιεύονται και να κοινοποιούνται σε μητρώα 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) ή το δικό σας μητρώο.

Η μορφή artifact είναι η ίδια με Ανοίξτε τα πακέτα Policy Agent (OPA), το οποίο σας επιτρέπει να χρησιμοποιήσετε το conftest για να εκτελέσετε δοκιμές από υπάρχοντα πακέτα OPA.

Μπορείτε να μάθετε περισσότερα σχετικά με την κοινή χρήση πολιτικών και άλλες δυνατότητες του conftest στο την επίσημη ιστοσελίδα του έργου.

6. Polaris

Το τελευταίο εργαλείο που θα συζητηθεί σε αυτό το άρθρο είναι Polaris. (Η περσινή του ανακοίνωση εμείς ήδη μεταφρασμένο - περίπου. μετάφραση)

Το Polaris μπορεί να εγκατασταθεί σε ένα σύμπλεγμα ή να χρησιμοποιηθεί σε λειτουργία γραμμής εντολών. Όπως μπορεί να έχετε μαντέψει, σας επιτρέπει να αναλύετε στατικά εκδηλώσεις Kubernetes.

Όταν εκτελείται σε λειτουργία γραμμής εντολών, είναι διαθέσιμες ενσωματωμένες δοκιμές που καλύπτουν τομείς όπως η ασφάλεια και οι βέλτιστες πρακτικές (παρόμοια με το kube-score). Επιπλέον, μπορείτε να δημιουργήσετε τα δικά σας τεστ (όπως στο config-lint, copper και conftest).

Με άλλα λόγια, το 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 Μπορείτε να τερματίσετε την εργασία με μη μηδενικό κωδικό χρησιμοποιώντας δύο σημαίες:

Σημαία --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 είναι διαθέσιμες στη διεύθυνση τοποθεσία έργου.

Περίληψη

Ενώ υπάρχουν πολλά διαθέσιμα εργαλεία για την επιθεώρηση και αξιολόγηση των αρχείων YAML Kubernetes, Είναι σημαντικό να έχουμε σαφή κατανόηση του τρόπου σχεδιασμού και εκτέλεσης των δοκιμών.

Για παράδειγμα, αν πάρετε τα μανιφέστα Kubernetes που περνούν από έναν αγωγό, το kubeval θα μπορούσε να είναι το πρώτο βήμα σε έναν τέτοιο αγωγό. Θα παρακολουθούσε εάν οι ορισμοί αντικειμένων συμμορφώνονται με το σχήμα Kubernetes API.

Μόλις ολοκληρωθεί μια τέτοια αναθεώρηση, θα μπορούσε κανείς να προχωρήσει σε πιο εξελιγμένες δοκιμές, όπως η συμμόρφωση με τυπικές βέλτιστες πρακτικές και συγκεκριμένες πολιτικές. Εδώ θα ήταν χρήσιμο το kube-score και ο Polaris.

Για όσους έχουν πολύπλοκες απαιτήσεις και πρέπει να προσαρμόσουν λεπτομερώς τις δοκιμές, ο χαλκός, το config-lint και το conftest θα ήταν κατάλληλα.

Το Conftest και το config-lint χρησιμοποιούν το YAML για να ορίσουν προσαρμοσμένες δοκιμές και το copper σάς δίνει πρόσβαση σε μια πλήρη γλώσσα προγραμματισμού, καθιστώντας το μια αρκετά ελκυστική επιλογή.

Από την άλλη πλευρά, αξίζει να χρησιμοποιήσετε ένα από αυτά τα εργαλεία και, επομένως, να δημιουργήσετε όλα τα τεστ χειροκίνητα ή να προτιμήσετε το Polaris και να προσθέσετε μόνο ό,τι χρειάζεται; Δεν υπάρχει σαφής απάντηση σε αυτό το ερώτημα.

Ο παρακάτω πίνακας παρέχει μια σύντομη περιγραφή κάθε εργαλείου:

Εργαλείο
Σκοπός
Περιορισμοί
Δοκιμές χρήστη

kubeval
Επικυρώνει τις εκδηλώσεις YAML έναντι μιας συγκεκριμένης έκδοσης του σχήματος API
Δεν μπορεί να λειτουργήσει με CRD
Όχι

kube-score
Αναλύει τις εκδηλώσεις YAML έναντι των βέλτιστων πρακτικών
Δεν είναι δυνατή η επιλογή της έκδοσης του Kubernetes API για έλεγχο των πόρων
Όχι

χαλκός
Ένα γενικό πλαίσιο για τη δημιουργία προσαρμοσμένων δοκιμών JavaScript για δηλώσεις YAML
Χωρίς ενσωματωμένες δοκιμές. Κακή τεκμηρίωση
Ναί

config-lint
Ένα γενικό πλαίσιο για τη δημιουργία δοκιμών σε γλώσσα συγκεκριμένης περιοχής ενσωματωμένη στο YAML. Υποστηρίζει διάφορες μορφές διαμόρφωσης (π.χ. Terraform)
Δεν υπάρχουν έτοιμα τεστ. Οι ενσωματωμένες δηλώσεις και λειτουργίες μπορεί να μην είναι αρκετές
Ναί

διαγωνισμός
Ένα πλαίσιο για τη δημιουργία των δικών σας δοκιμών χρησιμοποιώντας Rego (μια εξειδικευμένη γλώσσα ερωτημάτων). Επιτρέπει την κοινή χρήση πολιτικών μέσω πακέτων OCI
Χωρίς ενσωματωμένες δοκιμές. Πρέπει να μάθω Rego. Το Docker Hub δεν υποστηρίζεται κατά τη δημοσίευση πολιτικών
Ναί

Polaris
Κριτικές Το YAML εκδηλώνεται σε σχέση με τις τυπικές βέλτιστες πρακτικές. Σας επιτρέπει να δημιουργήσετε τις δικές σας δοκιμές χρησιμοποιώντας το σχήμα JSON
Οι δυνατότητες δοκιμής που βασίζονται στο σχήμα JSON ενδέχεται να μην είναι επαρκείς
Ναί

Επειδή αυτά τα εργαλεία δεν βασίζονται στην πρόσβαση στο σύμπλεγμα Kubernetes, είναι εύκολο να εγκατασταθούν. Σας επιτρέπουν να φιλτράρετε τα αρχεία προέλευσης και να παρέχετε γρήγορη ανατροφοδότηση στους συντάκτες των αιτημάτων έλξης σε έργα.

ΥΓ από τον μεταφραστή

Διαβάστε επίσης στο blog μας:

Πηγή: www.habr.com

Επικυρώστε το Kubernetes YAML έναντι των βέλτιστων πρακτικών και πολιτικών