不要被新项目分心，而是专注于取得你的 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中国 荣誉推出

Kubernetes 就像一辆翻斗车。它非常适合解决它所针对的问题，但你必须首先掌握其学习曲线。

在为什么说 Kubernetes 是一辆翻斗车中，我谈到了一个工具如何优雅地解决它所设计用来解决的问题 —— 只是你要学会如何使用它。在本系列的第 2 部分中，我将更深入地了解 Kubernetes 的学习曲线。

Kubernetes 的旅程通常从在一台主机上运行一个容器开始。你可以快速了解运行新版本软件的难易程度，与其他人分享该软件的难易程度，以及对于这些用户按照你预期方式运行它的难易程度。

但是你需要：

• 两个容器
• 两个主机

使用容器在端口 80 上启动一个 Web 服务器很容易，但是当你需要在端口 80 上启动第二个容器时会发生什么？当你构建生产环境时，需要容器化 Web 服务器在发生故障时转移到第二个主机时会发生什么？在任何一种情况下，这个答案简单来说就是你必须采用容器编排。

当你开始处理两个容器或两个主机问题时，你将不可避免地引入了复杂性，因此，这就是一个学习曲线。这个两个服务（容器的更通用说法）或两个主机的问题已经存在了很长时间，并且由此带来了复杂性。

从历史上看，这将涉及负载均衡、集群软件甚至集群文件系统。每个服务的配置逻辑都嵌入在每个系统（负载均衡、集群软件和文件系统）中。在负载平衡器后运行 60 或 70 个集群的服务是复杂的。添加另一个新服务也很复杂。更糟糕的是，撤下服务简直是一场噩梦。回想起我对生产环境中的 MySQL 和 Apache 服务器进行故障排除的日子，这些服务器的逻辑嵌入在三、四个或五个不同的地方，所有这些都采用不同的格式，让我头疼不已。

Kubernetes 使用一个软件优雅地解决了所有这些问题：

1. 两项服务（容器）：✅
2. 两台服务器（高可用性）：✅
3. 单一配置来源：✅
4. 标准配置格式：✅
5. 网络：✅
6. 储存：✅
7. 依赖关系（什么服务与哪些数据库对应）：✅
8. 易于配置：✅
9. 轻松取消配置：✅（也许是 Kubernetes 最强大的部分）

等等，这样初看起来 Kubernetes 非常优雅、非常强大。 没错。你可以在 Kubernetes 中建模一整个微型 IT 世界。

所以，是的，就像开始使用巨型翻斗车（或任何专业设备）时，有一个学习曲线。使用 Kubernetes 还有一个学习曲线，但它值得，因为你可以用一个工具解决这么多问题。如果你对学习曲线感到担忧，请仔细考虑 IT 基础架构中的所有底层网络、存储和安全问题，并设想一下今天的解决方案 —— 这并不容易。特别是当你越来越快地引入越来越多的服务时。速度是当今的目标，因此要特别考虑配置和取消配置问题。

但是，不要混淆了建造或配置 Kubernetes 的学习曲线（为你的翻斗车挑选合适的挡泥板可能很难，LOL）和使用它的学习曲线。学习用如此多的不同层次（容器引擎、日志记录、监控、服务网格、存储、网络）的技术来建立自己的 Kubernetes 有很多不同的选择，还有每六个月维护每个组件的更新选择，这可能不值得投资 —— 但学会使用它绝对是值得的。

我每天都与 Kubernetes 和容器泡在一起，即使这样我都很难跟踪几乎每天都在宣布的所有重大新项目。 但是，每一天我都对使用单一工具来模拟整个 IT 多个方面的运营优势感到兴奋。此外，记住 Kubernetes 已经成熟了很多，并将继续发展下去。与之前的 Linux 和 OpenStack 一样，每一层的接口和事实上的项目都将成熟并变得更容易选择。

在本系列的第三篇文章中，我将深入挖掘你在驾驶 Kubernetes “卡车”之前需要了解的内容。

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

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

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

翻斗车是解决各种基本业务问题的优雅解决方案。

这篇文章写于 Kubernetes 的生日（6 月 7 日星期五）前夕。

翻斗车很优雅。说真的，不信你听我说。它们以优雅的方式解决了各种各样的技术问题。它们可以搬动泥土、砾石、岩石、煤炭、建筑材料或道路上的障碍。它们甚至可以拉动拖车及它们上面的其他重型设备。你可以给一辆翻斗车装上五吨泥土，然后自驾游遍全国。对于像我这样的电脑极客来说，那就是优雅。

但是，它们并不容易使用。驾驶翻斗车需要特殊的驾驶执照。它们也不容易装配和维护。购买翻斗车和各种维护时要做很多选择。但是，它们可以优雅的搬动那些垃圾。

你知道搬动垃圾有什么不优雅的地方吗？假如你有一款新型的紧凑型轿车，它们到处可以买到，易于驾驶、更易于维护。但是，用它们来装泥土就很糟糕。这需要跑 200 趟才能运走 5 吨垃圾，而且，之后没人再会想要这辆车了。

好吧，你可以买一辆出售的翻斗车，而不是想自己造一辆。但是我不同，我是个极客，我喜欢自己造东西。但……

如果你拥有一家建筑公司，你就不会想着自己造一辆翻斗车。你肯定不会维持一条供应链来重构翻斗车（这可是一条很大的供应链）。但你可以学会驾驶一辆。

好吧，我的这个比喻很粗糙，但很容易理解。易用性是相对的，易于维护是相对的，易于装配也是相对的。这实际上取决于你想要做什么。Kubernetes 也不例外。

一次性构建 Kubernetes 并不太难。配置好 Kubernetes 呢？好吧，这稍微难一些。你如何看待 KubeCon？它们又宣布了多少新项目？哪些是“真实的”呢？而你应该学习哪些？你对 Harbour、TikV、NATD、Vitess，开放策略代理有多深入的了解？更不用说 Envoy、eBPF 和 Linux 中的一系列底层技术？这就像是 1904 年工业革命爆发时建造翻斗车一样，你要弄清楚使用的螺钉、螺栓、金属和活塞。（有没有蒸汽朋克在这里吗？）

像翻斗车一样构造和配置 Kubernetes 是一个技术问题，如果你从事金融服务、零售、生物研究、食品服务等等，这可能不是你应该做的事情。但是，学习如何驾驶 Kubernetes 肯定是你应该学习的东西。

Kubernetes 就像一辆翻斗车，因其可以解决的各种技术问题（以及它所拖带的生态系统）而优雅。所以，我会给你一句引用的话，这是我的一位计算机科学教授在我大学的第一年告诉我们的，她说，“有一天，你会看到一段代码并对自己说，‘真特么优雅！’”

Kubernetes 很优雅。

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

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

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

从一条日志消息的角度来巡览现代分布式系统。

混沌系统往往是不可预测的。在构建像分布式系统这样复杂的东西时，这一点尤其明显。如果不加以控制，这种不可预测性会无止境的浪费时间。因此，分布式系统的每个组件，无论多小，都必须设计成以简化的方式组合在一起。

Kubernetes 为抽象计算资源提供了一个很有前景的模型 —— 但即使是它也必须与其他分布式平台（如 Apache Kafka）协调一致，以确保可靠的数据传输。如果有人要整合这两个平台，它会如何运作？此外，如果你通过这样的系统跟踪像日志消息这么简单的东西，它会是什么样子？本文将重点介绍来自在 OKD 内运行的应用程序的日志消息如何通过 Kafka 进入数据仓库（OKD 是为 Red Hat OpenShift 提供支持的 Kubernetes 的原初社区发行版）。

OKD 定义的环境

这样的旅程始于 OKD，因为该容器平台完全覆盖了它抽象的硬件。这意味着日志消息等待由驻留在容器中的应用程序写入 stdout 或 stderr 流。从那里，日志消息被容器引擎（例如 CRI-O）重定向到节点的文件系统。

在 OpenShift 中，一个或多个容器封装在称为 pod（豆荚）的虚拟计算节点中。实际上，在 OKD 中运行的所有应用程序都被抽象为 pod。这允许应用程序以统一的方式操纵。这也大大简化了分布式组件之间的通信，因为 pod 可以通过 IP 地址和负载均衡服务进行系统寻址。因此，当日志消息由日志收集器应用程序从节点的文件系统获取时，它可以很容易地传递到在 OpenShift 中运行的另一个 pod 中。

在豆荚里的两个豌豆

为了确保可以在整个分布式系统中四处传播日志消息，日志收集器需要将日志消息传递到在 OpenShift 中运行的 Kafka 集群数据中心。通过 Kafka，日志消息可以以可靠且容错的方式低延迟传递给消费应用程序。但是，为了在 OKD 定义的环境中获得 Kafka 的好处，Kafka 需要完全集成到 OKD 中。

运行 Strimzi 操作子将所有 Kafka 组件实例化为 pod，并将它们集成在 OKD 环境中运行。 这包括用于排队日志消息的 Kafka 代理，用于从 Kafka 代理读取和写入的 Kafka 连接器，以及用于管理 Kafka 集群状态的 Zookeeper 节点。Strimzi 还可以将日志收集器实例化兼做 Kafka 连接器，允许日志收集器将日志消息直接提供给在 OKD 中运行的 Kafka 代理 pod。

在 OKD 内的 Kafka

当日志收集器 pod 将日志消息传递给 Kafka 代理时，收集器会写到单个代理分区，并将日志消息附加到该分区的末尾。使用 Kafka 的一个优点是它将日志收集器与日志的最终目标分离。由于解耦，日志收集器不关心日志最后是放在 Elasticsearch、Hadoop、Amazon S3 中的某个还是全都。Kafka 与所有基础设施连接良好，因此 Kafka 连接器可以在任何需要的地方获取日志消息。

一旦写入 Kafka 代理的分区，该日志消息就会在 Kafka 集群内的跨代理分区复制。这是它的一个非常强大的概念；结合平台的自愈功能，它创建了一个非常有弹性的分布式系统。例如，当节点变得不可用时，（故障）节点上运行的应用程序几乎立即在健康节点上生成。因此，即使带有 Kafka 代理的节点丢失或损坏，日志消息也能保证存活在尽可能多的节点上，并且新的 Kafka 代理将快速原位取代。

存储起来

在日志消息被提交到 Kafka 主题后，它将等待 Kafka 连接器使用它，该连接器将日志消息中继到分析引擎或日志记录仓库。在传递到其最终目的地时，可以分析日志消息以进行异常检测，也可以查询日志以立即进行根本原因分析，或用于其他目的。无论哪种方式，日志消息都由 Kafka 以安全可靠的方式传送到目的地。

OKD 和 Kafka 是正在迅速发展的功能强大的分布式平台。创建能够在不影响性能的情况下抽象出分布式计算的复杂特性的系统至关重要。毕竟，如果我们不能简化单一日志消息的旅程，我们怎么能夸耀全系统的效率呢？

via: https://opensource.com/article/18/9/life-log-message

作者：Josef Karásek 选题：lujun9972 译者：wxy 校对：wxy

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

Kubernetes 解决了一些开发和运维团队每天关注的的常见问题。

Kubernetes（K8S）是面向企业的开源容器编排工具的事实标准。它提供了应用部署、扩展、容器管理和其他功能，使企业能够通过容错能力快速优化硬件资源利用率并延长生产环境运行时间。该项目最初由谷歌开发，并将该项目捐赠给云原生计算基金会（CNCF）。2018 年，它成为第一个从 CNCF 毕业的项目。

这一切都很好，但它并不能解释为什么开发者和运维人员应该在 Kubernetes 上投入宝贵的时间和精力。Kubernetes 之所以如此有用，是因为它有助于开发者和运维人员迅速解决他们每天都在努力解决的问题。

以下是 Kubernetes 帮助开发者和运维人员解决他们最常见问题的五种能力。

1、厂商无关

许多公有云提供商不仅提供托管 Kubernetes 服务，还提供许多基于这些服务构建的云产品，来用于本地应用容器编排。由于与供应商无关，使运营商能够轻松、安全地设计、构建和管理多云和混合云平台，而不会有供应商锁定的风险。Kubernetes 还消除了运维团队对复杂的多云/混合云战略的担忧。

2、服务发现

为了开发微服务应用，Java 开发人员必须控制服务可用性（就应用是否可以提供服务而言），并确保服务持续存在，以响应客户端的请求，而没有任何例外。Kubernetes 的服务发现功能意味着开发人员不再需要自己管理这些东西。

3、触发

你的 DevOps 会如何在上千台虚拟机上部署多语言、云原生应用？理想情况下，开发和运维会在 bug 修复、功能增强、新功能、安全更新时触发部署。Kubernetes 的部署功能会自动化这个日常工作。更重要的时，它支持高级部署策略，例如蓝绿部署和金丝雀部署。

4、可伸缩性

自动扩展是处理云环境中大量工作负载所需的关键功能。通过构建容器平台，你可以为终端用户提高系统可靠性。Kubernetes Horizo​​ntal Pod Autoscaler（HPA）允许一个集群增加或减少应用程序（或 Pod）的数量，以应对峰值流量或性能峰值，从而减少对意外系统中断的担忧。

5、容错性

在现代应用体系结构中，应考虑故障处理代码来控制意外错误并快速从中恢复。但是开发人员需要花费大量的时间和精力来模拟偶然的错误。Kubernetes 的 ReplicaSet 通过确保指定数量的 Pod 持续保持活动来帮助开发人员解决此问题。

结论

Kubernetes 使企业能够轻松、快速、安全地解决常见的开发和运维问题。它还提供其他好处，例如构建无缝的多云/混合云战略，节省基础架构成本以及加快产品上市时间。

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

作者：Daniel Oh 选题：lujun9972 译者：geekpi 校对：wxy

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

创建统一管理的，具备灵活性的云原生生产部署来部署一个个性化的数据库即服务（DBaaS）。

通过在 Kubernetes 上运行 PostgreSQL 数据库，你能创建统一管理的，具备灵活性的云原生生产部署应用来部署一个个性化的数据库即服务为你的特定需求进行量身定制。

对于 Kubernetes，使用 Operator 允许你提供额外的上下文去管理有状态应用。当使用像PostgreSQL 这样开源的数据库去执行包括配置、扩展、高可用和用户管理时，Operator 也很有帮助。

让我们来探索如何在 Kubernetes 上启动并运行 PostgreSQL。

安装 PostgreSQL Operator

将 PostgreSQL 和 Kubernetes 结合使用的第一步是安装一个 Operator。在针对 Linux 系统的Crunchy 的快速启动脚本的帮助下，你可以在任意基于 Kubernetes 的环境下启动和运行开源的Crunchy PostgreSQL Operator。

快速启动脚本有一些必要前提：

• Wget 工具已安装。
• kubectl 工具已安装。
• 在你的 Kubernetes 中已经定义了一个 StorageClass。
• 拥有集群权限的可访问 Kubernetes 的用户账号，以安装 Operator 的 RBAC 规则。
• 一个 PostgreSQL Operator 的 命名空间。

执行这个脚本将提供给你一个默认的 PostgreSQL Operator 部署，其默认假设你采用 动态存储和一个名为 standard 的 StorageClass。这个脚本允许用户采用自定义的值去覆盖这些默认值。

通过下列命令，你能下载这个快速启动脚本并把它的权限设置为可执行：

wget <https://raw.githubusercontent.com/CrunchyData/postgres-operator/master/examples/quickstart.sh>
chmod +x ./quickstart.sh

然后你运行快速启动脚本：

./examples/quickstart.sh

在脚本提示你相关的 Kubernetes 集群基本信息后，它将执行下列操作：

• 下载 Operator 配置文件
• 将 $HOME/.pgouser 这个文件设置为默认设置
• 以 Kubernetes Deployment 部署 Operator
• 设置你的 .bashrc 文件包含 Operator 环境变量
• 设置你的 $HOME/.bash_completion 文件为 pgo bash_completion 文件

在快速启动脚本的执行期间，你将会被提示在你的 Kubernetes 集群设置 RBAC 规则。在另一个终端，执行快速启动命令所提示你的命令。

一旦这个脚本执行完成，你将会得到提示设置一个端口以转发到 PostgreSQL Operator pod。在另一个终端，执行这个端口转发操作；这将允许你开始对 PostgreSQL Operator 执行命令！尝试输入下列命令创建集群：

pgo create cluster mynewcluster

你能输入下列命令测试你的集群运行状况：

pgo test mynewcluster

现在，你能在 Kubernetes 环境下管理你的 PostgreSQL 数据库了！你可以在官方文档找到非常全面的命令，包括扩容，高可用，备份等等。

这篇文章部分参考了该作者为 Crunchy 博客而写的在 Kubernetes 上开始运行 PostgreSQL。

via: https://opensource.com/article/19/3/how-run-postgresql-kubernetes

作者：Jonathan S. Katz 选题：lujun9972 译者：arrowfeng 校对：wxy

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