引言
在 Go 语言中创建协程(Goroutine)的成本非常低,因此稍不注意就可能创建出大量的协程,一方面会造成资源不断增长负载变高,另一方面不容易控制这些协程的状态。
不过,“能力越大,越需要克制”。网络上已经存在一些讲控制 Goroutine 数目的文章,本文通过图示的方式再简单总结一下其基本理念,以便于记忆。
在 Go 语言中创建协程(Goroutine)的成本非常低,因此稍不注意就可能创建出大量的协程,一方面会造成资源不断增长负载变高,另一方面不容易控制这些协程的状态。
不过,“能力越大,越需要克制”。网络上已经存在一些讲控制 Goroutine 数目的文章,本文通过图示的方式再简单总结一下其基本理念,以便于记忆。
在Docker实践中,很多人应该都遇到过开机重启时,由于Docker守护程序在占用多核CPU使用100%C使用的情况,此时所有容器都无法正常工作,所有服务都不能用。解决唯一方法只能杀掉所有容器并重启守护进程,才能恢复。经过了解该问题是由于Docker守护进程引起,而且Docker守护进程是以root特权权限启动的,是一个安全问题,那么有什么方法解决呢?本文介绍一下基于CRI 等标准(Docker新架构也符合CRI标准)的新一代容器工具Podman
、Skopero
和Buiddah
套件。
为了防止容器被Docker一家垄断,巨头们(谷歌,Redhat、微软、IBM、Intel、思科)聚在一起决定要成立一个组织(OCI),大家一起商量指定了一套规范(CRI、CNI),大家一致统一只兼容符合这套规范的工具。Docker虽然心有不甘但是毕竟胳膊拧不过大腿,只能该架构兼容规范。
在该规范的指导下就有了本文的三个主人公,这三个工具都是符合OCI计划下的工具(https://github.com/containers)。他们主要是由RedHat推动,三者各司其职,配合完成Docker所有的功能和新扩展功能,并且对docker的问题进行了改良:包括不需要守护程序或访问有root权限的组;容器架构基于fork/exec模型创建容器,更加安全可靠;所以是更先进、高效和安全的下一代容器容器工具。
当 Kubernetes 中 Node 节点出现状态异常的情况下,节点上的 Pod 会被重新调度到其他节点上去,但是有的时候我们会发现节点 Down 掉以后,Pod 并不会立即触发重新调度,这实际上就是和 Kubelet 的状态更新机制密切相关的,Kubernetes 提供了一些参数配置来触发重新调度到嗯时间,下面我们来分析下 Kubelet 状态更新的基本流程。
--node-status-update-frequency
指定上报频率,默认是 10s 上报一次。--node-monitor-period
时间去检查 kubelet 的状态,默认是 5s。notready
状态,这段时长通过--node-monitor-grace-period
参数配置,默认 40s。unhealthy
状态,这段时长通过--node-startup-grace-period
参数配置,默认 1m0s。--pod-eviction-timeout
参数配置,默认 5m0s。kube-controller-manager 和 kubelet 是异步工作的,这意味着延迟可能包括任何的网络延迟、apiserver 的延迟、etcd 延迟,一个节点上的负载引起的延迟等等。因此,如果
--node-status-update-frequency
设置为5s,那么实际上 etcd 中的数据变化会需要 6-7s,甚至更长时间。
Calico 能够进行配置,为不同拓扑指定 IP 地址池。例如可能希望某些机架、地区、或者区域能够从同一个 IP 池中获取地址。这对于降低路由数量或者配合防火墙策略的要求会很有帮助。
cni 插件配置参考中的 IP 地址管理章节中包含了三种分配 IP 地址的方式。Kubernetes 注解方式只能用于 Namespace 或者 Pod 一级。剩下的只有两个办法,CNI 配置或者是基于节点选择器的 IP 池,相对于 CNI 配置的方式来说,节点选择器方案省去了修改本地文件的麻烦。
在更高层次上,基于节点选择器的 IP 地址分配方法就是给节点设置标签,然后用节点选择器选择对应的 IP 地址池进行分配。后面的内容中将给出一个详细的例子,用这种方式来设置一种机架亲和方式的 IP 地址分配方案。
如果 Calico 无法根据上述顺序来决定一个 IP 地址池,或者在选定的地址池中找不到可用的 IP 地址,那么这一工作负载就不会分到 IP 地址,无法启动。为了防止这种情况的发生,我们建议所有节点至少有一个合适的地址池。
道路千万条,安全第一条; 镜像不规范,同事两行泪。
Trivy 是一个面向镜像的漏洞检测工具,具备如下特点:
相对于老前辈 Clair,Trivy 的使用非常直观方便,适用于更多的场景。
下面是官方出具的对比表格:
扫描器 | 操作系统 | 依赖检测 | 适用性 | 准确度 | CI 友好 |
---|---|---|---|---|---|
Trivy | ◯ | ◯ | ◯ | ◎ | ◯ |
Clair | ◯ | × | △ | ◯ | △ |
Anchore Engine | ◯ | △ | △ | ◯ | △ |
Quay | ◯ | × | ◯ | ◯ | × |
MicroScanner | ◯ | × | ◯ | ◯ | ◯ |
Docker Hub | ◯ | × | ◯ | × | × |
GCR | ◯ | × | ◯ | ◯ | × |