diff --git a/content/docs/concepts/_index.md b/content/docs/concepts/_index.md
index 040c7d18..40db19f3 100644
--- a/content/docs/concepts/_index.md
+++ b/content/docs/concepts/_index.md
@@ -11,6 +11,6 @@ deploying, managing, and scaling applications within a Kubernetes environment.
{{< cards >}}
{{< card link="architecture" title="Architecture" icon="cube" >}}
{{< card link="configuration" title="Configurations" icon="adjustments" >}}
- {{< card link="blueprints" title="Blueprints" icon="template" >}}
+ {{< card link="k0rdent-templates" title="k0rdent templates" icon="template" >}}
{{< card link="cni" title="Container Network Interface (CNI)" icon="cube-transparent" >}}
{{< /cards >}}
diff --git a/content/docs/concepts/blueprints.md b/content/docs/concepts/blueprints.md
deleted file mode 100644
index 2df6a6ac..00000000
--- a/content/docs/concepts/blueprints.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-weight: 3
----
-
-# Blueprints
-
-All MKE 4 configuration files are translated into blueprints,
-a file type that is used to create Kubernetes Custom Resources (CRDs)
-that are also called blueprints. MKE 4 uses Blueprint Operator to manage blueprints and their assignments.
-
-Blueprint files must be in Kubernetes YAML format,
-and they must contain many of the same fields as a standard Kubernetes Object.
-
-A blueprint comprises three sections:
-
-
- - Kubernetes Provider
- - Details the settings for the provider. For the most part, the Kubernetes Provider section is managed by
mkectl, independently of the user's MKE configuration file.
- - Infrastructure
- - Provides details that are used for the Kubernetes cluster; the
hosts section of the MKE configuration file.
- - Components
- - Composed of addons that are specified in the MKE configuration file. The
mkectl command transforms the configuration options
-into specific settings for either Helm or Manifest type addons that are deployed into the cluster.
-
-
-To view a detailed blueprint of an MKE configuration, run the `mkectl init --blueprint` command.
-
-{{< callout type="error" >}}
-
-It is possible to directly modify a blueprint. However, such modifications are
-considered advanced and support by MKE 4 is not assured.
-
-{{< /callout >}}
-
-See the Blueprint Operator [documentation](https://mirantiscontainers.github.io/blueprint/) for more details on blueprints.
diff --git a/content/docs/concepts/configuration.md b/content/docs/concepts/configuration.md
index 081f2f5c..ff6f1aed 100644
--- a/content/docs/concepts/configuration.md
+++ b/content/docs/concepts/configuration.md
@@ -13,8 +13,8 @@ With the MKE configuration file, you can:
- Enable or disable certain MKE components.
- Configure MKE component features
-Once set, the MKE configuration file is translated into a more complex
-blueprint that contains the granular details on how to set up the cluster.
+Once set, the MKE configuration file is translated into a more complex [k0rdent
+template](../k0rdent-templates) that contains the granular details on how to set up the cluster.
## Create configuration
@@ -50,15 +50,13 @@ blueprint that contains the granular details on how to set up the cluster.
role: worker
```
-## Choose addons
+## Choose services
-A core component of MKE 4 is a default set of curated and tested addons that you
-can install by running `mkectl init` and subsequently applying the generated
-configuration file.
+A core component of MKE 4 is a default set of curated and tested services that
+you can install by running `mkectl init` and subsequently applying the
+generated configuration file.
-Using the MKE configuration file, you can enable and disable the MKE 4 addons,
-as well as modify their settings. In addition, you can use the
-`mkectl init` command with the `--blueprint` option to print the generated
-blueprint that reflects your current MKE 4 configuration.
+Using the MKE configuration file, you can enable and disable a number of the
+available MKE 4 services, as well as modify the settings of those services.
diff --git a/content/docs/concepts/k0rdent-templates.md b/content/docs/concepts/k0rdent-templates.md
new file mode 100644
index 00000000..b6c7f9cb
--- /dev/null
+++ b/content/docs/concepts/k0rdent-templates.md
@@ -0,0 +1,34 @@
+---
+weight: 3
+---
+
+# k0rdent templates
+
+{{< callout type="info" >}}
+
+[k0rdent](https://k0rdent.io) is a Mirantis-initiated open source project with which platform engineers can build, automate, and manage Kubernetes platforms at scale. MKE 4 is adopting k0rdent technology to enable installation and management of services and components in a template-driven manner. k0rdent is available in MKE 4k as a technical preview only.
+
+For more information on MKE 4k and k0rdent, [contact Mirantis Sales]([mirantis.com/contact).
+
+{{< /callout >}}
+
+k0rdent templates are re-usable text definitions of components that you can use
+to install services. These templates provide a declarative way
+for you to install and manage the lifecycles of components while greatly
+reducing the number of parameters that require hands-on configuration.
+
+## Benefits
+
+k0rdent templates are:
+
+* **Human readable and editable**: k0rdent templates use YAML as an abstraction
+to represent the target state.
+
+* **Usable in multiple contexts by way of runtime parameterization**: Through
+the use of placeholders, you can customize templates at runtime without having
+to directly edit the template.
+
+* **Capable of limited scope deployment**: You can set restrictions over which
+k0rdent templates can be deployed and by whom. For example, a platform manager
+can configure a template so that non-admin users can only execute templates
+that deploy a particular set of controllers.
diff --git a/content/docs/configuration/backup-restore/in-cluster.md b/content/docs/configuration/backup-restore/in-cluster.md
index 2ceb8cd7..40ca9933 100644
--- a/content/docs/configuration/backup-restore/in-cluster.md
+++ b/content/docs/configuration/backup-restore/in-cluster.md
@@ -10,10 +10,9 @@ provider, the [MinIO add-on](https://min.io/).
MinIO is not currently backed by persistent storage. For persistent storage of backups, use an external storage provider or download the MinIO backups.
{{< /callout >}}
-{{< callout type="info" >}}
- The offered instructions assume that you have created a cluster and
- applied a blueprint with the default MKE backup configuration.
-{{< /callout >}}
+{{< callout type="info" >}} The offered instructions assume that you have
+ created a cluster with the default MKE backup configuration. {{< /callout
+>}}
## Create an in-cluster backup
diff --git a/content/docs/configuration/policycontroller/opagatekeeper.md b/content/docs/configuration/policycontroller/opagatekeeper.md
index 6cd134b1..ce399aee 100644
--- a/content/docs/configuration/policycontroller/opagatekeeper.md
+++ b/content/docs/configuration/policycontroller/opagatekeeper.md
@@ -39,17 +39,21 @@ spec:
-
```
-The `exemptNamespaces` field lists the namespaces that are exempt from policy enforcement.
-The following namespaces are added by default, and thus cannot be removed:
-
-- `mke`
-- `kube-system`
-- `kube-public`
-- `kube-node-lease`
-- `k0s-system`
-- `k0s-autopilot`
-- `flux-system`
-- `blueprint-system`
+The `exemptNamespaces` field lists the namespaces that are exempt from policy
+enforcement. The following namespaces are added by default, and thus cannot be
+removed:
+
+- `kube-system`
+- `kube-public`
+- `kube-node-lease`
+- `k0s-system`
+- `k0s-autopilot`
+- `flux-system`
+- `blueprint-system`
+- `mke`
+- `tigera-operator`
+- `calico-system`
+- `calico-apiserver`
## Migration from MKE 3
diff --git a/content/docs/configuration/support-bundle.md b/content/docs/configuration/support-bundle.md
index 3b9b9757..571a5bfc 100644
--- a/content/docs/configuration/support-bundle.md
+++ b/content/docs/configuration/support-bundle.md
@@ -123,26 +123,20 @@ method that was used to install the plugin.
- Collects basic information about the cluster.
- Enumerates all available resources in the cluster.
- - Collects logs from the ``blueprint-controller-manager`` and
- ``blueprint-operator-webhook`` pods, in the ``logs/`` directory of the output.
+ - Collects logs from the ``mke-controller-manager`` pods, in the ``logs/`` directory of the output.
```yaml
- apiVersion: troubleshoot.sh/v1beta2
- kind: SupportBundle
- metadata:
- name: sample
- spec:
- collectors:
- - logs:
- selector:
- - app.kubernetes.io/name=blueprint-webhook
- namespace: blueprint-system
- name: logs/blueprint-system
- - logs:
- selector:
- - control-plane=controller-manager
- namespace: blueprint-system
- name: logs/blueprint-system
+ apiVersion: troubleshoot.sh/v1beta2
+ kind: SupportBundle
+ metadata:
+ name: sample
+ spec:
+ collectors:
+ - logs:
+ selector:
+ - control-plane=controller-manager
+ namespace: mke
+ name: logs/mke
```
2. Generate the support bundle: