From 8be6d346104a4cd66c62517fe0ee4a4e30bb7a78 Mon Sep 17 00:00:00 2001 From: mdziadosz Date: Mon, 27 May 2024 13:23:47 +0200 Subject: [PATCH 01/13] Architecture section update --- .../{README.md => architecture.md} | 23 +++++++++++-------- .../concepts/architecture/configuration.md | 20 +++++++++------- content/releases/README.md | 4 ++-- 3 files changed, 28 insertions(+), 19 deletions(-) rename content/docs/concepts/architecture/{README.md => architecture.md} (50%) diff --git a/content/docs/concepts/architecture/README.md b/content/docs/concepts/architecture/architecture.md similarity index 50% rename from content/docs/concepts/architecture/README.md rename to content/docs/concepts/architecture/architecture.md index 3ca0dbb3..e837943f 100644 --- a/content/docs/concepts/architecture/README.md +++ b/content/docs/concepts/architecture/architecture.md @@ -2,7 +2,7 @@ ## Overview -MKE4 is an enterprise-grade, production-ready Kubernetes platform that is designed to be secure, scalable, and reliable. MKE4 is deployed using a MKE [configuration file](./configuration.md) +Mirantis Kubernetes Engine (MKE) 4 is an enterprise-grade, production-ready Kubernetes platform designed to be secure, scalable, and reliable. MKE4 is deployed using an MKE [configuration file](./configuration.md) ## Components @@ -10,35 +10,40 @@ MKE 4 is built on top of k0s, a lightweight Kubernetes distribution. See the [k0 MKE 4 Alpha.1 is run on top of k0s v1.29.3. -### Control Plane +### Control Plane [mocny edyt] -<[Explain the control plane components and their roles]> +The control plane's components make global decisions about the cluster (for example, scheduling), as well as detecting and responding to cluster events (for example, starting up a new pod when a Deployment's replicas field is unsatisfied). + +Control plane components can be run on any machine in the cluster. However, for simplicity, setup scripts typically start all control plane components on the same machine, and do not run user containers on this machine. #### CNI By default, MKE 4 installs Calico as the CNI plugin. This is done by specifying `calico` in the network provider field of the k0s config. + Calico is installed with the following configuration: + - IPv4 only with a fixed pod CIDR of `10.244.0.0/16`. - The datastore mode is set to `kdd`. - `kube-proxy` set to `iptables` mode. - `vxlan` backend, which uses the default port of `4789` for traffic and default virtual network ID of `4096`. With the Alpha.1 release, MKE 4 has the following limitations: + - There is no option to use a different CNI plugin. - There is no option to configure Calico from the above defaults. - When a cluster is upgraded from MKE 3, the Calico configuration is not migrated. -### Data Plane + -[Discuss the data plane components and their functions] + -## High-Level Diagram + -[Include a high-level diagram illustrating the MKE architecture] + -## Deployment Considerations + -[Highlight any important considerations for deploying MKE] + ## Conclusion diff --git a/content/docs/concepts/architecture/configuration.md b/content/docs/concepts/architecture/configuration.md index 9b05e22f..7b09ccb6 100644 --- a/content/docs/concepts/architecture/configuration.md +++ b/content/docs/concepts/architecture/configuration.md @@ -1,8 +1,10 @@ -## MKE4 Configuration & Blueprints -The MKE4 Configuration file contains an opinionated configuration on how to set up the MKE cluster. It lets the user define details about their cluster such as how many nodes there are in the cluster, how to access the nodes, and any specific MKE4 feature that you want to enable/disable. The simple MKE4 configuration file is translated into a more complex Blueprint that contains the granular details of how to set up the cluster. +# Configuration and Blueprints +The Mirantis Kubernetes Engine (MKE) 4 Configuration file contains an opinionated configuration on how to set up the MKE cluster. It lets the user define details about their cluster such as how many nodes there are in the cluster, how to access the nodes, and any specific MKE4 feature that you want to enable/disable. The simple MKE4 configuration file is translated into a more complex Blueprint that contains the granular details of how to set up the cluster. + + +## Creating your config -### Creating your Config A default MKE config can be generated by running `mkectl init > mke.yaml`. This will generate a default config that you can modify to deploy MKE on your cluster. To apply your config to a set of pre-existing machines, modify the `hosts` section of the config. @@ -41,17 +43,19 @@ Alternatively you can provide `mkectl` with the credentials to connect to an MKE `mkectl init --mke3-admin-username admin --mke3-admin-password password --mke3-hostname mke3.example.com` -### Choosing Addons -A core part of MKE4 is the ability to selectively install addons from from a set of curated and tested addons. `mkectl init` will enable a set of default addons that are considered core to MKE4. You can modify the generated config to enable/disable additional addons as you wish, as well as modify settings on each particular addon. +## Choosing Addons + +A core part of MKE4 is the ability to selectively install addons from a set of curated and tested addons. `mkectl init` will enable a set of default addons that are considered core to MKE4. You can modify the generated config to enable/disable additional addons as you wish, as well as modify settings on each particular addon. + +## Blueprints -### Blueprints -MKE4 uses the blueprint operator under the hood. All MKE4 configs are translated into blueprints. A blueprint is a special type of file that is used to create a Kubernetes Custom Resource (CRD) also called a Blueprint. Thus the blueprint file must be valid Kubernetes YAML and contains many of the same fields as standard Kubernetes Objects. +MKE4 uses the blueprint operator under the hood. All MKE4 configs are translated into blueprints. A blueprint is a special type of file that is used to create a Kubernetes Custom Resource (CRD) also called a Blueprint. Thus, the blueprint file must be a valid Kubernetes YAML and contains many of the same fields as standard Kubernetes Objects. A blueprint is roughly composed of 3 sections. 1. The section detailing the Kubernetes Provider and any specific settings for that provider. This section is mostly managed by `mkectl` independently of the user provided MKE config. 2. The section detailing the infrastructure that will be used for the Kubernetes Cluster. This is essentially just the `hosts` section of the MKE config. 3. The components section. This section is composed of the various addons specified in the MKE config. `mkectl` takes the user-friendly MKE config options and translates them into specific settings in either Helm or Manifest type addons that are deployed into the cluster. -To see the detailed blueprint of a MKE config you can run `mkectl init --blueprint`. It is possible to modify the blueprint directly but any such modifications are considered advanced and not officially supported by MKE. +To see the detailed blueprint of a MKE config you can run `mkectl init --blueprint`. It is possible to modify the blueprint directly, but any such modifications are considered advanced and not officially supported by MKE. Please see the blueprint operator [documentation](https://mirantiscontainers.github.io/boundless/) for more details on blueprints. \ No newline at end of file diff --git a/content/releases/README.md b/content/releases/README.md index a1daeebc..9b996b97 100644 --- a/content/releases/README.md +++ b/content/releases/README.md @@ -26,12 +26,12 @@ This table summarizes MKE 4 features, their status, and links to guides | gMSA | | | | GPU Feature Discovery | | | | [Ingress](../docs/reference/ingress/README.md) | alpha.1| MVP | | -| [Kubernetes](../docs/concepts/architecture/README.md#Components) | alpha.1 | MVP 1.29 | | +| [Kubernetes](../docs/concepts/architecture/architecture#Components) | alpha.1 | MVP 1.29 | | | Life Cycle Management | | | | Licensing | | | | Load Balancing | | | | Logging, Monitoring and Alerting | alpha.1 | MVP | -| [Networking (CNI)](../docs/concepts/architecture/README.md#CNI) | alpha.1 | MVP | +| [Networking (CNI)](../docs/concepts/architecture/architecture#CNI) | alpha.1 | MVP | | Node Feature Discovery | | | | Offline Bundle | | | | OpsCare | | | From ba3c82886a9565d7df4cbe105b46e869b91e4cb4 Mon Sep 17 00:00:00 2001 From: mdziadosz Date: Wed, 29 May 2024 13:12:39 +0200 Subject: [PATCH 02/13] Architecture section update --- .../concepts/architecture/architecture.md | 34 ++++---- .../concepts/architecture/configuration.md | 81 ++++++++++++++----- 2 files changed, 78 insertions(+), 37 deletions(-) diff --git a/content/docs/concepts/architecture/architecture.md b/content/docs/concepts/architecture/architecture.md index e837943f..f405dec1 100644 --- a/content/docs/concepts/architecture/architecture.md +++ b/content/docs/concepts/architecture/architecture.md @@ -1,28 +1,32 @@ # MKE Architecture -## Overview - -Mirantis Kubernetes Engine (MKE) 4 is an enterprise-grade, production-ready Kubernetes platform designed to be secure, scalable, and reliable. MKE4 is deployed using an MKE [configuration file](./configuration.md) +Mirantis Kubernetes Engine (MKE) 4 is an enterprise-grade, production-ready +Kubernetes platform designed to be secure, scalable, and reliable. +MKE 4 is deployed using an MKE configuration file. +See the [Configuration and blueprints](configuration.md) for more information. ## Components -MKE 4 is built on top of k0s, a lightweight Kubernetes distribution. See the [k0s documentation](https://k0sproject.io/docs/) for more information. - -MKE 4 Alpha.1 is run on top of k0s v1.29.3. +MKE 4 is built on top of k0s, a lightweight Kubernetes distribution. +See the [official k0s documentation](https://docs.k0sproject.io/v1.29.3+k0s.0/) +for more information. -### Control Plane [mocny edyt] +### Control plane -The control plane's components make global decisions about the cluster (for example, scheduling), as well as detecting and responding to cluster events (for example, starting up a new pod when a Deployment's replicas field is unsatisfied). +MKE 4 uses a control plane that oversees crucial cluster-wide decisions, +and monitors and responds to events within the cluster. +While the control plane components can function on any machine in the cluster, +setup scripts streamline the process by running all control plane +components on one machine and excluding user containers from that machine. -Control plane components can be run on any machine in the cluster. However, for simplicity, setup scripts typically start all control plane components on the same machine, and do not run user containers on this machine. +### Container Network Interface (CNI) -#### CNI - -By default, MKE 4 installs Calico as the CNI plugin. This is done by specifying `calico` in the network provider field of the k0s config. +By default, MKE 4 installs Calico as the CNI plugin. This is done by specifying +`calico` in the network provider field of the k0s configuration. Calico is installed with the following configuration: -- IPv4 only with a fixed pod CIDR of `10.244.0.0/16`. +- IPv4 only with a fixed Pod CIDR of `10.244.0.0/16`. - The datastore mode is set to `kdd`. - `kube-proxy` set to `iptables` mode. - `vxlan` backend, which uses the default port of `4789` for traffic and default virtual network ID of `4096`. @@ -45,6 +49,4 @@ With the Alpha.1 release, MKE 4 has the following limitations: -## Conclusion - -[Wrap up the document with a conclusion or summary] + diff --git a/content/docs/concepts/architecture/configuration.md b/content/docs/concepts/architecture/configuration.md index 7b09ccb6..e85b14ad 100644 --- a/content/docs/concepts/architecture/configuration.md +++ b/content/docs/concepts/architecture/configuration.md @@ -1,15 +1,24 @@ -# Configuration and Blueprints +# Configuration and blueprints -The Mirantis Kubernetes Engine (MKE) 4 Configuration file contains an opinionated configuration on how to set up the MKE cluster. It lets the user define details about their cluster such as how many nodes there are in the cluster, how to access the nodes, and any specific MKE4 feature that you want to enable/disable. The simple MKE4 configuration file is translated into a more complex Blueprint that contains the granular details of how to set up the cluster. +The Mirantis Kubernetes Engine (MKE) 4 configuration file contains an +opinionated configuration on how to set up the MKE cluster. +In the configuration file, you can: -## Creating your config +- Define the number of nodes in the cluster. +- Define ways to access the nodes. +- Enable or disable certain MKE 4 features. -A default MKE config can be generated by running `mkectl init > mke.yaml`. This will generate a default config that you can modify to deploy MKE on your cluster. +The configuration file is translated into a more complex blueprint +that contains the granular details on how to set up the cluster. -To apply your config to a set of pre-existing machines, modify the `hosts` section of the config. +## Create configuration -An example of a hosts section is shown below: +To generate the default MKE configuration file run `mkectl init > mke.yaml` command. +Next, modify generated file accordingly to deploy MKE on the cluster. + +To apply configuration to a set of pre-existing machines, modify the `hosts` +section of the file: ```yaml hosts: @@ -33,29 +42,59 @@ hosts: role: worker ``` -For users migrating from MKE3, it is possible to pass some options to `mkectl` to migrate your settings directly from MKE3. +## Migrate configuration -To pass in a downloaded MKE3 config file set the `--mke3-config` flag. This will convert the local MKE3 config into a valid MKE4 config. +If you migrate from MKE 3, you can pass some options to `mkectl` to transfer +the settings directly from MKE 3. Execute one of the following options: -`mkectl init --mke3-config /path/to/mke3-config.toml` +**Convert local MKE 3 config** -Alternatively you can provide `mkectl` with the credentials to connect to an MKE3 Cluster, which will allow `mkectl` to retrieve the MKE3 config itself and then convert it to an MKE4 config. +To pass in a downloaded MKE 3 configuration file set the `--mke3-config` flag. +This will convert the local MKE 3 config into a valid MKE 4 config. -`mkectl init --mke3-admin-username admin --mke3-admin-password password --mke3-hostname mke3.example.com` +```bash +mkectl init --mke3-config /path/to/mke3-config.toml +``` -## Choosing Addons +**Retrieve and convert MKE 3 config from a cluster** -A core part of MKE4 is the ability to selectively install addons from a set of curated and tested addons. `mkectl init` will enable a set of default addons that are considered core to MKE4. You can modify the generated config to enable/disable additional addons as you wish, as well as modify settings on each particular addon. +Alternatively, you can provide `mkectl` with the credentials to connect to +an MKE 3 Cluster, which will allow `mkectl` to retrieve the MKE 3 config itself, +and convert it to an MKE 4 config. -## Blueprints +```bash +mkectl init --mke3-admin-username admin --mke3-admin-password password --mke3-hostname mke3.example.com +``` -MKE4 uses the blueprint operator under the hood. All MKE4 configs are translated into blueprints. A blueprint is a special type of file that is used to create a Kubernetes Custom Resource (CRD) also called a Blueprint. Thus, the blueprint file must be a valid Kubernetes YAML and contains many of the same fields as standard Kubernetes Objects. +## Choose addons -A blueprint is roughly composed of 3 sections. -1. The section detailing the Kubernetes Provider and any specific settings for that provider. This section is mostly managed by `mkectl` independently of the user provided MKE config. -2. The section detailing the infrastructure that will be used for the Kubernetes Cluster. This is essentially just the `hosts` section of the MKE config. -3. The components section. This section is composed of the various addons specified in the MKE config. `mkectl` takes the user-friendly MKE config options and translates them into specific settings in either Helm or Manifest type addons that are deployed into the cluster. +A core part of MKE 4 is the ability to selectively install addons from a set of +curated and tested addons. Run `mkectl init` command to enable a set of default +addons that are considered core to MKE 4. You can modify the generated config to +enable or disable additional addons, as well as modify their settings. -To see the detailed blueprint of a MKE config you can run `mkectl init --blueprint`. It is possible to modify the blueprint directly, but any such modifications are considered advanced and not officially supported by MKE. +## Blueprints -Please see the blueprint operator [documentation](https://mirantiscontainers.github.io/boundless/) for more details on blueprints. \ No newline at end of file +All MKE 4 configuration files are translated into blueprints. +A blueprint is a special type of file that is used +to create a Kubernetes Custom Resource (CRD) also called a blueprint. +Thus, the blueprint file must be a valid Kubernetes YAML and contain many +of the same fields as standard Kubernetes Objects. +MKE 4 uses the Blueprint Operator to manage all blueprints and their assignments. + +A blueprint is composed of three sections: + +1. The Kubernetes Provider details with settings for that provider. +This section is mostly managed by `mkectl` independently of the user provided MKE configuration file. +2. The infrastructure details that are used for the Kubernetes Cluster. +This is the `hosts` section of the MKE configuration file. +3. The components section, composed of various addons specified in the MKE +configuration file. The `mkectl` command transforms the MKE configuration options +into specific settings in either Helm or Manifest type addons that are deployed +into the cluster. + +To see detailed blueprint of an MKE config run `mkectl init --blueprint` command. +You can modify the blueprint directly, but any such modification is considered +advanced and is not supported by MKE. + + From 7ff1a2c384b43a770216c1e6fc3b9fcf6dd91413 Mon Sep 17 00:00:00 2001 From: mdziadosz Date: Wed, 29 May 2024 17:07:31 +0200 Subject: [PATCH 03/13] Authentication section update --- content/releases/README.md | 60 +++++++++++++++++++------------------- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/content/releases/README.md b/content/releases/README.md index 9b996b97..6e95fc59 100644 --- a/content/releases/README.md +++ b/content/releases/README.md @@ -13,33 +13,33 @@ ### Features This table summarizes MKE 4 features, their status, and links to guides -| Feature | Pre-Release | Status | -|------------------------------------------------------------------|-------|----------| -| Authentication | alpha.1| MVP | -| Authorization | alpha.1 | MVP | -| [Backup & Restore](../docs/reference/backuprestore/README.md) | alpha.1 | MVP | -| CIS Benchmark | | | -| CLI | | | -| Cloud Providers | | | -| CoreDNS | | | -| cAdvisor | | | -| gMSA | | | -| GPU Feature Discovery | | | -| [Ingress](../docs/reference/ingress/README.md) | alpha.1| MVP | | -| [Kubernetes](../docs/concepts/architecture/architecture#Components) | alpha.1 | MVP 1.29 | | -| Life Cycle Management | | | -| Licensing | | | -| Load Balancing | | | -| Logging, Monitoring and Alerting | alpha.1 | MVP | -| [Networking (CNI)](../docs/concepts/architecture/architecture#CNI) | alpha.1 | MVP | -| Node Feature Discovery | | | -| Offline Bundle | | | -| OpsCare | | | -| Policy Controller | | | -| Storage (CSI) | | | -| Support Dump | | | -| Telemetry | | | -| TLS | | | -| 2FA | | | -| Web UI | alpha 2 | | -| Windows | | | +| Feature | Pre-Release | Status | +|------------------------------------------------------------------------|-------|----------| +| Authentication | alpha.1| MVP | +| Authorization | alpha.1 | MVP | +| [Backup & Restore](../docs/reference/backuprestore/README.md) | alpha.1 | MVP | +| CIS Benchmark | | | +| CLI | | | +| Cloud Providers | | | +| CoreDNS | | | +| cAdvisor | | | +| gMSA | | | +| GPU Feature Discovery | | | +| [Ingress](../docs/reference/ingress/README.md) | alpha.1| MVP | | +| [Kubernetes](../docs/concepts/architecture/architecture.md#Components) | alpha.1 | MVP 1.29 | | +| Life Cycle Management | | | +| Licensing | | | +| Load Balancing | | | +| Logging, Monitoring and Alerting | alpha.1 | MVP | +| [Networking (CNI)](../docs/concepts/architecture/architecture.md#CNI) | alpha.1 | MVP | +| Node Feature Discovery | | | +| Offline Bundle | | | +| OpsCare | | | +| Policy Controller | | | +| Storage (CSI) | | | +| Support Dump | | | +| Telemetry | | | +| TLS | | | +| 2FA | | | +| Web UI | alpha 2 | | +| Windows | | | From b77300438bc82ffce67f1b18482aa88b2239a570 Mon Sep 17 00:00:00 2001 From: mdziadosz Date: Wed, 29 May 2024 17:10:54 +0200 Subject: [PATCH 04/13] Authentication section update --- content/releases/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/releases/README.md b/content/releases/README.md index 6e95fc59..01e6bdac 100644 --- a/content/releases/README.md +++ b/content/releases/README.md @@ -26,12 +26,12 @@ This table summarizes MKE 4 features, their status, and links to guides | gMSA | | | | GPU Feature Discovery | | | | [Ingress](../docs/reference/ingress/README.md) | alpha.1| MVP | | -| [Kubernetes](../docs/concepts/architecture/architecture.md#Components) | alpha.1 | MVP 1.29 | | +| [Kubernetes](../docs/concepts/architecture/architecture.md#components) | alpha.1 | MVP 1.29 | | | Life Cycle Management | | | | Licensing | | | | Load Balancing | | | | Logging, Monitoring and Alerting | alpha.1 | MVP | -| [Networking (CNI)](../docs/concepts/architecture/architecture.md#CNI) | alpha.1 | MVP | +| [Networking (CNI)](../docs/concepts/architecture/architecture.md#container-network-interface-cni-) | alpha.1 | MVP | | Node Feature Discovery | | | | Offline Bundle | | | | OpsCare | | | From e51f1c0fcb916cad34323f6b799d7c0c59706287 Mon Sep 17 00:00:00 2001 From: mdziadosz Date: Mon, 3 Jun 2024 14:20:07 +0200 Subject: [PATCH 05/13] Fixes after PR review --- .../concepts/architecture/architecture.md | 5 +--- .../concepts/architecture/configuration.md | 26 ++----------------- .../architecture/migrate-configuration.md | 13 ++++++++++ content/releases/README.md | 2 +- 4 files changed, 17 insertions(+), 29 deletions(-) create mode 100644 content/docs/concepts/architecture/migrate-configuration.md diff --git a/content/docs/concepts/architecture/architecture.md b/content/docs/concepts/architecture/architecture.md index f405dec1..5dfc5f97 100644 --- a/content/docs/concepts/architecture/architecture.md +++ b/content/docs/concepts/architecture/architecture.md @@ -21,10 +21,7 @@ components on one machine and excluding user containers from that machine. ### Container Network Interface (CNI) -By default, MKE 4 installs Calico as the CNI plugin. This is done by specifying -`calico` in the network provider field of the k0s configuration. - -Calico is installed with the following configuration: +By default, MKE 4 installs Calico as the CNI plugin with the following configuration: - IPv4 only with a fixed Pod CIDR of `10.244.0.0/16`. - The datastore mode is set to `kdd`. diff --git a/content/docs/concepts/architecture/configuration.md b/content/docs/concepts/architecture/configuration.md index e85b14ad..cee4e924 100644 --- a/content/docs/concepts/architecture/configuration.md +++ b/content/docs/concepts/architecture/configuration.md @@ -42,36 +42,14 @@ hosts: role: worker ``` -## Migrate configuration - -If you migrate from MKE 3, you can pass some options to `mkectl` to transfer -the settings directly from MKE 3. Execute one of the following options: - -**Convert local MKE 3 config** - -To pass in a downloaded MKE 3 configuration file set the `--mke3-config` flag. -This will convert the local MKE 3 config into a valid MKE 4 config. - -```bash -mkectl init --mke3-config /path/to/mke3-config.toml -``` - -**Retrieve and convert MKE 3 config from a cluster** - -Alternatively, you can provide `mkectl` with the credentials to connect to -an MKE 3 Cluster, which will allow `mkectl` to retrieve the MKE 3 config itself, -and convert it to an MKE 4 config. - -```bash -mkectl init --mke3-admin-username admin --mke3-admin-password password --mke3-hostname mke3.example.com -``` - ## Choose addons A core part of MKE 4 is the ability to selectively install addons from a set of curated and tested addons. Run `mkectl init` command to enable a set of default addons that are considered core to MKE 4. You can modify the generated config to enable or disable additional addons, as well as modify their settings. +The `init` command also includes a `--blueprint` option, which can be used to +print the generated blueprint that reflects the current MKE 4 configuration. ## Blueprints diff --git a/content/docs/concepts/architecture/migrate-configuration.md b/content/docs/concepts/architecture/migrate-configuration.md new file mode 100644 index 00000000..6d44e45a --- /dev/null +++ b/content/docs/concepts/architecture/migrate-configuration.md @@ -0,0 +1,13 @@ +# Migrate configuration + +If you migrate from MKE 3, you can pass some options to `mkectl` to transfer +the settings directly from MKE 3. + +**Convert local MKE 3 config** + +To pass in a downloaded MKE 3 configuration file set the `--mke3-config` flag. +This will convert the local MKE 3 config into a valid MKE 4 config. + +```bash +mkectl init --mke3-config /path/to/mke3-config.toml +``` diff --git a/content/releases/README.md b/content/releases/README.md index 01e6bdac..adb6047e 100644 --- a/content/releases/README.md +++ b/content/releases/README.md @@ -31,7 +31,7 @@ This table summarizes MKE 4 features, their status, and links to guides | Licensing | | | | Load Balancing | | | | Logging, Monitoring and Alerting | alpha.1 | MVP | -| [Networking (CNI)](../docs/concepts/architecture/architecture.md#container-network-interface-cni-) | alpha.1 | MVP | +| [Networking (CNI)](../docs/concepts/architecture/architecture.md#container-network-interface-cni) | alpha.1 | MVP | | Node Feature Discovery | | | | Offline Bundle | | | | OpsCare | | | From b74c66738129bb1858b2376460443b91ad459ac1 Mon Sep 17 00:00:00 2001 From: mdziadosz Date: Mon, 3 Jun 2024 14:50:00 +0200 Subject: [PATCH 06/13] Fixes after PR review --- content/docs/concepts/architecture/architecture.md | 4 ++-- content/releases/README.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/content/docs/concepts/architecture/architecture.md b/content/docs/concepts/architecture/architecture.md index 5dfc5f97..cc0ca526 100644 --- a/content/docs/concepts/architecture/architecture.md +++ b/content/docs/concepts/architecture/architecture.md @@ -19,9 +19,9 @@ While the control plane components can function on any machine in the cluster, setup scripts streamline the process by running all control plane components on one machine and excluding user containers from that machine. -### Container Network Interface (CNI) +### Container Network Interface -By default, MKE 4 installs Calico as the CNI plugin with the following configuration: +By default, MKE 4 installs Calico as the Container Network Interface (CNI) plugin with the following configuration: - IPv4 only with a fixed Pod CIDR of `10.244.0.0/16`. - The datastore mode is set to `kdd`. diff --git a/content/releases/README.md b/content/releases/README.md index adb6047e..7e01c683 100644 --- a/content/releases/README.md +++ b/content/releases/README.md @@ -31,7 +31,7 @@ This table summarizes MKE 4 features, their status, and links to guides | Licensing | | | | Load Balancing | | | | Logging, Monitoring and Alerting | alpha.1 | MVP | -| [Networking (CNI)](../docs/concepts/architecture/architecture.md#container-network-interface-cni) | alpha.1 | MVP | +| [Networking (CNI)](../docs/concepts/architecture/architecture.md#container-network-interface) | alpha.1 | MVP | | Node Feature Discovery | | | | Offline Bundle | | | | OpsCare | | | From 01facdfa831a31ac86df910b088fa8b13ea1a566 Mon Sep 17 00:00:00 2001 From: Magdalena Dziadosz <160592158+MagdaDziadosz@users.noreply.github.com> Date: Wed, 5 Jun 2024 09:15:36 +0200 Subject: [PATCH 07/13] Apply suggestions from code review Co-authored-by: Kory <57411706+KoryKessel-Mirantis@users.noreply.github.com> --- .../concepts/architecture/architecture.md | 24 +++++++++---------- .../concepts/architecture/configuration.md | 4 ++-- 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/content/docs/concepts/architecture/architecture.md b/content/docs/concepts/architecture/architecture.md index cc0ca526..13e2e064 100644 --- a/content/docs/concepts/architecture/architecture.md +++ b/content/docs/concepts/architecture/architecture.md @@ -1,14 +1,14 @@ # MKE Architecture Mirantis Kubernetes Engine (MKE) 4 is an enterprise-grade, production-ready -Kubernetes platform designed to be secure, scalable, and reliable. -MKE 4 is deployed using an MKE configuration file. -See the [Configuration and blueprints](configuration.md) for more information. +Kubernetes platform that is designed to be secure, scalable, and reliable. +You deploy the software using an MKE configuration file. +Refer to [Configuration and blueprints](configuration.md) for more information. ## Components MKE 4 is built on top of k0s, a lightweight Kubernetes distribution. -See the [official k0s documentation](https://docs.k0sproject.io/v1.29.3+k0s.0/) +Refer to the [official k0s documentation](https://docs.k0sproject.io/v1.29.3+k0s.0/) for more information. ### Control plane @@ -21,18 +21,18 @@ components on one machine and excluding user containers from that machine. ### Container Network Interface -By default, MKE 4 installs Calico as the Container Network Interface (CNI) plugin with the following configuration: +By default, Calico is installed as the Container Network Interface (CNI) plugin, with the following configuration: -- IPv4 only with a fixed Pod CIDR of `10.244.0.0/16`. -- The datastore mode is set to `kdd`. +- IPv4 only, with a fixed Pod CIDR of `10.244.0.0/16`. +- The datastore mode set to `kdd`. - `kube-proxy` set to `iptables` mode. -- `vxlan` backend, which uses the default port of `4789` for traffic and default virtual network ID of `4096`. +- A `vxlan` backend, which uses the default port of `4789` for traffic and default virtual network ID of `4096`. -With the Alpha.1 release, MKE 4 has the following limitations: +The MKE 4 Alpha.1 release has the following limitations: -- There is no option to use a different CNI plugin. -- There is no option to configure Calico from the above defaults. -- When a cluster is upgraded from MKE 3, the Calico configuration is not migrated. +- The CNI plugin cannot be changed. +- Calico cannot be reconfigured. +- The Calico configuration is not migrated during an upgrade to MKE4 from MKE 3. diff --git a/content/docs/concepts/architecture/configuration.md b/content/docs/concepts/architecture/configuration.md index cee4e924..80ab9a74 100644 --- a/content/docs/concepts/architecture/configuration.md +++ b/content/docs/concepts/architecture/configuration.md @@ -3,13 +3,13 @@ The Mirantis Kubernetes Engine (MKE) 4 configuration file contains an opinionated configuration on how to set up the MKE cluster. -In the configuration file, you can: +With the MKE configuration file, you can: - Define the number of nodes in the cluster. - Define ways to access the nodes. - Enable or disable certain MKE 4 features. -The configuration file is translated into a more complex blueprint +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. ## Create configuration From 4de1327839b082b891961b9153a461c6d6577141 Mon Sep 17 00:00:00 2001 From: mdziadosz Date: Wed, 5 Jun 2024 10:24:14 +0200 Subject: [PATCH 08/13] Fixes after PR review --- content/docs/concepts/architecture/architecture.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/docs/concepts/architecture/architecture.md b/content/docs/concepts/architecture/architecture.md index 13e2e064..5e145f24 100644 --- a/content/docs/concepts/architecture/architecture.md +++ b/content/docs/concepts/architecture/architecture.md @@ -13,11 +13,11 @@ for more information. ### Control plane -MKE 4 uses a control plane that oversees crucial cluster-wide decisions, -and monitors and responds to events within the cluster. -While the control plane components can function on any machine in the cluster, -setup scripts streamline the process by running all control plane -components on one machine and excluding user containers from that machine. +The MKE 4 control plane oversees crucial cluster-wide decisions, monitoring and +responding to events within the cluster. +While the control plane can function on any machine in the cluster, +setup scripts ensure maximum efficiency by running all control plane components +on one machine and by excluding user containers from that machine. ### Container Network Interface From f747d72cd1999a278619b3c9ec31a26eb872c5b1 Mon Sep 17 00:00:00 2001 From: mdziadosz Date: Wed, 5 Jun 2024 10:24:14 +0200 Subject: [PATCH 09/13] Fixes after PR review --- .../concepts/architecture/configuration.md | 58 ++++++++++--------- 1 file changed, 31 insertions(+), 27 deletions(-) diff --git a/content/docs/concepts/architecture/configuration.md b/content/docs/concepts/architecture/configuration.md index 80ab9a74..d1f612ea 100644 --- a/content/docs/concepts/architecture/configuration.md +++ b/content/docs/concepts/architecture/configuration.md @@ -14,33 +14,37 @@ that contains the granular details on how to set up the cluster. ## Create configuration -To generate the default MKE configuration file run `mkectl init > mke.yaml` command. -Next, modify generated file accordingly to deploy MKE on the cluster. - -To apply configuration to a set of pre-existing machines, modify the `hosts` -section of the file: - -```yaml -hosts: -- ssh: - address: 18.224.23.158 - keyPath: "/absolute/path/to/private/key.pem" - port: 22 - user: root - role: controller+worker -- ssh: - address: 18.224.23.158 - keyPath: "/absolute/path/to/private/key.pem" - port: 22 - user: ubuntu - role: worker -- ssh: - address: 18.117.87.45 - keyPath: "/absolute/path/to/private/key.pem" - port: 22 - user: ubuntu - role: worker -``` +1. Generate the default MKE configuration file by running: + + ```commandline + mkectl init > mke.yaml + ``` + +2. Modify the generated file to deploy MKE on the cluster. +3. Modify the hosts section of the MKE configuration file, +to apply the configuration to a set of pre-existing machines: + + ```yaml + hosts: + - ssh: + address: 18.224.23.158 + keyPath: "/absolute/path/to/private/key.pem" + port: 22 + user: root + role: controller+worker + - ssh: + address: 18.224.23.158 + keyPath: "/absolute/path/to/private/key.pem" + port: 22 + user: ubuntu + role: worker + - ssh: + address: 18.117.87.45 + keyPath: "/absolute/path/to/private/key.pem" + port: 22 + user: ubuntu + role: worker + ``` ## Choose addons From 8bad361bd6b9073315aa5df996e48fda576488ce Mon Sep 17 00:00:00 2001 From: mdziadosz Date: Fri, 7 Jun 2024 20:09:30 +0200 Subject: [PATCH 10/13] Fixes after review --- .../concepts/architecture/configuration.md | 70 +++++++++++-------- .../architecture/migrate-configuration.md | 10 +-- 2 files changed, 47 insertions(+), 33 deletions(-) diff --git a/content/docs/concepts/architecture/configuration.md b/content/docs/concepts/architecture/configuration.md index d1f612ea..2b20a08e 100644 --- a/content/docs/concepts/architecture/configuration.md +++ b/content/docs/concepts/architecture/configuration.md @@ -21,7 +21,7 @@ that contains the granular details on how to set up the cluster. ``` 2. Modify the generated file to deploy MKE on the cluster. -3. Modify the hosts section of the MKE configuration file, +3. Modify the `hosts` section of the MKE configuration file, to apply the configuration to a set of pre-existing machines: ```yaml @@ -48,35 +48,49 @@ to apply the configuration to a set of pre-existing machines: ## Choose addons -A core part of MKE 4 is the ability to selectively install addons from a set of -curated and tested addons. Run `mkectl init` command to enable a set of default -addons that are considered core to MKE 4. You can modify the generated config to -enable or disable additional addons, as well as modify their settings. -The `init` command also includes a `--blueprint` option, which can be used to -print the generated blueprint that reflects the current MKE 4 configuration. +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. + +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. ## Blueprints -All MKE 4 configuration files are translated into blueprints. -A blueprint is a special type of file that is used -to create a Kubernetes Custom Resource (CRD) also called a blueprint. -Thus, the blueprint file must be a valid Kubernetes YAML and contain many -of the same fields as standard Kubernetes Objects. -MKE 4 uses the Blueprint Operator to manage all blueprints and their assignments. - -A blueprint is composed of three sections: - -1. The Kubernetes Provider details with settings for that provider. -This section is mostly managed by `mkectl` independently of the user provided MKE configuration file. -2. The infrastructure details that are used for the Kubernetes Cluster. -This is the `hosts` section of the MKE configuration file. -3. The components section, composed of various addons specified in the MKE -configuration file. The `mkectl` command transforms the MKE configuration options -into specific settings in either Helm or Manifest type addons that are deployed -into the cluster. - -To see detailed blueprint of an MKE config run `mkectl init --blueprint` command. -You can modify the blueprint directly, but any such modification is considered -advanced and is not supported by MKE. +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. + +Blueprint files must be in Kubernetes YAML format, +and they must contain many of the same fields as a standard Kubernetes Object. + +MKE 4 uses Blueprint Operator to manage blueprints and their assignments. + +A blueprint comprises three sections: + +**Kubernetes Provider** + +Details the settings for the provider. + +For the most part, the Kubernetes Provider section is managed by `mkectrl`, +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. + +> It is possible to directly modify a blueprint, however, such modifications are +> considered advanced and support by MKE 4 is not assured. diff --git a/content/docs/concepts/architecture/migrate-configuration.md b/content/docs/concepts/architecture/migrate-configuration.md index 6d44e45a..53d10a7f 100644 --- a/content/docs/concepts/architecture/migrate-configuration.md +++ b/content/docs/concepts/architecture/migrate-configuration.md @@ -1,12 +1,12 @@ # Migrate configuration -If you migrate from MKE 3, you can pass some options to `mkectl` to transfer -the settings directly from MKE 3. +In migrating to MKE 4 from MKE 3, you can directly transfer settings by passing +several options to `mkectl`. -**Convert local MKE 3 config** +**To convert a local MKE 3 configuration for MKE 4:** -To pass in a downloaded MKE 3 configuration file set the `--mke3-config` flag. -This will convert the local MKE 3 config into a valid MKE 4 config. +Set the `--mke3-config` flag to convert a downloaded MKE 3 configuration file into +a valid MKE 4 configuration file, as follows: ```bash mkectl init --mke3-config /path/to/mke3-config.toml From 815b0fff190f75bcb594b329c9bf86fd3d771a95 Mon Sep 17 00:00:00 2001 From: mdziadosz Date: Fri, 7 Jun 2024 20:14:29 +0200 Subject: [PATCH 11/13] link update --- content/releases/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/releases/README.md b/content/releases/README.md index 7e01c683..6e22cbaf 100644 --- a/content/releases/README.md +++ b/content/releases/README.md @@ -17,7 +17,7 @@ This table summarizes MKE 4 features, their status, and links to guides |------------------------------------------------------------------------|-------|----------| | Authentication | alpha.1| MVP | | Authorization | alpha.1 | MVP | -| [Backup & Restore](../docs/reference/backuprestore/README.md) | alpha.1 | MVP | +| [Backup & Restore](../docs/reference/backuprestore/backup-restore.md) | alpha.1 | MVP | | CIS Benchmark | | | | CLI | | | | Cloud Providers | | | @@ -25,7 +25,7 @@ This table summarizes MKE 4 features, their status, and links to guides | cAdvisor | | | | gMSA | | | | GPU Feature Discovery | | | -| [Ingress](../docs/reference/ingress/README.md) | alpha.1| MVP | | +| [Ingress](../docs/reference/ingress/ingress-controller.md) | alpha.1| MVP | | | [Kubernetes](../docs/concepts/architecture/architecture.md#components) | alpha.1 | MVP 1.29 | | | Life Cycle Management | | | | Licensing | | | From 1d0f03aa7621a27ccb272e999207f4474c63afc8 Mon Sep 17 00:00:00 2001 From: KoryKessel-Mirantis Date: Tue, 11 Jun 2024 00:44:38 +0200 Subject: [PATCH 12/13] Format defintiion list in configuration.md using HTML. --- .../concepts/architecture/configuration.md | 30 +++++++------------ 1 file changed, 10 insertions(+), 20 deletions(-) diff --git a/content/docs/concepts/architecture/configuration.md b/content/docs/concepts/architecture/configuration.md index 2b20a08e..a0789412 100644 --- a/content/docs/concepts/architecture/configuration.md +++ b/content/docs/concepts/architecture/configuration.md @@ -61,32 +61,22 @@ blueprint that reflects your current MKE 4 configuration. 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. +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. -MKE 4 uses Blueprint Operator to manage blueprints and their assignments. - A blueprint comprises three sections: -**Kubernetes Provider** - -Details the settings for the provider. - -For the most part, the Kubernetes Provider section is managed by `mkectrl`, -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. +
+
Kubernetes Provider
+
Details the settings for the provider. For the most part, the Kubernetes Provider section is 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. From e981def82d4347d8bbb85ab9f67f01be9f779367 Mon Sep 17 00:00:00 2001 From: KoryKessel-Mirantis Date: Fri, 14 Jun 2024 12:42:26 +0200 Subject: [PATCH 13/13] Edits in response to comments from Nick Neisen, some deferral to post-initial release. --- .../concepts/architecture/architecture.md | 21 ++++++++++--------- .../concepts/architecture/configuration.md | 18 ++++++++++------ 2 files changed, 23 insertions(+), 16 deletions(-) diff --git a/content/docs/concepts/architecture/architecture.md b/content/docs/concepts/architecture/architecture.md index 5e145f24..ae36ff0f 100644 --- a/content/docs/concepts/architecture/architecture.md +++ b/content/docs/concepts/architecture/architecture.md @@ -2,7 +2,8 @@ Mirantis Kubernetes Engine (MKE) 4 is an enterprise-grade, production-ready Kubernetes platform that is designed to be secure, scalable, and reliable. -You deploy the software using an MKE configuration file. + +You can manage the entire MKE 4 cluster through the MKE configuration file. Refer to [Configuration and blueprints](configuration.md) for more information. ## Components @@ -11,23 +12,19 @@ MKE 4 is built on top of k0s, a lightweight Kubernetes distribution. Refer to the [official k0s documentation](https://docs.k0sproject.io/v1.29.3+k0s.0/) for more information. -### Control plane + -The MKE 4 control plane oversees crucial cluster-wide decisions, monitoring and -responding to events within the cluster. -While the control plane can function on any machine in the cluster, -setup scripts ensure maximum efficiency by running all control plane components -on one machine and by excluding user containers from that machine. + -### Container Network Interface +### Container Network Interface By default, Calico is installed as the Container Network Interface (CNI) plugin, with the following configuration: - IPv4 only, with a fixed Pod CIDR of `10.244.0.0/16`. - The datastore mode set to `kdd`. -- `kube-proxy` set to `iptables` mode. +- `kube-proxy` set to `iptables` mode. - A `vxlan` backend, which uses the default port of `4789` for traffic and default virtual network ID of `4096`. - + The MKE 4 Alpha.1 release has the following limitations: - The CNI plugin cannot be changed. @@ -47,3 +44,7 @@ The MKE 4 Alpha.1 release has the following limitations: + + + + diff --git a/content/docs/concepts/architecture/configuration.md b/content/docs/concepts/architecture/configuration.md index a0789412..c0432818 100644 --- a/content/docs/concepts/architecture/configuration.md +++ b/content/docs/concepts/architecture/configuration.md @@ -7,10 +7,11 @@ With the MKE configuration file, you can: - Define the number of nodes in the cluster. - Define ways to access the nodes. -- Enable or disable certain MKE 4 features. +- 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 +blueprint that contains the granular details on how to set up the cluster. ## Create configuration @@ -20,9 +21,9 @@ that contains the granular details on how to set up the cluster. mkectl init > mke.yaml ``` -2. Modify the generated file to deploy MKE on the cluster. -3. Modify the `hosts` section of the MKE configuration file, -to apply the configuration to a set of pre-existing machines: +2. Modify the `hosts` section of the MKE configuration file, to apply the + configuration to a set of pre-existing machines that you have set up in + advance: ```yaml hosts: @@ -84,3 +85,8 @@ To view a detailed blueprint of an MKE configuration, run the `mkectl init --blu > considered advanced and support by MKE 4 is not assured. + + + + +