advance-developer

weight: 112 title:高级开发指南 date: “2022-05-21T00:00:00+08:00” type: book

本页假定您已经熟悉Kubernetes的核心概念并可以轻松的部署自己的应用程序。在浏览了本页面及其链接的内容后，您将会更好的理解如下部分：

• 可以在应用程序中使用的高级功能
• 扩展Kubernetes API的各种方法

使用高级功能部署应用

现在您知道了Kubernetes中提供的一组API对象。理解了daemonset和deployment之间的区别对于应用程序部署通常是足够的。也就是说，熟悉Kubernetes中其它的鲜为人知的功能也是值得的。因为这些功能有时候对于特别的用例是非常强大的。

容器级功能

如您所知，将整个应用程序（例如容器化的Rails应用程序，MySQL数据库以及所有应用程序）迁移到单个Pod中是一种反模式。这就是说，有一些非常有用的模式超出了容器和Pod之间的1:1的对应关系：

• Sidecar容器：虽然Pod中依然需要有一个主容器，你还可以添加一个副容器作为辅助（见 日志示例)。单个Pod中的两个容器可以通过共享卷进行通信。
• Init容器：Init容器在Pod的应用容器（如主容器和sidecar容器）之前运行。

Pod配置

通常，您可以使用label和annotation将元数据附加到资源上。将数据注入到资源，您可以会创建ConfigMap（用于非机密数据）或Secret（用于机密数据）。

下面是一些其他不太为人所知的配置资源Pod的方法：

• Taint（污点）和Toleration（容忍）：这些为节点“吸引”或“排斥” Pod提供了一种方法。当需要将应用程序部署到特定硬件（例如用于科学计算的GPU）时，经常使用它们。阅读更多。
• 向下API：这允许您的容器使用有关自己或集群的信息，而不会过度耦合到Kubernetes API server。这可以通过环境变量 或者 DownwardAPIVolumeFiles。
• Pod预设：通常，要将运行时需求（例如环境变量、ConfigMap和Secret）安装到资源中，可以在资源的配置文件中指定它们。PodPresets允许您在创建资源时动态注入这些需求。例如，这允许团队A将任意数量的新Secret安装到团队B和C创建的资源中，而不需要B和C的操作。

其他API对象

在设置以下资源之前，请检查这是否属于您组织的集群管理员的责任。

• Horizontal Pod Autoscaler (HPA) ：这些资源是在CPU使用率或其他自定义度量标准“秒杀”时自动化扩展应用程序的好方法。*查看示例*以了解如何设置HPA。
• 联合集群对象：如果使用federation在多个Kubernetes集群上运行应用程序，则需要部署标准Kubernetes API对象的联合版本。

扩展Kubernetes API

Kubernetes在设计之初就考虑到了可扩展性。如果上面提到的API资源和功能不足以满足您的需求，则可以自定义其行为，而无需修改核心Kubernetes代码。

理解Kubernetes的默认行为

在进行任何自定义之前，了解Kubernetes API对象背后的一般抽象很重要。虽然Deployment和Secret看起来可能完全不同，但对于任何对象来说，以下概念都是正确的：

• Kubernetes对象是存储有关您的集群的结构化数据的一种方式。

  在Deployment的情况下，该数据代表期望的状态（例如“应该运行多少副本？”），但也可以是通用的元数据（例如数据库凭证）。

• Kubernetes对象通过Kubernetes API修改。

  换句话说，您可以对特定的资源路径（例如 <api-server-url>/api/v1/namespaces/default/deployments ）执行 GET 和 POST 请求来读取或修改对应的对象类型。

• 利用 Controller模式，Kubernetes对象可被确保达到期望的状态。为了简单起见，您可以将Controller模式看作以下连续循环：

  1. 检查当前状态（副本数、容器镜像等）
  2. 对比当前状态和期望状态
  3. 如果不匹配则更新当前状态

  这些状态是通过Kubernetes API来获取的。

  并非所有的Kubernetes对象都需要一个Controller。尽管Deployment触发集群进行状态更改，但ConfigMaps纯粹作为存储。

创建自定义资源

基于上述想法，您可以定义与Deployment一样合法的自定义资源。例如，如果 CronJobs 不能提供所有您需要的功能，您可能需要定义 Backup 对象以进行定期备份。

创建自定义资源有以下两种方式：

1. 自定义资源定义（CRD）：这种实现方式的工作量最小。参考示例。
2. API聚合：在实际设置单独的扩展API server 之前，此方法需要一些预配置

请注意，与依赖内置的 kube-controller-manager 不同，您需要编写并运行自定义控制器。

下面是一些有用的链接：

• 如何才知道自定义资源是否符合您的使用场景
• CRD还是API聚合，如何选择？

Service Catalog

如果您想要使用或提供完整的服务（而不是单个资源），Service Catalog为此提供了一个规范。这些服务使用Service Broker注册（请参阅 示例）。

如果您没有集群管理员来管理Service Catalog的安装，您可以使用 Helm 或 二进制安装器。

探索其他资源

参考

以下主题对构建更复杂的应用程序也很有用：

• Kubernetes中的其他扩展点 -在哪里可以挂勾到Kubernetes架构的概念性的概述
• Kubernetes客户端库-用于构建需要与Kubernetes API大量交互的应用程序。

下一步

恭喜您完成了应用开发者之旅！您已经了解了Kubernetes提供的大部分功能。现在怎么办？

• 如果您想推荐新功能或跟上Kubernetes应用开发的最新进展，请考虑加入SIG，如 SIG Apps。