K8S是什么？发展历史
Kubernetes (简称 k8s)是 Google 在2014年开源的，对容器生命周期管理的开源平台，致力于对容器集群提供易于管理、高可用、弹性负载与故障转移的能力，提高服务运维自动化的能力。
最初，Google 开发了一个叫 Borg 的系统(现在命名为Omega)来调度据说有20多亿个容器和工作负载。在积累了 10 余年经验后，Google 决定重写这个容器管理系统，并将其命名为 Kubernetes 贡献给开源社区，让全世界都能因此受益。
自从开源以来，K8S迅速获得开源社区的追捧，包括RedHat、VMware、Canonical在内的有很大影响力公司加入到开发与推广的阵营。
当微服务的概念的落地实践开始，微服务就与容器紧紧地绑在了一起，可以说K8s的成功离不开微服务与容器。
2017年是容器生态发展历史中具有里程碑意义的一年。
在这一年，长期作为Docker竞争对手的RKT容器一派的领导者CoreOS宣布放弃自己的容器管理系统Fleet，未来将会把所有容器管理的功能移至Kubernetes之上去实现。
在这一年，容器管理领域的独角兽Rancher Labs宣布放弃其内置了数年的容器管理系统Cattle，提出了“All-in-Kubernetes”战略，从2.0版本开始把1.x版本能够支持多种容器管理工具的Rancher，“升级”为只支持Kubernetes一种容器管理系统。
在这一年，Kubernetes的主要竞争者Apache Mesos在9月正式宣布了“Kubernetes on Mesos”集成计划，由竞争关系转为对Kubernetes提供支持，使其能够与Mesos的其他一级框架(如HDFS、Spark 和Chronos，等等)进行集群资源动态共享、分配与隔离。
在这一年，Kubernetes的最大竞争者Docker Swarm的母公司Docker，终于在10月被迫宣布Docker要同时支持Swarm与Kubernetes两套容器管理系统，事实上承认了Kubernetes的统治地位。这场已经持续了三、四年时间，以Docker Swarm、Apache Mesos与Kubernetes为主要竞争者的“容器战争”终于有了明确的结果。
时至今日，K8S 已经是发展最快、市场占有率最高的容器编排系统，是业界标杆。
小结：Kubernetes是Google公司2014年开源的容器编排产品，经过多年的发展，已经成为容器编排领域的佼佼者，拥有最广大的用户群体
应用部署容器化的发展历程
要说K8S的作用，得先从容器的发展与优势讲起，大致可分为 传统部署时代、虚拟化部署时代、容器部署时代
传统部署时代： 早期，在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界，这会导致资源分配困难与资源浪费的问题。例如，如果在物理服务器上运行多个应用程序，则可能会出现一个应用程序占用大部分资源的情况，结果可能导致其他应用程序的性能下降。一种解决方案是在不同的物理服务器上运行每个应用程序，但是由于资源利用不足而无法扩展，并且组织维护许多物理服务器的成本很高。
虚拟化部署时代： 作为解决方案，引入了虚拟化功能，它允许您在单个物理服务器的 CPU 上运行多个虚拟机(VM)。虚拟化功能允许应用程序在 VM 之间隔离，并提供安全级别，因为一个应用程序的信息不能被另一应用程序自由地访问。
因为虚拟化可以轻松地添加或更新应用程序、降低硬件成本等等，所以虚拟化可以更好地利用物理服务器中的资源，并可以实现更好的可伸缩性。
每个 VM 是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统，这势必也会造成资源的浪费、性能的下降
容器部署时代： 容器类似于 VM，但是它们具有轻量级的隔离属性，可以在应用程序之间共享操作系统(OS)。因此，容器被认为是轻量级的。容器与 VM 类似，具有自己的文件系统、CPU、内存、进程空间等。由于它们与基础架构分离，因此可以跨云和 OS 分发进行移植。
容器因具有许多优势而变得流行起来。下面列出了容器的一些好处：
- 敏捷应用程序的创建和部署：与使用 VM 镜像相比，提高了容器镜像创建的简便性和效率。
- 持续开发、集成和部署：通过快速简单的回滚(由于镜像不可变性)，提供可靠且频繁的容器镜像构建和部署。
- 关注开发与运维的分离：在构建/发布时而不是在部署时创建应用程序容器镜像，从而将应用程序与基础架构分离。
- 可观察性：不仅可以显示操作系统级别的信息和指标，还可以显示应用程序的运行状况和其他指标信号。
- 跨开发、测试和生产的环境一致性：在便携式计算机上与在云中相同地运行。
- 云和操作系统分发的可移植性：可在 Ubuntu、RHEL、CoreOS、本地、Google Kubernetes Engine 和其他任何地方运行。
- 以应用程序为中心的管理：提高抽象级别，从在虚拟硬件上运行 OS 到使用逻辑资源在 OS 上运行应用程序。
- 松散耦合、分布式、弹性、解放的微服务：应用程序被分解成较小的独立部分，并且可以动态部署和管理 - 而不是在一台大型单机上整体运行。
- 资源隔离：可预测的应用程序性能。
- 资源利用：高效率和高密度。
小结：相对于传统物理机部署方式，虚拟机部署将资源更好的隔离开来，使资源分配与隔离的问题解决，提高了资源使用率，但是由于其虚拟了硬件与OS，会浪费不必要的资源；容器部署继承了虚拟机部署的资源隔离优势的同时，使用共享宿主机的硬件与OS的方式，资源消耗更少，由于与基础架构进行了分离，可以做到良好的移植性
为什么需要 Kubernetes，它能做什么?
容器是打包和运行应用程序的好方式。在生产环境中，如果一个容器发生故障，则启动另一个容器。如此处理会不会更简单？
K8s就是这么做的！K8s 为您提供了一个可弹性运行分布式系统的框架，能满足您的扩展要求、故障转移、部署模式等。
Kubernetes 为您提供：
-
服务发现和负载均衡
Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器，如果到容器的流量很大，Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。 -
存储编排
Kubernetes 允许您自动挂载您选择的存储系统，例如本地存储、公共云提供商等。 -
自动部署和回滚
您可以使用 Kubernetes 描述已部署容器的所需状态，它可以以受控的速率将实际状态更改为所需状态。例如，您可以自动化 Kubernetes 来为您的部署创建新容器，删除现有容器并将它们的所有资源用于新容器。 -
自动二进制打包
Kubernetes 允许您指定每个容器所需 CPU 和内存(RAM)。当容器指定了资源请求时，Kubernetes 可以做出更好的决策来管理容器的资源。 -
自我修复
Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器，并且在准备好服务之前不将其通告给客户端。 -
密钥与配置管理
Kubernetes 允许您存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。您可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥。
小结：K8S 提供了服务发现和负载均衡、存储编排、自动部署和回滚、自动二进制打包、自我修复、密钥与配置管理等功能，能满足您的扩展要求、故障转移、部署模式等需求
扩展
1、有微服务实践的读者可能会发现，微服务组件中的服务发现、负载均衡、网关等功能在K8s体系中都有对应的实现，那么是不是我就可以不使用其他微服务的体系而直接拥抱K8s呢？
答案是可以的。但有一点限制就是开发人员要学习K8s，偏向DevOps了。
2、既然K8s提供了微服务所需的基础组件实现，但我可以不用么？
答案也是可行的。K8s的组件插拔能力允许你这么做，这样一来开发测试环境使用本地部署注册中心等组件，开发人员就无需关心K8s了，只需要理解所用微服务框架本身，如Spring Cloud等。
Kubernetes 不是什么
Kubernetes 不是传统的、包罗万象的 PaaS(平台即服务)系统。它只提供了 PaaS 产品共有的一些普遍适用的功能，例如部署、扩展、负载均衡、日志记录和监视。但是，Kubernetes 不是单一的，默认解决方案是可选和可插拔的。Kubernetes 提供了构建开发人员平台的基础，但是在重要的地方保留了用户的选择和灵活性。
Kubernetes：
-
不限制支持的应用程序类型。Kubernetes 旨在支持极其多种多样的工作负载，包括无状态、有状态和数据处理工作负载。如果应用程序可以在容器中运行，那么它应该可以在 Kubernetes 上很好地运行。
-
不部署源代码，也不构建您的应用程序。持续集成(CI)、交付和部署(CI/CD)工作流取决于组织的文化和偏好以及技术要求。
-
不提供应用程序级别的服务作为内置服务，例如中间件(例如，消息中间件)、数据处理框架(例如，Spark)、数据库(例如，mysql)、缓存、集群存储系统(例如，Ceph)。这样的组件可以在 Kubernetes 上运行，并且/或者可以由运行在 Kubernetes 上的应用程序通过可移植机制(例如，开放服务代理)来访问。
-
不指定日志记录、监视或警报解决方案。它提供了一些集成作为概念证明，并提供了收集和导出指标的机制。
-
不提供或不要求配置语言/系统(例如 jsonnet)，它提供了声明性 API，该声明性 API 可以由任意形式的声明性规范所构成。
-
不提供也不采用任何全面的机器配置、维护、管理或自我修复系统。
-
此外，Kubernetes 不仅仅是一个编排系统，实际上它消除了编排的需要。编排的技术定义是执行已定义的工作流程：首先执行 A，然后执行 B，再执行 C。相比之下，Kubernetes 包含一组独立的、可组合的控制过程，这些过程连续地将当前状态驱动到所提供的所需状态。从 A 到 C 的方式无关紧要，也不需要集中控制，这使得系统更易于使用且功能更强大、健壮、弹性和可扩展性。
小结：K8S 提供了基础的容器编排平台，但并不是大而全地将所有可能的功能都直接集成进来，而是做成可插拔的形式，可以做到因地适宜地组织与管理集群，拥有很高的灵活性。
Kubernetes 架构与组件
K8s的架构如上图，左边虚线框的部分称为 控制平面(Control Plane)，右侧为 集群节点(Nodes)
控制平面所在的主机称为 Master 节点，其余称为 Nodes 执行节点
简单按这两种角色来讲，Master节点负责发号施令(下发命令、监控节点与容器状态)，而 Nodes 节点负责干活
控制平面(Control Plane)组件
控制平面的组件对集群做出全局决策(比如调度)，以及检测和响应集群事件
控制平面组件可以在集群中的任何节点上运行。简单起见，通常会将控制平台配置在一台主机上，也可以配置高可用形式。
下边我们介绍下 控制平面中的几大组件：
- kube-apiserver：Master节点上负责提供 Kubernetes API 服务的组件；它是 Kubernetes 控制面的前端，由它来接收来自 CLI 与 UI 的指令
- etcd：是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。
- kube-scheduler：Master节点上的组件，该组件监视那些新创建的未指定运行节点的 Pod，并选择节点让 Pod 在上面运行。
- kube-controller-manager：控制器通过 apiserver 监控集群的公共状态，并致力于将当前状态转变为期望的状态。从逻辑上讲，每个控制器都是一个单独的进程，但是为了降低复杂性，它们都被编译到同一个可执行文件，并在一个进程中运行。包含以下几种控制器：
- 节点控制器(Node Controller): 负责在节点出现故障时进行通知和响应。
- 副本控制器(Replication Controller): 负责为系统中的每个副本控制器对象维护正确数量的 Pod。
- 端点控制器(Endpoints Controller): 填充端点(Endpoints)对象(即加入 Service 与 Pod)。
- 服务帐户和令牌控制器(Service Account & Token Controllers): 为新的命名空间创建默认帐户和 API 访问令牌
- cloud-controller-manager：云控制器管理器负责与基础云提供商交互，以下控制器具有云提供商依赖性:
- 节点控制器(Node Controller): 用于检查云提供商以确定节点是否在云中停止响应后被删除
- 路由控制器(Route Controller): 用于在底层云基础架构中设置路由
- 服务控制器(Service Controller): 用于创建、更新和删除云提供商负载均衡器
- 数据卷控制器(Volume Controller): 用于创建、附加和装载卷、并与云提供商进行交互以编排卷
节点(Node) 组件
节点组件在每个节点上运行，维护运行的 Pod 并提供 Kubernetes 运行环境
节点组件包含两大组件：
-
kubelet：一个在集群中每个节点上运行的代理。它保证容器都运行在 Pod 中。
kubelet 接收一组通过各类机制提供给它的 PodSpecs，确保这些 PodSpecs 中描述的容器处于运行状态且健康。kubelet 不会管理不是由 Kubernetes 创建的容器。
-
kube-proxy：是集群中每个节点上运行的网络代理，实现 Kubernetes Service 概念的一部分。
kube-proxy 维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。
如果操作系统提供了数据包过滤层并可用的话，kube-proxy会通过它来实现网络规则。否则，kube-proxy 仅转发流量本身
-
容器运行环境(Container Runtime)：容器运行环境是负责运行容器的软件。K8s支持多种容器运行环境：Docker、containerd、cri-o、rklet 以及任何实现K8s容器运行环境接口的技术。
插件(Addons)
-
DNS：所有 Kubernetes 集群都应具有 DNS。集群 DNS 还是一个 DNS 服务器，它为 Kubernetes 服务提供 DNS 记录。
-
用户界面(Dashboard)：Kubernetes 集群基于 Web 的 UI。它使用户可以管理集群中运行的应用程序以及集群本身并进行故障排除。
Dashboard 是 Kubernetes 集群的通用基于 Web 的 UI。它使用户可以管理集群中运行的应用程序以及集群本身并进行故障排除。
-
容器资源监控：将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，并提供用于浏览这些数据的界面。
-
集群层面日志：负责将容器的日志数据保存到一个集中的日志存储中，该存储能够提供搜索和浏览接口。
- kube-apiserver(访问入口，接收命令)
- etcd(KV数据库，保存集群状态与数据)
- kube-scheduler(监控节点状态，调度容器部署)
- kube-controller-manager(监控集群状态，控制节点、副本、端点、账户与令牌)
- cloud-controller-manager(控制与云交互的节点、路由、服务、数据卷)
- kubelet(监控与实际操作容器)
- kube-proxy(每个节点上运行的网络代理，维护网络转发规则，实现了Service)
- 容器运行时环境CRI(支持多种实现K8s CRI的容器技术)
本文总结
Kubernetes 作为容器编排的领航者，将容器化的优势发挥得淋漓尽致，排除了容器难于管理的问题。
按角色来看，K8s可以分为两部分，控制平面与执行节点，控制平台通过一系列接收指令、监控、部署调度等功能的组件组成，最主要的有kube-apiserver、etcd、kube-scheduler、kube-controller-manager；执行节点包含负责监控与具体干活的kubelet和维护网络规则的kube-proxy
参考文章
- https://kubernetes.io/docs/concepts/overview/components/