生成资源
根据资源创建或更新创建其他资源。
generate 规则可用于在创建新资源或更新源时创建其他资源。这对于创建支持资源很有用，例如命名空间的新 RoleBindings 或 NetworkPolicies。
generate 规则像其它规则一样，支持 match 和 exclude 块。因此，可以在创建任何资源时触发该规则。还可以根据subjects、roles等匹配或排除 API 请求。
在执行 API CREATE 操作时触发 generate 规则。您可以使用 synchronize 属性，在更改时保持资源同步。当 synchronize 被设为 true 时，衍生资源会和源资源（可以定义为策略的一部分，也可以是现有资源）保持同步，并且衍生资源不能被用户修改。如果 synchronize 被设为 false，用户可以直接修改或删除衍生资源。
注意：在 Kyverno 1.3.0 中，synchronize=true 的衍生资源可能会被其它 Kubernetes 控制器及有相应访问权限的用户修改或删除，Kyverno 将重新创建或更新资源以符合配置的策略。
当使用 generate 规则时，源资源既可以是由 Kubernetes 定义的、已存在的资源，也可以是由规则定义的新资源。如果源资源是已存在的资源，如 ConfigMap 或 Secret，将使用 clone 对象。如果源资源是规则中定义的新资源，将使用 data 对象。这些是相互排斥的，并且只能在规则中指定一个。
警告：删除包含有使用 data 对象的 generate 规则，且 synchronize=true 的策略时，将导致立即删除下游的衍生资源。包含 clone 对象的策略不受此行为的影响。
在 CustomResourceDefinitions (CRD) 中定义的 CustomResources 之前，Kubernetes 就有许多默认资源类型。Kyverno 也可以像生成 Kubernetes 默认资源一样，生成 CustomResources，但都需要给 generate 行为所依赖的 ClusterRole 授予额外的权限。要想允许 Kyverno 生成这些类型，需要修改名为 kyverno:generate 的 ClusterRole，并为其添加或更新规则以涵盖所需的资源和动词。
注意：生成自定义资源时，需要设置 apiVersion（例如 spec.generate.apiVersion 和 kind（例如 spec.generate.kind）。
Kyverno 将创建一个名为 UpdateRequest 的中间对象，用于将工作项排队以生成最终资源。要获取生成资源的详细信息和状态，请检查 UpdateRequest 的详细信息。下面将给出 UpdateRequest 的列表。
kubectl get updaterequests -A
UpdateRequest 状态可以具有以下四个值之一：
-
Completed：UpdateRequest 控制器完成策略中定义的资源的创建。 -
Failed：UpdateRequest 控制器处理规则失败。 -
Pending：请求尚未处理或资源尚未创建。 -
Skip：通过向现有资源添加标签/注释来触发 generate 策略，而策略中未定义选择器。
使用内联数据生成 ConfigMap
此策略基于在规则中定义的 ConfigMap 为所有命名空间设置 Zookeeper 和 Kafka 连接字符串。请注意，此规则定义了 generate.data 对象，在这种情况下，该规则将使用规则清单中指定的数据创建一个名为 zk-kafka-address 的新 ConfigMap。
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: zk-kafka-address
spec:
rules:
- name: k-kafka-address
match:
any:
- resources:
kinds:
- Namespace
exclude:
any:
- resources:
namespaces:
- kube-system
- default
- kube-public
- kyverno
generate:
synchronize: true
apiVersion: v1
kind: ConfigMap
name: zk-kafka-address
# 创建 namespace 时生成如下资源
namespace: "{{request.object.metadata.name}}"
data:
kind: ConfigMap
metadata:
labels:
somekey: somevalue
data:
ZK_ADDRESS: "192.168.10.10:2181,192.168.10.11:2181,192.168.10.12:2181"
KAFKA_ADDRESS: "192.168.10.13:9092,192.168.10.14:9092,192.168.10.15:9092"
克隆 ConfigMap 并传播更改
此策略中，源数据是一个已存在于 default 命名空间中名为 config-template 的 ConfigMap。请注意，当原始数据存在于 Kubernetes 中时，此处的 generate 规则将使用 generate.clone 对象。
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: basic-policy
spec:
rules:
- name: Clone ConfigMap
match:
any:
- resources:
kinds:
- Namespace
exclude:
any:
- resources:
namespaces:
- kube-system
- default
- kube-public
- kyverno
generate:
# Kind of generated resource
kind: ConfigMap
# apiVersion of the generated resource
apiVersion: v1
# Name of the generated resource
name: default-config
# namespace for the generated resource
namespace: "{{request.object.metadata.name}}"
# propagate changes from the upstream resource
synchronize : true
clone:
namespace: default
name: config-template
生成 Bindings
为了让 Kyverno 生成新的 RoleBinding 或 ClusterRoleBinding 资源，它的 ServiceAccount 必须首先绑定到您尝试生成的、相同 Role 或 ClusterRole。如果不这样做，Kubernetes 会阻止请求，因为它看到来自 Kyverno ServiceAccount 可能在尝试提升权限。这不是 Kyverno 的功能，而是 Kubernetes RBAC 的工作方式。
例如，如果你想要编写一个 generate 规则，该规则会创建一个新的 RoleBinding 资源，并授予某些用户在新命名空间上的 admin 角色，Kyverno ServiceAccount 必须通过 ClusterRoleBinding 与同样的 admin 角色绑定。
为 Kyverno 的 ServiceAccount（默认名为 kyverno ）创建一个新的 ClusterRoleBinding。
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: kyverno:generate-admin
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: admin
subjects:
- kind: ServiceAccount
name: kyverno
namespace: kyverno
现在，像往常一样，创建一个 generate 规则，将名为 steven 的测试用户与新命名空间的 admin ClusterRole 相绑定。此规则中名为 admin 的内置 ClusterRole 必须与之前 ClusterRoleBinding 中授予 Kyverno ServiceAccount 的 ClusterRole 匹配。
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: steven-rolebinding
spec:
rules:
- name: steven-rolebinding
match:
any:
- resources:
kinds:
- Namespace
generate:
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
name: steven-rolebinding
namespace: "{{request.object.metadata.name}}"
data:
subjects:
- kind: User
name: steven
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: admin
apiGroup: rbac.authorization.k8s.io
新创建命名空间时，Kyverno 会生成一个名为 steven-rolebinding 的 RoleBinding，并授予用户 steven 上述新命名空间的 admin ClusterRole。
生成 NetworkPolicy
在此示例中，新命名空间将接收到一个拒绝所有入站和出站流量的 NetworkPolicy。与第一个示例类似，generate.data 对象用于将 NetworkPolicy 资源的规范定义为覆盖模式。
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: default
spec:
rules:
- name: deny-all-traffic
match:
any:
- resources:
kinds:
- Namespace
exclude:
any:
- resources:
namespaces:
- kube-system
- default
- kube-public
- kyverno
generate:
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
name: deny-all-traffic
namespace: "{{request.object.metadata.name}}"
data:
spec:
# select all pods in the namespace
podSelector: {}
policyTypes:
- Ingress
- Egress
将资源与 ownerReferences 连接
在某些情况下，触发（源）资源和衍生（下游）资源需要共享相同的生命周期。也就是说，当触发资源被删除时，衍生资源也应该被删除。这样做是有价值的，因为某些资源只有在另一个资源存在时才需要，例如 LoadBalancer 类型的服务需要在某些 CNI 插件中使用特定的网络策略。虽然 Kyverno 不会在内部处理此任务，但 Kubernetes 可以通过在衍生资源中设置 ownerReferences 字段。对于下面的示例，当衍生的 ConfigMap 指定了 metadata.ownerReferences[] 对象，并定义了如下字段，包括引用触发的 Service 资源的 uid 时，就形成了所有者依赖关系。稍后，如果 Service 被删除，ConfigMap 也会被删除。有关更多详细信息，请参阅 Kubernetes 文档，包括有关这些参考范围的重要警告。命名空间级别资源不能是集群级别资源的所有者，也不允许跨命名空间引用。
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: demo-ownerref
spec:
background: false
rules:
- name: demo-ownerref-svc-cm
match:
any:
- resources:
kinds:
- Service
generate:
kind: ConfigMap
apiVersion: v1
name: "{{request.object.metadata.name}}-gen-cm"
namespace: "{{request.namespace}}"
synchronize: false
data:
metadata:
ownerReferences:
- apiVersion: v1
kind: Service
name: "{{request.object.metadata.name}}"
uid: "{{request.object.metadata.uid}}"
data:
foo: bar
为现有资源生成衍生资源
在 Kyverno 1.7.0+ 中，Kyverno 支持为现有资源生成衍生资源。为现有资源生成衍生资源的策略在后台应用，根据策略中的匹配语句创建目标资源。它们也可以选择配置为在更新策略本身时应用。
在现有命名空间中生成 NetworkPolicy
默认情况下，安装时不会将策略应用于现有触发器资源。可以通过 generateExistingOnPolicyUpdate 属性配置该行为。只有 generateExistingOnPolicyUpdate 设置为 true 时，Kyverno 会在收到策略的 CREATE 和 UPDATE 事件时，为现有的触发器生成目标衍生资源。
在这个示例中，触发器资源是 Namespace 类型，将会为所有新建或已存在的 Namespace 生成一个新的 NetworkPolicy。
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: generate-resources
spec:
generateExistingOnPolicyUpdate: true
rules:
- name: generate-existing-networkpolicy
match:
any:
- resources:
kinds:
- Namespace
generate:
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
name: default-deny
namespace: "{{request.object.metadata.name}}"
synchronize: true
data:
metadata:
labels:
created-by: kyverno
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
为现有的 Deployment 生成 PodDisruptionBudget
下面这个策略会给已存在的或新建的 deployment 创建一个 PodDisruptionBudget 资源。
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: create-default-pdb
spec:
generateExistingOnPolicyUpdate: true
rules:
- name: create-default-pdb
match:
any:
- resources:
kinds:
- Deployment
exclude:
resources:
namespaces:
- local-path-storage
generate:
apiVersion: policy/v1
kind: PodDisruptionBudget
name: "{{request.object.metadata.name}}-default-pdb"
namespace: "{{request.object.metadata.namespace}}"
synchronize: true
data:
spec:
minAvailable: 1
selector:
matchLabels:
"{{request.object.metadata.labels}}"
故障排查
要对策略应用程序故障进行故障排查，请检查 UpdateRequest 自定义资源以获取详细信息。
例如，如果未授予 Kyverno 相应的权限，您应该在 updaterequest.status 中看到此错误：
$ kubectl get ur -n kyverno
NAME POLICY RULETYPE RESOURCEKIND RESOURCENAME RESOURCENAMESPACE STATUS AGE
ur-7gtbx create-default-pdb generate Deployment nginx-deployment test Failed 2s
$ kubectl describe ur ur-7gtbx -n kyverno
Name: ur-7gtbx
Namespace: kyverno
...
status:
message: 'poddisruptionbudgets.policy is forbidden: User "system:serviceaccount:kyverno:kyverno-service-account"
cannot create resource "poddisruptionbudgets" in API group "policy" in the namespace "test"'
state: Failed