K8S系列一：概念入门

在这里插入图片描述

写在前面

本文组织方式：

K8S的架构、作用和目的。需要首先对K8S整体有所了解。
K8S是什么？
为什么是K8S？
K8S怎么做？
K8S的重要概念，即K8S的API对象。要学习和使用K8S必须知道和掌握的几个对象。
Pod 实例
Volume 数据卷
Container 容器
Deployment 和 ReplicaSet
Service和Ingress
namespace 命名空间
其他

I. K8S概览

1.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）应用程序”的开源系统。

翻译成大白话就是：“K8S是负责自动化运维管理多个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中说的观点“嘛，写全称也太累了吧，不如整个缩写”。其实只保留首位字符，用具体数字来替代省略的字符个数的做法，还是比较常见的。

1.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）。

II. K8S重要概念

2.1 Pod实例

官方对于Pod的解释是：

Pod是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。

这样的解释还是很难让人明白究竟Pod是什么，但是对于K8S而言，Pod可以说是所有对象中最重要的概念了！因此，我们必须首先清楚地知道“Pod是什么”，再去了解其他的对象。

从官方给出的定义，联想下“最小的xxx单元”，是不是可以想到本科在学校里学习“进程”的时候，教科书上有一段类似的描述：资源分配的最小单位；还有”线程“的描述是：CPU调度的最小单位。什么意思呢？”最小xx单位“要么就是事物的衡量标准单位，要么就是资源的闭包、集合。前者比如长度米、时间秒；后者比如一个”进程“是存储和计算的闭包，一个”线程“是CPU资源（包括寄存器、ALU等）的闭包。

同样的，Pod就是K8S中一个服务的闭包。这么说的好像还是有点玄乎，更加云里雾里了。简单来说，Pod可以被理解成一群可以共享网络、存储和计算资源的容器化服务的集合。再打个形象的比喻，在同一个Pod里的几个Docker服务/程序，好像被部署在同一台机器上，可以通过localhost互相访问，并且可以共用Pod里的存储资源（这里是指Docker可以挂载Pod内的数据卷，数据卷的概念，后文会详细讲述，暂时理解为“需要手动mount的磁盘”）。笔者总结Pod如下图，可以看到：同一个Pod之间的Container可以通过localhost互相访问，并且可以挂载Pod内所有的数据卷；但是不同的Pod之间的Container不能用localhost访问，也不能挂载其他Pod的数据卷。
在这里插入图片描述

对Pod有直观的认识之后，接着来看K8S中Pod究竟长什么样子，具体包括哪些资源？

K8S中所有的对象都通过yaml来表示，笔者从官方网站摘录了一个最简单的Pod的yaml：

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo
  namespace: mem-example
spec:
  containers:
 - name: memory-demo-ctr
    image: polinux/stress
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]
    volumeMounts:
    - name: redis-storage
      mountPath: /data/redis
  volumes:
 - name: redis-storage
    emptyDir: {}

看不懂不必慌张，且耐心听下面的解释：

apiVersion记录K8S的API Server版本，现在看到的都是v1，用户不用管。
kind记录该yaml的对象，比如这是一份Pod的yaml配置文件，那么值内容就是Pod。
metadata记录了Pod自身的元数据，比如这个Pod的名字、这个Pod属于哪个namespace（命名空间的概念，后文会详述，暂时理解为“同一个命名空间内的对象互相可见”）。
spec记录了Pod内部所有的资源的详细信息，看懂这个很重要：
containers记录了Pod内的容器信息，containers包括了：name容器名，image容器的镜像地址，resources容器需要的CPU、内存、GPU等资源，command容器的入口命令，args容器的入口参数，volumeMounts容器要挂载的Pod数据卷等。可以看到，上述这些信息都是启动容器的必要和必需的信息。
volumes记录了Pod内的数据卷信息，后文会详细介绍Pod的数据卷。

2.2 Volume 数据卷

K8S支持很多类型的volume数据卷挂载，具体请参见K8S卷。前文就“如何理解volume”提到：“需要手动mount的磁盘”，此外，有一点可以帮助理解：数据卷volume是Pod内部的磁盘资源。

其实，单单就Volume来说，不难理解。但是上面还看到了volumeMounts，这俩是什么关系呢？

volume是K8S的对象，对应一个实体的数据卷；而volumeMounts只是container的挂载点，对应container的其中一个参数。但是，volumeMounts依赖于volume，只有当Pod内有volume资源的时候，该Pod内部的container才可能有volumeMounts。

2.3 Container 容器

本文中提到的镜像Image、容器Container，都指代了Pod下的一个container。关于K8S中的容器，在2.1Pod章节都已经交代了，这里无非再啰嗦一句：一个Pod内可以有多个容器container。

在Pod中，容器也有分类，对这个感兴趣的同学欢迎自行资料：

标准容器 Application Container。
初始化容器 Init Container。
边车容器 Sidecar Container。
临时容器 Ephemeral Container。

一般来说，我们部署的大多是标准容器（ Application Container）。

2.4 Deployment 和 ReplicaSet（简称RS）

除了Pod之外，K8S中最常听到的另一个对象就是Deployment了。那么，什么是Deployment呢？官方给出了一个要命的解释：

一个 Deployment 控制器为 Pods 和 ReplicaSets 提供声明式的更新能力。你负责描述 Deployment 中的
目标状态，而 Deployment 控制器以受控速率更改实际状态，使其变为期望状态。你可以定义 Deployment 以创建新的
ReplicaSet，或删除现有 Deployment，并通过新的 Deployment 收养其资源。

翻译一下：Deployment的作用是管理和控制Pod和ReplicaSet，管控它们运行在用户期望的状态中。哎，打个形象的比喻，Deployment就是包工头，主要负责监督底下的工人Pod干活，确保每时每刻有用户要求数量的Pod在工作。如果一旦发现某个工人Pod不行了，就赶紧新拉一个Pod过来替换它。

新的问题又来了：那什么是ReplicaSets呢？

ReplicaSet 的目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合。因此，它通常用来保证给定数量的、完全相同的
Pod 的可用性。

再来翻译下：ReplicaSet的作用就是管理和控制Pod，管控他们好好干活。但是，ReplicaSet受控于Deployment。形象来说，ReplicaSet就是总包工头手下的小包工头。

笔者总结得到下面这幅图，希望能帮助理解：
在这里插入图片描述
新的问题又来了：如果都是为了管控Pod好好干活，为什么要设置Deployment和ReplicaSet两个层级呢，直接让Deployment来管理不可以吗？

回答：不清楚，但是私以为是因为先有ReplicaSet，但是使用中发现ReplicaSet不够满足要求，于是又整了一个Deployment（有清楚Deployment和ReplicaSet联系和区别的小伙伴欢迎留言啊）。

但是，从K8S使用者角度来看，用户会直接操作Deployment部署服务，而当Deployment被部署的时候，K8S会自动生成要求的ReplicaSet和Pod。在K8S官方文档中也指出用户只需要关心Deployment而不操心ReplicaSet：

This actually means that you may never need to manipulate ReplicaSet
objects: use a Deployment instead, and define your application in the
spec section.
这实际上意味着您可能永远不需要操作ReplicaSet对象：直接使用Deployments并在规范部分定义应用程序。

补充说明：在K8S中还有一个对象 — ReplicationController（简称RC），官方文档对它的定义是：

ReplicationController 确保在任何时候都有特定数量的 Pod 副本处于运行状态。
换句话说，ReplicationController 确保一个 Pod 或一组同类的 Pod 总是可用的。

怎么样，和ReplicaSet是不是很相近？在Deployments, ReplicaSets, and pods教程中说“ReplicationController是ReplicaSet的前身”，官方也推荐用Deployment取代ReplicationController来部署服务。

2.5 Service和Ingress

吐槽下K8S的概念/对象/资源是真的多啊！前文介绍的Deployment、ReplicationController和ReplicaSet主要管控Pod程序服务；那么，Service和Ingress则负责管控Pod网络服务。

我们先来看看官方文档中Service的定义：

将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法。使用 Kubernetes，您无需修改应用程序即可使用不熟悉的服务发现机制。
Kubernetes 为 Pods 提供自己的 IP 地址，并为一组 Pod 提供相同的 DNS 名，并且可以在它们之间进行负载均衡。

翻译下：K8S中的服务（Service）并不是我们常说的“服务”的含义，而更像是网关层，是若干个Pod的流量入口、流量均衡器。
那么，为什么要Service呢？

私以为在这一点上，官方文档讲解地非常清楚：

Kubernetes Pod 是有生命周期的。它们可以被创建，而且销毁之后不会再启动。如果您使用 Deployment
来运行您的应用程序，则它可以动态创建和销毁 Pod。每个 Pod 都有自己的 IP 地址，但是在 Deployment
中，在同一时刻运行的 Pod 集合可能与稍后运行该应用程序的 Pod 集合不同。这导致了一个问题：如果一组
Pod（称为“后端”）为群集内的其他 Pod（称为“前端”）提供功能，那么前端如何找出并跟踪要连接的 IP
地址，以便前端可以使用工作量的后端部分？

补充说明：K8S集群的网络管理和拓扑也有特别的设计，以后会专门出一章节来详细介绍K8S中的网络。这里需要清楚一点：K8S集群内的每一个Pod都有自己的IP（是不是很类似一个Pod就是一台服务器，然而事实上是多个Pod存在于一台服务器上，只不过是K8S做了网络隔离），在K8S集群内部还有DNS等网络服务（一个K8S集群就如同管理了多区域的服务器，可以做复杂的网络拓扑）。

此外，笔者推荐k8s外网如何访问业务应用对于Service的介绍，不过对于新手而言，推荐阅读前半部分对于service的介绍即可，后半部分就太复杂了。我这里做了简单的总结：

Service是K8S服务的核心，屏蔽了服务细节，统一对外暴露服务接口，真正做到了“微服务”。举个例子，我们的一个服务A，部署了3个备份，也就是3个Pod；对于用户来说，只需要关注一个Service的入口就可以，而不需要操心究竟应该请求哪一个Pod。优势非常明显：一方面外部用户不需要感知因为Pod上服务的意外崩溃、K8S重新拉起Pod而造成的IP变更，外部用户也不需要感知因升级、变更服务带来的Pod替换而造成的IP变化，另一方面，Service还可以做流量负载均衡。

但是，Service主要负责K8S集群内部的网络拓扑。那么集群外部怎么访问集群内部呢？这个时候就需要Ingress了，官方文档中的解释是：

Ingress 是对集群中服务的外部访问进行管理的 API 对象，典型的访问方式是 HTTP。 Ingress 可以提供负载均衡、SSL
终结和基于名称的虚拟托管。

翻译一下：Ingress是整个K8S集群的接入层，复杂集群内外通讯。

最后，笔者把Ingress和Service的关系绘制网络拓扑关系图如下，希望对理解这两个概念有所帮助：
在这里插入图片描述

2.6 namespace 命名空间

和前文介绍的所有的概念都不一样，namespace跟Pod没有直接关系，而是K8S另一个维度的对象。或者说，前文提到的概念都是为了服务Pod的，而namespace则是为了服务整个K8S集群的。

那么，namespace是什么呢？

上官方文档定义：

Kubernetes 支持多个虚拟集群，它们底层依赖于同一个物理集群。这些虚拟集群被称为名字空间。

翻译一下：namespace是为了把一个K8S集群划分为若干个资源不可共享的虚拟集群而诞生的。

也就是说，可以通过在K8S集群内创建namespace来分隔资源和对象。比如我有2个业务A和B，那么我可以创建ns-a和ns-b分别部署业务A和B的服务，如在ns-a中部署了一个deployment，名字是hello，返回用户的是“hello a”；在ns-b中也部署了一个deployment，名字恰巧也是hello，返回用户的是“hello b”（要知道，在同一个namespace下deployment不能同名；但是不同namespace之间没有影响）。前文提到的所有对象，都是在namespace下的；当然，也有一些对象是不隶属于namespace的，而是在K8S集群内全局可见的，官方文档提到的可以通过命令来查看，具体命令的使用办法，笔者会出后续的实战文章来介绍，先贴下命令：

# 位于名字空间中的资源
kubectl api-resources --namespaced=true

# 不在名字空间中的资源
kubectl api-resources --namespaced=false

不在namespace下的对象有：
在这里插入图片描述
在namespace下的对象有（部分）：

2.7 其他

K8S的对象实在太多了，2.1-2.6介绍的是在实际使用K8S部署服务最常见的。其他的还有Job、CronJob等等，在对K8S有了比较清楚的认知之后，再去学习更多的K8S对象，不是难事。

写在后面

本文是K8S系列文章第一篇，希望能够帮助对K8S不了解的新手快速了解K8S。如果文章中有纰漏，非常欢迎留言或者私信指出；有理解错误的地方，更是欢迎留言或者私信告知。

笔者一边写文章，一边查阅和整理K8S资料，过程中越发感觉K8S架构的完备、设计的精妙，是值得深入研究的，K8S大受欢迎是有道理的！再次感叹下。