关于 K8s ，你至少应该知道这些。
Kubernetes 概述
Kubernetes(也常称 K8s ，用 8 代替 8 个字符 “ubernete” 而成的缩写),是一个开源的，用于管理云平台中多个主机上的容器化应用。 它的一个核心特点是：能够自主的管理容器来保证云平台中的容器按照用户期望的状态运行。打个比方：比如我希望我的某个服务一直运行，至于怎么去做，我不管，我想要达到的目的就是我的那个服务一直运行，那么 Kubernetes 就会自动去监控，重启，新建，总之，只要是你想要让它一直运行，那么它就会一直运行下去。 可以说，因为 Kubernetes 的存在，使得自动化成为了可能，可用以及可靠。
Kubernetes 设计架构
Kubernetes 集群包含有节点代理 kubelet 和 Master 组件( APIs，scheduler，etc ),一切基于分布式的存储系统。来一张 Kubernetes 的架构图：
- etc 保存了整个集群的状态;
- controller manager 负责维护集群的状态，比如故障检测，自动扩展，滚动更新等;
- scheduler 负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上;
- apiserver 提供了资源操作的唯一入口，并提供认证，授权，访问控制， API 注册和发现等机制;
- kubelet 负责维护容器的生命周期，同时也负责 Volume(CVI) 和网络 (CNI) 的管理;
- Container runtime 负责镜像管理以及 Pod 和容器的真正运行(CRI);
- kube-proxy 负责为 Service 提供 cluster 内部的服务发现和负载均衡; </ul>
- 元数据(metadata):用来表示 API 对象，每个对象至少有 3 个元数据：namespace ，name ，uid
- 规范(spec):描述了用户期望 K8s 集群中的分布式系统达到的理想状态
- 状态(status):描述了系统实际当前达到的状态 </ul>
- Pod 是在 K8s 集群中运行部署应用或服务的最小单元，它支持多个容器在一个 Pod 中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。
- Pod 是 K8s 集群中所有业务类型的基础。不同类型的业务就需要不同类型的 Pod 去执行. </ul>
- 通过监控运行中的 Pod 来保证集群中运行指定数目的 Pod 副本。
- 一般情况下，通过 RC 运行 Pod 比直接运行 Pod 更明智，因为 RC 可以发挥它高可用的能力，保证永远有指定数目个 Pod 在运行。但它只适用于长期伺服型的业务类型 </ul>
- 新一代 RC ，提供同样的高可用能力，但 RS 能支持更多种类的匹配模式。
- 一般不单独使用，而是作为 Deployment 的理想状态参数使用 </ul>
- 部署表示用户对 K8s 集群的一次更新操作。 </ul>
- 服务(Service)
- RC，RS 和 Deployment 只是保证了支撑服务的微服务 Pod 数量，但是没有解决如何访问这些服务的问题。因为一个 Pod 只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点启动一个新的 Pod ，故而不能用确定的 ip 和端口号提供服务。
- 为解决这个问题，就有了 Service 的概念。在 K8s 集群中，客户端需要访问的服务就是 Service 对象。每个 Service 会对应一个集群内部有效的虚拟 ip ，这样客户端就不需要考虑 Pod 运行在哪儿个节点，这个工作只需要由 Service 去完成就 OK </ul>
- 任务(Job)
- Job 是 K8s 用来控制批处理型任务的 API 对象。
- Job 管理的 Pod 根据用户的设置把任务成功完成就退出，成功完成的标志根据不同的 spec.completions 策略而不同 </ul>
如上图， Job Controller 负责创建 Pod ，并持续监控 Pod 的状态，直至其成功结束。如果失败，则根据 restartPolicy （只支持 OnFailure 和 Never ，不支持 Always ）决定是否创建新的 Pod 再次重试任务。
# Kubernetes 核心设计理念
从以上介绍，我们可以知道， Kubernetes 的两个核心设计理念：一个是容错性，一个是易扩展性。
容错性实际是保证 K8s 系统稳定性和安全性的基础，易扩展性是保证 K8s 对变更友好，可以快速迭代增加新功能的基础。
图片有的参考自网上，如有侵权，可联系删除。
