认识 Kubernetes（K8S）容器集群。

Posted 2021-04-02 时代Java

↑ 点击上面 “时代Java”关注我们，

关注新技术，学习新知识！

1 K8S 是什么？

K8S 是Kubernetes的全称，官方称其是：

Kubernetes is an open source system for managing containerized applications across multiple hosts. It provides basic mechanisms for deployment, maintenance, and scaling of applications.
用于自动部署、扩展和管理“容器化（containerized）应用程序”的开源系统。

翻译成大白话就是：“K8 是 S 负责自动化运维管理多个 Docker 程序的集群”。那么问题来了：Docker 运行可方便了，为什么要用 K8S，它有什么优势？

插一句题外话：

• 为什么 Kubernetes 要叫 Kubernetes 呢？维基百科已经交代了（老美对星际是真的痴迷）：
   Kubernetes（在希腊语意为“舵手”或“驾驶员”）由 Joe Beda、Brendan Burns 和 Craig McLuckie 创立，并由其他谷歌工程师，包括 Brian Grant 和 Tim Hockin 等进行加盟创作，并由谷歌在 2014 年首次对外宣布 。该系统的开发和设计都深受谷歌的 Borg 系统的影响，其许多顶级贡献者之前也是 Borg 系统的开发者。在谷歌内部，Kubernetes 的原始代号曾经是Seven，即星际迷航中的 Borg（博格人）。Kubernetes 标识中舵轮有七个轮辐就是对该项目代号的致意。
  
  

• 为什么 Kubernetes 的缩写是 K8S 呢？我个人赞同Why Kubernetes is Abbreviated k8s中说的观点“嘛，写全称也太累了吧，不如整个缩写”。其实只保留首位字符，用具体数字来替代省略的字符个数的做法，还是比较常见的。
  

2 为什么是 K8S?

试想下传统的后端部署办法：把程序包（包括可执行二进制文件、配置文件等）放到服务器上，接着运行启动脚本把程序跑起来，同时启动守护脚本定期检查程序运行状态、必要的话重新拉起程序。

有问题吗？显然有！最大的一个问题在于：**如果服务的请求量上来，已部署的服务响应不过来怎么办？**传统的做法往往是，如果请求量、内存、CPU 超过阈值做了告警，运维马上再加几台服务器，部署好服务之后，接入负载均衡来分担已有服务的压力。

问题出现了：从监控告警到部署服务，中间需要人力介入！那么，有没有办法自动完成服务的部署、更新、卸载和扩容、缩容呢？

这，就是 K8S 要做的事情：自动化运维管理 Docker（容器化）程序。

1.3 K8S 怎么做？

我们已经知道了 K8S 的核心功能：自动化运维管理多个容器化程序。那么 K8S 怎么做到的呢？这里，我们从宏观架构上来学习 K8S 的设计思想。首先看下图，图片来自文章Components of Kubernetes Architecture：

K8S 是属于主从设备模型（Master-Slave 架构），即有 Master 节点负责核心的调度、管理和运维，Slave 节点则在执行用户的程序。但是在 K8S 中，主节点一般被称为Master Node 或者 Head Node（本文采用 Master Node 称呼方式），而从节点则被称为Worker Node 或者 Node（本文采用 Worker Node 称呼方式）。

要注意一点：Master Node 和 Worker Node 是分别安装了 K8S 的 Master 和 Woker 组件的实体服务器，每个 Node 都对应了一台实体服务器（虽然 Master Node 可以和其中一个 Worker Node 安装在同一台服务器，但是建议 Master Node 单独部署），所有 Master Node 和 Worker Node 组成了 K8S 集群，同一个集群可能存在多个 Master Node 和 Worker Node。

首先来看Master Node都有哪些组件：

• API Server。K8S 的请求入口服务。API Server 负责接收 K8S 所有请求（来自 UI 界面或者 CLI 命令行工具），然后，API Server 根据用户的具体请求，去通知其他组件干活。

• Scheduler。K8S 所有 Worker Node 的调度器。当用户要部署服务时，Scheduler 会选择最合适的 Worker Node（服务器）来部署。

• Controller Manager。K8S 所有 Worker Node 的监控器。Controller Manager 有很多具体的 Controller，在文章Components of Kubernetes Architecture中提到的有 Node Controller、Service Controller、Volume Controller 等。Controller 负责监控和调整在 Worker Node 上部署的服务的状态，比如用户要求 A 服务部署 2 个副本，那么当其中一个服务挂了的时候，Controller 会马上调整，让 Scheduler 再选择一个 Worker Node 重新部署服务。

• etcd。K8S 的存储服务。etcd 存储了 K8S 的关键配置和用户配置，K8S 中仅 API Server 才具备读写权限，其他组件必须通过 API Server 的接口才能读写数据（见Kubernetes Works Like an Operating System）。

接着来看Worker Node的组件，笔者更赞同HOW DO APPLICATIONS RUN ON KUBERNETES文章中提到的组件介绍：

• Kubelet。Worker Node 的监视器，以及与 Master Node 的通讯器。Kubelet 是 Master Node 安插在 Worker Node 上的“眼线”，它会定期向 Worker Node 汇报自己 Node 上运行的服务的状态，并接受来自 Master Node 的指示采取调整措施。

• Kube-Proxy。K8S 的网络代理。私以为称呼为 Network-Proxy 可能更适合？Kube-Proxy 负责 Node 在 K8S 的网络通讯、以及对外部网络流量的负载均衡。

• Container Runtime。Worker Node 的运行环境。即安装了容器化所需的软件环境确保容器化程序能够跑起来，比如 Docker Engine。大白话就是帮忙装好了 Docker 运行环境。

• Logging Layer。K8S 的监控状态收集器。私以为称呼为 Monitor 可能更合适？Logging Layer 负责采集 Node 上所有服务的 CPU、内存、磁盘、网络等监控项信息。

• Add-Ons。K8S 管理运维 Worker Node 的插件组件。有些文章认为 Worker Node 只有三大组件，不包含 Add-On，但笔者认为 K8S 系统提供了 Add-On 机制，让用户可以扩展更多定制化功能，是很不错的亮点。

总结来看，K8S 的 Master Node 具备：请求入口管理（API Server），Worker Node 调度（Scheduler），监控和自动调节（Controller Manager），以及存储功能（etcd）；而 K8S 的 Worker Node 具备：状态和监控收集（Kubelet），网络和负载均衡（Kube-Proxy）、保障容器化运行环境（Container Runtime）、以及定制化功能（Add-Ons）。

到这里，相信你已经对 K8S 究竟是做什么的，有了大概认识。接下来，再来认识下 K8S 的 Deployment、Pod、Replica Set、Service 等，但凡谈到 K8S，就绕不开这些名词，而这些名词也是最让 K8S 新手们感到头疼、困惑的。

--

知识分享，时代前行！

~~ 时代Java

还有更多好文章……

请查看历史文章和官网，

↓有分享，有收获~