k8s 随记

1.kubelet参数解析：https://blog.csdn.net/qq_34857250/article/details/84995381

2.如何在github中查找k8s代码关键字？

现在我想查找k8s源码中，关于kubelet参数pod-eviction-timeout的默认值是多少

https://github.com/kubernetes/kubernetes

先进入github对应的repository中，再Search关键字

3.计算节点频繁发生OOM，linux中发生oom时，oom_killer如何决定首先杀掉哪个进程：https://www.vpsee.com/2013/10/how-to-configure-the-linux-oom-killer/

为了防止它杀死关键的应用程序，例如数据库实例，可以手动调整分数。这可以通过/proc/[pid]/oom_score_adj(对于2.6.29之前的内核，使用/proc/[pid]/oom_adj)实现。oom_score_adj接受的值范围是-1000到1000，（oom_adj接受的值范围是-17到15）

在k8s的qos（quality of service）中，三个qos级别正是对应三个oom_score-adj值，通过调整该值来控制evict驱逐策略和system oom_killer的优先级。

guaranteed级别的pod的oom-score-adj= -998，而计算节点kubelet服务的oom-score-adi= -999

k8s doc: https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/

If the node experiences a system OOM (out of memory) event prior to the kubelet being able to reclaim memory, the node depends on the oom_killer to respond.

The kubelet sets a oom_score_adj value for each container based on the quality of service for the Pod.

Quality of Service	oom_score_adj
Guaranteed	-998
BestEffort	1000
Burstable	min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)，该值在2~999

在配置容器云计算节点驱逐策略时，可能存在以下问题：

Kubelet 无法及时观测到内存压力

Kubelet 目前从 cAdvisor 定时获取内存使用状况统计。如果内存使用在这个时间段内发生了快速增长，Kubelet 就无法观察到 MemoryPressure，可能会触发 OOMKiller。我们正在尝试将这一过程集成到 memcg 通知 API 中，来降低这一延迟，而不是让内核首先发现这一情况。如果用户不是希望获得终极使用率，而是作为一个过量使用的衡量方式，对付这一个问题的较为可靠的方式就是设置驱逐阈值为 75% 容量。这样就提高了避开 OOM 的能力，提高了驱逐的标准，有助于集群状态的平衡。

Kubelet 可能驱逐超出需要的更多 Pod

这也是因为状态搜集的时间差导致的。未来会加入功能，让根容器的统计频率和其他容器分别开来（https://github.com/google/cadvisor/issues/1247）

4.容器设计模式：Sidecar

什么是 Sidecar？在 Pod 里面，可以定义一些专门的容器，来执行主业务容器所需要的一些辅助工作，比如Init Container，它就是一个 Sidecar，它可以将文件拷贝到共享目录里面，以便被同pod中的业务容器用起来。

优势就是在于其实将辅助功能从我的业务容器解耦了，所以我就能够独立发布 Sidecar 容器，并且更重要的是这个能力是可以重用的，即同样的一个监控 Sidecar 或者日志 Sidecar，可以被全公司的人共用的。这就是设计模式的一个威力。

摘自：https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247486561&idx=1&sn=62758e8b600497923df05f853d030d39&chksm=fae507aecd928eb80d240dadb1ce403529b60f5cda0230f013850ccac60f68a876a0083ac4d5&mpshare=1&scene=1&srcid=&sharer_sharetime=1570671376610&sharer_shareid=bc0f20da14de543a8c3c8d489c80ea9f&pass_ticket=PfIyWTvIxxY3GIaq2oU20CrLwQcHSDJMVReWhDTY8cfRE269dCl%2FNIvDqH%2F8wAJy#rd

5. 我们发现k8s中的很多组件其实都是容器化部署的，比如etcd、api-server、controller等，那为什么每个node上面的kubelet服务不容器化部署呢？

kubelet 是 Kubernetes 项目用来操作 Docker 等容器运行时的核心组件。可是，除了跟容器运行时打交道外，kubelet 在配置容器网络、管理容器数据卷时，都需要直接操作宿主机。

而如果现在 kubelet 本身就运行在一个容器里，那么直接操作宿主机就会变得很麻烦。对于网络配置来说还好，kubelet 容器可以通过不开启 Network Namespace（即 Docker 的 host network 模式）的方式，直接共享宿主机的网络栈。可是，要让 kubelet 隔着容器的 Mount Namespace 和文件系统，操作宿主机的文件系统，就有点儿困难了。比如，如果用户想要使用 NFS 做容器的持久化数据卷，那么 kubelet 就需要在容器进行绑定挂载前，在宿主机的指定目录上，先挂载 NFS 的远程目录。可是，这时候问题来了。由于现在 kubelet 是运行在容器里的，这就意味着它要做的这个“mount -F nfs”命令，被隔离在了一个单独的 Mount Namespace 中。即，kubelet 做的挂载操作，不能被“传播”到宿主机上。对于这个问题，有人说，可以使用 setns() 系统调用，在宿主机的 Mount Namespace 中执行这些挂载操作；也有人说，应该让 Docker 支持一个–mnt=host 的参数。但是，到目前为止，在容器里运行 kubelet，依然没有很好的解决办法。