附加组件管理 ¶

kOps 包含一些附加组件的管理；我们必须管理一些在 Kubernetes API 正常运行之前需要的附加组件。

此外，kOps 通过 channels 工具提供附加组件的最终用户管理（该工具目前仍处于实验阶段，但我们正在努力使其成为 Kubernetes 附加组件管理的推荐部分）。我们在 addons 目录中提供了一些精选的附加组件，更多信息请参见 addons 文档。

kOps 也使用 channels 工具进行系统附加组件管理。由于 kOps 使用相同的工具进行系统附加组件管理和用户附加组件管理，这意味着由 kOps 在集群启动过程中安装的附加组件可以与其他附加组件一起管理。（但请注意，启动附加组件在 kOps 升级期间更有可能被替换）。

kOps 的总体理念是尽量减少启动附加组件的集合，并简化后续附加组件的安装。

因此，kube-dns 和网络覆盖（如果有）是典型的启动附加组件。但是，诸如仪表盘或 EFK 堆栈之类的附加组件可以在 kOps 启动后轻松安装，使用 kubectl apply -f https://... 或 channels 工具。

将来，我们可能会出于方便起见，简化将可选附加组件添加到 kOps 清单的过程，但这仅仅是手动执行此操作的便捷包装器。

更新启动附加组件 ¶

如果要更新启动附加组件，可以运行以下命令来显示哪些附加组件需要更新。添加 --yes 才能实际应用更新。

channels apply channel s3://KOPS_S3_BUCKET/CLUSTER_NAME/addons/bootstrap-channel.yaml

版本控制 ¶

channels 工具添加了一个清单-清单文件，其Kind: Addons，它允许描述各种可用的清单版本。这样，kOps 就可以在发布附加组件的新版本时管理更新。例如，dashboard 附加组件列出了多个版本。

例如，典型的附加组件声明可能如下所示

  - version: 1.4.0
    selector:
      k8s-addon: kubernetes-dashboard.addons.k8s.io
    manifest: v1.4.0.yaml
 - version: 1.5.0
    selector:
      k8s-addon: kubernetes-dashboard.addons.k8s.io
    manifest: v1.5.0.yaml

这声明了附加组件的两个版本，其清单位于 v1.4.0.yaml 和 v1.5.0.yaml。这些被评估为相对于附加组件文件本身的相对路径。（channels 工具支持比 kubectl 更多的协议，例如，s3://... 用于 S3 托管的清单）。

version 字段为备用清单赋予意义。它被解释为 semver。channels 工具会跟踪当前安装的版本（目前通过对 kube-system 命名空间的注释实现）。

当以下任何条件适用时，channels 工具会更新已安装的版本。

附加组件清单中声明的版本大于当前已安装的版本。
版本号匹配，但 id 不同
版本号和 id 匹配，但附加组件清单的哈希值自安装以来已更改。

这意味着用户可以编辑已部署的附加组件，但更改不会被替换，除非安装了附加组件的新版本。这里长期的方向是附加组件将主要通过 ConfigMap 或 Secret 对象进行配置，附加组件管理器将（待办事项）不会替换 ConfigMap。

selector 确定构成附加组件的对象。这将用于构建 --prune 参数（待办事项），以便在升级过程中删除先前版本中存在但新版本中不存在的对象。

Kubernetes 版本选择 ¶

附加组件管理器现在支持 kubernetesVersion 字段，该字段是对 Kubernetes 版本的 semver 范围说明符。如果 Kubernetes 的目标版本与指定的 semver 不匹配，则附加组件版本将被忽略。

这允许你为 Kubernetes API 的重大更改提供不同的清单版本。例如，1.6 将污点和容忍度更改为一个字段，RBAC 迁移到 beta 版。因此，拥有两个单独的清单更容易。

例如

  - version: 1.5.0
    selector:
      k8s-addon: kube-dashboard.addons.k8s.io
    manifest: v1.5.0.yaml
    kubernetesVersion: "<1.6.0"
    id: "pre-k8s-16"
 - version: 1.6.0
    selector:
      k8s-addon: kube-dashboard.addons.k8s.io
    manifest: v1.6.0.yaml
    kubernetesVersion: ">=1.6.0"
    id: "k8s-16"

在 1.6 之前的 Kubernetes 版本上，我们将安装 v1.5.0.yaml，而在 1.6 及更高版本的 Kubernetes 版本上，我们将安装 v1.6.0.yaml。

请注意，我们删除了 Kubernetes semver 的 pre-release 字段，以便 1.6.0-beta.1 将匹配 >=1.6.0。这与 Kubernetes 处理预发布版本的方式一致。

Semver 不够：`id` ¶

但是，semver 在此情况下不足以进行 Kubernetes 版本选择。问题出现在以下情况下

安装 k8s 1.5，安装 1.5 版本的清单
升级到 k8s 1.6，安装 1.6 版本的清单
降级到 k8s 1.5；我们希望安装 1.5 版本的清单，但 1.6 版本的 semver 将大于或等于 1.5 版本的 semver。

我们需要一种方法来打破 semver 之间的联系，因此我们引入了 id 字段。

因此，清单实际上将如下所示

  - version: 1.6.0
    selector:
      k8s-addon: kube-dns.addons.k8s.io
    manifest: pre-k8s-16.yaml
    kubernetesVersion: "<1.6.0"
    id: "pre-k8s-16"
 - version: 1.6.0
    selector:
      k8s-addon: kube-dns.addons.k8s.io
    manifest: k8s-16.yaml
    kubernetesVersion: ">=1.6.0"
    id: "k8s-16"

请注意，这两个附加组件具有相同的版本，但 kubernetesVersion 选择器不同。但它们的 id 值不同；具有匹配 semver 但 id 不同的附加组件将被升级。（但是，我们永远不会降级到更旧的 semver，无论 id 如何）。

因此，在上述情况下，降级到 1.5 后，尽管 semver 相同，但 id 将不匹配，并且将安装 pre-k8s-16。（当我们升级回 1.6 时，将安装 k8s-16 版本）。

一些提示

version 现在可以更 closely 地反映上游版本。
清单名称可能应该包含 id，以提高可维护性。

附加组件管理 ¶

更新启动附加组件 ¶

版本控制 ¶

Kubernetes 版本选择 ¶

Semver 不够：id ¶

Semver 不够：`id` ¶