管理开发的复杂性

Kubernetes原生开发中最关键的领域之一就是开发环境的管理。为了成功部署或提升（staging）至多个环境，需要执行的任务变得越来越多。其中一个原因就是独立应用或微服务的数量在不断增加。另外一个原因则是针对必要基础设施的特定应用的配置。图1-1给出了一个示例开发环境的概览，其中包括了实现完全自动化所需的工具。在本书中，我们会讨论其中的一部分，从而能够让你在新环境中快速起步。核心的开发任务并没有什么变化。你依然需要合适的框架来编写应用或服务，比如我们在本书中所使用的Quarkus（网址见链接列表1.17条目）。这一部分的开发工作流通常被称为“内循环”开发。

在本书中，我们会用大多数的时间来讨论“外循环”中的变化和机会。外循环会涉及构建和测试应用程序，并通过各种机制将其投入生产。有必要提醒大家，本书旗帜鲜明地表达了我们源于实践给出的观点；推荐的工具和技术，我们在体验后认为它们能够使Java开发人员变得更高效、快捷，甚至心情更愉悦。如图1-1所示，你在某些方面拥有一到两个选择。在本书中，我们为开发人员选择了更为传统的方式。比如，使用Maven而不是Gradle来构建应用，使用podman而不是Docker来构建容器镜像。我们还使用OpenJDK而不是GraalVM，并在例子中坚持使用JUnit而不是Testcontainers（网址见链接列表1.18条目）。

但是，正如CNCF全景图（网址见链接列表1.19条目）所描绘的那样，云原生生态系统有更多工具供我们选择。你可以把本书看作是企业级Java开发者的线索图。

图1-1 内循环与外循环开发，以及作者推荐的工具

除了技术选择，我们还必须决定如何使用这个新的生态系统。随着各种工具的出现，我们用另外一个维度来衡量Kubernetes的采用程度。如图1-2所示，我们将其区分为“预置倾向性”和“灵活性”。作为一个痴迷于细节的开发人员，你可能想要从实战中学习各种例子，编写YAML文件并使用“普通”的Kubernetes。

最初，YAML的含义是“另外一种标记语言（Yet Another Markup Language）”。这个名称的目的是表明它是一种标记语言，是一种调侃的说法。但是，后来它被重定义为“YAML不是一种标记语言（YAML Ain't Markup Language）”，这是一种递归的缩写，以强调它面向数据的目的。

你可能只关注源码，不想在实现业务逻辑时分心，这可以通过使用一些发行版所提供的开发工具来实现。取决于开发过程中事情的重要性，可以有多种选择。你可以使用主要的Kubernetes命令行接口（CLI）kubctl来取代特定产品的工具，比如OpenShift的CLI oc。如果你想要更完整的产品，那么建议你尝试一下CodeReady Containers（网址见链接列表1.20条目），这是一个能够在笔记本电脑上运行的OpenShift集群，可以提供简单的入门体验。但是，选择权在你。

我们推荐的另一个好工具是o d o（网址见链接列表1.21条目），它是一个通用的开发者CLI，适用于基于Kubernetes的项目。现有的工具，如kubectl和oc，更注重于运维，需要对底层概念有深刻的理解。odo为开发人员抽象出了复杂的Kubernetes概念。外循环开发的示例选择了持续集成（CI）解决方案。本书使用了Tekton（网址见链接列表1.22条目），在第6章中可以学习如何使用它。另一种可能是借助Jenkins Operator（网址见链接列表1.23条目）或者借助Jenkins X在Kubernetes上使用Jenkins。无论怎么选，你才是Kubernetes原生旅程的主人。

图1-2 “预置倾向性”和“灵活性”：在开发内循环和外循环中的技术选择