Kubernetes API Server 是如何验证和配置 API 里的数据,包括 Pod、Service、Replication Controller 等呢?
在 Kubernetes 中,API Server 根据配置文件中定义的 API 对象(例如 Pod、Service、Replication Controller 等)的规范进行校验和验证。当用户提交一个请求时,API Server 需要先对相应的 API 资源对象进行验证,验证通过后再进行操作。
在进行创建、删除、修改等操作时,API Server 会根据请求中的参数更新相应的 API 资源对象,并保存在 etcd 中。在进行查询操作时,API Server 会从 etcd 中获取相应的 API 资源对象。
Kubernetes API Server 验证和配置 API 里的数据的过程包括以下几个步骤:
- API Server 根据请求中的参数和请求路径确定要对哪个 API 资源对象进行操作。
- API Server 会读取相应的 API 资源对象的定义,并将其转换为内部数据结构。
- API Server 会对此数据结构进行基本的参数验证,比如根据 API 资源的类型、版本号等信息进行校验,并检查资源的必选项和可选项是否正确设置。
- API Server 会调用 Admission Control 插件来对数据结构进行更细致的验证和配置,以确保数据的正确性和安全性。Admission Control 插件可以检查和修改 API 资源对象中的字段,以及进行额外的验证和配置,也可以禁止请求或强制修改请求。
- 如果 Admission Control 插件验证通过,API Server 会将数据结构写入 etcd 中,完成对 API 资源对象的更新操作。否则,API Server 会拒绝请求并返回错误信息。
假设有一个名为 myapp 的 Deployment 对象,其中包含两个 Pod,它们都属于 myns 命名空间。现在我们想要对它们进行更新操作,增加一个新的 Label 和 Annotation。具体的操作请求如下:
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
namespace: myns
spec:
replicas: 2
template:
metadata:
labels:
app: myapp
annotations:
version: v1
spec:
containers:
- name: myapp
image: nginx
- 首先,Kubernetes API Server 根据请求中的参数和请求路径确定要对 myapp Deployment 对象进行更新操作,并读取相应的 API 资源对象定义。
- 然后,API Server 对请求参数进行基本的参数验证,检查资源的必选项和可选项是否正确设置。比如,检查该对象是否存在,命名空间是否正确等。
- 接下来,API Server 将请求中指定的 Label 和 Annotation 添加到已有的对象定义中。
- 然后,API Server 调用 Admission Control 插件进行更细致的验证和配置。在这个例子中,Kubernetes 内置了多个 Admission Control 插件,其中一个叫做 NamespaceExists。该插件会检查 myns 命名空间是否存在,如果存在则继续处理,否则会拒绝请求。
- 如果 Admission Control 插件验证通过,则 API Server 将更新后的 Deployment 对象写入 etcd 中,完成更新操作。否则,API Server 会拒绝请求并返回错误信息。
总之,Kubernetes API Server 通过对 API 资源对象的规范进行验证和配置,保证了整个 Kubeernetes 集群的稳定和安全运行。而 Admission Control 插件则提供了更细致、更灵活的验证和配置机制,为用户提供了更多的扩展和自定义的可能。