kelvinji2009 译 分布式实验室
这是Google Developer Advocate Sandeep Dinesh 关于如何充分利用Kubernetes环境的七部分视频和博客系列的第一部分。 主要讲保持容器镜像尽可能小的理论和实用性。
https://v.qq.com/x/page/t0752jh1emh.htmlDocker使构建容器镜像变得轻而易举。只需将标准 Dockerfile 放入您的文件夹，运行 docker build 命令，然后运行，芝麻开门！您的容器镜像已构建成功！
这种简单性的缺点是，很容易构建出大体积的容器镜像，其中包含您不需要的东西——包括潜在的安全漏洞。
在本期“Kubernetes最佳实践”中，让我们探讨如何使用Alpine Linux 和 Docker builder 模式创建生产就绪的容器镜像，再做一些基准测试，然后确定这些容器在Kubernetes集群中运行方式。
根据您使用的是解释型语言还是编译型语言，创建容器镜像的过程会有所不同。让我们一起来深入了解！
解释型语言的容器化
幸运的是，大多数这些语言都提供了预构建的Docker容器，其中包含一个轻量级环境，允许您运行更小的容器。
我们来看一个Node.js应用程序并对其进行容器化。 首先，让我们使用node：onbuild镜像作为基础。 Docker容器的onbuild版本预先打包了您需要的所有内容，因此无需执行大量配置即可搞定。 这意味着Dockerfile非常简单（只有两行！）。 但是你要付出的磁盘大小代价——差不多700MB！
通过使用较小的基础镜像（如Alpine），您可以显著减少容器的大小。Alpine Linux是一款体积小，轻量级的Linux发行版，在Docker用户中非常受欢迎，因为它与许多应用程序兼容，同时仍然保持小体积。
幸运的是，Node.js（以及其他流行语言）有一个官方的Alpine图像，可以满足您的一切需求。与默认的node镜像不同，node：alpine会删除许多文件和程序，只留下足以运行您的应用程序的部分。
基于Alpine Linux的Dockerfile创建起来有点复杂，因为你必须运行一些针对onbuild的命令。
但是，这是值得的，因为产生的镜像只有65MB！
编译型语言的容器化
借助Docker对多阶段构建的支持，您可以轻松地打包二进制文件和最少量的脚手架。 让我们学习一下怎么做。
让我们采用Go应用程序并使用此模式对其进行容器化。 首先，让我们使用golang：onbuild镜像作为基础。 和以前一样，Dockerfile只有两行，但你再次付出磁盘大小超过700MB的代价！
下一步是使用更小的基础镜像，也就是golang：alpine镜像。 到目前为止，这与我们针对解释型语言所遵循的过程相同。
同样，使用Alpine基础镜像创建Dockerfile有点复杂，因为您必须运行一些执行onbuild镜像相关的命令。
但同样，由此产生的镜像要小得多，大小只有256MB！
但是，我们可以使镜像更小：您不需要Go附带的任何编译器或其他构建和调试工具，因此您可以从最终容器中删除它们。
让我们使用多阶段构建来获取由golang：alpine容器创建的二进制文件并将其自行打包。
你看看现在！ 这个容器镜像只有12MB大小！
在构建此容器时，您可能会注意到Dockerfile会执行一些奇怪的操作，例如手动将HTTPS证书安装到容器中。这是因为基础的Alpine Linux几乎没有预安装任何东西。 因此，即使您需要手动安装任何依赖项，最终结果也还是超小容器镜像！
注意：如果您想节省更多空间，可以静态编译应用程序并使用scratch容器镜像。使用scratch作为基础容器镜像意味着您从头开始，根本没有基础层。 但是，我建议使用Alpine作为基础镜像而不是scratch，因为Alpine镜像中的仅仅增加少量额外MB的大小却可以使得使用标准工具和安装依赖项变得更加容易。
在哪构建和存储您的容器镜像？
Google Kubernetes Engine等平台可以安全地从Google Container Registry中拉取镜像而无需任何其他配置，让您轻松上手！
此外，Google Container Registry还为您提供漏洞扫描工具和开箱即用的IAM支持。 这些工具可以使您更轻松地保护和锁定容器。
评估小体积容器的性能
TL;DR：对于功能强大的计算机或Container Builder没有显著差异，但对于性能没有那么强大的计算机和共享系统（如许多CI/CD系统）而言则有明显差异。 就绝对性能而言，小镜像总是更好。
在大型机器上构建镜像
对于每次构建，我都会删除缓存中的所有Docker镜像。
构建（Build）：
对于较大的容器镜像，构建需要的时间大约是10秒左右。 虽然这个代价仅在初始构建时需要付出，但是如果您使用持续集成系统，则在每次构建时都要付出这个代价。
下一个测试是将容器镜像推送到远程镜像仓库。 对于此测试，我使用Google Container Registry来存储镜像。
推送（Push）：
这很有趣！ 为什么需要花费相同的时间来推送12MB镜像和700MB镜像？ 事实证明，Google Container Registry在幕后使用了很多技巧，包括许多流行基础镜像的全局缓存。
最后，我想测试将镜像从远程镜像仓库库拉到本地计算机所需的时间。
拉取（Pull）：
20秒的差距，这是使用两个不同容器镜像之间的最大差异。 您可以开始看到使用较小镜像的优势，尤其是在经常拉取镜像时。
您还可以使用Google Container Builder在云中构建容器镜像，这样可以自动将它们存储在Google Container Registry中。
构建（build）+ 推送（Push）：
再次证明，使用较小的镜像有一点小优势，没有我想象的那么大。
在小型机器上构建镜像
构建（build）：
推送（Push
拉取（Pull）：
在这种情况下，使用较小的容器镜像确实非常有帮助！
在Kubernetes上拉取镜像
例如，假设您有一个三节点集群，其中一个节点崩溃。 如果您使用的是像Kubernetes Engine这样的托管系统，系统会自动生成一个新节点来代替它。
但是，这个新节点将是全新的，并且必须先拉取所有容器镜像才能开始工作。 拉取容器镜像所需的时间越长，集群执行的时间就越长！
当您增加群集大小（例如，使用Kubernetes Engine Autoscaling）或将节点升级到新版本的Kubernetes时，可能会发生这种情况（接下来的几集中会关注这个问题）。
我们可以看到来自多个部署的多个容器的拉取性能可以在这里真正体现出来，使用小容器可能会浪费几分钟的部署时间！
安全性和漏洞
几个月前，我构建了Go onbuild和multi-age容器镜像，因此它们可能包含一些已被发现的漏洞。 使用Google Container Registry的内置漏洞扫描，可以轻松扫描容器中的已知漏洞。 让我们看看我们能找到些什么。
哇，这次两者之间有很大的不同！ 较小容器镜像中只有三个“中级”漏洞，而较大容器镜像中有16个严重漏洞和300多个其他漏洞。
让我们深入了解更大容器镜像里面存在的问题。
您可以看到大多数存在的问题与我们的应用程序无关，甚至没有我们的应用程序！ 因为多阶段构建使用的是更小的基础镜像，所以可以产生漏洞的东西更少。
结论
预告：下一篇中我们将讨论如何使用Kubernetes命名空间来隔离集群。
原文链接：https://cloudplatform.googleblog.com/2018/04/Kubernetes-best-practices-how-and-why-to-build-small-container-images.html
