ከምርጥ ልምዶች እና ፖሊሲዎች አንጻር Kubernetes YAMLን ያረጋግጡ

ማስታወሻ. ትርጉምለK8s አከባቢዎች የYAML ውቅሮች ቁጥር እያደገ በመምጣቱ፣ በራስ ሰር የማረጋገጫቸው አስፈላጊነት ከጊዜ ወደ ጊዜ ይበልጥ አጣዳፊ ይሆናል። የዚህ ግምገማ ደራሲ ለዚህ ተግባር ነባር መፍትሄዎችን መምረጥ ብቻ ሳይሆን እንዴት እንደሚሠሩ ለማየት Deploymentን እንደ ምሳሌ ተጠቅሟል። በዚህ ርዕስ ላይ ፍላጎት ላላቸው ሰዎች በጣም መረጃ ሰጪ ሆኖ ተገኝቷል.

ከምርጥ ልምዶች እና ፖሊሲዎች አንጻር Kubernetes YAMLን ያረጋግጡ

TL; DRይህ መጣጥፍ የኩበርኔትስ YAML ፋይሎችን ከምርጥ ልምዶች እና መስፈርቶች አንጻር ለማረጋገጥ እና ለመገምገም ስድስት የማይንቀሳቀሱ መሳሪያዎችን ያወዳድራል።

የኩበርኔትስ የስራ ጫናዎች በተለምዶ በ YAML ሰነዶች መልክ ይገለፃሉ። በ YAML ላይ ካሉት ችግሮች አንዱ በማንፀባረቅ ፋይሎች መካከል ገደቦችን ወይም ግንኙነቶችን የመግለጽ ችግር ነው።

ወደ ክላስተር የተሰማሩ ምስሎች በሙሉ ከታመነ መዝገብ የመጡ መሆናቸውን ማረጋገጥ ብንፈልግስ?

የPodDisruptionBudgets የሌላቸውን ማሰማራቶች ወደ ክላስተር እንዳይላኩ እንዴት መከላከል እችላለሁ?

የስታቲክ ሙከራ ውህደት በእድገት ደረጃ ላይ ስህተቶችን እና የፖሊሲ ጥሰቶችን ለመለየት ያስችልዎታል. ይህ የመርጃ ፍቺዎች ትክክለኛ እና ደህንነታቸው የተጠበቀ የመሆኑን ዋስትና ይጨምራል፣ እና የምርት የስራ ጫናዎች ምርጥ ልምዶችን የመከተል እድላቸው ሰፊ ያደርገዋል።

የኩበርኔትስ የማይንቀሳቀስ YAML ፋይል ፍተሻ ሥነ ምህዳር በሚከተሉት ምድቦች ሊከፈል ይችላል።

  • ኤፒአይ አረጋጋጮች. በዚህ ምድብ ውስጥ ያሉ መሳሪያዎች የ YAML መግለጫውን ከKubernetes API አገልጋይ መስፈርቶች ጋር ያረጋግጣሉ።
  • ዝግጁ ሞካሪዎች. የዚህ ምድብ መሳሪያዎች ለደህንነት ሲባል ከተዘጋጁ ሙከራዎች፣ ምርጥ ተሞክሮዎችን ማክበር፣ ወዘተ.
  • ብጁ አረጋጋጮች. የዚህ ምድብ ተወካዮች በተለያዩ ቋንቋዎች ብጁ ሙከራዎችን እንዲፈጥሩ ይፈቅዱልዎታል, ለምሳሌ, ሬጎ እና ጃቫስክሪፕት.

በዚህ ጽሑፍ ውስጥ ስድስት የተለያዩ መሳሪያዎችን እንገልፃለን እና እናነፃፅራለን-

  1. ኩቤቫል;
  2. ኩቤ-ውጤት;
  3. ማዋቀር-ሊንት;
  4. ናስ;
  5. ውርደት;
  6. ፖላሪስ

ደህና, እንጀምር!

ማሰማራቶችን በመፈተሽ ላይ

መሳሪያዎችን ማወዳደር ከመጀመራችን በፊት እነሱን የምንፈትሽበት ዳራ እንፍጠር።

ከታች ያለው ማኒፌስቶ በርካታ ስህተቶችን እና ምርጥ ተሞክሮዎችን አለማክበር ይዟል፡ ምን ያህሉን ልታገኝ ትችላለህ?

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

(base-valid.yaml)

የተለያዩ መሳሪያዎችን ለማነፃፀር ይህንን YAML እንጠቀማለን።

ከላይ ያለው ማኒፌስቶ base-valid.yaml እና ሌሎች መግለጫዎች ከዚህ ጽሑፍ ውስጥ ይገኛሉ የጂት ማከማቻዎች.

አንጸባራቂው የዌብ አፕሊኬሽን ዋና ስራው በ"ሄሎ አለም" ወደፖርት 5678 ምላሽ መስጠት እንደሆነ ይገልጻል።

kubectl apply -f hello-world.yaml

እና ስለዚህ - ስራውን ያረጋግጡ:

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

አሁን ወደ ይሂዱ http://localhost:8080 እና ማመልከቻው እየሰራ መሆኑን ያረጋግጡ. ግን ምርጥ ልምዶችን ይከተላል? እንፈትሽ።

1. ኩቤቫል

በመሠረቱ ኩቤቫል ሀሳቡ ከ Kubernetes ጋር የሚደረግ ማንኛውም ግንኙነት በ REST 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

ሀብቱ እየተረጋገጠ አይደለም።

የኤፒአይ ሥሪትን በመጠቀም ማሰማራቶች apps/v1፣ ከፖድ መለያው ጋር የሚዛመድ መራጭ ማካተት አለበት። ከላይ ያለው አንጸባራቂ መራጩን አያካትትም፣ ስለዚህ 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 schema ጋር ይፈትሻል። ነገር ግን፣ በአብዛኛዎቹ ሁኔታዎች ከተወሰነ የኩበርኔትስ ልቀት ላይ ማረጋገጥ ሊኖርብዎ ይችላል። ይህ ባንዲራ በመጠቀም ሊከናወን ይችላል --kubernetes-version:

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

እባክዎን ስሪቱ በቅርጸቱ መገለጽ እንዳለበት ያስተውሉ Major.Minor.Patch.

ማረጋገጫው የሚደገፍባቸው ስሪቶች ዝርዝር፣ እባክዎን ይመልከቱ የ JSON እቅድ በ GitHub ላይ, የትኛው ኩቤቫል ለማረጋገጫ ይጠቀማል. ኩቤቫልን ከመስመር ውጭ ማሄድ ከፈለጉ ንድፎቹን ያውርዱ እና ባንዲራውን በመጠቀም አካባቢያቸውን ይጥቀሱ --schema-location.

ከተናጠል YAML ፋይሎች በተጨማሪ kubeval ከማውጫ እና stdin ጋር መስራት ይችላል።

በተጨማሪም ኩቤቫል በቀላሉ በ CI ቧንቧ መስመር ውስጥ ይዋሃዳል. መግለጫዎችን ወደ ክላስተር ከመላክዎ በፊት ሙከራዎችን ማካሄድ የሚፈልጉ ኩቤቫል ሶስት የውጤት ቅርጸቶችን እንደሚደግፍ በማወቁ ይደሰታሉ።

  1. በሚነበብ መልኩ;
  2. JSON;
  3. ማንኛውንም ነገር ፕሮቶኮል (TAP) ሞክር።

እና የትኛውም ቅርጸቶች የሚፈለገውን አይነት ውጤት ማጠቃለያ ለመፍጠር የውጤቱን ተጨማሪ ትንተና ሊያገለግሉ ይችላሉ።

የኩቤቫል አንዱ መሰናክሎች በአሁኑ ጊዜ ብጁ የመረጃ ፍቺዎች (ሲአርዲዎች) መከበራቸውን ማረጋገጥ አለመቻሉ ነው። ሆኖም ግን, kubeval ን ማዋቀር ይቻላል እነርሱን ችላ ይበሉ.

ኩቤቫል ሀብቶችን ለመፈተሽ እና ለመገምገም ጥሩ መሳሪያ ነው; ነገር ግን ፈተናውን ማለፍ ሀብቱ ምርጥ ተሞክሮዎችን ለማክበር ዋስትና እንደማይሰጥ ሊሰመርበት ይገባል።

ለምሳሌ, መለያውን በመጠቀም latest በመያዣው ውስጥ ምርጥ ልምዶችን አይከተልም. ሆኖም ኩቤቫል ይህንን ስህተት አይቆጥረውም እና ሪፖርት አያደርገውም። ያም ማለት የእንደዚህ አይነት YAML ማረጋገጫ ያለ ማስጠንቀቂያ ይጠናቀቃል።

ግን YAML ን ለመገምገም እና እንደ መለያው ያሉ ጥሰቶችን ለመለየት ከፈለጉ ምን ማድረግ አለብዎት latest? የ YAML ፋይልን ከምርጥ ልምዶች እንዴት ማረጋገጥ እችላለሁ?

2. ኩቤ-ውጤት

ኩቤ-ውጤት 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 የኩቤቫል ፈተናዎችን አልፏል፣ ኩቤ-ነጥብ ደግሞ የሚከተሉትን ጉድለቶች ያሳያል።

  • ዝግጁነት ፍተሻዎች አልተዋቀሩም።
  • ለሲፒዩ ሀብቶች እና ማህደረ ትውስታ ምንም ጥያቄዎች ወይም ገደቦች የሉም።
  • የፖድ መቋረጥ በጀቶች አልተገለጹም።
  • የመለያየት ደንቦች የሉም (ፀረ-ግንኙነት) ተገኝነትን ከፍ ለማድረግ.
  • መያዣው እንደ ሼር ይሠራል.

እነዚህ ሁሉ ድክመቶችን የሚመለከቱ ትክክለኛ ነጥቦች ናቸው ማሰማራትን የበለጠ ቀልጣፋ እና አስተማማኝ ለማድረግ።

ቡድን 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 ያልተሳካ ፈተና ሲኖር ዜሮ ያልሆነ የመውጫ ኮድ ይመልሳል አስፈሪ. እንዲሁም ለ ተመሳሳይ ሂደትን ማንቃት ይችላሉ። ማስጠንቀቂያ.

በተጨማሪም, ከተለያዩ የኤፒአይ ስሪቶች (እንደ ኩቤቫል) ጋር መጣጣምን ሃብቶችን ማረጋገጥ ይቻላል. ነገር ግን፣ ይህ መረጃ በ kube-score በራሱ ሃርድ ኮድ ነው፡ የተለየ የ Kubernetes ስሪት መምረጥ አይችሉም። ክላስተርዎን ለማሻሻል ካሰቡ ወይም የተለያዩ የK8s ስሪቶች ያሏቸው ብዙ ዘለላዎች ካሉዎት ይህ ገደብ ትልቅ ችግር ሊሆን ይችላል።

አስታውስ አትርሳ የሚለው ጉዳይ አስቀድሞ አለ። ይህንን እድል ለመገንዘብ በፕሮፖዛል.

ስለ kube-score ተጨማሪ መረጃ በ ላይ ይገኛል። ኦፊሴላዊ ድር ጣቢያ.

የኩቤ-ውጤት ሙከራዎች ምርጥ ልምዶችን ለመተግበር በጣም ጥሩ መሳሪያ ናቸው, ነገር ግን በፈተናው ላይ ለውጦችን ማድረግ ወይም የራስዎን ህጎች ማከል ከፈለጉስ? ወዮ, ይህ ማድረግ አይቻልም.

Kube-score extensible አይደለም፡ በእሱ ላይ ፖሊሲዎችን ማከል ወይም ማስተካከል አይችሉም።

ከኩባንያው ፖሊሲዎች ጋር መከበራቸውን ለማረጋገጥ ብጁ ሙከራዎችን መጻፍ ከፈለጉ ከሚከተሉት አራት መሳሪያዎች ውስጥ አንዱን መጠቀም ይችላሉ፡ config-lint፣ copper፣ conftest ወይም polaris።

3.Config-lint

Config-lint YAMLን፣ JSONን፣ Terraformን፣ CSV ውቅር ፋይሎችን እና የኩበርኔትስ መገለጫዎችን የሚያረጋግጥ መሳሪያ ነው።

በመጠቀም መጫን ይችላሉ። መመሪያዎች በፕሮጀክቱ ድህረ ገጽ ላይ.

ዋናውን መጣጥፍ እስከተፃፈበት ጊዜ ድረስ ያለው የአሁኑ ልቀት 1.5.0 ነው።

Config-lint የ Kubernetes መገለጫዎችን ለማረጋገጥ አብሮ የተሰሩ ሙከራዎች የሉትም።

ማንኛውንም ፈተና ለማካሄድ, ተስማሚ ደንቦችን መፍጠር አስፈላጊ ነው. በ YAML ፋይሎች የተፃፉት "ሩልሴትስ" በሚባሉት ነው። (ደንቦች), እና የሚከተለው መዋቅር አላቸው:

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

(rule.yaml)

በጥልቀት እናጠናው፡-

  • መስክ type ምን አይነት ውቅር config-lint እንደሚጠቀም ይገልጻል። ለ K8s ይህ ይገለጻል። ሁልጊዜ Kubernetes.
  • በመስክ ውስጥ files ከፋይሎቹ እራሳቸው በተጨማሪ, ማውጫን መጥቀስ ይችላሉ.
  • መስክ rules የተጠቃሚ ሙከራዎችን ለማዘጋጀት የታሰበ።

በDeployment ውስጥ ያሉ ምስሎች ሁልጊዜ ከታመነ ማከማቻ መውረድን ማረጋገጥ ይፈልጋሉ እንበል my-company.com/myapp:1.0. እንዲህ ዓይነቱን ቼክ የሚያከናውን የማዋቀሪያ ደንብ ይህንን ይመስላል።

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

(rule-trusted-repo.yaml)

እያንዳንዱ ደንብ የሚከተሉትን ባህሪያት ሊኖረው ይገባል:

  • id - የደንቡ ልዩ መለያ;
  • severity - ምን አልባት አለመሳካት, ማስጠንቀቂያ и ያልተሟላ;
  • message - አንድ ደንብ ከተጣሰ, የዚህ መሾመር ይዘት ይታያል;
  • resource - ይህ ደንብ የሚተገበርበት የንብረት አይነት;
  • assertions - ከዚህ ሀብት ጋር በተያያዘ የሚገመገሙ ሁኔታዎች ዝርዝር።

ከላይ ባለው ደንብ assertion በዚህ ስም every ሁሉም ኮንቴይነሮች በማሰማራት ላይ መሆናቸውን ያረጋግጣል (key: spec.templates.spec.containers) የታመኑ ምስሎችን ይጠቀሙ (ማለትም በመጀመር my-company.com/).

የተሟላው ደንብ ይህንን ይመስላል

version: 1
description: Rules for Kubernetes spec files
type: Kubernetes
files:
  - "*.yaml"
rules:

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

(ruleset.yaml)

ፈተናውን ለመሞከር፣ እንደ ሆነ እናስቀምጠው check_image_repo.yaml. ፋይሉን እንፈትሽ base-valid.yaml:

$ config-lint -rules check_image_repo.yaml base-valid.yaml

[
  {
  "AssertionMessage": "Every expression fails: And expression fails: image does not start with my-company.com/",
  "Category": "",
  "CreatedAt": "2020-06-04T01:29:25Z",
  "Filename": "test-data/base-valid.yaml",
  "LineNumber": 0,
  "ResourceID": "http-echo",
  "ResourceType": "Deployment",
  "RuleID": "DEPLOYMENT_IMAGE_REPOSITORY",
  "RuleMessage": "Deployment must use a valid image repository",
  "Status": "FAILURE"
  }
]

ቼኩ አልተሳካም። አሁን የሚከተለውን አንጸባራቂ ከትክክለኛው የምስል ማከማቻ ጋር እንመልከተው፡

apiVersion: apps/v1
kind: Deployment
metadata:
  name: http-echo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: http-echo
  template:
    metadata:
      labels:
        app: http-echo
    spec:
      containers:
      - name: http-echo
         image: my-company.com/http-echo:1.0 # !!!
         args: ["-text", "hello-world"]
         ports:
         - containerPort: 5678

(image-valid-mycompany.yaml)

ከላይ ካለው አንጸባራቂ ጋር ተመሳሳይ ፈተና እንሰራለን. ምንም ችግሮች አልተገኙም:

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

Config-lint የ YAML DSL ን በመጠቀም የኩበርኔትስ YAML መግለጫዎችን ለማረጋገጥ የራስዎን ሙከራዎች እንዲፈጥሩ የሚያስችልዎ ተስፋ ሰጪ ማዕቀፍ ነው።

ግን የበለጠ ውስብስብ ሎጂክ እና ሙከራዎች ቢፈልጉስ? YAML ለዚህ በጣም የተገደበ አይደለም? ፈተናዎችን በሙሉ የፕሮግራም አወጣጥ ቋንቋ መፍጠር ከቻሉስ?

4. መዳብ

መዳብ V2 ብጁ ሙከራዎችን (ከ config-lint ጋር ተመሳሳይ) በመጠቀም አንጸባራቂዎችን ለማረጋገጥ የሚያስችል ማዕቀፍ ነው።

ነገር ግን፣ ፈተናዎችን ለመግለጽ YAML ባለመጠቀሙ ከሁለተኛው ይለያል። ፈተናዎች በምትኩ በጃቫስክሪፕት ሊጻፉ ይችላሉ። መዳብ በርካታ መሠረታዊ መሳሪያዎችን የያዘ ቤተ መጻሕፍት ያቀርባልስለ Kubernetes ነገሮች መረጃን ለማንበብ እና ስህተቶችን ሪፖርት ለማድረግ የሚረዳዎት.

መዳብን ለመጫን ደረጃዎች በ ውስጥ ይገኛሉ ኦፊሴላዊ ሰነዶች.

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 ፋይል ወደ ተለዋዋጭ ይጭናል። $$ እና ለስክሪፕት እንዲገኝ ያደርገዋል (የ jQuery ልምድ ላላቸው የታወቀ ዘዴ)።

የመዳብ ዋናው ጥቅም ግልፅ ነው፡ ልዩ ቋንቋን ማወቅ አያስፈልግዎትም እና የተለያዩ የጃቫ ስክሪፕት ባህሪያትን በመጠቀም የራስዎን ሙከራዎች ለምሳሌ እንደ string interpolation, ተግባራት, ወዘተ.

አሁን ያለው የመዳብ ስሪት ከ ES5 የጃቫ ስክሪፕት ሞተር ጋር እንደሚሰራ እንጂ ES6 እንዳልሆነ ልብ ሊባል ይገባል።

ዝርዝሮች በ ላይ ይገኛሉ ኦፊሴላዊ የፕሮጀክት ድር ጣቢያ.

ነገር ግን፣ ጃቫ ስክሪፕትን በትክክል የማትወድ ከሆነ እና መጠይቆችን ለመፍጠር እና ፖሊሲዎችን ለመግለፅ የተነደፈ ቋንቋን ከመረጥክ፣ ለ conftest ትኩረት መስጠት አለብህ።

5.ኮንፍስት

Conftest የውቅር ውሂብን ለመፈተሽ ማዕቀፍ ነው። እንዲሁም የ Kubernetes መገለጫዎችን ለመፈተሽ / ለማረጋገጥ ተስማሚ። ፈተናዎች የሚገለጹት በልዩ የጥያቄ ቋንቋ ነው። ክልል.

ኮንፍስትን በመጠቀም መጫን ይችላሉ። መመሪያዎችበፕሮጀክቱ ድህረ ገጽ ላይ ተዘርዝሯል.

ዋናውን ጽሑፍ በሚጽፉበት ጊዜ የቅርብ ጊዜው ስሪት 0.18.2 ነበር.

ልክ እንደ config-lint እና መዳብ፣ ኮንፍስት ያለ ምንም አብሮ የተሰሩ ሙከራዎች ይመጣል። እስቲ ሞክረን የራሳችንን ፖሊሲ እንፃፍ። እንደ ቀደሙት ምሳሌዎች, የመያዣው ምስሎች ከታማኝ ምንጭ የተወሰዱ መሆናቸውን እናረጋግጣለን.

ማውጫ ፍጠር 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. የተገለጹትን የመመሪያ ፋይሎች እንዴት እንደሚተነተን የሚያሳይ ዱካ ያወጣል።

የውድድር ፖሊሲዎች በ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) ወይም የራስዎ መዝገብ ቤት።

የአርቲፊክ ቅርፀት ተመሳሳይ ነው የፖሊሲ ወኪል ጥቅሎችን ክፈት (OPA)፣ ይህም አሁን ካሉ የኦፒኤ ፓኬጆች ፈተናዎችን ለማካሄድ conftest እንድትጠቀም ይፈቅድልሃል።

ስለ ፖሊሲ ማጋራት እና ሌሎች የኮንፌት ባህሪያት በ ላይ የበለጠ ማወቅ ይችላሉ። ኦፊሴላዊ የፕሮጀክት ድር ጣቢያ.

6. ፖላሪስ

በዚህ ጽሑፍ ውስጥ የሚብራራው የመጨረሻው መሣሪያ ነው ፖላሪስ. (የእሱ የመጨረሻ አመት ማስታወቂያ እኛ አስቀድሞ ተተርጉሟል - በግምት ትርጉም)

ፖላሪስ በክላስተር ውስጥ ሊጫን ወይም በትእዛዝ መስመር ሁነታ መጠቀም ይቻላል. እንደገመቱት የኩበርኔትስ አንጸባራቂዎችን በስታትስቲክስ እንዲተነትኑ ያስችልዎታል።

በትእዛዝ መስመር ሁነታ ላይ ሲሰሩ አብሮ የተሰሩ ሙከራዎች እንደ ደህንነት እና ምርጥ ልምዶች (ከኩቤ-ውጤት ጋር ተመሳሳይ) ያሉ ቦታዎችን የሚሸፍኑ አሉ። በተጨማሪም, የራስዎን ሙከራዎች (እንደ config-lint, copper እና conftest) መፍጠር ይችላሉ.

በሌላ አነጋገር, ፖላሪስ የሁለቱም የመሳሪያዎች ምድቦች ጥቅሞችን ያጣምራል: አብሮገነብ እና ብጁ ሙከራዎች.

በትእዛዝ መስመር ሁነታ ላይ ፖላሪስን ለመጫን ይጠቀሙ በፕሮጀክቱ ድህረ ገጽ ላይ መመሪያዎች.

ዋናውን ጽሑፍ በሚጽፉበት ጊዜ, ስሪት 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፣ ፖላሪስ አንጸባራቂው ምርጥ ተሞክሮዎችን ባላሟላባቸው አካባቢዎች ጉዳዮችን ይለያል፡-

  • ለፖዳዎች ምንም የጤና ምርመራዎች የሉም.
  • የመያዣ ምስሎች መለያዎች አልተገለጹም።
  • መያዣው እንደ ሼር ይሠራል.
  • የማህደረ ትውስታ እና ሲፒዩ ጥያቄዎች እና ገደቦች አልተገለጹም።

እያንዳንዱ ፈተና፣ በውጤቱ ላይ በመመስረት፣ ወሳኝነት ደረጃ ይመደባል፡- ማስጠንቀቂያ ወይም አደጋ. ስላሉት አብሮገነብ ሙከራዎች የበለጠ ለማወቅ እባክዎ ይመልከቱ ሰነድ.

ዝርዝሮች አስፈላጊ ካልሆኑ ባንዲራውን መጥቀስ ይችላሉ --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 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 schema በመጠቀም. በዚህ ፈተና ውስጥ ያለው ቁልፍ ቃል ነው 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 API ንድፍ ጋር መስማማታቸውን ይከታተላል።

እንደዚህ አይነት ግምገማ አንዴ ከተጠናቀቀ፣ አንድ ሰው ወደ ውስብስብ ፈተናዎች ሊሸጋገር ይችላል፣ ለምሳሌ መደበኛ ምርጥ ተሞክሮዎችን እና የተወሰኑ ፖሊሲዎችን ማክበር። ይህ ኩቤ-ውጤት እና ፖላሪስ ጠቃሚ ሆነው የሚመጡበት ነው።

ውስብስብ መስፈርቶች ላሏቸው እና ፈተናዎችን በዝርዝር ማበጀት ለሚያስፈልጋቸው መዳብ ፣ config-lint እና conftest ተስማሚ ይሆናሉ.

Conftest እና config-lint ብጁ ሙከራዎችን ለመግለጽ YAML ይጠቀማሉ፣ እና መዳብ ሙሉ የፕሮግራም አወጣጥ ቋንቋ መዳረሻ ይሰጥዎታል፣ ይህም ቆንጆ ምርጫ ያደርገዋል።

በሌላ በኩል ፣ ከእነዚህ መሳሪያዎች ውስጥ አንዱን መጠቀም እና ፣ ስለሆነም ሁሉንም ሙከራዎች በእጅ መፍጠር ፣ ወይም ፖላሪስን መምረጥ እና ለእሱ የሚያስፈልገውን ብቻ ማከል ጠቃሚ ነው? ለዚህ ጥያቄ ምንም ግልጽ መልስ የለም.

ከዚህ በታች ያለው ሰንጠረዥ የእያንዳንዱን መሳሪያ አጭር መግለጫ ይሰጣል-

መሣሪያ
ዓላማ
ችግሮች
የተጠቃሚ ሙከራዎች

ኩቤቫል
YAML ከተወሰነ የኤፒአይ ንድፍ ስሪት አንጻር ያረጋግጣል
ከሲአርዲ ጋር መስራት አልተቻለም
የለም

ኩቤ-ውጤት
YAML ከምርጥ ልምዶች አንጻር ይተነትናል።
መገልገያዎችን ለመፈተሽ የእርስዎን Kubernetes API ስሪት መምረጥ አይቻልም
የለም

መዳብ
ለ YAML መገለጫዎች ብጁ ጃቫስክሪፕት ሙከራዎችን ለመፍጠር አጠቃላይ ማዕቀፍ
ምንም አብሮ የተሰሩ ሙከራዎች የሉም። ደካማ ሰነዶች
ያ

ማዋቀር-lint
በYAML ውስጥ በተሰየመ ጎራ-ተኮር ቋንቋ ውስጥ ሙከራዎችን ለመፍጠር አጠቃላይ ማዕቀፍ። የተለያዩ የውቅር ቅርጸቶችን ይደግፋል (ለምሳሌ ቴራፎርም)
ምንም የተዘጋጁ ሙከራዎች የሉም. አብሮገነብ ማረጋገጫዎች እና ተግባራት በቂ ላይሆኑ ይችላሉ።
ያ

ንቀት
Rego (ልዩ የመጠይቅ ቋንቋ) በመጠቀም የራስዎን ሙከራዎች ለመፍጠር ማዕቀፍ። በOCI ቅርቅቦች በኩል ፖሊሲዎችን መጋራት ይፈቅዳል
ምንም አብሮ የተሰሩ ሙከራዎች የሉም። ሬጎን መማር አለብኝ። መመሪያዎችን ሲያትሙ Docker Hub አይደገፍም።
ያ

ፖላሪስ
ግምገማዎች YAML ከመደበኛ ምርጥ ተሞክሮዎች ጋር ይገለጻል። JSON Schema በመጠቀም የራስዎን ሙከራዎች እንዲፈጥሩ ይፈቅድልዎታል።
በJSON Schema ላይ የተመሠረቱ የሙከራ ችሎታዎች በቂ ላይሆኑ ይችላሉ።
ያ

እነዚህ መሳሪያዎች ወደ Kubernetes ክላስተር መድረስ ላይ ስለማይመሰረቱ, ለመጫን ቀላል ናቸው. የምንጭ ፋይሎችን እንዲያጣሩ እና በፕሮጀክቶች ውስጥ ለሚጎትቱ ጥያቄዎች ደራሲዎች ፈጣን ምላሽ እንዲሰጡ ያስችሉዎታል።

PS ከተርጓሚ

በብሎጋችን ላይ ያንብቡ፡-

ምንጭ: hab.com

አስተያየት ያክሉ