源码角度学习 Controller。(Kubernetes 1.19)
Kubernetes 的一个核心概念就是 “控制论” (Control theory) ，当然这是一个很大的学术命题，这里我们只需要明白，Kubernetes 通过声明式的 API 创建 “期望状态”，Controllers 就负责逐渐将当前状态转化为 “期望状态”。
这个过程被称为 “调谐” (reconciliation) 。
kube-controller-manager 管理着多组控制器 (如 replicaset-controller deployment-controller 等)，每个控制器都监测不同的资源对象，确保它们处于用户 “希望的状态”，这被称为 “控制器模式” (Controller Pattern) 。
如何对 Kubernetes 中的应用进行抓包调试，直接进入容器安装 tcpdump 过于粗暴，更好的方式是进入 Pod 所在命名空间。
一直以来，我都在寻找一个私有云下 Kubernetes 存储方案的“最佳实践“，常见如 GlusterFS 的部署方案并不太适合现有的环境，裸机方案需要三台服务器进行集群部署，然而手头并没有多余的机器了，在当前部署 Openstack 的机器上进行部署就更不用想了，这只会增加之后维护的复杂性，特别是服务器的磁盘我并没有进行特别的分区操作，Openstack 的卷存储是直接挂载在 /dev/loop 下，使用的是整个磁盘的空间，引入其他的分布式文件系统可能会与 Cinder 产生冲突。
GlusterFS 的另一种部署方案是在 k8s 集群上进行部署，直接使用 Node 上的存储资源，这要求我必须为虚拟机实例直接分配更多的存储，存储利用率很难保证；而根据使用情况将 Openstack 中的卷挂载到各个实例上，管理起来太过麻烦。
总结下来，存储方案需要满足的最关键的两点：
相较于 Scheduler Extender ，调度框架通过将所有的调度过程 “插件化“ 。
目前为止，Scheduler Framework 的开发需要重新 build 整个调度器的代码，还不支持一个 “热插拔” 的方式，这与 Scheduler Extender / Multi-scheduler 的 “无侵入“ 的扩展方式是不一样的。
API Server 作为 Kubernetes 的核心组件，接收包括用户和集群内部资源对象发来的请求，在处理这些请求之前，API Server 会通过凭证来认证请求是否有相应的权限。
早期版本的 Kubernetes 中，集群内以 token 作为身份认证的手段，这也意味着，如果以某种方式获取了这个 token 之后，就可以在 Kubernetes 中运行任意的 pod.
针对权限管理这个问题，Kubernetes 提出了插件形式的授权方法，包括基于角色的权限控制 ( RBAC , Role-Based Access Control ) 、基于属性的权限控制 ( ABAC , Attribute-Based Access Control )、 WebHook 插件以及自定义插件。
RBAC 作为 Kubernetes 的 GA (通用可用性) 级别的资源对象，在集群中是默认开启的，本文将介绍 RBAC 在 Kubernetes 中的利用。
使用 Kubeadm 工具在集群上安装 Kubernetes.
UPDATE 2020/05/15:
Troubleshooting for kubeadm.