Ⅰ 记一次k8s集群节点镜像存储容量报警问题
自从我们的kubernetes集群部署到生产环境后，将流量从原有的服务器上切过来之后，部分节点出现挂载目录容量爆满的情况。
运维的同事报给我们之后，我们首先想到的是节点镜像过多，于是我们提供一个命令用于清理当前节点上无用的、报错的、镜像和docker资源文件
docker system prune 命令可以用于清理磁盘，删除关闭的容器、无用的数据卷和网络，以及dangling镜像(即无tag的镜像)
docker system prune -a 命令清理得更加彻底，可以将没有容器使用Docker镜像都删掉。
待运维执行之后，目录存储资源释放了一些，我们本以为这就告一李亩友段落了。然而，事与愿违，没过多久，再次容量报警。。。
我们开始重视起来，开始检视节点上工作的容器，发现在日志爆炸的节点上运行了定时任务，开发人员将定时任务的日志输出到控制台，于是我们回到节点docker的工作目录，通过 -sh * 方式查看每个文件夹大小，发现docker目录下containers目录占用空间巨大，进去看原来是每个运行的容器存放日志的目录，我们找出占用空间最大的日志目录，发现容器日志特别的大
我们可使用如下命令查看各个日志的文件大小
ls -lh $(find /var/lib/docker/containers/ -name *-json.log)
那我们如何清理日志呢，如果docker容器正在运行，那么使哪槐用rm -rf 方式删除日志后，通过df -h会发现磁盘空间并没有释放
原因：在Linux或者Unix系统中，通过rm或者文件管理器删除文件将会从文件系统的目录结构上解除链接(unlink).然而如果文件是被打开的（有一个进程正在使用），那么进程将仍然可以读取该文件，磁盘空间也一直被占用
我们通过 cat /dev/null > *-json.log 来清理相应的日志，然后重启
systemctl daemon-reload
systemctl restart docker
然而，我思考，不能每次满的时候找运维清理日志啊，这多麻烦，难道docker没有相应的机制应付输出到控制台的日志吗？答案是：当然不会
在新版的docker中我们可以通过设置 vim /etc/docker/daemon.json 来限制docker的日志量
"log-driver":"json-file","log-opts":{ "max-size" :"200m","max-file":"5"}
顾名思义max-size就是每个日志文件大小，max-file是最多生成的文件数，如上我设置成功后，每个容器运行的日志最多有五份每份200M大小，这样就基本限制了容器的日志大小。
然后你觉得结束了吗？？并不！！
容器日志我们是限制完了，本以为高枕无忧，不用担心出现日志爆满的情况了，但是事与愿违，过几天硬盘容量又满了。。。
我们究其原因，发现在docker的运行目录下overlay这个文件夹里存放着所有的容器挂载目录，也就是容器的系统文件在这里放着，在容器中跑着的服务产生日志很可能并不是输出到控制台，而是保存到本地，容器内的日志文件也是会占用磁盘空间的，这就让我们犯愁了，这个不好限制开发团队不存日志或者规定团队存放目录啊，对于一个成熟的容器平台来说，海纳百川那是必须的~
于是我们打起了kubelet的主意
在 k8s中文社区中有详细的限制方法 那具体做法呢，其实就是为节点加上驱逐策略，当cpu或者内存或者硬盘空间不满足要求时，自动驱逐一些消耗资源大的容器，保证节点稳定性。
里面主要是有以下几个关键驱逐信号
上面的每个信号都支持整数值或者百分比。百分比的分母部分就是各个信号的总量。kubelet 支持两种文件系统分区。
nodefs：保存 kubelet 的卷和守护进程日志等。
imagefs：在容器运行时，用于保存镜像以及可写入层。
imagefs 是可选的。Kubelet 能够利用 cAdvisor 自动发现这些文耐歼件系统。Kubelet 不关注其他的文件系统。所有其他类型的配置，例如保存在独立文件系统的卷和日志，都不被支持。
因为磁盘压力已经被驱逐策略接管，因此未来将会停止对现有 垃圾收集 方式的支持。
具体的内容大家可以详细去看看社区里的介绍，我这里就不再赘述了，我这边献上我的驱逐方案~
执行vim /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
在里面插入
Environment="KUBELET_OTHER_ARGS=
--eviction-hard=memory.available<2Gi,nodefs.available<5Gi,imagefs.available<5Gi
--eviction-minimum-reclaim=memory.available=500Mi,nodefs.available=5Gi,imagefs.available=5Gi
--node-status-update-frequency=10s
--eviction-pressure-transition-period=30s"
解读：内存小于2G驱逐，root目录磁盘空间小于5G驱逐，镜像目录磁盘空间小于5G驱逐，节点检测为每10秒一次，在跳出压力状态之前要等待的时间为30秒。
在某些场景下，驱逐 Pod 可能只回收了很少的资源。这就导致了 kubelet 反复触发驱逐阈值。另外回收资源例如磁盘资源，是需要消耗时间的。
要缓和这种状况，Kubelet 能够对每种资源定义 minimum-reclaim。kubelet 一旦发现了资源压力，就会试着回收至少 minimum-reclaim 的资源，使得资源消耗量回到期望范围。
也就是说当内存触发驱逐时，kubelet至少要让内存有2.5G，当root和镜像磁盘空间发生驱逐时，kubelet至少要让磁盘有10G的空间。
那驱逐的规则是什么呢，对什么样的容器做驱逐呢？这个我们下回分解哈。
那总的来说，若要解决节点镜像存储报警，我们可以从三个方面入手
1.容器：通过docker限制容器日志大小
2.k8s：通过kubelet来驱逐过大的容器
3.跟开发人员沟通，精简容器，不让内存泄漏，不随意使用资源（很难啦~~~）
祝各位新春快乐~
Ⅱ k8s-踩坑篇2-服务器重启后重启集群
昨天不知道说明原因，测试环境的物理颤兆机挂了，安装k8s的3台虚枯洞哗拟机正好全在这台物理机上面，现在要把他们全部启动起来，安装的时候好像没有相关的步骤，今天研究一下手动重启。
报错：The connection to the server 10.100.1.236:6443 was refused
很明显apiserver没有起来，但是apiserver安装的时候是以容器的方式安装的
显示一个容器也没起来，完全不知道咋整，搜索k8s重启，看了好几篇文章，有的文章居然是kubeadm init，这txx还有什么好说的呢。不过民间的高手也是很多的，如下：
静态pod可以直接被kubelet启动，那很有可能是kubelet没有正确启动，尝试如下：每台机器没行上都要操作
然后用 docker ps 查看，可以看到master节点上的很多k8s容器已经启动起来了，但是worker node上的容器依然没有启动，用 kubectl get nodes ，看到node的状态还是notReady，那就很有可能是防火墙的问题了，直接关闭防火墙，看到worker node上的容器也起来了。
等待所有的calico pod启动完毕，node状态就变成ready了。
但是之前启动的 nignx pod 都不存在了，原因可能是：etcd的启动方式也是容器化的，重启后etcd内的数据被初始化了。
---本来怀疑是 systemctl daemon-reload 命令造成的，但是，今天这台服务器又重启了，我又试了一遍，不执行 systemctl daemon-reload 命令是无法重启k8s的。
---但是今天重启k8s，完成之后，昨天新建的2个pod仍然是存在的，那很有可能是我昨天不熟悉流程参杂了误操作，但是现在也想不起来了，就暂时告一段落了，后面遇到问题再说吧。
Ⅲ 9. K8s存储
Kubernetes的Volume是Pod的一部分，Volume不是单独的对象，不能独立创建，只能在Pod中定义。
Pod中的所有容器都可以访问Volume，但必须要挂载，且可以挂载到容器中任何目录。
实际中使用容器存储如下图所示，将容器的内容挂载到Volume中，通过Volume两个容器间实现了存储共享。
Volume的生命周期与挂载它的Pod相同，但是Volume里面的文件可能在Volume消失后仍然存在，这取决于Volume的类型。
Kubernetes的Volume有非常多的类型：
这个Volume挂载后就是一个空目录，应用程序可以在里面读写文件，emptyDir Volume的生命周期与Pod相同，Pod删除后Volume的数据也同时删除掉。
emptyDir的一些用途：
配置示例
emptyDir也可以设置存储介质为内存
HostPath存储的内容与节点相关，如果Pod被调度到其他Node，HostPath无法提供跨Node的数据。
配置示例
ConfigMap存储的是键值对，在Volume中应用时键值对表示的是 文件名 和 文件内容 ，代表将ConfigMap的每条数据填入Volume。ConfigMap的配置数据在 data 字段下定义。
ConfigMap文件示例
Volume中引用ConfigMap
与ConfigMap类似，在data字段中存储key-value键值对形式，不过存储的value不是明文，是Base64编码的加密值。
在Volume中引用后，文件中的值是Base64解码后的值，而非加密值。
Kubernetes抽象了PV（PersistentVolume）和PVC（PersistentVolumeClaim）来解耦网络存储种类多样的问题，从而让使用者不用关心具体的基础设施，当需要存储资源的时候，只要像CPU和内存一样，声明要多少即可。
PV是集群级别的资源，并不属于某个命名空间（在 default 命名空间下），而PVC是命名空间级别的资源，PV可以与任何命名空间的PVC资源绑定。
Kubernetes管理员设置好网络存储的类型，提供对应的PV描述符配置到Kubernetes，使用者需要存储的时候只需要创建PVC，然后在Pod中使用Volume关联PVC，即可让Pod使用到存储资源，它们之间的关系如下图所示。
PV 持久卷是用 插件 的形式来实现的，目前支持以下插件：
CSI
Container Storage Interface，容器存储接口，基于CSI这套接口，可以开发定制出CSI插件，从而支持特定的存储，达到解耦的目的。
PVC创建示例：
使用StorageClass可以自动创建PV，StorageClass包含 provisioner 、 parameters 和 reclaimPolicy 字段， 这些字段会在 StorageClass 需要动态分配 PersistentVolume 时会使用到。在声明PVC时加上StorageClassName，就可以自动创建PV，并自动创建底层的存储资源。
provisioner： PV配置器，用来决定使用哪个卷插件制备 PV。 该字段必须指定。
reclaimPolicy： 回收策略，可以是 Delete 或者 Retain ，默认是 Delete
使用StorageClassName创建PVC示例：
Ⅳ 深入剖析k8s中的存储
本文是《深入剖析k8s》学习笔记的第四篇，主要对k8s中的存储数据卷进行分析和学唤腊习。
容器中的存储是不稳定的，一旦容器重启或者销毁，这些存储就都会丢失。所以真实使用场景下，都会以数据卷挂载的方式将外部存储应用到容器中，带来的好处就是：
在k8s中，如果要在容器中使用数据卷，需要像如下一个pod的yaml示例一样进行声明定义：
其中pod的定义中，声明使用了自定义名称为 my-volume 的数据卷，并且类型为emptyDir；k8s的volume支持多种数据类型，可以通过命令 kubectl explain pod.spec.volumes 来查看所有支持的volume类型，其中常用的类型及意义比较如下：
从工程分工角度上来说，存储的定义和声明应该由运维人员完成，开发人员只要使用即可。因此，为了避免将存储细节过度地暴露给开发人员，k8s才引进了Persistent Volume Claim(PVC)和Persistent Volume(PV)这两个API对象，同时也降低了开发人员使用存储卷的门槛。如此，开发人员只需要如下两步就能解决存储卷的使用问题：
那么开发人员声明的PVC到底使用的是什么存储卷呢，这个和厅就由运维人员负责维护就行了，如下是一个PV的定义，开发人员了解即可：
为什么这个PV可以和上面的PVC绑定呢？只要符合如下的条件，k8s就会自动将它们绑定，绑定后，在PVC的配置文件中就能看到使用的数据卷就是该PV了。
总的来说，PVC和PV的关系就像是接口和实现的关系，PVC是接口定义，声明要使用什么，至于怎么实现，就是PV去完成的事情。如此解耦，使得开发和运维都能高效地搞定存储。
假设开发人员在创建好带有PVC的pod之后，且pod已经运行了，才发现运维还没有来得及创建对应的PVC或者PVC创建有问题，致使pod存储卷使用有问题该怎么办？只要运维及时创建对应的PV，k8s中的volume controller会循环遍历没有成功绑定PV的PVC，帮它们寻找唤链隐合适的PV进行绑定。
一个k8s集群往往有很多开发团队在使用，开发会部署很多pod，如果这些pod都需要存储卷，运维人员就需要天天创建pv来满足开发人员pvc绑定的需求了，太浪费人力，所以这种重复工作就被k8s中的storageClass取代了。原先手动创建PV的方式被称为static provisioning，使用storageClass自动创建PV的方式被称为dynamic provisioning，storageClass其实就是PV的一个模板，其定义大致分为两个部分：
在开发人员创建PVC的时候，只要指定使用的storageClassName是如上定义和创建的my-storageclass，那么k8s就会根据该storageClass自动创建一个PV与该PVC绑定。
Ⅳ 解决k8s集群中Redis Cluster故障
k8s集群中的一个node节点故障，将这个node节点下线后上面的pod迁移到其他节点，但是大量pod都产生报错。经排查，是由于redis集群故障导致。但是查看resdis pod，都是running状态，如下图
由于这些pod是组成集群使用，既然pod是正常的，应用又报redis链接的错误，所以问题肯定出在Redis Cluster上，查看Redis Cluster状态：
这个示意图我只画出三个node，简单表达一下意思即可。三个node上各运行了一个master和一个slave节点。由于node3节点故障已经移除集群，这个节点上之前运行的其他无状态pod迁移到其他节点可以正常运行，但是master2和slave2在node3上有持久化数据，虽然在node4上重建了，但是由于缺失数据，原来的集群状态被破坏了，所以重新部署也无法恢复，由于是master2和slave2的数据都丢失了，集群无法重建。通过开发了解到，redis上都是缓存数据，丢失影响不大，于是删除本地持久化数据，重新部署redis node，再手动创建集群。
三个节点都添加完成，并且没有报错。进入一个master节点查看集群状态：
集群状态终于恢复正常。重建后的Redis Cluster集群架构示意图如下
总结：对于有状态的应用，redis、mysql等，容器化时一定要考虑周全，避免主从节点运行在一个节点上。对于redis应用，如果读写I/O不是特别高，还是建议直接使用主从复制架构，故障恢复简单且迅速。