Docker 报错

Docker 启动或者重启时报以上两个错误：

• Error starting daemon: Devices cgroup isn't mounted

• Error response from daemon: Cannot restart container rsnmp_v4: OCI runtime create failed: container_linux.go:349: starting container process caused "process_linux.go:297: applying cgroup configuration for process caused \"mountpoint for devices not found\"": unknown

问题都是 cgroup 未挂载。可以通过下面脚本修复。

前言

随着各大浏览器对 http 请求标识为 不安全（见下图），现如今强烈推荐网站使用 https 请求。对于运维同学来说，SSL 证书有效期如何监控，不可能去记住每个域名证书到期日期，今天作者分享两个脚本并配合zabbix 来监控 SSL 证书到期日期。这样就不会因为 SSL 证书到期导致网站瘫痪。

一、节点配额和内核参数调整

对于公有云上的 Kubernetes 集群，规模大了之后很容器碰到配额问题，需要提前在云平台上增大配额。这些需要增大的配额包括：

• 虚拟机个数
• vCPU 个数
• 内网 IP 地址个数
• 公网 IP 地址个数
• 安全组条数
• 路由表条数
• 持久化存储大小

参考gce随着node节点的增加master节点的配置：

• 1-5 nodes: n1-standard-1
• 6-10 nodes: n1-standard-2
• 11-100 nodes: n1-standard-4
• 101-250 nodes: n1-standard-8
• 251-500 nodes: n1-standard-16
• more than 500 nodes: n1-standard-32

问题

使用 Docker Volumes 时，有时需要挂载一个宿主机目录或者文件，提供数据可持续或者容器内部服务配置文件。

使用命令 docker run -it --rm -v /root/test.txt:/root/test.txt debian:10 bash 挂载文件（test.txt 默认权限 644）时，通过 vim 修改宿主 test.txt 文件，但是容器中 test.txt 没有修改。这是为什么？

问题分析

Docker 中，mount volume 的原理是借用了 Linux Namespace 中的 Mount NameSpace，隔离系统中不同进程的挂载点视图，实际文件是没有变化。比如上面的例子，在container中，bash 实际就是一个运行在宿主机上的进程，被Docker用Linux分别隔离了 Mount Namespace、UTS Namespace、IPC Namespace、PID Namespace、Network Namespace和User Namespace，使得它看上去好像运行在了一个独立的、相对隔离的系统上，但实际它的一切资源都是宿主机在不同Namespace中的一个投影，文件也不例外。

为什么宿主机上修改 test.txt 文件，而容器中 test.txt 文件没有变化？

Linux中，证明文件是否相同的根本途径是，判断其 inode，如果两个文件的inode相同，两个文件必定为同一文件，从而两个文件的内容也必然相同。

案例一

问题

最近一台 CentOS 服务器，发现内存无端损失了许多，free 和 ps 统计的结果相差十几个G，非常奇怪，后来Google了许久才搞明白。

分析

1、linux系统内存消耗主要有三个地方：

• 进程
• slab
• pagecacge

用 free 命令查看到的是系统整体的内容使用情况，而使用 ps 和 top 看到的内存使用情况都是以进程维度来看的，因此看不到 slabcache 和pagecache 的内存占用信息。

前言

工作中经常会遇到数据拷贝或者数据同步事情。一般情况会使用 rsync 来做数据拷贝或者数据同步等。

问题

rsync 不能做并发同步，特别是需要拷贝上T数据时，rsync 一个进程拷贝有很大的瓶颈，不能把存储设备IO性能发挥的最好或者说把存储设备IO跑满。

有什么方法让 rsync 实现多进程同步，并且自动识别目录下有多少个文件或者目录，不会出现重复性同步。

还在为写 kubernetes yaml 烦恼吗？还在为记不住 kubernetes yaml 而心累吗？这些都没有关系，推荐一个kubernetes yaml 生成器，帮小伙伴们解决这些痛苦！

kubernetes yaml 生成器

故障一

故障现象

kubelet 启动不了，通过命令 journalctl -u kubelet 查看日志，报 Failed to start ContainerManager failed to initialize top level QOS containers: failed to update top level Burstable QOS cgroup : failed to set supported cgroup subsystems for cgroup [kubepods burstable]: failed to find subsystem mount for required subsystem: pids

故障分析

根据报错，有用的信息是 failed to find subsystem mount for required subsystem: pids，通过命令 ls -l /sys/fs/cgroup/systemd/kubepods/burstable/ 查看，该目录下没有 pids 目录。

SupportPodPidsLimit 在 kubernetes 1.14+ 默认开启。 SupportNodePidsLimit 在 1.15+ 默认开启。

相关Issues：https://github.com/kubernetes/kubernetes/issues/79046

解决方法

• 方法一：编辑 kubelet 配置文件，添加 --feature-gates=SupportPodPidsLimit=false,SupportNodePidsLimit=false 参数，后面在重启 kubelet 服务。
• 方法二：可以升级系统内核 5+ 版本

临时存储简介

Node节点通常还可以具有本地的临时性存储，由本地挂载的可写入设备或者 RAM来提供支持。 临时（Ephemeral） 意味着对所存储的数据不提供长期可用性的保证。

Pods 通常可以使用临时性本地存储来实现缓冲区、保存日志等功能。 kubelet 可以为使用本地临时存储的 Pods 提供这种存储空间，允许后者使用 emptyDir 类型的卷将其挂载到容器中。

kubelet 也使用此类存储来保存节点层面的容器日志， 容器镜像文件、以及运行中容器的可写入层。

临时存储有哪些

• 本地临时存储（local ephemeral storage）
• emptyDir

本地临时存储（local ephemeral storage）：Kubernetes在1.8的版本中引入了一种类似于CPU，内存的新的资源模式：ephemeral-storage，并且在1.10版本kubelet中默认打开这个特性。ephemeral-storage是为管理和调度Kubernetes中运行的应用短暂存储。

emptyDir：emptyDir 类型Volume在Pod分配到Node上时被创建，Kubernetes会在Node节点上自动分配一个目录，因此无需指定宿主机Node上对应的目录文件。 这个目录初始内容为空，当Pod从Node上移除时，emptyDir中的数据会被永久删除。

注释：容器的 crashing 事件并不会导致 emptyDir 中的数据被删除。

前言

前几天 纯上 同学问了一个问题：

我 ps aux 看到的RSS内存只有不到30M，但是free看到内存却已经使用了7,8G了，已经开始swap了，请问ps aux的实际物理内存统计是不是漏了哪些内存没算？我有什么办法确定free中used的内存都去哪儿了呢？

这个问题不止一个同学遇到过了，之前子嘉同学也遇到这个问题，内存的计算总是一个迷糊账。 我们今天来把它算个清楚下!