Skip to content

Deploy YAML/JSON Kubernetes manifests

ClusterProfile policyRefs Reference

The ClusterProfile spec.policyRefs is a list of Secrets/ConfigMaps. Both Secrets and ConfigMaps data fields can be a list of key-value pairs. Any key is acceptable, and the value can be multiple objects in YAML or JSON format1.

Example: Create a Secret

To create a Kubernetes Secret that contains the Calico YAMLs and make it usable with Sveltos, utilise the below commands.

$ wget https://raw.githubusercontent.com/projectcalico/calico/master/manifests/calico.yaml

$ kubectl create secret generic calico --from-file=calico.yaml --type=addons.projectsveltos.io/cluster-profile

The commands will download the calico.yaml manifest file and afterwards create a Kubernetes secret of type generic by defining the file downloaded in the previous command plus defining the needed type=addons.projectsveltos.io/cluster-profile.

Please note: A ClusterProfile can only reference Secrets of type addons.projectsveltos.io/cluster-profile

Example: Create a ConfigMap

The YAML definition below exemplifies a ConfigMap that holds multiple resources. When a ClusterProfile instance references the ConfigMap, a GatewayClass and a Gateway instance are automatically deployed in any managed cluster that adheres to the ClusterProfile clusterSelector.

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: contour-gateway
  namespace: default
data:
  gatewayclass.yaml: |
    kind: GatewayClass
    apiVersion: gateway.networking.k8s.io/v1beta1
    metadata:
      name: contour
    spec:
      controllerName: projectcontour.io/projectcontour/contour
  gateway.yaml: |
    kind: Namespace
    apiVersion: v1
    metadata:
      name: projectcontour
    ---
    kind: Gateway
    apiVersion: gateway.networking.k8s.io/v1beta1
    metadata:
     name: contour
     namespace: projectcontour
    spec:
      gatewayClassName: contour
      listeners:
        - name: http
          protocol: HTTP
          port: 80
          allowedRoutes:
            namespaces:
              from: All

Another way to create a Kubernetes ConfigMap resource is with the imperative approach. The below command will create the same ConfigMap resource in the management cluster.

$ kubectl create configmap contour-gateway --from-file=gatewayclass.yaml --from-file=gateway.yaml

Once the required Kubernetes resources are created/deployed, the below example represents a ClusterProfile resource that references the ConfigMap and the Secret created above.

apiVersion: config.projectsveltos.io/v1alpha1
kind: ClusterProfile
metadata:
  name: deploy-resources
spec:
  clusterSelector: env=fv
  policyRefs:
  - name: contour-gateway
    namespace: default
    kind: ConfigMap
  - name: calico
    namespace: default
    kind: Secret

Note: The namespace definition refers to the namespace where the ConfigMap, and the Secret were created in the management cluster. In our example, both resources created in the default namespace.

When a ClusterProfile references a ConfigMap or a Secret, the kind and name fields are required, while the namespace field is optional. Specifying a namespace uniquely identifies the resource using the tuple namespace, name, and kind, and that resource will be used for all matching clusters.

If you leave the namespace field empty, Sveltos will search for the ConfigMap or the Secret with the provided name within the namespace of each matching cluster.

Example: Understand Namespace Definition

apiVersion: config.projectsveltos.io/v1alpha1
kind: ClusterProfile
metadata:
  name: deploy-resources
spec:
  clusterSelector: env=fv
  policyRefs:
  - name: contour-gateway
    kind: ConfigMap

Consider the provided ClusterProfile, when we have two workload clusters matching. One in the foo namespace and another in the bar namespace. Sveltos will search for the ConfigMap contour-gateway in the foo namespace for the Cluster in the foo namespace and for a ConfigMap contour-gateway in the bar namespace for the Cluster in the bar namespace.

More ClusterProfile examples can be found here.

Remember to adapt the provided resources to your specific repository structure, cluster configuration, and desired templating logic.


  1. A ConfigMap is not designed to hold large chunks of data. The data stored in a ConfigMap cannot exceed 1 MiB. If you need to store settings that are larger than this limit, you may want to consider mounting a volume or use a separate database or file service.