简单描述一下客户端发出创建一个pod的请求,kubecnetes内部是如何运作的,如图:
- kubectl使用kubeconfig向API Server发起创建Pod的请求
- API Server处理用户请求，对kubeconfig进行认证
- 认证：Authentication，即身份认证。检查用户是否为合法用户，如客户端证书、密码、bootstrap tookens和JWT tokens等方式。
- 鉴权：Authorization，即权限判断。判断该用户是否具有该操作的权限，k8s 中支持 Node、RBAC（Role-Based Access Control）、ABAC、webhook等机制，RBAC 为主流方式
- 准入控制：Admission Control。请求的最后一个步骤，一般用于拓展功能，如检查 pod 的resource是否配置，yaml配置的安全是否合规等。一般使用admission webhooks来实现
kubernetes 支持很多种认证机制，包括：
-
X509 client certs
-
Static Token File
-
Bootstrap Tokens
-
Static Password File
-
Service Account Tokens
-
OpenId Connect Tokens
-
Webhook Token Authentication
-
Authticating Proxy
-
Anonymous requests
-
User impersonation
-
Client-go credential plugins
kubeconfig使用X509 client certs方式: 即客户端证书认证，X509 是一种数字证书的格式标准，是 kubernetes 中默认开启使用最多的一种，也是最安全的一种，api-server 启动时会指定 ca 证书以及 ca 私钥，只要是通过同一个 ca 签发的客户端 x509 证书，则认为是可信的客户端。
客户端证书认证叫作 TLS 双向认证，也就是服务器、客户端互相验证证书的正确性，在都正确的情况下协调通信加密方案。apiserver 、controller-manager、scheduler、kubelet 等组件之间的交互，一般也是基于X509的客户端认证方式，上面生成 kubeconfig 时用到就是 cfssl 工具签发的证书。
3.将Pod数据存储到etcd
4.Controller-Manager通过apiserver的watch接口发现了pod信息的更新，执行该资源所依赖的拓扑结构整合，整合后将对应的信息写到etcd，此时pod已经可以被调度了。
5.Scheduler同样通过apiserver的watch接口查看未绑定的Pod
6.通过调度算法给pod分配节点，并将pod和对应节点绑定的信息写到etcd，然后将pod交给kubelet。
Kubernetes Scheduler 提供的调度流程分三步：
-
预选策略(predicate) 遍历nodelist，过滤掉不符合要求的node。比如Pod指定了所需要的资源量，那么可用资源比Pod需要的资源量少的node会被过滤掉。
-
优选策略(priority) 在选择出符合要求的候选节点中，采用优选规则计算出每个节点的积分，最后选择得分最高的。
-
选定(select) 如果最高得分有好几个节点，select就会从中随机选择一个节点进行binding操作，结果存储到etcd中。
7. 运行在每个工作节点上的kubelet也会定期与etcd同步boundpod信息，一旦发现应该在该工作节点上运行的boundpod对象没有更新，则创建并启动pod。
