简单介绍k8s中的几个基础概念

写在前面

前面的博文对docker的基本概念和使用进行了简单的介绍（见参考），解决了开发测试环境与运行时环境不一致的问题。只要镜像在本地开发环境能够正常运行且测试通过，理论上这个镜像也能在生产环境正常使用。

k8s解决的是另一个问题。假设为了快速迭代，我们把系统拆分成几十个子服务，每个子服务打包成一个镜像，这几十个镜像协同向用户提供服务；这样做我们就可以单独对某个子服务进行升级，而不影响其他子服务的运行。那么，有没有好的方式管理这几十个镜像的部署呢，又该如何管理这些镜像之间的相互调用关系？

k8s解决的便是docker镜像及其服务编排复杂的问题。它为运维开发提供了一个统一的接口，管理机器，部署应用，管理副本数量，负载均衡，服务发现，等等。先不要贪多，我们先简单介绍一下k8s中的基本概念。

基本概念

通过对k8s的学习和使用，发现里面涉及的概念非常多，对于普通的开发者来说，可能很难一下子把握。不过顺着一定的思路理解，再多花一些时间琢磨，理解这些基本概念也不是什么困难的事情。

Cluster（集群）

提到k8s平台，大多数我们指的是一个k8s集群。所谓集群，是指k8s管理了很多物理机（或者云虚拟机），有这些机器的超级管理权限，k8s想在这些机器上面做什么就做什么。

k8s中主要包含两个角色：Master和Worker。从名称不难理解，Master是k8s的大脑，所有的管理及元数据保存皆由Master负责；Worder是k8s的主要工作者，k8s调度的服务大都在上面运行。

Node（节点）

Node就是我们上面提到的物理机或者云虚拟机，在搭建k8s集群时，会选择一些（一般为3个）作为Master节点，剩余的便是Worker节点。

如果是生产环境的机器，一般只让Master节点负责调度，并不会跑业务的服务。因此Master节点的性能相对可以比Worker节点逊色；而Worker节点主要负责出力，性能比Master高一些。

Pod

用docker打好镜像，并被部署到k8s以后，它的运行时便在Pod中进行。

我们可以把Pod看做是k8s管理的轻量级的虚拟机。和普通虚拟机不同，k8s管理的Pod会共享Node上的内核，只运行那些必要的进程，有点类似docker中的 Container (容器)概念。但是要注意，Pod 又和 Container 不一样，因为一个Pod上可以运行多个Container。

Service（服务）

当访问量很多的时候，如果只有一个Pod可能不够用，利用k8s可以很方便地扩展出几个甚至几十个Pod。当Pod很多的时候，就需要一个提供负载均衡的地方，能够把用户的请求发送到这些Pod。Service便可以实现这个功能。

Service能够根据标签找到所有相关的Pod，并把这些Pod的IP收集记录下来，当有请求发送到Service时，Service会再把请求负载均衡到各个Pod。

Volume（卷）

每个Pod被k8s调度，当其中一个因为故障重启，里面的文件也会随之”蒸发“掉，这时候就需要把其中的文件给持久化到某个地方。

在k8s中就是通过Volume挂载持久盘到Pod中的。

Namespace（命名空间）

如果把所有的应用部署在k8s上，当应用多的时候，很难区分哪个是哪个。

Namespace可以从逻辑上把不同的应用区分开，比如小组A开发所有应用部署在group-a命名空间，小组B开发的所有应用部署在group-b命名空间，通过设置让小组A的成员只能访问group-a，小组B的成员只能访问group-b，这样管理起来就方便很多了。

小结

本文简单介绍了k8s中的几个静态的概念：Cluster、Node、Pod、Service、Volume以及Namespace。不过k8s中还包含成百上千的概念，只知道上面几个概念远远不够的。

如果根据官方的课程，比如Kubernetes Basics，可以很快地在k8s中部署一个应用。不过，就k8s中所包含的众多的概念，想要在生产中使用k8s，需要很深的技术储备才行。可以认为k8s是一个集权的管理平台，而作为一个系统，如果其本身出现一个故障，那么部署在上面的所有服务有可能都会出现问题，也就是说k8s在提供便易的同时把风险也叠加了。这就需要维护k8s平台的同学对它有很深的理解才行。

不过，k8s的使用是一个趋势，尤其在人工成本逐渐升高的当下。有了k8s的加持，理论上就可以把复杂的应用尽可能地拆分，每个服务拆分成开发人员都容易理解维护的模块，这样对企业来说招人、换人的成本也就不会那么高了。

参考