方亮的专栏

在中，我们讲了就绪探针和服务之间的特殊关系。就绪探针检测失败并不代表整个程序处于“非存活”状态，可能只是短暂临时的不可以提供服务，比如CPU阶段性占满，导致就绪探针检测超时而导致失败。这个时候就绪探针并不会向存活探针那样尝试重启容器，而只是简单的把它从何它关联的Service中摘除。

启动（Startup Probe）、存活（Liveness Probe）和就绪探针(Readiness Probe)有其不同的用途和优先级。

一文中介绍的更简单的方法控制一个Node上只有一个Pod，那就是使用DaemonSet。通过上述清单文件创建Pod。可以看到每个Node都被部署了一个Pod。

初始化容器用于运行一次就可以退出的业务场景，而普通容器则要一直有前台程序在运行。

在一文中，我们利用Node亲和性，让Pod部署在节点ubuntud上。因为Pod使用的PVC可以部署在节点ubuntuc或者ubuntud上，而系统为了让Pod可以部署成功，则让PVC与Pod亲和的ubuntud上的PV绑定。这样Pod在自身节点亲和性和PVC上都满足了条件。在一些业务场景下，我们通过磁盘来保存数据，而程序通过数据设置自身状态。如果一旦一个Pod崩溃，我们希望新补充的Pod可以延续之前的状态。这个时候我们就可以使用PV的节点亲和性来完成上述调度。

不同的PV可以使用相同的StorageClass，它们是一对多的关系。PV可以设置节点亲和性。比如下图，local-storage-class-waitforfirstconsumer-pv-ubuntuc只能在节点ubuntuc上；local-storage-class-waitforfirstconsumer-pv-ubuntud只能在节点ubuntud上。如果我们使用一文中的“立即绑定”型的StorageClass。则在创建PVC时，立即会选择一个PV。

除了中介绍的使用Label做选择因子外，PVC还可以通过storageClassName选择符合条件的PV。StorageClass的设计是用于描述如何动态创建PV。最开始时，管理员需要一次性申请好所有的PV，使用者只要设计PVC申请PV绑定即可。但是如果一旦PV不够用了，管理员又要手工去申请PV来满足需求。为了降低管理员的工作，StorageClass可以动态去创建PV，即PVC发现PV不够后，直接通过其指定的storageClassName来动态申请PV。动态申请PV的内容我们会在《》中介绍。

在和中，我们介绍了指定VPC的spec.volumeName为PV名称来绑定它们的方法。本文将介绍PVC在创建时，系统自动选择绑定哪个PV。在设计上，PV是系统管理员分配的，它用于隔绝具体是哪种介质。比如一些PV来源于谷歌云，一些PV来源于阿里云，还有一些PV来源于AWS。使用者只要通过PVC向其申请使用即可。申请时可以通过spec.volumeName指定特定名称PV，还可以使用spec.selector在一堆PV中选择符合条件的PV。

在一文中，我们使用了hostPath类型卷在一个Node上实现了不同Pod的数据共享。本节我们将使用local型持久卷（PV）来实现。

PV全称是PersistentVolume，即持久卷，是由管理员事先准备好的资源。它可以是本地磁盘，也可以是网络磁盘。PVC全称是PersistentVolumeClaim，即持久卷申领。它表示卷的使用者，对PV的申请。即我们可以认为，PV是整体，PVC是申请其中的部分。

有别于一文中介绍的emptyDir，hostPath可以在卷。下面的清单文件利用了Pod亲和性，让Pod集中到一个Node上。我们观察创建的两个Pod中文件的内容…………可以看到它们的文件内容一样，即可以证明它们可以共享同一个文件。我们在hostpath映射的宿主机目录/tmp下可以找到lockfile文件，且其内容也是明文可读的。

kubernets可以通过emptyDir实现在共享文件系统。正如它的名字，当Pod被创建时，emptyDir卷会被创建，这个时候它是一个空的文件夹；当Pod被删除时，emptyDir卷也会被删除。

在一文中我们介绍了Pod的反亲和性应用。本节我们将使用亲和性做几个实验。nginx Pod在每个Node上只能存在一个；alpine Pod在每个Node上只能存在一个，同时要求该Node上还要有nginx Pod。

在和中，我们介绍了Node的亲和性。后面几节我们将介绍Pod的亲和性和反亲和性。Pod的亲和性和反亲和性通过Pod的标签来识别，而不是通过Node的标签。比如标题中“利用Pod反亲和性控制一个Node上只能有一个Pod”可以翻译成：只能将Pod调度到不存在该Pod标签的Node上。

requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms.matchExpressions之间是取或的关系，即只要满足其中一个条件就可以被调度到。没有匹配的条件，Pod会被创建，但是处于Pending状态，不会被部署到任何一个Node上。如果Pod已经在Node上运行，此时删除Node匹配上的Label，Deployment不会终止该Pod。

在中我们提到亲和性（affinity）中的requiredDuringSchedulingIgnoredDuringExecution，它可以定向调度Pod。本节我们将使用相关特性完成定向调度的介绍。

在中，有一次Pod被分配到Master Node——UbuntuA上。进一步的实验需要我们关闭其所在的Node，而Master Node又不能关闭，否则我们将无法对Kubernetes进行操作。这个时候我只能使用Pod调度技法来将其从Master Node上驱逐。

总结下：Node失效后，Kubernetes并不会自动将其摘除，而是一直等待它可用。失效后的Node在重启后，会自动向Kubernetes Master Node(本例中是Node UbuntuA)请求恢复。相应的，如果此时Deployment没有将原本在失效Node上的Pod设置为终止（Terminating）状态，则则Pod会就地恢复（IP会变动）；如果设置为终止状态，则老的Pod会失效，Deployment会使用新启动的Pod。

在中，我们创建了Master Node: UbunutA，以及四个Worker Node:UbunutB、UbunutC、UbunutD和UbunutE。本节我们将使用Deployment创建只含有一个nginx的Pod，然后关掉它所在的主机以模拟Node失效，观察kubernetes在这种情况下的表现。

在之前的系列中，我们都是在单Node上“玩转”kubernetes，熟悉了它很多指令和特性。从本节开始，我们开始探索多Worker Node的相关特性。

依据微服务理念，我们希望每个独立的功能由一个服务支持。比如有两个接口：http://www.xxx.com/plus和http://www.xxx.com/minus，前者由一个叫plus-service的服务支持，后者由一个叫minus-service的服务支持。这样就需要一个路由层，在前方将/plus请求路由到plus-service；将/minus路由到minus-service。本文介绍的ingress就可以起到路由的作用。我们借用。

测试容器并不是什么都没有的容器，只是它没有我们期望的常驻进程。我们常用它来做一些测试。举个例子，在中我们使用本地wrk进行了压力测试。如果我们希望进入容器手工调用wrk，该怎么做呢？

定时任务是指可以制定周期的任务，比如每周二0点1分执行一次。在中，我们介绍了单次执行的任务。现在我们只要对其清单稍作修改，就可以实现定时任务。和单次任务清单相比，主要的修改点是：新增了spec.schedule字段。它用于描述周期。可以见得，我们可以控制的最短周期是分钟。在表达式中，*表示”所有”。我们还可以使用来查看表达式的表意。比如例子中的*/1 * * * *表达的是每一分钟执行一次。我们使用下面指令创建cronjob。可以看到每隔一分钟，我们创建了一个Job；

在一文中，我们使用在本地使用wrk进行了压力测试。如果我们希望在容器中运行，该怎么做呢？

在一文中，我们通过Deployment实现了多副本维护——即维持在一个确定数量的副本个数。而在现实场景中，我们往往需要根据服务的压力，采用水平（横向）扩容的方式——即增加多个副本，来分担压力。当服务压力降低时，又需要减少副本数来节约成本。本节我们将介绍如何根据服务压力进行自动的扩缩容。

在一个Pod中，可以有多个容器，比如一个主要业务容器和若干辅助业务容器。如果辅助业务容器内程序有问题，导致占用了大量的CPU资源，进而影响了主要业务容器的执行效率，那就需要进行干涉了。本节我们将使用“资源配额”来限制容器的CPU使用。

在中，Pod的IP是通过代码获取的实际我们可以在清单文件中，通过环境变量将该值传递给容器中的程序。

软件升级是一件非常常见的事，本节我们将尝试使用Deployment进行软件升级。

多副本维护是指，对一组在任何时候都处于运行状态的 Pod 副本的稳定集合进行维护。说的直白点，就是保证某种的Pod数量会被自动维持——增加了该类Pod会自动删除多余的，减少了该类Pod会自动新增以弥补，以保证Pod数量不变。Kubernetes是一个一直在迭代更新的系统，其多副本维护方案也经历了几个版本大的改动。本文将采用最新的Deployment方案，而不是老版本的ReplicaSet和ReplicationController。

在一文中，我们使用kubectl expose创建了一个Service，暴露了一个Pod上的nginx服务。这篇文章我们将使用文件的形式创建Service。为了增加有趣性，我们采用中的镜像部署两个Pod。这两个Pod有不同的Cluster IP（kubernetes内部IP），而Service将同时暴露这两个Pod上的服务。这样我们访问Service时，将通过打印出来的IP得知本次请求被分配到哪个Pod上。

我们使用kubectl run命令启动了一个可以在kubernetes集群内部访问的nginx——它不可以通过物理机访问。而我们使用文件创建时，则可以通过设置相关参数，让nginx可以通过物理机地址访问。

这几节我们都是使用microk8s学习kubernetes，于是镜像库我们也是使用它的插件——registry。

Hyper-V上Ubuntu Desktop版的分辨率很低，不能完全展示dashboard。由于上述地址是kubernetes内部地址，不是Ubuntu Desktop虚拟机的地址，我们就在虚拟机内部访问。对GRUB_CMDLINE_LINUX_DEFAULT的内容进行修改，新增分辨率信息（本例以1920*1440）。由于dashboard是在kube-system的namespace中，我们可以使用下面指令查看它服务的地址。然后选择对应的命名空间（namespace），就可以看到相关资源了。

Kubernetes是容器的管理编排工具，而容器则是程序的载体。我们先在Docker上部署应用，然后再在kubernetes上部署，并对它们进行对比学习。

研发工程师玩转Kubernetes》将立足于实操，试图由浅入深探索Kubernetes世界。于是在技术选型和内容上也将由易到难，由简单到复杂。为了降低进入的门槛，我们前期将不考虑多实例（机器）的部署，而采用单机部署。这样可以更加贴近研发人员的工作，并和运维工作拉开一定的距离，以方便研发人员学习和理解。