پرو هوسٽر > بلاگ > انتظاميه > بهترين عملن ۽ پاليسين جي خلاف ڪبرنيٽس YAML جي تصديق ڪريو

بهترين عملن ۽ پاليسين جي خلاف ڪبرنيٽس YAML جي تصديق ڪريو

نوٽ. ترجمو: K8s ماحوليات لاء YAML ترتيبن جي وڌندڙ تعداد سان، انهن جي خودڪار تصديق جي ضرورت وڌيڪ ۽ وڌيڪ تڪڙي ٿي ويندي آهي. هن جائزي جي ليکڪ نه رڳو هن ڪم لاءِ موجوده حل چونڊيا آهن، پر انهن کي ڪيئن ڪم ڪرڻ لاءِ مثال طور استعمال ڪيو ويو آهي. اھو انھن لاءِ تمام معلوماتي ثابت ٿيو جيڪي ھن موضوع ۾ دلچسپي رکن ٿا.

بهترين عملن ۽ پاليسين جي خلاف ڪبرنيٽس YAML جي تصديق ڪريو

TL، ڊاڪٽر: هي آرٽيڪل ڇهن جامد اوزارن جو مقابلو ڪري ٿو ڪبرنيٽس YAML فائلن کي صحيح ۽ جائزو وٺڻ لاءِ بهترين عملن ۽ گهرجن جي خلاف.

Kubernetes ڪم لوڊ عام طور تي YAML دستاويزن جي صورت ۾ بيان ڪيا ويا آهن. YAML سان مسئلن مان هڪ آهي واضح فائلن جي وچ ۾ رڪاوٽون يا رشتا بيان ڪرڻ جي مشڪل.

ڇا جيڪڏهن اسان کي پڪ ڪرڻ جي ضرورت آهي ته ڪلستر تي لڳل سڀئي تصويرون هڪ قابل اعتماد رجسٽري مان اچن ٿيون؟

مان انهن ڊيپلائيمينٽن کي ڪيئن روڪي سگهان ٿو جن وٽ پوڊ ڊسپريشن بجيٽ نه آهي ڪلستر ڏانهن موڪلڻ کان؟

جامد جانچ جي انضمام توهان کي ترقي جي اسٽيج تي غلطين ۽ پاليسي جي ڀڃڪڙي جي نشاندهي ڪرڻ جي اجازت ڏئي ٿي. اهو گارنٽي وڌائي ٿو ته وسيلن جي وصف صحيح ۽ محفوظ آهن، ۽ اهو وڌيڪ ممڪن بڻائي ٿو ته پيداوار جي ڪم لوڊ بهترين عملن جي پيروي ڪندا.

Kubernetes جامد YAML فائل انسپيڪشن ايڪو سسٽم کي هيٺين ڀاڱن ۾ ورهائي سگهجي ٿو:

  • API جي تصديق ڪندڙ. هن درجي جا اوزار چيڪ ڪن ٿا YAML منشور کي Kubernetes API سرور جي گهرجن جي خلاف.
  • تيار ٽيسٽ ڪندڙ. هن درجي جا اوزار سيڪيورٽي لاءِ تيار ڪيل ٽيسٽن سان گڏ ايندا آهن، بهترين عملن جي تعميل وغيره.
  • حسب ضرورت تصديق ڪندڙ. هن درجي جا نمائندا توهان کي مختلف ٻولين ۾ ڪسٽم ٽيسٽ ٺاهڻ جي اجازت ڏين ٿا، مثال طور، ريگو ۽ جاوا اسڪرپٽ.

هن آرٽيڪل ۾ اسين ڇهن مختلف اوزارن جو بيان ۽ مقابلو ڪنداسين:

  1. ڪبيوال؛
  2. ڪوبي-اسڪور؛
  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 repositories.

مينيفيسٽ هڪ ويب ايپليڪيشن کي بيان ڪري ٿو جنهن جو مکيه ڪم هڪ "هيلو ورلڊ" پيغام سان پورٽ 5678 ڏانهن جواب ڏيڻ آهي. اهو هيٺ ڏنل حڪم سان ترتيب ڏئي سگهجي ٿو:

kubectl apply -f hello-world.yaml

۽ پوء - ڪم چيڪ ڪريو:

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

ھاڻي ڏانھن وو http://localhost:8080 ۽ تصديق ڪريو ته ايپليڪيشن ڪم ڪري رهي آهي. پر ڇا اهو بهترين عملن جي پيروي ڪري ٿو؟ اچو ته چيڪ ڪريو.

1. ڪبيوال

اندر ۾ ڪبيوال خيال اهو آهي ته ڪبرنيٽس سان ڪو به رابطو ان جي 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)

جيڪڏهن ڪامياب ٿيو ته، ڪبيوال نڪرڻ واري ڪوڊ سان نڪرندو 0. توھان ان کي ھيٺين طور چيڪ ڪري سگھو ٿا:

$ echo $?
0

اچو ته هاڻي ڪوشش ڪريون ڪوبيوال کي هڪ مختلف منشور سان:

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

(kubeval-invalid.yaml)

ڇا توهان اکين سان مسئلو ڳولي سگهو ٿا؟ اچو ته لانچ ڪريون:

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

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

وسيلن جي تصديق نه ڪئي وئي آهي.

API ورزن استعمال ڪندي ڊيپلائيشن apps/v1, هڪ چونڊيندڙ کي شامل ڪرڻ گهرجي جيڪو پوڊ جي ليبل سان ملندو آهي. مٿي ڏنل پڌرنامي ۾ چونڊيندڙ شامل نه آهي، تنهن ڪري ڪوبيوال هڪ غلطي جي رپورٽ ڪئي ۽ غير صفر ڪوڊ سان نڪتل.

مان حيران آهيان ته ڇا ٿيندو kubectl apply -f هن منشور سان؟

خير، اچو ته ڪوشش ڪريون:

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

اها ئي غلطي آهي جنهن بابت ڪوبيوال خبردار ڪيو هو. توھان ھن کي درست ڪري سگھو ٿا چونڊيندڙ شامل ڪندي:

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

(base-valid.yaml)

ڪبيوال وانگر اوزارن جو فائدو اهو آهي ته اهڙن غلطين کي پڪڙي سگهجي ٿو شروعات ۾ مقرري جي چڪر ۾.

اضافي طور تي، انهن چيڪن کي ڪلستر تائين رسائي جي ضرورت ناهي؛ اهي آف لائن ڪري سگهجن ٿيون.

ڊفالٽ طور، kubeval تازو Kubernetes API اسڪيما جي خلاف وسيلن کي چيڪ ڪري ٿو. جڏهن ته، اڪثر ڪيسن ۾ توهان کي ڪنهن مخصوص ڪبرنيٽس رليز جي خلاف چيڪ ڪرڻ جي ضرورت پوندي. اهو پرچم استعمال ڪندي ڪري سگهجي ٿو --kubernetes-version:

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

مهرباني ڪري نوٽ ڪريو ته نسخو فارميٽ ۾ بيان ڪيو وڃي Major.Minor.Patch.

نسخن جي فهرست لاءِ جن جي تصديق جي حمايت ڪئي وئي آهي، مهرباني ڪري ڏسو GitHub تي JSON اسڪيما، جيڪو ڪبيوال تصديق لاءِ استعمال ڪري ٿو. جيڪڏهن توهان کي هلائڻ جي ضرورت آهي kubeval آف لائن، اسڪيما ڊائون لوڊ ڪريو ۽ پرچم استعمال ڪندي انهن جي مقامي مقام جي وضاحت ڪريو --schema-location.

انفرادي YAML فائلن جي اضافي ۾، ڪبيوال پڻ ڊائريڪٽرن ۽ اسٽين سان ڪم ڪري سگھن ٿا.

ان کان سواء، ڪوبيوال آساني سان CI پائپ لائن ۾ ضم ٿي. جيڪي ڪلستر ڏانهن منشور موڪلڻ کان اڳ ٽيسٽ هلائڻ جي خواهشمند آهن اهي ڄاڻڻ لاءِ خوش ٿيندا ته ڪوبيوال ٽن آئوٽ پٽ فارميٽ کي سپورٽ ڪري ٿو:

  1. سادي متن؛
  2. JSON؛
  3. ڪجھ به پروٽوڪول جي جانچ ڪريو (TAP).

۽ ڪنهن به فارميٽ کي استعمال ڪري سگھجن ٿا آئوٽ جي وڌيڪ تجزيي لاءِ گهربل قسم جي نتيجن جو خلاصو پيدا ڪرڻ لاءِ.

ڪبيوال جي خرابين مان هڪ آهي ته اهو في الحال ڪسٽم ريسورس ڊيفينشنز (CRDs) جي تعميل جي جانچ نٿو ڪري سگهي. بهرحال، اهو ممڪن آهي ته ڪوبيوال کي ترتيب ڏيو ان کي نظر انداز ڪريو.

Kubeval وسيلن جي چڪاس ۽ جائزو وٺڻ لاء هڪ بهترين اوزار آهي. بهرحال، اهو زور ڀريو وڃي ٿو ته امتحان پاس ڪرڻ جي ضمانت نه آهي ته وسيلن جي بهترين عملن جي تعميل آهي.

مثال طور، ٽيگ استعمال ڪندي 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 kubeval ٽيسٽ پاس ڪري ٿو، جڏهن ته ڪوبي-اسڪور هيٺين خامين ڏانهن اشارو ڪري ٿو:

  • تياري جي چڪاس ترتيب نه ڏني وئي آهي.
  • سي پي يو وسيلن ۽ ياداشت لاءِ ڪي به درخواستون يا حدون نه آهن.
  • پوڊ جي رڪاوٽ جي بجيٽ بيان نه ڪئي وئي آهي.
  • جدا ٿيڻ جا ڪي به ضابطا نه آهن (مخالف تعلق) دستيابي کي وڌائڻ لاء.
  • ڪنٽينر روٽ وانگر هلندو آهي.

اهي سڀ صحيح نقطا آهن نقص جي باري ۾ جن کي حل ڪرڻ جي ضرورت آهي ڊيپلائيمينٽ کي وڌيڪ موثر ۽ قابل اعتماد بڻائڻ لاءِ.

ٽيم 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

kubeval سان ملندڙ جلندڙ، ڪوبي-اسڪور هڪ غير صفر نڪرڻ واري ڪوڊ کي واپس ڪري ٿو جڏهن ڪو امتحان آهي جيڪو ناڪام ٿئي ٿو ڪريٽو. توھان پڻ ساڳيو پروسيسنگ کي چالو ڪري سگھو ٿا خبردار.

ان کان علاوه، اهو ممڪن آهي ته مختلف API نسخن جي تعميل لاء وسيلن جي جانچ ڪرڻ (جيئن ته ڪبيوال ۾). بهرحال، هي معلومات خود ڪبي-اسڪور ۾ هارڊ ڪوڊ ٿيل آهي: توهان ڪبرنيٽس جو مختلف ورزن نه چونڊي سگهو ٿا. اها حد هڪ وڏو مسئلو ٿي سگهي ٿي جيڪڏهن توهان پنهنجي ڪلستر کي اپڊيٽ ڪرڻ جو ارادو رکو ٿا يا جيڪڏهن توهان وٽ K8s جي مختلف ورزن سان ڪيترائي ڪلستر آهن.

اهو ياد رک اتي اڳ ۾ ئي هڪ مسئلو آهي هن موقعي کي محسوس ڪرڻ جي تجويز سان.

kube-score بابت وڌيڪ معلومات ملي سگهي ٿي سرڪاري ويب سائيٽ.

ڪبي-اسڪور ٽيسٽ بهترين عملن کي لاڳو ڪرڻ لاءِ هڪ بهترين اوزار آهن، پر جيڪڏهن توهان کي ٽيسٽ ۾ تبديليون آڻڻ يا پنهنجا ضابطا شامل ڪرڻ گهرجن؟ افسوس، اهو نه ٿو ڪري سگهجي.

Kube-score extensible نه آهي: توهان ان ۾ پاليسيون شامل نه ٿا ڪري سگهو يا انهن کي ترتيب ڏئي سگهو ٿا.

جيڪڏهن توهان کي ڪمپني جي پاليسين جي تعميل جي تصديق ڪرڻ لاءِ ڪسٽم ٽيسٽ لکڻ جي ضرورت آهي، توهان هيٺ ڏنل چار اوزارن مان هڪ استعمال ڪري سگهو ٿا: config-lint، copper، confest، or polaris.

3.Config-lint

Config-lint YAML، JSON، Terraform، CSV ڪنفيگريشن فائلن ۽ Kubernetes manifests جي تصديق ڪرڻ لاءِ ھڪڙو اوزار آھي.

توھان ان کي استعمال ڪندي انسٽال ڪري سگھو ٿا هدايتون منصوبي جي ويب سائيٽ تي.

اصل مضمون لکڻ جي وقت تائين موجوده رليز 1.5.0 آهي.

Config-lint وٽ ڪوبرنيٽس مينيفيسٽس کي درست ڪرڻ لاءِ بلٽ ان ٽيسٽ نه آهي.

ڪنهن به امتحان کي منظم ڪرڻ لاء، توهان کي مناسب ضابطن ٺاهڻ جي ضرورت آهي. اهي YAML فائلن ۾ لکيل آهن جن کي "قاعدن" سڏيو ويندو آهي (قاعدا)، ۽ ھيٺ ڏنل جوڙجڪ آھي:

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

(rule.yaml)

اچو ته ان کي وڌيڪ تفصيل سان پڙهون:

  • ميدان type وضاحت ڪري ٿي ته ڪهڙي قسم جي configuration config-lint استعمال ڪندي. K8s لاء اهو ظاهر ٿئي ٿو ھميشہ Kubernetes.
  • جي ميدان ۾ files پاڻ فائلن جي اضافي ۾، توهان هڪ ڊاريڪٽري بيان ڪري سگهو ٿا.
  • ميدان rules استعمال ڪندڙ ٽيسٽ کي ترتيب ڏيڻ جو مقصد.

اچو ته چئو ته توھان پڪ ڪرڻ چاھيو ٿا ته ڊيپلائيمينٽ ۾ تصويرون ھميشه قابل اعتماد مخزن مان ڊائون لوڊ ڪيون وينديون آھن جھڙوڪ my-company.com/myapp:1.0. هڪ config-lint قاعدو جيڪو انجام ڏئي ٿو اهڙي چيڪ هن طرح نظر ايندو:

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

(rule-trusted-repo.yaml)

هر قاعدي ۾ هيٺيون خاصيتون هجڻ گهرجن:

  • id - قاعدي جي منفرد سڃاڻپ ڪندڙ؛
  • severity - ٿي سگهي ٿو ناڪامي, خبردار и 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
[]

Config-lint هڪ واعدو ڪندڙ فريم ورڪ آهي جيڪو توهان کي اجازت ڏئي ٿو توهان جا پنهنجا ٽيسٽ ٺاهڻ جي تصديق ڪرڻ لاءِ ڪبرنيٽس YAML منشور YAML DSL استعمال ڪندي.

پر جيڪڏهن توهان کي وڌيڪ پيچيده منطق ۽ تجربن جي ضرورت آهي؟ ڇا YAML ان لاءِ تمام محدود ناهي؟ ڇا جيڪڏهن توهان مڪمل پروگرامنگ ٻولي ۾ ٽيسٽ ٺاهي سگهو ٿا؟

4. ٽوپي

ڪاپر V2 ڪسٽم ٽيسٽ استعمال ڪندي منشور جي تصديق لاءِ هڪ فريم ورڪ آهي (جيئن config-lint).

بهرحال، اهو بعد ۾ مختلف آهي ته اهو YAML استعمال نه ڪندو آهي ٽيسٽ بيان ڪرڻ لاء. ٽيسٽ بدران JavaScript ۾ لکي سگهجن ٿيون. ڪاپر ڪيترن ئي بنيادي اوزارن سان گڏ لائبريري مهيا ڪري ٿو، جيڪو توهان کي ڪبرنيٽس شين جي باري ۾ معلومات پڙهڻ ۽ غلطين جي رپورٽ ڪرڻ ۾ مدد ڪري ٿو.

ڪاپر کي انسٽال ڪرڻ جا مرحلا ڳولي سگهجن ٿا سرڪاري دستاويز.

2.0.1 اصل مضمون لکڻ جي وقت هن افاديت جو تازو رليز آهي.

config-lint وانگر، ڪاپر ۾ تعمير ٿيل ٽيسٽ نه آهن. اچو ته هڪ لکون. ان کي چيڪ ڪرڻ ڏيو ته ڊيپلائيزيشن ڪنٽينر تصويرون استعمال ڪن ٿيون خاص طور تي قابل اعتماد ريپوزٽريز مان 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 فائل کي متغير ۾ $$ ۽ ان کي اسڪرپٽنگ لاءِ دستياب بڻائي ٿو (جيڪي جو تجربو رکندڙ ماڻهن لاءِ هڪ واقف ٽيڪنڪ).

Copper جو بنيادي فائدو واضح آهي: توهان کي ڪنهن خاص ٻوليءَ ۾ مهارت حاصل ڪرڻ جي ضرورت نه آهي ۽ توهان جاوا اسڪرپٽ جون مختلف خاصيتون استعمال ڪري سگهو ٿا پنهنجا ٽيسٽ ٺاهڻ لاءِ، جهڙوڪ اسٽرنگ انٽرپوليشن، افعال وغيره.

اهو پڻ ياد رکڻ گهرجي ته Copper جو موجوده نسخو جاوا اسڪرپٽ انجڻ جي ES5 ورزن سان ڪم ڪري ٿو، نه ES6.

تفصيلات موجود آهن تي سرڪاري پروجيڪٽ ويب سائيٽ.

تنهن هوندي، جيڪڏهن توهان واقعي جاوا اسڪرپٽ پسند نٿا ڪريو ۽ خاص طور تي سوالن ٺاهڻ ۽ پاليسين کي بيان ڪرڻ لاءِ ٺهيل ٻولي کي ترجيح ڏيو، توهان کي مقابلي تي ڌيان ڏيڻ گهرجي.

5. Conftest

Confest هڪ فريم ورڪ آهي ترتيب ڏيڻ واري ڊيٽا کي جانچڻ لاءِ. Kubernetes manifests جي جانچ/تصديق ڪرڻ لاءِ پڻ موزون. ٽيسٽ هڪ خاص سوال جي ٻولي استعمال ڪندي بيان ڪيا ويا آهن ريگو.

توهان استعمال ڪندي conftest انسٽال ڪري سگهو ٿا هدايتونمنصوبي جي ويب سائيٽ تي درج ٿيل.

اصل مضمون لکڻ وقت، جديد نسخو موجود هو 0.18.2.

config-lint ۽ copper سان ملندڙ جلندڙ، مقابلو بغير ڪنهن بلٽ ان ٽيسٽ جي اچي ٿو. اچو ته ڪوشش ڪريون ۽ پنهنجي پاليسي لکون. جيئن اڳئين مثالن ۾، اسان چيڪ ڪنداسين ته ڇا ڪنٽينر جون تصويرون ڪنهن قابل اعتماد ذريعن کان ورتيون ويون آهن.

ڊاريڪٽري ٺاھيو 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 (Open Container Initiative) رجسٽري ۾ آرٽيڪلز جي طور تي.

Команды push и pull توهان کي هڪ آرٽيڪل شايع ڪرڻ جي اجازت ڏئي ٿي يا ريموٽ رجسٽري مان موجوده آرٽيڪل ٻيهر حاصل ڪرڻ. اچو ته اها پاليسي شايع ڪرڻ جي ڪوشش ڪريون جيڪا اسان ٺاهي مقامي ڊاڪر رجسٽري کي استعمال ڪندي conftest push.

توهان جي مقامي Docker رجسٽري شروع ڪريو:

$ docker run -it --rm -p 5000:5000 registry

ٻئي ٽرمينل ۾، ڊاريڪٽري ڏانھن وڃو جيڪو توھان اڳ ۾ ٺاھيو آھي conftest-checks ۽ ھيٺ ڏنل حڪم هلائي:

$ conftest push 127.0.0.1:5000/amitsaha/opa-bundle-example:latest

جيڪڏهن حڪم ڪامياب ٿي ويو، توهان هن وانگر هڪ پيغام ڏسندا:

2020/06/10 14:25:43 pushed bundle with digest: sha256:e9765f201364c1a8a182ca637bc88201db3417bacc091e7ef8211f6c2fd2609c

ھاڻي ھڪ عارضي ڊاريڪٽري ٺاھيو ۽ ان ۾ ڪمانڊ ھلايو conftest pull. اهو پوئين حڪم پاران ٺاهيل پيڪيج ڊائون لوڊ ڪندو:

$ cd $(mktemp -d)
$ conftest pull 127.0.0.1:5000/amitsaha/opa-bundle-example:latest

هڪ ذيلي ڊاريڪٽري عارضي ڊاريڪٽري ۾ ظاهر ٿيندي policyاسان جي پاليسي فائل تي مشتمل آهي:

$ tree
.
└── policy
  └── check_image_registry.rego

ٽيسٽ سڌو سنئون مخزن مان هلائي سگھجن ٿيون:

$ conftest test --update 127.0.0.1:5000/amitsaha/opa-bundle-example:latest base-valid.yaml
..
FAIL - base-valid.yaml - image 'hashicorp/http-echo' doesn't come from my-company.com repository
2 tests, 1 passed, 0 warnings, 1 failure

بدقسمتي سان، DockerHub اڃا تائين سپورٽ ناهي. تنهن ڪري پنهنجو پاڻ کي خوش قسمت سمجهيو جيڪڏهن توهان استعمال ڪريو Azure ڪنٽينر رجسٽري (ACR) يا توهان جي پنهنجي رجسٽري.

artifact فارميٽ ساڳيو آهي کليل پاليسي ايجنٽ پيڪيجز (OPA)، جيڪو توهان کي موجوده OPA پيڪيجز مان ٽيسٽ هلائڻ لاءِ مقابلو استعمال ڪرڻ جي اجازت ڏئي ٿو.

توهان پاليسي شيئرنگ ۽ مقابلي جي ٻين خاصيتن جي باري ۾ وڌيڪ سکو سگهو ٿا سرڪاري پروجيڪٽ ويب سائيٽ.

6. پولارس

آخري اوزار آهي ته هن مضمون ۾ بحث ڪيو ويندو آهي پولارس. (هن جو گذريل سال جو اعلان اسان اڳ ۾ ئي ترجمو ڪيو ويو آهي - لڳ ڀڳ ترجمو)

پولارس کي ڪلستر ۾ نصب ڪري سگھجي ٿو يا ڪمانڊ لائن موڊ ۾ استعمال ڪيو وڃي. جئين توهان اندازو ڪيو هوندو، اهو توهان کي اجازت ڏئي ٿو ته توهان ڪبرنيٽس جي ظاهري بيانن جو مستحڪم تجزيو ڪيو.

جڏهن ڪمانڊ لائن موڊ ۾ هلندي، بلٽ ان ٽيسٽ موجود هوندا آهن جيڪي علائقن کي ڍڪيندا آهن جهڙوڪ سيڪيورٽي ۽ بهترين طريقا (ڪيوب-اسڪور وانگر). اضافي طور تي، توهان پنهنجون ٽيسٽ ٺاهي سگهو ٿا (جيئن ته config-lint، copper ۽ confest ۾).

ٻين لفظن ۾، پولارس اوزار جي ٻنهي قسمن جي فائدن کي گڏ ڪري ٿو: بلٽ ان ۽ ڪسٽم ٽيسٽ سان.

ڪمانڊ لائن موڊ ۾ پولارس کي انسٽال ڪرڻ لاءِ، استعمال ڪريو منصوبي جي ويب سائيٽ تي هدايتون.

اصل مضمون لکڻ جي وقت، نسخو 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": [
    /* длинный список */
  ]
}

مڪمل پيداوار دستياب هتي.

kube-score وانگر، Polaris انهن علائقن ۾ مسئلن جي نشاندهي ڪري ٿو جتي منشور بهترين عملن کي پورو نٿو ڪري:

  • پوڊ لاءِ ڪي به صحت جي چڪاس نه آهن.
  • ڪنٽينر تصويرن لاءِ ٽيگ بيان نه ڪيا ويا آهن.
  • ڪنٽينر روٽ وانگر هلندو آهي.
  • ميموري ۽ سي پي يو لاءِ درخواستون ۽ حدون بيان نه ڪيون ويون آهن.

هر امتحان، ان جي نتيجن تي منحصر ڪري، تنقيد جو درجو مقرر ڪيو ويو آهي: دڙڪا يا خطرو. دستياب بلٽ ان ٽيسٽ بابت وڌيڪ سکڻ لاءِ، مهرباني ڪري ڏسو دستاويز.

جيڪڏهن تفصيل گهربل نه آهي، توهان پرچم کي بيان ڪري سگهو ٿا --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

پولارس بلٽ ان ٽيسٽ کي مڪمل ڪري ٿو ڪسٽم وارن سان، ان ڪري ٻنهي دنيان جي بهترين کي گڏ ڪري ٿو.

ٻئي طرف، وڌيڪ طاقتور ٻولين جهڙوڪ ريگو يا جاوا اسڪرپٽ استعمال ڪرڻ جي ناڪامي هڪ محدود عنصر ٿي سگهي ٿي جيڪا وڌيڪ نفيس ٽيسٽ جي تخليق کي روڪي ٿي.

پولارس بابت وڌيڪ معلومات دستياب آهي منصوبي جي ويب سائيٽ.

خلاصو

جڏهن ته ڪيبرنيٽس YAML فائلن جي معائنو ۽ جائزو وٺڻ لاءِ ڪيترائي اوزار موجود آهن، اهو ضروري آهي ته هڪ واضح سمجهه ۾ هجي ته ٽيسٽ ڪيئن ٺاهيا ويندا ۽ ان تي عمل ڪيو ويندو.

مثال طور، جيڪڏهن توهان پائيپ لائين مان گذرندڙ Kubernetes manifests وٺو، ڪبيوال اهڙي پائپ لائن ۾ پهريون قدم ٿي سگهي ٿو. اهو مانيٽر ڪندو ته ڇا اعتراض جي تعريف ڪبرنيٽس API اسڪيما سان مطابقت رکي ٿي.

هڪ دفعو اهڙو جائزو مڪمل ٿيڻ بعد، هڪ وڌيڪ نفيس ٽيسٽن ڏانهن منتقل ٿي سگهي ٿو، جهڙوڪ معياري بهترين عملن ۽ مخصوص پاليسين جي تعميل. هي اهو آهي جتي ڪبي سکور ۽ پولارس هٿ ۾ ايندا.

انهن لاءِ جن کي پيچيده گهرجون آهن ۽ ٽيسٽ کي تفصيل سان ترتيب ڏيڻ جي ضرورت آهي، ٽامي، ترتيب-لنٽ ۽ مقابلو مناسب هوندا.

Conftest ۽ config-lint استعمال ڪري ٿو YAML ڪسٽم ٽيسٽ کي بيان ڪرڻ لاءِ، ۽ ڪاپر توهان کي مڪمل پروگرامنگ ٻولي تائين رسائي ڏئي ٿي، ان کي هڪ خوبصورت پرڪشش پسند بڻائيندي.

ٻئي طرف، ڇا اهو انهن اوزارن مان هڪ کي استعمال ڪرڻ جي قابل آهي، ۽ تنهن ڪري، دستي طور تي سڀني ٽيسٽ ٺاهڻ، يا پولارس کي ترجيح ڏيو ۽ صرف ان کي شامل ڪريو جيڪي ان جي ضرورت آهي؟ هن سوال جو ڪو به واضح جواب نه آهي.

هيٺ ڏنل جدول هر اوزار جي مختصر وضاحت مهيا ڪري ٿو:

ساز
مقصد
shortcomings
استعمال ڪندڙ ٽيسٽ

ڪبيوال
تصديق ڪري ٿو YAML ظاهر ڪري ٿو API اسڪيما جي مخصوص ورزن جي خلاف
CRD سان ڪم نٿو ڪري سگھجي
نه

ڪوبي-اسڪور
YAML جو تجزيو ڪيو بهترين عملن جي خلاف ظاهر ٿئي ٿو
وسيلا چيڪ ڪرڻ لاءِ توهان جو ڪبرنيٽس API ورزن نه چونڊيو
نه

ٽامي
YAML manifests لاءِ ڪسٽم جاوا اسڪرپٽ ٽيسٽ ٺاهڻ لاءِ هڪ عام فريم ورڪ
نه بلٽ ان ٽيسٽ. ناقص دستاويز
ته

config-lint
YAML ۾ شامل ٿيل ڊومين-مخصوص ٻولي ۾ ٽيسٽ ٺاهڻ لاءِ هڪ عام فريم ورڪ. مختلف ترتيبن جي فارميٽ کي سپورٽ ڪري ٿو (مثال طور Terraform)
تيار ٿيل ٽيسٽ نه آهن. بلٽ-ان دعويٰ ۽ افعال ڪافي نه هوندا
ته

مقابلو
ريگو (هڪ خاص سوال جي ٻولي) استعمال ڪندي پنهنجون ٽيسٽون ٺاهڻ لاءِ هڪ فريم ورڪ. OCI بنڊل ذريعي پاليسين جي حصيداري جي اجازت ڏئي ٿي
نه بلٽ ان ٽيسٽ. مون کي ريگو سکڻو آهي. Docker Hub سپورٽ نه آهي جڏهن پاليسين شايع ڪري ٿي
ته

پولارس
جائزو YAML معياري بهترين عملن جي خلاف ظاهر ڪري ٿو. توهان کي اجازت ڏئي ٿي توهان جي پنهنجي ٽيسٽ ٺاهڻ جي JSON اسڪيما استعمال ڪندي
JSON اسڪيما جي بنياد تي ٽيسٽ صلاحيتون ڪافي نه هجن
ته

ڇاڪاڻ ته اهي اوزار ڪبرنيٽس ڪلستر تائين رسائي تي ڀروسو نٿا ڪن، اهي انسٽال ڪرڻ آسان آهن. اهي توهان کي ماخذ فائلن کي فلٽر ڪرڻ جي اجازت ڏين ٿا ۽ منصوبن ۾ پل درخواستن جي ليکڪن کي تڪڙو موٽ ڏيو.

پي ايس مترجم کان

اسان جي بلاگ تي پڻ پڙهو:

جو ذريعو: www.habr.com

تبصرو شامل ڪريو