商业网站建设政策支持,网页制作和网站建设的区别,游戏开发大亨高分攻略,百度收录不到公司网站#作者#xff1a;程宏斌 文章目录 动态准入控制什么是准入 Webhook#xff1f; 尝试准入Webhook先决条件编写一个准入 Webhook 服务器部署准入 Webhook 服务即时配置准入 Webhook对 API 服务器进行身份认证 Webhook 请求与响应Webhook 配置匹配请求-规则匹配请求#xff1a…#作者程宏斌 文章目录 动态准入控制什么是准入 Webhook 尝试准入Webhook先决条件编写一个准入 Webhook 服务器部署准入 Webhook 服务即时配置准入 Webhook对 API 服务器进行身份认证 Webhook 请求与响应Webhook 配置匹配请求-规则匹配请求objectSelector匹配请求namespaceSelector匹配请求matchPolicy匹配请求matchConditions 调用Webhook服务引用副作用超时再调用策略失败策略 动态准入控制
什么是准入 Webhook
准入 Webhook 是一种用于接收准入请求并对其进行处理的 HTTP 回调机制。 可以定义两种类型的准入 Webhook 即验证性质的准入 Webhook 和变更性质的准入 Webhook。 变更性质的准入 Webhook 会先被调用。它们可以修改发送到 API 服务器的对象以执行自定义的设置默认值操作。 在完成了所有对象修改并且 API 服务器也验证了所传入的对象之后 验证性质的 Webhook 会被调用并通过拒绝请求的方式来强制实施自定义的策略。 说明 如果准入 Webhook 需要保证它们所看到的是对象的最终状态以实施某种策略。 则应使用验证性质的准入 Webhook因为对象被修改性质 Webhook 看到之后仍然可能被修改。
尝试准入Webhook
准入 Webhook 本质上是集群控制平面的一部分。你应该非常谨慎地编写和部署它们。 如果你打算编写或者部署生产级准入 Webhook 请阅读用户指南以获取相关说明。 在下文中我们将介绍如何快速试验准入 Webhook。
先决条件
确保启用 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 控制器。 这里是一组推荐的准入控制器 通常可以启用。确保启用了 admissionregistration.k8s.io/v1 API。
编写一个准入 Webhook 服务器
请参阅 Kubernetes e2e 测试中的 Admission Webhook 服务器的实现。 Webhook 处理由 API 服务器发送的 AdmissionReview 请求并且将其决定作为 AdmissionReview 对象以相同版本发送回去。 有关发送到 Webhook 的数据的详细信息请参阅 Webhook 请求。 要获取来自 Webhook 的预期数据请参阅 Webhook 响应。
示例准入 Webhook 服务器置 ClientAuth 字段为空 默认为 NoClientCert 。这意味着 Webhook 服务器不会验证客户端的身份认为其是 API 服务器。 如果你需要双向 TLS 或其他方式来验证客户端 请参阅如何对 API 服务器进行身份认证。
部署准入 Webhook 服务
e2e 测试中的 Webhook 服务器通过 deployment API 部署在 Kubernetes 集群中。该测试还将创建一个 Service 作为 Webhook 服务器的前端。 参见相关代码。 你也可以在集群外部署 Webhook。这样做需要相应地更新你的 Webhook 配置。
即时配置准入 Webhook
你可以通过 ValidatingWebhookConfiguration 或者 MutatingWebhookConfiguration 动态配置哪些资源要被哪些准入 Webhook 处理。
对 API 服务器进行身份认证
如果你的 Webhook 需要身份验证则可以将 API 服务器配置为使用基本身份验证、持有者令牌或证书来向 Webhook 提供身份证明。完成此配置需要三个步骤。 启动 API 服务器时通过 --admission-control-config-file 参数指定准入控制配置文件的位置。
在准入控制配置文件中指定 MutatingAdmissionWebhook 控制器和 ValidatingAdmissionWebhook 控制器应该读取凭据的位置。 凭证存储在 kubeConfig 文件中是的与 kubectl 使用的模式相同因此字段名称为 kubeConfigFile。
Webhook 请求与响应
请求 Webhook 发送 POST 请求时请设置 Content-Type: application/json 并对 admission.k8s.io API 组中的 AdmissionReview 对象进行序列化将所得到的 JSON 作为请求的主体。 Webhook 可以在配置中的 admissionReviewVersions 字段指定可接受的 AdmissionReview 对象版本
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
webhooks:
- name: my-webhook.example.com
admissionReviewVersions: [v1, v1beta1]创建 Webhook 配置时admissionReviewVersions 是必填字段。 Webhook 必须支持至少一个当前和以前的 API 服务器都可以解析的 AdmissionReview 版本。 API 服务器将发送的是 admissionReviewVersions 列表中所支持的第一个 AdmissionReview 版本。 如果 API 服务器不支持列表中的任何版本则不允许创建配置。
如果 API 服务器遇到以前创建的 Webhook 配置并且不支持该 API 服务器知道如何发送的任何 AdmissionReview 版本则调用 Webhook 的尝试将失败并依据失败策略进行处理。
响应 Webhook 使用 HTTP 200 状态码、Content-Type: application/json 和一个包含 AdmissionReview 对象的 JSON 序列化格式来发送响应。该 AdmissionReview 对象与发送的版本相同且其中包含的 response 字段已被有效填充。
response 至少必须包含以下字段
uid从发送到 Webhook 的 request.uid 中复制而来allowed设置为 true 或 false
Webhook 配置
要注册准入 Webhook请创建 MutatingWebhookConfiguration 或 ValidatingWebhookConfiguration API 对象。 MutatingWebhookConfiguration 或ValidatingWebhookConfiguration 对象的名称必须是有效的 DNS 子域名。 每种配置可以包含一个或多个 Webhook。如果在单个配置中指定了多个 Webhook则应为每个 Webhook 赋予一个唯一的名称。 这是必需的以使生成的审计日志和指标更易于与激活的配置相匹配。 每个 Webhook 定义以下内容。
匹配请求-规则
每个 Webhook 必须指定用于确定是否应将对 apiserver 的请求发送到 Webhook 的规则列表。 每个规则都指定一个或多个 operations、apiGroups、apiVersions 和 resources 以及资源的 scope
operations 列出一个或多个要匹配的操作。 可以是 CREATE、UPDATE、DELETE、CONNECT 或 * 以匹配所有内容。apiGroups 列出了一个或多个要匹配的 API 组。“” 是核心 API 组。“*” 匹配所有 API 组。apiVersions 列出了一个或多个要匹配的 API 版本。“*” 匹配所有 API 版本。resources 列出了一个或多个要匹配的资源。 “*” 匹配所有资源但不包括子资源。“/” 匹配所有资源包括子资源。“pods/*” 匹配 pod 的所有子资源。“*/status” 匹配所有 status 子资源。 scope 指定要匹配的范围。有效值为 “Cluster”、“Namespaced” 和 “。 子资源匹配其父资源的范围。默认值为 ”。 “Cluster” 表示只有集群作用域的资源才能匹配此规则API 对象 Namespace 是集群作用域的。“Namespaced” 意味着仅具有名字空间的资源才符合此规则。“*” 表示没有作用域限制。
如果传入请求与任何 Webhook rules 的指定 operations、groups、versions、 resources 和 scope 匹配则该请求将发送到 Webhook。 以下是可用于指定应拦截哪些资源的规则的其他示例。
匹配请求objectSelector
通过指定 objectSelectorWebhook 能够根据可能发送的对象的标签来限制哪些请求被拦截。 如果指定则将对 objectSelector 和可能发送到 Webhook 的 object 和 oldObject 进行评估。如果两个对象之一与选择算符匹配则认为该请求已匹配。 空对象对于创建操作而言为 oldObject对于删除操作而言为 newObject 或不能带标签的对象例如 DeploymentRollback 或 PodProxyOptions 对象 被认为不匹配。 仅当选择使用 Webhook 时才使用对象选择器因为最终用户可以通过设置标签来 跳过准入 Webhook。
匹配请求namespaceSelector
通过指定 namespaceSelector Webhook 可以根据具有名字空间的资源所处的名字空间的标签来选择拦截哪些资源的操作。 namespaceSelector 根据名字空间的标签是否匹配选择算符决定是否针对具名字空间的资源 或 Namespace 对象的请求运行 Webhook。 如果对象是除 Namespace 以外的集群范围的资源则 namespaceSelector 标签无效。
匹配请求matchPolicy
API 服务器可以通过多个 API 组或版本来提供对象。 例如如果一个 Webhook 仅为某些 API 组/版本指定了规则例如 apiGroups:[“apps”], apiVersions:[“v1”,“v1beta1”]而修改资源的请求是通过另一个 API 组/版本例如 extensions/v1beta1发出的该请求将不会被发送到 Webhook。 matchPolicy 允许 Webhook 定义如何使用其 rules 匹配传入的请求。 允许的值为 Exact 或 Equivalent。
Exact 表示仅当请求与指定规则完全匹配时才应拦截该请求。Equivalent 表示如果某个请求意在修改 rules 中列出的资源 即使该请求是通过其他 API 组或版本发起也应拦截该请求。 在上面给出的示例中仅为 apps/v1 注册的 Webhook 可以使用 matchPolicymatchPolicy: Exact 表示不会将 extensions/v1beta1 请求发送到 WebhookmatchPolicy:Equivalent 表示将 extensions/v1beta1 请求发送到 Webhook 将对象转换为 Webhook 指定的版本apps/v1
建议指定 Equivalent确保升级后启用 API 服务器中资源的新版本时 Webhook 继续拦截他们期望的资源。
当 API 服务器停止提供某资源时该资源不再被视为等同于该资源的其他仍在提供服务的版本。 例如extensions/v1beta1 中的 Deployment 已被废弃计划在 v1.16 中移除。
移除后带有 apiGroups:[“extensions”], apiVersions:[“v1beta1”], resources: [“deployments”] 规则的 Webhook 将不再拦截通过 apps/v1 API 来创建的 Deployment。 因此Webhook 应该优先注册稳定版本的资源。
匹配请求matchConditions
特性状态 Kubernetes v1.30 [stable] (enabled by default: true) 如果你需要细粒度地过滤请求你可以为 Webhook 定义匹配条件。 如果你发现匹配规则、objectSelectors 和 namespaceSelectors 仍然不能提供你想要的何时进行 HTTP 调用的过滤条件那么添加这些条件会很有用。 匹配条件是 CEL 表达式。 所有匹配条件都必须为 true 才能调用 Webhook。
匹配条件可以访问以下 CEL 变量
object - 来自传入请求的对象。对于 DELETE 请求该值为 null。 该对象版本可能根据 matchPolicy 进行转换。oldObject - 现有对象。对于 CREATE 请求该值为 null。request - AdmissionReview 的请求部分不包括 object 和 oldObject。authorizer - 一个 CEL 鉴权组件。可用于对请求的主体经过身份认证的用户执行鉴权检查。 更多详细信息请参阅 Kubernetes CEL 库文档中的 Authz。authorizer.requestResource - 对配置的请求资源组、资源、子资源、名字空间、名称进行授权检查的快捷方式。
调用Webhook
API 服务器确定请求应发送到 Webhook 后它需要知道如何调用 Webhook。 此信息在 Webhook 配置的 clientConfig 节中指定。 Webhook 可以通过 URL 或服务引用来调用并且可以选择包含自定义 CA 包以用于验证 TLS 连接。
URL url 以标准 URL 形式给出 Webhook 的位置scheme://host:port/path。
host 不应引用集群中运行的服务通过指定 service 字段来使用服务引用。 主机可以通过某些 API 服务器中的外部 DNS 进行解析。 例如kube-apiserver 无法解析集群内 DNS因为这将违反分层规则。host 也可以是 IP 地址。
请注意将 localhost 或 127.0.0.1 用作 host 是有风险的 除非你非常小心地在所有运行 apiserver 的、可能需要对此 Webhook 进行调用的主机上运行。这样的安装方式可能不具有可移植性即很难在新集群中启用。 scheme 必须为 “https”URL 必须以 “https://” 开头。 使用用户或基本身份验证例如user:password是不允许的。 使用片段#…和查询参数?..也是不允许的。
服务引用
clientConfig 内部的 Service 是对该 Webhook 服务的引用。 如果 Webhook 在集群中运行则应使用 service 而不是 url。 服务的 namespace 和 name 是必需的。 port 是可选的默认值为 443。path 是可选的默认为 “/”。
副作用
Webhook 通常仅对发送给他们的 AdmissionReview 内容进行操作。 但是某些 Webhook 在处理 admission 请求时会进行带外更改。
进行带外更改的产生“副作用”的Webhook 必须具有协调机制如控制器 该机制定期确定事物的实际状态并调整由准入 Webhook 修改的带外数据以反映现实情况。 这是因为对准入 Webhook 的调用不能保证所准入的对象将原样保留或根本不保留。 以后Webhook 可以修改对象的内容在写入存储时可能会发生冲突 或者服务器可以在持久保存对象之前关闭电源。
此外处理 dryRun: true admission 请求时具有副作用的 Webhook 必须避免产生副作用。 一个 Webhook 必须明确指出在使用 dryRun 运行时不会有副作用 否则 dry-run 请求将不会发送到该 Webhook而 API 请求将会失败。 Webhook 使用 Webhook 配置中的 sideEffects 字段显示它们是否有副作用
None调用 Webhook 没有副作用。NoneOnDryRun调用 Webhook 可能会有副作用但是如果将带有 dryRun: true 属性的请求发送到 Webhook则 Webhook 将抑制副作用该 Webhook 可识别 dryRun。
超时
由于 Webhook 会增加 API 请求的延迟因此应尽快完成自身的操作。 timeoutSeconds 用来配置在将调用视为失败之前允许 API 服务器等待 Webhook 响应的时间长度。 如果超时在 Webhook 响应之前被触发则基于失败策略将忽略 Webhook 调用或拒绝 API 调用。 超时值必须设置在 1 到 30 秒之间。
再调用策略
变更性质的准入插件包括 Webhook的任何一种排序方式都不会适用于所有情况。 (参见 https://issue.k8s.io/64333 示例)。 变更性质的 Webhook 可以向对象中添加新的子结构例如向 pod 中添加 container 已经运行的其他修改插件可能会对这些新结构有影响 就像在所有容器上设置 imagePullPolicy 一样。 要允许变更性质的准入插件感应到其他插件所做的更改 如果变更性质的 Webhook 修改了一个对象则会重新运行内置的变更性质的准入插件 并且变更性质的 Webhook 可以指定 reinvocationPolicy 来控制是否也重新调用它们。 可以将 reinvocationPolicy 设置为 Never 或 IfNeeded。 默认为 Never。
Never: 在一次准入测试中不得多次调用 Webhook。IfNeeded: 如果在最初的 Webhook 调用之后被其他对象的插件修改了被接纳的对象 则可以作为准入测试的一部分再次调用该 Webhook。 要注意的重要因素有不能保证附加调用的次数恰好是一。如果其他调用导致对该对象的进一步修改则不能保证再次调用 Webhook。使用此选项的 Webhook 可能会重新排序以最大程度地减少额外调用的次数。要在确保所有修改都完成后验证对象请改用验证性质的 Webhook 推荐用于有副作用的 Webhook。
失败策略
failurePolicy 定义了如何处理准入 Webhook 中无法识别的错误和超时错误。允许的值为 Ignore 或 Fail。
Ignore 表示调用 Webhook 的错误将被忽略并且允许 API 请求继续。Fail 表示调用 Webhook 的错误导致准入失败并且 API 请求被拒绝。
