kyverno | 伪架构师

用 Kyverno 让 Argo Workflow 单步执行

Thu, 18 Jul 2024 22:59:35 +0800

AWS 的 SSM Automation 中，有个有趣的特性就是单步执行，在编写自动化脚本的时候，这个功能对调试非常有帮助。Argo Workflow 也有个暂停特性，官网给出的例子是这样的：

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: pause-after-
spec:
  entrypoint: whalesay
  templates:
    - name: whalesay
      container:
        image: argoproj/argosay:v2
        env:
          - name: ARGO_DEBUG_PAUSE_AFTER
            value: 'true'

把他提交到 Argo 会看到暂停的情况：

$ argo submit --watch debug.yml
Name:                pause-after-hpvg9                                                                                                                                          [0/1455]
Namespace:           default
ServiceAccount:      unset (will run with the default ServiceAccount)
Status:              Running
Conditions:
 PodRunning          True
Created:             Thu Jul 18 23:18:46 +0800 (18 seconds ago)
Started:             Thu Jul 18 23:18:46 +0800 (18 seconds ago)
Duration:            18 seconds
Progress:            0/1

STEP                  TEMPLATE  PODNAME            DURATION  MESSAGE
 ● pause-after-hpvg9  whalesay  pause-after-hpvg9  18s

你会发现，这个 Workflow 会一直冻结在这个状态，

$ argo list
NAME                STATUS      AGE   DURATION   PRIORITY   MESSAGE
pause-after-hpvg9   Running     11m   11m        0
...

这时候只要进入 Pod，执行一个命令，工作流就会完成：

$ kubectl exec -it pause-after-hpvg9 -- bash
root@pause-after-hpvg9:/# touch /proc/1/root/var/run/argo/ctr/main/after
root@pause-after-hpvg9:/# command terminated with exit code 137

可以看到 Argo 的 Watch 也发生了变化：

STEP                  TEMPLATE  PODNAME            DURATION  MESSAGE
 ✔ pause-after-hpvg9  whalesay  pause-after-hpvg9  21m

问题来了，正常的工作流不会只有一个步骤，要实现单步执行的效果，就需要给每个步骤加入环境变量，是不是有点麻烦？我想到一个办法——用 Kyverno 做个自动补丁。只要 Workflow 加上一个 debug 标签，就给所有步骤加入暂停标志。

废话不多说，上策略代码：

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-argo-debug-env
spec:
  rules:
    - name: add-debug-env-var
      match:
        resources:
          kinds:
            - argoproj.io/v1alpha1/Workflow
          selector:
            matchLabels:
              debug: "true"
          operations:
          - CREATE
      mutate:
        foreach:
          - list: request.object.spec.templates[]
            patchesJson6902: |-
              - path: /spec/templates/{{elementIndex}}/container/env/-
                op: add
                value:
                  name: ARGO_DEBUG_PAUSE_AFTER
                  value: "true"

这段策略有几个要点：

selector 指定，只处理带有 Debug 标签，并且操作为 CREATE 的
使用 foreach 语法，处理工作流中出现的每一个步骤
用 patchesJson6902 方式，给每个步骤的容器加入 ARGO_DEBUG_PAUSE_AFTER 环境变量。

提交策略之后，用如下任务脚本测试一下：

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: debug314159-
  labels:
    debug: "true"
spec:
  entrypoint: whalesay
  templates:
    - name: whalesay
      container:
        image: argoproj/argosay:v2
    - name: whalesayagain
      container:
        image: argoproj/argosay:v2

提交工作流：

$ argo submit debug.yml
Name:                debug314159-dvqmw
Namespace:           default
ServiceAccount:      unset (will run with the default ServiceAccount)
Status:              Pending
Created:             Fri Jul 19 00:11:15 +0800 (now)
Progress:

查看生成的工作流：

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
...
  labels:
    debug: "true"
    workflows.argoproj.io/completed: "false"
    workflows.argoproj.io/phase: Running
  name: debug314159-dvqmw
  namespace: default
...
spec:
...
  - container:
      env:
      - name: ARGO_DEBUG_PAUSE_AFTER
        value: "true"
      image: argoproj/argosay:v2
...
  - container:
      env:
      - name: ARGO_DEBUG_PAUSE_AFTER
        value: "true"
      image: argoproj/argosay:v2
      name: ""
...

可以看到，Kyverno 给每个步骤都加入了环境变量，这样一来，就实现了单步执行的效果。

后记

这个办法还有个问题，就是恢复太麻烦了，我打算接下来用 Shell Operator 来解决。

不明白为什么 Argo Workflow 没有给这种步骤设置一个暂停状态。

Kubernetes 策略引擎对比：OPA/Gatekeeper vs Kyverno

Tue, 23 Feb 2021 16:57:55 +0800

Kubernetes 的 Pod Security Policy（PSP）即将被淘汰和移除，所以需要找到一个替代方案来填补这个即将出现的空白。目前看来，Kubernetes 自身并没有准备相应的替代方案，因此需要在 Kubernetes 之外寻求解决之道。CNCF 的两个头部项目可能会成为首选的替代产品，它们分别是基于 Open Policy Agent（OPA）的 Gatekeeper 以及 Kyverno，两个产品各行有千秋，但是目前还没有对这两个产品进行过正式的比较，这就让面临选择的用户无从下手了。这两个项目都是全功能的 Kubernetes 策略引擎，因此其功能不仅限于替代 PSP。本文尝试对 Gatekeeper 和 Kyverno 进行一个中立客观的比较，让用户能够据此作出决策。这里仅从 Kubernetes 的视角来对这两个项目来进行评价。

因为本文仅仅涉及 Kubernetes，因此对后续对 OPA/Gatekeeper 项目会简称为 Gatekeeper。

为了透明起见，我想公开说明我个人的立场。我是 Kyverno 而不是 GateKeeper 的撰稿人。我在 Kyverno 上写过几篇博客，在 Gatekeeper 上则没有。我过去还曾对 OPA Rego 提出过一些批评。然而，我的目标是把所有这些和任何个人感情放在一边，并试图以全新的方式来对待这两个项目，没有任何偏见和偏爱。

在和 Kyverno 和 OPA 两个社区进行平等地沟通，让双方的管理者和贡献者公平地对比较标准和结果进行评论。在参与比较、评论等方面均没有偏向任何项目。

导言

Kubernetes 策略是什么

Kubernetes 的 Pod Security Policy，正如其名字所暗示的，仅是针对 Pod 工作的，是一种用来验证和控制 Pod 及其属性的机制。另外 PSP 只能屏蔽非法 Pod 的创建，无法执行任何补救/纠正措施。而 Gatekeeper 和 Kyverno 的作用范围就不是局限在 Pod 上，并且也有更多更深入的功能，而不只是简单的验证功能。策略引擎是一种能对整个 Kubernetes 环境进行全局控制的方法。

Gatekeeper 简介

Gatekeeper 是一个由 Google、微软等多个公司合作推出的开源项目，后来捐赠给了 CNCF。现已经历了三次迭代。Gatekeeper 是通用策略引擎 Open Policy Agent（OPA）的 Kubernetes 专用实现。由于 Open Policy Agent 与 Gatekeeper 之间的关系，该项目经常被写成“OPA Gatekeeper”来表明这层关系。Gatekeeper 实现了请求验证功能，最近还加入了变异能力。OPA 的一个主要特征是依赖于使用一种叫做 Rego 的专用编程语言，这种语言被用来实现策略决策的必要逻辑。通过 Rego，OPA 能够广泛适用于包括 Kubernetes 在内的多种不同的软件，实现高层次的逻辑操作。

Kyverno 简介

Kyverno 是来自 Nirmata 的开源项目，后来也捐赠给了 CNCF。和 Gatekeeper一样，Kyverno 也是一个具有验证和变异能力的 Kubernetes 策略引擎，但是它还有生成资源的功能，最近还加入了 API 对象查询的能力。与 Gatekeeper 不同，Kyverno 原本就是为 Kubernetes 编写的。和 Gatekeeper 相比，Kyverno 除了对象生成功能之外，还无需专用语言即可编写策略，从实现语言的角度上来看，Kyverno 的模型更为简洁。

对比

下面的三个表格对两个项目的特征和质量进行分类，并试图以最客观的方式进行对比。这些维度分别是：

特征/功能维度用于描述技术属性；
社区/生态系统维度用于描述落地情况和组织属性；
杂项。

特征/功能	Gatekeeper	Kyverno
验证	✅	✅
变异	✅（Alpha）	✅
生成	❌	✅
原生策略对象	✅	✅
监控指标	✅	❌
OpenAPI 验证（`kubectl explain`）	❌	✅
高可用	✅	❌
API 对象查询	✅	✅（Alpha）
具备测试能力的 CLI 工具	✅ 独立的客户端	✅
策略审计	✅	✅

社区/生态系统	Gatekeeper	Kyverno
CNCF 状态	毕业（OPA）	沙箱
合作伙伴生态系统采用（注 1）	◗	◔
Github 状态（星，分叉、版本、提交）	1,543, 280, 38, 510	702, 72, 60, 3,034
社区认同（注 1）	◗	◔
策略样本库	✅	✅

注 1：无精确定义，Gatekeeper 看起来比 Kyverno 采用数量更多，但是并没有具体数字。注 2：无客观标准，Gatekeeper 历史更长，社区认可度可能更高。

杂项	Gatekeeper	Kyverno
需要编程	✅	✅
可以在 Kubernetes 之外工作	✅	❌
诞生时间	2017 年 7 月	2019 年 5 月
创始公司	Styra（OPA）	Nirmata
文档成熟度	◗（注 1）	◕

注 1：并没有统一的评判标准。这里的评价基于 Gatekeeper 的功能，而不是 Rego。

分析

根据前面的功能对比，我做了一个简单的归纳，列出两个产品的优劣，这里只写出了标题内容，并不够详尽。

Gatekeeper 的优势

能够表达非常复杂的策略；
社区更为成熟；
支持多副本模式，更好的可用性和伸缩性。

Gatekeeper 的劣势

需要编程语言支持，该语言的学习曲线较为陡峭，可能会产生大量技术债，并延长交付时间；
变异能力还处在萌芽期；
没有生成能力，意味着它的主要应用场景就在验证方面；
策略复杂冗长，需要多个对象协同实现。

Kyverno 的优势

Kubernetes 风格的策略表达方式，非常易于编写；
成熟的变异能力；
独特的生成和同步能力，扩展了应用场景；
快速交付，场景丰富。

Kyverno 的劣势

受到语言能力的限制，难以实现复杂策略；
较为年轻，社区接受度不高；
API 对象查询能力还很初级；
没有高可用能力（还在路线图阶段）。

警告：下面的内容是我根据前面的对比表和优势劣势列表，再加上自己对这两个工具的体验，以及在云原生社区的走访，综合起来的意见分析。如果你没有兴趣看我的观点，文章就到此为止了。

Kubernetes 是一个声明式的系统：用户向 Kubernetes 提出对状态的要求，Kubernetes 通过各种控制器，去协调观察到的状态，以使其与用户期望的状态一致。这就是云原生平台的核心价值主张。为了实现这一目标，逻辑实现的重任从用户身上转移到了平台本身。每个资源类型都存在一些内部逻辑，这些逻辑就是协调其状态所需的能力。对于 Gatekeeper 来说，到目前为止最大的弱点是它需要一种叫做 Rego 的专门的编程语言来实现这种逻辑，这种语言在其他地方都无法使用。这是一个现实，因为 OPA 是一个通用的策略引擎。只有通过 Gatekeeper 将其改编成 Kubernetes 形式，才能利用其能力。那么实际上，用户负责描述他们希望调和的对象（策略），以及提供必要的逻辑（Rego）来调和它。使用外部 DSL 来管理 Kubernetes 策略，在很多方面都会变得繁琐和复杂，并给项目增加技术债务。作为一种权衡，其明显的优势是可以实现非常强大的策略。毕竟，当一个人需要编写一种编程语言时，他只受限于该语言的能力及其输入。不过，如果可以在其他地方利用 OPA，就可以分摊这种费用。

相比 Gatekeeper 来说，Kyverno 的第一印象就是没有那么复杂的技术需求。因为它是专门为 Kubernetes 构建的，并且用声明式的方法来表达策略，所以它的心理模型与 Kubernetes 对象的描述和协调方式是相同的。执行策略决策所需的逻辑被从用户的负担中移除，成为工具本身的领域。这种模式导致策略的编写方式得到了极大的简化，全面的降低了策略引擎的使用难度。Kyverno 的编译和生成能力，使它从一个简单的准入控制器转变为一个真正的自动化工具。通过结合这三种能力，再加上最近增加的 API 查询能力，Kyverno 能够执行 Gatekeeper 所不能执行的任务，而且还能够消除可能在整个集群和/或组织中分散使用的其他和不同的工具。这种简单性加上它的自动化能力和对其他工具的整合，为新用户以及有经验的用户和操作者带来了巨大的价值。

根据所介绍的信息，我认为 Kyverno 应该是应用 Kubernetes 策略的一个比较自然的选择。但如果用户符合下面两个用例中的一种或两种，就更应该选择 Gatekeeper。

有一种需求和具体意图，使用一致的核心工具将策略应用于组织内不同的系统（即，不仅仅是Kubernetes）。

反对意见：根据我的经验，无论是在云原生社区内部还是外部，大多数组织目前已经在使用其他工具将策略应用于现有系统。这通常是因为这些系统以及为这些系统实施策略的软件在 Kubernetes 以及 OPA 和 Gatekeeper 之前就已经存在。此外，这些现有工具通常不要求使用编程语言来实现其策略。因此，考虑到现有的知识、运营和资本投资，大多数组织不太可能为了实现工具一致性带来的价值，选择放弃这些工具，转而使用技术负担较重的新工具。

太长不看：如果你正在寻找一个跨 Kubernetes 和其他系统使用的单一策略引擎，Kyverno 不适合你。
策略的复杂度很高。

反对意见：根据我的经验，大多数 Kubernetes 用户都没有使用包括 PSP 在内的任何策略支持。而 2020 年对在 AWS 上运行容器化工作负载的客户的调查也得到了类似的结果，只有 49% 的客户使用策略。这些用户中的绝大多数都在做的是重复的策略——例如“容器不应该有特权”或“确保所有命名空间都带有给定的标签”或“验证 Pods 没有使用 hostPath 卷”等。“复杂”这个词是相对的，有点主观，但这样的策略表达方式绝对不复杂。Kyverno 允许以最简单的形式编写策略，这反过来又更容易推理和维护。如果要为一个更复杂、更困难的工具支付额外的价格，就应该尽量物尽其用，否则无法获得价值。

太长不看：如果无需实现高度复杂的策略，Gatekeeper 不会带来好处。

结语

Gatekeeper 和 Kyverno 项目本身都是有价值、有能力的策略引擎，每个项目都有各自的优缺点。最终，用户应该根据自己的需求和限制条件进行评估并做出最明智的决定，但作为一般建议，所有生产用户都应该计划使用策略引擎来保护集群的安全并简化 Kubernetes 管理。

使用 Kyverno 定义 Kubernetes 策略

Fri, 19 Jul 2019 09:56:01 +0800

Kubernetes 的日常使用过程中，在对象提交给集群之前，我们会有很多机会，很多方法对资源的 Yaml 定义进行检查和处理。很多读者应该也会知道，资源提交之后，还有机会使用 Admission Controller 对资源动动手脚，这其中其实有很多可以提炼出来的标准动作，可以用统一的控制器来进行处理，Kyverno 就是这样一个工具。有了 Kyverno 的帮助，YAML 程序员可以根据条件对资源进行筛选，符合条件的资源可以：

验证资源：对资源定义进行检查，不符合条件的资源拒绝创建，从而保证集群资源的合规性。
修改资源：在资源定义中进行注入，强制资源部分行为的一致性。
生成资源：在资源创建时，同时创建相关的资源。

安装

安装过程是很简单的，安装清单文件位于 https://github.com/nirmata/kyverno/raw/master/definitions/install.yaml，使用 kubectl 直接部署即可：

$ kubectl create -f https://github.com/nirmata/kyverno/raw/master/definitions/install.yaml
customresourcedefinition.apiextensions.k8s.io/policies.kyverno.io created
namespace/kyverno created
service/kyverno-svc created
serviceaccount/kyverno-service-account created
clusterrolebinding.rbac.authorization.k8s.io/kyverno-admin created
deployment.extensions/kyverno created

有一点需要注意的是资源的类型范围，可以在主进程的命令行参数中设定不需要处理的资源类型，缺省设置为：

  containers:
    - name: kyverno
      image: nirmata/kyverno:latest
      args: ["--filterKind","Node,Event,APIService,Policy,TokenReview,SubjectAccessReview"]
      ports:

策略定义

安装完成后，就可以编写策略了，策略的规则不算复杂，具体格式可以从 install.yaml 中的 CRD 定义里面推断出来。

apiVersion : kyverno.io/v1alpha1
kind: Policy
metadata:
  name: sample-policy
spec:
  rules: # 规则数组，spec 的唯一下级
  - name: check-rule-1
    resource: # 定义选择条件，限制生效范围
      kinds: # 生效对象类型数组，必要字段
      - Deployment
      - StatefulSet
      namespace: default  # 命名空间
      name: "*" # 资源名称
      selector: # 用更加复杂一点的方式来定义选择方式
        matchLabels: # 精确匹配标签
          app: some-app
        matchExpressions: # 表达式匹配标签
          key: "operator"
          operator: In
          values:
          - v2
          - v3
    validate:
      ...
    mutate:
      ...
    generate:
      ...

resource 部分是固定的，而 validate mutate generate 三个动作则各有各的结构。

下面用几个例子来演示一下他的功能。

验证资源（validate）

定义一个限制特定命名空间下镜像地址的策略如下：

apiVersion : kyverno.io/v1alpha1
kind: Policy
metadata:
  name: check-registries
spec:
  rules:
  - name: check-registries
    resource:
      kinds:
      - Deployment
      namespace: default
    validate:
      message: "Registry is not allowed"
      pattern:
        spec:
          template:
            spec:
              containers:
              - name: "*"
                image: "docker.io/citizenstig/*"

这个策略文件中，pattern 部分和我们要处理的 deployment 文档结构一致，其中支持通配符，可以用它来对目标进行校验，这里我们要求 default 命名空间中的 Deplyment 对象，containers 下的 image 字段必须符合 docker.io/citizenstig/* 的通配符要求。

例如下面的的 Deployment 就无法创建：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: httpbin
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: httpbin
        version: v1
    spec:
      containers:
        - name: httpbin
          image: citizenstig/httpbin
          imagePullPolicy: IfNotPresent

$ kubectl apply -f httpbin.yaml
Error from server: error when creating "httpbin.yaml": admission webhook "nirmata.kyverno.validating-webhook" denied the request:
Policy check-registries failed with following rules;rulename: check-registries;Rule check-registries: Validation has failed, err Failed to validate value citizenstig/httpbin with pattern docker.io/citizenstig/*. Path: /spec/template/spec/containers/0/image/.

但是如果我们换个命名空间就没问题了：

$ kubectl create ns free
kunamespace/free created
$ kubectl apply -f httpbin.yaml -n free
deployment.extensions/httpbin created

又或者我们不用 Deployment，直接创建 Pod：

apiVersion: v1
kind: Pod
metadata:
  name: static-httpbin
spec:
  containers:
    - name: httpbin
      image: citizenstig/httpbin

果然就能够创建成功了：

$ kubectl apply -f pod.yaml
pod/static-httpbin created

这样的绕过自然是我们不想要的，但是可以改变策略，把限制做到 Pod 上：

  rules:
  - name: check-registries
    resource:
      kinds:
      - Pod
      namespace: default
    validate:
      message: "Registry is not allowed"
      pattern:
        spec:
          containers:
          - name: "*"
            image: "docker.io/citizenstig/*"

这样更新之后，不管是 Deployment 还是静态 Pod 都无法通过了。

如果使用 kubectl edit deploy httpbin 把 image 字段修改为 docker.io/citizenstig/httpbin，就能看到 deployment 能够正常工作了。

或者我们可以要求所有 Pod 都必须指定 CPU 限制：

validate:
  message: "resources/limits is needed."
  pattern:
    spec:
      template:
        spec:
          containers:
          - resources:
              limits:
                cpu: "*"

这个策略提交之后，上面的 Deploy 就再次无法部署了：

$ kubectl apply -f httpbin.yaml
Error from server: error when creating "httpbin.yaml": admission webhook "nirmata.kyverno.validating-webhook" denied the request:
...
Path: /spec/template/spec/containers/0/resources/limits/. Expected map[string]interface {}, found <nil>.

修改清单，加入资源限制，即可满足条件。

修改资源（mutate）

这里也可以做类似自动注入的内容，例如我们可以要求所有 default 命名空间中的 Deployment，如果 deployment 标签中有 io=heavy，则分配到 ssd=true 的节点上。

apiVersion : kyverno.io/v1alpha1
kind: Policy
metadata:
  name: assign-ssd
spec:
  rules:
  - name: assign-ssd
    resource:
      kinds:
      - Deployment
      namespace: default
      selector:
        matchLabels:
          io: heavy
    mutate:
      overlay:
        spec:
          template:
            spec:
              nodeSelector:
                ssd: true

修改一下上面的 Deployment，加上标签：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: httpbin
  labels:
    io: heavy
spec:
...

提交到集群之后，查看变更结果：

$ kubectl get deployments httpbin -o yaml
apiVersion: extensions/v1beta1
kind: Deployment
...
    spec:
...
      dnsPolicy: ClusterFirst
      nodeSelector:
        ssd: "true"

看到多出来的 nodeSelector 字段，如果查看 Pod 信息，也会发现这个 Deployment 的所有 Pod 都分配到了指定的节点上。

创建资源（generate）

有时候我们在 Kubernetes 上创建资源的时候，可能希望同时提供一些缺省资源，例如一个新的命名空间，我们希望其中包含缺省的 Configmap 或者 SA 或者资源限制。

例如我们要在新建 test-n 的命名空间的同时，创建名为 dummy 的 sa。

apiVersion : kyverno.io/v1alpha1
kind: Policy
metadata:
  name: auto-sa
spec:
  rules:
  - name: auto-sa
    resource:
      kinds:
      - Namespace
      name: "test-*"
    generate:
      kind: ServiceAccount
      name: dummy
      data:
        spec: {}
        metadata:
          labels:
            source: "webhook"

这个策略生效后，每次我们创建形如 test-* 的命名空间，其中都会生成对应的名为 dummy 的 ServiceAccount，并且有标签：source=webhook。

Generate 还提供了复制对象的方法，例如每个新命名空间中都应该复制一个名为 conn 的 Configmap，就可以使用如下策略：

apiVersion : kyverno.io/v1alpha1
kind: Policy
metadata:
  name: auto-cm
spec:
  rules:
  - name: auto-cm
    resource:
      kinds:
      - Namespace
      name: "test-*"
    generate:
        kind: ConfigMap
        name: conn
        clone:
          namespace: default
          name: conn

随意验证一下：

$ kubectl create configmap conn \
    --from-literal=mysql=mysql \
    --from-literal=mongodb=mongodb
configmap/conn created
$ kubectl create ns test-6
namespace/test-6 created
$ kubectl get cm,sa -n test-6
NAME             DATA   AGE
configmap/conn   2      6s

NAME                     SECRETS   AGE
serviceaccount/default   1         7s
serviceaccount/dummy     1         6s

这里会发现，随着新的命名空间的创建，新的 SA 和 CM 也都出现了。

结论

相对于其他的类似工具，Kyverno 在灵活、强大和易用之间取得了一个很好的平衡，不需要太多学习时间，就能够提供相当方便的功能，官网提供了大量的针对各种场景的样例，非常值得一看。

参考链接

项目主页：https://kyverno.io/