Kubernetes 的系统架构
一个 K8s 集群是由分布式存储（etcd）、服务节点（Minion，etcd 现在称为 Node）和控制节点（Master）构成的。所有的集群状态都保存在 etcd 中，Master 节点上则运行集群的管理控制模块。Node 节点是真正运行应用容器的主机节点，在每个 Minion 节点上都会运行一个 Kubelet 代理，控制该节点上的容器、镜像和存储卷等。
Kubernetes 的架构实现理念
1、只有 API Server 与存储通信，其他模块通过 API Server 访问集群状态。这样第一，是为了保证集群状态访问的安全。第二，是为了隔离集群状态访问的方式和后端存储实现的方式：API Server 是状态访问的方式，不会因为后端存储技术 etcd 的改变而改变。加入以后将 etcd 更换成其他的存储方式，并不会影响依赖依赖 API Server 的其他 K8s 系统模块。
2、一个工作节点被攻破不能导致整个 K8s 集群被攻破。这是所有分布式系统架构设计中都应该考虑的问题。
3、考虑网络随时可能断开的情况，没有新配置声明时各模块按照之前的配置声明继续工作。在 K8s 集群中，所有的配置管理操作都声明式而非命令式的，因为声明式操作对于网络故障等分布式系统常见的故障情况更加稳定。
4、各个模块在内存中缓存自己的相关状态以提高系统性能。
5、需要监控某个系统状态来做下一步动作的时候，优先考虑观察通知模式，其次再考虑轮询模式，这也是为了提高系统的响应速度
Kubernetes 的核心技术概念和 API 对象
API 对象是 K8s 集群中的管理操作单元。K8s 集群系统每支持一项新功能，引入一项新技术，一定会新引入对应的 API 对象，支持对该功能的管理操作。例如副本集 Replica Set 对应的 API 对象是 RS。
每个 API 对象都有 3 大类属性：元数据 metadata、规范 spec 和状态 status。元数据是用来标识 API 对象的，每个对象都至少有 3 个元数据：namespace，name 和 uid；除此以外还有各种各样的标签 labels 用来标识和匹配不同的对象，例如用户可以用标签 env 来标识区分不同的服务部署环境，分别用 env=dev、env=testing、env=production 来标识开发、测试、生产的不同服务。规范描述了用户期望 K8s 集群中的分布式系统达到的理想状态（Desired State），例如用户可以通过复制控制器 Replication Controller 设置期望的 Pod 副本数为 3；status 描述了系统实际当前达到的状态（Status），例如系统当前实际的 Pod 副本数为 2；那么复制控制器当前的程序逻辑就是自动启动新的 Pod，争取达到副本数为 3。
K8s 中所有的配置都是通过 API 对象的 spec 去设置的，也就是用户通过配置系统的理想状态来改变系统，这是 k8s 重要设计理念之一，即所有的操作都是声明式（Declarative）的而不是命令式（Imperative）的。声明式操作在分布式系统中的好处是稳定，不怕丢操作或运行多次，例如设置副本数为 3 的操作运行多次也还是一个结果，而给副本数加 1 的操作就不是声明式的，运行多次结果就错了
