写到这里，k8s的内容已经到一半了，虽然后面的内容我觉得更加玄学一点。控制器真的是个神奇的东西，虽然后面的CRD会带着大家一起做一个控制器，但是还是觉得很奇妙。
控制器大概就是k8s中的精华了，通过控制器去监听k8s中api的请求，然后创建对应的资源。这个资源可以是应用业务的pod，也可以是用来管理集群的pod（如calico用来做网络）。
如果能够理解控制器和service服务，那么k8s中的很大部分东西都能够理清楚了。当然，还有其他的重要内容，如存储卷、资源、pod调度、升级备份以及自定义资源等等。
这一部分主要来讲一讲pod中的探针，探针是给容器做健康检查的，主要分为三种类型，存活探针、就绪探针和启动探针。这三种探针的功能作用不同，并且经常结合起来使用。每个探针的定义都是在容器中创建，如spec.containers.livenessprobe。
存活探针
首先来介绍一下spec.restartPolicy字段，用来控制pod内的容器的重启策略，是应用于所有的容器。如果是Always则是总是重启，如果是onFailure则是在失败的时候重启，如果是Never则永远不会重启。
如果重启次数过多，超过限制时，可能会导致pod的重建。
livenessProbes用来检测容器是否正常运行，可以使用exec来执行对应的命令或者使用httpGet来验证。如果容器非正常运行，则会杀死然后根据重启策略来决定是否重启容器。
可以定义探针在容器启动后多少秒开始探测，然后定义探测周期。
就绪探针
同样需要定义等待多少秒开始探测，然后定义探测周期。并且同样可以用httpGet或者tcpGet来探测容器是否就绪，如果探测失败，则会将该pod从service中的endpoints列表中（记录当前可路由的pod地址）。
不过注意的是存活探针会杀死容器，但是就绪探针不会，仅仅是控制流量路由，不影响容器的生命周期。并且会不断检测，当容器就绪的时候会重新添加到endpoints列表中。
启动探针
由于有些容器初始化的时间可能比较长，仅仅使用就绪探针或者存活探针的延迟等待可能不够，所以由启动探针来等待容器初始化。
启动探针仅仅执行一次而不是周期性的，如果检测失败则会杀死容器并根据restartPolicy来决定是否重启。
优雅关闭
其实就是使用spec.terminationGracePeriodsSeconds来指定秒数，在pod要销毁的时候等待容器结束。如果超过这个时间容器还没有结束依旧会强制让容器下线的。
以上就是健康检测的全部内容，当然有些细节没说，比如具体是什么字段来约束。但是比较长就没写了。接下来打算继续写k8s中的配置存储卷，主要是emptyDir、hostPath、persistentVolume这三种，最后一个需要结合PVC来使用。
emptyDir
这个比较简单，主要是通过spec.volumes.emptyDir字段指示，可以指定大小（limitSize）。当然，实质其实是使用node节点上的临时目录作为存储卷的。
但是由于pod分配在哪个节点是不确定的，所以emptyDir的位置还需要具体分析。不过emptyDir不能够跨pod共享，即使在同一个节点上，因为临时目录在node上的位置也是不确定的。
hostPath
这个需要指定主机上的目录，并挂载到容器的挂载点上。同节点上的pod能够共享该目录，但是不能跨节点共享。
和临时目录不同的是，当pod删除时，hostPath上的文件目录不会自动删除。
由于不能跨节点共享的缺陷，而且pod的调度还是不确定的（除非配置好亲和性和容忍度），所以有更好的解决方案。
persistentVolume
这个属于一种资源，需要通过yml文件定义并创建。示例通过配置NFS共享存储卷，实现跨节点的共享，突破hostPath只能在节点内共享的限制。
由于使用了nfs，需要给每个节点安装nfs-common客户端才行，并且在共享目录的主机上（可以不是master，通过spec.nfs.server指定）安装nfs-server。
在共享主机上配置好/etc/exportfs文件，然后就可以编写定义persistentVolume的yml文件。但是pod如果要使用PV，还需要创建PVC，也就是持久卷申领。
persistentVolumeClaim
这也是k8s中的一种资源，需要在yml文件中使用标签选择器来关联PV。并且PVC的卷模式（filesystem和block）和访问模式(RWO)需要和PV保持一致。
要注意的是，不同的PV的访问模式，对于PV本身的使用有着很大的区别！ReadWriteOnce (RWO)模式：卷可被单个节点以读写模式挂载；ReadOnlyMany (ROX)模式：卷可被多个节点以只读模式挂载；ReadWriteMany (RWX)模式：卷可被多个节点以读写模式挂载。
当 PV 的访问模式为 ReadWriteMany (RWX) 或 ReadOnlyMany (ROX) 时，可以手动配置多个 PVC 指向同一个 PV。但需要确保PVC 的 storage 请求总量 ≤ PV 的容量，并且PV 必须是 Retain 回收策略。
不能使用Delete回收策略， 因为该策略删除 PVC 时 PV 会被自动删除，无法重复使用。Recycle 策略会在 PVC 删除时自动清空 PV 内的所有数据（执行 rm -rf），若多个 PVC 共享该 PV，删除任意一个 PVC 会导致其他 PVC 的数据突然丢失。
最后打算继续写一些k8s中的pod调度，主要包括亲和性、污点、容忍度等内容。这其实是三个章节的内容，但是不多所以我放在了一块。不过这个k8s系列已经写到5了，预计能够在10之前写完！
NodeSelector与NodeName
nodeSelector根据节点的标签进行选择，通过spec.nodeSelector.name来指明选择的节点标签。nodeName将pod仅调度到具有特定名称的节点上，通过spec.nodeName.name字段表明。不过这两种方式也受到污点的影响，即使通过标签或名称选择，如果不能容忍污点，也无法调度。
节点亲和性Affinity
不同于上面的强制选择，节点亲和性是pod的一种属性，它使pod能够被吸引到特定的节点上。上面提到的污点作用正相反，会排斥不能容忍该污点的pod。
节点亲和性有两种模式，一种是优先但不强制，使用spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution字段表示该模式，可以设置权重，以及具有哪些特征的节点优先。还有一种强制优先调度，使用spec.affinity.nodeAffinity.requriedDuringSchedulingIgnoredDuringExecution字段表示。
污点和容忍度
可以通过kubectl taint node <节点名> key=value:effect来标记污点，使用kubectl taint node <节点名> key=value:effect-来取消污点。effect有`NoSchedule`，`PreferNoSchedule`和`NoExecute`三种。
`NoSchedule`：新 Pod 不会被调度到该节点，已运行的 Pod 不受影响；`PreferNoSchedule`：尽量不调度，但若无其他可用节点仍可能调度。`NoExecute`：新 Pod 不调度，且已运行的 Pod 也会被驱逐，在`tolerationSeconds`指定的时间后被驱逐。若未设置 `tolerationSeconds`，则默认容忍 300 秒。
容忍度则应用于pod，允许调度器调度pod到能够容忍对应污点的节点上。使用spec.tolerations字段添加规则，不过即使容忍了该污点，也未必会被调度该节点上。
函数)