kubectl创建pod的过程

kubectl

1.验证和生成器

1.1 验证客户端操作，过滤不合法的请求，如创建的资源不存在、镜像格式不正确将快速返回失败
1.2 使用generators根据需要创建的资源类型来构建runtime object，参考https://kubernetes.io/docs/reference/kubectl/conventions/#generators

2.API资源协商

如果使用kubectl时未指定具体的资源，Kubectl会通过apiserver的/api接口获取所有的api资源对象（会缓存在节点的/root/.kube/cache目录下），然后寻找匹配apiGroup和apiVersion

3.配置客户端身份信息

在发出http请求之前还需要配置访问apiserver时用的证书和token等信息，kubectl使用的这些信息可以从以下方式获得
--kubeconfig参数指定的文件
$KUBECONFIG环境变量指定额文件
前两种方式都未指定时使用$HOME/.kube/config默认配置
优先级逐渐降低

apiserver

4.身份认证（请求的用户是否存在）

apiserver启动的时候会根据自己的启动参数（可以查看apiserver的manifests文件）来构造一个认证链，例如参数--client-ca-file对应认证链中的x509 authenticator、参数--token-auth-file对应认证链中
的token authenticator，用户请求将被认证链中的authenticator逐个认证直到某个成功就认为通过，apiserver启动参数：https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/
认证链匹配过程：

https://github.com/kubernetes/apiserver/blob/51bebaffa01be9dc28195140da276c2f39a10cd4/pkg/authentication/request/union/union.go#L54
// AuthenticateRequest authenticates the request using a chain of authenticator.Request objects.
func (authHandler *unionAuthRequestHandler) AuthenticateRequest(req *http.Request) (user.Info, bool, error) {
    var errlist []error
    for _, currAuthRequestHandler := range authHandler.Handlers {
        info, ok, err := currAuthRequestHandler.AuthenticateRequest(req)
        if err != nil {
            if authHandler.FailOnError {
                return info, ok, err
            }
            errlist = append(errlist, err)
            continue
        }

        if ok {
            return info, ok, err
        }
    }

    return nil, false, utilerrors.NewAggregate(errlist)
}

5.鉴权（用户是否具有对请求指定资源的操作权限）

apiserver的启动参数--authorization_mode参数指定了权限鉴定的方式，可以同时指定多个以逗号分隔的鉴权方式

webhook, which interacts with an off-cluster HTTP(S) service;
ABAC, which enforces policies defined in a static file;
RBAC, which enforces RBAC roles which are added by the admin as k8s resources
Node, which ensures that node clients, i.e. the kubelet, can only access resources hosted on itself.

6.Admission control

前面鉴权目的是验证用户是否对请求资源有某个操作的权限，而这里准入控制器会拦截请求以确保它符合集群的更广泛的期望和规则，是资源对象保存到 etcd 之前的最后一个堡垒。像每个pod中自动注入的serviceaccount
和ResourceQuota、LimitRanger等的实现都是通过admission controller实现。如果admission controller chain中的某个controller拒绝了用户请求，那么请求将立刻失败。官方已经实现了很多准入控制器，对
应源码中的plugin/pkg/admission目录，这些准入控制器被编译到apiserver中。

其中提供了mutating webhook和validating webhook，可以对用户提交的资源操作请求进行mutate和validate，可以利用这个扩展特性做很多自动化的配置

默认启动的admission controller和每个controller的作用可见：https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/
各admission controller源码：https://github.com/kubernetes/kubernetes/tree/master/plugin/pkg/admission

7. 持久化到etcd

到目前为止，Kubernetes已经完全审查了传入的请求，并允许它继续进行并成功。在下一步中，kube apiserver反序列化HTTP请求，从中构造运行时对象（类似于kubectl生成器的逆过程），并将它们持久化到数据存储。

kubectl创建pod的过程

kubectl

apiserver

猜你喜欢