Kubernetes编程—— 使用自定义资源 —— 自定义资源合法性验证
自定义资源合法性验证
在创建和更新 CR 时，会由 API 服务器进行合法性验证，该验证基于 CRD 定义中的 validation 字段所指定的 OpenAPI v3 Schema 进行。
当一个请求要创建或修改 CR 时，会基于这个资源定义对 JSON 格式的对象进行合法性验证，如果有问题，会给用户返回 HTTP 400，结果中包含发生冲突的字段。这种验证的目的是确保请求的 JSON 对象满足特定的规则和约束，以确保数据的完整性和一致性。
以下是一个详细的步骤说明：
- 当接收到一个创建或修改 CR 的请求时，首先会从请求的 JSON 对象中提取出相关的数据。
- 然后，这些数据将被与预定义的资源定义进行比较。资源定义通常包含一组规则和约束，定义了什么样的 JSON 对象是合法的。资源定义可能包括字段的必选性、数据类型、格式和其他限制。
- 如果 JSON 对象不符合资源定义的要求，比如某个字段是必填的但实际没有提供，或者某个字段的数据类型不正确，那么验证过程将失败，并返回 HTTP 400（Bad Request）错误。
- 在 HTTP 400 错误响应中，通常会包含一个描述错误的详细信息。对于字段冲突的情况，响应中可能会包含发生冲突的字段名称，以及具体的错误信息，以帮助用户识别和解决问题。
这种验证机制的好处是，它可以防止无效或不符合规则的数据被存储到系统中，从而提高系统的数据质量。同时，通过返回明确的错误信息，用户可以更准确地了解问题所 在，并采取适当的措施进行修复。
如果需要更复杂的验证，可以通过实现准入 Webhook 来做到。在 Kubernetes 中，通过实现准入 Webhook 可以进行更复杂的验证。准入 Webhook 是一种机制，允许你在 API 服务器接收到请求之前或之后拦截请求，并执行自定义的验证逻辑。
以下是一个详细的步骤说明：
- 在 Kubernetes 集群中，创建一个自定义的 Admission Webhook。这个 Webhook 应该与 API 服务器进行配置，使其在创建或更新 CR（变更请求）时调用。
- 在 Admission Webhook 中，你需要实现一个或多个 HTTP 回调。这些回调将会在 API 服务器接收到创建或更新 CR 的请求时被调用。
- 在回调中，你可以接收并解析 API 服务器发送的请求数据。这包括需要创建或更新 CR 的 JSON 数据。
- 根据你的需求，使用图灵完备的编程语言（如 Java、Go、JavaScript、Python 或其他语言）来编写自定义的验证逻辑。你可以使用任何适合你的需求的语言来完成这个任务。
- 在自定义的验证逻辑中，你可以访问和解析 JSON 数据，并根据你的规则和约束进行验证。如果验证失败，你可以返回一个错误响应给 API 服务器，并包含详细的错误信息。
- 如果验证通过，你可以将 JSON 数据发送回 API 服务器，并继续处理正常的 CR 创建或更新流程。
通过这种方式，你可以使用准入 Webhook 来实现更复杂的验证逻辑，以满足特定的需求。这使得你可以在数据被存储到 Kubernetes 系统中之前，对数据进行更深入的验证和过滤。
需要注意的是，准入 Webhook 的实现需要遵循 Kubernetes 的 Webhook API 规范，以确保与 Kubernetes 集群的兼容性。可以参考 Kubernetes 的官方文档和示例代码来了解更多关于准入 Webhook 的详细信息和实现方法（https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/）。
