उत्तम अभ्यास र नीतिहरू विरुद्ध Kubernetes YAML मान्य गर्नुहोस्

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

TL; ड: यस लेखले उत्तम अभ्यास र आवश्यकताहरू विरुद्ध Kubernetes YAML फाइलहरू प्रमाणीकरण र मूल्याङ्कन गर्न छवटा स्थिर उपकरणहरू तुलना गर्दछ।

Kubernetes वर्कलोडहरू सामान्यतया YAML कागजातहरूको रूपमा परिभाषित गरिन्छ। YAML सँग समस्याहरू मध्ये एउटा भनेको बाधाहरू वा manifest फाइलहरू बीचको सम्बन्ध निर्दिष्ट गर्न कठिनाई हो।

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

क्लस्टरमा पठाउनबाट PodDisruptionBudgets नभएका डिप्लोयमेन्टहरूलाई म कसरी रोक्न सक्छु?

स्थिर परीक्षणको एकीकरणले तपाईंलाई विकास चरणमा त्रुटिहरू र नीति उल्लङ्घनहरू पहिचान गर्न अनुमति दिन्छ। यसले ग्यारेन्टी बढाउँछ कि स्रोत परिभाषाहरू सही र सुरक्षित छन्, र उत्पादन कार्यभारहरूले उत्कृष्ट अभ्यासहरू पछ्याउने सम्भावना बढाउँछ।

Kubernetes स्थिर YAML फाइल निरीक्षण इकोसिस्टमलाई निम्न कोटिहरूमा विभाजन गर्न सकिन्छ:

• 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 भण्डारहरू.

म्यानिफेस्टले एउटा वेब अनुप्रयोगको वर्णन गर्दछ जसको मुख्य कार्य पोर्ट ५६७८ मा "हेलो वर्ल्ड" सन्देशको साथ प्रतिक्रिया दिनु हो। यसलाई निम्न आदेशद्वारा प्रयोग गर्न सकिन्छ:

kubectl apply -f hello-world.yaml

र त्यसैले - काम जाँच गर्नुहोस्:

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

अब जानुहोस् http://localhost:8080 र पुष्टि गर्नुहोस् कि अनुप्रयोगले काम गरिरहेको छ। तर के यसले उत्तम अभ्यासहरू पछ्याउँछ? जाँच गरौं।

1. कुबेवल

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

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

मूल लेख लेख्ने समयमा, संस्करण 0.15.0 उपलब्ध थियो।

एक पटक स्थापना भएपछि, यसलाई माथिको म्यानिफेस्ट फिड गरौं:

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

यदि सफल भएमा, कुबेवल निकास कोड ० को साथ बाहिर निस्कनेछ। तपाइँ यसलाई निम्नानुसार जाँच गर्न सक्नुहुन्छ:

$ echo $?
0

अब एक फरक manifest संग कुबेवल प्रयास गरौं:

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, पोडको लेबलसँग मेल खाने चयनकर्ता समावेश गर्नुपर्छ। माथिको manifest मा चयनकर्ता समावेश छैन, त्यसैले kubeval ले त्रुटि रिपोर्ट गर्नुभयो र गैर-शून्य कोडको साथ बाहिर निस्कनुभयो।

मैले गरे भने के होला भनेर सोचिरहेको छु kubectl apply -f यो घोषणा पत्र संग?

खैर, प्रयास गरौं:

$ kubectl apply -f kubeval-invalid.yaml
error: error validating "kubeval-invalid.yaml": error validating data: ValidationError(Deployment.spec):
missing required field "selector" in io.k8s.api.apps.v1.DeploymentSpec; if you choose to ignore these errors,
turn validation off with --validate=false

कुबेवलले चेतावनी दिएको गल्ती यही हो । तपाइँ चयनकर्ता थपेर यसलाई ठीक गर्न सक्नुहुन्छ:

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

(base-valid.yaml)

कुबेवल जस्ता उपकरणहरूको फाइदा यो हो कि यस्ता त्रुटिहरू डिप्लोइमेन्ट चक्रमा चाँडै समात्न सकिन्छ।

थप रूपमा, यी जाँचहरूलाई क्लस्टरमा पहुँच आवश्यक पर्दैन; तिनीहरू अफलाइन प्रदर्शन गर्न सकिन्छ।

पूर्वनिर्धारित रूपमा, kubeval ले नवीनतम Kubernetes API स्कीमा विरुद्ध स्रोतहरू जाँच गर्दछ। जे होस्, धेरै जसो केसहरूमा तपाईंले एक विशिष्ट Kubernetes रिलीज विरुद्ध जाँच गर्न आवश्यक पर्दछ। यो झण्डा प्रयोग गरेर गर्न सकिन्छ --kubernetes-version:

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

कृपया नोट गर्नुहोस् कि संस्करण ढाँचामा निर्दिष्ट हुनुपर्छ Major.Minor.Patch.

संस्करणहरूको सूचीको लागि जसको लागि प्रमाणीकरण समर्थित छ, कृपया सन्दर्भ गर्नुहोस् GitHub मा JSON स्कीमा, जुन कुबेवलले प्रमाणीकरणको लागि प्रयोग गर्दछ। यदि तपाइँ kubeval अफलाइन चलाउन आवश्यक छ भने, स्कीमाहरू डाउनलोड गर्नुहोस् र झण्डा प्रयोग गरेर तिनीहरूको स्थानीय स्थान निर्दिष्ट गर्नुहोस् --schema-location.

व्यक्तिगत YAML फाईलहरूको अतिरिक्त, kubeval ले डाइरेक्टरीहरू र stdin सँग पनि काम गर्न सक्छ।

थप रूपमा, कुबेवल सजिलै CI पाइपलाइनमा एकीकृत हुन्छ। क्लस्टरमा म्यानिफेस्टहरू पठाउनु अघि परीक्षणहरू चलाउन चाहनेहरूले कुबेवलले तीन आउटपुट ढाँचाहरूलाई समर्थन गर्दछ भनेर जान्न पाउँदा खुसी हुनेछन्:

1. सादा पाठ;
2. JSON;
3. कुनै पनि प्रोटोकल (ट्याप) परीक्षण गर्नुहोस्।

र इच्छित प्रकारको नतिजाहरूको सारांश उत्पन्न गर्न आउटपुटको थप पार्सिङको लागि कुनै पनि ढाँचाहरू प्रयोग गर्न सकिन्छ।

कुबेवलको एउटा कमजोरी यो हो कि यसले हाल Custom Resource Definitions (CRDs) को अनुपालनको जाँच गर्न सक्दैन। यद्यपि, कुबेवल कन्फिगर गर्न सम्भव छ तिनीहरूलाई बेवास्ता गर्नुहोस्.

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

उदाहरणका लागि, ट्याग प्रयोग गर्दै latest कन्टेनरमा उत्तम अभ्यासहरू पछ्याउँदैन। यद्यपि, कुबेवालले यसलाई त्रुटि मान्दैनन् र रिपोर्ट गर्दैनन्। त्यो हो, यस्तो YAML को प्रमाणिकरण बिना चेतावनी पूरा हुनेछ।

तर यदि तपाइँ YAML को मूल्याङ्कन गर्न र ट्याग जस्तै उल्लङ्घनहरू पहिचान गर्न चाहनुहुन्छ भने latest? मैले उत्तम अभ्यासहरू विरुद्ध YAML फाइल कसरी जाँच गर्ने?

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

कुबे-अङ्क YAML manifests लाई पार्स गर्दछ र बिल्ट-इन परीक्षणहरू विरुद्ध मूल्याङ्कन गर्दछ। यी परीक्षणहरू सुरक्षा दिशानिर्देशहरू र उत्कृष्ट अभ्यासहरूको आधारमा चयन गरिन्छ, जस्तै:

• कन्टेनर चलाउँदै रूटको रूपमा होइन।
• पोड स्वास्थ्य जाँच को उपलब्धता।
• स्रोतहरूको लागि अनुरोध र सीमाहरू सेट गर्दै।

परीक्षण नतिजाको आधारमा, तीन नतिजा दिइन्छ: OK, चेतावनी и CRITICAL.

तपाइँ कुबे-स्कोर अनलाइन प्रयास गर्न सक्नुहुन्छ वा यसलाई स्थानीय रूपमा स्थापना गर्न सक्नुहुन्छ।

मूल लेख लेख्ने समयमा, कुबे-स्कोरको नवीनतम संस्करण 1.7.0 थियो।

हाम्रो manifest मा यसलाई प्रयास गरौं base-valid.yaml:

$ kube-score score base-valid.yaml

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

YAML ले kubeval परीक्षणहरू पास गर्छ, जबकि kube-स्कोरले निम्न त्रुटिहरूलाई संकेत गर्छ:

• तयारी जाँचहरू कन्फिगर गरिएको छैन।
• CPU स्रोत र मेमोरीको लागि कुनै अनुरोध वा सीमाहरू छैनन्।
• पोड अवरोध बजेट निर्दिष्ट गरिएको छैन।
• त्यहाँ छुट्टिने नियमहरू छैनन् (सम्बन्ध विरोधी) उपलब्धता अधिकतम गर्न।
• कन्टेनर रूटको रूपमा चल्छ।

यी सबै कमीकमजोरीहरूका वैध बुँदाहरू हुन् जुन डिप्लोयमेन्टलाई अझ प्रभावकारी र भरपर्दो बनाउनको लागि सम्बोधन गर्न आवश्यक छ।

टोली kube-score सबै प्रकारका उल्लङ्घनहरू सहित मानव-पठनीय फारममा जानकारी प्रदर्शन गर्दछ चेतावनी и CRITICAL, जसले विकासको क्रममा धेरै मद्दत गर्दछ।

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-स्कोरले एक गैर-शून्य निकास कोड फर्काउँछ जब त्यहाँ एक परीक्षण असफल हुन्छ। CRITICAL। तपाईं पनि को लागी समान प्रशोधन सक्षम गर्न सक्नुहुन्छ चेतावनी.

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

त्यो नोट गर्नुहोस् त्यहाँ पहिले नै एक मुद्दा छ यो अवसर महसुस गर्न एक प्रस्ताव संग।

कुबे-स्कोरको बारेमा थप जानकारी यहाँ पाउन सकिन्छ आधिकारिक वेबसाइट.

Kube-स्कोर परीक्षणहरू उत्तम अभ्यासहरू लागू गर्नको लागि उत्कृष्ट उपकरण हो, तर यदि तपाईंले परीक्षणमा परिवर्तनहरू गर्न वा आफ्नै नियमहरू थप्न आवश्यक छ भने के हुन्छ? अहो, यो गर्न सकिँदैन।

कुबे-स्कोर एक्स्टेन्सिबल छैन: तपाईंले यसमा नीतिहरू थप्न वा समायोजन गर्न सक्नुहुन्न।

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

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

कन्फिग-लिन्ट YAML, JSON, Terraform, CSV कन्फिगरेसन फाइलहरू र Kubernetes manifests प्रमाणीकरण गर्ने उपकरण हो।

प्रयोग गरेर स्थापना गर्न सक्नुहुन्छ निर्देशनहरू परियोजना वेबसाइटमा।

मूल लेख लेख्ने समयको रूपमा हालको रिलीज 1.5.0 हो।

कन्फिग-लिन्टमा Kubernetes manifests को प्रमाणीकरणको लागि बिल्ट-इन परीक्षणहरू छैनन्।

कुनै पनि परीक्षण सञ्चालन गर्न, तपाईंले उपयुक्त नियमहरू सिर्जना गर्न आवश्यक छ। तिनीहरू 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 - हुनसक्छ FAILURE, चेतावनी и 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"
  }
]

चेक असफल भयो। अब सही छवि भण्डारको साथ निम्न manifest जाँच गरौं:

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)

हामी माथिको manifest संग समान परीक्षण चलाउँछौं। कुनै समस्या भेटिएन:

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

कन्फिग-लिन्ट एक आशाजनक ढाँचा हो जसले तपाईंलाई YAML DSL प्रयोग गरेर Kubernetes YAML manifests प्रमाणित गर्न आफ्नै परीक्षणहरू सिर्जना गर्न अनुमति दिन्छ।

तर के हुन्छ यदि तपाईंलाई थप जटिल तर्क र परीक्षणहरू चाहिन्छ? YAML यसको लागि धेरै सीमित छैन? के हुन्छ यदि तपाइँ पूर्ण प्रोग्रामिङ भाषामा परीक्षणहरू सिर्जना गर्न सक्नुहुन्छ?

१. कपर

कपर V2 अनुकूलन परीक्षणहरू (कन्फिग-लिन्ट जस्तै) प्रयोग गरेर म्यानिफेस्टहरू मान्य गर्ने ढाँचा हो।

यद्यपि, यो पछिल्लो भन्दा फरक छ कि यसले परीक्षणहरू वर्णन गर्न YAML प्रयोग गर्दैन। परीक्षणहरू सट्टा जाभास्क्रिप्टमा लेख्न सकिन्छ। कपरले धेरै आधारभूत उपकरणहरूको साथ एक पुस्तकालय प्रदान गर्दछ, जसले तपाईंलाई 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

यो स्पष्ट छ कि तामाको मद्दतले तपाईले थप जटिल परीक्षणहरू गर्न सक्नुहुन्छ - उदाहरणका लागि, Ingress manifests मा डोमेन नामहरू जाँच गर्ने वा विशेषाधिकार प्राप्त मोडमा चलिरहेको पोडहरू अस्वीकार गर्ने।

कपरमा निर्मित विभिन्न उपयोगिता प्रकार्यहरू छन्:

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

तपाईं सबै उपलब्ध सेवा प्रकार्यहरू हेर्न सक्नुहुन्छ यहाँ.

पूर्वनिर्धारित रूपमा यसले सम्पूर्ण इनपुट YAML फाइललाई चरमा लोड गर्दछ $$ र यसलाई स्क्रिप्टिङको लागि उपलब्ध गराउँदछ (jQuery अनुभव भएकाहरूका लागि परिचित प्रविधि)।

Copper को मुख्य फाइदा स्पष्ट छ: तपाइँलाई एक विशेष भाषा मास्टर गर्न आवश्यक छैन र तपाइँ तपाइँको आफ्नै परीक्षणहरू सिर्जना गर्न विभिन्न JavaScript सुविधाहरू प्रयोग गर्न सक्नुहुन्छ, जस्तै स्ट्रिङ इन्टरपोलेसन, प्रकार्यहरू, आदि।

यो पनि ध्यान दिनुपर्छ कि कपरको हालको संस्करणले जाभास्क्रिप्ट इन्जिनको ES5 संस्करणसँग काम गर्दछ, ES6 होइन।

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

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

5. प्रतियोगिता

Confest कन्फिगरेसन डाटा परीक्षणको लागि एक रूपरेखा हो। Kubernetes manifests परीक्षण/प्रमाणीकरणका लागि पनि उपयुक्त। परीक्षणहरू विशेष क्वेरी भाषा प्रयोग गरेर वर्णन गरिन्छ रेगो.

तपाईं प्रयोग गरेर confest स्थापना गर्न सक्नुहुन्छ निर्देशनहरूपरियोजना वेबसाइटमा सूचीबद्ध।

मूल लेख लेख्ने समयमा, नवीनतम संस्करण उपलब्ध थियो 0.18.2।

config-lint र copper जस्तै, confest कुनै पनि निर्मित परीक्षण बिना आउँछ। यसलाई प्रयास गरौं र हाम्रो आफ्नै नीति लेखौं। अघिल्लो उदाहरणहरूमा जस्तै, हामी कन्टेनर छविहरू विश्वसनीय स्रोतबाट लिइएको हो कि भनेर जाँच गर्नेछौं।

डाइरेक्टरी बनाउनुहोस् conftest-checks, र यसमा नामको फाइल छ check_image_registry.rego निम्न सामग्री संग:

package main

deny[msg] {

  input.kind == "Deployment"
  image := input.spec.template.spec.containers[_].image
  not startswith(image, "my-company.com/")
  msg := sprintf("image '%v' doesn't come from my-company.com repository", [image])
}

अब परीक्षण गरौं base-valid.yaml मार्फत conftest:

$ conftest test --policy ./conftest-checks base-valid.yaml

FAIL - base-valid.yaml - image 'hashicorp/http-echo' doesn't come from my-company.com repository
1 tests, 1 passed, 0 warnings, 1 failure

परीक्षण असफल भयो किनभने छविहरू अविश्वसनीय स्रोतबाट आएका थिए।

रेगो फाइलमा हामी ब्लक परिभाषित गर्छौं 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

दुर्भाग्यवश, DockerHub अझै समर्थित छैन। त्यसैले यदि तपाइँ प्रयोग गर्नुहुन्छ भने आफूलाई भाग्यशाली ठान्नुहोस् Azure कन्टेनर रजिस्ट्री (ACR) वा तपाईंको आफ्नै रजिस्ट्री।

कलाकृति ढाँचा उस्तै छ नीति एजेन्ट प्याकेजहरू खोल्नुहोस् (OPA), जसले तपाइँलाई अवस्थित OPA प्याकेजहरूबाट परीक्षणहरू चलाउन कन्फेस्ट प्रयोग गर्न अनुमति दिन्छ।

तपाईं नीति साझेदारी र confest को अन्य सुविधाहरू बारे थप जान्न सक्नुहुन्छ आधिकारिक परियोजना वेबसाइट.

6। पोलरिस

यस लेखमा छलफल गरिने अन्तिम उपकरण हो पोलारिस. (उनको गत वर्षको घोषणा हामी पहिले नै अनुवाद - लगभग। अनुवाद)

पोलारिस क्लस्टरमा स्थापित गर्न सकिन्छ वा कमांड लाइन मोडमा प्रयोग गर्न सकिन्छ। तपाईले अनुमान गर्नु भएको हुनसक्छ, यसले तपाईलाई Kubernetes manifests लाई स्थिर रूपमा विश्लेषण गर्न अनुमति दिन्छ।

कमाण्ड लाइन मोडमा चल्दा, बिल्ट-इन परीक्षणहरू सुरक्षा र उत्तम अभ्यासहरू (कुबे-स्कोर जस्तै) कभर गर्ने क्षेत्रहरू उपलब्ध हुन्छन्। थप रूपमा, तपाइँ तपाइँको आफ्नै परीक्षणहरू सिर्जना गर्न सक्नुहुन्छ (जस्तै कन्फिग-लिन्ट, कपर र कन्फेस्टमा)।

अन्य शब्दहरूमा, पोलारिसले उपकरणहरूको दुवै कोटीहरूको फाइदाहरू संयोजन गर्दछ: बिल्ट-इन र अनुकूलन परीक्षणहरूसँग।

कमाण्ड लाइन मोडमा पोलारिस स्थापना गर्न, प्रयोग गर्नुहोस् परियोजना वेबसाइटमा निर्देशनहरू.

मूल लेख लेख्ने समयमा, संस्करण 1.0.3 उपलब्ध छ।

एक पटक स्थापना पूरा भएपछि तपाईंले manifest मा पोलारिस चलाउन सक्नुहुन्छ 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 manifest सँग।

हाम्रो घोषणापत्र परीक्षण गरौं base-valid.yaml:

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

टोली polaris audit माथि निर्दिष्ट गरिएको प्रयोगकर्ता परीक्षण मात्र चल्यो र यो असफल भयो।

यदि तपाईंले छविलाई ठीक गर्नुभयो भने my-company.com/http-echo:1.0, पोलारिस सफलतापूर्वक पूरा हुनेछ। परिवर्तनसहितको घोषणापत्र आइसकेको छ भण्डारहरूत्यसैले तपाईंले manifest मा अघिल्लो आदेश जाँच गर्न सक्नुहुन्छ image-valid-mycompany.yaml.

अब प्रश्न उठ्छ: कसरी अनुकूलन परीक्षणहरू सँगै बिल्ट-इन परीक्षणहरू चलाउने? सजिलै! तपाईंले कन्फिगरेसन फाइलमा निर्मित परीक्षण पहिचानकर्ताहरू थप्न आवश्यक छ। नतिजाको रूपमा, यसले निम्न फारम लिनेछ:

checks:
  cpuRequestsMissing: warning
  cpuLimitsMissing: warning
  # Other inbuilt checks..
  # ..
  # custom checks
  checkImageRepo: danger # !!!
customChecks:
  checkImageRepo:        # !!!
    successMessage: Image registry is valid
    failureMessage: Image registry is not valid
    category: Images
    target: Container
    schema:
      '$schema': http://json-schema.org/draft-07/schema
      type: object
      properties:
        image:
          type: string
          pattern: ^my-company.com/.+$

(config_with_custom_check.yaml)

पूर्ण कन्फिगरेसन फाइलको उदाहरण उपलब्ध छ यहाँ.

manifest जाँच गर्नुहोस् base-valid.yamlबिल्ट-इन र अनुकूलन परीक्षणहरू प्रयोग गरेर, तपाइँ आदेश प्रयोग गर्न सक्नुहुन्छ:

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

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

अर्कोतर्फ, रेगो वा जाभास्क्रिप्ट जस्ता अधिक शक्तिशाली भाषाहरू प्रयोग गर्न असक्षमता थप परिष्कृत परीक्षणहरूको सिर्जनालाई रोक्नको लागि सीमित कारक हुन सक्छ।

Polaris बारे थप जानकारी मा उपलब्ध छ परियोजना वेबसाइट.

सारांश

जबकि त्यहाँ Kubernetes YAML फाइलहरू निरीक्षण र मूल्याङ्कन गर्न धेरै उपकरणहरू उपलब्ध छन्, परीक्षणहरू कसरी डिजाइन र कार्यान्वयन हुनेछन् भन्ने स्पष्ट बुझाइ हुनु महत्त्वपूर्ण छ.

उदाहरणका लागि, यदि तपाइँ पाइपलाइनमा जाने कुबेरनेट्स मेनिफेस्टहरू लिनुहुन्छ भने, कुबेवल यस्तो पाइपलाइनमा पहिलो चरण हुन सक्छ।। यसले वस्तु परिभाषाहरू Kubernetes API स्कीमा अनुरूप छन् कि छैनन् भनेर निगरानी गर्नेछ।

एक पटक यस्तो समीक्षा पूरा भएपछि, कसैले मानक उत्कृष्ट अभ्यासहरू र विशिष्ट नीतिहरूको अनुपालन जस्ता थप परिष्कृत परीक्षणहरूमा जान सक्छ। यहाँ कुबे-स्कोर र पोलारिस काममा आउनेछन्।

जटिल आवश्यकताहरू भएका र विस्तृत रूपमा परीक्षणहरू अनुकूलन गर्न आवश्यक पर्नेहरूका लागि, कपर, कन्फिग-लिन्ट र कन्फेस्ट उपयुक्त हुनेछ।.

कन्फेस्ट र कन्फिग-लिन्टले अनुकूलन परीक्षणहरू परिभाषित गर्न YAML प्रयोग गर्दछ, र तांबेले तपाईंलाई पूर्ण प्रोग्रामिङ भाषामा पहुँच दिन्छ, यसलाई राम्रो आकर्षक विकल्प बनाउँछ।

अर्कोतर्फ, के यो यी मध्ये कुनै एक उपकरण प्रयोग गर्न लायक छ र, त्यसैले, म्यानुअल रूपमा सबै परीक्षणहरू सिर्जना गर्नुहोस्, वा पोलारिसलाई प्राथमिकता दिनुहोस् र यसमा आवश्यक पर्ने मात्र थप्नुहोस्? यस प्रश्नको कुनै स्पष्ट जवाफ छैन.

तलको तालिकाले प्रत्येक उपकरणको संक्षिप्त विवरण प्रदान गर्दछ:

उपकरण
उद्देश्य
कमीकमजोरी
प्रयोगकर्ता परीक्षणहरू

कुबेवल
एपीआई स्कीमा को एक विशेष संस्करण विरुद्ध YAML प्रकट प्रमाणित गर्दछ
CRD सँग काम गर्न सकिँदैन
कुनै

kube-स्कोर
विश्लेषण YAML उत्कृष्ट अभ्यासहरू विरुद्ध प्रकट हुन्छ
स्रोतहरू जाँच गर्न तपाईंको Kubernetes API संस्करण चयन गर्न सकिँदैन
कुनै

तामा
YAML manifests को लागि अनुकूलन JavaScript परीक्षणहरू सिर्जना गर्नको लागि एक सामान्य ढाँचा
बिल्ट-इन परीक्षणहरू छैनन्। खराब कागजात
हो

config-lint
YAML मा सम्मिलित डोमेन-विशिष्ट भाषामा परीक्षणहरू सिर्जना गर्नको लागि एक सामान्य ढाँचा। विभिन्न कन्फिगरेसन ढाँचाहरूलाई समर्थन गर्दछ (जस्तै Terraform)
त्यहाँ कुनै तयार परीक्षणहरू छैनन्। बिल्ट-इन दावी र कार्यहरू पर्याप्त नहुन सक्छ
हो

प्रतिस्पर्धा
रेगो (एक विशेष क्वेरी भाषा) प्रयोग गरेर आफ्नै परीक्षणहरू सिर्जना गर्ने ढाँचा। OCI बन्डलहरू मार्फत नीतिहरू साझेदारी गर्न अनुमति दिन्छ
बिल्ट-इन परीक्षणहरू छैनन्। मैले रेगो सिक्नु पर्छ। नीतिहरू प्रकाशित गर्दा डकर हब समर्थित छैन
हो

पोलारिस
YAML ले मानक उत्कृष्ट अभ्यासहरू विरुद्ध प्रकट गर्दछ समीक्षा गर्दछ। JSON स्कीमा प्रयोग गरेर तपाईलाई आफ्नै परीक्षणहरू सिर्जना गर्न अनुमति दिन्छ
JSON स्कीमामा आधारित परीक्षण क्षमताहरू पर्याप्त नहुन सक्छ
हो

किनभने यी उपकरणहरू Kubernetes क्लस्टरमा पहुँचमा भर पर्दैनन्, तिनीहरू स्थापना गर्न सजिलो छन्। तिनीहरूले तपाईंलाई स्रोत फाइलहरू फिल्टर गर्न र परियोजनाहरूमा पुल अनुरोधहरूको लेखकहरूलाई द्रुत प्रतिक्रिया प्रदान गर्न अनुमति दिन्छ।

अनुवादकबाट PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «पोलारिसले Kubernetes क्लस्टरहरूलाई स्वस्थ राख्नको लागि पेश गर्यो»;
• «Kubernetes को लागि YAML समर्थन संग Vim»;
• «गुगल अनुसार कन्टेनरहरू प्रयोग गर्नका लागि 7 उत्तम अभ्यासहरू"।

स्रोत: www.habr.com