Cluster profiles are created by configuring various layers of the Kubernetes infrastructure stack. To create a New Cluster Profile, follow these steps:
Provide the Basic Information such as:
Parameter Description Name Give a name for the new cluster. Version Include the Cluster Profile Version number for the cluster under which the cluster profile needs to be created. See below for more information. Description Provide quick description of your cluster. This is optional. Profile Type (Full, Infrastructure, Add-on) Dictates the layers that can be configured in the cluster profile. If the cluster profile type is Infrastructure or Full, you are able to select a Cloud Type or Data Center environments. For more information on Add-on types go to step four. Tags Tags on a cluster profile are propagated to the VMs deployed on the cloud/data center environments when clusters are created from the cluster profile. This is optional.
- In the Cloud Type section, select the Environment you are working with. This list displays the environments supported in Palette.
Configure the Profile Layers of the infrastructure stack. The following layers are considered Core Infrastructure layers. Configuring these layers is mandatory for Full or Infrastructure cluster profiles.
Note: These layers are not configurable for Add-On cluster profiles:
Select the Registry, Pack Name, Pack Version, and Pack Values and click on Next Layer to go through each profile layer to completely build the core infrastructure.
Note: Container Storage Interface (CSI) and Container Network Interface (CNI) layers can be added as Helm Charts from customized Helm registries and linked to Spectro Registry packs.
Add-on Layers are additional layers such as Monitoring, Security, or Load Balancers may be added and configured as desired. These layers may be configured for the profiles of the type Full or Add-On. These add-on layers can be added in one of the following ways:Add New PackImport from clusterAdd ManifestAdd New Pack - Add a Palette Pack from a pack registry or a Helm Chart from a chart registry. The public Palette Pack registry and a few popular Helm chart repositories are already available out of the box. Additional pack registries or public/private chart registries can be added to Palette.
Configure each layer as follows:VersionsConfiguration ParametersManifestVersions- Choose the desired version. Choices include pinning to a specific version (e.g. 1.1.1) or picking a major or minor train such as 1.x or 1.1.x. Picking a major/minor train results in a dynamic version association. The latest release from that train is linked to the pack at any given point. Future release updates on the train will result in the pack being relinked to the newest version. This allows clusters to always be at the latest released version, without having to make subsequent updates to the profile.
In order to allow packs to be added multiple times in a profile, add the following key to the pack values in the yaml editor:
<custom_name> is a name unique across a cluster profile and the cluster.
pack:# The namespace (on the target cluster) to install this chart# When not found, a new namespace will be creatednamespace: "external-dns"# Custom pack name for multi-layer supportspectrocloud.com/display-name: "dns-1"
If the same pack is needed at another layer, repeat the above block with the same namespace but a different name such as
dns-2. Display names used for a pack across layers should be unique.
pack:namespace: kube-systemreleaseNameOverride:actual_chart_name1: custom_name1actual_chart_name2: custom_name2
Palette enables users to create multiple versions of a cluster profile within the scope of a single profile name. The Version field of the cluster profile takes a semantic versioning format (only numbers supported) as below:
major.minor.patch represented as: Version 1.1.2
Profile versioning is an optional field with a default value of 1.0.0 . The users can create multiple versions of a cluster profile under a single profile name and each of these versions can have its own pack configurations.
Cluster profile versions are grouped under their unique names and their uniqueness is decided by the name and version within the scope and promotes backward compatibility to profile changes.
Example: Profile-1 can have multiple versions like 1.0.0 and 2.0.1. These versions are grouped under the Cluster Profile Name Profile-1. The menu next to the cluster profile name contains the different versions under that name.
The version numbers can be edited from the Settings > Edit Info option from the Cluster Profile page. While deleting the profile, select the version to be deleted.