Kubefeeds Team A dedicated and highly skilled team at Kubefeeds, driven by a passion for Kubernetes and Cloud-Native technologies, delivering innovative solutions with expertise and enthusiasm.

Orchestrating Kubernetes Deployments Through Dependencies

3 min read

In complex Kubernetes environments, deploying applications often involves intricate dependencies. Ensuring that components are installed in the correct order, and that required services are healthy before proceeding, is crucial for stability and reliability. Manually managing these dependencies becomes increasingly challenging as the number of applications and their interrelationships grow. This necessitates robust mechanisms for automating deployment sequences, verifying application health, and optimizing resource utilization to prevent redundant installations. Effective dependency management is vital for simplifying deployments, reducing operational overhead, and ensuring the smooth functioning of distributed applications within Kubernetes.

Sveltos Solution

Sveltos is a set of Kubernetes controllers operating within a management cluster. From this central point, Sveltos manages add-ons and applications across a fleet of managed Kubernetes clusters. It employs a declarative approach, ensuring that the desired state is consistently reflected across these managed environments.

A Sveltos ClusterProfile/Profile is a bundle of Helm charts and Kubernetes resources that Sveltos will deploy to every cluster that matches its selection criteria.

To simplify complex deployments, Sveltos allows you to create multiple profiles and specify a deployment order using the dependsOn field, ensuring all profile prerequisites are met.

Consider deploying admission policies. Here are the relevant ClusterProfile snippets:

apiVersion: config.projectsveltos.io/v1beta1
kind: ClusterProfile
metadata:
  name: kyverno
spec:
  syncMode: Continuous
  helmCharts:
  - repositoryURL:    https://kyverno.github.io/kyverno/
    repositoryName:   kyverno
    chartName:        kyverno/kyverno
    chartVersion:     3.3.4
    releaseName:      kyverno-latest
    releaseNamespace: kyverno
    ...
apiVersion: config.projectsveltos.io/v1beta1
kind: ClusterProfile
metadata:
  name: admission-policies
spec:
  dependsOn:
  - kyverno
  clusterSelector:
    matchLabels:      
      env: production
  ...

Notice that the kyverno ClusterProfile lacks a clusterSelector, so it won’t be deployed on its own. The admission-policies ClusterProfile, however, has a clusterSelector targeting production clusters and a dependsOn field referencing kyverno. When this profile is created, Sveltos resolves its dependency. Any time a production cluster matches the admission-policies selector, Sveltos will first deploy the Kyverno Helm chart and then apply the admission policies.

Kubernetes Application Dependencies

Beyond Order: Verifying Application Health

While deployment order is a fundamental aspect of application dependencies, it’s not always the sole requirement. In the Kyverno example, we prioritize deploying the CRDs before the custom resources, focusing on sequence. But consider a scenario where an application relies on a database. The database must not only be deployed first but also be fully initialized and ready to accept connections. In such cases, the state of the dependency becomes critical. Dependency management tools must accommodate these more complex state-based requirements.

Building on our Kyverno example, let’s address the need for state-based dependencies. We want to ensure that all Kyverno deployments are fully operational before deploying admission policies. To achieve this, we add a validateHealths section to the kyverno ClusterProfile.

apiVersion: config.projectsveltos.io/v1beta1
kind: ClusterProfile
metadata:
  name: kyverno
spec:
  syncMode: Continuous
  helmCharts:
  - repositoryURL:    https://kyverno.github.io/kyverno/
    repositoryName:   kyverno
    chartName:        kyverno/kyverno
    chartVersion:     3.3.4
    releaseName:      kyverno-latest
    releaseNamespace: kyverno
    helmChartAction:  Install
    values: |
      admissionController:
        replicas: 3
      backgroundController:
        replicas: 3
validateHealths:
- name: deployment-health
  featureID: Helm
  group: "apps"
  version: "v1"
  kind: "Deployment"
  namespace: kyverno
  script: |
    function evaluate()
      hs = {}
      hs.healthy = false
      hs.message = "available replicas not matching requested replicas"
      if obj.status ~= nil then
        if obj.status.availableReplicas ~= nil then
          if obj.status.availableReplicas == obj.spec.replicas then
            hs.healthy = true
          end
        end
      end
      return hs
    end      

Recursive Resolution

One of the key strengths of Sveltos is its ability to handle complex dependency chains. Imagine an application whoami that relies on Traefik, which itself depends on cert-manager. With Sveltos, you only need to define the deployment of whoami. Sveltos will automatically resolve the entire dependency tree, ensuring cert-manager and Traefik are deployed in the correct order before whoami is deployed. This simplifies complex deployments by automating the resolution of multi-level dependencies.

Dependency Chain

This capability is especially valuable in environments where different administrators manage distinct components. For instance, the whoami application might be managed by the application administrator, Traefik by the networking administrator, and cert-manager by the security administrator. Sveltos eliminates the need for manual coordination, allowing each administrator to focus on their respective components while ensuring the overall deployment succeeds.

Different Administrators

Sveltos Dashboard displays those dependencies:

Sveltos Dashboard

Dependency Deduplication

Sveltos efficiently manages shared dependencies by ensuring they are deployed only once per cluster, even when multiple profiles rely on them. This optimizes resource utilization and prevents redundant deployments. Crucially, Sveltos maintains a dependency as long as any profile requiring it is active on the cluster.

Consider a 3-tier application scenario:

  • Database Layer (Profile postgresql): Deploys a PostgreSQL database.

  • Backend Layer (Profiles backend-service-1, backend-service-2): Two distinct microservices, each requiring the PostgreSQL database.

  • Frontend Layer (Profiles frontend-app-1, frontend-app-2): Two frontend applications, each dependent on a respective backend service.

Here’s how this translates to Sveltos profiles and dependencies:

  • Profile postgresql: Deploys the PostgreSQL database.

  • Profile backend-service-1: Depends on Profile postgresql.

  • Profile frontend-app-1: Depends on Profile backend-service-1.

  • Profile backend-service-2: Depends on Profile postgresql.

  • Profile frontend-app-2: Depends on Profile backend-service-2.

Kubernetes Application Dependency Deduplication

When frontend-app-1 is deployed, Sveltos first deploys postgresql and then backend-service-1, resolving the dependency chain.

Subsequently, when frontend-app-2 is deployed to the same cluster, Sveltos recognizes that postgresql is already present and avoids redeploying it.

If frontend-app-1 is then removed, backend-service-1 is also removed. However, postgresql persists because it remains a dependency of frontend-app-2.

Finally, only when frontend-app-2 is removed will Sveltos remove backend-service-2 and postgresql, as they are no longer required by any active profile on the cluster.

 Contact Information

If you have some questions, would like to have a friendly chat or just network to not miss any topics, then don’t use the comment function at medium, just feel free to add me to your LinkedIn network!

👏 Support this project

If you enjoyed this article, please check out the Projectsveltos GitHub repo. You can also star 🌟 the project if you found it helpful.

The GitHub repo is a great resource for getting started with the project. It contains the code, documentation, and examples. You can also find the latest news and updates on the project on the GitHub repo.

Kubefeeds Team A dedicated and highly skilled team at Kubefeeds, driven by a passion for Kubernetes and Cloud-Native technologies, delivering innovative solutions with expertise and enthusiasm.