什么是 Kind

kind：是一种使用Docker容器节点运行本地Kubernetes集群的工具。该类型主要用于测试Kubernetes，但可用于本地开发或CI。

注意：kind仍在开发中

部署

Mac & Linux

1
2
3

$ curl -Lo ./kind "https://kind.sigs.k8s.io/dl/v0.9.0/kind-$(uname)-amd64"
$ chmod +x ./kind
$ mv ./kind /some-dir-in-your-PATH/kind

前言

这篇文章的全称应该叫：[在某些内核版本上，cgroup 的 kmem account 特性有内存泄露问题]，如果你遇到过 pod 的 cannot allocated memory 报错，node 内核日志的 SLUB: Unable to allocate memory on node -1 报错，那么恭喜你中招了。

这个问题在 pingcap 文章 和腾讯云的官方修复都发过，原因也讲的很清楚，不过因为版本差异，文章里的方法有所变动，这里做下总结。

Nextcloud 优点

• 完全开源
• 支持web界面、手机ios系统、手机安卓系统
• 容器化部署

准备环境

• 部署 docker、docker-compose (本文不讲docker、docker-compose部署)

概述

在k8s中节点会通过docker pull机制获取外部的镜像，那么什么时候清除镜像呢？k8s运行的容器又是什么时候清除呢?

• api-server: 运行在master，无状态组件，go自动内存垃圾回收
• controller-manager: 运行在master,无状态组件，go自动内存垃圾回收，owner机制提供resource垃圾回收
• scheduler: 运行在master，无状态组件，go自动内存垃圾回收
• kube-proxy: 运行在node，无状态组件，无垃圾收集需要
• kubelet：运行在node,无状态组件,需要管理宿主机的image和container

Kubelet：会定期进行垃圾回收（Garbage Collection），以清理节点上的无用镜像和容器。

• 每隔 1 分钟进行一次容器清理
• 每隔 5 分钟进行一次镜像清理

截止到 v1.15 版本，垃圾回收间隔时间还都是在源码中固化的，不可自定义配置，如果节点上已经运行了 Kubelet，不建议再额外运行其它的垃圾回收工具，因为这些工具可能错误地清理掉 Kubelet 认为本应保留的镜像或容器，从而可能造成不可预知的问题。

前言

Grafana Tanka 是 Kubernetes 集群的配置工具，由 Jsonnet 数据模板语言实现。

使用它比使用 Yaml 来定义 Kubernetes 资源更简洁。Jsonnet 高度可重用，使你能通过组合现成的库来实现你的技术栈。

Grafana Tanka 亮点

• 干净：使用 Jsonet 语言表示你的Kubernetes应用，比YAML更简洁。
• 可重用：构建应用程序库，将它们导入任何地方，甚至在GitHub上共享它们！
• 简洁：使用Kubernetes库，不再需要模板。
• 变化：以轻松地知道确切的变化。
• 生产环境Ready：Tanka 部署了 Grafana Cloud 和更多生产设置。
• 开源：就像广受欢迎的 Grafana 和 Loki 项目一样，Tanka 是完全开源的。

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 的内存占用信息。