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

对于公有云上的 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的内存都去哪儿了呢？

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

前言

终于，我们推出了Kubernetes 1.19，这是2020年的第二个发行版，并且迄今为止最长的发行周期持续了20周。它由33项增强功能组成。12个增强功能进入稳定版，18个增强功能进入测试版，13个增强功能进入alpha版。

由于 COVID-19、George Floyd 抗议以及我们作为发布团队经历的其他一些全球性事件，因此1.19版本与常规版本完全不同。由于这些事件，我们决定调整我们的时间表，并让 SIG、工作组和贡献者有更多的时间来完成任务。额外的时间也让大家有时间关注 Kubernetes 项目之外的生活，并确保他们的精神状态更加良好。

贡献者是 Kubernetes 的核心，《 Kubernetes行为准则》要求人们彼此优秀，尽管我们的世界动荡不安，但我们从社区中看到的只是伟大和谦卑。

Kubectl 备忘录

Kubectl 自动补全

BASH 环境下设置

1
2
3
4
5
6
7
8
9
10
11
12

# Centos 或者 RedHat 需要安装 bash-completion 包命令
$ yum install -y bash-completion

# Ubuntu 或者 Debian 需要安装 bash-completion 包命令
$ apt install -y bash-completion

# 写入当前用户 .bashrc 文件中
$ echo "source /usr/share/bash-completion/bash_completion" >> ~/.bashrc
$ echo "source <(kubectl completion bash)" >> ~/.bashrc

# 让当前终端生效
$ source ~/.bashrc