创建 nfs 的 storageClass 请跳到 Kubernetes–StorageClass(二)，因为 本文中的 NFS 仓库中的项目有点 bug ，对于新版 k8s 无法解决。不信邪你可以试试
在之前的文章 Kubernetes的数据管理 一文中，介绍了一些 volume 以及 PV 、 PVC 的使用方法，也被称为 静态 PV 供给，因为 PVC 是建立在 PV 的前提下，必须手动创建 PV ，再去创建 PVC 去匹配 PV 获取存储资源。
以上说到的方法中，对于大量 pod 的场景来说，维护成本相当大，对于运维人员也是不友好的。所以 k8s 支持了 PV 的动态供给 — StroageClass。也就是使用了 StorageClass 之后，不需要单独创建 PV，只需要创建 PVC ，就会根据 PVC 的申请自动创建一个 PV，也被称为 动态 PV 供给
据我当下所学，对于 Kubernetes 如何对外暴露服务，一个字—**service**，只要是集群内部要访问 pod，通过创建 service，可以做到使用ip访问，那如果想要对互联网提供服务，应该怎么去做，也不能一直使用 IP 访问，而且对于集群来说也是不安全的。本文提到的 Ingress 就是为了弥补 NodePort 存在的不足而生。
我们都知道 k8s 集群中 master 节点默认是存在不可调度的污点的，也就是普通的 pod 默认是不会被调度到 master 节点的，这也是 Taint(污点) 的作用。
在实际应用中，也可能会给 worker 节点也去添加污点，是为了达到避免 Pod 调度到特定的节点中。
本文将会介绍关于节点 Taint 的设置以及如何调度要具有 Taint 的节点
在之前的文章 labels控制pod运行位置 提到可以通过 nodeSelector来控制将pod运行到哪台集群节点。
本文中要使用的 nodeAffinity (节点亲和性)，其功能与 nodeSelector是类似的，也是根据节点标签来对 pod 进行调度启动
相比 nodeSelector ，nodeAffinity 更加的灵活，功能多，支持硬策略和软策略
之前的文章 Kubernetes 的 Health Check 一文中提到的健康检查的方式有三种，仅仅只用了 exec 一种方式来演示。
本文将使用一个 yaml 文件，展示 httpGet 和 tcpSocket 两种方式怎么使用，两者区别就是修改健康检查部分就可以
直接上示例
在之前的文章 Depolyment中提到的伸缩 ，是通过 Deployment 管理的 ReplicaSet 来手动控制 pod 的伸缩，而在刚接触 Kubernetes 时，就一直听到或者看到各种视频文章教程，都说K8S可以通过对资源利用率的判断，进行 pod 的自动伸缩。本文中，它来了。
Docker 企业级仓库 Harbor，根据该文章搭建两台服务器用作Harbor。
| HOSTNAME | IP | OS | Hard |
|---|---|---|---|
| harbor1 | 192.168.1.12 | Centos 7.6 | 4c4g |
| harbor2 | 192.168.1.13 | Centos 7.6 | 4c4g |
完成后在 harbor1 域名中添加 harbor2 的DNS记录，如果不添加的话，无法解析域名将不会复制成功
生产环境中，对于运维来说，可能不需要亲自去编写Dockerfile来构建镜像，大多数是研发部门来做这个事情，但我认为运维岗位有必要清楚Dockerfile的构建过程，再不济也应该知道运行这个image时，最后的进程是怎么样的，这会更有利于测试维护。
在我的公司来说，底层运维和研发是搭不上话的，更别说了解Dockerfile了，这就需要自己来研究。
今天客户让检查Kubernetes环境，说是环境起不来了，我通过远程ssh，结果发现ssh无法连接，客户方检查结果为内存oom溢出（环境已运行半年），因为是测试环境故而将服务器重启，内存被释放。然后我检查Kubernetes环境，发现大多数pod无法启动，状态为ImagePullBackOff和Evicted，还有NodeAffinity。
ImagePullBackOff：镜像下载失败，意味着本地没有镜像
Evicted：一般可以查看到
describe信息，我见过的此状态都是磁盘容量问题NodeAffinity：调度节点亲和性失败
相信有很多人都遇到过，无论是生产还是测试等各种环境，都有遇到过删除资源一直卡在Terminating状态的，有namespace/pv/pvc等各种资源
简单说一下原因，一般情况下，刚创建的资源，还未使用的时候删除，肯定可以删除成功。
偶然的一次机会，解决项目故障的分析过程中，看到项目中有研发团队写好的Dockerfile，居然出现了两个FORM，吸引了我的眼球。和我自己之前写过的文章 Dockerfile构建简单镜像 有所不同，决定一探究竟。
作为一个运维在编写自动化脚本时，希望在脚本头部添加自己的作者信息，又或者版权信息，但是每写一个脚本就添加一遍注释，就显得自己很呆，本身工作就是做的自动化，结果还是劳心劳肺。
在条件测试一文中，通过逻辑测试已经可以通过&&和||完成简单的条件判断，并执行相应的操作，但是当需要判断的条件过多时，就会显得逻辑测试的方法的代码复杂，不好理解。而使用if条件语句，就可以让代码结构清晰易懂。
Shell脚本就是命令的集合，这也是脚本最简单易懂的理解。脚本的运行，无非就是想让命令在什么条件下怎么样的执行。如果仅仅是根据命令的集合来完成脚本自动化，就会出现很多的意外的脚本中断。要想让脚本有自己的”思想”。如：在创建目录之前，要知道有没有同名目录，如果同名的情况下，肯定会报错的。
