Skip to content

Deploying Applications

Your cluster is a conformant Kubernetes cluster and you are cluster-admin in it.

kubectl apply, Helm, Kustomize, an operator, your own CRDs, your own RBAC — all of it works the way it does anywhere, and this page does not repeat the upstream documentation for any of it.

What follows is only what is different here.

Getting your kubeconfig

The credential for your cluster is a Secret in your Environment, written by the platform when the cluster's control plane came up:

kubectl get secret my-cluster-admin-kubeconfig -n dynamo-prod \
  -o jsonpath='{.data.admin\.conf}' | base64 -d > my-cluster.kubeconfig

export KUBECONFIG=my-cluster.kubeconfig
kubectl get nodes

That is a cluster-admin credential for the whole cluster, so treat it as one. It is also cluster-specific — the certificate authority behind it exists for this cluster alone, so it is meaningless against any other, including your own next one.

Two contexts, and it matters which one you are in

Almost every mistake on this page and the next two is running a command against the wrong cluster.

You use Where it lives
Cluster, EipClaim, ClusterBackup, ResourceQuota Your Environment credentials The under cluster
Deployment, PersistentVolumeClaim, Service, VolumeSnapshot Your cluster's kubeconfig Your cluster

Commands on this site say which one they mean when it is not obvious.

What is already in your cluster

Some things are delivered by the platform and put back if you change them. They are drift-corrected on purpose: a cluster whose CNI a tenant deleted is a support call, not a lesson.

Where
The CNI kube-system or its own namespace Chosen by your platform team, not by you.
kubevirt-csi-node, the kubevirt StorageClass, kubevirt-csi-snapclass kube-system See Persistent Storage.
The snapshot controller and its CRDs kube-system
A ValidatingWebhookConfiguration for storage quota cluster-scoped Deleting or narrowing it is reverted. It is not a way around the quota.

Everything else in the cluster is yours.

kubectl get pods -n kube-system

How this differs from a managed cloud cluster

If your instinct comes from EKS, GKE or AKS, these are the differences that will actually cost you time:

There is no cloud provider. No cloud load balancer, no cloud disk types, no IAM-to-ServiceAccount integration, no cloud DNS controller. The two things a cloud provider usually gives you are replaced by specific mechanisms — an EipClaim for a LoadBalancer, and one StorageClass.

There is no ingress controller. Install the one you want; the platform deliberately does not pick for you. See Ingress.

There are no control plane nodes. Your control plane runs as pods on the platform, not on machines you own. kubectl get nodes shows workers only — that is correct, not a missing node. It also means there is no control-plane host to SSH into, patch, or size.

Your worker nodes are cattle, and genuinely are. They are virtual machines built from a golden image. A replacement is minutes away and identical, so anything you configure by hand on a node is lost the next time one is replaced. Configure nodes through a DaemonSet, not through SSH.

Your quota is enforced from outside. Storage, addresses, and how many clusters you may run are capped on the platform side and refuse you at request time. That is the design — see Persistent Storage.

Delivering add-ons across your clusters

If you run more than one cluster, installing the same add-on into each by hand does not scale, and neither does a CI job holding every kubeconfig.

The platform's own delivery mechanism is available to you for your own clusters. A Profile is an object in your Environment that matches clusters in that Environment only, and keeps applying what it names into them:

apiVersion: config.projectsveltos.io/v1beta1
kind: Profile
metadata:
  name: monitoring-agent
  namespace: dynamo-prod
spec:
  clusterSelector:
    matchLabels:
      env: prod
  syncMode: ContinuousWithDriftDetection
  policyRefs:
    - kind: ConfigMap
      name: monitoring-agent-manifests

What this buys over a CI job:

  • New clusters are covered on creation. A cluster you create tomorrow that matches the selector gets the add-on without anything being run.
  • Drift is corrected. ContinuousWithDriftDetection puts back what somebody removed inside the cluster.
  • No credentials to hold. You never handle the target clusters' kubeconfigs.
kubectl get profiles -n dynamo-prod
kubectl get clustersummaries -n dynamo-prod    # one per profile × cluster; what actually landed

Three constraints worth knowing before you build on it:

  • policyRefs may only name ConfigMaps and Secrets in the same Environment. The API fills the namespace in for you, so a Profile cannot reach content — or clusters — outside the Environment it lives in.
  • The platform's own profiles can conflict with yours. Conflicts resolve to the lowest tier, and mandatory platform add-ons are set low deliberately. Do not try to replace the CNI this way.
  • Profile may not be granted to you. It is a per-customer decision. If kubectl get profiles is refused, ask your platform team.

If you only run one cluster, this is not worth the indirection — helm install is fine.

Where to go next