LabHub
学习 学习路径 课程

KCA — Kyverno 认证助理

Webhook 故障实验：Fail、Ignore 与恢复

在 LabHub 中继续学习

目标

仅停止保留注册的Webhook的响应，并通过实际请求比较Fail·Ignore的差异。分别确认正常服务器明确拒绝、故障期间超时·存储、范围外对照组、恢复。

为什么重要

用失败这个词把政策的明确拒绝和网页跳转调用错误捆绑在一起，就会选择错误的应对措施。 需要单独观测政策、注册、响应、已经正在执行中的Pod。两个练习分别在新的VM上 开始时不需要其他实习资料。不要在学生专用VM以外造成故障。

正常缩放使用55秒恢复监视者，响应中断使用pidfd和20秒自动重新启动计时器。 预计这次实习需要55分钟。基本课程是60分钟，如果在到期前需要的话，可以加+时间。 请延长。最多180分钟，结束时VM和文件会消失。请先下载所需资料。

所有学生文件都在/root/kca-webhook下面。每个act N的原始资料都在evidence/NN.json上 保存，内容从facts中读取。说明中出现的02.json等是这个evidence路径。 正规JSON哈希是/opt/fixtures/kca_webhook_common.py的digest(read(路径)) 与sha256sum的文件字节哈希不同。请在Python中在sys.path中添加/opt/fixtures使用。

阶段

  1. 请用inspect确认这次VM的vm.node_uid和namespaces。在scope.json中记录target=kca-webhook-target、control=kca-webhook-control、node_uid、namespaces。namespaces将实际名称作为键，UID作为值。用act 1保存这次VM的范围。
  2. 请在policy.json中写入policies.kyverno.io/v1的ValidatingPolicy。名称为kca-webhook-label，validationActions=[Deny]，failurePolicy=Fail，webhookConfiguration.timeoutSeconds=3，evaluation.background.enabled=false。matchConstraints.namespaceSelector.matchLabels为kubernetes.io/metadata.name=kca-webhook-target，resourceRules为apiGroups=[空字符串]，apiVersions=[v1]，operations=[CREATE]，resources=[pods]。validations的expression为"'environment' in object.metadata.?labels.orValue({})"，message为KCA_ENVIRONMENT_REQUIRED。请不要填写不需要的字段，然后用act 2确认实际注册。
  3. 用act 3观察有标签的Pod的保存、UID、Running和没有标签的Pod的明确拒绝、未保存。比较evidence/03.json的facts.good、bad、existing。不导入之前的练习的文件或VM。
  4. 请在freeze-plan.json中记录action=freeze-one-controller-process、实际node_uid和deployment_uid、resume_after_sec=20、signal_identity=pidfd、preserve_webhook=true、evidence_sha256=03.json的正则JSON哈希。act 4只调查CRI容器·Pod UID·PID开始时间，还没有停止。
  5. 请执行act 5。在evidence/05.json中比较注册保存、停止区间内的正常·违规请求超时和未保存、范围外对比请求保存、恢复后拒绝违规和与现有Pod UID的比较。区分明确拒绝和context deadline exceeded。
  6. 根据policy.json编写policy-ignore.json，但只将spec.failurePolicy改为Ignore。act 6在相同的政策UID上首先确认正常违规拒绝，只短暂停止响应。请在evidence/06.json中比较故障中正常·违规请求存储、恢复后拒绝、现有Pod生存情况。
  7. 请在recovery.json中放入mode=Ignore, healthy_bad=explicit-deny, existing=same-uid-running, policy_uid=02.json的facts.policy.metadata.uid, ignore_evidence_sha256=06.json的正规JSON哈希。act 7拒绝新的名称的违规请求，并确认03阶段基准Pod的相同UID·Running。
  8. 请在report.json中记录fail=matching-requests-timeout, ignore=unvalidated-request-stored, healthy_ignore=explicit-deny, control=outside-selector, existing=same-uid-running。fail_evidence_sha256, ignore_evidence_sha256, recovery_evidence_sha256分别是05·06·07.json的正规JSON哈希值。请在act 8后重新运行整个评分。

参考

命令是python3 /opt/fixtures/kca_webhook_lab.py inspect, act 1到act 8， 从grade 1到grade 8。grade是通过阅读输入和保存的实际观测，不会重现障碍。 完成act会保存资料和资源。部分输入也不会自动覆盖。 中断的执行结果不确定，请接受失败材料，并在新的练习中重现。 政策对象是CREATE pods。不要对所有API、所有安装版本、高可用性进行概括。 Kubernetes服务器dry-run

在新VM中独立的实验范围

请用inspect确认这次VM的vm.node_uid和namespaces。在scope.json中记录target=kca-webhook-target、control=kca-webhook-control、node_uid、namespaces。namespaces将实际名称作为键，UID作为值。用act 1保存这次VM的范围。

看看inspect的vm.node_uid和namespaces。名称和UID是不同的。

直接撰写Deny·Fail政策

请在policy.json中写入policies.kyverno.io/v1的ValidatingPolicy。名称为kca-webhook-label，validationActions=[Deny]，failurePolicy=Fail，webhookConfiguration.timeoutSeconds=3，evaluation.background.enabled=false。matchConstraints.namespaceSelector.matchLabels为kubernetes.io/metadata.name=kca-webhook-target，resourceRules为apiGroups=[空字符串]，apiVersions=[v1]，operations=[CREATE]，resources=[pods]。validations的expression为"'environment' in object.metadata.?labels.orValue({})"，message为KCA_ENVIRONMENT_REQUIRED。请不要填写不需要的字段，然后用act 2确认实际注册。

namespaceSelector选择namespace标签。区分验证动作Deny和调用失败处理Fail。

正常服务器允许·拒绝的基准线

用act 3观察有标签的Pod的保存、UID、Running和没有标签的Pod的明确拒绝、未保存。比较evidence/03.json的facts.good、bad、existing。不导入之前的练习的文件或VM。

这次VM的政策必须从一开始就运行，之后才能解释故障中的结果。

CRI·Pod·PID身份和自动恢复计划

请在freeze-plan.json中记录action=freeze-one-controller-process、实际node_uid和deployment_uid、resume_after_sec=20、signal_identity=pidfd、preserve_webhook=true、evidence_sha256=03.json的正则JSON哈希。act 4只调查CRI容器·Pod UID·PID开始时间，还没有停止。

只要相信PID数字，就可以停止重复使用的其他进程。在这个练习中，不会进行scale-down。

维持注册，观察Fail时间超出

请执行act 5。在evidence/05.json中比较注册保存、停止区间内的正常·违规请求超时和未保存、范围外对比请求保存、恢复后拒绝违规和与现有Pod UID的比较。区分明确拒绝和context deadline exceeded。

如果正常标签请求也受阻，可能不是因为验证式是False，而是因为无法响应呼叫。

Ignore的正常拒绝和障碍中存储

根据policy.json编写policy-ignore.json，但只将spec.failurePolicy改为Ignore。act 6在相同的政策UID上首先确认正常违规拒绝，只短暂停止响应。请在evidence/06.json中比较故障中正常·违规请求存储、恢复后拒绝、现有Pod生存情况。

Ignore不是政策禁用。必须先确认正常状态的明确拒绝，才能解释故障中的存储。

用新的请求和之前的UID重新确认恢复

请在recovery.json中放入mode=Ignore, healthy_bad=explicit-deny, existing=same-uid-running, policy_uid=02.json的facts.policy.metadata.uid, ignore_evidence_sha256=06.json的正规JSON哈希。act 7拒绝新的名称的违规请求，并确认03阶段基准Pod的相同UID·Running。

不要仅仅因为向进程发送了重新启动信号的事实就得出结论说政策响应也恢复了。

将两个障碍结果与依据联系起来的报告

请在report.json中记录fail=matching-requests-timeout, ignore=unvalidated-request-stored, healthy_ignore=explicit-deny, control=outside-selector, existing=same-uid-running。fail_evidence_sha256, ignore_evidence_sha256, recovery_evidence_sha256分别是05·06·07.json的正规JSON哈希值。请在act 8后重新运行整个评分。

请解释Fail和Ignore的区别不是正常违反判定，而是作为调用失败处理。A 没有练习的资料，仅凭这次VM观测完成。