高级开发指南

本页假定您已经熟悉 Kubernetes 的核心概念并可以轻松的部署自己的应用程序。如果还不能，您需要先查看下中级应用开发者主题。

在浏览了本页面及其链接的内容后，您将会更好的理解如下部分：

使用高级功能部署应用

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

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

Sidecar 容器：虽然 Pod 中依然需要有一个主容器，你还可以添加一个副容器作为辅助（见日志示例)。单个 Pod 中的两个容器可以通过共享卷进行通信。
Init 容器：Init 容器在 Pod 的应用容器（如主容器和 sidecar 容器）之前运行。阅读更多，查看 nginx 服务器示例，并学习如何调试这些容器。

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

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

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

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

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

Kubernetes 在设计之初就考虑到了可扩展性。如果上面提到的 API 资源和功能不足以满足您的需求，则可以自定义其行为，而无需修改核心 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 纯粹作为存储。