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.
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.
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.
Sveltos Dashboard displays those dependencies:
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.
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.