This the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Automatic propagation of associated resources

    What are associated resources

    The workloads (such as Deployments, StatefulSets, etc.) in Kubernetes usually rely on many other resources, such as ConfigMaps, Secrets, PVCs, etc.

    Therefore, it is necessary to ensure that when the workload is propagated to the target member cluster, the associated resources are synchronously distributed to the same member cluster.

    The ways of associating workloads and other resources mainly include the following two types:

    • Built-in follower resources: Refer to resources that are associated with each other in the Yaml configuration file. For example, workloads (Deployment, StatefulSet, etc.) and ConfigMap, Secret, PVC, etc. When resources are distributed, if the workload and associated resources are not distributed to the same cluster, it will cause the workload to fail to deploy due to resource missing.

    • Specified follower resources: Mainly refer to Service and Ingress. The absence of specified follower resources will not cause failure in workload deployment, but will affect usage. For example, when service and ingress are not distributed to the same member cluster as the workload, the workload will not be able to provide services externally.

    Automatic propagation of associated resources

    KubeAdmiral supports the automatic propagation of associated resources: when a workload is associated with related resources, KubeAdmiral will ensure that the workload and associated resources are scheduled to the same member cluster.

    We name the automatic propagation of associated resources as follower scheduling.

    Supported resource types for follower scheduling

    Built-in follower resources: Directly configure the associated resources when using YAML to configure workloads.

    Association TypeWorkloadsAssociated Resources
    Built-in follower resourcesDeploymentConfigMap
    StatefulSetSecret
    DaemonSetPersistentVolumeClaim
    JobServiceAccount
    CronJob
    Pod

    Specified follower resources: Using Annotations to declare the resources that need to be associated when creating workloads.

    Association TypeWorkloadsAssociated Resources
    Specified follower resourcesDeploymentConfigMap
    StatefulSetSecret
    DaemonSetPersistentVolumeClaim
    JobServiceAccount
    CronJobService
    PodIngress

    How to configure follower scheduling

    Built-in follower resources

    KubeAdmiral will propagate the build-in follower resources automatically which does not require users to add additional configurations.

    For examples:

    1. The Deployment A mounts the ConfigMap N, and the Deployment A is specified to be propagated to Cluster1 and Cluster2.

    2. The ConfigMap N does not specify a propagation policy, but will follow Deployment A to be propagated to Cluster1 and Cluster2.

    Specified follower resources

    When creating a workload, users can declare one or more associated resources using Annotations, which will be propagated to the target member clusters automatically along with the workload.

    The format for specifying associated resources using Annotations is as follows:

    • Annotation Key: kubeadmiral.io/followers:
    • Each associated resource contains 3 fields: group, kind, and name. They are wrapped in {}.
    • When there are multiple associated resources, they are separated by ,, and all resources are wrapped in [].

    Different associated resources have different field configurations in the Annotation, as follows:

    kindgroupnameAnonotation
    ConfigMap""configmap-namekubeadmiral.io/followers: ‘[{“group”: “”, “kind”: “ConfigMap”, “name”: “configmap-name”}]’
    Secret""secret-namekubeadmiral.io/followers: ‘[{“group”: “”, “kind”: “Secret”, “name”: “secret-name”}]’
    Service""service-namekubeadmiral.io/followers: ‘[{“group”: “”, “kind”: “Service”, “name”: “service-name”}]’
    PersistentVolumeClaim""pvc-namekubeadmiral.io/followers: ‘[{“group”: “”, “kind”: “PersistentVolumeClaim, “name”: “pvc-name”}]’
    ServiceAcount"”serviceacount-namekubeadmiral.io/followers: ‘[{“group”: “”, “kind”: “ServiceAcount, “name”: “serviceacount-name”}]’
    Ingressnetworking.k8s.ioingress-namekubeadmiral.io/followers: ‘[{“group”: “networking.k8s.io”, “kind”: “Ingress, “name”: “ingress-name”}]’

    In this example, the Deployment is associated with two resources, namely Secret and Ingress.

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      annotations:
        kubeadmiral.io/followers: '[{"group": "", "kind": "Secret", "name": "serect-demo"}, {"group": "networking.k8s.io",  "kind": "Ingress", "name": "ingress-demo"}]'
      name: deployment-demo
    spec:
      replicas: 2 
      selector:
        matchLabels:
          app: demo
      template:
        metadata:
          labels:
            app: demo
        spec:
          containers:
          - image: demo-repo:v1
            name: demo
            ports: 
            - containerPort: 80
    

    Disable follower scheduling for workloads

    Follower scheduling is enabled by default in KubeAdmiral. If users want to disable follower scheduling, they need to modify the PropagationPolicy by setting the disableFollowerScheduling field to true. Here is an example:

    apiVersion: core.kubeadmiral.io/v1alpha1
    kind: PropagationPolicy
    metadata:
      name: follow-demo
      namespace: default
    spec:
      disableFollowerScheduling: true
    

    Disable follower scheduling for associated resources

    To prevent some associated resources from follower scheduling, users add the following declaration on the Annotation of the associated resources: kubeadmiral.io/disable-following: "true"

    For example:

    1. The Deployment A is mounted with ConfigMap N and Secret N, and the workload is specified to be propagated to Cluster1 and Cluster2.
    2. If the user does not want Secret N to follow the scheduling, by adding the Annotation kubeadmiral.io/disable-following: "true" to Secret N, Secret N will not automatically be propagated to Cluster1 and Cluster2.
    3. ConfigMap N will still follow Deployment A to be distributed to Cluster1 and Cluster2.

    The YAML is as follows:

    apiVersion: v1
    kind: Secret
    metadata:
      annotations:
        kubeadmiral.io/disable-following: "true"
      name: follow-demo
      namespace: default
    data: {}