Kubernetes YAML सर्वोत्तम पद्धती आणि धोरणांविरुद्ध प्रमाणित करा

नोंद. अनुवाद: K8s वातावरणासाठी YAML कॉन्फिगरेशनच्या वाढत्या संख्येसह, त्यांच्या स्वयंचलित पडताळणीची गरज अधिकाधिक निकड होत आहे. या पुनरावलोकनाच्या लेखकाने या कार्यासाठी केवळ विद्यमान उपाय निवडले नाहीत तर ते कसे कार्य करतात हे पाहण्यासाठी उदाहरण म्हणून उपयोजन देखील वापरले. ज्यांना या विषयात रस आहे त्यांच्यासाठी हे खूप माहितीपूर्ण ठरले.

TL; डॉ: हा लेख सर्वोत्तम पद्धती आणि आवश्यकतांनुसार Kubernetes YAML फाइल्सचे प्रमाणीकरण आणि मूल्यमापन करण्यासाठी सहा स्थिर साधनांची तुलना करतो.

Kubernetes वर्कलोड्स सामान्यत: YAML दस्तऐवजांच्या स्वरूपात परिभाषित केले जातात. YAML मधील समस्यांपैकी एक म्हणजे मॅनिफेस्ट फाइल्समधील मर्यादा किंवा संबंध निर्दिष्ट करण्यात अडचण.

क्लस्टरमध्ये उपयोजित केलेल्या सर्व प्रतिमा विश्वासार्ह रेजिस्ट्रीमधून आल्याची खात्री करायची असल्यास काय?

PodDisruptionBudgets नसलेल्या उपयोजनांना मी क्लस्टरला पाठवण्यापासून कसे रोखू शकतो?

स्थिर चाचणीचे एकत्रीकरण तुम्हाला विकासाच्या टप्प्यावर त्रुटी आणि धोरणांचे उल्लंघन ओळखण्यास अनुमती देते. हे संसाधन व्याख्या योग्य आणि सुरक्षित असल्याची हमी वाढवते आणि उत्पादन वर्कलोड सर्वोत्तम पद्धतींचे पालन करतील अशी अधिक शक्यता निर्माण करते.

Kubernetes स्थिर YAML फाइल तपासणी इकोसिस्टम खालील श्रेणींमध्ये विभागली जाऊ शकते:

• API प्रमाणीकरणकर्ते. या वर्गातील साधने कुबर्नेट्स API सर्व्हरच्या आवश्यकतांनुसार YAML मॅनिफेस्ट तपासतात.
• तयार परीक्षक. या श्रेणीतील साधने सुरक्षिततेसाठी, सर्वोत्तम पद्धतींचे पालन इत्यादींसाठी तयार केलेल्या चाचण्यांसह येतात.
• सानुकूल सत्यापनकर्ते. या श्रेणीचे प्रतिनिधी तुम्हाला विविध भाषांमध्ये सानुकूल चाचण्या तयार करण्याची परवानगी देतात, उदाहरणार्थ, रेगो आणि जावास्क्रिप्ट.

या लेखात आम्ही सहा वेगवेगळ्या साधनांचे वर्णन आणि तुलना करू:

1. कुबेवल;
2. kube-स्कोअर;
3. config-lint;
4. तांबे;
5. स्पर्धा
6. पोलारिस.

बरं, चला सुरुवात करूया!

उपयोजन तपासत आहे

आपण साधनांची तुलना सुरू करण्यापूर्वी, त्यांची चाचणी घेण्यासाठी काही पार्श्वभूमी तयार करूया.

खालील घोषणापत्रामध्ये अनेक त्रुटी आणि सर्वोत्तम पद्धतींचे पालन न करणे समाविष्ट आहे: त्यापैकी किती तुम्हाला सापडतील?

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

(base-valid.yaml)

आम्ही वेगवेगळ्या साधनांची तुलना करण्यासाठी या YAML चा वापर करू.

वरील जाहीरनामा base-valid.yaml आणि या लेखातील इतर घोषणापत्रे यामध्ये आढळू शकतात Git भांडार.

मॅनिफेस्ट एका वेब ऍप्लिकेशनचे वर्णन करतो ज्याचे मुख्य कार्य पोर्ट 5678 वर "हॅलो वर्ल्ड" संदेशासह प्रतिसाद देणे आहे. ते खालील आदेशासह तैनात केले जाऊ शकते:

kubectl apply -f hello-world.yaml

आणि म्हणून - काम तपासा:

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

आता जा http://localhost:8080 आणि अनुप्रयोग कार्य करत असल्याची पुष्टी करा. पण ते सर्वोत्तम पद्धतींचे पालन करते का? चला तपासूया.

1. कुबेवल

च्या हृदयात कुबेवल कल्पना अशी आहे की कुबर्नेट्सशी कोणताही संवाद त्याच्या REST API द्वारे होतो. दुस-या शब्दात, दिलेल्या YAML त्याच्याशी सुसंगत आहे की नाही हे तपासण्यासाठी तुम्ही API स्कीमा वापरू शकता. एक उदाहरण पाहू.

स्थापना सूचना kubeval प्रकल्पाच्या वेबसाइटवर उपलब्ध आहेत.

मूळ लेख लिहिण्याच्या वेळी, आवृत्ती 0.15.0 उपलब्ध होती.

एकदा इन्स्टॉल केल्यानंतर, वरील मॅनिफेस्टला फीड करूया:

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

यशस्वी झाल्यास, कुबेवल एक्झिट कोड 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)

कुबेवल सारख्या साधनांचा फायदा असा आहे की यासारख्या त्रुटी उपयोजन चक्रात लवकर पकडल्या जाऊ शकतात.

याव्यतिरिक्त, या तपासण्यांना क्लस्टरमध्ये प्रवेश आवश्यक नाही; ते ऑफलाइन केले जाऊ शकतात.

डीफॉल्टनुसार, कुबेवल नवीनतम Kubernetes API स्कीमा विरुद्ध संसाधने तपासते. तथापि, बर्‍याच प्रकरणांमध्ये आपल्याला विशिष्ट कुबर्नेट्स रिलीझ विरूद्ध तपासण्याची आवश्यकता असू शकते. हे ध्वज वापरून केले जाऊ शकते --kubernetes-version:

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

कृपया लक्षात ठेवा की आवृत्ती फॉरमॅटमध्ये निर्दिष्ट करणे आवश्यक आहे Major.Minor.Patch.

आवृत्त्यांच्या सूचीसाठी ज्यासाठी सत्यापन समर्थित आहे, कृपया पहा GitHub वर JSON स्कीमा, जे कुबेवाल प्रमाणीकरणासाठी वापरतात. तुम्हाला कुबेवल ऑफलाइन चालवायचे असल्यास, स्कीमा डाउनलोड करा आणि ध्वज वापरून त्यांचे स्थानिक स्थान निर्दिष्ट करा --schema-location.

वैयक्तिक YAML फाइल्स व्यतिरिक्त, kubeval निर्देशिका आणि stdin सह देखील कार्य करू शकते.

याव्यतिरिक्त, कुबेवल सहजपणे सीआय पाइपलाइनमध्ये समाकलित होते. क्लस्टरला मॅनिफेस्ट पाठवण्यापूर्वी चाचण्या चालवण्याची इच्छा असलेल्यांना हे जाणून आनंद होईल की कुबेवल तीन आउटपुट फॉरमॅटला सपोर्ट करतो:

1. साधा मजकूर;
2. JSON;
3. एनीथिंग प्रोटोकॉल (टॅप) चाचणी करा.

आणि इच्छित प्रकाराच्या परिणामांचा सारांश तयार करण्यासाठी आउटपुटच्या पुढील विश्लेषणासाठी कोणतेही स्वरूप वापरले जाऊ शकते.

कुबेवलच्या त्रुटींपैकी एक म्हणजे ते सध्या कस्टम रिसोर्स डेफिनिशन (CRDs) चे अनुपालन तपासू शकत नाही. तथापि, कुबेवल कॉन्फिगर करणे शक्य आहे त्यांच्याकडे दुर्लक्ष करा.

कुबेवल हे संसाधने तपासण्यासाठी आणि मूल्यमापन करण्यासाठी एक उत्तम साधन आहे; तथापि, यावर जोर दिला पाहिजे की चाचणी उत्तीर्ण केल्याने संसाधन सर्वोत्तम पद्धतींचे पालन करते याची हमी देत ​​नाही.

उदाहरणार्थ, टॅग वापरणे latest कंटेनरमध्ये सर्वोत्तम पद्धतींचे पालन करत नाही. मात्र, कुबेवाल याला त्रुटी मानत नाहीत आणि तक्रार करत नाहीत. म्हणजेच, अशा YAML चे सत्यापन चेतावणीशिवाय पूर्ण होईल.

पण तुम्हाला YAML चे मूल्यमापन करायचे असेल आणि टॅगसारखे उल्लंघन ओळखायचे असेल तर? latest? सर्वोत्तम पद्धतींविरुद्ध मी YAML फाइल कशी तपासू?

2. कुबे-स्कोअर

कुबे-स्कोअर YAML मॅनिफेस्ट पार्स करते आणि अंगभूत चाचण्यांविरूद्ध त्यांचे मूल्यांकन करते. या चाचण्या सुरक्षा मार्गदर्शक तत्त्वे आणि सर्वोत्तम पद्धतींवर आधारित निवडल्या जातात, जसे की:

• रूट म्हणून नाही कंटेनर चालवणे.
• पॉड आरोग्य तपासणीची उपलब्धता.
• संसाधनांसाठी विनंत्या आणि मर्यादा सेट करणे.

चाचणी परिणामांवर आधारित, तीन परिणाम दिले जातात: OK, चेतावणी и गंभीर.

तुम्ही कुबे-स्कोअर ऑनलाइन वापरून पाहू शकता किंवा स्थानिक पातळीवर स्थापित करू शकता.

मूळ लेख लिहिण्याच्या वेळी, कुबे-स्कोअरची नवीनतम आवृत्ती 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-स्कोअर खालील त्रुटींकडे निर्देश करते:

• तयारी तपासणी कॉन्फिगर केलेली नाही.
• 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

कुबेवल प्रमाणेच, कुबे-स्कोअर एक नॉन-झिरो एक्झिट कोड परत करतो जेव्हा एखादी चाचणी अपयशी ठरते गंभीर. आपण यासाठी समान प्रक्रिया सक्षम देखील करू शकता चेतावणी.

याव्यतिरिक्त, वेगवेगळ्या API आवृत्त्यांसह (कुबेवल प्रमाणे) अनुपालनासाठी संसाधने तपासणे शक्य आहे. तथापि, ही माहिती kube-स्कोअरमध्येच हार्डकोड केलेली आहे: तुम्ही Kubernetes ची वेगळी आवृत्ती निवडू शकत नाही. तुमचा क्लस्टर अपग्रेड करायचा असेल किंवा तुमच्याकडे K8 च्या वेगवेगळ्या आवृत्त्यांसह अनेक क्लस्टर्स असतील तर ही मर्यादा मोठी समस्या असू शकते.

लक्षात ठेवा की आधीच एक समस्या आहे या संधीची जाणीव करून देण्यासाठी प्रस्तावासह.

कुबे-स्कोअरबद्दल अधिक माहिती येथे आढळू शकते अधिकृत वेबसाइट.

कुबे-स्कोअर चाचण्या सर्वोत्तम पद्धती लागू करण्यासाठी एक उत्तम साधन आहे, परंतु तुम्हाला चाचणीमध्ये बदल करणे किंवा तुमचे स्वतःचे नियम जोडणे आवश्यक असल्यास काय? अरेरे, हे करता येत नाही.

कुबे-स्कोअर एक्स्टेंसिबल नाही: तुम्ही त्यात पॉलिसी जोडू शकत नाही किंवा समायोजित करू शकत नाही.

कंपनीच्या धोरणांचे अनुपालन सत्यापित करण्यासाठी तुम्हाला सानुकूल चाचण्या लिहिण्याची आवश्यकता असल्यास, तुम्ही खालील चार साधनांपैकी एक वापरू शकता: कॉन्फिग-लिंट, कॉपर, कॉन्फेस्ट किंवा पोलारिस.

3.कॉन्फिग-लिंट

कॉन्फिग-लिंट हे YAML, JSON, Terraform, CSV कॉन्फिगरेशन फाइल्स आणि Kubernetes मॅनिफेस्टचे प्रमाणीकरण करण्यासाठी एक साधन आहे.

वापरून स्थापित करू शकता सूचना प्रकल्प वेबसाइटवर.

मूळ लेख लिहिण्याच्या वेळेनुसार वर्तमान प्रकाशन 1.5.0 आहे.

Config-lint मध्ये Kubernetes manifests प्रमाणित करण्यासाठी अंगभूत चाचण्या नाहीत.

कोणत्याही चाचण्या आयोजित करण्यासाठी, आपल्याला योग्य नियम तयार करणे आवश्यक आहे. ते "नियमसेट" नावाच्या YAML फायलींमध्ये लिहिलेले आहेत (नियमसंच), आणि खालील रचना आहे:

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

(rule.yaml)

चला याचा अधिक बारकाईने अभ्यास करूया:

• फील्ड type config-lint कोणत्या प्रकारचे कॉन्फिगरेशन वापरेल ते निर्दिष्ट करते. K8s साठी हे प्रकट होते नेहमी Kubernetes.
• क्षेत्रात files फायलींव्यतिरिक्त, आपण निर्देशिका निर्दिष्ट करू शकता.
• फील्ड rules वापरकर्ता चाचण्या सेट करण्यासाठी हेतू.

समजा तुम्हाला खात्री करायची आहे की डिप्लॉयमेंटमधील प्रतिमा नेहमी विश्वसनीय भांडारातून डाउनलोड केल्या जातात जसे की my-company.com/myapp:1.0. अशी तपासणी करणारा कॉन्फिग-लिंट नियम असे दिसेल:

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

(rule-trusted-repo.yaml)

प्रत्येक नियमामध्ये खालील गुणधर्म असणे आवश्यक आहे:

• id - नियमाचा अद्वितीय अभिज्ञापक;
• severity - कदाचित अपयश, चेतावणी и NON_COMPLIANT;
• 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
[]

कॉन्फिग-लिंट हे एक आशादायक फ्रेमवर्क आहे जे तुम्हाला YAML DSL वापरून Kubernetes YAML मॅनिफेस्ट प्रमाणित करण्यासाठी तुमच्या स्वतःच्या चाचण्या तयार करण्यास अनुमती देते.

परंतु आपल्याला अधिक जटिल तर्कशास्त्र आणि चाचण्यांची आवश्यकता असल्यास काय? YAML इतकेच मर्यादित नाही का? तुम्ही पूर्ण प्रोग्रामिंग भाषेत चाचण्या तयार करू शकत असाल तर?

4. तांबे

तांबे V2 सानुकूल चाचण्या (कॉन्फिग-लिंट प्रमाणे) वापरून मॅनिफेस्ट प्रमाणित करण्यासाठी फ्रेमवर्क आहे.

तथापि, ते चाचण्यांचे वर्णन करण्यासाठी YAML वापरत नसल्यामुळे नंतरच्यापेक्षा वेगळे आहे. त्याऐवजी चाचण्या JavaScript मध्ये लिहिल्या जाऊ शकतात. कॉपर अनेक मूलभूत साधनांसह लायब्ररी प्रदान करते, जे तुम्हाला Kubernetes वस्तूंबद्दल माहिती वाचण्यात आणि त्रुटींची तक्रार करण्यास मदत करतात.

कॉपर स्थापित करण्याच्या चरणांमध्ये आढळू शकते अधिकृत दस्तऐवजीकरण.

2.0.1 हे मूळ लेख लिहिण्याच्या वेळी या उपयुक्ततेचे नवीनतम प्रकाशन आहे.

कॉन्फिग-लिंट प्रमाणे, कॉपरमध्ये अंगभूत चाचण्या नाहीत. चला एक लिहूया. डिप्लॉयमेंट्स केवळ विश्वसनीय रिपॉझिटरीजमधून कंटेनर प्रतिमा वापरतात हे तपासू द्या 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

हे स्पष्ट आहे की तांब्याच्या मदतीने आपण अधिक जटिल चाचण्या करू शकता - उदाहरणार्थ, इंग्रेस मॅनिफेस्टमध्ये डोमेन नावे तपासणे किंवा विशेषाधिकार मोडमध्ये चालणारे पॉड नाकारणे.

कॉपरमध्ये विविध उपयुक्तता कार्ये अंगभूत आहेत:

• DockerImage निर्दिष्ट इनपुट फाइल वाचते आणि खालील गुणधर्मांसह एक ऑब्जेक्ट तयार करते:
  • name - प्रतिमेचे नाव,
  • tag - प्रतिमा टॅग,
  • registry - प्रतिमा नोंदणी,
  • registry_url - प्रोटोकॉल (https://) आणि प्रतिमा नोंदणी,
  • fqin - प्रतिमेचे संपूर्ण स्थान.
• कार्य findByName दिलेल्या प्रकारानुसार संसाधन शोधण्यात मदत करते (kind) आणि नाव (name) इनपुट फाइलमधून.
• कार्य findByLabels निर्दिष्ट प्रकाराद्वारे संसाधन शोधण्यात मदत करते (kind) आणि लेबले (labels).

तुम्ही सर्व उपलब्ध सेवा कार्ये पाहू शकता येथे.

डीफॉल्टनुसार ते संपूर्ण इनपुट YAML फाइल व्हेरिएबलमध्ये लोड करते $$ आणि ते स्क्रिप्टिंगसाठी उपलब्ध करून देते (jQuery अनुभव असलेल्यांसाठी एक परिचित तंत्र).

कॉपरचा मुख्य फायदा स्पष्ट आहे: तुम्हाला विशिष्ट भाषेवर प्रभुत्व मिळवण्याची गरज नाही आणि तुम्ही तुमच्या स्वतःच्या चाचण्या तयार करण्यासाठी विविध JavaScript वैशिष्ट्ये वापरू शकता, जसे की स्ट्रिंग इंटरपोलेशन, फंक्शन्स इ.

हे देखील लक्षात घ्यावे की कॉपरची वर्तमान आवृत्ती JavaScript इंजिनच्या ES5 आवृत्तीसह कार्य करते, ES6 नाही.

येथे तपशील उपलब्ध आहेत अधिकृत प्रकल्प वेबसाइट.

तथापि, जर तुम्हाला खरोखर JavaScript आवडत नसेल आणि विशेषत: क्वेरी तयार करण्यासाठी आणि धोरणांचे वर्णन करण्यासाठी डिझाइन केलेली भाषा पसंत करत असाल, तर तुम्ही कॉन्टेस्टकडे लक्ष दिले पाहिजे.

5.कॉन्फेस्ट

कॉन्फटेस्ट कॉन्फिगरेशन डेटाच्या चाचणीसाठी एक फ्रेमवर्क आहे. Kubernetes मॅनिफेस्टची चाचणी/पडताळणी करण्यासाठी देखील योग्य. विशेष क्वेरी भाषा वापरून चाचण्यांचे वर्णन केले जाते रेगो.

आपण वापरून conftest स्थापित करू शकता सूचनाप्रकल्प वेबसाइटवर सूचीबद्ध.

मूळ लेख लिहिण्याच्या वेळी, नवीनतम आवृत्ती 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

चाचणी अयशस्वी ठरली कारण प्रतिमा अविश्वासू स्त्रोताकडून आल्या आहेत.

रेगो फाइलमध्ये आम्ही ब्लॉक परिभाषित करतो deny. त्याचे सत्य उल्लंघन मानले जाते. अवरोध असल्यास deny अनेक, कॉन्टेस्ट त्यांना एकमेकांपासून स्वतंत्रपणे तपासतात आणि कोणत्याही ब्लॉकचे सत्य उल्लंघन मानले जाते.

डीफॉल्ट आउटपुट व्यतिरिक्त, कॉन्फटेस्ट JSON, TAP आणि टेबल फॉरमॅटला सपोर्ट करते - जर तुम्हाला विद्यमान CI पाइपलाइनमध्ये रिपोर्ट एम्बेड करायचा असेल तर एक अत्यंत उपयुक्त वैशिष्ट्य. आपण ध्वज वापरून इच्छित स्वरूप सेट करू शकता --output.

धोरणे डीबग करणे सोपे करण्यासाठी, confest ला ध्वज आहे --trace. कॉन्टेस्ट निर्दिष्ट पॉलिसी फाइल्सचे विश्लेषण कसे करते याचा ट्रेस आउटपुट करते.

स्पर्धा धोरणे प्रकाशित केली जाऊ शकतात आणि OCI (ओपन कंटेनर इनिशिएटिव्ह) नोंदणीमध्ये कलाकृती म्हणून सामायिक केली जाऊ शकतात.

टीम्स push и pull तुम्हाला आर्टिफॅक्ट प्रकाशित करण्यास किंवा रिमोट रेजिस्ट्रीमधून विद्यमान आर्टिफॅक्ट पुनर्प्राप्त करण्याची अनुमती देते. आम्ही स्थानिक डॉकर रेजिस्ट्री वापरून तयार केलेले धोरण प्रकाशित करण्याचा प्रयत्न करूया conftest push.

तुमची स्थानिक डॉकर रेजिस्ट्री सुरू करा:

$ 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

दुर्दैवाने, डॉकरहब अद्याप समर्थित नाही. त्यामुळे तुम्ही वापरत असाल तर स्वतःला भाग्यवान समजा Azure कंटेनर नोंदणी (ACR) किंवा तुमची स्वतःची नोंदणी.

आर्टिफॅक्ट फॉरमॅट सारखेच आहे पॉलिसी एजंट पॅकेज उघडा (OPA), जे तुम्हाला विद्यमान OPA पॅकेजेसमधून चाचण्या चालवण्यासाठी कॉन्टेस्ट वापरण्याची परवानगी देते.

तुम्ही येथे पॉलिसी शेअरिंग आणि कॉन्टेस्टच्या इतर वैशिष्ट्यांबद्दल अधिक जाणून घेऊ शकता अधिकृत प्रकल्प वेबसाइट.

6. पोलारिस

या लेखात चर्चा केली जाईल की शेवटचे साधन आहे पोलारिस. (त्याची गेल्या वर्षीची घोषणा आम्ही आधीच अनुवादित - अंदाजे भाषांतर)

पोलारिस क्लस्टरमध्ये स्थापित केले जाऊ शकते किंवा कमांड लाइन मोडमध्ये वापरले जाऊ शकते. जसे तुम्ही अंदाज लावला असेल, तो तुम्हाला कुबर्नेट्स मॅनिफेस्टचे स्थिर विश्लेषण करण्यास अनुमती देतो.

कमांड लाइन मोडमध्ये चालत असताना, बिल्ट-इन चाचण्या सुरक्षितता आणि सर्वोत्तम पद्धती (कुबे-स्कोअर प्रमाणे) यासारख्या क्षेत्रांना कव्हर करण्यासाठी उपलब्ध असतात. याव्यतिरिक्त, तुम्ही तुमच्या स्वतःच्या चाचण्या तयार करू शकता (कॉन्फिग-लिंट, कॉपर आणि कॉन्फेस्ट प्रमाणे).

दुसऱ्या शब्दांत, पोलारिस दोन्ही श्रेणींच्या साधनांचे फायदे एकत्र करते: अंगभूत आणि सानुकूल चाचण्यांसह.

कमांड लाइन मोडमध्ये पोलारिस स्थापित करण्यासाठी, वापरा प्रकल्प वेबसाइटवर सूचना.

मूळ लेख लिहिण्याच्या वेळी, आवृत्ती 1.0.3 उपलब्ध आहे.

एकदा इंस्टॉलेशन पूर्ण झाल्यावर तुम्ही मॅनिफेस्टवर पोलारिस चालवू शकता base-valid.yaml खालील आदेशासह:

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

हे केलेल्या चाचण्यांचे तपशीलवार वर्णन आणि त्यांच्या परिणामांसह JSON फॉरमॅटमध्ये स्ट्रिंग आउटपुट करेल. आउटपुटमध्ये खालील रचना असेल:

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

पूर्ण आउटपुट उपलब्ध येथे.

क्यूबे-स्कोअर प्रमाणे, पोलारिस अशा क्षेत्रातील समस्या ओळखतो जेथे मॅनिफेस्ट सर्वोत्तम पद्धती पूर्ण करत नाही:

• शेंगांची आरोग्य तपासणी होत नाही.
• कंटेनर प्रतिमांसाठी टॅग निर्दिष्ट केलेले नाहीत.
• कंटेनर रूट म्हणून चालते.
• मेमरी आणि CPU साठी विनंत्या आणि मर्यादा निर्दिष्ट नाहीत.

प्रत्येक चाचणी, त्याच्या परिणामांवर अवलंबून, गंभीरतेची डिग्री नियुक्त केली जाते: चेतावणी किंवा धोका. उपलब्ध अंगभूत चाचण्यांबद्दल अधिक जाणून घेण्यासाठी, कृपया पहा दस्तऐवजीकरण.

तपशील आवश्यक नसल्यास, आपण ध्वज निर्दिष्ट करू शकता --format score. या प्रकरणात, पोलारिस 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 आवश्यक असलेल्या प्रतिमा स्त्रोताशी तुलना करण्यासाठी वापरले जाते.

वरील चाचणी चालवण्यासाठी, तुम्हाला खालील पोलारिस कॉन्फिगरेशन तयार करणे आवश्यक आहे:

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, पोलारिस यशस्वीरित्या पूर्ण होईल. बदलांसह जाहीरनामा आधीच आत आहे भांडारत्यामुळे तुम्ही मॅनिफेस्टवर मागील कमांड तपासू शकता 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

पोलारिस सानुकूल चाचण्यांसह अंगभूत चाचण्यांची पूर्तता करते, ज्यामुळे दोन्ही जगातील सर्वोत्तम गोष्टी एकत्र होतात.

दुसरीकडे, Rego किंवा JavaScript सारख्या अधिक शक्तिशाली भाषा वापरण्यास असमर्थता अधिक अत्याधुनिक चाचण्या तयार करण्यास प्रतिबंध करणारा एक मर्यादित घटक असू शकतो.

पोलारिस बद्दल अधिक माहिती येथे उपलब्ध आहे प्रकल्प वेबसाइट.

सारांश

Kubernetes YAML फाइल्सची तपासणी आणि मूल्यमापन करण्यासाठी अनेक साधने उपलब्ध असताना, चाचण्यांची रचना आणि अंमलबजावणी कशी केली जाईल याची स्पष्ट समज असणे महत्त्वाचे आहे.

उदाहरणार्थ, जर तुम्ही पाइपलाइनमधून जाणारे कुबेरनेट्स मॅनिफेस्ट घेतले तर कुबेवल ही अशा पाइपलाइनची पहिली पायरी असू शकते.. ऑब्जेक्ट व्याख्या Kubernetes API स्कीमाशी सुसंगत आहे की नाही यावर ते निरीक्षण करेल.

एकदा असे पुनरावलोकन पूर्ण झाल्यानंतर, एखादी व्यक्ती अधिक अत्याधुनिक चाचण्यांकडे जाऊ शकते, जसे की मानक सर्वोत्तम पद्धती आणि विशिष्ट धोरणांचे पालन. इथेच कुबे-स्कोअर आणि पोलारिस उपयोगी पडतील.

ज्यांना जटिल आवश्यकता आहेत आणि तपशीलवार चाचण्या सानुकूलित करण्याची आवश्यकता आहे त्यांच्यासाठी, तांबे, कॉन्फिग-लिंट आणि कॉन्फेस्ट योग्य असतील..

कॉन्फटेस्ट आणि कॉन्फिग-लिंट सानुकूल चाचण्या परिभाषित करण्यासाठी YAML वापरतात आणि कॉपर तुम्हाला संपूर्ण प्रोग्रामिंग भाषेत प्रवेश देते, ज्यामुळे ती एक आकर्षक निवड बनते.

दुसरीकडे, यापैकी एक साधन वापरणे आणि म्हणून, सर्व चाचण्या व्यक्तिचलितपणे तयार करणे किंवा पोलारिसला प्राधान्य देणे आणि त्यात आवश्यक तेच जोडणे योग्य आहे का? या प्रश्नाचे कोणतेही स्पष्ट उत्तर नाही.

खालील सारणी प्रत्येक साधनाचे संक्षिप्त वर्णन प्रदान करते:

उपकरणे
गंतव्य
उणीवा
वापरकर्ता चाचण्या

कुबेवल
API स्कीमाच्या विशिष्ट आवृत्तीवर YAML मॅनिफेस्टचे प्रमाणीकरण करते
CRD सह काम करू शकत नाही
कोणत्याही

kube-स्कोअर
सर्वोत्तम पद्धतींविरुद्ध YAML प्रकटतेचे विश्लेषण करते
संसाधने तपासण्यासाठी तुमची Kubernetes API आवृत्ती निवडू शकत नाही
कोणत्याही

तांबे
YAML मॅनिफेस्टसाठी सानुकूल JavaScript चाचण्या तयार करण्यासाठी एक सामान्य फ्रेमवर्क
अंगभूत चाचण्या नाहीत. खराब दस्तऐवजीकरण
होय

config-lint
YAML मध्ये एम्बेड केलेल्या डोमेन-विशिष्ट भाषेमध्ये चाचण्या तयार करण्यासाठी एक सामान्य फ्रेमवर्क. विविध कॉन्फिगरेशन फॉरमॅटला सपोर्ट करते (उदा. टेराफॉर्म)
कोणत्याही रेडीमेड चाचण्या नाहीत. अंगभूत विधाने आणि कार्ये पुरेशी नसतील
होय

स्पर्धा
रेगो (एक विशेष क्वेरी भाषा) वापरून तुमच्या स्वतःच्या चाचण्या तयार करण्यासाठी फ्रेमवर्क. OCI बंडलद्वारे पॉलिसी शेअर करण्याची अनुमती देते
अंगभूत चाचण्या नाहीत. मला रेगो शिकायचे आहे. धोरणे प्रकाशित करताना डॉकर हब समर्थित नाही
होय

पोलारिस
पुनरावलोकने YAML मानक सर्वोत्तम पद्धतींविरुद्ध प्रकट होतात. तुम्हाला JSON स्कीमा वापरून तुमच्या स्वतःच्या चाचण्या तयार करण्याची अनुमती देते
JSON स्कीमावर आधारित चाचणी क्षमता पुरेशी नसू शकतात
होय

ही साधने कुबर्नेट्स क्लस्टरच्या प्रवेशावर अवलंबून नसल्यामुळे, ते स्थापित करणे सोपे आहे. ते तुम्हाला स्त्रोत फायली फिल्टर करण्याची आणि प्रकल्पांमधील पुल विनंत्या लेखकांना द्रुत अभिप्राय प्रदान करण्याची परवानगी देतात.

अनुवादकाकडून पुनश्च

आमच्या ब्लॉगवर देखील वाचा:

• «कुबर्नेट्स क्लस्टर्स निरोगी ठेवण्यासाठी पोलारिसची ओळख झाली";
• «Kubernetes साठी YAML समर्थनासह Vim";
• «Google नुसार कंटेनर वापरण्यासाठी 7 सर्वोत्तम पद्धती».

स्त्रोत: www.habr.com