声明资源对象之间的依赖项

本指南介绍了 Config Sync 中依赖项的工作原理,以及如何指定您自己的依赖项。

在将特定对象同步到集群时,Config Sync 会自动检测这些对象之间的隐式依赖项。例如,系统始终会先应用命名空间对象,然后再应用这些命名空间中的任何对象;同样,系统也始终会先应用 CustomResourceDefinition (CRD) 对象,然后再应用此类型的任何自定义资源。同理,这些隐式依赖项的删除顺序则相反:系统会先删除命名空间中的对象,然后再删除命名空间;同样,系统也会先删除 CRD 类型的自定义资源,然后再删除 CRD。

您还可以使用 depends-on 注解来设置显式依赖项。例如,您可能希望 MySQL StatefulSet 在 Wordpress 部署之前启动,以便数据库在 Wordpress 启动之前应用并准备就绪。

要求

  • 您需要启用 RootSync API 和 RepoSync API。如果您使用 kubectl 手动安装了 Config Sync,并且未启用 RootSync API 和 RepoSync API,则您将需要迁移 ConfigManagement 对象

  • 限制:依赖项必须与其所依赖的对象位于同一可靠来源。依赖项必须由与其所依赖对象相同的 RootSync 或 RepoSync 对象管理,这样可确保所有资源都在同一个 ResourceGroup 中。

应用组

将资源同步到集群时,Config Sync 会将具有直接或间接依赖项的资源划分为不同的应用组。一个应用组仅包含彼此间没有直接或间接依赖关系的资源。系统会首先应用其中的资源没有任何依赖项的应用组。

执行和协调

执行对象(应用或删减)后,该对象可能需要一段时间才能由其控制器进行协调。例如,应用部署后,底层 Pod 可能无法立即准备就绪。底层 Pod 准备就绪后,便可以对该部署进行协调。对于不同类型的对象,Config Sync 会检查不同类型的条件,以验证对象是否经过协调。如需了解详情,请参阅 sigs.k8s.io/cli-utils

使用 depends-on 注释时,Config Sync 不仅会按照您希望的顺序应用对象,并且还会先验证依赖项对象是否已经过协调,然后再应用其所依赖的对象。

如果依赖项对象在 5 分钟的默认协调超时内未进行协调,则 Config Sync 在下一个同步周期之前不会应用该依赖项对象。您可以通过设置 spec.override.reconcileTimeout 替换默认协调超时。

向对象添加 depends-on 注释

如需指定依赖项,请使用一个引用依赖项对象的值将 config.kubernetes.io/depends-on 注释添加到其所依赖的对象上。

对于 Wordpress 示例,Wordpress 部署中的注释类似于以下内容:

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress
  namespace: default
  labels:
    app: wordpress
  annotations:
    config.kubernetes.io/depends-on: apps/namespaces/default/StatefulSet/wordpress-mysql

Config Sync 应用对象时,会首先应用依赖项,即对象 wordpress-mysql StatefulSet。协调依赖项后,Config Sync 会应用其所依赖的对象,即 wordpress 部署。

对象引用

对象引用使用以下语法:

  • 对于命名空间型对象:

    GROUP/namespaces/NAMESPACE/KIND/NAME
    
  • 对于集群级对象:

    GROUP/KIND/NAME
    

    替换以下内容:

    • GROUP:依赖项对象的群组。
    • NAMESPACE:命名空间级依赖项对象的命名空间。
    • KIND:依赖项对象的种类。此字段区分大小写。例如,请使用“Pod”而不是“pod”。
    • NAME:依赖项对象的名称。

对于核心群组中的对象,请改用空字符串,例如 /namespaces/test/Pod/pod-a

使用 , 分隔多个对象引用,例如 /namespaces/test/Pod/pod-a,/namespaces/test/Pod/pod-b