KCA 模拟考 A
策略和集群策略有什么区别?
- Policy只能使用validate,而ClusterPolicy可以使用up来mutate。
- 策略不支持后台扫描
- ClusterPolicy 不适用于命名空间资源
- Policy仅适用于其所属的命名空间,而ClusterPolicy适用于整个集群。
Kyverno 注册准入 webhooks 的正确方法是什么?
- 根据策略内容创建用于验证和修改的Webhook设置,并将目标缩小到仅必要的资源。
- 始终为每个资源注册一个固定的 Webhook
- 控制器定期轮询而不使用 webhook
- 直接编辑并注册API服务器配置文件。
Kyverno 规则中的比赛块有什么作用?
- 定义一条消息,在违反规则时向用户显示
- 选择策略将应用到的集群
- 确定将评估此规则的资源范围
- 指定多个规则的执行顺序
容器镜像中的标签和摘要有什么区别?
- 标签始终是不可变的,并且摘要可以在每次重建时更新。
- 标签稍后可以更改为指向不同的图像,但摘要是根据内容计算的并且不会更改。
- 两者都是由注册表随机分配的标识符。
- 摘要因注册表而异,并且不可移植。
关于 Kyverno 规则,以下哪一项是正确的?
- 您可以将 validate 和 mutate 放在一条规则中并按顺序执行它们
- 规则名称是可选的,可以省略
- 一条规则只有一个动作,如果需要多个动作,则规则被拆分
- 规则只能在 ClusterPolicy 中定义
Kyverno 将策略评估结果留在集群中的正确方式是什么?
- 只需将其保留为事件,而不创建单独的对象。
- 将结果记录在命名空间范围和集群范围的策略报告资源中。
- 违规行为会累积并存储在 ConfigMap 中。
- 仅写入审核日志文件,无法使用 kubectl 查看
Kyverno 的清理控制器有什么作用?
- 从策略报告中清除旧条目
- 删除失败的 Webhook 设置
- 清理已终止 Pod 的日志
- 符合条件的资源将按照设定的时间表进行删除。
当请求到达 Kyverno Webhook 时,哪些步骤已经完成?
- 用户认证和RBAC授权审核
- 将对象保存在etcd中
- 调度程序将节点分配给 Pod。
- kubelet 负责启动容器。
将策略表达为 Kubernetes 资源而不是单独的语言有什么好处?
- 始终可以在没有 API 服务器的情况下评估策略
- 您可以使用现有的 kubectl、RBAC 和 GitOps 流来处理策略。
- 政策评估总是更快
- 策略可以作为二进制文件进行编译和分发
有一个针对 Deployment 的策略,但我创建的 Pod 没有被阻止。最合适的原因是什么?
- Kyverno 无法定位 Deployment
- Webhook 超时很短,请求已通过。
- 该策略设置为审核模式
- 您自己创建的 Pod 不经过 Deployment,因此 Pod 也必须包含在目标中。
为什么安装过程中默认排除像 kube-system 这样的命名空间?
- 因为该命名空间中没有需要检查的 pod。
- 这是为了减少政策报告的大小。
- 这是为了避免出现集群核心组件由于 webhooks 无法启动的情况。
- 这是因为命名空间已经受到 RBAC 的充分保护。
使用 Helm 安装 Kyverno 时如何处理自定义资源定义?
- 图表是一起安装的,升级时必须单独检查定义更新是否已正确反映。
- 控制器在启动时自行生成。
- 内置于 Kubernetes 中,无需安装
- 当您创建第一个策略时自动创建
在高可用性配置中安装 Kyverno 时有哪些建议?
- 放置三个或更多控制器副本并应用放置规则将它们分布在节点上。
- 保留一个副本并手动移动它,以防节点发生故障
- 将所有控制器聚集在同一节点上以减少延迟
- 通过将 Webhook 失败策略更改为忽略来确保可用性
增加策略后,准入控制器会反复重启。首先要调整什么?
- 将所有策略的失败行为更改为审核模式
- 将 webhook 超时增加到最大值
- 提高控制器的内存请求和上限并检查缓存相关设置
- 增加集群中的节点数量
我正在尝试使用生成规则创建自定义资源。授予权力的正确方式是什么?
- 如果您在策略中写入服务帐户名称,它将自动拥有必要的权限。
- 您所要做的就是向您的 Kyverno pod 授予超级管理员权限。
- 将管理员 kubeconfig 设置为机密
- 通过创建参与角色聚合的 ClusterRole 添加必要的资源权限。
以下哪项是在部署时更改 Kyverno 控制器行为的正确方法?
- 记下策略资源规范中的控制器设置。
- 使用作为容器参数传递的标志和 Kyverno 配置 ConfigMap。
- 修改API服务器中的准入插件列表
- 将默认值放入自定义资源定义的架构中
我正在尝试跳过 Kyverno 的几个小版本。推荐的方法是什么?
- 仅指定最新的图表版本并立即上传。
- 如果删除现有安装并安装新安装,该策略将保持原样。
- 检查发行说明中的支持路径并逐步反映定义更改。
- 只需更改控制器映像标签并重新启动即可。
安装 Kyverno 后,某些工作负载创建立即失败。最可能的原因是什么?
- Webhook 已注册,但请求被拒绝,因为控制器尚未准备好。
- 由于未安装自定义资源定义,Pod 创建被阻止
- 政策报告资源已满
- 版本名称不符合命名约定
关于 Kyverno webhooks 使用的 TLS 证书,以下哪一项是正确的?
- 只有管理员直接发布并保密的情况下它才有效。
- 默认情况下是自我管理的,到期前续订,如果需要可以替换为外部颁发的证书。
- 无需证书即可以纯文本方式进行通信
- 服务帐户令牌替换证书
如何从集群范围内的所有策略目标中排除特定命名空间?
- 唯一的方法是为每个策略添加一个排除块。
- 标记该命名空间将自动排除它
- 通过手动编辑来排除 Webhook 设置对象。
- 将命名空间添加到 Kyverno 设置 ConfigMap 中的资源过滤器
为什么由多个副本启动的后台控制器不会一遍又一遍地执行相同的任务?
- 这是因为负责的命名空间是自动为每个副本划分的。
- 这是因为任务是幂等的,因此即使重复执行,结果也会相同。
- 这是因为由于领导者选举,只有一个实例负责实际处理。
- 这是因为 API 服务器会过滤掉重复的请求。
卸载Kyverno时需要注意什么?
- 请务必检查清理顺序,因为任何剩余的 Webhook 设置和定义可能会继续阻止请求或留下策略对象。
- 一旦删除它,集群中的所有 Pod 都会重新创建
- 即使取消后,现有政策仍将继续执行
- 如果删除,通过 mutate 改变的值将恢复到原来的状态。
安装 Kyverno CLI 的正确方法是什么?
- 将 CLI Pod 部署到您的集群并进入并运行它
- 如果您重命名 kubectl 插件,它将自动激活
- 如果您安装 Helm Chart,二进制文件也将放置在本地。
- 从发行版下载二进制文件或使用包管理器安装它并将其放置在可执行路径中。
kyverno apply命令的正确性质是什么?
- 通过将策略注册到集群来立即执行策略
- 在本地评估策略和资源,输出通过或失败,并且不更改集群。
- 更改集群中的现有资源以匹配策略
- 为您的集群生成策略报告
kyverno test与kyverno apply有何不同?
- 测试仅在连接到集群时有效
- test 读取包含预期结果的文件,并将其与实际结果进行比较,以确定是否通过。
- 测试只能处理变异策略
- test 只执行策略语法检查
什么情况下需要使用kyverno jp子命令?
- 这是您想要在将策略应用到集群之前签署策略的情况。
- 这是当您想要以表格形式打印策略报告时。
- 尝试验证自定义资源定义的架构时
- 这是当您想要提前检查策略中写入的表达式将给出什么值时。
检查失败,因为 CLI 评估未找到策略引用的值。怎么解决呢?
- 将包含变量值的文件传递给 CLI 以用于评估。
- 划分策略,以便仅跳过那些规则进行检查
- 放弃CLI并通过将其应用到集群来进行检查。
- 将策略中的所有变量引用替换为常量
使用kyverno apply作为持续积分门时如何判断失败?
- 检查输出字符串中是否有单词 failure
- 如果命令执行时间过长,则认为失败。
- 检查命令的退出代码,如有必要,将结果保存到文件中并一起检查它们。
- 检查集群的策略报告
哪些策略很难单独使用 Kyverno CLI 来完全验证?
- 这是实时检查并确定集群中其他资源的规则。
- 该规则仅检查标签是否存在。
- 检查容器镜像前缀的规则
- 需要资源上限的规则
如何仅将策略应用于带标签的命名空间?
- 将命名空间添加到匹配类型列表中。
- 为每个命名空间创建单独的策略。
- 通过在匹配的资源条件中添加命名空间选择器来选择标签。
- 列出排除中所有剩余的命名空间
match 中的any 和all 有什么区别?
- any 需要满足所有条件,all 只需要满足一个条件。
- Any 表示必须满足所列条件中的任何一个,all 表示所有条件都必须为真。
- any 只能用于集群资源,all 只能用于命名空间资源。
- 两者具有相同的含义,为了便于阅读而将其分开。
如何使用新策略评估集群中已存在的资源?
- 所有资源都必须重新创建
- 如果将策略更改为强制模式,还将自动评估现有资源。
- 您需要重新注册您的 webhook 设置
- 必须打开后台扫描,并且可以在策略报告中查看结果
应用该策略后,现有工作负载保持不变,但仅阻止新创建的工作负载。如何解释这种行为?
- 该政策写得不正确,并且仅部分有效。
- 由于 webhook 超时,仅检查了部分请求
- 这是因为后台扫描仅处理新资源。
- 这是正常行为,因为准入检查仅适用于新请求,并且现有资源仅在报告中显示。
如果将可设置为匹配的条件移至前提条件会怎样?
- 这是因为 match 不支持标签条件。
- 这是当无法表示为匹配的条件(例如资源内的字段值)必须被评估为变量时。
- 这是因为先决条件总是评估得更快。
- 这是因为每条规则只能使用一个匹配项。
该策略不适用于修改请求,仅适用于创建请求。去哪里检查?
- 这是策略的失败行为设置。
- Webhook 失败策略设置
- match 中指定的请求操作列表
- 是否启用后台扫描
哪些 Pod 通过以下规则?```yaml validate: message: 메모리 상한을 지정해야 합니다 pattern: spec: containers: - resources: limits: memory: "?*"
- 为所有容器分配非空内存限制的 pod
- 仅第一个容器具有内存上限的 Pod
- 只指定内存请求并省略上限的 Pod。
- 容器列表本身是一个空的 pod
括号中字段名称周围的条件锚在模式中意味着什么?
- 该字段必须存在并且值必须匹配
- 仅当条件为真时才在同一块中应用其余检查,否则跳过该项目
- 从扫描中完全排除该字段
- 将该字段的值替换为指定值。
什么时候使用拒绝和条件表达式而不是模式更好?
- 是时候比较或计算多个字段值来做出决定了。
- 当你只需要检查该字段是否存在时
- 是时候要求数组的所有元素具有相同的形状了
- 仅检查某些字符串前缀时
保单中的`{{ request.object.metadata.labels.team }}`指的是什么?
- 这是创建策略时的固定字符串。
- 这是集群中存在的所有团队标签的列表。
- 这是写入 Kyverno 设置 ConfigMap 中的值。
- 这是附加到正在审查请求的资源的团队标签值。
如何从 ConfigMap 获取策略将用于决策的值?
- 在消息字段中写入 ConfigMap 名称
- 在与策略相同的文件中一起定义 ConfigMap。
- 在规则上下文中声明 ConfigMap 引用并将其作为变量引用。
- 将 ConfigMap 作为卷安装在 Kyverno 控制器上
下面的 mutate 规则有什么作用?```yaml
mutate:
patchStrategicMerge:
metadata:
labels:
+(team): unassigned
- 始终用未分配的内容覆盖团队标签
- 如果团队标签已存在,则跳过整个规则。
- 仅当没有团队标签时添加未分配。
- 删除团队标签
我正在尝试将多个容器的图像前缀更改为我的内部注册表。什么是合适的方法呢?
- 战略合并补丁仅替换第一个容器
- 使用生成规则创建一个新的 Pod
- 使用清理策略清除现有的 Pod
- 使用 foreach 遍历容器列表并替换每个图像值。
我们希望为每个新命名空间创建一个默认的 NetworkPolicy。什么是正确的规则类型以及适合谁?
- 编写针对名称空间创建的生成规则
- 编写针对 Pod 创建的 mutate 规则
- 编写针对 NetworkPolicy 创建的验证规则
- 编写针对命名空间创建的 verifyImages 规则
如果我使用源复制而不是直接在生成规则中指定数据会怎样?
- 当要创建的资源是集群范围时
- 这是当您想要复制和分发您已经管理的原始资源时的情况。
- 当创建目标是自定义资源时
- 这是您想要将生成的结果保留在策略报告中的情况。
当 verifyImages 规则失败时,默认情况下会发生什么?
- 该请求被拒绝并且 Pod 未创建
- 图像会自动替换为旧版本
- Pod 已正常创建,仅出现警告。
- 图像被复制到您的内部注册表
为什么为 Pod 编写的策略也适用于通过 Deployment 创建的 Pod?
- 这是因为部署控制器重新评估策略。
- 这是因为后台扫描稍后会检查创建的 Pod。
- 这是因为 webhooks 无条件拦截所有资源。
- 这是因为 Kyverno 会自动创建适合控制器类型的规则,并将它们应用到父资源。
如何控制自动生成的规则的创建目的?
- 将规则重命名为给定前缀
- 直接在 match 的类型列表中列出父资源
- 注释策略以指定自动生成的目标控制器。
- 重新启动 Kyverno 控制器
我正在尝试组织已经在一定时间内完成的工作。如何使用 Kyverno 做到这一点?
- 通过验证规则防止创建旧作业
- 在清理政策中写下目标条件和时间表,并定期删除。
- 创建一个使用生成规则执行删除的作业
- 使用 mutate 规则清除作业的所有者引用。
能够在 Kyverno 策略中使用 CEL 表达式有哪些好处?
- 现在可以用 JavaScript 编写策略
- 即使没有集群,策略也会始终被评估
- 评估结果被缓存,无需网络钩子
- 可以使用类似于 Kubernetes 内置验证策略的表达式语法来简洁地编写条件。
JSON patch中添加带斜杠的label key需要注意什么?
- 如果密钥包含点,则该补丁无法使用
- 只需在路径中写入斜杠即可。
- 键中包含的斜杠必须替换为指定的转义符号。
- 路径必须全部用大写字母书写。
如何在验证失败消息中包含违规资源的名称?
- 提前记下消息中的资源名称
- 通过在消息字符串中放置变量引用来填写要筛选的主题的名称。
- 这是不可能的,因为消息仅支持固定字符串
- 您只能在政策报告中看到名称
如果您尝试在后台扫描中使用引用请求者信息的规则,会出现什么问题?
- 应从扫描中排除该规则,因为扫描没有发送填充值的请求的用户信息。
- 扫描始终使用管理员帐户进行评估,因此所有资源都会通过
- 扫描通过从审核日志中读取用户信息来填充用户信息
- 该保单根本未注册并被拒绝
以下规则的正确行为是什么?```yaml validate: message: 볼륨은 다섯 개까지만 허용합니다 deny: conditions: all: - key: "{{ request.object.spec.volumes[] | length(@) }}" operator: GreaterThan value: 5
- 当卷数或更少时拒绝请求
- 超过六卷时拒绝请求
- 无论数量多少,始终拒绝请求
- 删除除五卷之外的所有内容
关于以下规则的哪项表述是正确的?```yaml
preconditions:
all:
- key: "{{ request.operation }}"
operator: Equals
value: CREATE
mutate:
patchStrategicMerge:
metadata:
annotations:
created-by: "{{ request.userInfo.username }}"
- 注释每个请求
- 仅注释修改请求
- 仅在创建请求上注释请求者名称。
- 如果注解值为空,则拒绝请求
检查命名空间范围的策略报告的正确方法是什么?
- 使用
kubectl get policyreport -n prod检查命名空间的结果。 - 您所要做的就是阅读控制器日志以找到违规行
- 检查 Kyverno 设置 ConfigMap。
- 通过查询 webhook 设置对象进行检查。
集群范围资源的政策评估结果记录在哪里?
- 它与报告一起记录在默认命名空间中。
- 记录在每个资源的注释中
- 它仅保留在控制器的内存中
- 集群范围的策略写入报告资源
PolicyException 对象实际上做了什么?
- 只有指定用于特定政策和规则的资源才可以免于评估
- 暂时禁用整个策略
- 隐藏报告中的违规结果,但保持执法完整
- 自动纠正并通过违规资源
安全运行异常的适当设置是什么?
- 让异常对象可以在任何命名空间中自由创建
- 限制可以创建异常的命名空间,并对其及其到期日期和所有者进行管理。
- 将策略更改为审核模式而不是例外
- 动态修改规则而不使用例外
我应该寻找什么来获得我的策略实际上阻止请求的指示?
- 控制器 Pod 的 CPU 使用率
- 集群中注册的策略对象数量
- webhook证书剩余有效期
- 这是一个将规则执行结果分为通过和失败的计数器以及准入请求指示器。
当政策报告在大型集群中变得太大时,适当的响应是什么?
- 关闭后台扫描并删除所有现有报告
- 将报告导出到文件并删除关联的定义
- 使用过滤器缩小扫描目标资源并调整频率以减少生成
- 将所有政策更改为强制模式以消除违规行为