புரோஹோஸ்டர் > Блог > நிர்வாகம் > சிறந்த நடைமுறைகள் மற்றும் கொள்கைகளுக்கு எதிராக Kubernetes YAML ஐ சரிபார்க்கவும்

சிறந்த நடைமுறைகள் மற்றும் கொள்கைகளுக்கு எதிராக Kubernetes YAML ஐ சரிபார்க்கவும்

குறிப்பு. மொழிபெயர்: K8s சூழல்களுக்கான YAML உள்ளமைவுகளின் எண்ணிக்கை அதிகரித்து வருவதால், அவற்றின் தானியங்கி சரிபார்ப்பின் தேவை மேலும் மேலும் அவசரமாகிறது. இந்த மதிப்பாய்வின் ஆசிரியர், இந்தப் பணிக்கான தற்போதைய தீர்வுகளைத் தேர்ந்தெடுப்பது மட்டுமல்லாமல், அவை எவ்வாறு செயல்படுகின்றன என்பதைப் பார்க்க, வரிசைப்படுத்துதலையும் உதாரணமாகப் பயன்படுத்தினார். இந்த தலைப்பில் ஆர்வமுள்ளவர்களுக்கு இது மிகவும் தகவலறிந்ததாக மாறியது.

சிறந்த நடைமுறைகள் மற்றும் கொள்கைகளுக்கு எதிராக Kubernetes YAML ஐ சரிபார்க்கவும்

டிஎல்; DR: சிறந்த நடைமுறைகள் மற்றும் தேவைகளுக்கு எதிராக Kubernetes YAML கோப்புகளை சரிபார்க்க மற்றும் மதிப்பீடு செய்ய ஆறு நிலையான கருவிகளை இந்தக் கட்டுரை ஒப்பிடுகிறது.

குபெர்னெட்ஸ் பணிச்சுமைகள் பொதுவாக YAML ஆவணங்களின் வடிவத்தில் வரையறுக்கப்படுகின்றன. YAML இல் உள்ள சிக்கல்களில் ஒன்று, மேனிஃபெஸ்ட் கோப்புகளுக்கு இடையே உள்ள கட்டுப்பாடுகள் அல்லது உறவுகளைக் குறிப்பிடுவதில் உள்ள சிரமம்.

கிளஸ்டரில் பயன்படுத்தப்படும் அனைத்து படங்களும் நம்பகமான பதிவேட்டில் இருந்து வந்தவை என்பதை உறுதி செய்ய வேண்டுமானால் என்ன செய்வது?

PodDisruptionBudgets இல்லாத வரிசைப்படுத்துதல்கள் கிளஸ்டருக்கு அனுப்பப்படுவதை நான் எவ்வாறு தடுப்பது?

நிலையான சோதனையின் ஒருங்கிணைப்பு வளர்ச்சி கட்டத்தில் பிழைகள் மற்றும் கொள்கை மீறல்களை அடையாளம் காண உங்களை அனுமதிக்கிறது. இது வள வரையறைகள் சரியானது மற்றும் பாதுகாப்பானது என்பதற்கான உத்தரவாதத்தை அதிகரிக்கிறது, மேலும் உற்பத்திப் பணிச்சுமைகள் சிறந்த நடைமுறைகளைப் பின்பற்றும் வாய்ப்பை அதிகமாக்குகிறது.

குபெர்னெட்ஸ் நிலையான YAML கோப்பு ஆய்வு சுற்றுச்சூழல் அமைப்பை பின்வரும் வகைகளாகப் பிரிக்கலாம்:

  • API மதிப்பீட்டாளர்கள். இந்த வகையில் உள்ள கருவிகள் குபெர்னெட்ஸ் ஏபிஐ சேவையகத்தின் தேவைகளுக்கு எதிராக YAML மேனிஃபெஸ்ட்டைச் சரிபார்க்கும்.
  • தயார் சோதனையாளர்கள். இந்த வகையைச் சேர்ந்த கருவிகள் பாதுகாப்பு, சிறந்த நடைமுறைகளுக்கு இணங்குதல் போன்றவற்றிற்கான ஆயத்த சோதனைகளுடன் வருகின்றன.
  • தனிப்பயன் சரிபார்ப்பாளர்கள். இந்த வகையின் பிரதிநிதிகள் பல்வேறு மொழிகளில் தனிப்பயன் சோதனைகளை உருவாக்க உங்களை அனுமதிக்கின்றனர், எடுத்துக்காட்டாக, ரெகோ மற்றும் ஜாவாஸ்கிரிப்ட்.

இந்த கட்டுரையில் ஆறு வெவ்வேறு கருவிகளை விவரித்து ஒப்பிடுவோம்:

  1. குபேவல்;
  2. குபே-ஸ்கோர்;
  3. config-lint;
  4. செம்பு;
  5. மோதல்;
  6. போலரிஸ்.

சரி, ஆரம்பிக்கலாம்!

வரிசைப்படுத்தல்களை சரிபார்க்கிறது

கருவிகளை ஒப்பிடத் தொடங்கும் முன், அவற்றைச் சோதிப்பதற்கான சில பின்னணியை உருவாக்குவோம்.

கீழே உள்ள மேனிஃபெஸ்டோவில் பல பிழைகள் மற்றும் சிறந்த நடைமுறைகளுக்கு இணங்காதவை உள்ளன: அவற்றில் எத்தனை கண்டுபிடிக்க முடியும்?

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

(base-valid.yaml)

வெவ்வேறு கருவிகளை ஒப்பிட இந்த YAML ஐப் பயன்படுத்துவோம்.

மேலே உள்ள அறிக்கை base-valid.yaml மற்றும் இந்த கட்டுரையில் இருந்து மற்ற அறிக்கைகள் காணலாம் Git களஞ்சியங்கள்.

போர்ட் 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)

வெற்றியடைந்தால், kubeval வெளியேறும் குறியீடு 0 உடன் வெளியேறும். நீங்கள் அதை பின்வருமாறு சரிபார்க்கலாம்:

$ 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)

குபேவல் போன்ற கருவிகளின் நன்மை என்னவென்றால், இது போன்ற பிழைகள் வரிசைப்படுத்தல் சுழற்சியின் ஆரம்பத்தில் பிடிக்கப்படலாம்.

கூடுதலாக, இந்த சோதனைகளுக்கு கிளஸ்டருக்கான அணுகல் தேவையில்லை; அவை ஆஃப்லைனில் செய்யப்படலாம்.

இயல்பாக, kubeval சமீபத்திய Kubernetes API திட்டத்திற்கு எதிராக ஆதாரங்களைச் சரிபார்க்கிறது. இருப்பினும், பெரும்பாலான சந்தர்ப்பங்களில் நீங்கள் ஒரு குறிப்பிட்ட குபெர்னெட்ஸ் வெளியீட்டை சரிபார்க்க வேண்டும். கொடியைப் பயன்படுத்தி இதைச் செய்யலாம் --kubernetes-version:

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

பதிப்பு வடிவமைப்பில் குறிப்பிடப்பட வேண்டும் என்பதை நினைவில் கொள்க Major.Minor.Patch.

சரிபார்ப்பு ஆதரிக்கப்படும் பதிப்புகளின் பட்டியலுக்கு, தயவுசெய்து பார்க்கவும் GitHub இல் JSON ஸ்கீமா, சரிபார்ப்புக்கு எந்த குபேவல் பயன்படுத்துகிறது. நீங்கள் kubeval ஆஃப்லைனில் இயக்க வேண்டும் என்றால், ஸ்கீமாவைப் பதிவிறக்கி, கொடியைப் பயன்படுத்தி அவற்றின் உள்ளூர் இருப்பிடத்தைக் குறிப்பிடவும் --schema-location.

தனிப்பட்ட YAML கோப்புகளுக்கு கூடுதலாக, kubeval கோப்பகங்கள் மற்றும் stdin உடன் வேலை செய்யலாம்.

கூடுதலாக, குபேவல் CI பைப்லைனில் எளிதாக ஒருங்கிணைக்கிறது. க்ளஸ்டருக்கு மேனிஃபெஸ்ட்களை அனுப்பும் முன் சோதனைகளை நடத்த விரும்புபவர்கள், kubeval மூன்று வெளியீட்டு வடிவங்களை ஆதரிக்கிறது என்பதை அறிந்து மகிழ்ச்சி அடைவார்கள்:

  1. சாதாரண எழுத்து;
  2. JSON;
  3. சோதனை எதையும் நெறிமுறை (TAP).

விரும்பிய வகையின் முடிவுகளின் சுருக்கத்தை உருவாக்க வெளியீட்டை மேலும் பாகுபடுத்துவதற்கு எந்த வடிவத்தையும் பயன்படுத்தலாம்.

kubeval இன் குறைபாடுகளில் ஒன்று, அது தற்போது Custom Resource Definitions (CRDs) உடன் இணக்கத்தை சரிபார்க்க முடியாது. இருப்பினும், kubeval ஐ கட்டமைக்க முடியும் அவர்களை புறக்கணிக்கவும்.

குபேவல் வளங்களைச் சரிபார்ப்பதற்கும் மதிப்பிடுவதற்கும் ஒரு சிறந்த கருவியாகும்; இருப்பினும், தேர்வில் தேர்ச்சி பெறுவது வளமானது சிறந்த நடைமுறைகளுடன் இணங்குகிறது என்பதற்கு உத்தரவாதம் அளிக்காது என்பதை வலியுறுத்த வேண்டும்.

எடுத்துக்காட்டாக, குறிச்சொல்லைப் பயன்படுத்துதல் latest ஒரு கொள்கலனில் சிறந்த நடைமுறைகளைப் பின்பற்றுவதில்லை. இருப்பினும், குபேவல் இதை ஒரு பிழையாகக் கருதவில்லை மற்றும் புகாரளிக்கவில்லை. அதாவது, அத்தகைய YAML இன் சரிபார்ப்பு எச்சரிக்கைகள் இல்லாமல் முடிவடையும்.

நீங்கள் YAML ஐ மதிப்பீடு செய்து குறிச்சொல் போன்ற மீறல்களை அடையாளம் காண விரும்பினால் என்ன செய்வது latest? சிறந்த நடைமுறைகளுக்கு எதிராக YAML கோப்பை எவ்வாறு சரிபார்க்கலாம்?

2. குபே-ஸ்கோர்

குபே-ஸ்கோர் YAML ஐ பாகுபடுத்துகிறது மற்றும் உள்ளமைக்கப்பட்ட சோதனைகளுக்கு எதிராக அவற்றை மதிப்பிடுகிறது. இந்தச் சோதனைகள் பாதுகாப்பு வழிகாட்டுதல்கள் மற்றும் சிறந்த நடைமுறைகளின் அடிப்படையில் தேர்ந்தெடுக்கப்படுகின்றன.

  • கொள்கலனை ரூட்டாக இயக்கவில்லை.
  • காய்களின் ஆரோக்கிய சோதனைகளின் இருப்பு.
  • ஆதாரங்களுக்கான கோரிக்கைகள் மற்றும் வரம்புகளை அமைத்தல்.

சோதனை முடிவுகளின் அடிப்படையில், மூன்று முடிவுகள் வழங்கப்படுகின்றன: OK, எச்சரிக்கை и கிரிடிகல்.

நீங்கள் ஆன்லைனில் Kube-ஸ்கோரை முயற்சி செய்யலாம் அல்லது உள்ளூரில் நிறுவலாம்.

அசல் கட்டுரையை எழுதும் போது, ​​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 குபேவல் சோதனைகளில் தேர்ச்சி பெறுகிறது, அதே நேரத்தில் க்யூப்-ஸ்கோர் பின்வரும் குறைபாடுகளை சுட்டிக்காட்டுகிறது:

  • தயார்நிலை சரிபார்ப்புகள் உள்ளமைக்கப்படவில்லை.
  • 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-ஸ்கோரும் ஒரு சோதனை தோல்வியடையும் போது பூஜ்ஜியமற்ற வெளியேறும் குறியீட்டை வழங்கும் கிரிடிகல். இதேபோன்ற செயலாக்கத்தையும் நீங்கள் இயக்கலாம் எச்சரிக்கை.

கூடுதலாக, வெவ்வேறு API பதிப்புகளுடன் (குபேவல் போல) இணங்குவதற்கான ஆதாரங்களைச் சரிபார்க்க முடியும். இருப்பினும், இந்தத் தகவல் kube-ஸ்கோரில் ஹார்ட்கோட் செய்யப்பட்டுள்ளது: நீங்கள் Kubernetes இன் வேறு பதிப்பைத் தேர்ந்தெடுக்க முடியாது. நீங்கள் உங்கள் கிளஸ்டரை மேம்படுத்த விரும்பினால் அல்லது K8s இன் வெவ்வேறு பதிப்புகளுடன் பல கிளஸ்டர்களை வைத்திருந்தால், இந்த வரம்பு பெரிய சிக்கலாக இருக்கலாம்.

அதை கவனியுங்கள் ஏற்கனவே ஒரு பிரச்சினை உள்ளது இந்த வாய்ப்பை உணர ஒரு முன்மொழிவுடன்.

kube-ஸ்கோர் பற்றிய கூடுதல் தகவல்களை இங்கே காணலாம் அதிகாரப்பூர்வ வலைத்தளம்.

க்யூப்-ஸ்கோர் சோதனைகள் சிறந்த நடைமுறைகளைச் செயல்படுத்துவதற்கான சிறந்த கருவியாகும், ஆனால் நீங்கள் சோதனையில் மாற்றங்களைச் செய்ய வேண்டுமா அல்லது உங்கள் சொந்த விதிகளைச் சேர்க்க வேண்டுமானால் என்ன செய்வது? ஐயோ, இதைச் செய்ய முடியாது.

Kube-ஸ்கோர் நீட்டிக்க முடியாது: நீங்கள் அதில் கொள்கைகளைச் சேர்க்கவோ அல்லது அவற்றைச் சரிசெய்யவோ முடியாது.

நிறுவனத்தின் கொள்கைகளுடன் இணங்குவதைச் சரிபார்க்க தனிப்பயன் சோதனைகளை நீங்கள் எழுத வேண்டும் என்றால், பின்வரும் நான்கு கருவிகளில் ஒன்றைப் பயன்படுத்தலாம்: config-lint, copper, conftest அல்லது Polaris.

3.Config-lint

கான்ஃபிக்-லின்ட் என்பது YAML, JSON, Terraform, CSV உள்ளமைவு கோப்புகள் மற்றும் குபெர்னெட்டஸ் மேனிஃபெஸ்டுகளை சரிபார்ப்பதற்கான ஒரு கருவியாகும்.

நீங்கள் அதை பயன்படுத்தி நிறுவ முடியும் அறிவுறுத்தல்கள் திட்ட இணையதளத்தில்.

அசல் கட்டுரையை எழுதும் நேரத்தில் தற்போதைய வெளியீடு 1.5.0 ஆகும்.

குபெர்னெட்டஸ் மேனிஃபெஸ்டுகளை சரிபார்ப்பதற்கான உள்ளமைக்கப்பட்ட சோதனைகளை கான்ஃபிக்-லின்ட் கொண்டிருக்கவில்லை.

எந்தவொரு சோதனையையும் நடத்த, நீங்கள் பொருத்தமான விதிகளை உருவாக்க வேண்டும். அவை "விதிகள்" எனப்படும் 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 - இருக்கலாம் தோல்வி, எச்சரிக்கை и 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 மேனிஃபெஸ்டுகளை சரிபார்க்க உங்கள் சொந்த சோதனைகளை உருவாக்க உங்களை அனுமதிக்கும் ஒரு நம்பிக்கைக்குரிய கட்டமைப்பாக config-lint உள்ளது.

ஆனால் உங்களுக்கு மிகவும் சிக்கலான தர்க்கம் மற்றும் சோதனைகள் தேவைப்பட்டால் என்ன செய்வது? YAML இதற்கு மிகவும் மட்டுப்படுத்தப்பட்டதல்லவா? நீங்கள் ஒரு முழு நிரலாக்க மொழியில் சோதனைகளை உருவாக்கினால் என்ன செய்வது?

4. செம்பு

காப்பர் V2 தனிப்பயன் சோதனைகளைப் பயன்படுத்தி (config-lint போன்றது) மேனிஃபெஸ்டுகளை சரிபார்க்கும் கட்டமைப்பாகும்.

இருப்பினும், சோதனைகளை விவரிக்க YAML ஐப் பயன்படுத்தாததால் இது பிந்தையவற்றிலிருந்து வேறுபடுகிறது. சோதனைகளை ஜாவாஸ்கிரிப்ட்டில் எழுதலாம். தாமிரம் பல அடிப்படைக் கருவிகளைக் கொண்ட நூலகத்தை வழங்குகிறது, இது குபெர்னெட்டஸ் பொருட்களைப் பற்றிய தகவலைப் படிக்கவும் பிழைகளைப் புகாரளிக்கவும் உதவுகிறது.

தாமிரத்தை நிறுவுவதற்கான படிகளைக் காணலாம் அதிகாரப்பூர்வ ஆவணங்கள்.

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

தாமிரத்தின் உதவியுடன் நீங்கள் மிகவும் சிக்கலான சோதனைகளைச் செய்யலாம் என்பது தெளிவாகிறது - எடுத்துக்காட்டாக, இன்க்ரஸ் மேனிஃபெஸ்ட்டில் டொமைன் பெயர்களைச் சரிபார்த்தல் அல்லது சலுகை பெற்ற பயன்முறையில் இயங்கும் காய்களை நிராகரித்தல்.

தாமிரம் பல்வேறு பயன்பாட்டு செயல்பாடுகளைக் கொண்டுள்ளது:

  • DockerImage குறிப்பிடப்பட்ட உள்ளீட்டு கோப்பைப் படித்து, பின்வரும் பண்புக்கூறுகளுடன் ஒரு பொருளை உருவாக்குகிறது:
    • name - படத்தின் பெயர்,
    • tag - படக் குறிச்சொல்,
    • registry - படப் பதிவு,
    • registry_url - நெறிமுறை (https://) மற்றும் படப் பதிவு,
    • fqin - படத்தின் முழு இடம்.
  • செயல்பாடு findByName கொடுக்கப்பட்ட வகை மூலம் ஒரு வளத்தைக் கண்டறிய உதவுகிறது (kind) மற்றும் பெயர் (name) உள்ளீட்டு கோப்பிலிருந்து.
  • செயல்பாடு findByLabels ஒரு குறிப்பிட்ட வகை மூலம் வளத்தைக் கண்டறிய உதவுகிறது (kind) மற்றும் லேபிள்கள் (labels).

கிடைக்கக்கூடிய அனைத்து சேவை செயல்பாடுகளையும் நீங்கள் பார்க்கலாம் இங்கே.

முன்னிருப்பாக இது முழு உள்ளீட்டு YAML கோப்பையும் மாறியாக ஏற்றுகிறது $$ மற்றும் அதை ஸ்கிரிப்டிங்கிற்குக் கிடைக்கச் செய்கிறது (jQuery அனுபவம் உள்ளவர்களுக்கு நன்கு தெரிந்த நுட்பம்).

தாமிரத்தின் முக்கிய நன்மை வெளிப்படையானது: நீங்கள் ஒரு சிறப்பு மொழியில் தேர்ச்சி பெறத் தேவையில்லை மற்றும் சரம் இடைக்கணிப்பு, செயல்பாடுகள் போன்ற உங்கள் சொந்த சோதனைகளை உருவாக்க பல்வேறு ஜாவாஸ்கிரிப்ட் அம்சங்களைப் பயன்படுத்தலாம்.

காப்பரின் தற்போதைய பதிப்பு ஜாவாஸ்கிரிப்ட் இன்ஜினின் ES5 பதிப்பில் வேலை செய்கிறது, ES6 அல்ல என்பதையும் கவனத்தில் கொள்ள வேண்டும்.

விவரங்கள் கிடைக்கும் அதிகாரப்பூர்வ திட்ட வலைத்தளம்.

இருப்பினும், நீங்கள் உண்மையில் ஜாவாஸ்கிரிப்டை விரும்பவில்லை மற்றும் வினவல்களை உருவாக்குவதற்கும் கொள்கைகளை விவரிப்பதற்கும் குறிப்பாக வடிவமைக்கப்பட்ட மொழியை விரும்பினால், நீங்கள் மோதலுக்கு கவனம் செலுத்த வேண்டும்.

5.போட்டி

Conftest என்பது உள்ளமைவுத் தரவைச் சோதிப்பதற்கான ஒரு கட்டமைப்பாகும். குபெர்னெட்டஸ் மேனிஃபெஸ்டைச் சோதிப்பதற்கு/சரிபார்ப்பதற்கும் ஏற்றது. சிறப்பு வினவல் மொழியைப் பயன்படுத்தி சோதனைகள் விவரிக்கப்பட்டுள்ளன ரெகோ.

நீங்கள் 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

நம்பத்தகாத மூலத்திலிருந்து படங்கள் வந்ததால், சோதனை தோல்வியடைந்தது.

ரெகோ கோப்பில் நாம் தொகுதியை வரையறுக்கிறோம் deny. அதன் உண்மை மீறலாகக் கருதப்படுகிறது. தொகுதிகள் என்றால் deny பல, கான்ஃபெஸ்ட் அவற்றை ஒருவருக்கொருவர் சுயாதீனமாக சரிபார்க்கிறது, மேலும் எந்த தொகுதிகளின் உண்மையும் மீறலாகக் கருதப்படுகிறது.

இயல்புநிலை வெளியீட்டிற்கு கூடுதலாக, கான்ஃப்டெஸ்ட் JSON, TAP மற்றும் டேபிள் வடிவமைப்பை ஆதரிக்கிறது - நீங்கள் ஏற்கனவே இருக்கும் CI பைப்லைனில் அறிக்கைகளை உட்பொதிக்க வேண்டும் என்றால் மிகவும் பயனுள்ள அம்சமாகும். கொடியைப் பயன்படுத்தி விரும்பிய வடிவமைப்பை அமைக்கலாம் --output.

கொள்கைகளை பிழைத்திருத்துவதை எளிதாக்க, conftest ஒரு கொடியைக் கொண்டுள்ளது --trace. குறிப்பிட்ட கொள்கை கோப்புகளை கான்ஃப்டெஸ்ட் எவ்வாறு பாகுபடுத்துகிறது என்பதற்கான தடத்தை இது வெளியிடுகிறது.

போட்டிக் கொள்கைகள் OCI (திறந்த கொள்கலன் முன்முயற்சி) பதிவேடுகளில் கலைப்பொருளாக வெளியிடப்பட்டு பகிரப்படலாம்.

கட்டளைகளை push и pull தொலைநிலைப் பதிவேட்டில் இருந்து ஒரு கலைப்பொருளை வெளியிட அல்லது ஏற்கனவே உள்ள கலைப்பொருளை மீட்டெடுக்க உங்களை அனுமதிக்கிறது. நாங்கள் உருவாக்கிய கொள்கையை உள்ளூர் டோக்கர் பதிவேட்டில் வெளியிட முயற்சிப்போம் conftest push.

உங்கள் உள்ளூர் டோக்கர் பதிவேட்டைத் தொடங்கவும்:

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

மற்றொரு முனையத்தில், நீங்கள் முன்பு உருவாக்கிய கோப்பகத்திற்குச் செல்லவும் conftest-checks மற்றும் பின்வரும் கட்டளையை இயக்கவும்:

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

கட்டளை வெற்றிகரமாக இருந்தால், இது போன்ற ஒரு செய்தியை நீங்கள் காண்பீர்கள்:

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

இப்போது ஒரு தற்காலிக அடைவை உருவாக்கி அதில் கட்டளையை இயக்கவும் conftest pull. இது முந்தைய கட்டளையால் உருவாக்கப்பட்ட தொகுப்பைப் பதிவிறக்கும்:

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

தற்காலிக கோப்பகத்தில் ஒரு துணை அடைவு தோன்றும் policyஎங்கள் கொள்கை கோப்பு உள்ளது:

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

சோதனைகள் களஞ்சியத்திலிருந்து நேரடியாக இயக்கப்படலாம்:

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

துரதிர்ஷ்டவசமாக, DockerHub இன்னும் ஆதரிக்கப்படவில்லை. எனவே நீங்கள் பயன்படுத்தினால் உங்களை அதிர்ஷ்டசாலி என்று கருதுங்கள் அசூர் கொள்கலன் பதிவு (ACR) அல்லது உங்கள் சொந்த பதிவு.

கலைப்பொருள் வடிவம் போன்றது பாலிசி ஏஜென்ட் தொகுப்புகளைத் திறக்கவும் (OPA), இது ஏற்கனவே உள்ள OPA தொகுப்புகளிலிருந்து சோதனைகளை இயக்க கான்ஃப்டெஸ்ட்டைப் பயன்படுத்த உங்களை அனுமதிக்கிறது.

கொள்கைப் பகிர்வு மற்றும் மோதலின் பிற அம்சங்களைப் பற்றி மேலும் அறியலாம் அதிகாரப்பூர்வ திட்ட வலைத்தளம்.

6. போலரிஸ்

இந்த கட்டுரையில் விவாதிக்கப்படும் கடைசி கருவி போலாரிஸ். (அவரது கடந்த ஆண்டு அறிவிப்பு நாங்கள் ஏற்கனவே மொழிபெயர்க்கப்பட்டுள்ளது - தோராயமாக மொழிபெயர்ப்பு)

போலரிஸை ஒரு கிளஸ்டரில் நிறுவலாம் அல்லது கட்டளை வரி பயன்முறையில் பயன்படுத்தலாம். நீங்கள் யூகித்துள்ளபடி, குபெர்னெட்டஸ் வெளிப்பாடுகளை நிலையான முறையில் பகுப்பாய்வு செய்ய இது உங்களை அனுமதிக்கிறது.

கட்டளை வரி பயன்முறையில் இயங்கும் போது, ​​பாதுகாப்பு மற்றும் சிறந்த நடைமுறைகள் (குபே-ஸ்கோர் போன்றது) போன்ற பகுதிகளை உள்ளடக்கிய உள்ளமைக்கப்பட்ட சோதனைகள் கிடைக்கும். கூடுதலாக, நீங்கள் உங்கள் சொந்த சோதனைகளை உருவாக்கலாம் (config-lint, copper and conftest போன்றவை).

வேறு வார்த்தைகளில் கூறுவதானால், போலரிஸ் இரண்டு வகை கருவிகளின் நன்மைகளை ஒருங்கிணைக்கிறது: உள்ளமைக்கப்பட்ட மற்றும் தனிப்பயன் சோதனைகளுடன்.

கட்டளை வரி முறையில் 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": [
    /* длинный список */
  ]
}

முழு வெளியீடு கிடைக்கும் இங்கே.

க்யூப்-ஸ்கோரைப் போலவே, மேனிஃபெஸ்ட் சிறந்த நடைமுறைகளைச் சந்திக்காத பகுதிகளில் உள்ள சிக்கல்களை போலரிஸ் அடையாளம் காட்டுகிறது:

  • காய்களுக்கு சுகாதார சோதனைகள் இல்லை.
  • கொள்கலன் படங்களுக்கான குறிச்சொற்கள் குறிப்பிடப்படவில்லை.
  • கொள்கலன் வேராக இயங்குகிறது.
  • நினைவகம் மற்றும் CPU க்கான கோரிக்கைகள் மற்றும் வரம்புகள் குறிப்பிடப்படவில்லை.

ஒவ்வொரு சோதனையும், அதன் முடிவுகளைப் பொறுத்து, விமர்சனத்தின் அளவு ஒதுக்கப்படுகிறது: எச்சரிக்கை அல்லது ஆபத்து. உள்ளமைக்கப்பட்ட சோதனைகளைப் பற்றி மேலும் அறிய, தயவுசெய்து பார்க்கவும் ஆவணங்கள்.

விவரங்கள் தேவையில்லை என்றால், நீங்கள் கொடியைக் குறிப்பிடலாம் --format score. இந்த வழக்கில், போலரிஸ் 1 ​​முதல் 100 - வரையிலான எண்ணை வெளியிடும் மதிப்பெண் (அதாவது மதிப்பீடு):

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

மதிப்பெண் 100 க்கு நெருக்கமாக இருந்தால், ஒப்பந்தத்தின் அளவு அதிகமாகும். கட்டளையின் வெளியேறும் குறியீட்டைச் சரிபார்த்தால் polaris audit, இது 0 க்கு சமம் என்று மாறிவிடும்.

படை polaris audit இரண்டு கொடிகளைப் பயன்படுத்தி பூஜ்ஜியமற்ற குறியீட்டைக் கொண்டு வேலையை நிறுத்தலாம்:

  • கொடியை --set-exit-code-below-score ஒரு வாதமாக 1-100 வரம்பில் உள்ள வாசல் மதிப்பை எடுத்துக்கொள்கிறது. இந்த வழக்கில், மதிப்பெண் வாசலுக்குக் கீழே இருந்தால், கட்டளை வெளியேறும் குறியீடு 4 உடன் வெளியேறும். உங்களிடம் ஒரு குறிப்பிட்ட வரம்பு மதிப்பு இருக்கும் போது இது மிகவும் பயனுள்ளதாக இருக்கும் (எனவும் 75) மேலும் மதிப்பெண் கீழே சென்றால் நீங்கள் விழிப்பூட்டலைப் பெற வேண்டும்.
  • கொடியை --set-exit-code-on-danger ஆபத்து சோதனைகளில் ஒன்று தோல்வியுற்றால், குறியீடு 3 உடன் கட்டளை தோல்வியடையும்.

இப்போது படம் நம்பகமான களஞ்சியத்திலிருந்து எடுக்கப்பட்டதா என்பதைச் சரிபார்க்கும் தனிப்பயன் சோதனையை உருவாக்க முயற்சிப்போம். தனிப்பயன் சோதனைகள் YAML வடிவத்தில் குறிப்பிடப்பட்டுள்ளன, மேலும் சோதனையே JSON ஸ்கீமாவைப் பயன்படுத்தி விவரிக்கப்பட்டுள்ளது.

பின்வரும் YAML குறியீடு துணுக்கு புதிய சோதனையை விவரிக்கிறது checkImageRepo:

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

அதைக் கூர்ந்து கவனிப்போம்:

  • successMessage - சோதனை வெற்றிகரமாக முடிந்தால் இந்த வரி அச்சிடப்படும்;
  • failureMessage - தோல்வி ஏற்பட்டால் இந்த செய்தி காண்பிக்கப்படும்;
  • category - வகைகளில் ஒன்றைக் குறிக்கிறது: Images, Health Checks, Security, Networking и Resources;
  • target--- எந்த வகையான பொருளை தீர்மானிக்கிறது (spec) சோதனை பயன்படுத்தப்படுகிறது. சாத்தியமான மதிப்புகள்: Container, Pod அல்லது Controller;
  • சோதனையே பொருளில் குறிப்பிடப்பட்டுள்ளது schema JSON திட்டத்தைப் பயன்படுத்துகிறது. இந்த சோதனையின் முக்கிய சொல் pattern படத்தின் மூலத்தை தேவையானவற்றுடன் ஒப்பிட பயன்படுகிறது.

மேலே உள்ள சோதனையை இயக்க, நீங்கள் பின்வரும் போலரிஸ் உள்ளமைவை உருவாக்க வேண்டும்:

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

(polaris-conf.yaml)

கோப்பை அலசுவோம்:

  • துறையில் checks சோதனைகள் மற்றும் அவற்றின் விமர்சன அளவு பரிந்துரைக்கப்படுகிறது. நம்பத்தகாத மூலத்திலிருந்து படம் எடுக்கப்படும்போது எச்சரிக்கையைப் பெறுவது விரும்பத்தக்கது என்பதால், அளவை இங்கே அமைத்துள்ளோம் danger.
  • சோதனை தானே checkImageRepo பின்னர் பொருளில் பதிவு செய்யப்பட்டது customChecks.

கோப்பை இவ்வாறு சேமிக்கவும் custom_check.yaml. இப்போது நீங்கள் ஓடலாம் polaris audit சரிபார்ப்பு தேவைப்படும் YAML மேனிஃபெஸ்ட்டுடன்.

நமது தேர்தல் அறிக்கையை சோதிப்போம் 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 பற்றிய கூடுதல் தகவல்கள் இங்கே கிடைக்கின்றன திட்ட இணையதளம்.

சுருக்கம்

குபெர்னெட்ஸ் YAML கோப்புகளை ஆய்வு செய்வதற்கும் மதிப்பீடு செய்வதற்கும் பல கருவிகள் உள்ளன, சோதனைகள் எவ்வாறு வடிவமைக்கப்பட்டு செயல்படுத்தப்படும் என்பது பற்றிய தெளிவான புரிதல் முக்கியம்.

உதாரணமாக, குபெர்னெட்டஸ் மேனிஃபெஸ்ட்ஸ் ஒரு பைப்லைன் வழியாக செல்கிறது என்று நீங்கள் எடுத்துக் கொண்டால், அத்தகைய பைப்லைனில் குபேவல் முதல் படியாக இருக்கும்.. பொருள் வரையறைகள் குபெர்னெட்ஸ் ஏபிஐ திட்டத்துடன் ஒத்துப்போகிறதா என்பதை இது கண்காணிக்கும்.

அத்தகைய மதிப்பாய்வு முடிந்ததும், நிலையான சிறந்த நடைமுறைகள் மற்றும் குறிப்பிட்ட கொள்கைகளுடன் இணங்குதல் போன்ற அதிநவீன சோதனைகளுக்கு ஒருவர் செல்லலாம். இங்குதான் குபே-ஸ்கோரும் போலரிஸும் கைக்கு வரும்.

சிக்கலான தேவைகள் மற்றும் சோதனைகளை விரிவாகத் தனிப்பயனாக்க வேண்டியவர்களுக்கு, தாமிரம், config-lint மற்றும் conftest ஆகியவை பொருத்தமானதாக இருக்கும்..

Conftest மற்றும் config-lint ஆகியவை தனிப்பயன் சோதனைகளை வரையறுக்க YAML ஐப் பயன்படுத்துகின்றன, மேலும் செம்பு உங்களுக்கு முழு நிரலாக்க மொழிக்கான அணுகலை வழங்குகிறது, இது மிகவும் கவர்ச்சிகரமான தேர்வாக அமைகிறது.

மறுபுறம், இந்த கருவிகளில் ஒன்றைப் பயன்படுத்துவது மதிப்புக்குரியதா, எனவே, அனைத்து சோதனைகளையும் கைமுறையாக உருவாக்குவது, அல்லது போலரிஸை விரும்புவது மற்றும் அதற்குத் தேவையானதை மட்டும் சேர்க்க வேண்டுமா? இந்த கேள்விக்கு தெளிவான பதில் இல்லை.

கீழே உள்ள அட்டவணை ஒவ்வொரு கருவியின் சுருக்கமான விளக்கத்தை வழங்குகிறது:

கருவி
விதி
குறைபாடுகளை
பயனர் சோதனைகள்

குபேவல்
API ஸ்கீமாவின் குறிப்பிட்ட பதிப்பிற்கு எதிராக YAML வெளிப்பாட்டைச் சரிபார்க்கிறது
CRD உடன் வேலை செய்ய முடியாது
இல்லை

kube-ஸ்கோர்
சிறந்த நடைமுறைகளுக்கு எதிராக YAML வெளிப்படுவதை பகுப்பாய்வு செய்கிறது
ஆதாரங்களைச் சரிபார்க்க, உங்கள் குபெர்னெட்ஸ் API பதிப்பைத் தேர்ந்தெடுக்க முடியவில்லை
இல்லை

செப்பு
YAML மேனிஃபெஸ்ட்டிற்கான தனிப்பயன் JavaScript சோதனைகளை உருவாக்குவதற்கான பொதுவான கட்டமைப்பு
உள்ளமைக்கப்பட்ட சோதனைகள் இல்லை. மோசமான ஆவணங்கள்
ஆம்

config-lint
YAML இல் உட்பொதிக்கப்பட்ட டொமைன்-குறிப்பிட்ட மொழியில் சோதனைகளை உருவாக்குவதற்கான பொதுவான கட்டமைப்பு. பல்வேறு உள்ளமைவு வடிவங்களை ஆதரிக்கிறது (எ.கா. டெர்ராஃபார்ம்)
ஆயத்த சோதனைகள் எதுவும் இல்லை. உள்ளமைக்கப்பட்ட வலியுறுத்தல்கள் மற்றும் செயல்பாடுகள் போதுமானதாக இருக்காது
ஆம்

மோதல்
Rego (ஒரு சிறப்பு வினவல் மொழி) பயன்படுத்தி உங்கள் சொந்த சோதனைகளை உருவாக்குவதற்கான ஒரு கட்டமைப்பு. OCI தொகுப்புகள் மூலம் கொள்கைகளைப் பகிர அனுமதிக்கிறது
உள்ளமைக்கப்பட்ட சோதனைகள் இல்லை. நான் ரெகோ கற்றுக்கொள்ள வேண்டும். கொள்கைகளை வெளியிடும் போது Docker Hub ஆதரிக்கப்படாது
ஆம்

போலாரிஸ்
மதிப்புரைகள் YAML நிலையான சிறந்த நடைமுறைகளுக்கு எதிராக வெளிப்படுகிறது. JSON ஸ்கீமாவைப் பயன்படுத்தி உங்கள் சொந்த சோதனைகளை உருவாக்க உங்களை அனுமதிக்கிறது
JSON ஸ்கீமாவின் அடிப்படையிலான சோதனை திறன்கள் போதுமானதாக இருக்காது
ஆம்

இந்த கருவிகள் குபெர்னெட்ஸ் கிளஸ்டருக்கான அணுகலை நம்பவில்லை என்பதால், அவற்றை நிறுவுவது எளிது. மூலக் கோப்புகளை வடிகட்டவும், திட்டங்களில் இழுக்கும் கோரிக்கைகளின் ஆசிரியர்களுக்கு விரைவான கருத்தை வழங்கவும் அவை உங்களை அனுமதிக்கின்றன.

மொழிபெயர்ப்பாளரிடமிருந்து பி.எஸ்

எங்கள் வலைப்பதிவிலும் படிக்கவும்:

ஆதாரம்: www.habr.com

கருத்தைச் சேர்