源码角度学习 Controller。(Kubernetes 1.19)
Kubernetes 的一个核心概念就是 “控制论” (Control theory) ，当然这是一个很大的学术命题，这里我们只需要明白，Kubernetes 通过声明式的 API 创建 “期望状态”，Controllers 就负责逐渐将当前状态转化为 “期望状态”。
这个过程被称为 “调谐” (reconciliation) 。
kube-controller-manager 管理着多组控制器 (如 replicaset-controller deployment-controller 等)，每个控制器都监测不同的资源对象，确保它们处于用户 “希望的状态”，这被称为 “控制器模式” (Controller Pattern) 。
如何对 Kubernetes 中的应用进行抓包调试，直接进入容器安装 tcpdump 过于粗暴，更好的方式是进入 Pod 所在命名空间。
管理数据中心的 k8s 集群，最麻烦的是网络环境的限制，内网、单出口等，集群镜像拉取上，目前采用了两个方案，达成节省带宽与突破访问限制的目的。
一直以来，我都在寻找一个私有云下 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 中的利用。
一直以来都比较希望掌握在复杂系统中定位和分析问题的能力，所以也是承接上一片网络分析的文章，这篇文章中主要想试着尝试对程序运行过程中的问题进行分析和定位。
关于这个领域也是第一次接触，质量有限，之后再做增补。
灵活的使用各种网络分析工具，可以有效地快速定位问题。