🥇การตรวจสอบ Kubernetes YAML กับแนวทางปฏิบัติและนโยบายที่ดีที่สุด

บันทึก. แปล: เนื่องจากการกำหนดค่า YAML สำหรับสภาพแวดล้อม K8s มีเพิ่มมากขึ้น ความจำเป็นในการตรวจสอบอัตโนมัติจึงมีความจำเป็นเร่งด่วนมากขึ้นเรื่อยๆ ผู้เขียนการทบทวนนี้ไม่เพียงแต่เลือกโซลูชันที่มีอยู่สำหรับงานนี้ แต่ยังใช้ Deployment เป็นตัวอย่างเพื่อดูว่าโซลูชันทำงานอย่างไร กลายเป็นข้อมูลที่เป็นประโยชน์มากสำหรับผู้ที่สนใจหัวข้อนี้

TL; DR: บทความนี้จะเปรียบเทียบเครื่องมือแบบคงที่ XNUMX รายการเพื่อตรวจสอบและประเมินไฟล์ Kubernetes YAML ตามแนวทางปฏิบัติที่ดีที่สุดและข้อกำหนด

โดยทั่วไปปริมาณงาน Kubernetes จะได้รับการกำหนดในรูปแบบของเอกสาร YAML ปัญหาประการหนึ่งของ YAML คือความยากในการระบุข้อจำกัดหรือความสัมพันธ์ระหว่างไฟล์ Manifest

จะเกิดอะไรขึ้นหากเราต้องการให้แน่ใจว่าอิมเมจทั้งหมดที่ปรับใช้กับคลัสเตอร์มาจากรีจีสทรีที่เชื่อถือได้

ฉันจะป้องกันการปรับใช้ที่ไม่มี PodDisruptionBudgets ไม่ให้ถูกส่งไปยังคลัสเตอร์ได้อย่างไร

การบูรณาการการทดสอบแบบคงที่ทำให้คุณสามารถระบุข้อผิดพลาดและการละเมิดนโยบายได้ในขั้นตอนการพัฒนา สิ่งนี้จะเพิ่มการรับประกันว่าคำจำกัดความของทรัพยากรนั้นถูกต้องและปลอดภัย และทำให้มีแนวโน้มมากขึ้นที่ปริมาณงานการผลิตจะเป็นไปตามแนวทางปฏิบัติที่ดีที่สุด

ระบบนิเวศการตรวจสอบไฟล์ YAML แบบคงที่ของ Kubernetes สามารถแบ่งออกเป็นหมวดหมู่ต่อไปนี้:

เครื่องมือตรวจสอบ API. เครื่องมือในหมวดหมู่นี้จะตรวจสอบไฟล์ Manifest ของ YAML กับข้อกำหนดของเซิร์ฟเวอร์ Kubernetes API
ผู้ทดสอบพร้อมแล้ว. เครื่องมือจากหมวดหมู่นี้มาพร้อมกับการทดสอบความปลอดภัย การปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุด ฯลฯ
เครื่องมือตรวจสอบแบบกำหนดเอง. ตัวแทนของหมวดหมู่นี้อนุญาตให้คุณสร้างการทดสอบแบบกำหนดเองในภาษาต่างๆ เช่น Rego และ Javascript

ในบทความนี้เราจะอธิบายและเปรียบเทียบเครื่องมือที่แตกต่างกันหกรายการ:

คูเบวัล;
kube-คะแนน;
config-ผ้าสำลี;
ทองแดง;
คอนเฟิร์ม;
ดาวเหนือ

เอาล่ะ มาเริ่มกันเลย!

การตรวจสอบการปรับใช้

ก่อนที่เราจะเริ่มเปรียบเทียบเครื่องมือ เรามาสร้างพื้นหลังเพื่อทดสอบเครื่องมือกันก่อน

ประกาศด้านล่างนี้ประกอบด้วยข้อผิดพลาดและการไม่ปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดจำนวนหนึ่ง คุณจะพบข้อผิดพลาดเหล่านี้ได้กี่ข้อ

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

(base-valid.yaml)

เราจะใช้ YAML นี้เพื่อเปรียบเทียบเครื่องมือต่างๆ

แถลงการณ์ข้างต้น base-valid.yaml และประกาศอื่น ๆ จากบทความนี้สามารถพบได้ใน ที่เก็บ Git.

รายการนี้จะอธิบายเว็บแอปพลิเคชันที่มีหน้าที่หลักในการตอบกลับด้วยข้อความ “Hello World” ไปยังพอร์ต 5678 ซึ่งสามารถใช้งานได้ด้วยคำสั่งต่อไปนี้:

kubectl apply -f hello-world.yaml

ดังนั้น - ตรวจสอบงาน:

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

ตอนนี้ไปที่ http://localhost:8080 และยืนยันว่าแอปพลิเคชันใช้งานได้ แต่มันเป็นไปตามแนวทางปฏิบัติที่ดีที่สุดหรือไม่? มาเช็คกัน

1. คูเบวัล

ตรงส่วนฐาน คูเบวาล แนวคิดก็คือการโต้ตอบใดๆ กับ Kubernetes เกิดขึ้นผ่าน REST API กล่าวอีกนัยหนึ่ง คุณสามารถใช้สคีมา API เพื่อตรวจสอบว่า YAML ที่กำหนดสอดคล้องกับสคีมานั้นหรือไม่ ลองดูตัวอย่าง

คำแนะนำในการติดตั้ง kubeval มีอยู่บนเว็บไซต์ของโครงการ

ในขณะที่เขียนบทความต้นฉบับ เวอร์ชัน 0.15.0 ก็พร้อมใช้งาน

เมื่อติดตั้งแล้ว ให้ป้อนรายการด้านบนนี้:

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

หากสำเร็จ kubeval จะออกด้วยรหัสทางออก 0 คุณสามารถตรวจสอบได้ดังนี้:

$ echo $?
0

ตอนนี้เรามาลองใช้ kubeval ด้วย 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

นี่เป็นข้อผิดพลาดที่ kubeval เตือนอย่างแน่นอน คุณสามารถแก้ไขได้โดยการเพิ่มตัวเลือก:

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

(base-valid.yaml)

ข้อดีของเครื่องมืออย่าง kubeval ก็คือข้อผิดพลาดเช่นนี้สามารถตรวจพบได้ตั้งแต่เนิ่นๆ ในรอบการปรับใช้

นอกจากนี้ การตรวจสอบเหล่านี้ไม่จำเป็นต้องเข้าถึงคลัสเตอร์ แต่สามารถดำเนินการแบบออฟไลน์ได้

ตามค่าเริ่มต้น kubeval จะตรวจสอบทรัพยากรกับสคีมา Kubernetes API ล่าสุด อย่างไรก็ตาม ในกรณีส่วนใหญ่ คุณอาจต้องตรวจสอบกับรุ่น Kubernetes รุ่นใดรุ่นหนึ่ง ซึ่งสามารถทำได้โดยใช้ธง --kubernetes-version:

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

โปรดทราบว่าจะต้องระบุเวอร์ชันในรูปแบบ Major.Minor.Patch.

สำหรับรายการเวอร์ชันที่รองรับการตรวจสอบ โปรดดูที่ สคีมา JSON บน GitHubซึ่ง kubeval ใช้สำหรับการตรวจสอบ หากคุณต้องการเรียกใช้ kubeval แบบออฟไลน์ ให้ดาวน์โหลดสคีมาและระบุตำแหน่งในพื้นที่โดยใช้แฟล็ก --schema-location.

นอกจากไฟล์ YAML แต่ละไฟล์แล้ว kubeval ยังสามารถทำงานกับไดเร็กทอรีและ stdin ได้อีกด้วย

นอกจากนี้ Kubeval ยังรวมเข้ากับไปป์ไลน์ CI ได้อย่างง่ายดาย ผู้ที่ต้องการเรียกใช้การทดสอบก่อนที่จะส่งรายการไปยังคลัสเตอร์จะต้องทราบว่า kubeval รองรับรูปแบบเอาต์พุตสามรูปแบบ:

ข้อความธรรมดา;
เจสัน;
ทดสอบโปรโตคอลอะไรก็ได้ (TAP)

และสามารถใช้รูปแบบใดก็ได้ในการแยกวิเคราะห์ผลลัพธ์เพิ่มเติมเพื่อสร้างการสรุปผลลัพธ์ประเภทที่ต้องการ

ข้อเสียประการหนึ่งของ kubeval คือขณะนี้ไม่สามารถตรวจสอบการปฏิบัติตามข้อกำหนดทรัพยากรที่กำหนดเอง (CRD) ได้ อย่างไรก็ตาม คุณสามารถกำหนดค่า kubeval ได้ ไม่สนใจพวกเขา.

Kubeval เป็นเครื่องมือที่ยอดเยี่ยมสำหรับการตรวจสอบและประเมินทรัพยากร อย่างไรก็ตาม ควรเน้นย้ำว่าการผ่านการทดสอบไม่ได้รับประกันว่าทรัพยากรจะเป็นไปตามแนวทางปฏิบัติที่ดีที่สุด

เช่น การใช้แท็ก latest ในคอนเทนเนอร์ไม่ปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุด อย่างไรก็ตาม kubeval ไม่ถือว่านี่เป็นข้อผิดพลาดและไม่ได้รายงาน นั่นคือการตรวจสอบ YAML ดังกล่าวจะเสร็จสิ้นโดยไม่มีคำเตือน

แต่ถ้าคุณต้องการประเมิน YAML และระบุการละเมิดเช่นแท็กล่ะ latest? ฉันจะตรวจสอบไฟล์ YAML กับแนวทางปฏิบัติที่ดีที่สุดได้อย่างไร

2. Kube-คะแนน

Kube-คะแนน แยกวิเคราะห์ YAML และประเมินผลกับการทดสอบในตัว การทดสอบเหล่านี้ได้รับการคัดเลือกตามหลักเกณฑ์ด้านความปลอดภัยและแนวทางปฏิบัติที่ดีที่สุด เช่น:

การรันคอนเทนเนอร์ไม่ใช่ในฐานะรูท
ความพร้อมใช้งานของการตรวจสุขภาพพ็อด
การตั้งค่าคำขอและขีดจำกัดสำหรับทรัพยากร

จากผลการทดสอบจะได้รับผลลัพธ์สามประการ: OK, คำเตือน и มีวิจารณญาณ.

คุณสามารถลองใช้ Kube-score ออนไลน์หรือติดตั้งในเครื่องได้

ในขณะที่เขียนบทความต้นฉบับ kube-score เวอร์ชันล่าสุดคือ 1.7.0

มาลองใช้ในรายการของเรากันดีกว่า base-valid.yaml:

$ kube-score score base-valid.yaml

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

YAML ผ่านการทดสอบ kubeval ในขณะที่คะแนน kube ชี้ไปที่ข้อบกพร่องต่อไปนี้:

ไม่ได้กำหนดค่าการตรวจสอบความพร้อม
ไม่มีการร้องขอหรือข้อจำกัดสำหรับทรัพยากร CPU และหน่วยความจำ
ไม่ได้ระบุงบประมาณการหยุดชะงักของพ็อด
ไม่มีกฎเกณฑ์ในการแยกจากกัน (ต่อต้านความสัมพันธ์) เพื่อเพิ่มความพร้อมให้สูงสุด
คอนเทนเนอร์ทำงานเป็นรูท

สิ่งเหล่านี้ล้วนเป็นจุดที่ถูกต้องเกี่ยวกับข้อบกพร่องที่ต้องแก้ไขเพื่อทำให้การปรับใช้มีประสิทธิภาพและเชื่อถือได้มากขึ้น

ทีม kube-score แสดงข้อมูลในรูปแบบที่มนุษย์สามารถอ่านได้ รวมถึงการละเมิดทุกประเภท คำเตือน и มีวิจารณญาณซึ่งช่วยได้มากในระหว่างการพัฒนา

ผู้ที่ต้องการใช้เครื่องมือนี้ภายในไปป์ไลน์ CI สามารถเปิดใช้งานเอาต์พุตที่ถูกบีบอัดได้มากขึ้นโดยใช้แฟล็ก --output-format ci (ในกรณีนี้ การทดสอบพร้อมผลลัพธ์จะปรากฏขึ้นด้วย OK):

$ kube-score score base-valid.yaml --output-format ci

[OK] http-echo apps/v1/Deployment
[OK] http-echo apps/v1/Deployment
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) CPU limit is not set
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) Memory limit is not set
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) CPU request is not set
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) Memory request is not set
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) Image with latest tag
[OK] http-echo apps/v1/Deployment
[CRITICAL] http-echo apps/v1/Deployment: The pod does not have a matching network policy
[CRITICAL] http-echo apps/v1/Deployment: Container is missing a readinessProbe
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) Container has no configured security context
[CRITICAL] http-echo apps/v1/Deployment: No matching PodDisruptionBudget was found
[WARNING] http-echo apps/v1/Deployment: Deployment does not have a host podAntiAffinity set
[OK] http-echo v1/Service
[OK] http-echo v1/Service
[OK] http-echo v1/Service
[OK] http-echo v1/Service

เช่นเดียวกับ kubeval kube-score จะส่งคืนโค้ดทางออกที่ไม่เป็นศูนย์เมื่อมีการทดสอบที่ล้มเหลว มีวิจารณญาณ. คุณยังสามารถเปิดใช้งานการประมวลผลที่คล้ายกันได้ คำเตือน.

นอกจากนี้ยังสามารถตรวจสอบทรัพยากรว่าสอดคล้องกับเวอร์ชัน API ต่างๆ ได้หรือไม่ (เช่นใน kubeval) อย่างไรก็ตาม ข้อมูลนี้ได้รับการฮาร์ดโค้ดไว้ในคะแนน kube เอง: คุณไม่สามารถเลือก Kubernetes เวอร์ชันอื่นได้ ข้อจำกัดนี้อาจเป็นปัญหาใหญ่ได้หากคุณต้องการอัปเกรดคลัสเตอร์ของคุณ หรือหากคุณมีหลายคลัสเตอร์ที่มี K8 เวอร์ชันต่างกัน

โปรดทราบว่า มีปัญหาอยู่แล้ว โดยมีข้อเสนอให้ตระหนักถึงโอกาสนี้

ข้อมูลเพิ่มเติมเกี่ยวกับ kube-score สามารถดูได้ที่ เว็บไซต์อย่างเป็นทางการ.

การทดสอบคะแนน Kube เป็นเครื่องมือที่ยอดเยี่ยมสำหรับการนำแนวทางปฏิบัติที่ดีที่สุดไปใช้ แต่ถ้าคุณจำเป็นต้องเปลี่ยนแปลงการทดสอบหรือเพิ่มกฎของคุณเองล่ะ อนิจจาสิ่งนี้ไม่สามารถทำได้

คะแนน Kube ไม่สามารถขยายได้: คุณไม่สามารถเพิ่มนโยบายหรือปรับเปลี่ยนนโยบายได้

หากคุณต้องการเขียนการทดสอบแบบกำหนดเองเพื่อตรวจสอบการปฏิบัติตามนโยบายของบริษัท คุณสามารถใช้หนึ่งในสี่เครื่องมือต่อไปนี้: config-lint, copper, conftest หรือ polaris

3.กำหนดค่า-ผ้าสำลี

Config-lint เป็นเครื่องมือสำหรับตรวจสอบความถูกต้องของไฟล์การกำหนดค่า YAML, JSON, Terraform, CSV และไฟล์ Manifest ของ Kubernetes

คุณสามารถติดตั้งโดยใช้ คำแนะนำ บนเว็บไซต์โครงการ

รุ่นปัจจุบัน ณ เวลาที่เขียนบทความต้นฉบับคือ 1.5.0

Config-lint ไม่มีการทดสอบในตัวสำหรับการตรวจสอบความถูกต้องของไฟล์ Manifest ของ Kubernetes

หากต้องการดำเนินการทดสอบ คุณต้องสร้างกฎที่เหมาะสม เขียนเป็นไฟล์ YAML ที่เรียกว่า "ชุดกฎ" (กฎ)และมีโครงสร้างดังนี้

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

(rule.yaml)

มาศึกษาให้ละเอียดยิ่งขึ้น:

สนาม type ระบุประเภทของการกำหนดค่า config-lint ที่จะใช้ สำหรับรายการ K8s นี่คือ เสมอ Kubernetes.
ใน files นอกจากตัวไฟล์แล้ว คุณยังสามารถระบุไดเร็กทอรีได้ด้วย
สนาม rules มีไว้สำหรับการตั้งค่าการทดสอบผู้ใช้

สมมติว่าคุณต้องการให้แน่ใจว่าอิมเมจในการปรับใช้จะถูกดาวน์โหลดจากพื้นที่เก็บข้อมูลที่เชื่อถือได้เช่นเสมอ my-company.com/myapp:1.0. กฎ config-lint ที่ดำเนินการตรวจสอบดังกล่าวจะมีลักษณะดังนี้:

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

(rule-trusted-repo.yaml)

แต่ละกฎจะต้องมีคุณลักษณะดังต่อไปนี้:

id — ตัวระบุเฉพาะของกฎ
severity - อาจจะ ความล้มเหลว, คำเตือน и ไม่เป็นไปตามข้อกำหนด;
message — หากมีการละเมิดกฎ เนื้อหาของบรรทัดนี้จะปรากฏขึ้น
resource — ประเภทของทรัพยากรที่กฎนี้ใช้
assertions — รายการเงื่อนไขที่จะได้รับการประเมินที่เกี่ยวข้องกับทรัพยากรนี้

ในกฎเกณฑ์ข้างต้น assertion ที่เรียกว่า every ตรวจสอบว่าคอนเทนเนอร์ทั้งหมดอยู่ใน Deployment (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 เป็นเฟรมเวิร์กที่น่าหวังที่ช่วยให้คุณสร้างการทดสอบของคุณเองเพื่อตรวจสอบความถูกต้องของรายการ Kubernetes YAML โดยใช้ YAML DSL

แต่ถ้าคุณต้องการตรรกะและการทดสอบที่ซับซ้อนกว่านี้ล่ะ? YAML ไม่ได้จำกัดเกินไปสำหรับเรื่องนี้ใช่ไหม จะเป็นอย่างไรหากคุณสามารถสร้างการทดสอบในภาษาโปรแกรมเต็มรูปแบบได้

4. ทองแดง

ทองแดง V2 เป็นเฟรมเวิร์กสำหรับการตรวจสอบความถูกต้องของรายการโดยใช้การทดสอบแบบกำหนดเอง (คล้ายกับ config-lint)

อย่างไรก็ตาม มันแตกต่างจากอย่างหลังตรงที่ไม่ใช้ YAML เพื่ออธิบายการทดสอบ การทดสอบสามารถเขียนเป็น JavaScript แทนได้ Copper มีไลบรารีพร้อมเครื่องมือพื้นฐานหลายอย่างซึ่งช่วยให้คุณอ่านข้อมูลเกี่ยวกับออบเจ็กต์ Kubernetes และรายงานข้อผิดพลาด

ขั้นตอนการติดตั้ง Copper สามารถดูได้ที่ เอกสารราชการ.

2.0.1 เป็นยูทิลิตี้รุ่นล่าสุด ณ เวลาที่เขียนบทความต้นฉบับ

เช่นเดียวกับ config-lint Copper ไม่มีการทดสอบในตัว มาเขียนกัน ปล่อยให้ตรวจสอบว่าการปรับใช้ใช้คอนเทนเนอร์อิมเมจจากแหล่งเก็บข้อมูลที่เชื่อถือได้เช่น my-company.com.

สร้างไฟล์ check_image_repo.js โดยมีเนื้อหาดังนี้

$$.forEach(function($){
    if ($.kind === 'Deployment') {
        $.spec.template.spec.containers.forEach(function(container) {
            var image = new DockerImage(container.image);
            if (image.registry.lastIndexOf('my-company.com/') != 0) {
                errors.add_error('no_company_repo',"Image " + $.metadata.name + " is not from my-company.com repo", 1)
            }
        });
    }
});

ตอนนี้เพื่อทดสอบรายการของเรา base-valid.yamlให้ใช้คำสั่ง copper validate:

$ copper validate --in=base-valid.yaml --validator=check_image_tag.js

Check no_company_repo failed with severity 1 due to Image http-echo is not from my-company.com repo
Validation failed

เป็นที่ชัดเจนว่าด้วยความช่วยเหลือของ Copper คุณสามารถทำการทดสอบที่ซับซ้อนมากขึ้นได้ ตัวอย่างเช่น การตรวจสอบชื่อโดเมนในรายการ Ingress หรือการปฏิเสธพ็อดที่ทำงานในโหมดสิทธิพิเศษ

Copper มีฟังก์ชั่นอรรถประโยชน์มากมายในตัว:

DockerImage อ่านไฟล์อินพุตที่ระบุและสร้างวัตถุที่มีคุณสมบัติดังต่อไปนี้:
- name - ชื่อของภาพ
- tag - แท็กรูปภาพ
- registry - รีจิสทรีรูปภาพ
- registry_url - มาตรการ (https://) และรีจิสตรีรูปภาพ
- fqin - ตำแหน่งเต็มของภาพ
ฟังก์ชัน findByName ช่วยในการค้นหาทรัพยากรตามประเภทที่กำหนด (kind) และชื่อ (name) จากไฟล์อินพุต
ฟังก์ชัน findByLabels ช่วยในการค้นหาทรัพยากรตามประเภทที่ระบุ (kind) และป้ายกำกับ (labels).

คุณสามารถดูฟังก์ชันบริการที่มีอยู่ทั้งหมดได้ ที่นี่.

ตามค่าเริ่มต้น มันจะโหลดไฟล์ YAML อินพุตทั้งหมดลงในตัวแปร $$ และทำให้มันพร้อมใช้งานสำหรับการเขียนสคริปต์ (เทคนิคที่คุ้นเคยสำหรับผู้ที่มีประสบการณ์ jQuery)

ข้อได้เปรียบหลักของ Copper นั้นชัดเจน: คุณไม่จำเป็นต้องเชี่ยวชาญภาษาพิเศษ และคุณสามารถใช้ฟีเจอร์ JavaScript ต่างๆ เพื่อสร้างการทดสอบของคุณเองได้ เช่น การแก้ไขสตริง ฟังก์ชัน ฯลฯ

ควรสังเกตว่า Copper เวอร์ชันปัจจุบันใช้งานได้กับเอ็นจิ้น JavaScript เวอร์ชัน ES5 ไม่ใช่ ES6

รายละเอียดดูได้ที่ เว็บไซต์โครงการอย่างเป็นทางการ.

อย่างไรก็ตาม หากคุณไม่ชอบ JavaScript มากนัก และชอบภาษาที่ออกแบบมาเพื่อการสร้างข้อความค้นหาและอธิบายนโยบายโดยเฉพาะ คุณควรให้ความสนใจกับ Conftest

5.งานประกวด

Conftest เป็นเฟรมเวิร์กสำหรับทดสอบข้อมูลการกำหนดค่า ยังเหมาะสำหรับการทดสอบ/ตรวจสอบไฟล์ Manifest ของ Kubernetes ด้วย การทดสอบอธิบายโดยใช้ภาษาคิวรีเฉพาะ เรโก.

คุณสามารถติดตั้ง conftest โดยใช้ คำแนะนำระบุไว้ในเว็บไซต์โครงการ

ในขณะที่เขียนบทความต้นฉบับ เวอร์ชันล่าสุดคือ 0.18.2

เช่นเดียวกับ config-lint และ copper conftest มาโดยไม่มีการทดสอบในตัว มาลองใช้และเขียนนโยบายของเราเองกัน เช่นเดียวกับในตัวอย่างก่อนหน้านี้ เราจะตรวจสอบว่าอิมเมจคอนเทนเนอร์ถูกนำมาจากแหล่งที่เชื่อถือได้หรือไม่

สร้างไดเร็กทอรี conftest-checksและในนั้นมีไฟล์ชื่อ check_image_registry.rego โดยมีเนื้อหาดังนี้

package main

deny[msg] {

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

ตอนนี้เรามาทดสอบกัน base-valid.yaml ตลอด conftest:

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

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

การทดสอบล้มเหลวอย่างคาดการณ์ได้เนื่องจากรูปภาพมาจากแหล่งที่ไม่น่าเชื่อถือ

ในไฟล์ Rego เรากำหนดบล็อก deny. ความจริงถือเป็นการละเมิด ถ้าบล็อก deny หลายครั้ง ตรวจสอบโดย conftest โดยแยกจากกัน และความจริงของการบล็อกใด ๆ ถือเป็นการละเมิด

นอกเหนือจากเอาต์พุตเริ่มต้นแล้ว Conftest ยังรองรับรูปแบบ JSON, TAP และตาราง ซึ่งเป็นคุณสมบัติที่มีประโยชน์อย่างยิ่งหากคุณต้องการฝังรายงานลงในไปป์ไลน์ CI ที่มีอยู่ คุณสามารถกำหนดรูปแบบที่ต้องการได้โดยใช้แฟล็ก --output.

เพื่อให้ง่ายต่อการแก้ไขนโยบาย conftest มีการตั้งค่าสถานะ --trace. โดยจะแสดงผลการติดตามวิธีที่ conftest แยกวิเคราะห์ไฟล์นโยบายที่ระบุ

นโยบายการแข่งขันสามารถเผยแพร่และแชร์ในการลงทะเบียน OCI (Open Container Initiative) ในรูปแบบอาร์ติแฟกต์ได้

Команды push и pull อนุญาตให้คุณเผยแพร่สิ่งประดิษฐ์หรือเรียกค้นสิ่งประดิษฐ์ที่มีอยู่จากรีจิสตรีระยะไกล มาลองเผยแพร่นโยบายที่เราสร้างไปยังรีจิสทรี Docker ในเครื่องโดยใช้ conftest push.

เริ่มรีจิสทรี Docker ในพื้นที่ของคุณ:

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

ในเทอร์มินัลอื่น ให้ไปที่ไดเร็กทอรีที่คุณสร้างไว้ก่อนหน้านี้ conftest-checks และรันคำสั่งต่อไปนี้:

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

หากคำสั่งสำเร็จ คุณจะเห็นข้อความดังนี้:

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

ตอนนี้สร้างไดเร็กทอรีชั่วคราวและรันคำสั่งในนั้น conftest pull. มันจะดาวน์โหลดแพ็คเกจที่สร้างโดยคำสั่งก่อนหน้า:

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

ไดเร็กทอรีย่อยจะปรากฏในไดเร็กทอรีชั่วคราว policyที่มีไฟล์นโยบายของเรา:

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

การทดสอบสามารถดำเนินการได้โดยตรงจากพื้นที่เก็บข้อมูล:

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

ขออภัย DockerHub ยังไม่รองรับ ดังนั้นถือว่าตัวเองโชคดีถ้าคุณใช้ การลงทะเบียนคอนเทนเนอร์ Azure (ACR) หรือทะเบียนของคุณเอง

รูปแบบสิ่งประดิษฐ์จะเหมือนกับ เปิดแพ็คเกจตัวแทนนโยบาย (OPA) ซึ่งช่วยให้คุณใช้ conftest เพื่อรันการทดสอบจากแพ็คเกจ OPA ที่มีอยู่ได้

คุณสามารถเรียนรู้เพิ่มเติมเกี่ยวกับการแชร์นโยบายและคุณสมบัติอื่น ๆ ของ Conftest ได้ที่ เว็บไซต์โครงการอย่างเป็นทางการ.

6 นักษัตรเนมี

เครื่องมือสุดท้ายที่จะกล่าวถึงในบทความนี้คือ นักษัตรเนมี. (ประกาศปีที่แล้วของเขาเรา แปลแล้ว - ประมาณ การแปล)

Polaris สามารถติดตั้งในคลัสเตอร์หรือใช้ในโหมดบรรทัดคำสั่ง ตามที่คุณอาจเดาได้ ช่วยให้คุณสามารถวิเคราะห์รายการ Kubernetes แบบคงที่ได้

เมื่อทำงานในโหมดบรรทัดคำสั่ง การทดสอบในตัวจะพร้อมใช้งานครอบคลุมด้านต่างๆ เช่น ความปลอดภัยและแนวทางปฏิบัติที่ดีที่สุด (คล้ายกับคะแนน kube) นอกจากนี้ คุณสามารถสร้างการทดสอบของคุณเองได้ (เช่นใน config-lint, copper และ conftest)

กล่าวอีกนัยหนึ่ง Polaris ผสมผสานประโยชน์ของเครื่องมือทั้งสองประเภทเข้าด้วยกัน: ด้วยการทดสอบในตัวและการทดสอบแบบกำหนดเอง

หากต้องการติดตั้ง Polaris ในโหมดบรรทัดคำสั่งให้ใช้ คำแนะนำบนเว็บไซต์โครงการ.

ในขณะที่เขียนบทความต้นฉบับ เวอร์ชัน 1.0.3 จะพร้อมใช้งาน

เมื่อการติดตั้งเสร็จสมบูรณ์ คุณสามารถเรียกใช้ Polaris บนไฟล์ 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": [
    /* длинный список */
  ]
}

มีเอาต์พุตเต็มรูปแบบ ที่นี่.

เช่นเดียวกับ kube-score Polaris ระบุปัญหาในพื้นที่ที่รายการไม่เป็นไปตามแนวทางปฏิบัติที่ดีที่สุด:

ไม่มีการตรวจสุขภาพสำหรับพ็อด
ไม่ได้ระบุแท็กสำหรับอิมเมจคอนเทนเนอร์
คอนเทนเนอร์ทำงานเป็นรูท
ไม่ได้ระบุคำขอและขีดจำกัดสำหรับหน่วยความจำและ CPU

การทดสอบแต่ละครั้งได้รับการกำหนดระดับวิกฤต ขึ้นอยู่กับผลลัพธ์: คำเตือน หรือ อันตราย. หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการทดสอบในตัวที่มีอยู่ โปรดดูที่ เอกสาร.

หากไม่ต้องการรายละเอียด คุณสามารถระบุแฟล็กได้ --format score. ในกรณีนี้ Polaris จะส่งออกตัวเลขตั้งแต่ 1 ถึง 100 − คะแนน (เช่น การประเมิน):

$ polaris audit --audit-path test-data/base-valid.yaml --format score
68

ยิ่งคะแนนใกล้ 100 มากเท่าใด ระดับของข้อตกลงก็จะยิ่งสูงขึ้นเท่านั้น หากคุณตรวจสอบรหัสทางออกของคำสั่ง polaris auditปรากฎว่ามันเท่ากับ 0

บังคับ polaris audit คุณสามารถยุติการทำงานด้วยโค้ดที่ไม่ใช่ศูนย์ได้โดยใช้สองแฟล็ก:

ธง --set-exit-code-below-score ใช้เป็นอาร์กิวเมนต์ค่าเกณฑ์ในช่วง 1-100 ในกรณีนี้ คำสั่งจะออกด้วยรหัสทางออก 4 หากคะแนนต่ำกว่าเกณฑ์ สิ่งนี้มีประโยชน์มากเมื่อคุณมีค่าเกณฑ์ที่แน่นอน (เช่น 75) และคุณต้องได้รับการแจ้งเตือนหากคะแนนต่ำกว่า
ธง --set-exit-code-on-danger จะทำให้คำสั่งล้มเหลวด้วยรหัส 3 หากการทดสอบอันตรายอย่างใดอย่างหนึ่งล้มเหลว

ตอนนี้เรามาลองสร้างการทดสอบแบบกำหนดเองเพื่อตรวจสอบว่ารูปภาพนั้นนำมาจากพื้นที่เก็บข้อมูลที่เชื่อถือได้หรือไม่ การทดสอบแบบกำหนดเองได้รับการระบุในรูปแบบ YAML และการทดสอบนั้นอธิบายไว้โดยใช้ JSON Schema

ข้อมูลโค้ด YAML ต่อไปนี้อธิบายการทดสอบใหม่ที่เรียกว่า checkImageRepo:

checkImageRepo:
  successMessage: Image registry is valid
  failureMessage: Image registry is not valid
  category: Images
  target: Container
  schema:
    '$schema': http://json-schema.org/draft-07/schema
    type: object
    properties:
      image:
        type: string
        pattern: ^my-company.com/.+$

มาดูกันดีกว่า:

successMessage — บรรทัดนี้จะถูกพิมพ์หากการทดสอบเสร็จสมบูรณ์
failureMessage — ข้อความนี้จะแสดงในกรณีที่เกิดความล้มเหลว
category — ระบุหนึ่งในหมวดหมู่: Images, Health Checks, Security, Networking и Resources;
target--- กำหนดประเภทของวัตถุ (spec) ทดสอบแล้ว ค่าที่เป็นไปได้: Container, Pod หรือ Controller;
การทดสอบนั้นระบุไว้ในออบเจ็กต์ schema ใช้สคีมา JSON คำสำคัญในการทดสอบนี้คือ pattern ใช้เพื่อเปรียบเทียบแหล่งที่มาของภาพกับแหล่งที่ต้องการ

หากต้องการรันการทดสอบข้างต้น คุณต้องสร้างการกำหนดค่า Polaris ต่อไปนี้:

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

(polaris-conf.yaml)

มาแยกวิเคราะห์ไฟล์กัน:

ใน checks มีการกำหนดการทดสอบและระดับวิกฤต เนื่องจากเป็นการดีที่จะได้รับคำเตือนเมื่อรูปภาพถูกนำมาจากแหล่งที่ไม่น่าเชื่อถือ เราจึงกำหนดระดับไว้ที่นี่ danger.
การทดสอบนั้นเอง checkImageRepo แล้วลงทะเบียนในวัตถุ customChecks.

บันทึกไฟล์เป็น custom_check.yaml. ตอนนี้คุณสามารถวิ่งได้แล้ว polaris audit ด้วยไฟล์ Manifest 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

Polaris เสริมการทดสอบในตัวด้วยการทดสอบแบบกำหนดเอง จึงเป็นการผสมผสานสิ่งที่ดีที่สุดของทั้งสองโลกเข้าด้วยกัน

ในทางกลับกัน การไม่สามารถใช้ภาษาที่มีประสิทธิภาพมากขึ้น เช่น Rego หรือ JavaScript อาจเป็นปัจจัยจำกัดที่ทำให้ไม่สามารถสร้างการทดสอบที่ซับซ้อนมากขึ้นได้

ข้อมูลเพิ่มเติมเกี่ยวกับโพลาริสสามารถดูได้ที่ เว็บไซต์โครงการ.

สรุป

แม้ว่าจะมีเครื่องมือมากมายสำหรับตรวจสอบและประเมินไฟล์ Kubernetes YAML สิ่งสำคัญคือต้องมีความเข้าใจที่ชัดเจนว่าการทดสอบจะได้รับการออกแบบและดำเนินการอย่างไร.

ตัวอย่างเช่น หากคุณใช้รายการ Kubernetes ผ่านไปป์ไลน์ kubeval อาจเป็นขั้นตอนแรกในไปป์ไลน์ดังกล่าว. มันจะตรวจสอบว่าคำจำกัดความของวัตถุสอดคล้องกับสคีมา Kubernetes API หรือไม่

เมื่อการตรวจสอบดังกล่าวเสร็จสิ้น ก็สามารถดำเนินการทดสอบที่ซับซ้อนมากขึ้นได้ เช่น การปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดมาตรฐานและนโยบายเฉพาะ นี่คือจุดที่ kube-score และ Polaris จะมีประโยชน์

สำหรับผู้ที่มีข้อกำหนดที่ซับซ้อนและจำเป็นต้องปรับแต่งการทดสอบโดยละเอียด Copper, config-lint และ conftest น่าจะเหมาะสม.

Conftest และ config-lint ใช้ YAML เพื่อกำหนดการทดสอบแบบกำหนดเอง และ copper ช่วยให้คุณเข้าถึงภาษาการเขียนโปรแกรมเต็มรูปแบบ ทำให้เป็นตัวเลือกที่น่าสนใจทีเดียว

ในทางกลับกัน มันคุ้มค่าที่จะใช้หนึ่งในเครื่องมือเหล่านี้หรือไม่ ดังนั้น ควรสร้างการทดสอบทั้งหมดด้วยตนเอง หรือชอบ Polaris และเพิ่มเฉพาะสิ่งที่จำเป็นเท่านั้น ไม่มีคำตอบที่ชัดเจนสำหรับคำถามนี้.

ตารางด้านล่างแสดงคำอธิบายโดยย่อของแต่ละเครื่องมือ:

เครื่องมือ
โชคชะตา
ข้อ จำกัด
การทดสอบผู้ใช้

คูเบวาล
ตรวจสอบความถูกต้องของ YAML กับเวอร์ชันเฉพาะของสคีมา API
ไม่สามารถทำงานร่วมกับ CRD
ไม่

คะแนน kube
วิเคราะห์รายการ YAML เทียบกับแนวทางปฏิบัติที่ดีที่สุด
เลือกเวอร์ชัน Kubernetes API เพื่อตรวจสอบทรัพยากรไม่ได้
ไม่

ทองแดง
เฟรมเวิร์กทั่วไปสำหรับการสร้างการทดสอบ JavaScript แบบกำหนดเองสำหรับรายการ YAML
ไม่มีการทดสอบในตัว เอกสารไม่ดี
มี

config-lint.php
เฟรมเวิร์กทั่วไปสำหรับการสร้างการทดสอบในภาษาเฉพาะโดเมนที่ฝังอยู่ใน YAML รองรับรูปแบบการกำหนดค่าที่หลากหลาย (เช่น Terraform)
ไม่มีการทดสอบสำเร็จรูป การยืนยันและฟังก์ชันในตัวอาจไม่เพียงพอ
มี

คอนเฟิร์มที่สุด
เฟรมเวิร์กสำหรับการสร้างการทดสอบของคุณเองโดยใช้ Rego (ภาษาคิวรีเฉพาะ) อนุญาตให้แชร์นโยบายผ่านชุด OCI
ไม่มีการทดสอบในตัว ฉันต้องเรียนเรโก้ ไม่รองรับ Docker Hub เมื่อเผยแพร่นโยบาย
มี

นักษัตรเนมี
บทวิจารณ์ YAML ขัดต่อแนวทางปฏิบัติที่ดีที่สุดมาตรฐาน ช่วยให้คุณสร้างการทดสอบของคุณเองโดยใช้ JSON Schema
ความสามารถในการทดสอบตาม JSON Schema อาจไม่เพียงพอ
มี

เนื่องจากเครื่องมือเหล่านี้ไม่ต้องอาศัยการเข้าถึงคลัสเตอร์ Kubernetes จึงติดตั้งง่าย ช่วยให้คุณสามารถกรองไฟล์ต้นฉบับและให้ข้อเสนอแนะอย่างรวดเร็วแก่ผู้เขียนคำขอดึงในโครงการ

ปล.จากผู้แปล

อ่านเพิ่มเติมในบล็อกของเรา:

ที่มา: will.com

ตรวจสอบ Kubernetes YAML กับแนวทางปฏิบัติและนโยบายที่ดีที่สุด