容器的网络解决方案有很多种，每支持一种网络实现就进行一次适配显然是不现实的，而 CNI 就是为了兼容多种网络方案而发明的。CNI 是 Container Network Interface 的缩写，是一个标准的通用的接口，用于连接容器管理系统和网络插件。
简单来说，容器 runtime 为容器提供 network namespace，网络插件负责将 network interface 插入该 network namespace 中并且在宿主机做一些必要的配置，最后对 namespace 中的 interface 进行 IP 和路由的配置。
所以网络插件的主要工作就在于为容器提供网络环境，包括为 pod 设置 ip 地址、配置路由保证集群内网络的通畅。目前比较流行的网络插件是 Flannel 和 Calico。
最近解决了我们项目中的一个内存泄露问题，事实再次证明 pprof 是一个好工具，但掌握好工具的正确用法，才能发挥好工具的威力，不然就算你手里有屠龙刀，也成不了天下第一，本文就是带你用 pprof 定位内存泄露问题。
关于Go的内存泄露有这么一句话不知道你听过没有：
10次内存泄露，有9次是 goroutine 泄露。
我所解决的问题，也是 goroutine 泄露导致的内存泄露，所以这篇文章主要介绍Go程序的goroutine 泄露，掌握了如何定位和解决 goroutine 泄露，就掌握了内存泄露的大部分场景。
本文草稿最初数据都是生产坏境数据，为了防止敏感内容泄露，全部替换成了demo数据，demo的数据比生产环境数据简单多了，更适合入门理解，有助于掌握 pprof。
很多人对hostPath volume和local persistent volume的使用场景还存在很多困惑。下面对着两种volume的使用场景、基本的工作机制进行了分析，介绍了使用时的注意事项，并简单介绍local volume manager如何帮助administrator进行local persistent volume的生命周期管理的
过去我们经常会通过hostPath volume让Pod能够使用本地存储，将Node文件系统中的文件或者目录挂载到容器内，但是hostPath volume的使用是很难受的，并不适合在生产环境中使用。
我们先看看hostPath Type有哪些类型：
| 取值 | 行为 |
|---|---|
| 空字符串（默认）用于向后兼容，这意味着在安装 hostPath 卷之前不会执行任何检查。 | |
| DirectoryOrCreate | 在给定路径上必须存在的目录。 |
| FileOrCreate | 如果在给定路径上什么都不存在，那么将在那里根据需要创建空文件，权限设置为 0644，具有与 Kubelet 相同的组和所有权。 |
| File | 在给定路径上必须存在的文件。 |
| Socket | 在给定路径上必须存在的 UNIX 套接字。 |
| CharDevice | 在给定路径上必须存在的字符设备。 |
| BlockDevice | 在给定路径上必须存在的块设备。 |
看起来支持这么多type还是挺好的，但为什么说不适合在生产环境中使用呢？
线上某个环境发现 S3 上传请求卡住，请求不返回，卡了30分钟，长时间没有发现有效日志。一般来讲，死锁问题还是好排查的，因为现场一般都在。类似于 c 程序，遇到死锁问题都会用 pstack 看一把。golang 死锁排查思路也类似（golang 不适合使用 pstack，因为 golang 调度的是协程，pstack 只能看到线程栈），我们其实是需要知道 S3 程序里 goroutine 的栈状态。golang 遇到这个问题我们有两个办法：
需要注意到，golang 程序和 c 程序还是有点区别，goroutine 非常多，成百上千个 goroutine 是常态，甚至上万个也不稀奇。所以我们一般无法在终端上直接看完所有的栈，一般都是把所有的 goroutine 栈 dump 到文件，然用 vi 打开慢慢分析。
gorouties -t -u 这个命令，并且把输出 dump 到文件；curl xxx/debug/pprof/goroutine典型案例：某运维同学反馈：昨天晚上 Istio 环境中应用的心跳检测报 connect reset，然后服务重启了。怀疑是 Istio 环境中网络不稳定导致了服务重启。
该问题的表现是安装了 sidecar proxy 的应用，在启动后的一小段时间内无法通过网络访问 pod 外部的其他服务，例如外部的 HTTP，MySQL，Redis等服务。如果应用没有对依赖服务的异常进行容错处理，该问题还常常会导致应用启动失败。
下面我们以该问题导致的一个典型故障的分析过程为例，对该问题的原因进行说明。