Kubernetes 是什么？

Kubernetes 是什么

都9102年了，你再不了解 Kubernetes 就真的 out 了！！！（贩卖焦虑体

在 kubernetes 的 站上，描述 kubernetes 是:

生产级别的容器编排系统

从这个定义我们可以提炼出三个关键字：

1. 生产级别
2. 容器
3. 编排系统

那下面分别解释下 k8s 的几个关键字（k8s是kubernetes的缩写，中间的8代表k与s间省略的8个字母，类似的缩写方式还有 internationalization 缩写为 i18n）。

1 生产级别

说 k8s 是生产级别有如下几个原因：

• k8s 是 Google 开源的系统，基于 Google 的 Borg 和 Omega 系统设计，这套系统已经在 Google 内部运行了10年以上，并还在支持Google 每周数十亿容器的运行。
• k8s 是 CNCF （Cloud Native Computing Foundation）的首个毕业项目。
• k8s 在2015年6月发布首个生产级成熟版本1.0后，目前（19年8月）已经进展到1.15版本，已经被各大公司广泛使用。

2 容器

没有集装箱，就没有全球化

什么是容器器的英文为 container，这个词除了有容器的意思，还有集装箱的意思。对于运输，集装箱有着重大的意义，在《集装箱改变世界》 这本书中，提出了“没有集装箱，就没有全球化”的观点，下面引用其中一段文字：

经济全球化的基础就是现代运输体系,而一个高度自动化、低成本和低复杂性的货物运输系统的核心就是集装箱。在1956年集装箱出现之前,人们很难想象美国的沃尔玛能够遍地开花。而在集装箱出现之后,以至于某件东半球的产品运至纽约销售,远比在纽约近郊生产该产品更划算。毫不起眼的集装箱降低了货物运输的成本,实现了货物运输的标准化,以此为基础逐步建立全球范围内的船舶、港口、航线、公路、中转站、桥梁、隧道、多式联运相配套的物流系统,世界经济形态因此而改变。

集装箱运输能够获得成功，可以概括出如下几个特点：

• 可移植性：集装箱可以被任何类型支持的船舶使用
• 包容性：支持多种类型的货物，这些货物都可以被打包在集装箱内
• 标准大小：标准大小的集装箱可以被完美的组合在一起
• 共存：多个集装箱可以放到同一个船上
• 隔离：不同集装箱的货物间彼此隔离

这些特点同样适用于软件领域的容器：

• 可移植性：容器可以被任何类型支持的操作系统安装使用
• 包容性：支持多种类型的软件，这些软件都可以被打包在容器内
• 标准格式
• 共存：多个容器可以运行在同一个物理机上
• 隔离：不同容器的软件间彼此隔离

因此，可以说容器是集装箱思路在软件领域的实现，容器是软件的一个标准单元，可以将代码和依赖打包在一起、能够运行在多种操作系统和环境之上、多个容器能够在同一台物理机器上运行。

容器和微服务化后，带来了一些好处，比如：

• 模块间更加独立，可以独立的部署和发布，加快了发布和更新的速度
• 隔离的运行环境，可以为不同模块定制不同的运行环境

但同时微服务化带来的问题就是，以前的一个单独的服务，现在变成了多个服务，服务的个数骤增，增大了部署和运维的工作量。同时，由于不同模块的软件依赖、 络配置、资源需求等各不相同，如果都直接使用 docker cli 来进行管理和配置，无疑是一件困难且容易出错的事，不能管理大规模的容器系统，因此就需要容器编排系统来处理。

3 编排系统

容器的编排系统需要能够管理和组织在一个集群上的运行的宿主机和容器，需要能完成如下任务：

• 管理 络和访问
• 跟踪容器的状态
• 增大或缩小服务的规模
• 实现负载平衡
• 宿主机无响应后实现容器的重新分配
• 服务发现
• 管理容器的存储
• 等等…

k8s 是这样一个容器编排系统，但除了 k8s 还有一些其他的容器编排系统，比如：

• Apache Mesos：是一个集群管理工具，支持容器的编排
• Docker Swarm：docker 容器平台自带的编排系统

这三个不同的容器编排系统，在不同的场景下有各自的优势，具体的对比可以参考文章，简单来说：

• 入门或者测试使用：Docker Swarm
• 企业级使用：k8s
• 需要除了容器编排外的更多集群管理功能：Apache Mesos

不过，不管是Docker 还是 Mesos 都支持与 k8s 的集成，所以 k8s 是目前被使用的最为广泛的容器编排系统。

4 k8s 架构概览

k8s 的架构图如下：

当需要更新应用的时候，一版希望做到如下两点：

• 不停服务，不影响正在使用的用户
• 支持灰度发布，可以在全量更新前验证新版本时候工作正常

对此，k8s 中抽象出了 Deployment 的概念，对 ReplicaSet 模型中 Pod 的更新进行支持。目前支持两种更新策略：

• Recreate：销毁所有在运行的 Pod 后进行重建，这种策略的问题是会带来 downtime
• RollingUpdate：滚动升级，符合期望的两点目标

k8s 中的更新策略为 RollingUpdate，通过两个参数来配置具体的更新方法：

• max unavailable：指定能够同时进行更新的 Pod 的个数
• max surge：在更新过程中能够使用的额外的 Pod 的个数

下面是一份 Deployment 的例子：

5.5 数据持久化

很多服务并不是无状态的，要支持有状态的服务，出了上述的 Statefull 工作模型，还需要数据持久化的支持。k8s 通过 Persistent Volumes 子系统来实现支持。

Persistent Volumes

• 是对集群中存储的抽象，提供存储服务的后端可以是：NFS、RBD等
• 生命周期与使用它的 Pod 的生命周期解耦
• 可以被手动添加也可以动态添加
• 不能直接和 Pod 关联，需要 Persistent Volumes Claim

Persistent Volumes Claim

• 是一个用户对存储的请求
• 在存储的角色类似于 Pod，Pod 消耗 Node 资源，而 Persistent Volumes Claim 消耗 Persistent Volumes 资源
• 提供抽象的存储资源，列出需要存储满足的要求，而不是直接使用 Persistent Volumes

下面是一个 Persistent Volume Claims 的例子：

5.6 小结

将上述的概念做一个小结：

• 最小计算单元 = Pod
• 最小通信单元 = Service
• 分组 = Labels
• 配置 = ConfigMap 和 Secrets
• 无状态 Pod 调度 = ReplicaSet、DaemonSet、Job
• 更新部署 = Deployment
• 有状态 Pod 调度 = StatefulSet
• 存储 = Persistent Volumes 以及之上的 Persistent Volumes Claim

整体的例子可以查看 https://github.com/kubernetes/examples ，包括如下几个例子：

6 k8s 与 大数据

我们看到很多企业的业务应用都已经部署到了 k8s 的集群之上，尤其是一些无状态的 Web 服务和 API 服务，特别适合 k8s 的场景。但是以 Hadoop 为代表的大数据系统能够运行在 k8s 之上吗/p>

如果将 Hadoop 部署在 k8s 之上，会带来哪些好处呢：

• 更好的资源利用：现在使用k8s的在线业务集群与离线大数据集群一般不在一起，而 Hadoop 部署在 k8s 之上就可以共用一套集群，更好的利用业务白天高峰和数据夜里高峰的特点
• 按需获取资源：就像 AWS 的 EMR，可以根据需要获取任意规模和任意时长的 Hadoop 集群，按需付费
• 更好的运维与升级：可以利用 k8s 的工具对 Hadoop 集群进行运维，不用再建设 Hadoop 运维工具
• 更灵活的资源隔离：使用 k8s 实现多个集群的部署，集群间互不影响

但是也存在一些挑战：

• IO性能：首当其冲的就是 IO，大数据系统是一类重 IO 操作的应用，容器化后需要将存储从本地 IO 变为 络 IO，这必然会引起性能的下
• 数据本地化：变为 络 IO 后，数据本地化的特点将不能利用
• 安全：因为不同容器共享一个内核，会有一定的安全隐患

但应对这些挑战，已经有一些企业和组织在进行优化了，比如 bluedata 提供了一套 spark on docker 的方案，并且获得了不错的性能，如下图：

总的来说，使用 k8s 可以快速构建起一套私有云的方案，降低了自建运维体系的成本。如果未来大数据等类型的应用也能在 k8s 上运行的很好，那 k8s 将会发挥更大的作用，我对此比较乐观。

• 滴滴云全线标准型云服务器限时特惠,注册即送新手大礼包
• 新购云服务1月5折 3月4折 6月低至3折
• 滴滴云使者招募，推荐最高返佣50%

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树k8s包管理(helm)安装helm8709 人正在系统学习中