容器构建有两大趋势：使用基本镜像和从头开始构建。每个都有工程上的权衡。

有人说 Linux 发行版不再与容器有关。像 distroless 和 scratch 容器等可替代的方法，似乎是风靡一时。看来，我们在考虑和做出技术决策时，更多的是基于时尚感和即时的情感满足，而不是考虑我们选择的次要影响。我们应该问这样的问题：这些选择将如何影响未来六个月的维护？工程权衡是什么？这种范式转换如何影响我们的大规模构建系统？

这真让人沮丧。如果我们忘记了工程是一个零和游戏，有可衡量的利弊权衡，有不同方法的成本和收益 —— 这样对我们自己不利，对雇主不利，对最终维护我们的代码的同事不利。最后，我们对所有的维护人员（向维护人员致敬！ ）都是一种伤害，因为我们不欣赏他们所做的工作。

理解问题所在

为了理解这个问题，我们必须首先研究为什么我们使用 Linux 发行版。我将把原因分为两大类：内核和其他包。编译内核实际上相当容易。Slackware 和 Gentoo（ 我的小心脏还是有点害怕）教会了我们这一点。

另一方面，对于一个可用的 Linux 系统需要打包大量的开发软件和应用软件，这可能会让人望而生畏。此外，确保数百万个程序包可以一起安装和工作的唯一方法是使用旧的范例：即编译它并将它作为一个工件（即 Linux 发行版）一起发布。那么，为什么 Linux 发行版要将内核和所有包一起编译呢？很简单：确保事情协调一致。

首先，我们来谈谈内核。内核很特别。在没有编译好的内核的情况下引导 Linux 系统有点困难。它是 Linux 操作系统的核心，也是我们在系统启动时首先依赖的。内核在编译时有很多不同的配置选项，这些选项会对硬件和软件如何在一个内核上运行产生巨大影响。这方面中的第二个问题是，系统软件（如编译器 、C 库和解释器）必须针对内核中内置的选项进行调优。Gentoo 的维基以一种发自内心的方式教我们这一点，它把每个人都变成了一个微型的开发版维护者。

令人尴尬的是（因为我在过去五年里一直在使用容器），我必须承认我最近才编译过内核。我必须让嵌套的 KVM 在 RHEL7 上工作，这样我才能在笔记本电脑上的 KVM 虚拟机中运行 OpenShift on OpenStack 虚拟机，以及我的 Container Development Kit（CDK）。我只想说，当时我在一个全新的 4.X 内核上启动了 RHEL7。和任何优秀的系统管理员一样，我有点担心自己错过了一些重要的配置选项和补丁。当然，我也的确错过了一些东西。比如睡眠模式无法正常工作，我的扩展底座无法正常工作，还有许多其他小的随机错误。但它在我的笔记本电脑上的一个 KVM 虚拟机上，对于 OpenStack 上的 OpenShift 的实时演示来说已经足够好了。来吧，这很有趣，对吧？但我离题了……

现在，我们来谈谈其他的软件包。虽然内核和相关的系统软件可能很难编译，但从工作负载的角度来看，更大的问题是编译成千上万的包，以提供一个可用的 Linux 系统。每个软件包都需要专业知识。有些软件只需要运行三个命令：./configure、make 和 make install。另一些则需要大量的专业知识，从在 etc 中添加用户和配置特定的默认值到运行安装后脚本和添加 systemd 单元文件。对于任何一个人来说，调试好你可能用得到的成千上万种不同软件所需要的一套技能都是令人望而生畏的。但是，如果你想要一个可以随时尝试新软件的可用系统，你必须学会如何编译和安装新软件，然后才能开始学习使用它。这就是没有 Linux 发行版的 Linux。当你放弃使用 Linux 发行版时，那么你就得自己编译软件。

关键是，你必须将所有内容构建在一起，以确保它能够以任何合理的可靠性级别协同工作，而且构建一个可用的包群需要大量的知识。这是任何一个开发人员或系统管理员都无法合理地学习和保留的知识。我描述的每个问题都适用于你的 容器主机（内核和系统软件）和 容器镜像（系统软件和所有其他包）——请注意：在容器镜像中还包含有编译器 、C 库、解释器和 JVM。

解决方案

所以你也看到了，其实使用 Linux 发行版就是解决方案。别再看了，给离你最近的软件包维护者（再次向维护人员致敬！）发张电子卡吧（等等，我是不是把我的年龄告诉别人了？）。不过说真的，这些人做了大量的工作，这真的是被低估了。Kubernetes、Istio、Prometheus，还有 Knative：我在看着你们。你们的时代要来了，到时候你们会进入维护模式，被过度使用，被低估。大约七到十年后，我将再次写这篇文章，可能是关于 Kubernetes 的。

容器构建的首要原则

从零开始构建和从基础镜像构建之间存在权衡。

从基础镜像构建

从基础镜像构建的优点是，大多数构建操作只不过是安装或更新包。它依赖于 Linux 发行版中包维护人员所做的大量工作。它还有一个优点，即六个月甚至十年后的修补事件（使用 RHEL）是运维/系统管理员事件 （yum update），而不是开发人员事件（这需要通过代码找出某些函数参数不再工作的原因）。

你想想，应用程序代码依赖于许多库，从 JSON mung 库到对象关系映射器。与 Linux 内核和 Glibc 不同，这些类型的库很少改变 API 兼容性。这意味着三年后你的修补事件可能会变成代码更改事件，而不是 yum 更新事件。因此让他自己深入下去吧。开发人员，如果安全团队找不到防火墙黑客来阻止攻击，你将在凌晨 2 点收到短信。

从基础镜像构建不是完美的；还有一些缺点，比如所有被拖入的依赖项的大小。这几乎总是会使容器镜像比从头开始构建的镜像更大。另一个缺点是你并不总是能够访问最新的上游代码。这可能会让开发人员感到沮丧，尤其是当你只想使用依赖项中的一部分功能时，但是你仍然不得不将你根本用不着的东西一起打包带走，因为上游的维护人员一直在改变这个库。

如果你是一个 web 开发人员，正在对我翻白眼，我有一个词可以形容你：DevOps。那意味着你带着寻呼机，我的朋友。

Scratch 构建

Scratch 构建的优点是镜像非常小。当你不依赖容器中的 Linux 发行版时，你有很多控制权，这意味着你可以根据需要定制所有内容。这是一个最佳模型，在某些用例中是很有效的。另一个优势是你可以访问最新的软件包。你不必等待 Linux 发行版更新任何内容。是你自己在控制，所以你可以自行选择什么时候去费功夫纳入新的软件。

记住，控制一切都是有代价的。通常，更新到具有新特性的新库会拖如不必要的 API 更改，这意味着修复代码中的不兼容（换句话说，这就像给牦牛剪毛）。在凌晨 2 点应用程序不起作用的时候给牦牛剪毛是不好玩的。幸运的是，使用容器，你可以在下一个工作日回滚并给牦牛剪毛，但它仍会占用你为业务提供新价值、为应用程序提供新功能的时间。欢迎来到系统管理员的生活。

好吧，也就是说，有些时候，Scratch 构建是有意义的。我完全承认，静态编译的 Golang 程序和 C 程序是 scratch/distorless 构建的两个不错的候选程序。对于这些类型的程序，每个容器构建都是一个编译事件。三年后你仍然需要担心 API 的损坏，但是如果你是一个 Golang 商店，你应该有能力随着时间的推移修复问题。

结论

基本上，Linux 发行版做了大量工作来节省你在常规 Linux 系统或容器上的时间。维护人员所拥有的知识是巨大的，而且没有得到真正的赞赏。容器的采用使得问题更加严重，因为它被进一步抽象了。

通过容器主机，Linux 发行版可以让你访问广泛的硬件生态系统，从微型 ARM 系统到 128 核 CPU x86 巨型机箱，再到云服务商的虚拟机。他们提供可工作的容器引擎和开箱即用的容器运行时环境，所以你只需启动你的容器，让其他人担心事情的进展。

对于容器镜像，Linux 发行版为你的项目提供了对大量软件的轻松访问。即使你从头开始构建，你也可能会看到一个包维护人员是如何构建和运送东西的 —— 一个好的艺术家是一个好的偷学者，所以不要低估这项工作的价值。

所以，感谢 Fedora、RHEL（Frantisek，你是我的英雄 ）、Debian、Gentoo 和其他 Linux 发行版的所有维护人员。我很感激你所做的工作，尽管我是个“容器工人”

via: https://opensource.com/article/19/2/linux-distributions-still-matter-containers

作者：Scott McCarty 选题：lujun9972 译者：Chao-zhi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

以及，对 2019 年最受欢迎的 Kubernetes 文章的回顾。

你是怎么追踪一个广受欢迎的项目（如 Kubernetes）的发展轨迹？你是怎么了解它发展到什么程度了？如果你在为这个项目作贡献或加入了特殊兴趣组（SIG），可能你会在潜移默化中了解到它的发展轨迹，但如果你的全日工作不涉及到为 Kubernetes 作贡献，那么你可能需要一点关于未来的预测来帮助你了解。对于一个诸如 Kubernetes 的快速发展的项目，年末是回顾过去的一年和展望新的一年的最好时机。

今年，Kubernetes 取得了很大的进展。除了去查看源码、文档、会议笔记，你也可以去浏览博客。为了深入了解，我在 Opensource.com 上找到了 Kubernetes 排名前十的文章。通过这些文章，我们能了解开发者们更喜欢读和写哪些话题的文章。我们开始吧！

• 为什么数据科学家喜欢Kubernetes
• Kubernetes 机密信息和 ConfigMap 简介
• 怎样在 Kubernetes 上运行 PostgreSQL（译文）
• 为什么说 Kubernetes 是一辆翻斗车（译文）
• 安全扫描你的 DevOps 流程
• 在 Kubernetes 上部署 InfluxDB 和 Grafana 以收集 Twitter 统计信息
• 使用 Kubernetes 操作器扩展 PostgreSQL
• 使用 Kubernetes 控制器减少系统管理员的工作量
• 将 Kubernetes 带到裸金属边缘计算
• 为什么你不必担心 Kubernetes

首先，我要指明这些文章中有 5 篇是关于 Kubernetes 工作负载的扩展以及它们可以运行在什么场景。这些工作负载涵盖数据科学、PostgreSQL、InfluxDB、Grafana（不仅仅监控集群本身）和边缘计算。从历史角度看，Kubernetes 和容器都是在虚拟机上运行的，尤其是运行在由云提供的基础设施上时。抛开对于 Kubernetes 的兴趣因素，这也表明了终端用户们极度希望在裸机上安装 Kubernetes（参照 用 OpenShift 在裸机环境运行 Kubernetes）。

其次，也有很多开发者希望了解操作相关的知识以及 Kubernetes 的最佳实践。从 Kubernetes 操作器 到 Kubernetes 控制器，从 机密信息 到 ConfigMaps，开发者和运维人员都希望能找到简化部署和管理工作的最佳实践。我们经常纠结在怎么去修改配置文件或别人会怎么配置，而不去回头想想这些配置是怎么让应用部署运转的（不是怎么安装，也不是怎么运行 Kubernetes）。

最后，人们似乎对入门教程真的感兴趣。事实上，构建 Kubernetes 所需了解的信息太多了，以至于让人们望而却步，也使他们走了错误的路。流行度高的文章中有几篇讲述了为什么你需要了解用 Kubernetes 运行应用程序，而不仅仅是安装它。就像最佳实践类的文章一样，人们也通常不会回头分析在入门时他们应该在什么地方花费时间。我一直秉持的理念是，把有限的时间和金钱投入到如何使用某项技术上，而不是如何构建它。

2020 年对 Kubernetes 的 5 个预测

回顾了 2019 年的相关主题，这些主题告诉我们 2020 年将如何发展？结合这些文章中的观点，加上我自己的看法，我来分享下我对于 2020 年以及未来发展趋势的想法：

1. 工作负载扩展。我会关注高性能计算、AI/ML 以及使用操作器的有状态工作负载。
2. 更多的生产中的最佳实践，尤其是跟一些成熟的标准相关的，像 PCI、HIPAA、NIST 等等。
3. 提升免 root 和更安全的运行时类（如 gVisor、Kata Containers 等等）的安全性。
4. 在部署和开发者们共享应用时，把 Kubernetes 清单的更好的规范标准作为部署的核心要素。如 podman 生成 kube、podman 运行 kube，还有多合一 Kubernetes 环境，如 CodeReady Containers (CRC)
5. 一个前所未有的网络、存储和专业硬件（如 GPU 等等）供应商的生态系统，为 Kubernetes 提供 BoB（LCTT 译注：best of breed，单项最佳品牌）解决方案（在自由软件中，我们相信开放的生态系统好过垂直整合的解决方案）。

期待 Kubernetes 在新的一年里再创辉煌！

via: https://opensource.com/article/20/1/kubernetes-2020

作者：Scott McCarty 选题：lujun9972 译者：lxbwolf 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

不仅可以部署简单的应用程序，还可以用 Kubernetes 运维器应对第 2 天运营。

在我的第一篇文章 为什么说 Kubernetes 是一辆翻斗车 中，我谈到了 Kubernetes 如何在定义、分享和运行应用程序方面很出色，类似于翻斗车在移动垃圾方面很出色。在第二篇中，如何跨越 Kubernetes 学习曲线，我解释了 Kubernetes 的学习曲线实际上与运行任何生产环境中的应用程序的学习曲线相同，这确实比学习所有传统组件要容易（如负载均衡器、路由器、防火墙、交换机、集群软件、集群文件系统等）。这是 DevOps，是开发人员和运维人员之间的合作，用于指定事物在生产环境中的运行方式，这意味着双方都需要学习。在第三篇 Kubernetes 基础：首先学习如何使用 中，我重新设计了 Kubernetes 的学习框架，重点是驾驶翻斗车而不是制造或装备翻斗车。在第四篇文章 帮助你驾驭 Kubernetes 的 4 个工具 中，我分享了我喜爱的工具，这些工具可帮助你在 Kubernetes 中构建应用程序（驾驶翻斗车）。

在这最后一篇文章中，我会分享我为什么对在 Kubernetes 上运行应用程序的未来如此兴奋的原因。

从一开始，Kubernetes 就能够很好地运行基于 Web 的工作负载（容器化的）。Web 服务器、Java 和相关的应用程序服务器（PHP、Python等）之类的工作负载都可以正常工作。该平台处理诸如 DNS、负载平衡和 SSH（由 kubectl exec 取代）之类的支持服务。在我的职业生涯的大部分时间里，这些都是我在生产环境中运行的工作负载，因此，我立即意识到，除了 DevOps 之外，除了敏捷之外，使用 Kubernetes 运行生产环境工作负载的强大功能。即使是我们几乎不改变我们的文化习惯，也可以提高效率。调试和退役变得非常容易，而这对于传统 IT 来说是极为困难的。因此，从早期开始，Kubernetes 就用一种单一的配置语言（Kube YAML/Json）为我提供了对生产环境工作负载进行建模所需的所有基本原语。

但是，如果你需要运行具有复制功能的多主 MySQL，会发生什么情况？使用 Galera 的冗余数据呢？你如何进行快照和备份？那么像 SAP 这样复杂的工作呢？使用 Kubernetes，简单的应用程序（Web 服务器等）的第 0 天（部署）相当简单，但是没有解决第 2 天的运营和工作负载。这并不是说，具有复杂工作负载的第 2 天运营要比传统 IT 难解决，而是使用 Kubernetes 并没有使它们变得更容易。每个用户都要设计自己的天才想法来解决这些问题，这基本上是当今的现状。在过去的五年中，我遇到的第一类问题是复杂工作负载的第 2 天操作。（LCTT 译注：在软件生命周期中，第 0 天是指软件的设计阶段；第 1 天是指软件的开发和部署阶段；第 2 天是指生产环境中的软件运维阶段。）

值得庆幸的是，随着 Kubernetes 运维器 Operator 的出现，这种情况正在改变。随着运维器的出现，我们现在有了一个框架，可以将第 2 天的运维知识汇总到平台中。现在，我们可以应用我在 Kubernetes 基础：首先学习如何使用 中描述的相同的定义状态、实际状态的方法，现在我们可以定义、自动化和维护各种各样的系统管理任务。

（LCTT 译注： Operator 是 Kubernetes 中的一种可以完成运维工程师的特定工作的组件，业界大多没有翻译这个名词，此处仿运维工程师例首倡翻译为“运维器”。）

我经常将运维器称为“系统管理机器人”，因为它们实质上是在第 2 天的工作中整理出一堆运维知识，该知识涉及 主题专家 Subject Matter Expert （SME、例如数据库管理员或系统管理员）针对的工作负载类型（数据库、Web 服务器等），通常会记录在 Wiki 中的某个地方。这些知识放在 Wiki 中的问题是，为了将该知识应用于解决问题，我们需要：

1. 生成事件，通常监控系统会发现故障，然后我们创建故障单
2. SME 人员必须对此问题进行调查，即使这是我们之前见过几百万次的问题
3. SME 人员必须执行该知识（执行备份/还原、配置 Galera 或事务复制等）

通过运维器，所有这些 SME 知识都可以嵌入到单独的容器镜像中，该镜像在有实际工作负荷之前就已部署。 我们部署运维器容器，然后运维器部署和管理一个或多个工作负载实例。然后，我们使用“运维器生命周期管理器”（Katacoda 教程）之类的方法来管理运维器。

因此，随着我们进一步使用 Kubernetes，我们不仅简化了应用程序的部署，而且简化了整个生命周期的管理。运维器还为我们提供了工具，可以管理具有深层配置要求（群集、复制、修复、备份/还原）的非常复杂的有状态应用程序。而且，最好的地方是，构建容器的人员可能是做第 2 天运维的主题专家，因此现在他们可以将这些知识嵌入到操作环境中。

本系列的总结

Kubernetes 的未来是光明的，就像之前的虚拟化一样，工作负载的扩展是不可避免的。学习如何驾驭 Kubernetes 可能是开发人员或系统管理员可以对自己的职业发展做出的最大投资。随着工作负载的增多，职业机会也将增加。因此，这是驾驶一辆令人惊叹的 在移动垃圾时非常优雅的翻斗车……

你可能想在 Twitter 上关注我，我在 @fatherlinux 上分享有关此主题的很多内容。

via: https://opensource.com/article/19/6/kubernetes-potential-run-anything

作者：Scott McCarty 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Kubernetes 绝对是满足复杂 web 应用程序需求的最简单、最容易的方法。

在 90 年代末和 2000 年代初，在大型网站工作很有趣。我的经历让我想起了 American Greetings Interactive，在情人节那天，我们拥有了互联网上排名前 10 位之一的网站（以网络访问量衡量）。我们为 AmericanGreetings.com、BlueMountain.com 等公司提供了电子贺卡，并为 MSN 和 AOL 等合作伙伴提供了电子贺卡。该组织的老员工仍然深切地记得与 Hallmark 等其它电子贺卡网站进行大战的史诗般的故事。顺便说一句，我还为 Holly Hobbie、Care Bears 和 Strawberry Shortcake 运营过大型网站。

我记得那就像是昨天发生的一样，这是我们第一次遇到真正的问题。通常，我们的前门（路由器、防火墙和负载均衡器）有大约 200Mbps 的流量进入。但是，突然之间，Multi Router Traffic Grapher（MRTG）图示突然在几分钟内飙升至 2Gbps。我疯了似地东奔西跑。我了解了我们的整个技术堆栈，从路由器、交换机、防火墙和负载平衡器，到 Linux/Apache web 服务器，到我们的 Python 堆栈（FastCGI 的元版本），以及网络文件系统（NFS）服务器。我知道所有配置文件在哪里，我可以访问所有管理界面，并且我是一位经验丰富的，打过硬仗的系统管理员，具有多年解决复杂问题的经验。

但是，我无法弄清楚发生了什么……

当你在一千个 Linux 服务器上疯狂地键入命令时，五分钟的感觉就像是永恒。我知道站点可能会在任何时候崩溃，因为当它被划分成更小的集群时，压垮上千个节点的集群是那么的容易。

我迅速跑到老板的办公桌前，解释了情况。他几乎没有从电子邮件中抬起头来，这使我感到沮丧。他抬头看了看，笑了笑，说道：“是的，市场营销可能会开展广告活动。有时会发生这种情况。”他告诉我在应用程序中设置一个特殊标志，以减轻 Akamai 的访问量。我跑回我的办公桌，在上千台 web 服务器上设置了标志，几分钟后，站点恢复正常。灾难也就被避免了。

我可以再分享 50 个类似的故事，但你脑海中可能会有一点好奇：“这种运维方式将走向何方?”

关键是，我们遇到了业务问题。当技术问题使你无法开展业务时，它们就变成了业务问题。换句话说，如果你的网站无法访问，你就不能处理客户交易。

那么，所有这些与 Kubernetes 有什么关系？一切！世界已经改变。早在 90 年代末和 00 年代初，只有大型网站才出现大型的、 规模级 web-scale 的问题。现在，有了微服务和数字化转型，每个企业都面临着一个大型的、规模级的问题——可能是多个大型的、规模级的问题。

你的企业需要能够通过许多不同的人构建的许多不同的、通常是复杂的服务来管理复杂的规模级的网站。你的网站需要动态地处理流量，并且它们必须是安全的。这些属性需要在所有层（从基础结构到应用程序层）上由 API 驱动。

进入 Kubernetes

Kubernetes 并不复杂；你的业务问题才复杂。当你想在生产环境中运行应用程序时，要满足性能（伸缩性、性能抖动等）和安全性要求，就需要最低程度的复杂性。诸如高可用性（HA）、容量要求（N+1、N+2、N+100）以及保证最终一致性的数据技术等就会成为必需。这些是每家进行数字化转型的公司的生产要求，而不仅仅是 Google、Facebook 和 Twitter 这样的大型网站。

在旧时代，我还在 American Greetings 任职时，每次我们加入一个新的服务，它看起来像这样：所有这些都是由网站运营团队来处理的，没有一个是通过订单系统转移给其他团队来处理的。这是在 DevOps 出现之前的 DevOps：

1. 配置 DNS（通常是内部服务层和面向公众的外部）
2. 配置负载均衡器（通常是内部服务和面向公众的）
3. 配置对文件的共享访问（大型 NFS 服务器、群集文件系统等）
4. 配置集群软件（数据库、服务层等）
5. 配置 web 服务器群集（可以是 10 或 50 个服务器）

大多数配置是通过配置管理自动完成的，但是配置仍然很复杂，因为每个系统和服务都有不同的配置文件，而且格式完全不同。我们研究了像 Augeas 这样的工具来简化它，但是我们认为使用转换器来尝试和标准化一堆不同的配置文件是一种反模式。

如今，借助 Kubernetes，启动一项新服务本质上看起来如下：

1. 配置 Kubernetes YAML/JSON。
2. 提交给 Kubernetes API（kubectl create -f service.yaml）。

Kubernetes 大大简化了服务的启动和管理。服务所有者（无论是系统管理员、开发人员还是架构师）都可以创建 Kubernetes 格式的 YAML/JSON 文件。使用 Kubernetes，每个系统和每个用户都说相同的语言。所有用户都可以在同一 Git 存储库中提交这些文件，从而启用 GitOps。

而且，可以弃用和删除服务。从历史上看，删除 DNS 条目、负载平衡器条目和 Web 服务器的配置等是非常可怕的，因为你几乎肯定会破坏某些东西。使用 Kubernetes，所有内容都处于命名空间下，因此可以通过单个命令删除整个服务。尽管你仍然需要确保其它应用程序不使用它（微服务和函数即服务 [FaaS] 的缺点），但你可以更加确信：删除服务不会破坏基础架构环境。

构建、管理和使用 Kubernetes

太多的人专注于构建和管理 Kubernetes 而不是使用它（详见 Kubernetes 是一辆翻斗车）。

在单个节点上构建一个简单的 Kubernetes 环境并不比安装 LAMP 堆栈复杂得多，但是我们无休止地争论着构建与购买的问题。不是 Kubernetes 很难；它以高可用性大规模运行应用程序。建立一个复杂的、高可用性的 Kubernetes 集群很困难，因为要建立如此规模的任何集群都是很困难的。它需要规划和大量软件。建造一辆简单的翻斗车并不复杂，但是建造一辆可以运载 10 吨垃圾并能以 200 迈的速度稳定行驶的卡车则很复杂。

管理 Kubernetes 可能很复杂，因为管理大型的、规模级的集群可能很复杂。有时，管理此基础架构很有意义；而有时不是。由于 Kubernetes 是一个社区驱动的开源项目，它使行业能够以多种不同方式对其进行管理。供应商可以出售托管版本，而用户可以根据需要自行决定对其进行管理。（但是你应该质疑是否确实需要。）

使用 Kubernetes 是迄今为止运行大规模网站的最简单方法。Kubernetes 正在普及运行一组大型、复杂的 Web 服务的能力——就像当年 Linux 在 Web 1.0 中所做的那样。

由于时间和金钱是一个零和游戏，因此我建议将重点放在使用 Kubernetes 上。将你的时间和金钱花费在掌握 Kubernetes 原语或处理活跃度和就绪性探针的最佳方法上（表明大型、复杂的服务很难的另一个例子）。不要专注于构建和管理 Kubernetes。（在构建和管理上）许多供应商可以为你提供帮助。

结论

我记得对无数的问题进行了故障排除，比如我在这篇文章的开头所描述的问题——当时 Linux 内核中的 NFS、我们自产的 CFEngine、仅在某些 Web 服务器上出现的重定向问题等）。开发人员无法帮助我解决所有这些问题。实际上，除非开发人员具备高级系统管理员的技能，否则他们甚至不可能进入系统并作为第二双眼睛提供帮助。没有带有图形或“可观察性”的控制台——可观察性在我和其他系统管理员的大脑中。如今，有了 Kubernetes、Prometheus、Grafana 等，一切都改变了。

关键是：

1. 时代不一样了。现在，所有 Web 应用程序都是大型的分布式系统。就像 AmericanGreetings.com 过去一样复杂，现在每个网站都有扩展性和 HA 的要求。
2. 运行大型的分布式系统是很困难的。绝对是。这是业务的需求，不是 Kubernetes 的问题。使用更简单的编排系统并不是解决方案。

Kubernetes 绝对是满足复杂 Web 应用程序需求的最简单，最容易的方法。这是我们生活的时代，而 Kubernetes 擅长于此。你可以讨论是否应该自己构建或管理 Kubernetes。有很多供应商可以帮助你构建和管理它，但是很难否认这是大规模运行复杂 Web 应用程序的最简单方法。

via: https://opensource.com/article/19/10/kubernetes-complex-business-problem

作者：Scott McCarty 选题：lujun9972 译者：laingke 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

学习如何驾驭 Kubernetes 比如何建造它更重要，这些工具可以帮助你更快上路。

在本系列的第三篇文章中，Kubernetes 基础：首先学习如何使用，我强调你应该学会使用 Kubernetes，而不是建造它。我还解释说，在 Kubernetes 中，你必须学习最小的一组原语来建模应用程序。我想强调这一点：你需要学习的这组原语是最简单的原语集，你可以通过它们学习如何实现生产级的应用程序部署（即高可用性 [HA]、多容器、多应用程序）。换句话说，学习 Kubernetes 内置的原语集比学习集群软件、集群文件系统、负载平衡器、让人发疯的 Apache 和 Nginx 的配置、路由器、交换机、防火墙和存储后端更容易 —— 这些是你在传统的 IT 环境（虚拟机或裸机）中建模简单的 HA 应用程序所需要的东西。

在这第四篇文章中，我将分享一些有助于你学习快速驾驭 Kubernetes 的工具。

1、Katacoda

无疑，Katacoda 是试驾 Kubernetes 集群的最简单方法。只需单击一下，五秒钟后就可以将基于 Web 的终端直接连接到正在运行的 Kubernetes 集群中。这对于使用和学习来说非常棒。我甚至将它用于演示和测试新想法。Katacoda 提供了一个完整的临时环境，在你使用完毕后可以回收利用。

OpenShift Playground

Kubernetes Playground

Katacoda 提供了一个临时的环境和更深入的实验室环境。例如，我最近三四年主讲的 Linux Container Internals Lab 是在 Katacoda 中构建的。

Katacoda 在其主站点上维护了若干 Kubernetes 和云教程并与 Red Hat 合作以支持了一个 OpenShift 的专用学习门户。了解一下，它们是极好的学习资源。

当你第一次学习驾驶翻斗车时，最好先观察一下其他人的驾驶方式。

2、Podman generate kube

podman generate kube 命令是一个很棒的子命令，可以帮助用户自然地从运行简单容器的简单容器引擎转换到运行许多容器的集群用例（正如我在上篇文章中所描述的那样）。Podman 通过让你启动一个新的容器，然后导出这个可工作的 Kube YAML，并在 Kubernetes 中启动它来实现这一点。看看这个（你可以在 Katacoda lab 中运行它，它已经有了 Podman 和 OpenShift）。

首先，请注意运行容器的语法与 Docker 非常相似：

podman run -dtn two-pizza quay.io/fatherlinux/two-pizza

不过这个是其它容器引擎所没有的：

podman generate kube two-pizza

输出：

# Generation of Kubernetes YAML is still under development!
#
# Save the output of this file and use kubectl create -f to import
# it into Kubernetes.
#
# Created with podman-1.3.1
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2019-06-07T08:08:12Z"
  labels:
    app: two-pizza
  name: two-pizza
spec:
  containers:
  - command:
    - /bin/sh
    - -c
    - bash -c 'while true; do /usr/bin/nc -l -p 3306 < /srv/hello.txt; done'
    env:
    - name: PATH
      value: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
    - name: TERM
      value: xterm
    - name: HOSTNAME
    - name: container
      value: oci
    image: quay.io/fatherlinux/two-pizza:latest
    name: two-pizza
    resources: {}
    securityContext:
      allowPrivilegeEscalation: true
      capabilities: {}
      privileged: false
      readOnlyRootFilesystem: false
    tty: true
    workingDir: /
status: {}
---
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: "2019-06-07T08:08:12Z"
  labels:
    app: two-pizza
  name: two-pizza
spec:
  selector:
    app: two-pizza
  type: NodePort
status:
  loadBalancer: {}

你现在有了一些可以的工作 Kubernetes YAML，你可以用它作为练习的起点来学习、调整等等。-s 标志可以为你创造一项服务。Brent Baude 甚至致力于添加卷/持久卷断言等新功能。如果想进一步深入，请在 Brent 的博客文章《Podman 现在可以轻松过渡到 Kubernetes 和 CRI-O》中了解他的工作。

3、oc new-app

oc new-app 命令非常强大。它是特定于 OpenShift 的，所以它在默认的 Kubernetes 中不可用，但是当你开始学习 Kubernetes 时它非常有用。让我们从快速命令开始创建一个相当复杂的应用程序：

oc new-project -n example
oc new-app -f https://raw.githubusercontent.com/openshift/origin/master/examples/quickstarts/cakephp-mysql.json

使用 oc new-app，你可以从 OpenShift 开发人员那里偷取模板，并在开发原语来描述你自己的应用程序时拥有一个已知良好的起点。运行上述命令后，你的 Kubernetes 命名空间（在 OpenShift 中）将由若干新的已定义资源填充。

oc get all

输出：

NAME                                READY     STATUS      RESTARTS   AGE
pod/cakephp-mysql-example-1-build   0/1       Completed   0          4m
pod/cakephp-mysql-example-1-gz65l   1/1       Running     0          1m
pod/mysql-1-nkhqn                   1/1       Running     0          4m

NAME                                            DESIRED   CURRENT   READY     AGE
replicationcontroller/cakephp-mysql-example-1   1         1         1         1m
replicationcontroller/mysql-1                   1         1         1         4m

NAME                            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/cakephp-mysql-example   ClusterIP   172.30.234.135   <none>        8080/TCP   4m
service/mysql                   ClusterIP   172.30.13.195    <none>        3306/TCP   4m

NAME                                                       REVISION   DESIRED   CURRENT   TRIGGERED BY
deploymentconfig.apps.openshift.io/cakephp-mysql-example   1          1         1         config,image(cakephp-mysql-example:latest)
deploymentconfig.apps.openshift.io/mysql                   1          1         1         config,image(mysql:5.7)

NAME                                                   TYPE      FROM      LATEST
buildconfig.build.openshift.io/cakephp-mysql-example   Source    Git       1

NAME                                               TYPE      FROM          STATUS     STARTED         DURATION
build.build.openshift.io/cakephp-mysql-example-1   Source    Git@47a951e   Complete   4 minutes ago   2m27s

NAME                                                   DOCKER REPO                                                      TAGS      UPDATED
imagestream.image.openshift.io/cakephp-mysql-example   docker-registry.default.svc:5000/example/cakephp-mysql-example   latest    About aminute ago

NAME                                             HOST/PORT                                                                         PATH   SERVICES                PORT      TERMINATION   WILDCARD
route.route.openshift.io/cakephp-mysql-example   cakephp-mysql-example-example.2886795271-80-rhsummit1.environments.katacoda.com   cakephp-mysql-example   <all>                   None

这样做的好处是你可以删除 Pod，观察复制控制器如何重新创建它们，缩放 Pod 等等。你可以使用模板并将其更改为其他应用程序（这是我第一次启动时所做的）。

4、Visual Studio Code

我把我最喜欢的放在最后。我的大部分工作都使用 vi，但我从来没有为 Kubernetes 找到一个好的语法高亮器和代码补完插件（如果有的话，请告诉我）。相反，我发现微软的 VS Code 有一套杀手级的插件，可以完成 Kubernetes 资源的创建并提供样板。

首先，安装上图中显示的 Kubernetes 和 YAML 插件。

然后，你可以从头开始创建新的 YAML 文件，并自动补完 Kubernetes 资源。上面的示例显示了一个服务。

当你使用自动补完并选择服务资源时，它会填充该对象的一些模板。当你第一次学习使用 Kubernetes 时，这非常棒。你可以构建 Pod、服务、复制控制器、部署等。当你从头开始构建这些文件甚至修改你使用 podman generate kube 创建的文件时，这是一个非常好的功能。

总结

这四个工具（如果算上两个插件，则为六个）将帮助你学习驾驭 Kubernetes，而不是构造或装备它。在本系列的最后一篇文章中，我将讨论为什么 Kubernetes 如此适合运行这么多不同的工作负载。

via: https://opensource.com/article/19/6/tools-drive-kubernetes

作者：Scott McCarty 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

不要被新项目分心，而是专注于取得你的 Kubernetes 翻斗车驾驶执照。

在本系列的前两篇文章中，我解释了为何 Kubernetes 像翻斗车，并且想要理解像 Kubernetes（和翻斗车，起重机等）这样优雅、专业工具总是有学习曲线的。本文是下一步：学习如何驾驶。

最近，我在 Reddit 上看到了一个关于重要的 Kubernetes 项目的帖子。人们似乎很想知道他们应该学习如何开始使用 Kubernetes。“驾驶翻斗车的类比”有助于确保这个问题回到轨道上去。在这个帖子中的某个人提到，除非必要，你不应该运行自己的镜像仓库，所以人们开始逐渐接受驾驭 Kubernetes 而不是构建它的想法。

API 是 Kubernetes 的引擎和变速器。像翻斗车的方向盘、离合器、汽油和制动踏板一样，用于构建应用程序的 YAML 或 JSON 文件是机器的主要接口。当你第一次学习 Kubernetes 时，这应该是你的主要关注点。了解你的控制部件。不要分心于最新和最大的那些项目。当你刚学会开车时，不要尝试驾驶实验性的翻斗车。相反，请专注于基础知识。

定义状态和实际状态

首先，Kubernetes 遵循定义状态和实际状态的原则。

人类（开发人员/系统管理员/运维人员）使用他们提交给 Kubernetes API 的 YAML/JSON 文件指定定义的状态。然后，Kubernetes 使用控制器来分析 YAML/JSON 中定义的新状态与集群中的实际状态之间的差异。

在上面的例子中，Replication Controller 可以看到用户指定的三个 pod 之间的差异，其中一个 pod 正在运行，并调度另外两个 Pod。如果你登录 Kubernetes 并手动杀死其中一个 Pod，它会不断启动另一个来替换它。在实际状态与定义的状态匹配之前，Kubernetes 不会停止。这是非常强大的。

原语

接下来，你需要了解可以在 Kubernetes 中指定的原语。

这些原语不仅仅有 Pod，还有 部署 Deployment 、 持久化卷声明 Persistent Volume Claim 、 服务 Service ， 路由 route 等。使用支持 Kubernetes 的平台 OpenShift，你可以添加 构建 build 和 BuildConfig。你大概需要一天左右的时间来了解这些原语。你可以在你的用例变得更加复杂时再深入了解。

将原生开发者映射到传统 IT 环境

最后，考虑这该如何映射到你在传统 IT 环境中的操作。

尽管是一个技术问题，但用户一直在尝试解决业务问题。从历史上看，我们使用诸如 剧本 playbook 之类的东西将业务逻辑与单一语言的 IT 系统绑定起来。对于运维人员来说，这很不错，但是当你尝试将其扩展到开发人员时，它会变得更加繁琐。

直到 Kubernete 出现之前，我们从未能够以原生开发者的方式真正同时指定一组 IT 系统应如何表现和交互。如果你考虑一下，我们正在使用在 Kubernetes 中编写的 YAML/JSON 文件以非常便携和声明的方式扩展了管理存储、网络和计算资源的能力，但它们总会映射到某处的“真实”资源。我们不必以开发者身份担心它。

因此，快放弃关注 Kubernetes 生态系统中的新项目，而是专注开始使用它。在下一篇文章中，我将分享一些可以帮助你使用 Kubernetes 的工具和工作流程。

via: https://opensource.com/article/19/6/kubernetes-basics

作者：Scott McCarty 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出