മികച്ച രീതികൾക്കും നയങ്ങൾക്കും എതിരായി Kubernetes YAML സാധൂകരിക്കുക

കുറിപ്പ്. വിവർത്തനം.: K8s പരിതസ്ഥിതികൾക്കായുള്ള YAML കോൺഫിഗറേഷനുകളുടെ എണ്ണം വർദ്ധിക്കുന്നതിനനുസരിച്ച്, അവയുടെ സ്വയമേവയുള്ള പരിശോധനയുടെ ആവശ്യകത കൂടുതൽ കൂടുതൽ അടിയന്തിരമായി മാറുന്നു. ഈ അവലോകനത്തിന്റെ രചയിതാവ് ഈ ടാസ്‌ക്കിനായി നിലവിലുള്ള പരിഹാരങ്ങൾ തിരഞ്ഞെടുക്കുക മാത്രമല്ല, അവ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് കാണുന്നതിന് വിന്യാസം ഒരു ഉദാഹരണമായി ഉപയോഗിക്കുകയും ചെയ്തു. ഈ വിഷയത്തിൽ താൽപ്പര്യമുള്ളവർക്ക് ഇത് വളരെ വിജ്ഞാനപ്രദമായി മാറി.

അച്ചു ഡി.ആർ.: ഈ ലേഖനം മികച്ച രീതികൾക്കും ആവശ്യകതകൾക്കും എതിരായി Kubernetes YAML ഫയലുകൾ സാധൂകരിക്കുന്നതിനും വിലയിരുത്തുന്നതിനുമായി ആറ് സ്റ്റാറ്റിക് ടൂളുകളെ താരതമ്യം ചെയ്യുന്നു.

കുബർനെറ്റസ് ജോലിഭാരങ്ങൾ സാധാരണയായി YAML ഡോക്യുമെന്റുകളുടെ രൂപത്തിലാണ് നിർവചിച്ചിരിക്കുന്നത്. മാനിഫെസ്റ്റ് ഫയലുകൾ തമ്മിലുള്ള നിയന്ത്രണങ്ങളോ ബന്ധങ്ങളോ വ്യക്തമാക്കുന്നതിനുള്ള ബുദ്ധിമുട്ടാണ് YAML-ലെ ഒരു പ്രശ്‌നം.

ക്ലസ്റ്ററിലേക്ക് വിന്യസിച്ചിരിക്കുന്ന എല്ലാ ചിത്രങ്ങളും വിശ്വസനീയമായ രജിസ്ട്രിയിൽ നിന്നാണ് വരുന്നതെന്ന് ഉറപ്പാക്കേണ്ടതുണ്ടെങ്കിൽ എന്തുചെയ്യും?

PodDisruptionBudgets ഇല്ലാത്ത ഡിപ്ലോയ്‌മെന്റുകൾ ക്ലസ്റ്ററിലേക്ക് അയയ്‌ക്കുന്നതിൽ നിന്ന് എനിക്ക് എങ്ങനെ തടയാനാകും?

വികസന ഘട്ടത്തിൽ പിശകുകളും നയ ലംഘനങ്ങളും തിരിച്ചറിയാൻ സ്റ്റാറ്റിക് ടെസ്റ്റിംഗിന്റെ സംയോജനം നിങ്ങളെ അനുവദിക്കുന്നു. ഇത് റിസോഴ്‌സ് നിർവചനങ്ങൾ കൃത്യവും സുരക്ഷിതവുമാണെന്നുള്ള ഗ്യാരന്റി വർദ്ധിപ്പിക്കുകയും ഉൽപ്പാദന ജോലിഭാരം മികച്ച രീതികൾ പിന്തുടരാനുള്ള സാധ്യത വർദ്ധിപ്പിക്കുകയും ചെയ്യുന്നു.

കുബർനെറ്റസ് സ്റ്റാറ്റിക് YAML ഫയൽ പരിശോധനാ ഇക്കോസിസ്റ്റത്തെ ഇനിപ്പറയുന്ന വിഭാഗങ്ങളായി തിരിക്കാം:

• API വാലിഡേറ്ററുകൾ. ഈ വിഭാഗത്തിലെ ടൂളുകൾ, Kubernetes API സെർവറിന്റെ ആവശ്യകതകൾക്കെതിരെ YAML മാനിഫെസ്റ്റ് പരിശോധിക്കുന്നു.
• റെഡി ടെസ്റ്റർമാർ. ഈ വിഭാഗത്തിൽ നിന്നുള്ള ടൂളുകൾ സുരക്ഷ, മികച്ച രീതികൾ പാലിക്കൽ തുടങ്ങിയവയ്‌ക്കായുള്ള റെഡിമെയ്ഡ് ടെസ്റ്റുകൾക്കൊപ്പം വരുന്നു.
• ഇഷ്‌ടാനുസൃത മൂല്യനിർണ്ണയക്കാർ. വിവിധ ഭാഷകളിൽ ഇഷ്‌ടാനുസൃത പരിശോധനകൾ സൃഷ്‌ടിക്കാൻ ഈ വിഭാഗത്തിന്റെ പ്രതിനിധികൾ നിങ്ങളെ അനുവദിക്കുന്നു, ഉദാഹരണത്തിന്, Rego, Javascript.

ഈ ലേഖനത്തിൽ ഞങ്ങൾ ആറ് വ്യത്യസ്ത ഉപകരണങ്ങൾ വിവരിക്കുകയും താരതമ്യം ചെയ്യുകയും ചെയ്യും:

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 ഈ ലേഖനത്തിൽ നിന്നുള്ള മറ്റ് മാനിഫെസ്റ്റോകളും ഇതിൽ കാണാം Git റിപ്പോസിറ്ററികൾ.

പോർട്ട് 5678-ലേക്ക് "ഹലോ വേൾഡ്" സന്ദേശത്തിലൂടെ പ്രതികരിക്കുക എന്നതാണ് പ്രധാന ചുമതലയുള്ള ഒരു വെബ് ആപ്ലിക്കേഷനെ മാനിഫെസ്റ്റ് വിവരിക്കുന്നു. ഇനിപ്പറയുന്ന കമാൻഡ് ഉപയോഗിച്ച് ഇത് വിന്യസിക്കാനാകും:

kubectl apply -f hello-world.yaml

അതിനാൽ - ജോലി പരിശോധിക്കുക:

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

ഇപ്പോൾ പോകുക http://localhost:8080 ആപ്ലിക്കേഷൻ പ്രവർത്തിക്കുന്നുണ്ടെന്ന് സ്ഥിരീകരിക്കുകയും ചെയ്യുക. എന്നാൽ ഇത് മികച്ച രീതികൾ പിന്തുടരുന്നുണ്ടോ? നമുക്ക് പരിശോധിക്കാം.

1. കുബേവൽ

അടിസ്ഥാനത്തിൽ കുബേവൽ കുബർനെറ്റസുമായുള്ള ഏതൊരു ഇടപെടലും അതിന്റെ REST API വഴിയാണ് സംഭവിക്കുന്നത് എന്നതാണ് ആശയം. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, നൽകിയിരിക്കുന്ന YAML അതിനോട് പൊരുത്തപ്പെടുന്നുണ്ടോയെന്ന് പരിശോധിക്കാൻ നിങ്ങൾക്ക് ഒരു API സ്കീമ ഉപയോഗിക്കാം. ഒരു ഉദാഹരണം നോക്കാം.

ഇന്സ്റ്റല്ലേഷന് നിര്ദ്ദേശങ്ങള് 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 ഉപയോഗിച്ച് kubeval പുറത്തുകടക്കും. നിങ്ങൾക്ക് ഇത് ഇനിപ്പറയുന്ന രീതിയിൽ പരിശോധിക്കാം:

$ echo $?
0

മറ്റൊരു മാനിഫെസ്റ്റ് ഉപയോഗിച്ച് നമുക്ക് ഇപ്പോൾ kubeval പരീക്ഷിക്കാം:

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, പോഡിന്റെ ലേബലുമായി പൊരുത്തപ്പെടുന്ന ഒരു സെലക്ടർ ഉൾപ്പെടുത്തണം. മുകളിലെ മാനിഫെസ്റ്റിൽ സെലക്ടർ ഉൾപ്പെടുന്നില്ല, അതിനാൽ 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)

കുബേവൽ പോലുള്ള ഉപകരണങ്ങളുടെ പ്രയോജനം, വിന്യാസ ചക്രത്തിൽ തന്നെ ഇത്തരം പിശകുകൾ കണ്ടെത്താനാകും എന്നതാണ്.

കൂടാതെ, ഈ പരിശോധനകൾക്ക് ക്ലസ്റ്ററിലേക്ക് ആക്‌സസ് ആവശ്യമില്ല; അവ ഓഫ്‌ലൈനായി നടത്താം.

ഡിഫോൾട്ടായി, ഏറ്റവും പുതിയ Kubernetes API സ്കീമയ്‌ക്കെതിരായ ഉറവിടങ്ങൾ kubeval പരിശോധിക്കുന്നു. എന്നിരുന്നാലും, മിക്ക കേസുകളിലും നിങ്ങൾ ഒരു നിർദ്ദിഷ്‌ട Kubernetes റിലീസിനെതിരെ പരിശോധിക്കേണ്ടതുണ്ട്. പതാക ഉപയോഗിച്ച് ഇത് ചെയ്യാം --kubernetes-version:

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

പതിപ്പ് ഫോർമാറ്റിൽ വ്യക്തമാക്കിയിരിക്കണം എന്നത് ശ്രദ്ധിക്കുക Major.Minor.Patch.

സ്ഥിരീകരണത്തെ പിന്തുണയ്ക്കുന്ന പതിപ്പുകളുടെ ഒരു ലിസ്‌റ്റിനായി, ദയവായി റഫർ ചെയ്യുക GitHub-ലെ JSON സ്കീമ, ഏത് കുബേവൽ സാധൂകരണത്തിന് ഉപയോഗിക്കുന്നു. നിങ്ങൾക്ക് kubeval ഓഫ്‌ലൈനിൽ പ്രവർത്തിപ്പിക്കണമെങ്കിൽ, സ്കീമകൾ ഡൗൺലോഡ് ചെയ്ത് ഫ്ലാഗ് ഉപയോഗിച്ച് അവയുടെ പ്രാദേശിക സ്ഥാനം വ്യക്തമാക്കുക --schema-location.

വ്യക്തിഗത YAML ഫയലുകൾക്ക് പുറമേ, kubeval-ന് ഡയറക്ടറികൾ, stdin എന്നിവയിലും പ്രവർത്തിക്കാനാകും.

കൂടാതെ, കുബേവൽ സിഐ പൈപ്പ്ലൈനിലേക്ക് എളുപ്പത്തിൽ സംയോജിപ്പിക്കുന്നു. ക്ലസ്റ്ററിലേക്ക് മാനിഫെസ്റ്റുകൾ അയയ്‌ക്കുന്നതിന് മുമ്പ് ടെസ്റ്റുകൾ നടത്താൻ ആഗ്രഹിക്കുന്നവർക്ക്, kubeval മൂന്ന് ഔട്ട്‌പുട്ട് ഫോർമാറ്റുകളെ പിന്തുണയ്‌ക്കുന്നു എന്നറിയുന്നതിൽ സന്തോഷമുണ്ട്:

1. പ്ലെയിൻ ടെക്സ്റ്റ്;
2. JSON;
3. ടെസ്റ്റ് എനിതിംഗ് പ്രോട്ടോക്കോൾ (TAP).

ആവശ്യമുള്ള തരത്തിലുള്ള ഫലങ്ങളുടെ ഒരു സംഗ്രഹം സൃഷ്ടിക്കുന്നതിന് ഔട്ട്പുട്ടിന്റെ കൂടുതൽ പാഴ്സിംഗിനായി ഏതെങ്കിലും ഫോർമാറ്റുകൾ ഉപയോഗിക്കാം.

കുബേവലിന്റെ ഒരു പോരായ്മ, കസ്റ്റം റിസോഴ്‌സ് ഡെഫനിഷനുകൾ (സിആർഡി) പാലിക്കുന്നുണ്ടോയെന്ന് പരിശോധിക്കാൻ നിലവിൽ അതിന് കഴിയില്ല എന്നതാണ്. എന്നിരുന്നാലും, kubeval കോൺഫിഗർ ചെയ്യാൻ സാധിക്കും അവരെ അവഗണിക്കുക.

വിഭവങ്ങൾ പരിശോധിക്കുന്നതിനും വിലയിരുത്തുന്നതിനുമുള്ള ഒരു മികച്ച ഉപകരണമാണ് കുബേവൽ; എന്നിരുന്നാലും, പരീക്ഷയിൽ വിജയിക്കുന്നത് റിസോഴ്‌സ് മികച്ച സമ്പ്രദായങ്ങളുമായി പൊരുത്തപ്പെടുന്നുവെന്ന് ഉറപ്പുനൽകുന്നില്ല എന്നത് ഊന്നിപ്പറയേണ്ടതാണ്.

ഉദാഹരണത്തിന്, ടാഗ് ഉപയോഗിക്കുന്നത് latest ഒരു കണ്ടെയ്നറിൽ മികച്ച രീതികൾ പാലിക്കുന്നില്ല. എന്നിരുന്നാലും, kubeval ഇത് ഒരു പിശകായി കണക്കാക്കുന്നില്ല, അത് റിപ്പോർട്ട് ചെയ്യുന്നില്ല. അതായത്, അത്തരം YAML-ന്റെ സ്ഥിരീകരണം മുന്നറിയിപ്പുകളില്ലാതെ പൂർത്തിയാകും.

നിങ്ങൾക്ക് YAML വിലയിരുത്താനും ടാഗ് പോലുള്ള ലംഘനങ്ങൾ തിരിച്ചറിയാനും താൽപ്പര്യമുണ്ടെങ്കിൽ എന്തുചെയ്യും latest? മികച്ച രീതികൾക്കെതിരെ ഒരു YAML ഫയൽ എങ്ങനെ പരിശോധിക്കാം?

2. കുബെ-സ്കോർ

കുബെ-സ്കോർ YAML മാനിഫെസ്റ്റുകൾ പാഴ്‌സ് ചെയ്യുകയും ബിൽറ്റ്-ഇൻ ടെസ്റ്റുകൾക്കെതിരെ അവയെ വിലയിരുത്തുകയും ചെയ്യുന്നു. സുരക്ഷാ മാർഗ്ഗനിർദ്ദേശങ്ങളും മികച്ച രീതികളും അടിസ്ഥാനമാക്കിയാണ് ഈ ടെസ്റ്റുകൾ തിരഞ്ഞെടുക്കുന്നത്, ഇനിപ്പറയുന്നവ:

• കണ്ടെയ്നർ പ്രവർത്തിപ്പിക്കുന്നത് റൂട്ട് ആയിട്ടല്ല.
• പോഡ് ആരോഗ്യ പരിശോധനകളുടെ ലഭ്യത.
• ഉറവിടങ്ങൾക്കായുള്ള അഭ്യർത്ഥനകളും പരിധികളും സജ്ജീകരിക്കുന്നു.

പരിശോധനാ ഫലങ്ങളെ അടിസ്ഥാനമാക്കി, മൂന്ന് ഫലങ്ങൾ നൽകിയിരിക്കുന്നു: OK, മുന്നറിയിപ്പ് и ക്രിട്ടിക്കൽ.

നിങ്ങൾക്ക് ഓൺലൈനിൽ Kube-സ്കോർ പരീക്ഷിക്കാവുന്നതാണ് അല്ലെങ്കിൽ പ്രാദേശികമായി ഇൻസ്റ്റാൾ ചെയ്യാം.

യഥാർത്ഥ ലേഖനം എഴുതുമ്പോൾ, ക്യൂബ്-സ്കോറിന്റെ ഏറ്റവും പുതിയ പതിപ്പ് 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 എല്ലാ തരത്തിലുള്ള ലംഘനങ്ങളും ഉൾപ്പെടെ മനുഷ്യർക്ക് വായിക്കാവുന്ന രൂപത്തിൽ വിവരങ്ങൾ പ്രദർശിപ്പിക്കുന്നു മുന്നറിയിപ്പ് и ക്രിട്ടിക്കൽ, ഇത് വികസന സമയത്ത് വളരെയധികം സഹായിക്കുന്നു.

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 പോലെ) പാലിക്കുന്നതിനുള്ള ഉറവിടങ്ങൾ പരിശോധിക്കാൻ സാധിക്കും. എന്നിരുന്നാലും, ഈ വിവരങ്ങൾ ക്യൂബ്-സ്‌കോറിൽ തന്നെ ഹാർഡ്‌കോഡ് ചെയ്‌തിരിക്കുന്നു: നിങ്ങൾക്ക് കുബർനെറ്റസിന്റെ മറ്റൊരു പതിപ്പ് തിരഞ്ഞെടുക്കാൻ കഴിയില്ല. നിങ്ങളുടെ ക്ലസ്റ്റർ അപ്‌ഗ്രേഡ് ചെയ്യാനാണ് നിങ്ങൾ ഉദ്ദേശിക്കുന്നെങ്കിലോ K8-ന്റെ വ്യത്യസ്ത പതിപ്പുകളുള്ള ഒന്നിലധികം ക്ലസ്റ്ററുകൾ നിങ്ങൾക്കുണ്ടെങ്കിൽ ഈ പരിമിതി ഒരു വലിയ പ്രശ്‌നമായിരിക്കും.

അതല്ല ഇതിനകം ഒരു പ്രശ്നമുണ്ട് ഈ അവസരം സാക്ഷാത്കരിക്കാനുള്ള നിർദ്ദേശത്തോടെ.

ക്യൂബ്-സ്കോറിനെക്കുറിച്ചുള്ള കൂടുതൽ വിവരങ്ങൾ ഇവിടെ കാണാം ഔദ്യോഗിക വെബ്സൈറ്റ്.

മികച്ച സമ്പ്രദായങ്ങൾ നടപ്പിലാക്കുന്നതിനുള്ള മികച്ച ഉപകരണമാണ് ക്യൂബ്-സ്കോർ ടെസ്റ്റുകൾ, എന്നാൽ നിങ്ങൾ ടെസ്റ്റിൽ മാറ്റങ്ങൾ വരുത്തുകയോ നിങ്ങളുടെ സ്വന്തം നിയമങ്ങൾ ചേർക്കുകയോ ചെയ്യണമെങ്കിൽ എന്തുചെയ്യും? അയ്യോ, ഇത് ചെയ്യാൻ കഴിയില്ല.

ക്യൂബ്-സ്കോർ വിപുലീകരിക്കാൻ കഴിയില്ല: നിങ്ങൾക്ക് അതിൽ നയങ്ങൾ ചേർക്കാനോ ക്രമീകരിക്കാനോ കഴിയില്ല.

കമ്പനി പോളിസികൾ പാലിക്കുന്നുണ്ടോയെന്ന് പരിശോധിക്കാൻ നിങ്ങൾക്ക് ഇഷ്‌ടാനുസൃത പരിശോധനകൾ എഴുതണമെങ്കിൽ, നിങ്ങൾക്ക് ഇനിപ്പറയുന്ന നാല് ടൂളുകളിൽ ഒന്ന് ഉപയോഗിക്കാം: കോൺഫിഗ്-ലിന്റ്, കോപ്പർ, കോൺഫെസ്റ്റ് അല്ലെങ്കിൽ പോളാരിസ്.

3.Config-lint

YAML, JSON, Terraform, CSV കോൺഫിഗറേഷൻ ഫയലുകൾ, Kubernetes മാനിഫെസ്റ്റുകൾ എന്നിവ സാധൂകരിക്കുന്നതിനുള്ള ഒരു ഉപകരണമാണ് കോൺഫിഗ്-ലിന്റ്.

ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഇത് ഇൻസ്റ്റാൾ ചെയ്യാൻ കഴിയും നിർദ്ദേശങ്ങൾ പദ്ധതി വെബ്സൈറ്റിൽ.

യഥാർത്ഥ ലേഖനം എഴുതുന്ന സമയത്തെ നിലവിലെ റിലീസ് 1.5.0 ആണ്.

കുബർനെറ്റസ് മാനിഫെസ്റ്റുകൾ സാധൂകരിക്കുന്നതിനുള്ള ബിൽറ്റ്-ഇൻ ടെസ്റ്റുകൾ കോൺഫിഗ്-ലിന്റിലില്ല.

ഏതെങ്കിലും പരിശോധനകൾ നടത്താൻ, നിങ്ങൾ ഉചിതമായ നിയമങ്ങൾ സൃഷ്ടിക്കേണ്ടതുണ്ട്. അവ "റൂൾസെറ്റുകൾ" എന്ന് വിളിക്കുന്ന YAML ഫയലുകളിൽ എഴുതിയിരിക്കുന്നു (നിയമങ്ങൾ), കൂടാതെ ഇനിപ്പറയുന്ന ഘടനയുണ്ട്:

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

(rule.yaml)

നമുക്ക് ഇത് കൂടുതൽ വിശദമായി പഠിക്കാം:

• ഫീൽഡ് type ഏത് തരത്തിലുള്ള കോൺഫിഗറേഷൻ കോൺഫിഗറേഷൻ-ലിന്റ് ഉപയോഗിക്കുമെന്ന് വ്യക്തമാക്കുന്നു. K8s-ന് ഇത് പ്രകടമാണ് എപ്പോഴും Kubernetes.
• ഫീൽഡിൽ files ഫയലുകൾക്ക് പുറമേ, നിങ്ങൾക്ക് ഒരു ഡയറക്ടറി വ്യക്തമാക്കാൻ കഴിയും.
• ഫീൽഡ് rules ഉപയോക്തൃ പരിശോധനകൾ സജ്ജീകരിക്കാൻ ഉദ്ദേശിച്ചുള്ളതാണ്.

ഡിപ്ലോയ്‌മെന്റിലെ ചിത്രങ്ങൾ എല്ലായ്പ്പോഴും ഒരു വിശ്വസനീയമായ ശേഖരത്തിൽ നിന്നാണ് ഡൗൺലോഡ് ചെയ്യുന്നതെന്ന് ഉറപ്പാക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെന്ന് പറയാം. my-company.com/myapp:1.0. അത്തരമൊരു പരിശോധന നടത്തുന്ന ഒരു കോൺഫിഗറേഷൻ-ലിന്റ് നിയമം ഇതുപോലെ കാണപ്പെടും:

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

(rule-trusted-repo.yaml)

ഓരോ നിയമത്തിനും ഇനിപ്പറയുന്ന ആട്രിബ്യൂട്ടുകൾ ഉണ്ടായിരിക്കണം:

• id - നിയമത്തിന്റെ അദ്വിതീയ ഐഡന്റിഫയർ;
• severity - ഒരുപക്ഷേ പരാജയം, മുന്നറിയിപ്പ് и 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
[]

YAML DSL ഉപയോഗിച്ച് Kubernetes YAML മാനിഫെസ്റ്റുകൾ സാധൂകരിക്കുന്നതിന് നിങ്ങളുടെ സ്വന്തം ടെസ്റ്റുകൾ സൃഷ്ടിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന ഒരു വാഗ്ദാന ചട്ടക്കൂടാണ് കോൺഫിഗ്-ലിന്റ്.

എന്നാൽ നിങ്ങൾക്ക് കൂടുതൽ സങ്കീർണ്ണമായ യുക്തിയും പരിശോധനകളും വേണമെങ്കിൽ എന്തുചെയ്യും? YAML ഇതിന് വളരെ പരിമിതമല്ലേ? നിങ്ങൾക്ക് ഒരു പൂർണ്ണ പ്രോഗ്രാമിംഗ് ഭാഷയിൽ ടെസ്റ്റുകൾ സൃഷ്ടിക്കാനായാലോ?

4. ചെമ്പ്

ചെമ്പ് V2 കസ്റ്റം ടെസ്റ്റുകൾ (config-lint പോലെ) ഉപയോഗിച്ച് മാനിഫെസ്റ്റുകൾ സാധൂകരിക്കുന്നതിനുള്ള ഒരു ചട്ടക്കൂടാണ്.

എന്നിരുന്നാലും, ടെസ്റ്റുകളെ വിവരിക്കാൻ YAML ഉപയോഗിക്കുന്നില്ല എന്നതിനാൽ ഇത് രണ്ടാമത്തേതിൽ നിന്ന് വ്യത്യസ്തമാണ്. പകരം ജാവാസ്ക്രിപ്റ്റിൽ ടെസ്റ്റുകൾ എഴുതാം. ചെമ്പ് നിരവധി അടിസ്ഥാന ഉപകരണങ്ങളുള്ള ഒരു ലൈബ്രറി നൽകുന്നു, കുബർനെറ്റസ് ഒബ്‌ജക്റ്റുകളെക്കുറിച്ചുള്ള വിവരങ്ങൾ വായിക്കാനും പിശകുകൾ റിപ്പോർട്ട് ചെയ്യാനും നിങ്ങളെ സഹായിക്കുന്നു.

കോപ്പർ ഇൻസ്റ്റാൾ ചെയ്യുന്നതിനുള്ള ഘട്ടങ്ങൾ ഇതിൽ കാണാം ഔദ്യോഗിക ഡോക്യുമെന്റേഷൻ.

യഥാർത്ഥ ലേഖനം എഴുതുന്ന സമയത്ത് ഈ യൂട്ടിലിറ്റിയുടെ ഏറ്റവും പുതിയ പതിപ്പാണ് 2.0.1.

കോൺഫിഗർ-ലിന്റ് പോലെ, കോപ്പറിന് ബിൽറ്റ്-ഇൻ ടെസ്റ്റുകൾ ഇല്ല. ഒന്ന് എഴുതാം. വിന്യാസങ്ങൾ പോലുള്ള വിശ്വസനീയമായ ശേഖരണങ്ങളിൽ നിന്ന് മാത്രമായി കണ്ടെയ്‌നർ ഇമേജുകൾ ഉപയോഗിക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കാൻ അനുവദിക്കുക my-company.com.

ഒരു ഫയൽ സൃഷ്ടിക്കുക check_image_repo.js ഇനിപ്പറയുന്ന ഉള്ളടക്കത്തോടൊപ്പം:

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

ഇനി നമ്മുടെ മാനിഫെസ്റ്റ് പരിശോധിക്കാം base-valid.yaml, കമാൻഡ് ഉപയോഗിക്കുക copper validate:

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

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

ചെമ്പിന്റെ സഹായത്തോടെ നിങ്ങൾക്ക് കൂടുതൽ സങ്കീർണ്ണമായ പരിശോധനകൾ നടത്താനാകുമെന്ന് വ്യക്തമാണ് - ഉദാഹരണത്തിന്, ഇൻഗ്രെസ്സ് മാനിഫെസ്റ്റുകളിലെ ഡൊമെയ്ൻ നാമങ്ങൾ പരിശോധിക്കുക അല്ലെങ്കിൽ പ്രിവിലേജ്ഡ് മോഡിൽ പ്രവർത്തിക്കുന്ന പോഡുകൾ നിരസിക്കുക.

ചെമ്പിന് വിവിധ യൂട്ടിലിറ്റി പ്രവർത്തനങ്ങൾ ഉണ്ട്:

• DockerImage നിർദ്ദിഷ്ട ഇൻപുട്ട് ഫയൽ വായിക്കുകയും ഇനിപ്പറയുന്ന ആട്രിബ്യൂട്ടുകളുള്ള ഒരു ഒബ്ജക്റ്റ് സൃഷ്ടിക്കുകയും ചെയ്യുന്നു:
  • name - ചിത്രത്തിന്റെ പേര്,
  • tag - ഇമേജ് ടാഗ്,
  • registry - ഇമേജ് രജിസ്ട്രി,
  • registry_url - പ്രോട്ടോക്കോൾ (https://) കൂടാതെ ഇമേജ് രജിസ്ട്രി,
  • fqin - ചിത്രത്തിന്റെ പൂർണ്ണ സ്ഥാനം.
• ഫംഗ്ഷൻ findByName തന്നിരിക്കുന്ന തരം അനുസരിച്ച് ഒരു ഉറവിടം കണ്ടെത്താൻ സഹായിക്കുന്നു (kindപേര് ()name) ഇൻപുട്ട് ഫയലിൽ നിന്ന്.
• ഫംഗ്ഷൻ findByLabels ഒരു നിർദ്ദിഷ്ട തരം ഉപയോഗിച്ച് ഒരു ഉറവിടം കണ്ടെത്താൻ സഹായിക്കുന്നു (kind) കൂടാതെ ലേബലുകൾ (labels).

നിങ്ങൾക്ക് ലഭ്യമായ എല്ലാ സേവന പ്രവർത്തനങ്ങളും കാണാൻ കഴിയും ഇവിടെ.

സ്ഥിരസ്ഥിതിയായി ഇത് മുഴുവൻ ഇൻപുട്ട് YAML ഫയലും ഒരു വേരിയബിളിലേക്ക് ലോഡ് ചെയ്യുന്നു $$ സ്ക്രിപ്റ്റിങ്ങിനായി ഇത് ലഭ്യമാക്കുകയും ചെയ്യുന്നു (jQuery അനുഭവം ഉള്ളവർക്ക് പരിചിതമായ ഒരു സാങ്കേതികത).

കോപ്പറിന്റെ പ്രധാന നേട്ടം വ്യക്തമാണ്: നിങ്ങൾക്ക് ഒരു പ്രത്യേക ഭാഷയിൽ വൈദഗ്ദ്ധ്യം ആവശ്യമില്ല, കൂടാതെ സ്ട്രിംഗ് ഇന്റർപോളേഷൻ, ഫംഗ്ഷനുകൾ മുതലായവ പോലുള്ള നിങ്ങളുടെ സ്വന്തം ടെസ്റ്റുകൾ സൃഷ്ടിക്കാൻ നിങ്ങൾക്ക് വിവിധ JavaScript സവിശേഷതകൾ ഉപയോഗിക്കാം.

കോപ്പറിന്റെ നിലവിലെ പതിപ്പ് ES5 അല്ല, JavaScript എഞ്ചിന്റെ ES6 പതിപ്പിലാണ് പ്രവർത്തിക്കുന്നത് എന്നതും ശ്രദ്ധിക്കേണ്ടതാണ്.

വിശദാംശങ്ങൾ ലഭ്യമാണ് ഔദ്യോഗിക പദ്ധതി വെബ്സൈറ്റ്.

എന്നിരുന്നാലും, നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ JavaScript ഇഷ്‌ടപ്പെടുന്നില്ലെങ്കിൽ, ചോദ്യങ്ങൾ സൃഷ്‌ടിക്കുന്നതിനും നയങ്ങൾ വിവരിക്കുന്നതിനുമായി പ്രത്യേകം രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്ന ഒരു ഭാഷയാണ് നിങ്ങൾ തിരഞ്ഞെടുക്കുന്നതെങ്കിൽ, നിങ്ങൾ കോൺഫ്‌റ്റസ്റ്റിലേക്ക് ശ്രദ്ധിക്കണം.

5.മത്സരം

കോൺഫിഗറേഷൻ ഡാറ്റ പരിശോധിക്കുന്നതിനുള്ള ഒരു ചട്ടക്കൂടാണ് കോൺഫെസ്റ്റ്. കുബർനെറ്റസ് മാനിഫെസ്റ്റുകൾ പരിശോധിക്കുന്നതിനും പരിശോധിക്കുന്നതിനും അനുയോജ്യമാണ്. ഒരു പ്രത്യേക അന്വേഷണ ഭാഷ ഉപയോഗിച്ചാണ് പരിശോധനകൾ വിവരിക്കുന്നത് രെഗൊ.

ഉപയോഗിച്ച് നിങ്ങൾക്ക് കോൺഫെസ്റ്റ് ഇൻസ്റ്റാൾ ചെയ്യാം നിർദ്ദേശങ്ങൾപദ്ധതി വെബ്സൈറ്റിൽ ലിസ്റ്റ് ചെയ്തിരിക്കുന്നു.

യഥാർത്ഥ ലേഖനം എഴുതുമ്പോൾ, ലഭ്യമായ ഏറ്റവും പുതിയ പതിപ്പ് 0.18.2 ആയിരുന്നു.

കോൺഫിഗർ-ലിന്റ്, കോപ്പർ എന്നിവയ്ക്ക് സമാനമായി, ബിൽറ്റ്-ഇൻ ടെസ്റ്റുകളൊന്നുമില്ലാതെയാണ് കോൺഫെസ്റ്റും വരുന്നത്. നമുക്ക് അത് പരീക്ഷിച്ച് സ്വന്തം നയം എഴുതാം. മുമ്പത്തെ ഉദാഹരണങ്ങളിലെന്നപോലെ, കണ്ടെയ്നർ ചിത്രങ്ങൾ വിശ്വസനീയമായ ഉറവിടത്തിൽ നിന്നാണോ എടുത്തതെന്ന് ഞങ്ങൾ പരിശോധിക്കും.

ഒരു ഡയറക്ടറി സൃഷ്ടിക്കുക conftest-checks, അതിൽ പേരുള്ള ഒരു ഫയൽ ഉണ്ട് check_image_registry.rego ഇനിപ്പറയുന്ന ഉള്ളടക്കത്തോടൊപ്പം:

package main

deny[msg] {

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

ഇനി നമുക്ക് ടെസ്റ്റ് ചെയ്യാം base-valid.yaml മുഖാന്തിരം conftest:

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

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

വിശ്വസനീയമല്ലാത്ത ഉറവിടത്തിൽ നിന്ന് ചിത്രങ്ങൾ വന്നതിനാൽ പരീക്ഷണം പരാജയപ്പെട്ടു.

Rego ഫയലിൽ നമ്മൾ ബ്ലോക്ക് നിർവചിക്കുന്നു deny. അതിന്റെ സത്യം ഒരു ലംഘനമായി കണക്കാക്കപ്പെടുന്നു. ബ്ലോക്കുകളാണെങ്കിൽ deny നിരവധി, കോൺഫെസ്റ്റ് അവ പരസ്പരം സ്വതന്ത്രമായി പരിശോധിക്കുന്നു, കൂടാതെ ഏതെങ്കിലും ബ്ലോക്കുകളുടെ സത്യത്തെ ലംഘനമായി കണക്കാക്കുന്നു.

ഡിഫോൾട്ട് ഔട്ട്‌പുട്ടിന് പുറമേ, കോൺഫെസ്റ്റ് JSON, TAP, ടേബിൾ ഫോർമാറ്റ് എന്നിവയെ പിന്തുണയ്‌ക്കുന്നു - നിലവിലുള്ള ഒരു CI പൈപ്പ്‌ലൈനിൽ നിങ്ങൾക്ക് റിപ്പോർട്ടുകൾ ഉൾപ്പെടുത്തണമെങ്കിൽ വളരെ ഉപയോഗപ്രദമായ സവിശേഷത. ഫ്ലാഗ് ഉപയോഗിച്ച് നിങ്ങൾക്ക് ആവശ്യമുള്ള ഫോർമാറ്റ് സജ്ജമാക്കാൻ കഴിയും --output.

നയങ്ങൾ ഡീബഗ് ചെയ്യുന്നത് എളുപ്പമാക്കുന്നതിന്, കോൺഫെസ്റ്റിന് ഒരു ഫ്ലാഗ് ഉണ്ട് --trace. നിർദ്ദിഷ്‌ട നയ ഫയലുകൾ കോൺഫെസ്റ്റ് പാഴ്‌സ് ചെയ്യുന്നതെങ്ങനെ എന്നതിന്റെ ഒരു ട്രെയ്സ് ഇത് ഔട്ട്പുട്ട് ചെയ്യുന്നു.

ഒസിഐ (ഓപ്പൺ കണ്ടെയ്‌നർ ഇനിഷ്യേറ്റീവ്) രജിസ്‌ട്രികളിൽ ആർട്ടിഫാക്‌റ്റുകളായി മത്സര നയങ്ങൾ പ്രസിദ്ധീകരിക്കാനും പങ്കിടാനും കഴിയും.

Команды 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 ഇതുവരെ പിന്തുണയ്‌ക്കുന്നില്ല. അതിനാൽ നിങ്ങൾ ഉപയോഗിക്കുകയാണെങ്കിൽ നിങ്ങൾ ഭാഗ്യവാനാണെന്ന് കരുതുക അസൂർ കണ്ടെയ്നർ രജിസ്ട്രി (ACR) അല്ലെങ്കിൽ നിങ്ങളുടെ സ്വന്തം രജിസ്ട്രി.

ആർട്ടിഫാക്‌റ്റ് ഫോർമാറ്റ് സമാനമാണ് പോളിസി ഏജന്റ് പാക്കേജുകൾ തുറക്കുക (OPA), നിലവിലുള്ള OPA പാക്കേജുകളിൽ നിന്ന് ടെസ്റ്റുകൾ പ്രവർത്തിപ്പിക്കുന്നതിന് കോൺഫെസ്റ്റ് ഉപയോഗിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു.

പോളിസി പങ്കിടലിനെയും കോൺഫെസ്റ്റിന്റെ മറ്റ് സവിശേഷതകളെയും കുറിച്ച് നിങ്ങൾക്ക് കൂടുതലറിയാൻ കഴിയും ഔദ്യോഗിക പദ്ധതി വെബ്സൈറ്റ്.

ക്സനുമ്ക്സ. Polaris

ഈ ലേഖനത്തിൽ ചർച്ച ചെയ്യുന്ന അവസാന ഉപകരണം പോളാരിസ്. (അവന്റെ കഴിഞ്ഞ വർഷത്തെ പ്രഖ്യാപനം ഞങ്ങൾ ഇതിനകം വിവർത്തനം ചെയ്തിട്ടുണ്ട് - ഏകദേശം. വിവർത്തനം)

പോളാരിസ് ഒരു ക്ലസ്റ്ററിൽ ഇൻസ്റ്റാൾ ചെയ്യാം അല്ലെങ്കിൽ കമാൻഡ് ലൈൻ മോഡിൽ ഉപയോഗിക്കാം. നിങ്ങൾ ഊഹിച്ചതുപോലെ, കുബർനെറ്റസ് മാനിഫെസ്റ്റുകളെ സ്ഥിരമായി വിശകലനം ചെയ്യാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു.

കമാൻഡ് ലൈൻ മോഡിൽ പ്രവർത്തിക്കുമ്പോൾ, സുരക്ഷയും മികച്ച രീതികളും (ക്യൂബ്-സ്കോറിന് സമാനമായത്) പോലുള്ള മേഖലകൾ ഉൾക്കൊള്ളുന്ന ബിൽറ്റ്-ഇൻ ടെസ്റ്റുകൾ ലഭ്യമാണ്. കൂടാതെ, നിങ്ങൾക്ക് നിങ്ങളുടെ സ്വന്തം ടെസ്റ്റുകൾ സൃഷ്ടിക്കാൻ കഴിയും (കോൺഫിഗ്-ലിന്റ്, കോപ്പർ, കോൺഫെസ്റ്റ് എന്നിവ പോലെ).

മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, പോളാരിസ് രണ്ട് വിഭാഗത്തിലുള്ള ഉപകരണങ്ങളുടെയും പ്രയോജനങ്ങൾ സംയോജിപ്പിക്കുന്നു: അന്തർനിർമ്മിതവും ഇഷ്‌ടാനുസൃതവുമായ ടെസ്റ്റുകൾക്കൊപ്പം.

കമാൻഡ് ലൈൻ മോഡിൽ Polaris ഇൻസ്റ്റാൾ ചെയ്യാൻ, ഉപയോഗിക്കുക പ്രൊജക്റ്റ് വെബ്സൈറ്റിലെ നിർദ്ദേശങ്ങൾ.

യഥാർത്ഥ ലേഖനം എഴുതുന്ന സമയത്ത്, പതിപ്പ് 1.0.3 ലഭ്യമാണ്.

ഇൻസ്റ്റാളേഷൻ പൂർത്തിയായാൽ നിങ്ങൾക്ക് മാനിഫെസ്റ്റിൽ പോളാരിസ് പ്രവർത്തിപ്പിക്കാൻ കഴിയും base-valid.yaml ഇനിപ്പറയുന്ന കമാൻഡ് ഉപയോഗിച്ച്:

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

നടത്തിയ പരിശോധനകളുടെയും അവയുടെ ഫലങ്ങളുടെയും വിശദമായ വിവരണത്തോടെ ഇത് JSON ഫോർമാറ്റിൽ ഒരു സ്ട്രിംഗ് ഔട്ട്പുട്ട് ചെയ്യും. ഔട്ട്പുട്ടിന് ഇനിപ്പറയുന്ന ഘടന ഉണ്ടായിരിക്കും:

{
  "PolarisOutputVersion": "1.0",
  "AuditTime": "0001-01-01T00:00:00Z",
  "SourceType": "Path",
  "SourceName": "test-data/base-valid.yaml",
  "DisplayName": "test-data/base-valid.yaml",
  "ClusterInfo": {
    "Version": "unknown",
    "Nodes": 0,
    "Pods": 2,
    "Namespaces": 0,
    "Controllers": 2
  },
  "Results": [
    /* длинный список */
  ]
}

പൂർണ്ണമായ ഔട്ട്പുട്ട് ലഭ്യമാണ് ഇവിടെ.

ക്യൂബ്-സ്‌കോർ പോലെ, മാനിഫെസ്റ്റ് മികച്ച രീതികൾ പാലിക്കാത്ത മേഖലകളിലെ പ്രശ്‌നങ്ങൾ പോളാരിസ് തിരിച്ചറിയുന്നു:

• കായ്കൾക്ക് ആരോഗ്യ പരിശോധനകളൊന്നുമില്ല.
• കണ്ടെയ്നർ ചിത്രങ്ങളുടെ ടാഗുകൾ വ്യക്തമാക്കിയിട്ടില്ല.
• കണ്ടെയ്നർ റൂട്ട് ആയി പ്രവർത്തിക്കുന്നു.
• മെമ്മറിക്കും സിപിയുവിനുമുള്ള അഭ്യർത്ഥനകളും പരിധികളും വ്യക്തമാക്കിയിട്ടില്ല.

ഓരോ പരിശോധനയും, അതിന്റെ ഫലങ്ങളെ ആശ്രയിച്ച്, നിർണായകതയുടെ ഒരു പരിധി നിശ്ചയിച്ചിരിക്കുന്നു: മുന്നറിയിപ്പ് അഥവാ അപകടം. ലഭ്യമായ ബിൽറ്റ്-ഇൻ ടെസ്റ്റുകളെക്കുറിച്ച് കൂടുതലറിയാൻ, ദയവായി റഫർ ചെയ്യുക പ്രമാണീകരണം.

വിശദാംശങ്ങൾ ആവശ്യമില്ലെങ്കിൽ, നിങ്ങൾക്ക് ഫ്ലാഗ് വ്യക്തമാക്കാം --format score. ഈ സാഹചര്യത്തിൽ, പോളാരിസ് 1 മുതൽ 100 ​​- വരെയുള്ള സംഖ്യകൾ പുറപ്പെടുവിക്കും സ്കോർ (അതായത് വിലയിരുത്തൽ):

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

സ്കോർ 100-ലേക്ക് അടുക്കുന്തോറും കരാറിന്റെ അളവ് കൂടും. നിങ്ങൾ കമാൻഡിന്റെ എക്സിറ്റ് കോഡ് പരിശോധിക്കുകയാണെങ്കിൽ polaris audit, ഇത് 0 ന് തുല്യമാണെന്ന് മാറുന്നു.

ശക്തിയാണ് polaris audit രണ്ട് ഫ്ലാഗുകൾ ഉപയോഗിച്ച് പൂജ്യമല്ലാത്ത കോഡ് ഉപയോഗിച്ച് നിങ്ങൾക്ക് ജോലി അവസാനിപ്പിക്കാം:

• ഫ്ലാഗ് --set-exit-code-below-score 1-100 ശ്രേണിയിലുള്ള ഒരു പരിധി മൂല്യം ഒരു ആർഗ്യുമെന്റായി എടുക്കുന്നു. ഈ സാഹചര്യത്തിൽ, സ്കോർ ത്രെഷോൾഡിന് താഴെയാണെങ്കിൽ, എക്സിറ്റ് കോഡ് 4 ഉപയോഗിച്ച് കമാൻഡ് പുറത്തുകടക്കും. നിങ്ങൾക്ക് ഒരു നിശ്ചിത ത്രെഷോൾഡ് മൂല്യമുള്ളപ്പോൾ ഇത് വളരെ ഉപയോഗപ്രദമാണ് (പറയുക 75) കൂടാതെ സ്കോർ താഴെ പോയാൽ നിങ്ങൾക്ക് ഒരു അലേർട്ട് ലഭിക്കേണ്ടതുണ്ട്.
• ഫ്ലാഗ് --set-exit-code-on-danger അപകട പരിശോധനകളിൽ ഒന്ന് പരാജയപ്പെട്ടാൽ കോഡ് 3 ഉപയോഗിച്ച് കമാൻഡ് പരാജയപ്പെടാൻ ഇടയാക്കും.

വിശ്വസനീയമായ ഒരു ശേഖരത്തിൽ നിന്നാണോ ചിത്രം എടുത്തതെന്ന് പരിശോധിക്കുന്ന ഒരു ഇഷ്‌ടാനുസൃത പരിശോധന സൃഷ്‌ടിക്കാൻ നമുക്ക് ശ്രമിക്കാം. ഇഷ്‌ടാനുസൃത പരിശോധനകൾ YAML ഫോർമാറ്റിൽ വ്യക്തമാക്കിയിട്ടുണ്ട്, കൂടാതെ JSON സ്കീമ ഉപയോഗിച്ചാണ് ടെസ്റ്റ് വിവരിച്ചിരിക്കുന്നത്.

ഇനിപ്പറയുന്ന YAML കോഡ് സ്‌നിപ്പറ്റ് ഒരു പുതിയ ടെസ്റ്റിനെ വിവരിക്കുന്നു checkImageRepo:

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

നമുക്ക് അത് സൂക്ഷ്മമായി പരിശോധിക്കാം:

• successMessage - ടെസ്റ്റ് വിജയകരമായി പൂർത്തിയാക്കിയാൽ ഈ ലൈൻ പ്രിന്റ് ചെയ്യപ്പെടും;
• failureMessage - പരാജയപ്പെട്ടാൽ ഈ സന്ദേശം കാണിക്കും;
• category - വിഭാഗങ്ങളിലൊന്ന് സൂചിപ്പിക്കുന്നു: Images, Health Checks, Security, Networking и Resources;
• target--- ഏത് തരം ഒബ്ജക്റ്റാണ് നിർണ്ണയിക്കുന്നത് (spec) ടെസ്റ്റ് പ്രയോഗിക്കുന്നു. സാധ്യമായ മൂല്യങ്ങൾ: Container, Pod അഥവാ Controller;
• പരീക്ഷണം തന്നെ വസ്തുവിൽ വ്യക്തമാക്കിയിട്ടുണ്ട് schema JSON സ്കീമ ഉപയോഗിക്കുന്നു. ഈ പരീക്ഷയിലെ പ്രധാന വാക്ക് pattern ഇമേജ് ഉറവിടം ആവശ്യമുള്ളതുമായി താരതമ്യം ചെയ്യാൻ ഉപയോഗിക്കുന്നു.

മുകളിലുള്ള ടെസ്റ്റ് പ്രവർത്തിപ്പിക്കുന്നതിന്, നിങ്ങൾ ഇനിപ്പറയുന്ന പോളാരിസ് കോൺഫിഗറേഷൻ സൃഷ്ടിക്കേണ്ടതുണ്ട്:

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

(polaris-conf.yaml)

നമുക്ക് ഫയൽ പാഴ്സ് ചെയ്യാം:

• ഫീൽഡിൽ checks പരിശോധനകളും അവയുടെ നിർണായക നിലവാരവും നിർദ്ദേശിക്കപ്പെടുന്നു. വിശ്വസനീയമല്ലാത്ത ഉറവിടത്തിൽ നിന്ന് ഒരു ചിത്രം എടുക്കുമ്പോൾ മുന്നറിയിപ്പ് ലഭിക്കുന്നത് അഭികാമ്യമായതിനാൽ, ഞങ്ങൾ ലെവൽ ഇവിടെ സജ്ജമാക്കുന്നു danger.
• പരീക്ഷ തന്നെ checkImageRepo തുടർന്ന് വസ്തുവിൽ രജിസ്റ്റർ ചെയ്തു customChecks.

ഫയൽ ഇതായി സേവ് ചെയ്യുക custom_check.yaml. ഇപ്പോൾ നിങ്ങൾക്ക് ഓടാം polaris audit സ്ഥിരീകരണം ആവശ്യമുള്ള ഒരു YAML മാനിഫെസ്റ്റിനൊപ്പം.

നമുക്ക് നമ്മുടെ പ്രകടനപത്രിക പരിശോധിക്കാം base-valid.yaml:

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

ടീം polaris audit മുകളിൽ വ്യക്തമാക്കിയ ഉപയോക്തൃ പരിശോധന മാത്രം നടത്തി, അത് പരാജയപ്പെട്ടു.

നിങ്ങൾ ചിത്രം ശരിയാക്കുകയാണെങ്കിൽ my-company.com/http-echo:1.0, പോളാരിസ് വിജയകരമായി പൂർത്തിയാക്കും. മാറ്റങ്ങളുള്ള പ്രകടനപത്രിക ഇതിനോടകം പുറത്തിറക്കിയിട്ടുണ്ട് ശേഖരങ്ങൾഅതിനാൽ നിങ്ങൾക്ക് മാനിഫെസ്റ്റിൽ മുമ്പത്തെ കമാൻഡ് പരിശോധിക്കാം image-valid-mycompany.yaml.

ഇപ്പോൾ ചോദ്യം ഉയർന്നുവരുന്നു: ഇഷ്‌ടാനുസൃതമായവയ്‌ക്കൊപ്പം ബിൽറ്റ്-ഇൻ ടെസ്റ്റുകൾ എങ്ങനെ പ്രവർത്തിപ്പിക്കാം? എളുപ്പത്തിൽ! നിങ്ങൾ കോൺഫിഗറേഷൻ ഫയലിലേക്ക് ബിൽറ്റ്-ഇൻ ടെസ്റ്റ് ഐഡന്റിഫയറുകൾ ചേർക്കേണ്ടതുണ്ട്. തൽഫലമായി, ഇത് ഇനിപ്പറയുന്ന ഫോം എടുക്കും:

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

(config_with_custom_check.yaml)

ഒരു സമ്പൂർണ്ണ കോൺഫിഗറേഷൻ ഫയലിന്റെ ഒരു ഉദാഹരണം ലഭ്യമാണ് ഇവിടെ.

മാനിഫെസ്റ്റ് പരിശോധിക്കുക base-valid.yamlബിൽറ്റ്-ഇൻ, ഇഷ്‌ടാനുസൃത പരിശോധനകൾ ഉപയോഗിച്ച്, നിങ്ങൾക്ക് കമാൻഡ് ഉപയോഗിക്കാം:

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

പോളാരിസ് ഇഷ്‌ടാനുസൃതമായവ ഉപയോഗിച്ച് ബിൽറ്റ്-ഇൻ ടെസ്റ്റുകൾ പൂർത്തീകരിക്കുന്നു, അതുവഴി രണ്ട് ലോകങ്ങളിലും മികച്ചത് സംയോജിപ്പിക്കുന്നു.

മറുവശത്ത്, റീഗോ അല്ലെങ്കിൽ ജാവാസ്ക്രിപ്റ്റ് പോലുള്ള കൂടുതൽ ശക്തമായ ഭാഷകൾ ഉപയോഗിക്കാനുള്ള കഴിവില്ലായ്മ കൂടുതൽ സങ്കീർണ്ണമായ ടെസ്റ്റുകൾ സൃഷ്ടിക്കുന്നത് തടയുന്ന ഒരു പരിമിത ഘടകമാണ്.

പോളാരിസിനെക്കുറിച്ചുള്ള കൂടുതൽ വിവരങ്ങൾ ഇവിടെ ലഭ്യമാണ് പദ്ധതി വെബ്സൈറ്റ്.

സംഗ്രഹം

Kubernetes YAML ഫയലുകൾ പരിശോധിക്കാനും വിലയിരുത്താനും നിരവധി ടൂളുകൾ ലഭ്യമാണെങ്കിലും, ടെസ്റ്റുകൾ എങ്ങനെ രൂപകൽപന ചെയ്യുകയും നടപ്പിലാക്കുകയും ചെയ്യും എന്നതിനെക്കുറിച്ച് വ്യക്തമായ ധാരണ ഉണ്ടായിരിക്കേണ്ടത് പ്രധാനമാണ്.

ഉദാഹരണത്തിന്, പൈപ്പ് ലൈനിലൂടെ കടന്നുപോകുന്ന കുബെർനെറ്റസ് മാനിഫെസ്റ്റുകൾ എടുക്കുകയാണെങ്കിൽ, അത്തരമൊരു പൈപ്പ്ലൈനിന്റെ ആദ്യപടിയാകാം കുബേവൽ. ഒബ്‌ജക്റ്റ് നിർവചനങ്ങൾ കുബർനെറ്റസ് API സ്കീമയുമായി പൊരുത്തപ്പെടുന്നുണ്ടോ എന്ന് ഇത് നിരീക്ഷിക്കും.

അത്തരമൊരു അവലോകനം പൂർത്തിയായിക്കഴിഞ്ഞാൽ, സ്റ്റാൻഡേർഡ് ബെസ്റ്റ് പ്രാക്ടീസുകളും നിർദ്ദിഷ്ട നയങ്ങളും പാലിക്കുന്നത് പോലെയുള്ള കൂടുതൽ സങ്കീർണ്ണമായ ടെസ്റ്റുകളിലേക്ക് ഒരാൾക്ക് നീങ്ങാം. ഇവിടെയാണ് ക്യൂബ്-സ്കോറും പോളാരിസും ഉപയോഗപ്രദമാകുന്നത്.

സങ്കീർണ്ണമായ ആവശ്യകതകളുള്ളവർക്കും പരിശോധനകൾ വിശദമായി ഇഷ്‌ടാനുസൃതമാക്കേണ്ടവർക്കും, ചെമ്പ്, കോൺഫിഗർ-ലിന്റ്, കോൺഫെസ്റ്റ് എന്നിവ അനുയോജ്യമാകും..

Conftest ഉം config-lint ഉം ഇഷ്ടാനുസൃത പരിശോധനകൾ നിർവചിക്കുന്നതിന് YAML ഉപയോഗിക്കുന്നു, കൂടാതെ കോപ്പർ നിങ്ങൾക്ക് ഒരു പൂർണ്ണ പ്രോഗ്രാമിംഗ് ഭാഷയിലേക്ക് പ്രവേശനം നൽകുന്നു, ഇത് വളരെ ആകർഷകമായ തിരഞ്ഞെടുപ്പാക്കി മാറ്റുന്നു.

മറുവശത്ത്, ഈ ഉപകരണങ്ങളിൽ ഒന്ന് ഉപയോഗിക്കുന്നത് മൂല്യവത്താണോ, അതിനാൽ, എല്ലാ ടെസ്റ്റുകളും സ്വമേധയാ സൃഷ്ടിക്കുക, അല്ലെങ്കിൽ പോളാരിസ് തിരഞ്ഞെടുത്ത് അതിൽ ആവശ്യമുള്ളത് മാത്രം ചേർക്കുക? ഈ ചോദ്യത്തിന് വ്യക്തമായ ഉത്തരം ഇല്ല.

ചുവടെയുള്ള പട്ടിക ഓരോ ഉപകരണത്തിന്റെയും ഒരു ഹ്രസ്വ വിവരണം നൽകുന്നു:

ഉപകരണം
ഉദ്ദേശ്യം
അസൗകര്യങ്ങൾ
ഉപയോക്തൃ പരിശോധനകൾ

കുബേവൽ
API സ്കീമയുടെ ഒരു നിർദ്ദിഷ്‌ട പതിപ്പിനെതിരെ YAML മാനിഫെസ്‌റ്റുകൾ സാധൂകരിക്കുന്നു
സിആർഡിയിൽ പ്രവർത്തിക്കാൻ കഴിയില്ല
ഇല്ല

kube-സ്കോർ
മികച്ച രീതികൾക്കെതിരെയുള്ള YAML പ്രകടനങ്ങളെ വിശകലനം ചെയ്യുന്നു
ഉറവിടങ്ങൾ പരിശോധിക്കാൻ നിങ്ങളുടെ Kubernetes API പതിപ്പ് തിരഞ്ഞെടുക്കാൻ കഴിയില്ല
ഇല്ല

ചെമ്പ്
YAML മാനിഫെസ്റ്റുകൾക്കായി ഇഷ്‌ടാനുസൃത JavaScript ടെസ്റ്റുകൾ സൃഷ്‌ടിക്കുന്നതിനുള്ള ഒരു പൊതു ചട്ടക്കൂട്
അന്തർനിർമ്മിത പരിശോധനകളൊന്നുമില്ല. മോശം ഡോക്യുമെന്റേഷൻ
ആ

config-lint
YAML-ൽ ഉൾച്ചേർത്ത ഒരു ഡൊമെയ്ൻ-നിർദ്ദിഷ്ട ഭാഷയിൽ ടെസ്റ്റുകൾ സൃഷ്ടിക്കുന്നതിനുള്ള ഒരു പൊതു ചട്ടക്കൂട്. വിവിധ കോൺഫിഗറേഷൻ ഫോർമാറ്റുകൾ പിന്തുണയ്ക്കുന്നു (ഉദാ. ടെറാഫോം)
റെഡിമെയ്ഡ് ടെസ്റ്റുകളൊന്നുമില്ല. അന്തർനിർമ്മിത അവകാശവാദങ്ങളും പ്രവർത്തനങ്ങളും മതിയാകണമെന്നില്ല
ആ

ഏറ്റുമുട്ടൽ
Rego (ഒരു പ്രത്യേക അന്വേഷണ ഭാഷ) ഉപയോഗിച്ച് നിങ്ങളുടെ സ്വന്തം ടെസ്റ്റുകൾ സൃഷ്ടിക്കുന്നതിനുള്ള ഒരു ചട്ടക്കൂട്. OCI ബണ്ടിലുകൾ വഴി പോളിസികൾ പങ്കിടാൻ അനുവദിക്കുന്നു
അന്തർനിർമ്മിത പരിശോധനകളൊന്നുമില്ല. എനിക്ക് റീഗോ പഠിക്കണം. നയങ്ങൾ പ്രസിദ്ധീകരിക്കുമ്പോൾ ഡോക്കർ ഹബ് പിന്തുണയ്ക്കുന്നില്ല
ആ

പോളാരിസ്
അവലോകനങ്ങൾ YAML സ്റ്റാൻഡേർഡ് ബെസ്റ്റ് പ്രാക്ടീസുകൾക്ക് എതിരായി പ്രകടമാണ്. JSON സ്കീമ ഉപയോഗിച്ച് നിങ്ങളുടെ സ്വന്തം ടെസ്റ്റുകൾ സൃഷ്ടിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു
JSON സ്കീമയെ അടിസ്ഥാനമാക്കിയുള്ള ടെസ്റ്റ് കഴിവുകൾ മതിയാകണമെന്നില്ല
ആ

ഈ ഉപകരണങ്ങൾ Kubernetes ക്ലസ്റ്ററിലേക്കുള്ള ആക്‌സസിനെ ആശ്രയിക്കാത്തതിനാൽ, അവ ഇൻസ്റ്റാൾ ചെയ്യാൻ എളുപ്പമാണ്. ഉറവിട ഫയലുകൾ ഫിൽട്ടർ ചെയ്യാനും പ്രോജക്റ്റുകളിലെ പുൾ അഭ്യർത്ഥനകളുടെ രചയിതാക്കൾക്ക് ദ്രുത ഫീഡ്‌ബാക്ക് നൽകാനും അവ നിങ്ങളെ അനുവദിക്കുന്നു.

വിവർത്തകനിൽ നിന്ന് പി.എസ്

ഞങ്ങളുടെ ബ്ലോഗിലും വായിക്കുക:

• «കുബർനെറ്റസ് ക്ലസ്റ്ററുകളെ ആരോഗ്യകരമായി നിലനിർത്താൻ പോളാരിസ് അവതരിപ്പിച്ചു";
• «Kubernetes-ന് YAML പിന്തുണയുള്ള Vim";
• «Google-ന്റെ 7 കണ്ടെയ്‌നർ മികച്ച സമ്പ്രദായങ്ങൾ".

അവലംബം: www.habr.com