Example Flux Sources
Flux Sources
Sveltos can seamlessly integrate with Flux1 to automatically deploy YAML manifests or Helm charts stored in a Git repository or a Bucket. This powerful combination allows you to manage Kubernetes configurations in a central location and leverage Sveltos to target deployments across clusters.
Example: Deploy Nginx Ingress with Flux and Sveltos
Imagine a repository like this containing an nginx-ingress directory with all the required YAML resources for deployment2. In the steps below we demonstrate how to leverage Flux and Sveltos to automatically perform the deployment.
Step 1: Configure Flux in the Management Cluster
Install and run Flux in the management cluster and configure it to synchronise the Git repository containing the Nginx manifests. More information about the Flux installation can be found here.
Deploy a GitRepository resource similar to the below.
GitRepository Resource
Step 2: Create a Sveltos ClusterProfile
Define a Sveltos ClusterProfile referencing the flux-system GitRepository and specify the nginx-ingress directory as the source of the deployment.
Sveltos ClusterProfile Nginx Ingress
The ClusterProfile
targets clusters with the env=fv label and fetches relevant deployment information from the nginx-ingress directory within the flux-system Git repository managed by Flux.
$ sveltosctl show addons
+-----------------------------+----------------------------------------------+-----------+---------------------------------------+---------+-------------------------------+-------------------------------------+
| CLUSTER | RESOURCE TYPE | NAMESPACE | NAME | VERSION | TIME | PROFILES |
+-----------------------------+----------------------------------------------+-----------+---------------------------------------+---------+-------------------------------+-------------------------------------+
| default/clusterapi-workload | :ConfigMap | default | nginx-ingress-leader | N/A | 2024-03-23 11:43:10 +0100 CET | ClusterProfile/deploy-nginx-ingress |
| default/clusterapi-workload | rbac.authorization.k8s.io:ClusterRole | | nginx-stable-nginx-ingress | N/A | 2024-03-23 11:43:10 +0100 CET | ClusterProfile/deploy-nginx-ingress |
| default/clusterapi-workload | rbac.authorization.k8s.io:RoleBinding | default | nginx-stable-nginx-ingress | N/A | 2024-03-23 11:43:10 +0100 CET | ClusterProfile/deploy-nginx-ingress |
| default/clusterapi-workload | apps:Deployment | default | nginx-stable-nginx-ingress-controller | N/A | 2024-03-23 11:43:10 +0100 CET | ClusterProfile/deploy-nginx-ingress |
| default/clusterapi-workload | :ServiceAccount | default | nginx-stable-nginx-ingress | N/A | 2024-03-23 11:43:10 +0100 CET | ClusterProfile/deploy-nginx-ingress |
| default/clusterapi-workload | :ConfigMap | default | nginx-stable-nginx-ingress | N/A | 2024-03-23 11:43:10 +0100 CET | ClusterProfile/deploy-nginx-ingress |
| default/clusterapi-workload | rbac.authorization.k8s.io:ClusterRoleBinding | | nginx-stable-nginx-ingress | N/A | 2024-03-23 11:43:10 +0100 CET | ClusterProfile/deploy-nginx-ingress |
| default/clusterapi-workload | rbac.authorization.k8s.io:Role | default | nginx-stable-nginx-ingress | N/A | 2024-03-23 11:43:10 +0100 CET | ClusterProfile/deploy-nginx-ingress |
| default/clusterapi-workload | :Service | default | nginx-stable-nginx-ingress-controller | N/A | 2024-03-23 11:43:10 +0100 CET | ClusterProfile/deploy-nginx-ingress |
| default/clusterapi-workload | networking.k8s.io:IngressClass | | nginx | N/A | 2024-03-23 11:43:10 +0100 CET | ClusterProfile/deploy-nginx-ingress |
+-----------------------------+----------------------------------------------+-----------+---------------------------------------+---------+-------------------------------+-------------------------------------+
Example: Deploy Kyverno policies with Flux and Sveltos
Step 1: Configure Flux in the Management Cluster
Install and run Flux in the management cluster and configure it to synchronise the Git repository containing the Kyverno manifests.
Deploy a GitRepository resource similar to the below.
GitRepository Resource
Step 2: Create a Sveltos ClusterProfile
Define a ClusterProfile to deploy the Kyverno helm chart.
Sveltos ClusterProfile Kyverno
cat > clusterprofile_kyverno.yaml <<EOF
---
apiVersion: config.projectsveltos.io/v1beta1
kind: ClusterProfile
metadata:
name: deploy-kyverno
spec:
clusterSelector:
matchLabels:
env: fv
syncMode: Continuous
helmCharts:
- repositoryURL: https://kyverno.github.io/kyverno/
repositoryName: kyverno
chartName: kyverno/kyverno
chartVersion: v3.3.3
releaseName: kyverno-latest
releaseNamespace: kyverno
helmChartAction: Install
EOF
Define a Sveltos ClusterProfile
referencing the flux-system GitRepository and defining the kyverno directory as the source of the deployment.
The mentioned directory contains a list of Kyverno ClusterPolicies.
Sveltos ClusterProfile Kyverno Policies
cat > clusterprofile_kyverno_policies.yaml <<EOF
---
apiVersion: config.projectsveltos.io/v1beta1
kind: ClusterProfile
metadata:
name: deploy-kyverno-policies
spec:
clusterSelector:
matchLabels:
env: fv
policyRefs:
- kind: GitRepository
name: flux-system
namespace: flux-system
path: kyverno
dependsOn:
- deploy-kyverno
EOF
The above ClusterProfile
targets clusters with the env=fv label and fetches relevant deployment information from the kyverno directory within the flux-system Git repository managed by Flux.
The Kyverno Helm chart and all the Kyverno policies contained in the Git repository under the kyverno directory are deployed:
$ sveltosctl show addons
+-----------------------------+--------------------------+-----------+---------------------------+---------+-------------------------------+----------------------------------------+
| CLUSTER | RESOURCE TYPE | NAMESPACE | NAME | VERSION | TIME | PROFILES |
+-----------------------------+--------------------------+-----------+---------------------------+---------+-------------------------------+----------------------------------------+
| default/clusterapi-workload | helm chart | kyverno | kyverno-latest | 3.2.5 | 2024-03-23 11:39:30 +0100 CET | ClusterProfile/deploy-kyverno |
| default/clusterapi-workload | kyverno.io:ClusterPolicy | | restrict-image-registries | N/A | 2024-03-23 11:40:11 +0100 CET | ClusterProfile/deploy-kyverno-policies |
| default/clusterapi-workload | kyverno.io:ClusterPolicy | | disallow-latest-tag | N/A | 2024-03-23 11:40:11 +0100 CET | ClusterProfile/deploy-kyverno-policies |
| default/clusterapi-workload | kyverno.io:ClusterPolicy | | require-ro-rootfs | N/A | 2024-03-23 11:40:11 +0100 CET | ClusterProfile/deploy-kyverno-policies |
+-----------------------------+--------------------------+-----------+---------------------------+---------+-------------------------------+----------------------------------------+
Example: Referencing Helm Charts from Flux Sources
Sveltos allows us to deploy Helm charts from various sources, including traditional HTTP repositories, OCI registries, and Flux sources. This section focuses on using Flux sources as a Helm chart repository.
Using a Flux GitRepository as a Helm Chart Source
To deploy Helm charts from a Flux GitRepository, specify the repositoryURL
in your ClusterProfile
using the following format:
<flux source kind>
: The type of Flux source. For Git repositories, this isgitrepository
(available options:ocirepository
andbucket
)<flux source namespace>
: The Kubernetes namespace where the Flux GitRepository is located<flux source name>
: The name of the Flux GitRepository<path>
: The relative path within the Git repository to the directory containing the Helm charts
Note
Use the kubectl get gitrepository.source.toolkit.fluxcd.io -A
command to get a view of the existing syncronised repositories.
Example Scenario
Let's assume we have a Flux GitRepository named flux-system
in the flux-system
namespace. The GitRepository is configured to synchronise the https://github.com/projectsveltos/helm-charts.git/
repository. The Helm charts we want to deploy are located in the charts/projectsveltos
directory within the mentioned Git repository.
To deploy the projectsveltos
chart using Sveltos, we would create a ClusterProfile
with the below helmCharts
options.
helmCharts:
- repositoryURL: gitrepository://flux-system/flux-system/charts/projectsveltos
releaseName: projectsveltos
releaseNamespace: projectsveltos
helmChartAction: Install
Example: Template with Git Repository/Bucket Content
The content within the Git repository or other sources referenced by a Sveltos ClusterProfile
can be templates3.To enable templating, annotate the referenced GitRepository
instance with "projectsveltos.io/template: true".
When Sveltos processes the template, it will perform the below.
- Read the content of all files inside the specified path
- Instantiate the templates ultilising the data from resources in the management cluster, similar to how it currently works with referenced Secrets and ConfigMaps
This allows dynamic deployment customisation based on the specific characteristics of the clusters, further enhancing flexibility and automation.
Let's try it out! The content in the "template" directory of the repository serves as the perfect example.
Template Definition
ConfigMap Definition
cat > cm.yaml <<EOF
# Sveltos will instantiate this template before deploying to matching managed cluster
# Sveltos will get the ClusterAPI Cluster instance representing the cluster in the
# managed cluster, and use that resource data to instintiate this ConfigMap before
# deploying it
---
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Cluster.metadata.name }}
namespace: default
data:
controlPlaneEndpoint: "{{ .Cluster.spec.controlPlaneEndpoint.host }}:{{ .Cluster.spec.controlPlaneEndpoint.port }}"
EOF
GitRepository Definition
Note
Add the projectsveltos.io/template: "true" annotation to the GitRepository resources created further above.
GitRepository Resource
ClusterProfile Definition
Sveltos ClusterProfile Flux Definition
The ClusterProfile
will use the information from the "Cluster" resource in the management cluster to populate the template and deploy it.
An example of a deployed ConfigMap in the managed cluster can be found below.
Express Path as Template
The path field within a policyRefs object in Sveltos can be defined using a template. This allows to dynamically set the path based on information from the cluster itself.
Sveltos ClusterProfile Flux Region West
cat > clusterprofile_flux_region_west.yaml <<EOF
---
apiVersion: config.projectsveltos.io/v1beta1
kind: ClusterProfile
metadata:
name: flux-system
spec:
clusterSelector:
matchLabels:
region: west
syncMode: Continuous
policyRefs:
- kind: GitRepository
name: flux-system
namespace: flux-system
path: '{{ index .Cluster.metadata.annotations "environment" }}/helloWorld'
EOF
Sveltos uses the cluster instance in the management cluster to populate the template in the path field. The template expression {{ index .Cluster.metadata.annotations "environment" }}
retrieves the value of the annotation named environment from the cluster's metadata.
For example:
- Cluster A: If cluster A has an annotation environment: production, the resulting path will be: production/helloWorld.
- Cluster B: If cluster B has an annotation environment: pre-production, the resulting path will be: pre-production/helloWorld.
The mentioned approach allows for flexible configuration based on individual cluster environments. Remember to adapt the provided resources to your specific repository structure, cluster configuration, and desired templating logic.
A more complex example can be when we want to express the path field as a template using if statements.
Sveltos ClusterProfile Flux Template path
cat > clusterprofile_flux_template_path.yaml <<EOF
---
apiVersion: config.projectsveltos.io/v1beta1
kind: ClusterProfile
metadata:
name: flux-system
spec:
clusterSelector:
matchLabels:
region: west
templateResourceRefs:
- resource:
apiVersion: lib.projectsveltos.io/v1beta1
kind: SveltosCluster
name: "{{ .Cluster.metadata.name }}"
identifier: Cluster
syncMode: Continuous
policyRefs:
- kind: GitRepository
name: flux-system
namespace: flux-system
path: |-
{{$path := index .Cluster.metadata.labels "projectsveltos.io/k8s-version" }}{{- if eq $path "v1.29.8"}}system/prod
{{- else}}system/test
{{- end}}
EOF
Effectively, by defining the templateResourceRefs
at the beginning of the ClusterProfile we can retrieve the Sveltos managed clusters Kubernetes version. The information is used at the policyRefs
definition when we set the path as a template with if statements.
-
This ClusterProfile allows you to install Flux in your management cluster. However, before applying it, ensure your management cluster has labels that match the specified clusterSelector.
↩apiVersion: config.projectsveltos.io/v1beta1 kind: ClusterProfile metadata: name: flux spec: clusterSelector: matchLabels: cluster: mgmt helmCharts: - chartName: flux2/flux2 chartVersion: 2.12.4 helmChartAction: Install releaseName: flux2 releaseNamespace: flux2 repositoryName: flux2 repositoryURL: https://fluxcd-community.github.io/helm-charts
-
The YAML was obtained by running
helm template nginx-stable nginx-stable/nginx-ingress
. ↩ -
Do you want to dive deeper into Sveltos's templating features? Check out this section. ↩