基础组件
上图是kubernetes的基本组成部分，以下将简单描述一下其组件及其功能。
Master
- API Server：管理集群资源的唯一入口
- Controller-Manager：一个资源对应一个控制器
- Node Controller
- Deployment Controller
- Namespace Controller
- ...
- Scheduler：节点调度，选择Worker节点部署
- Filter：选择符合Pod Spce描述的Node
- Score：打分和排序
- Reserve：缓存数据，表示这个Pod已经分配到这个Node上
- etcd：用于存储集群相关的数据
Worker
- kube-proxy：提供网络代理、负载均衡
- 实现的Proxy Mode支持iptables、ipvs Virtual IPs and service proxies
- 扩展阅读：性能提升40%: 腾讯 TKE 用 eBPF 绕过 conntrack 优化 K8s Service
- kubelet：管理本机的容器
- 基于 PodSpec 来工作的，每个 PodSpec 是一个描述 Pod 的 YAML 或 JSON 对象。
身份验证
每一次的访问请求都需要进行合法性的检验，其中包括身份验证、操作权限验证以及操作规范验证等，需要通过一系列验证通过之后才能访问。
工作流程
- 认证：验证账号的有效性
- 鉴权：拥有哪些访问权限
- 准入控制：自定义插件，API请求拦截器，它可以更改请求对象，甚至完全拒绝请求。
认证
拥有三种认证方式，分别是：
- Http Basic Authentication
- 基于证书认证（CA）
- 基于token认证
鉴权
基于RBAC，也就是角色访问控制。通俗的说，就是将权限赋予给角色，然后将角色绑定要用户主体上。
- 主体
- user
- group
- 角色
- role：特定命名空间访问权限
- ClusterRole：所有命名空间访问角色
- 角色绑定
- RoleBinding：角色绑定到主体
- ClusterRoleBinding：集群角色绑定到主体
准入控制
我从网上扒了一个例子，供参考
去年曝光的 runC 漏洞（CVE-2019-5736），它被利用的原因之一就是容器内进程都是以 root 权限运行的。下面我们以这个问题为例，一起利用准入控制器 webhook 建立自定义安全策略。
为了解决上述问题，工程师可以使用自定义的变更准入控制器 Webhook 使默认设置变得更安全：除非明确要求，否则 webhook 将强制要求 Pod 以非 root 身份运行（示例中为分配 ID 1234）。
请注意，这个设置不会影响到集群中的工作负载，包括那些明确需要 root 权限的工作负载。
完整代码请见以下 admission-controller-webhook-demo
Pod 启动流程
最后给大家分享一下容器的完整创建流程，对此有一个大概的认知。
