सर्वोत्तम प्रथाओं और नीतियों के विरुद्ध Kubernetes YAML को मान्य करें

टिप्पणी। अनुवाद।: K8s परिवेशों के लिए YAML कॉन्फ़िगरेशन की बढ़ती संख्या के साथ, उनके स्वचालित सत्यापन की आवश्यकता अधिक से अधिक जरूरी हो गई है। इस समीक्षा के लेखक ने न केवल इस कार्य के लिए मौजूदा समाधानों का चयन किया, बल्कि यह देखने के लिए उदाहरण के रूप में परिनियोजन का भी उपयोग किया कि वे कैसे काम करते हैं। यह उन लोगों के लिए बहुत जानकारीपूर्ण साबित हुआ जो इस विषय में रुचि रखते हैं।

TL, डॉ: यह आलेख सर्वोत्तम प्रथाओं और आवश्यकताओं के विरुद्ध कुबेरनेट्स YAML फ़ाइलों को मान्य और मूल्यांकन करने के लिए छह स्थिर उपकरणों की तुलना करता है।

कुबेरनेट्स वर्कलोड को आमतौर पर YAML दस्तावेज़ों के रूप में परिभाषित किया जाता है। YAML के साथ समस्याओं में से एक मैनिफ़ेस्ट फ़ाइलों के बीच बाधाओं या संबंधों को निर्दिष्ट करने की कठिनाई है।

यदि हमें यह सुनिश्चित करने की आवश्यकता है कि क्लस्टर में तैनात सभी छवियां एक विश्वसनीय रजिस्ट्री से आती हैं तो क्या होगा?

मैं उन परिनियोजनओं को क्लस्टर में भेजे जाने से कैसे रोक सकता हूँ जिनमें PodDisruptionBudgets नहीं हैं?

स्थैतिक परीक्षण का एकीकरण आपको विकास चरण में त्रुटियों और नीति उल्लंघनों की पहचान करने की अनुमति देता है। इससे यह गारंटी बढ़ जाती है कि संसाधन परिभाषाएँ सही और सुरक्षित हैं, और यह अधिक संभावना है कि उत्पादन कार्यभार सर्वोत्तम प्रथाओं का पालन करेगा।

कुबेरनेट्स स्थिर YAML फ़ाइल निरीक्षण पारिस्थितिकी तंत्र को निम्नलिखित श्रेणियों में विभाजित किया जा सकता है:

• एपीआई सत्यापनकर्ता. इस श्रेणी के उपकरण कुबेरनेट्स एपीआई सर्वर की आवश्यकताओं के विरुद्ध YAML मैनिफ़ेस्ट की जाँच करते हैं।
• तैयार परीक्षक. इस श्रेणी के उपकरण सुरक्षा, सर्वोत्तम प्रथाओं के अनुपालन आदि के लिए तैयार परीक्षणों के साथ आते हैं।
• कस्टम सत्यापनकर्ता. इस श्रेणी के प्रतिनिधि आपको विभिन्न भाषाओं में कस्टम परीक्षण बनाने की अनुमति देते हैं, उदाहरण के लिए, रेगो और जावास्क्रिप्ट।

इस लेख में हम छह अलग-अलग उपकरणों का वर्णन और तुलना करेंगे:

1. कुबेवल;
2. क्यूब-स्कोर;
3. कॉन्फिग-लिंट;
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 और इस लेख के अन्य घोषणापत्र यहां पाए जा सकते हैं गिट रिपॉजिटरी.

मेनिफेस्ट एक वेब एप्लिकेशन का वर्णन करता है जिसका मुख्य कार्य पोर्ट 5678 पर "हैलो वर्ल्ड" संदेश के साथ प्रतिक्रिया देना है। इसे निम्नलिखित कमांड के साथ तैनात किया जा सकता है:

kubectl apply -f hello-world.yaml

और इसलिए - कार्य की जाँच करें:

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

अब जाओ http://localhost:8080 और पुष्टि करें कि एप्लिकेशन काम कर रहा है। लेकिन क्या यह सर्वोत्तम प्रथाओं का पालन करता है? चलो जांचते हैं।

1. कुबेवल

दिल में कुबेवल विचार यह है कि कुबेरनेट्स के साथ कोई भी इंटरैक्शन इसके REST API के माध्यम से होता है। दूसरे शब्दों में, आप यह जांचने के लिए एपीआई स्कीमा का उपयोग कर सकते हैं कि कोई दिया गया YAML इसके अनुरूप है या नहीं। आइए एक उदाहरण देखें.

स्थापाना निर्देश क्यूबेवल परियोजना वेबसाइट पर उपलब्ध हैं।

मूल लेख लिखने के समय, संस्करण 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

संसाधन का सत्यापन नहीं किया जा रहा है.

एपीआई संस्करण का उपयोग कर तैनाती 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-version:

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

कृपया ध्यान दें कि संस्करण को प्रारूप में निर्दिष्ट किया जाना चाहिए Major.Minor.Patch.

उन संस्करणों की सूची के लिए जिनके लिए सत्यापन समर्थित है, कृपया देखें GitHub पर JSON स्कीमा, जो क्यूबवल सत्यापन के लिए उपयोग करता है। यदि आपको क्यूबेवल को ऑफ़लाइन चलाने की आवश्यकता है, तो स्कीमा डाउनलोड करें और ध्वज का उपयोग करके उनका स्थानीय स्थान निर्दिष्ट करें --schema-location.

व्यक्तिगत YAML फ़ाइलों के अलावा, क्यूबेवल निर्देशिकाओं और stdin के साथ भी काम कर सकता है।

इसके अलावा, क्यूबेवल आसानी से सीआई पाइपलाइन में एकीकृत हो जाता है। जो लोग क्लस्टर में मैनिफ़ेस्ट भेजने से पहले परीक्षण चलाना चाहते हैं, उन्हें यह जानकर ख़ुशी होगी कि क्यूबेवल तीन आउटपुट स्वरूपों का समर्थन करता है:

1. सादे पाठ;
2. JSON;
3. कुछ भी प्रोटोकॉल का परीक्षण करें (टीएपी)।

और वांछित प्रकार के परिणामों का सारांश उत्पन्न करने के लिए आउटपुट के आगे विश्लेषण के लिए किसी भी प्रारूप का उपयोग किया जा सकता है।

क्यूबेवल की कमियों में से एक यह है कि यह वर्तमान में कस्टम संसाधन परिभाषाओं (सीआरडी) के अनुपालन की जांच नहीं कर सकता है। हालाँकि, क्यूबेवल को कॉन्फ़िगर करना संभव है उन्हें नजरअंदाज करो.

क्यूबेवल संसाधनों की जाँच और मूल्यांकन के लिए एक महान उपकरण है; हालाँकि, इस बात पर जोर दिया जाना चाहिए कि परीक्षा उत्तीर्ण करना यह गारंटी नहीं देता है कि संसाधन सर्वोत्तम प्रथाओं का अनुपालन करता है।

उदाहरण के लिए, टैग का उपयोग करना 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-score सभी प्रकार के उल्लंघनों सहित जानकारी को मानव-पठनीय रूप में प्रदर्शित करता है चेतावनी и गंभीर, जो विकास के दौरान बहुत मदद करता है।

जो लोग सीआई पाइपलाइन के भीतर इस उपकरण का उपयोग करना चाहते हैं वे ध्वज का उपयोग करके अधिक संपीड़ित आउटपुट सक्षम कर सकते हैं --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

क्यूबेवल के समान, क्यूब-स्कोर एक गैर-शून्य निकास कोड लौटाता है जब कोई परीक्षण विफल हो जाता है गंभीर. आप इसके लिए समान प्रसंस्करण भी सक्षम कर सकते हैं चेतावनी.

इसके अलावा, विभिन्न एपीआई संस्करणों (क्यूबेवल में) के अनुपालन के लिए संसाधनों की जांच करना संभव है। हालाँकि, यह जानकारी क्यूब-स्कोर में ही हार्डकोड की गई है: आप कुबेरनेट्स के एक अलग संस्करण का चयन नहीं कर सकते हैं। यदि आप अपने क्लस्टर को अपग्रेड करने का इरादा रखते हैं या यदि आपके पास K8s के विभिन्न संस्करणों के साथ कई क्लस्टर हैं तो यह सीमा एक बड़ी समस्या हो सकती है।

ध्यान दें कि वहाँ पहले से ही एक मुद्दा है इस अवसर को साकार करने के प्रस्ताव के साथ।

क्यूब-स्कोर के बारे में अधिक जानकारी यहां पाई जा सकती है आधिकारिक वेबसाइट.

क्यूब-स्कोर परीक्षण सर्वोत्तम प्रथाओं को लागू करने के लिए एक महान उपकरण हैं, लेकिन क्या होगा यदि आपको परीक्षण में बदलाव करने या अपने स्वयं के नियम जोड़ने की आवश्यकता है? अफ़सोस, ऐसा नहीं किया जा सकता.

क्यूब-स्कोर विस्तार योग्य नहीं है: आप इसमें नीतियां नहीं जोड़ सकते या उन्हें समायोजित नहीं कर सकते।

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

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

कॉन्फिग-लिंट YAML, JSON, टेराफॉर्म, CSV कॉन्फ़िगरेशन फ़ाइलों और कुबेरनेट्स मैनिफ़ेस्ट को मान्य करने के लिए एक उपकरण है।

आप इसका उपयोग करके इंस्टॉल कर सकते हैं निर्देश प्रोजेक्ट वेबसाइट पर.

मूल लेख लिखे जाने तक वर्तमान रिलीज़ 1.5.0 है।

कॉन्फिग-लिंट में कुबेरनेट्स मैनिफ़ेस्ट को मान्य करने के लिए अंतर्निहित परीक्षण नहीं हैं।

कोई भी परीक्षण करने के लिए, आपको उचित नियम बनाने होंगे। वे YAML फ़ाइलों में लिखे गए हैं जिन्हें "नियमसेट" कहा जाता है (नियम-सेट), और निम्नलिखित संरचना है:

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

(rule.yaml)

आइए इसका अधिक बारीकी से अध्ययन करें:

• क्षेत्र type निर्दिष्ट करता है कि कॉन्फिग-लिंट किस प्रकार की कॉन्फ़िगरेशन का उपयोग करेगा। 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 - शायद असफलता, चेतावनी и गैर_अनुपालक;
• 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 का उपयोग करके कुबेरनेट्स YAML मैनिफ़ेस्ट को मान्य करने के लिए अपने स्वयं के परीक्षण बनाने की अनुमति देता है।

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

4। तांबा

तांबा V2 कस्टम परीक्षणों (कॉन्फिग-लिंट के समान) का उपयोग करके मैनिफ़ेस्ट को मान्य करने के लिए एक रूपरेखा है।

हालाँकि, यह बाद वाले से अलग है क्योंकि यह परीक्षणों का वर्णन करने के लिए YAML का उपयोग नहीं करता है। इसके बजाय परीक्षण जावास्क्रिप्ट में लिखे जा सकते हैं। कॉपर कई बुनियादी उपकरणों के साथ एक पुस्तकालय प्रदान करता है, जो आपको कुबेरनेट्स ऑब्जेक्ट के बारे में जानकारी पढ़ने और त्रुटियों की रिपोर्ट करने में मदद करता है।

कॉपर स्थापित करने के चरण यहां पाए जा सकते हैं आधिकारिक दस्तावेज.

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 अनुभव वाले लोगों के लिए एक परिचित तकनीक)।

कॉपर का मुख्य लाभ स्पष्ट है: आपको किसी विशेष भाषा में महारत हासिल करने की आवश्यकता नहीं है और आप अपने स्वयं के परीक्षण, जैसे स्ट्रिंग इंटरपोलेशन, फ़ंक्शन इत्यादि बनाने के लिए विभिन्न जावास्क्रिप्ट सुविधाओं का उपयोग कर सकते हैं।

यह भी ध्यान दिया जाना चाहिए कि कॉपर का वर्तमान संस्करण जावास्क्रिप्ट इंजन के ES5 संस्करण के साथ काम करता है, ES6 के साथ नहीं।

विवरण यहां उपलब्ध है परियोजना की आधिकारिक वेबसाइट.

हालाँकि, यदि आप वास्तव में जावास्क्रिप्ट को पसंद नहीं करते हैं और विशेष रूप से क्वेरीज़ बनाने और नीतियों का वर्णन करने के लिए डिज़ाइन की गई भाषा पसंद करते हैं, तो आपको कॉन्टेस्ट पर ध्यान देना चाहिए।

5. कॉन्टेस्ट

कॉन्टेस्ट कॉन्फ़िगरेशन डेटा के परीक्षण के लिए एक रूपरेखा है। कुबेरनेट्स मेनिफ़ेस्ट के परीक्षण/सत्यापन के लिए भी उपयुक्त। परीक्षणों का वर्णन एक विशेष क्वेरी भाषा का उपयोग करके किया जाता है रेगो.

आप कॉन्टेस्ट का उपयोग करके इंस्टॉल कर सकते हैं निर्देशपरियोजना वेबसाइट पर सूचीबद्ध।

मूल लेख लिखने के समय, उपलब्ध नवीनतम संस्करण 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.

नीतियों को डीबग करना आसान बनाने के लिए कॉन्टेस्ट में एक ध्वज होता है --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

दुर्भाग्य से, DockerHub अभी तक समर्थित नहीं है। इसलिए यदि आप इसका उपयोग करते हैं तो अपने आप को भाग्यशाली समझें Azure कंटेनर रजिस्ट्री (एसीआर) या आपकी अपनी रजिस्ट्री।

विरूपण साक्ष्य प्रारूप के समान है पॉलिसी एजेंट पैकेज खोलें (ओपीए), जो आपको मौजूदा ओपीए पैकेजों से परीक्षण चलाने के लिए कॉन्टेस्ट का उपयोग करने की अनुमति देता है।

आप नीति साझाकरण और कॉन्टेस्ट की अन्य विशेषताओं के बारे में अधिक जान सकते हैं परियोजना की आधिकारिक वेबसाइट.

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": [
    /* длинный список */
  ]
}

पूर्ण आउटपुट उपलब्ध है यहां.

क्यूब-स्कोर की तरह, पोलारिस उन क्षेत्रों में मुद्दों की पहचान करता है जहां मेनिफेस्ट सर्वोत्तम प्रथाओं को पूरा नहीं करता है:

• पॉड्स के लिए कोई स्वास्थ्य जांच नहीं होती है।
• कंटेनर छवियों के लिए टैग निर्दिष्ट नहीं हैं.
• कंटेनर रूट के रूप में चलता है।
• मेमोरी और सीपीयू के लिए अनुरोध और सीमाएँ निर्दिष्ट नहीं हैं।

प्रत्येक परीक्षण को, उसके परिणामों के आधार पर, गंभीरता की एक डिग्री दी जाती है: चेतावनी या खतरा. उपलब्ध अंतर्निहित परीक्षणों के बारे में अधिक जानने के लिए कृपया देखें प्रलेखन.

यदि विवरण की आवश्यकता नहीं है, तो आप ध्वज निर्दिष्ट कर सकते हैं --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

पोलारिस अंतर्निर्मित परीक्षणों को कस्टम परीक्षणों के साथ पूरक करता है, जिससे दोनों दुनिया के सर्वश्रेष्ठ का संयोजन होता है।

दूसरी ओर, रेगो या जावास्क्रिप्ट जैसी अधिक शक्तिशाली भाषाओं का उपयोग करने में असमर्थता अधिक परिष्कृत परीक्षणों के निर्माण को रोकने वाला एक सीमित कारक हो सकता है।

पोलारिस के बारे में अधिक जानकारी यहां उपलब्ध है परियोजना स्थल.

सारांश

हालाँकि Kubernetes YAML फ़ाइलों का निरीक्षण और मूल्यांकन करने के लिए कई उपकरण उपलब्ध हैं, परीक्षणों को कैसे डिज़ाइन और क्रियान्वित किया जाएगा, इसकी स्पष्ट समझ होना महत्वपूर्ण है.

उदाहरण के लिए, यदि आप एक पाइपलाइन से गुजरने वाले कुबेरनेट्स मैनिफ़ेस्ट को लेते हैं, तो क्यूबेवल ऐसी पाइपलाइन में पहला कदम हो सकता है. यह निगरानी करेगा कि ऑब्जेक्ट परिभाषाएँ कुबेरनेट्स एपीआई स्कीमा के अनुरूप हैं या नहीं।

एक बार ऐसी समीक्षा पूरी हो जाने के बाद, कोई अधिक परिष्कृत परीक्षणों की ओर आगे बढ़ सकता है, जैसे मानक सर्वोत्तम प्रथाओं और विशिष्ट नीतियों का अनुपालन। यहीं पर क्यूब-स्कोर और पोलारिस काम आएंगे।

उन लोगों के लिए जिनकी आवश्यकताएं जटिल हैं और जिन्हें परीक्षणों को विस्तार से अनुकूलित करने की आवश्यकता है, कॉपर, कॉन्फिग-लिंट और कॉन्टेस्ट उपयुक्त होंगे.

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

दूसरी ओर, क्या इन उपकरणों में से किसी एक का उपयोग करना उचित है और इसलिए, सभी परीक्षण मैन्युअल रूप से बनाना, या पोलारिस को प्राथमिकता देना और केवल वही जोड़ना है जो इसमें आवश्यक है? इस प्रश्न का कोई स्पष्ट उत्तर नहीं है.

नीचे दी गई तालिका प्रत्येक उपकरण का संक्षिप्त विवरण प्रदान करती है:

उपकरण
भाग्य
सीमाएं
उपयोगकर्ता परीक्षण

कुबेवल
एपीआई स्कीमा के एक विशिष्ट संस्करण के विरुद्ध YAML मैनिफ़ेस्ट को मान्य करता है
सीआरडी के साथ काम नहीं कर सकता
नहीं

क्यूब-स्कोर
सर्वोत्तम प्रथाओं के विरुद्ध YAML मेनिफेस्टों का विश्लेषण करता है
संसाधनों की जाँच के लिए आपके Kubernetes API संस्करण का चयन नहीं किया जा सकता
नहीं

तांबा
YAML मेनिफेस्टों के लिए कस्टम जावास्क्रिप्ट परीक्षण बनाने के लिए एक सामान्य रूपरेखा
कोई अंतर्निहित परीक्षण नहीं. ख़राब दस्तावेज़ीकरण
Да

config-lint
YAML में एम्बेडेड डोमेन-विशिष्ट भाषा में परीक्षण बनाने के लिए एक सामान्य रूपरेखा। विभिन्न कॉन्फ़िगरेशन प्रारूपों का समर्थन करता है (जैसे टेराफॉर्म)
कोई तैयार परीक्षण नहीं हैं. अंतर्निहित दावे और कार्य पर्याप्त नहीं हो सकते हैं
Да

संघर्ष
रेगो (एक विशेष क्वेरी भाषा) का उपयोग करके अपने स्वयं के परीक्षण बनाने के लिए एक रूपरेखा। ओसीआई बंडलों के माध्यम से नीतियों को साझा करने की अनुमति देता है
कोई अंतर्निहित परीक्षण नहीं. मुझे रेगो सीखना है. नीतियों को प्रकाशित करते समय डॉकर हब समर्थित नहीं है
Да

पोलरिस
समीक्षा YAML मानक सर्वोत्तम प्रथाओं के विरुद्ध प्रकट होती है। आपको JSON स्कीमा का उपयोग करके अपने स्वयं के परीक्षण बनाने की अनुमति देता है
JSON स्कीमा पर आधारित परीक्षण क्षमताएं पर्याप्त नहीं हो सकती हैं
Да

क्योंकि ये उपकरण कुबेरनेट्स क्लस्टर तक पहुंच पर निर्भर नहीं हैं, इसलिए इन्हें स्थापित करना आसान है। वे आपको स्रोत फ़ाइलों को फ़िल्टर करने और परियोजनाओं में पुल अनुरोधों के लेखकों को त्वरित प्रतिक्रिया प्रदान करने की अनुमति देते हैं।

अनुवादक से पी.एस

हमारे ब्लॉग पर भी पढ़ें:

• «कुबेरनेट क्लस्टर को स्वस्थ रखने के लिए पोलारिस पेश किया गया";
• «कुबेरनेट्स के लिए YAML समर्थन के साथ विम";
• «Google के अनुसार कंटेनरों का उपयोग करने की 7 सर्वोत्तम प्रथाएँ'.

स्रोत: www.habr.com