Kubernetes最佳实践S01E01：如何构建尽可能小的容器镜像？-低调大师

Kubernetes最佳实践S01E01：如何构建尽可能小的容器镜像？

2018-12-17 668

这是是Google Developer Advocate Sandeep Dinesh 关于如何充分利用Kubernetes环境的七部分视频和博客系列的第一部分。今天，他主要讲保持容器镜像尽可能小的理论和实用性。

Docker使构建容器镜像变得轻而易举。只需将标准 Dockerfile 放入您的文件夹，运行 docker build 命令，然后运行，芝麻开门！您的容器镜像已构建成功！

这种简单性的缺点是，很容易构建出大体积的容器镜像，其中包含您不需要的东西——包括潜在的安全漏洞。

在本期“Kubernetes最佳实践”中，让我们探讨如何使用 Alpine Linux 和 Docker builder 模式创建生产就绪的容器镜像，再做一些基准测试，然后确定这些容器在Kubernetes集群中运行方式。

根据您使用的是解释型语言还是编译型语言，创建容器镜像的过程会有所不同。让我们一起来深入了解！

解释型语言的容器化

解释型语言，如Ruby，Python，Node.js，PHP和其他语言通过发送源代码到解释器来运行代码。这样的好处是可以跳过编译步骤，但其缺点是要求您将解释器与代码一起丢进去。

幸运的是，大多数这些语言都提供了预构建的Docker容器，其中包含一个轻量级环境，允许您运行更小的容器。

我们来看一个Node.js应用程序并对其进行容器化。首先，让我们使用 node：onbuild 镜像作为基础。 Docker容器的 onbuild 版本预先打包了您需要的所有内容，因此无需执行大量配置即可搞定。这意味着Dockerfile非常简单（只有两行！）。但是你要付出的磁盘大小代价——差不多700MB！

dockerfile
FROM node:onbuild
EXPOSE 8080

通过使用较小的基础镜像（如Alpine），您可以显著减少容器的大小。 Alpine Linux 是一款体积小，轻量级的Linux发行版，在Docker用户中非常受欢迎，因为它与许多应用程序兼容，同时仍然保持小体积。

幸运的是，Node.js（以及其他流行语言）有一个官方的 Alpine 图像，可以满足您的一切需求。与默认的 node 镜像不同， node：alpine 会删除许多文件和程序，只留下足以运行您的应用程序的部分。

基于 Alpine Linux 的Dockerfile创建起来有点复杂，因为你必须运行一些针对 onbuild 的命令。

dockerfile
FROM node:alpine
WORKDIR /app
COPY package.json /app/package.json
RUN npm install --production
COPY server.js /app/server.js
EXPOSE 8080
CMD npm start

但是，这是值得的，因为产生的镜像只有65MB！

编译型语言的容器化

诸如Go，C，C ++，Rust，Haskell等编译型语言可以创建在没有许多外部依赖性的情况下运行的二进制文件。这意味着你可以提前构建二进制文件并将其投入生产，而无需把创建二进制文件（如编译器）放进去。

借助Docker对多阶段构建的支持，您可以轻松地打包二进制文件和最少量的脚手架。让我们学习一下怎么做。

让我们采用Go应用程序并使用此模式对其进行容器化。首先，让我们使用 golang：onbuild 镜像作为基础。和以前一样，Dockerfile只有两行，但你再次付出磁盘大小超过700MB的代价！

dockerfile
FROM golang:onbuild
EXPOSE 8080

下一步是使用更小的基础镜像，也就是 golang：alpine 镜像。到目前为止，这与我们针对解释型语言所遵循的过程相同。

同样，使用Alpine基础镜像创建Dockerfile有点复杂，因为您必须运行一些执行 onbuild 镜像相关的命令。

dockerfile
FROM golang:alpine
WORKDIR /app
ADD . /app
RUN cd /app && go build -o goapp
EXPOSE 8080
ENTRYPOINT ./goapp

但同样，由此产生的镜像要小得多，大小只有256MB！

但是，我们可以使镜像更小：您不需要Go附带的任何编译器或其他构建和调试工具，因此您可以从最终容器中删除它们。

让我们使用多阶段构建来获取由 golang：alpine 容器创建的二进制文件并将其自行打包。

dockerfile
FROM golang:alpine AS build-env
WORKDIR /app
ADD . /app
RUN cd /app && go build -o goapp

FROM alpine
RUN apk update && \
apk add ca-certificates && \
update-ca-certificates && \
rm -rf /var/cache/apk/*
WORKDIR /app
COPY --from=build-env /app/goapp /app
EXPOSE 8080
ENTRYPOINT ./goapp

你看看现在！这个容器镜像只有12MB大小！

在构建此容器时，您可能会注意到Dockerfile会执行一些奇怪的操作，例如手动将HTTPS证书安装到容器中。这是因为基础的 Alpine Linux 几乎没有预安装任何东西。因此，即使您需要手动安装任何依赖项，最终结果也还是超小容器镜像！

注意：如果您想节省更多空间，可以静态编译应用程序并使用 scratch 容器镜像。使用 scratch 作为基础容器镜像意味着您从头开始，根本没有基础层。但是，我建议使用 Alpine 作为基础镜像而不是 scratch ，因为 Alpine 镜像中的仅仅增加少量额外MB的大小却可以使得使用标准工具和安装依赖项变得更加容易。

在哪构建和存储您的容器镜像？

为了构建和存储镜像，我强烈推荐 Google Container Builder 和 Google Container Registry 的组合。 Google Container Builder 非常快，并自动将镜像推送到 Google Container Registry 。大多数开发人员应该可以轻松地在GCP的免费套餐中完成所有工作，而 Google Container Registry 与原始Google云端存储的价格相同（便宜！）。

Google Kubernetes Engine 等平台可以安全地从 Google Container Registry 中拉取镜像而无需任何其他配置，让您轻松上手！

此外， Google Container Registry 还为您提供漏洞扫描工具和开箱即用的IAM支持。这些工具可以使您更轻松地保护和锁定容器。

评估小体积容器的性能

人们声称小体积容器的巨大优势是缩短了时间——建立时间和拉取时间。让我们测试一下，使用 onbuild 创建的容器，对比在多阶段过程中使用 Alpine 创建的容器，看看真实情况如何。

TL;DR：对于功能强大的计算机或Container Builder没有显著差异，但对于性能没有那么强大的计算机和共享系统（如许多CI/CD系统）而言则有明显差异。就绝对性能而言，小镜像总是更好。

在大型机器上构建镜像

对于第一次测试，我将使用笔记本电脑进行构建。我正在使用我们的办公室WiFi，所以下载速度非常快！

对于每次构建，我都会删除缓存中的所有Docker镜像。

构建（Build）：

Go Onbuild: 35 Seconds
Go Multistage: 23 Seconds

对于较大的容器镜像，构建需要的时间大约是10秒左右。虽然这个代价仅在初始构建时需要付出，但是如果您使用持续集成系统，则在每次构建时都要付出这个代价。

下一个测试是将容器镜像推送到远程镜像仓库。对于此测试，我使用 Google Container Registry 来存储镜像。

推送（Push）：

Go Onbuild: 15 Seconds
Go Multistage: 14 Seconds

这很有趣！为什么需要花费相同的时间来推送12MB镜像和700MB镜像？事实证明， Google Container Registry 在幕后使用了很多技巧，包括许多流行基础镜像的全局缓存。

最后，我想测试将镜像从远程镜像仓库库拉到本地计算机所需的时间。

拉取（Pull）：

Go Onbuild: 26 Seconds
Go Multistage: 6 Seconds

20秒的差距，这是使用两个不同容器镜像之间的最大差异。您可以开始看到使用较小镜像的优势，尤其是在经常拉取镜像时。

您还可以使用 Google Container Builder 在云中构建容器镜像，这样可以自动将它们存储在 Google Container Registry 中。

构建（build）+推送（Push）：

Go Onbuild: 25 Seconds
Go Multistage: 20 Seconds

再次证明，使用较小的镜像有一点小优势，没有我想象的那么大。

在小型机器上构建镜像

如果是在小型机器上构建镜像，那么使用较小的容器镜像是否有优势呢？如果你有一个功能强大的笔记本电脑与快速互联网连接和/或容器生成器，优势并不明显。但是，如果您使用功能较弱的机器，故事就会发生变化。为了模拟这一点，我使用了一个 Google Compute Engine f1-micro VM 来构建，推送和拉取这些镜像，结果非常惊人！

构建（build）：

Go Onbuild: 52 seconds
Go Multistage: 6 seconds

推送（Push）：

Go Onbuild: 54 seconds
Go Multistage: 28 seconds

拉取（Pull）：

Go Onbuild: 48 Seconds
Go Multistage: 16 seconds

在这种情况下，使用较小的容器镜像确实非常有帮助！

在Kubernetes上拉取镜像

虽然您可能不关心构建和推送容器镜像所需的时间，但您应该非常关心拉取容器镜像所需的时间。对于Kubernetes，这可能是您的生产集群最重要的指标。

例如，假设您有一个三节点集群，其中一个节点崩溃。如果您使用的是像 Kubernetes Engine 这样的托管系统，系统会自动生成一个新节点来代替它。

但是，这个新节点将是全新的，并且必须先拉取所有容器镜像才能开始工作。拉取容器镜像所需的时间越长，集群执行的时间就越长！

当您增加群集大小（例如，使用 Kubernetes Engine Autoscaling ）或将节点升级到新版本的Kubernetes时，可能会发生这种情况（接下来的几集中会关注这个问题）。

我们可以看到来自多个部署的多个容器的拉取性能可以在这里真正体现出来，使用小容器可能会浪费几分钟的部署时间！

安全性和漏洞

除了性能之外，使用较小的容器镜像还有很大的安全性提升。与使用大基础镜像的容器镜像相比，小容器镜像通常具有较小的攻击面。

几个月前，我构建了 Go onbuild 和 multi-age 容器镜像，因此它们可能包含一些已被发现的漏洞。使用 Google Container Registry 的内置漏洞扫描，可以轻松扫描容器中的已知漏洞。让我们看看我们能找到些什么。

哇，这次两者之间有很大的不同！较小容器镜像中只有三个“中级”漏洞，而较大容器镜像中有16个严重漏洞和300多个其他漏洞。

让我们深入了解更大容器镜像里面存在的问题。

您可以看到大多数存在的问题与我们的应用程序无关，甚至没有我们的应用程序！因为多阶段构建使用的是更小的基础镜像，所以可以产生漏洞的东西更少。

结论

使用小容器镜像的性能和安全优势不言而喻。使用小的基础镜像和builder pattern可以更容易地构建小镜像，并且还有许多其他技术可用于单个技术栈和编程语言，以最小化容器体积。无论你做什么，你都可以确信你保持容器镜像最小化的努力是值得的！

本文转自DockOne-Kubernetes最佳实践S01E01：如何构建尽可能小的容器镜像？

微信关注我们

原文链接：https://yq.aliyun.com/articles/680342

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

DockOne微信分享（一八三）：滴滴弹性云Kubernetes实践

当前Kubetnetes已经成为容器编排领域事实的行业标准，越来越多的公司选择使用Kubernetes来搭建其容器云平台。本次分享主要介绍滴滴弹性云在围绕Kubernetes打造企业级私有云过程中的一些实践经验和教训，为同样正走在企业云化转型道路上的朋友们提供一些启发和帮助。当前滴滴国际化业务全部运行在弹性云平台上，国内的顺风车，金融，汽车后市场、企业安全、客服以及专车快车等业务的全部或部分模块也运行在我们的平台上。平台规模大约1K+宿主，2W+容器实例。今天的分享我主要聚焦一些我们平台相对有特色的地方，希望能给各位带来一些启发。网络模型首先介绍一下平台的网络模型，我们最开始使用的是Flannel，这种网络模型的问题大家应该都有体会，这里不多说。之后我们过度到了使用ONOS为主体集中式SDN网络，这种网络模型的功能可以说非常丰富，容器可以在overlay网络上随意漂移，且在容器名不变的情况下保证IP不变。于此同时容器IP相互独立，和物理网络双向互通，所以设置各类白名单也和物理机完全一致，不占用物理网络IP资源。利用Kubernetes的CNI可以很方便的为容器配置网络，用户使...

2018-12-18

564

自从Kubernetes项目开天辟地以来，其安全性已经取得了长足的发展，但它目前依然还有些要点值得注意。本文列举了11条军规来帮助让你的集群在稳定运行时加固安全，以及在受到危害时对抗冲击。这些军规涵盖了对控制面板的配置，对工作负载的防护，乃至对未来的展望。第一部分：控制面板作为Kubernetes的核心大脑，控制面板全面展示了在集群中所有容器和Pod的运行情况。它可以直接调度新的Pod（可能包含对宿主节点有root权限的容器），还可以用来读取集群中所有的secret。控制面板中展示的内容非常重要，需要好好的保护起来以免发生意外泄漏和恶意访问——无论这些内容是被访问时，在存储状态，又或者是在网络中传输时。 1. 全面启用TLS 应该在所有组件上都使用TLS，以防止网络嗅探，验证服务器端的身份，以及在启动双向TLS认证时验证客户端的身份。需要注意的是，一些组件在安装时可能会有默认设置启用http端口。管理员需要熟悉每个组件的设置从而识别出这种潜在会产生不安全流量的情况。出处这份来自 Lucas Käldström 的网络图展示了几处应该配置TLS的地...

2018-12-18

629

资源下载

更多资源

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。