关于kubernetes:验证Kubernetes-YAML的最佳实践和策略

本文来自Rancher Labs

Kubernetes工作负载最常见的定义是YAML格局的文件。应用YAML所面临的挑战之一是，它相当难以表白manifest文件之间的束缚或关系。

如果你想查看所有部署到集群中的镜像是否从受信赖的镜像仓库中提取应该怎么做？如何避免没有PodDisruptionBudgets的部署被提交到集群？

集成动态查看能够在靠近开发生命周期的时候发现错误和策略违规。而且因为围绕资源定义的有效性和安全性的保障失去了改善，你能够置信生产工作负载是遵循最佳实际的。

Kubernetes YAML文件动态查看的生态系统能够分为以下几类：

API验证器：这一类工具能够针对Kubernetes API服务器验证给定的YAML manifest。

内置查看器：这一类工具捆绑了平安、最佳实际等方面的意见查看。

自定义验证器：这一类工具容许用几种语言编写自定义查看，如Rego和Javascript。

在本文中，你将学习并比拟六种不同的工具：

Kubeval
Kube-score
Config-lint
Copper
Conftest
Polaris

让咱们开始吧！

验证Deployment

在开始比拟工具之前，你应该设置一个基准。以下manifest并没有遵循最佳实际，可能存在一些问题，你能发现几个问题呢？

apiVersion: apps/v1kind: Deploymentmetadata:  name: http-echospec:  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: v1kind: Servicemetadata:  name: http-echospec:  ports:  - port: 5678    protocol: TCP    targetPort: 5678  selector:    app: http-echo

咱们将会应用这个YAML文件来比照不同的工具。

你能够在这个git仓库中找到下面的YAML清单、文件 base-valid.yaml以及文章中提到的其余manifest：

https://github.com/amitsaha/k...

manifest形容了一个总是在5678端口回复“Hello World”音讯的web应用程序。

你能够通过以下形式部署该应用程序：

kubectl apply -f hello-world.yaml

你能够应用以下命令测试它：

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

你能够拜访http://localhost:8080 并确认该应用程序是否依照预期运行。然而它是否遵循了最佳实际呢？

让咱们往下看。

Kubeval

主页：https://www.kubeval.com/

Kubeval的前提是，与Kubernetes的任何交互都要通过它的REST API。因而，你能够应用API模式来验证一个给定的YAML输出是否合乎该模式。咱们来看看一个例子。

你能够依照我的项目网站上的阐明来装置kubeval，撰写此文时最新版本是0.15.0。装置实现之后，让咱们用前文探讨的manifest来运行它：

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

当胜利之后，kubeval退出时代码为0。你能够应用以下代码验证退出代码：

echo $?0

当初，让咱们应用另一个manifest来测试kubeval：

apiVersion: apps/v1kind: Deploymentmetadata:  name: http-echospec:  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: v1kind: Servicemetadata:  name: http-echospec:  ports:  - port: 5678    protocol: TCP    targetPort: 5678  selector:    app: http-echo

你能发现问题吗？

让咱们运行kubeval：

kubeval kubeval-invalid.yamlWARN - kubeval-invalid.yaml contains an invalid Deployment (http-echo) - selector: selector is requiredPASS - kubeval-invalid.yaml contains a valid Service (http-echo)# let's check the return valueecho $?1

资源并没有通过验证。应用app/v1 API版本的Deployment必须蕴含一个匹配Pod标签的selector。下面的manifest没有蕴含selector，针对manifest运行kubeval报告了一个谬误和一个非零的退出代码。

你可能想晓得，当你用下面的manifest运行kubectl apply -f时会产生什么？

让咱们试一试：

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

这正是kubeval正告你的谬误。你能够通过增加像这样的selector来修复资源。

apiVersion: apps/v1kind: Deploymentmetadata:  name: http-echospec:  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: v1kind: Servicemetadata:  name: http-echospec:  ports:  - port: 5678    protocol: TCP    targetPort: 5678  selector:    app: http-echo

像kubeval这样的工具的益处是，你能够在部署周期的晚期发现这样的谬误。此外，你不须要拜访集群来运行查看——它们能够离线运行。默认状况下，kubeval会依据最新的未公布的Kubernetes API模式验证资源。然而，在大多数状况下，你可能心愿依据特定的Kubernetes版本运行验证。你能够应用标记--kubernetes-version来测试特定的API版本：

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

请留神，版本应该是Major.Minor.Patch.的模式。要查看可用于验证的版本，请查看GitHub上的JSON schema，kubeval应用它来执行验证。

如果你须要离线运行kubeval，你能够下载schemas，而后应用--schema-location标记来应用本地目录。除了单个YAML文件，你还能够针对目录以及规范输出运行kubeval。你还应该晓得，Kubeval易于与你的继续集成流水线集成。如果你想在提交你的manifest到集群之前蕴含查看，那么kubeval反对三种输入格局兴许可能对你有所帮忙。

纯文本
JSON
测试任何货色协定(TAP)

而且你能够应用其中一种格局来进一步解析输入，以创立一个自定义的后果摘要。然而，kubeval存在一个局限性，就是它目前还不能对自定义资源定义（CRD）进行验证。不过kubeval能够疏忽它们。

只管Kubeval是检查和验证资源的绝佳抉择，但请留神，通过测试的资源并不能保障合乎最佳实际。举个例子，在容器镜像中应用最新的标签被认为不是最佳实际。然而，Kubeval并不会将其作为错误报告，它会在没有正告的状况下验证YAML。

如果你想对YAML进行打分，并抓住诸如应用最新的标签这样的违规行为怎么办？如何依据最佳实际查看你的YAML文件？

Kube-score

主页：https://github.com/zegl/kube-...

Kube-score剖析YAML清单，并依据内置的查看进行评分。这些查看是依据平安倡议和最佳实际而抉择的，例如：

以非root用户身份运行容器。
为pods指定健康检查。
定义资源申请和限度。
查看的后果能够是OK、WARNING或CRITICAL。

你能够在线试用kube-score，也能够在本地装置。在写这篇文章时，最新的版本是1.7.0让咱们试着用之前的manifest 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指出了几个不足之处。

短少了readiness probe
短少内存和CPU申请和限度。
短少Poddisruptionbudgets
短少反亲和规定以最大化可用性。
容器以root身份运行。

这些都是你应该解决的无效点，以使你的部署更加强壮和牢靠。kube-score命令会输入一个可读性高的后果，蕴含所有的WARNING和CRITICAL违规行为，这在开发过程中是十分好的。如果你打算把它作为继续集成流水线的一部分，你能够用--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相似，当有一个CRITICAL查看失败时，kube-score会返回一个非零的退出代码，但你配置它在WARNINGs时也会失败。还有一个内置的查看来验证不同API版本的资源，相似于kubeval。然而，这些信息是硬编码在kube-score自身，你不能抉择不同的Kubernetes版本。因而，如果你降级你的集群或你有几个不同的集群运行不同的版本，这可能会限度你应用这一工具。

请留神，有一个open issue能够实现这个性能。你能够在官方网站上理解更多对于kube-score的信息：https://github.com/zegl/kube-...

Kube-score查看是执行最佳实际的优良工具，但如果你想自定义，或者增加本人的规定呢？临时不能够，Kube-score的设计不是可扩大的，你不能增加或调整政策。如果你想写自定义查看来恪守你的组织政策，你能够应用接下来的四个选项之——config-lint、copper、conftest或polaris。

Config-lint

Config-lint是一个旨在验证以YAML、JSON、Terraform、CSV和Kubernetes manifest编写的配置文件的工具。你能够应用我的项目网站上的阐明装置它：

https://stelligent.github.io/...

在撰写本文时，最新的版本是1.5.0。

Config-lint没有内置对Kubernetes manifest的查看。你必须编写本人的规定来执行验证。这些规定被写成YAML文件，称为规定集，具备以下构造：

version: 1description: Rules for Kubernetes spec filestype: Kubernetesfiles:  - "*.yaml"rules:   # list of rules

让咱们来具体看看。type字段示意你将用config-lint查看什么类型的配置——个别是Kubernetes manifest。

files字段除了承受单个文件外，还承受一个目录作为输出。

rules字段是你能够定义自定义查看的中央。比方说，你心愿查看Deployment中的镜像是否总是从受信赖的镜像仓库（如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/"

每条规定必须具备以下属性。

id——这是对规定的惟一标识。
severity——它必须是FAILURE、WARNING和NON_COMPLIANT中的一个。
message——如果违反了一个规定，这个字符串的内容会被显示进去。
resource——你心愿这个规定被利用到的资源品种。
assertions——将对指定资源进行评估的条件列表。

在下面的规定中，every assertion查看每个容器中的Deployment（key:spec.templates.spec.contains）是否应用受信赖的镜像（即以 "my-company.com/"结尾的镜像）。

残缺的规定集看起来如下：

version: 1description: Rules for Kubernetes spec filestype: Kubernetesfiles:  - "*.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/"

如果你想要测试查看，你能够将规定集保留为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"  }]

它失败了。当初，让咱们思考以下manifest和无效的镜像仓库：

apiVersion: apps/v1kind: Deploymentmetadata:  name: http-echospec:  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

应用以上manifest运行雷同的查看并且将不会报告违规：

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

Config-lint是一个很有前途的框架，它能够让你应用YAML DSL为Kubernetes YAML manifest编写自定义查看。但如果你想表白更简单的逻辑和查看呢？是不是YAML的限制性太大？如果你能用真正的编程语言来表白这些查看呢？

Copper

主页：https://github.com/cloud66-os...

Copper V2是一个应用自定义查看来验证清单的框架——就像config-lint一样。然而，Copper并没有应用YAML来定义查看。取而代之的是，测试是用JavaScript编写的，Copper提供了一个库，外面有一些根本的帮忙程序来帮助读取Kubernetes对象和报告谬误。

你能够依照官网文档来装置Copper。在写这篇文章的时候，最新的版本是2.0.1：

https://github.com/cloud66-os...

与config-lint相似，Copper没有内置查看。让咱们写一个查看，以确保部署只能从受信赖的仓库（如my-company.com）拉取容器镜像。创立一个新文件check_image_repo.js，内容如下：

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

当初，要依据咱们的base-valid.yaml manifest运行这项查看，能够应用copper validate命令：

copper validate --in=base-valid.yaml --validator=check_image_tag.jsCheck no_company_repo failed with severity 1 due to Image http-echo is not from my-company.com repoValidation failed

正如你所想的，你能够编写更简单的查看，比方验证Ingress manifest的域名，或者回绝任何作为特权运行的Pod。Copper有一些内置的助手:

DockerImage函数读取指定的输出文件并创立一个蕴含以下属性的对象：

name-蕴含镜像名称
tag-蕴含镜像tag
registry-镜像仓库
registry_url-蕴含协定和镜像仓库
fqin代表整个齐全合格的镜像地位。

findByName函数能够帮忙从输出文件中找到给定kind和name的资源。

findByLabels函数能够帮忙查找资源提供的kind和labels。

你能够在这里看到所有可用的帮忙程序：

https://github.com/cloud66-os...

默认状况下，它将整个输出的YAML文件加载到$$变量中，并使其在你的脚本中可用（如果你过来应用jQuery，你可能会发现这个模式很相熟）。

除了不必学习自定义语言外，你还能够应用整个JavaScript语言来编写你的查看，如字符串插值、函数等。值得注意的是，目前的copper版本嵌入了ES5版本的JavaScript引擎，而不是ES6。想要理解更多，能够拜访我的项目官网：

https://github.com/cloud66-os...

如果Javascript不是你的首选语言，或者你更喜爱用于查问和形容策略的语言，你应该看看conftest。

Conftest

Conftest是一个配置数据的测试框架，可用于检查和验证Kubernetes manifest。测试应用专门构建的查询语言Rego编写。

你能够依照我的项目网站上的阐明装置conftest，在撰写本文时，最新的版本是0.18.2：

https://www.conftest.dev/inst...

与config-lint和copper相似，conftest也没有任何内置的查看。所以咱们通过编写一个策略来试试。和后面的例子一样，你将查看容器是否来自一个可信的起源。

创立一个新的目录，conftest-checks和一个名为check_image_registry.rego的文件，内容如下：

package maindeny[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])}

当初让咱们运行conftest来验证manifest base-valid.yaml：

conftest test --policy ./conftest-checks base-valid.yamlFAIL - base-valid.yaml - image 'hashicorp/http-echo' doesn't come from my-company.com repository1 tests, 1 passed, 0 warnings, 1 failure

当然，它是失败的，因为镜像不受信赖。下面的Rego文件指定了一个deny块，当为true时就会评估为违规。当你有多个deny块时，conftest会独立查看它们，总体后果是任何一个块的违规都会导致整体违规。

除了默认的输入格局外，conftest还反对JSON、TAP和通过--output标记的表格格局，如果你心愿将报告与现有的继续集成流水线集成，那么这些格局将会很有帮忙。为了帮忙调试策略，conftest有一个不便的--trace标记，它能够打印conftest如何解析指定策略文件的跟踪。

Conftest策略能够作为artefacts在OCI（Open Container Initiative）仓库中公布和共享。命令push和pull容许公布一个工件和从近程仓库中提取一个现有的artefact。

让咱们看看应用conftest push将上述策略公布到本地docker仓库的演示。应用以下命令启动本地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命令，将上述bundle下载到长期目录中：

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

你会看到，在蕴含之前push的策略文件的长期目录中，有一个新的子目录策略：

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 repository2 tests, 1 passed, 0 warnings, 1 failure

可怜的是，DockerHub还不是反对的镜像仓库之一。然而，如果你正在应用Azure容器仓库（ACR）或运行你的容器仓库，可能会通过测试。

artefact格局与凋谢策略代理 (OPA) 绑定应用的格局雷同，这使得应用 conftest 从现有的 OPA 绑定中运行测试成为可能。

你能够在官方网站上理解更多对于共享策略和conftest的其余性能：

https://www.conftest.dev/

Polaris

主页：https://github.com/FairwindsO...

本文将探讨的最初一个工具是polaris。Polaris既能够装置在集群外部，也能够作为命令行工具动态地剖析Kubernetes manifest。当作为命令行工具运行时，它包含几个内置的查看，涵盖平安和最佳实际等畛域，相似于kube-score。此外，你还能够用它来编写相似config-lint、copper和conftest的自定义查看。换句话说，polaris联合了两个类别中最好的：内置和自定义查看器。

你能够依照我的项目网站上的阐明装置polaris命令行工具。在写这篇文章的时候，最新的版本是1.0.3：

https://github.com/FairwindsO...

装置实现后，你能够应用以下命令针对base-valid.yaml manifest运行polaris:

polaris audit --audit-path base-valid.yam

上述命令将打印一个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": [    /* long list */  ]}

你能够在下方链接中获取残缺的输入：

https://github.com/amitsaha/k...

与kube-score相似，polaris也发现了一些manifest未达到倡议的最佳实际的状况，其中包含：

短少健康检查的pod。
容器镜像没有指定标签。
容器以root身份运行。
没有设置CPU和内存申请和限度。
每项查看都被划分为正告或危险的重大水平。

要理解无关以后内置查看的更多信息，请参阅文档：

https://github.com/FairwindsO...

如果你对具体的后果不感兴趣，传递标记--format score会打印一个范畴为1-100的数字，polaris将其称为分数（score）：

polaris audit --audit-path test-data/base-valid.yaml --format score68

分数越靠近100，合乎度越高。如果你查看polaris audit命令的退出代码，你会发现它是0。要使polaris审计退出时的代码是非0，能够利用另外两个标记。

--set-exit-code-below-score标记承受范畴为1-100的阈值分数，当分数低于阈值时，将以4的退出代码退出。当你的基线分数是75分，而你想在分数低于75分时收回警报时，这十分有用。

当任何危险查看失败时，--set-exit-code-on-danger标记将以3的退出代码退出。

当初让咱们看看如何为polaris定义一个自定义查看，以测试Deployment中的容器镜像是否来自可信赖的镜像仓库。自定义查看以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指的是其中一个类别—镜像、健康检查、平安、网络和资源。
target是一个字符串，用于确定查看所针对的标准对象，应该是Container、Pod或Controller中的一个。
测试自身是在schema对象中应用JSON模式定义的。这里的查看应用模式关键字来匹配镜像是否来自容许的仓库。

要运行下面定义的查看，你须要创立一个Polaris配置文件，如下所示：

checks:  checkImageRepo: dangercustomChecks:  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/.+$

让咱们来剖析一下这个文件。

check字段指定了检查和它们的严重性。因为你想在镜像不受信赖时收回警报，所以checkImageRepo被调配了一个danger重大水平。
而后在customChecks对象中定义checkImageRepo查看自身。

你能够将下面的文件保留为custom_check.yaml，而后用你想要验证的YAML manifest运行polaris audit。

你能够用base-valid.yaml manifest进行测试：

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

你会发现，polaris audit只运行了下面定义的自定义查看，但没有胜利。如果你将容器镜像批改为my-company.com/http-echo:1.0，polaris将报告胜利。Github仓库中蕴含了批改后的manifest，所以你能够依据image-valid-mycompany.yaml manifest测试后面的命令。

然而如何同时运行内置和自定义查看呢？下面的配置文件应该更新所有内置的查看标识符，看起来应该如下：

checks:  cpuRequestsMissing: warning  cpuLimitsMissing: warning  # Other inbuilt checks..  # ..  # custom checks  checkImageRepo: dangercustomChecks:  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/.+$

你能够在这里看到一个残缺的配置文件的例子：

https://github.com/amitsaha/k...

你能够用自定义和内置查看来测试base-valid.yaml manifest：

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

Polaris用你的自定义查看加强了内置查看，从而联合了两种形式的最佳状态。然而，如果不能应用更弱小的语言，如Rego或JavaScript，可能会限度编写更简单的查看。

要理解更多对于polaris的信息，请查看我的项目网站：

https://github.com/FairwindsO...

总结

尽管有很多工具能够验证、打分和精简Kubernetes YAML文件，但重要的是要有一个心理模型来理解你将如何设计和执行查看。举个例子，如果你想让Kubernetes manifest通过一个流水线，kubeval能够是这样一个流水线的第一步，因为它验证对象定义是否合乎Kubernetes API模式。一旦这项查看胜利，兴许你能够持续进行更具体的测试，比方规范最佳实际和自定义策略。Kube-score和polaris在这里是最优良的抉择。

如果你有简单的需要，并且想要自定义查看的细节，你应该思考copper、config-lint和conftest。尽管conftest和config-lint都应用了更多的YAML来定义自定义验证规定，但copper给你提供了一个真正的编程语言，使其相当有吸引力。然而，你应该应用其中的一个，从头开始写所有的查看，还是应该应用Polaris，只写额定的自定义查看？这要依据状况而定。

验证Deployment

Kubeval

Kube-score

Config-lint

Copper

Conftest

Polaris

总 结

总结