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.

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.

Managed System Add-ons Behavior

For Amazon EKS clusters, the Default Blueprint includes certain managed system add-ons that are enabled by default.

The Node Termination Handler add-on is enabled by default when the Default Blueprint is selected. This add-on can be disabled during blueprint configuration if it is not required.

This behavior is specific to the Default Blueprint and applies only to EKS clusters.

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.