k8s 架构浅析
Kubernetes 的电梯间演讲
Kubernetes 是一个 面向应用 的容器集群部署、管理及编排系统，旨在为最终用户屏蔽物理/虚拟计算、网络、存储基础设施的复杂度，关注以应用为核心、以容器为原语的自动化运营平台。
Kubernetes 具备完善的集群管理能力，包括多层次的安全认证和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力。 Kubernetes 还提供完善的管理工具，涵盖开发、部署测试、运维监控等各个环节。
Kubernetes 的核心层级对象
Cluster： 是一个被 k8s 协调的高可用集群，作为 k8s 集群的根操作对象，将多台计算节点（Master/Node）连接成一个工作整体，是计算、存储和网络资源的集合。
Master：下属于 Cluster，充当集群中的中央控制角色，负责管理、协调集群中的所有活动（e.g. scheduler app、维护 app 状态机、 弹性扩展 apps、发布 app 更新 etc.）。
Node：下属于 Cluster，作为集群中的 Worker，受 Master 指使。是 Containers 及其 runtime 引擎的允许载体。
Pod： 是一个抽象而统一的概念，屏蔽底层异构 Container Runtime 技术实现。k8s 的最小工作单元，是 Containers 的 “Container”。
Container：下属于 Pod，是真正意义上的、常规的容器。
NOTE：为什么要引入 Pod 逻辑对象？
-
可管理性：有些容器天生就是需要紧密联系，一起工作的。例如：微服务中的 Side Car 模式，Pod 中的一个 ContainerA 提供业务，另一个 ContainerB 专门负责对 ContainerA 进行收集、监控日志和流量信息；又例如：ContainerA 作为 File Puller 定期从外部拉取最新的文件，将其存放到共享 Volume 中，ContainerB 作为 Web Server 直接从 Volume 读取文件，两个 Containers 紧密合作；Pod 将 Containers 封装到一个部署单元中，k8s 以 Pod 为最小单位进行调度、扩展、资源分配、管理生命周期。
-
通信和资源共享：Pod 中的所有 Containers 使用同一个 network namespace，即 Containers 具有相同的 IP 地址和 Port 空间，它们互相之间可以直接用 localhost 进行通信。同样的，这些容器也会共享存储，当 k8s 挂载 Volume 到 Pod，本质上是将 Volume 挂载到 Pod 中的每一个 Container。
简单的理解， 是不是有点类似与进程和线程的关系？
Kubernetes 的组件架构
Kubernetes 是典型的中控分布式架构（Central control distributed architecture），下面分别列举 Master、Node 的组件。
Master：
-
etcd：提供高可用性、严格数据一致性的非关系型数据库，具有共享配置、服务发现、分布式等特点。常被用于构建服务发现系统。
-
API Server：统一且唯一的 Cluster 北向访问接口，依靠 CA 认证体系提供身份认证、授权、鉴权等访问控制功能，统称 3A（Authentication、Authorization、Admission），是 Kubernets Security Mechanism 的门神。
-
Controller Manager：中央控制管理器，Cluster 的核心管理模块，负责整个 Cluster 的 “运”（e.g. 故障检测、弹性扩展、滚动更新，etc.）
-
Scheduler：资源调度器，按照预设的策略将 Pod 调度到目的（最佳）Node 上启动。
Node：
-
kubelet：维护 Container 的生命周期，同时也负责存储（CSI）和网络（CNI）的管理。
-
kube-proxy：为 Service 提供 Cluster 内部的服务发现和负载均衡功能。
-
Container runtime：负责镜像管理以及 Pod 和 Container 的运行（CRI）。
Kubernetes 的组件通信协议/接口
Kubernetes 的分层架构
Kubernetes 的术语词典
Controller：Pod 的控制器，k8s 提供了多种控制器来对 Pod 进行管理，包括 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等，以满足不同的业务需求。
Deployment：负责 Pod 的部署，并维护部署拓扑（e.g. 创建、监控、自修复 Pod），保证 Pod 按照期望的状态运行。
ReplicaSet：负责 Pod 的多副本管理，使用 Deployment 的同时会自动创建 ReplicaSet，也就是说 Deployment 实际是通过 ReplicaSet 来管理 Pod 多副本的，通常不需要直接使用 ReplicaSet。
DaemonSet：用于每个 Nodes 都运行且只运行一个 Pod 副本的场景。通常用于运行 daemon 服务进程。
StatefuleSet：保证 Pod 的所有副本的名称在其整个生命周期中是不变的。一般的，当 Pod 因为故障需要删除并重新启动时，它的名称是会发生变化的。StatefuleSet 还可以保证 Pod 的副本按照固定的顺序启动、更新或者删除。
Job：特殊的任务控制器，用于 App 运行结束就可以立即删除 Pod 的场景。
Service：用于定义外界访问一组特定 Pod 的方式。是一个北向提供外部访问方式（e.g. ClusterIP、NodePort、LoadBalancer），南向通过 Label 和 Selectors 来匹配 Pods 的 逻辑对象，还可以为 Pods 提供了负载均衡。
Namespace：k8s 实现多租户的方式，将一个物理 Cluster 从逻辑上划分成多个虚拟 Cluster，每个虚拟 Cluster 就是一个 Namespace，不同 Namespace 间的资源完全隔离。
- default Namespace：默认的 Namespace，如果创建任意资源时 不特别指定，就会将资源放到这个 namespace 下。
- kube-system Namespace：k8s 自己创建的系统资源将放到这个 namespace 下。
最后
一图抵万语，上文图源均来自互联网。实话说，并没有找到一张笔者满意的架构图，还是找个时间自己画一画吧。但依旧感谢这些图的原创作者们的贡献。
回到主题，Kubernets 的架构和整个部署的复杂度相较于 OpenStack 要更低，从这个角度来看好像的确为企业用户的运维成本省了不少。当然笔者对 k8s 也只是初学，做不得准。但可以肯定的是，k8s 的核心精髓在于 编排 二字，这是由 Container 的基因决定的。将 Container 当作 VM 来使用，那就是一个天大的误解了。所以每每看见市场上哪些为容器而容器，毫无编排特征的产品，笔者实在是难免感慨。
参考资料
- k8s 中文指南
- 每天 5 分钟学习 k8s
- 参考博客:http://blog.csdn.net/jmilk https://blog.csdn.net/Jmilk/article/details/85028828
