.svg){kind=logo}
What’s in your Kubernetes stack?
If you’re like most organizations, the latest research shows you have more than 20 Kubernetes clusters, each with more than ten different software applications running inside — things like observability tools, security, logging or service mesh.
And both the number of clusters and software elements keeps growing year on year.
As a Kubernetes administrator, how do you manage the deployment of all these software tools to your clusters, across all your different environments?
Helm charts, manifests, YAML, oh my!
The truth is that the deployment and configuration process for these applications at scale may become very complicated.
Using common Kubernetes deployment tools — like Helm or Kustomize — simply falls short. Why?
- They’re not designed to deploy applications at scale. You need to find another tool to deploy Kubernetes Helm charts and Kustomized manifests to the fleet of Kubernetes clusters, or create automation scripts to deploy and reconcile each application’s state on multiple Kubernetes clusters.
- The user experience is daunting. Helm and Kustomize are great tools, but they’re purely CLI based and require you to dig into the YAML files to specify your desired application parameters. Sometimes even K8s power users benefit from an intuitive UI to select applications and clusters and define application parameters.
- They lack enterprise guardrails. You can’t set constraints, for example, minimum requirements for Kubernetes distribution and version to use the application.
- They can’t handle complex applications. If an application contains multiple Helm charts or requires applying a few Kubernetes manifests to configure it properly, the deployment and configuration process forces users to execute additional steps/scripts to apply those manifests.
We need a new concept: introducing packs
To tackle all these challenges, we created the concept of ‘Packs’, a simpler and more powerful way to manage how applications are configured and deployed across Kubernetes clusters.
What actually is a Palette Pack?
A pack is a content package that wraps around Helm charts and manifests, bundling together all the artifacts needed to deploy and configure an application, giving them a friendly name and version number, and describing through metadata how that application should be integrated into the Kubernetes infrastructure landscape.
A wrapper, huh? If that sounds pretty mundane, keep reading — packs solve almost every issue you’ll face managing YAML or wrangling Helm today.
What do packs cover?
Palette provides infrastructure packs to build the core layers of the Kubernetes stack (operating systems, Kubernetes distributions, CNIs, and CSIs) as well as add-on packs to deploy system applications on top of Kubernetes clusters, such as monitoring and logging stacks, ingress controllers, etc.
If you’ve heard of our concept of Cluster Profiles, the different layers of each profile are made up of packs (although you can build profiles directly from charts, manifests and Zarf packages too).
How can you find and use packs?
Packs are distributed via standard OCI or Spectro Cloud registries, and there are default registries, containing many packs, configured and available for users directly in the Palette user interface, whenever they’re building or managing a cluster.
There are two classes of pack: verified and community.
Spectro Cloud Verified Packs are available from the Spectro Cloud Registry. They cover many of the most popular Kubernetes software integrations, and they are fully supported, which means the Spectro Cloud team takes care of version updates, quality control, security and conformance scanning, validating interoperability, and providing first-line technical support.
Some packs are even FIPS compliant for use in regulated industries with our Palette VerteX edition.
There’s also a Spectro Cloud Community Packs repository, which contains packs created and supported by other people and organizations, available for Palette users to install and configure. For example, the nice folks at ngrok have contributed a pack for their unified ingress platform.
All these packs are available for users once they are onboarded to Palette, and they can immediately deploy and configure these applications to Kubernetes clusters using a declarative approach or the Palette UI.
You can build your own custom packs to extend the benefits
You can also create your own custom packs to deploy and configure your own applications across the fleet of Kubernetes clusters managed by Palette.
To publish a custom pack, you can use your own private in-house OCI-compatible registries, or submit to the Spectro Cloud community registry if you want to — after we review your submission, it’ll be available for all Palette users.
Building a custom pack to distribute applications is a time investment, but it’s well worth it. Every time you configure and deploy that application in the future, using the pack means you don’t have to worry about dependencies; default values are already set; configuration best practices are baked in.
This will save you time, improve consistency, and avoid manual configuration and values entry, which means less risk of human error. And as we all know, human error is a big contributing factor in outages and security breaches — so think of all the troubleshooting and remediation you could avoid.
Six reasons why packs are so important
So, a pack is just a bundle of existing stuff plus some metadata, right? How valuable can that be? Give us a minute and we’ll show you how this simple concept and construct is actually mind-blowingly powerful and tackles so many of the challenges of managing Kubernetes software stacks.
Advantage 1: simplify rollouts with unified distribution
Spectro Cloud packs allow users to combine multiple Helm charts and Kubernetes manifests in one pack and distribute it as one application.
This is a very common use-case where users need to deploy an application containing a Helm chart along with additional Kubernetes manifests, to deploy resources required for the Helm chart to work (Kubernetes Custom Resources, ConfigMaps, etc..).
Simply add multiple Helm chart archives and manifests your application requires to the pack’s directory, specify them in the pack metadata file (pack.json), add the “values.yaml” file to allow users to configure the application (set values for all Helm charts and/or manifests), then push the pack to your OCI registry.
After that, instead of requiring users to deploy multiple Helm charts and manually create additional Kubernetes resources to configure the application, they now have only one place where they define all the values for the application, and deploy this one pack across a fleet of Kubernetes clusters.
Over time, software versions change, and deployments need to be updated. Palette packs provide an intuitive way of seeing available pack versions, understanding which ones are supported and current, and choosing which ones to apply to the cluster.
Palette holds the user’s hand every step of the way when browsing, building or deploying packs, including providing documentation directly in the user interface.
Advantage 2: limit user risk with presets and value limits
As a pack creator, you can limit the values your users can define and configure in the included Helm charts. For example, you might only want your users to be able to set the desired namespace and ingress hostname for their application. In this case, all you have to do is remove the other values from the pack’s “values.yaml” file, and your users will not see or be able to configure them during the application deployment — they’ll remain on the default values.
You can go a step further and define “Pack Presets”, sets of predefined values for the pack. Then, users will just have to pick the desired preset from the Palette UI, instead of typing them out. It’s faster, easier, and much safer.
Advantage 3: control deployments with environment limits
You probably have many Kubernetes clusters deployed across multiple on-premise and cloud environments, but some workloads should only be deployed in specific environments.
With Palette packs, you can limit the environments where the application can be deployed, using the pack metadata (pack.json). Just list the supported environments in the “cloudTypes” field, and users will not be able to deploy this pack on any other cloud.
We go a step further and allow you to define the minimum hardware requirements for your packs too, so if a user attempts to deploy resource-intensive applications to an instance that is too small, Palette will alert them. This avoids you running into performance issues or downtime.
Similarly, you can set limits on which version of Kubernetes the app requires, so users aren’t allowed to use older versions that may have vulnerabilities or cause issues. Just set the minimum Kubernetes version requirement in the pack.json file, and users will not be able to deploy the application. Instead, they will see a warning in the Palette UI, explaining that the Kubernetes cluster version is too old for this application to deploy.
Advantage 4: avoid errors with dependency awareness
Does your application require another application to be present on the Kubernetes cluster, so your application can work properly? It’s a very common requirement.
Palette packs are aware of dependencies, and you can set other packs as prerequisites before deployment is allowed. Just add to the list of dependencies in the pack.json file. Users will be notified that the application has dependencies, and they have to add the corresponding packs to their Cluster Profile before they can deploy your application.
By the way, you can set not only the pack name but also the minimum (and maximum) dependent pack version, if required.
Palette also has an ordering capability, much like ArgoCD waves, which allows you to define which packs to install first — minimizing error messages as your cluster comes up.
Advantage 5: effortlessly repeat values with pack parameters
Many applications contain a Helm chart defining Kubernetes Custom Resource Definitions (CRDs) plus a few Custom Resources (CRs) that users need to create, and require users to set values for these Custom Resources during application deployment.
This can be a painstaking and error-prone process, particularly at scale.
Palette packs include a feature called manifest parameterizing to solve it. It turns repeated values into repeatable parameters.
You can add your CustomResource Kubernetes manifests to the pack, templatize it to introduce parameters, and add those parameters to the pack’s “values.yaml” file.
Now users can define values when they deploy the application, per cluster or in the Cluster Profile, when deploying it across many Kubernetes clusters.
Advantage 6: squash human error with schema constraints
Worried that users can make a mistake or mistype when they're defining application values? It’s so easy to do.
Perhaps they’re typing an ingress hostname that’s not a valid FQDN, or maybe they forgot to define a mandatory variable. Either way, the deployment will fail or the application won’t work as expected.
Palette packs have an incredibly powerful feature called schema constraints — a set of rules that administrators define at the pack level to validate values before the pack is deployed to the target cluster, to ensure successful deployment. You can use regex to define requirements and limits for the values that users can type, or make some values mandatory for users to define.
Moreover, administrators can use sprig template functions to manipulate the values that users need to type (for example, making all letters capitalized) or to set default values for some variables.
These rules also include masking the values, so for example if a variable string format is set as a password, when the user types a value it’ll automatically be masked with asterisks and not be visible once the pack has been added to the profile (and it will remain masked if the user exports the Cluster Profile).
So simple, yet so powerful
So you see, using Spectro Cloud packs to distribute your applications across a fleet of Kubernetes clusters makes the deployment process faster and the configuration process easier. That’s easier both for platform administrators, and for your users, because it takes away huge amounts of manual effort, cuts the risk of human error, and protects against many common causes of deployment failures.
If after reading this article you decide to give it a try, the pack creation process is straightforward and simple. To create a Spectro Cloud Palette Pack, you need to:
- Take one or more Helm charts or one or more Kubernetes manifests
- Add a pack metadata file (pack.json), containing pack information (such as pack name and description, pack version, list of environments where this pack can be deployed, etc..);
- Build a file containing values available for users, so they can configure the application during the deployment;
- Provide a pack name and logo
- Optionally, define your pack schema constraints
Once you get all of this, you can create and publish the pack by executing “spectro pack push <pack-name>” command to your Palette or OCI repository.
Check our fantastic documentation for detailed information explaining how to create and publish your pack.
If you’re not ready to make your own, you can get started by taking a look at our verified packs and community packs available here.
And if this has inspired you to try Palette for the first time? Great! To get access, start by booking a demo so we can show you around and give you the keys.
