Overview
Overview¶
In order to streamline cluster deployments and installation of commonly used services, the platform has default blueprints in the system that can be leveraged by admins. There are two primary use cases for default system blueprints:
Use Cases¶
- Standardize on Best Practices managed by the platform: Streamline cluster deployments by using standard, best-practice templates already built-in to the platform rather than having to create custom blueprints. With this approach, there is less overhead in terms of having to update versions for managed add-ons.
- Use default blueprints as the baseline for your custom blueprints: Rather than having to create completely custom blueprints and having to re-specify add-ons that are common, use a default blueprint as your base and then specify the other custom add-ons or services that you want to use. See the custom blueprint documentation for more.
Navigating to Default Blueprints¶
As an Admin, login into the Web Console
- Select Project
- Select Infrastructure -> Blueprints
- Select the "Default Blueprints" tab
In the example below, the dashboard shows that there are >300 versions of the default blueprint over the entire lifecycle and that there two clusters in the Project based on the default blueprint
Clicking on the clusters link will display the status of the default blueprint on the list of clusters. An illustrative example is shown below.
Types of Default Blueprints¶
There are two types of default blueprints that are available in the platform today:
- Minimal: With the minimal blueprint, all add-ons are disabled by default. The minimal blueprint is extremely useful when as an admin, you want to customize the add-ons and services your clusters are using versus using some of the managed add-ons available in the system.
- Default: "Optimized" default blueprints are available per type of cluster to ensure that the experience is optimized for the particular environment. These blueprints have certain managed add-ons, such as monitoring & visibility enabled in order to streamline deployment of commonly used add-ons in typical enterprise settings. You should use this blueprint type when you want certain managed services to always be enabled on clusters without the overhead of adding it yourself.
The following table summarizes the blueprints that can be used for each cluster type (imported or created). All cluster types support the minimal blueprint. If you want to use the default blueprint type, use the one as specified in the table that corresponds to your cluster type.
| Cluster Type | Minimal Blueprint Supported | Default Blueprint To Use |
|---|---|---|
| AWS EKS | YES | default |
| Azure AKS | YES | default-aks |
| Google GKE | YES | default-gke |
| Upstream (MKS) | YES | default-upstream |
| VMware vSphere | YES | default |
| Red Hat OpenShift | YES | default-openshift |
Considerations when using default blueprints (minimal or cluster optimized defaults)¶
Enabling Turnkey Services (ex. Cost Management)¶
Certain turnkey services in the platform such as cost management are only available with custom blueprints as they require more configuration settings. The following table summarizes which turnkey services can be used with default blueprints.
| Service | Can be used with default blueprint |
|---|---|
| Monitoring & Visibility | YES |
| Network Policy Manager | NO |
| Service Mesh Manager | NO |
| Policy Management (OPA) | NO |
| Cost Management | NO |
| Secrets Store CSI Driver | NO |
Using Your Own Software Add-Ons¶
Many times you want all your clusters by default to be running certain software add-ons. For example, if you are using a specific platform for observability, maybe you want that software to be always running in your clusters.
In order to enable this, you should use a custom blueprint where you can define a blueprint that has that observability software-add on. Refer to custom blueprints to learn more.
Versions for default blueprints¶
Default blueprints are version controlled. These are remotely updated when patches or upgrades are necessary. The configuration for each version can be checked by clicking the eye icon next to each version.
In the example below, the managed cluster is based on a default blueprint. Note the following details
- Name of Blueprint: "default" in this example
- The version/timestamp of the default blueprint
- Blueprint Sync Status
Disabling Default Blueprints In the System¶
Sometimes as an admin, you may want to disable the default blueprint that is included with the controller. For example, you may want to prevent publishing the default blueprint to their production clusters because you want to make sure to use custom blueprints which contains specific software add-ons that you have validated for your organization.
In order to achieve this, default blueprints can be disabled in the system.
Important
In order to this operation, you must be an organization administrator. After disabling the default blueprint, organization administrators can still deploy the default blueprint to their clusters but other users will not be able to use the default blueprints when creating or updating clusters.
- In the console, select System > Settings.
- For Default Blueprints, click the switch. Make sure the setting displays Disabled.
- Click Save.
