Kubernetes入门——基本概念篇

0、前言

今年参加的夏令营，选择的是云计算方向，要求搭建kubernetes集群，菜鸟的我连kubernetes是啥都不知道……
从网上找了各种资料，结合自己的一些理解，先学习一下kubernetes吧

1、背景知识

官方文档描述为：

Kubernetes一个用于容器集群的自动化部署、扩容以及运维的开源平台。通过Kubernetes,你可以快速有效地响应用户需求;快速而有预期地部署你的应用;极速地扩展你的应用;无缝对接新应用功能;节省资源，优化硬件资源的使用。为容器编排管理提供了完整的开源方案。

总的来说，Kubernetes是用于自动部署、扩展和容器化应用程序的开源系统。
因此我们要了解Kubernetes，首先要明白容器的概念，以及常说的Docker是什么。

1.1、容器

容器技术的官方定义是：

容器是通过一种虚拟化技术来隔离运行在主机上不同进程，从而达到进程之间、进程和宿主操作系统相互隔离、互不影响的技术。

要理解这个定义，首先要弄清楚容器和虚拟机的区别：
简单来说，虚拟机是一个机器，但容器是一个进程。每一个虚拟机里面都有一套完整的操作系统，而容器层安装在操作系统之上，它直接利用了宿主机的内核，更加轻量化，启动速度极快。通常，我们在会每个容器里面跑单个的应用，而在虚拟机里会跑很多应用。
容器技术具有：简化部署、快速启动、服务组合、易于迁移等优点。
容器技术最早应用在Linux操作系统，称为Linux Container(LXC)，早期在互联网公司开始使用部署分布式应用，随后随着容器管理器（Docker、Rocket和CloudFoundary Garden）兴起，定制容器宿主操作系统(CoreOS、Ubuntu Snappy、Red Hat Atomic)盛行，容器被有效构建和管理、并在各行各业普遍使用和认可。

1.2、docker

Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。Docker容器十分轻量。
Docker把容器变得标准化了，我们现在常说的容器一般是指Docker容器。
要理解Docker，需要明白三个最主要的概念：容器、镜像、仓库。

• 容器是运行在虚拟机上的进程（前面已经介绍过了）。
• 镜像是一种存储形式，可以理解为数据或应用的副本。
• 仓库是用来存储镜像的。

Docker能够普遍使用起来，很大程度上个得益于Docker的仓库里汇集了很多已经标准化的镜像，大大提升了部署效率。

1.3、什么是Kubernetes

Kubernetes是一个开源的 Linux容器自动化运维（操作）平台，这些操作包括部署，调度和节点集群间扩展。
可以将Docker看成Kubernetes内部使用的低级别组件。Kubernetes不仅仅支持Docker，还支持Rocket，这是另一种容器技术。换一句话说kubernetes负责管理服务中所有的Docker容器，创建、运行、重启与删除容器。

小知识: 因kubernetes名字过长，一般简称为k8s，因为k与s之间有8个字母，故而称之。

使用Kubernetes可以：

• 自动化容器的部署和复制
• 随时扩展或收缩容器规模
• 将容器组织成组，并且提供容器间的负载均衡
• 很容易地升级应用程序容器的新版本
• 提供容器弹性，如果容器失效就替换它，等等…

上文提到，Kubernetes是用于自动部署、扩展和容器化应用程序的开源系统。
当我们使用的容器服务多了，面临的访问量增大以后，我们就需要一种工具把这些容器统一的管理起来，需要实现对这些容器的自动部署、扩展和管理。也就是俗称的容器编排。Kubernetes就是这样一种容器编排系统。
上图是Kubernetes的架构图（摘自一篇博客）。
从大的模块看，图中包含Master组件(APIs, scheduler, etc)，Node节点和cloud端。
Cloud端作为集群外部的附加能力，通过与cloud-controller-manager组件对接，扩展k8s集群云上动态扩展的特性。
关于cloud这一部分不做详细叙述，核心概念部分的重点在于master节点和node节点。

2、核心概念

Kubernetes集群由两类节点组成：Master和Node。
在Master上运行etcd、API Server、Controller Manager和Scheduler四个组件，其中后三个组件构成了Kubernetes的总控中心，负责对集群中所有资源进行管理和调度。
在每个Node上运行Kubelet、Proxy和Docker Daemon三个组件，负责对本节点上的Pod（Pod是什么请看下文）的生命周期进行管理，以及实现服务代理的功能。
另外在所有节点上都可以运行Kubectl命令行工具，它提供了Kubernetes的集群管理工具集。

2.1、整体架构

master节点是Kubernetes的大脑，而node节点则是kubernetes中实际运行服务的劳动者。两个部分是通过API server来进行交互的。
下面的架构图选自另一篇博客。

2.2、master节点

master：控制 Kubernetes 节点的机器，也是创建作业任务的地方。

• etcd：
  主要负责存储各个node节点的状态和其它相关数据，可以理解为kubernetes的数据库。
• API server：
  提供可以用来和集群交互的REST端点。
• Controller Manager：
  负责维护集群的状态，比如故障检测、自动扩展、滚动更新等
• Scheduler：
  负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上

2.3、node节点

node：在master的控制下执行被分配的任务。

• kubelet
  负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；
• kube-proxy
  负责为Service提供cluster内部的服务发现和负载均衡；
• kube-dns
  负责为整个集群提供DNS服务，通过Service名称访问相应的服务

2.4、其他概念

这里要引用另一篇文章的图了：

2.4.1、集群

集群是一组节点，这些节点可以是物理服务器或者虚拟机，之上安装了Kubernetes平台。上图展示这样的集群。

2.4.2、volume（存储卷）

Volume是Pod中能够被多个容器访问的共享目录。Kubernetes的Volume概念与Docker的Volume比较类似，但不完全相同。Kubernetes中的Volume与Pod生命周期相同，但与容器的生命周期不相关。当容器终止或者重启时，Volume中的数据也不会丢失。另外，Kubernetes支持多种类型的Volume，并且一个Pod可以同时使用任意多个Volume。
Kubernetes提供了非常丰富的Volume类型，下面逐一进行说明。
（1）EmptyDir：一个EmptyDir Volume是在Pod分配到Node时创建的。从它的名称就可以看出，它的初始内容为空。在同一个Pod中所有容器可以读和写EmptyDir中的相同文件。当Pod从Node上移除时，EmptyDir中的数据也会永久删除。
（2）hostPath：在Pod上挂载宿主机上的文件或目录。
（3）gcePersistentDisk：使用这种类型的Volume表示使用谷歌计算引擎（Google Compute Engine，GCE）上永久磁盘（Persistent Disk，PD）上的文件。与EmptyDir不同，PD上的内容会永久保存，当Pod被删除时，PD只是被卸载（Unmount），但不会被删除。需要注意的是，你需要先创建一个永久磁盘（PD）才能使用gcePersistentDisk。
（4）awsElasticBlockStore：与GCE类似，该类型的Volume使用Amazon提供的Amazon Web Service（AWS）的EBS Volume，并可以挂在到Pod中去。需要注意到是，需要首先创建一个EBS Volume才能使用awsElasticBlockStore。
（5）nfs：使用NFS（网络文件系统）提供的共享目录挂载到Pod中。在系统中需要一个运行中的NFS系统。
（6）iscsi：使用iSCSI存储设备上的目录挂载到Pod中。
（7）glusterfs：使用开源GlusterFS网络文件系统的目录挂载到Pod中。
（8）rbd：使用Linux块设备共享存储（Rados Block Device）挂载到Pod中。
（9）gitRepo：通过挂载一个空目录，并从GIT库clone一个git respository以供Pod使用。
（10）secret：一个secret volume用于为Pod提供加密的信息，你可以将定义在Kubernetes中的secret直接挂载为文件让Pod访问。secret volume是通过tmfs（内存文件系统）实现的，所以这种类型的volume总是不会持久化的。
（11）persistentVolumeClaim：从PV（PersistentVolume）中申请所需的空间，PV通常是一种网络存储，例如GCEPersistentDisk、AWSElasticBlockStore、NFS、iSCSI等。

2.4.3、pod

Pod（上图绿色方框）安排在节点上，包含一组容器和卷。同一个Pod里的容器共享同一个网络命名空间，可以使用localhost互相通信。Pod是短暂的，不是持续性实体。
因此会有这些问题：

• 如果Pod是短暂的，那么怎么才能持久化容器数据使其能够跨重启而存在呢？
  答：Kubernetes支持卷的概念，因此可以使用持久化的卷类型。
• 是否手动创建Pod，如果想要创建同一个容器的多份拷贝，需要一个个分别创建出来么？
  答：可以手动创建单个Pod，但是也可以使用Replication Controller使用Pod模板创建出多份拷贝，下文会详细介绍。
• 如果Pod是短暂的，那么重启时IP地址可能会改变，那么怎么才能从前端容器正确可靠地指向后台容器呢？
  答：这时可以使用Service，下文会详细介绍。

2.4.4、label

Label是Kubernetes系统中的一个核心概念。Label以 key / value 键值对的形式附加到各种对象上，如Pod、Service、RC、Node等。Label定义了这些对象的可识别属性，用来对它们进行管理和选择。Label可以在创建时附加到对象上，也可以在对象创建后通过API进行管理。
在为对象定义好Label后，其他对象就可以使用Label Selector（选择器）来定义其作用的对象了。
Label Selector的定义由多个逗号分隔的条件组成。

“labels”: { “key1”: “value1”, “key2”: “value2” }

当前有两种Label Selector：基于等式的（Equality-based）和基于集合的（Set-based），在使用时可以将多个Label进行组合来选择。

• 基于等式的Label Selector使用等式类的表达式来进行选择：
  name = redis-slave: 选择所有包含Label中key="name"且value="redis-slave"的对象；
  env != production: 选择所有包括Label中的key="env"且value不等于"production"的对象。
• 基于集合的Label Selector使用集合操作的表达式来进行选择：
  name in (redis-master, redis-slave): 选择所有包含Label中的key="name"且value="redis-master"或"redis-slave"的对象；
  name not in (php-frontend): 选择所有包含Label中的key="name"且value不等于"php-frontend"的对象。

在某些对象需要对另一些对象进行选择时，可以将多个Label Selector进行组合，使用逗号","进行分隔即可。基于等式的LabelSelector和基于集合的Label Selector可以任意组合。例如：

name=redis-slave,env!=production name not in
(php-frontend),env!=production

2.4.5、Replication Controller

Replication Controller确保任意时间都有指定数量的Pod“副本”在运行。如果为某个Pod创建了Replication Controller并且指定3个副本，它会创建3个Pod，并且持续监控它们。如果某个Pod不响应，那么Replication Controller会替换它，保持总数为3。
过程如下面的动画所示：
如果之前不响应的Pod恢复了，现在就有4个Pod了，那么Replication Controller会将其中一个终止保持总数为3。
如果在运行中将副本总数改为5，Replication Controller会立刻启动2个新Pod，保证总数为5。
还可以按照这样的方式缩小Pod，这个特性在执行滚动升级时很有用。
当创建Replication Controller时，需要指定两个东西：

• Pod模板：用来创建Pod副本的模板
• Label：Replication Controller需要监控的Pod的标签。

2.4.6、Service

Service是定义一系列Pod以及访问这些Pod的策略的一层抽象。Service通过Label找到Pod组。因为Service是抽象的，所以在图表里通常看不到它们的存在，这也就让这一概念更难以理解。

现在，假定有2个后台Pod，并且定义后台Service的名称为‘backend-service’，lable选择器为（tier=backend, app=myapp）。backend-service 的Service会完成如下两件重要的事情：

• 会为Service创建一个本地集群的DNS入口，因此前端Pod只需要DNS查找主机名为 ‘backend-service’，就能够解析出前端应用程序可用的IP地址。
• 现在前端已经得到了后台服务的IP地址，但是它应该访问2个后台Pod的哪一个呢？Service在这2个后台Pod之间提供透明的负载均衡，会将请求分发给其中的任意一个（如下面的动画所示）。通过每个Node上运行的代理（kube-proxy）完成。这里有更多技术细节。

下述动画展示了Service的功能。注意该图作了很多简化。如果不进入网络配置，那么达到透明的负载均衡目标所涉及的底层网络和路由相对先进。

参考链接

《十分钟带你理解Kubernetes核心概念》
《关于kubernetes（k8s），这可能是讲的最通俗易懂的一次了》
《k8s基本概念及使用》
《一、Kubernetes简介-是什么？》