一 背景

在Kubernetes的编排中，我们为了IaC，均使用yaml语法进行描述业务资源，无论是使用单独编写资源清单文件，还是使用helm 的charts，对于yaml语法是否具有像其他语言一样的lint工具进行语法检测？防患于未然，在编写阶段是否可以对kubernetes的错误配置进行提前检测呢，是否有一款工具能检测代码是否遵循kubernetes的最佳实践检测呢？

同时在DevOPS盛行的当下，在GitOPS的工作流中，语法错误检测也不仅限于代码业务本身，更需要对配置代码也进行检测测试，此时一款yaml检测工具就显得尤为重要。

二 kubelinter简介

社区里面StackRox开源来一款名为KubeLinter的yaml检测工具，其旨在帮助用户检测Kubernetes的错误配置，让开发人员能够以简单的方法，在Kubernetes的YAML文件和HELM图表尚未部署到集群之前，先以最佳实践进行检查，并对其进行分析调试。

将YAML文件提供给该工具后，它将通过内置检查运行，然后详细报告任何错误以及解决这些错误的补救措施。关于此工具的最好之处在于它是可配置和可扩展的：可以启用或禁用内置检查，并且您可以定义和使用自己的自定义检查。

三 安装部署

3.1 MacOS安装

brew install kube-linter

3.2 Linux安装

使用二进制安装，可以在release中找到自己想要的版本进行安装。

wget https://github.com/stackrox/kube-linter/releases/download/0.1.3/kube-linter-linux.tar.gz
tar -zxvf kube-linter-linux.tar.gz
mv kube-linter /usr/bin/

四 使用

4.1 待检测yaml

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - name: sec-ctx-demo
    image: busybox
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
    securityContext:
      allowPrivilegeEscalation: false

4.2 执行检测

kube-linter lint pod.yaml

4.3 查看检测结果

pod.yaml: (object: <no namespace>/security-context-demo /v1, Kind=Pod) container "sec-ctx-demo" does not have a read-only root file system (check: no-read-only-root-fs, remediation: Set readOnlyRootFilesystem to true in your container's securityContext.)

pod.yaml: (object: <no namespace>/security-context-demo /v1, Kind=Pod) container "sec-ctx-demo" has cpu limit 0 (check: unset-cpu-requirements, remediation: Set    your container's CPU requests and limits depending on its requirements. See    https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/   #requests-and-limits for more details.)

pod.yaml: (object: <no namespace>/security-context-demo /v1, Kind=Pod) container "sec-ctx-demo" has memory limit 0 (check: unset-memory-requirements, remediation:    Set your container's memory requests and limits depending on its requirements.    See https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/   #requests-and-limits for more details.)

Error: found 3 lint errors

如您所见，YAML文件中发现了错误，每个错误都有明确的补救步骤。

4.4 查看检测类型

如果您想看一下内置检查，可以在https://github.com/stackrox/kube-linter/blob/main/docs/genic/checks.md中列出所有这些检查，或者也可以使用KubeLinter查看清单：

4.5 忽略检测

您可以使用以下注释忽略针对YAML文件的特定检查，也可以根据需要忽略检查组：

ignore-check.kube-linter.io/<check-name>
# 例如：
ignore-check.kube-linter.io/unset-cpu-requirements

您可以像上面这样在上面的部署文件示例中添加忽略检查规则：

metadata:
  name: portainer
  namespace: portainer
  labels:
    io.portainer.kubernetes.application.stack: portainer
    app.kubernetes.io/name: portainer
    app.kubernetes.io/instance: portainer
    app.kubernetes.io/version: "2.0.0"
  annotations:
    ignore-check.kube-linter.io/unset-cpu-requirements : "cpu requirements not required"

现在，当您kube-linter lint deploy.yaml再次运行时，您应该不会看到与CPU要求相关的错误提示。

4.6 使用配置忽略

KubeLinter也可以使用配置运行，您可以在其中提供要包含/排除的所有检测信息。以下是存储库中的示例配置：

# customChecks defines custom checks.
customChecks:
- name: "required-label-app"
  template: "required-label"
  params:
    key: "app"
checks:
  # if doNotAutoAddDefaults is true, default checks are not automatically added.
  doNotAutoAddDefaults: false

  # addAllBuiltIn, if set, adds all built-in checks. This allows users to
  # explicitly opt-out of checks that are not relevant using Exclude.
  # Takes precedence over doNotAutoAddDefaults, if both are set.
  addAllBuiltIn: false

  # include explicitly adds checks, by name. You can reference any of the built-in checks.
  # Note that customChecks defined above are included automatically.
  include:
  - "required-label-owner"
  # exclude explicitly excludes checks, by name. exclude has the highest priority: if a check is
  # in exclude, then it is not considered, even if it is in include as well.
  exclude:
    - "privileged"

如果你运行kubelinter --config config lint deploy.yaml，其中config与上述配置的文件，你应该可以看到添加了需要标签的检查：

deploy.yaml: (object: portainer/portainer apps/v1, Kind=Deployment) no label matching "owner=<any>" found (check: required-label-owner, remediation: Add an email annotation to your object with information about the object's owner.)

当内置到CI管道中时，KubeLinter可以证明是非常有用的工具。可以检查和验证推送到存储库中的编排文件，以获取最佳实践和安全考虑，并在检测到问题时生成警报。

五 集成到DevOPS中

将kubelinter集成在CI过程中非常合适，可以在讲实际应用部署到环境前，进行对kubernetes检测。

这样，可以将部署到集群的应用程序进行健康的就绪检查。该项目处于Alpha阶段，但有望作为CI集成工具在实际部署到生产之前验证所有部署。

六 反思

日常中检测编写的业务Kubernetes资源清单文件可以使用--dry-run来进行，检测是否为kubernetes最佳实践可以使用kube-linter进行，将其无论是安装在开放环境本地检测，还是集成到DevOPS中，都能及时发现并对资源清单文件进行优化。

参考链接

• https://mp.weixin.qq.com/s/Qo2SgTCvVBwJaPfXY_AY1Q
• https://github.com/stackrox/kube-linter
• https://github.com/stackrox/kube-linter/tree/main/docs