一，Kubernetes的起源和发展

清疚 2021-09-22 00:28 387阅读 0赞

### 一，Kubernetes 的起源 ###

Kubernetes最初源于谷歌内部的Borg，Kubernetes 的最初目标是为应用的容器化编排部署提供一个最小化的平台，包含几个基本功能：

*  将应用水平扩容到多个集群
 *  为扩容的实例提供负载均衡的策略
 *  提供基本的健康检查和自愈能力
 *  实现任务的统一调度

## 二，Kubernetes 的发展 ##

*  2014年6月 谷歌云计算专家Eric Brewer在旧金山的发布会为这款新的开源工具揭牌。
 *  2015年7月22日K8S迭代到 v 1.0并在OSCON大会上正式对外公布。
 *  为了建立容器编排领域的标准和规范，Google、RedHat 等开源基础设施领域玩家们，在 2015 年共同牵头发起了名为 CNCF（Cloud Native Computing Foundation）的基金会。Kubernetes 成为 CNCF 最核心的项目。发起成员：AT&T, Box, Cisco, Cloud Foundry Foundation, CoreOS, Cycle Computing, Docker, eBay, Goldman Sachs, Google, Huawei, IBM, Intel, Joyent, Kismatic, Mesosphere, Red Hat, Switch SUPERNAP, Twitter, Univa, VMware and Weaveworks。
 *  2018年，超过 1700 开发者成为 Kubernetes 项目社区贡献者，全球有 500 多场沙龙。国内出现大量基于 Kubernetes 的创业公司。
 *  2020 年，Kubernetes 项目已经成为贡献者仅次于 Linux 项目的第二大开源项目。成为了业界容器编排的事实标准，各大厂商纷纷宣布支持 Kubernetes 作为容器编排的方案。

### 三，为什么需要 Kubernetes ###

**1，传统的容器编排痛点**

容器技术虽然解决了应用和基础设施异构的问题，让应用可以做到一次构建，多次部署，但在复杂的微服务场景，单靠 Docker 技术还不够，它仍然有以下问题没有解决：

*  集成和编排微服务模块
 *  提供按需自动扩容，缩容能力
 *  故障自愈
 *  集群内的通信

**2，Kubernetes 能解决的问题**

*  按需的垂直扩容，新的服务器(node)能够轻易的增加或删除
 *  按需的水平扩容，容器实例能够轻松扩容，缩容
 *  副本控制器，你不用担心副本的状态
 *  服务发现和路由
 *  自动部署和回滚，如果应用状态错误，可以实现自动回滚

**3，什么时候使用 Kubernetes？**

*  当你的应用是微服务架构
 *  开发者需要快速部署自己的新功能到测试环境进行验证
 *  降低硬件资源成本，提高使用率

什么时候不适合使用 Kubernetes

*  应用是轻量级的单体应用，没有高并发的需求
 *  团队文化不适应变革

### 四，Kubernetes 的架构和核心概念 ###

**1，主控制节点组件**

主控制节点组件对集群做出全局决策(比如调度)，以及检测和响应集群事件（例如，当不满足部署的 replicas 字段时，启动新的 pod）。

主控制节点组件可以在集群中的任何节点上运行。 然而，为了简单起见，设置脚本通常会在同一个计算机上启动所有主控制节点组件，并且不会在此计算机上运行用户容器。

*  apiserver 主节点上负责提供 Kubernetes API 服务的组件；它是 Kubernetes 控制面的前端组件。
 *  etcd etcd 是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。
 *  kube-scheduler 主节点上的组件，该组件监视那些新创建的未指定运行节点的 Pod，并选择节点让 Pod 在上面运行。 调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。
 *  kube-controller-manager 在主节点上运行控制器的组件。 从逻辑上讲，每个控制器都是一个单独的进程，但是为了降低复杂性，它们都被编译到同一个可执行文件，并在一个进程中运行。这些控制器包括:
    
    1.  节点控制器（Node Controller）: 负责在节点出现故障时进行通知和响应。
    2.  副本控制器（Replication Controller）: 负责为系统中的每个副本控制器对象维护正确数量的 Pod。
    3.  终端控制器（Endpoints Controller）: 填充终端(Endpoints)对象(即加入 Service 与 Pod)。
    4.  服务帐户和令牌控制器（Service Account & Token Controllers），为新的命名空间创建默认帐户和 API 访问令牌.

**2，从节点组件**

节点组件在每个节点上运行，维护运行的 Pod 并提供 Kubernetes 运行环境。

*  kubelet 一个在集群中每个节点上运行的代理。它保证容器都运行在 Pod 中。

kubelet 接收一组通过各类机制提供给它的 PodSpecs，确保这些 PodSpecs 中描述的容器处于运行状态且健康。kubelet 不会管理不是由 Kubernetes 创建的容器。

*  kube-proxy kube-proxy 是集群中每个节点上运行的网络代理,实现 Kubernetes Service 概念的一部分。 kube-proxy 维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。
 *  容器运行时（Container Runtime） 容器运行环境是负责运行容器的软件。 Kubernetes 支持多个容器运行环境: Docker、 containerd、cri-o、 rktlet 以及任何实现 Kubernetes CRI (容器运行环境接口)。

**3，插件（Addons）**

*  DNS 尽管其他插件都并非严格意义上的必需组件，但几乎所有 Kubernetes 集群都应该有集群 DNS， 因为很多示例都需要 DNS 服务。
 *  Web 界面（仪表盘） Dashboard 是K ubernetes 集群的通用的、基于 Web 的用户界面。 它使用户可以管理集群中运行的应用程序以及集群本身并进行故障排除。
 *  容器资源监控 容器资源监控 将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，并提供用于浏览这些数据的界面。
 *  集群层面日志 集群层面日志 机制负责将容器的日志数据 保存到一个集中的日志存储中，该存储能够提供搜索和浏览接口。