diff --git a/docs/clustertemplates/aws/hosted-control-plane.md b/docs/clustertemplates/aws/hosted-control-plane.md index eb23adf..d4bb96d 100644 --- a/docs/clustertemplates/aws/hosted-control-plane.md +++ b/docs/clustertemplates/aws/hosted-control-plane.md @@ -1,14 +1,14 @@ # AWS Hosted control plane deployment -This section covers setting up for a K0smotron hosted control plane on AWS. +This section covers setting up for a k0smotron hosted control plane on AWS. ## Prerequisites - Management Kubernetes cluster (v1.28+) deployed on AWS with HMC installed on it - Default storage class configured on the management cluster -- VPC id for the worker nodes +- VPC ID for the worker nodes - Subnet ID which will be used along with AZ information -- AMI id which will be used to deploy worker nodes +- AMI ID which will be used to deploy worker nodes Keep in mind that all control plane components for all managed clusters will reside in the management cluster. @@ -31,30 +31,30 @@ and other provider controllers will need a large amount of resources to run. **VPC ID** ```bash - kubectl get awscluster -o go-template='{{.spec.network.vpc.id}}' + kubectl get awscluster -o go-template='{{.spec.network.vpc.id}}' ``` **Subnet ID** ```bash - kubectl get awscluster -o go-template='{{(index .spec.network.subnets 0).resourceID}}' + kubectl get awscluster -o go-template='{{(index .spec.network.subnets 0).resourceID}}' ``` **Availability zone** ```bash - kubectl get awscluster -o go-template='{{(index .spec.network.subnets 0).availabilityZone}}' + kubectl get awscluster -o go-template='{{(index .spec.network.subnets 0).availabilityZone}}' ``` **Security group** ```bash - kubectl get awscluster -o go-template='{{.status.networkStatus.securityGroups.node.id}}' + kubectl get awscluster -o go-template='{{.status.networkStatus.securityGroups.node.id}}' ``` **AMI id** ```bash - kubectl get awsmachinetemplate -worker-mt -o go-template='{{.spec.template.spec.ami.id}}' + kubectl get awsmachinetemplate -worker-mt -o go-template='{{.spec.template.spec.ami.id}}' ``` If you want to use different VPCs/regions for your management or managed diff --git a/docs/clustertemplates/aws/template-parameters.md b/docs/clustertemplates/aws/template-parameters.md index 85083fe..8ada696 100644 --- a/docs/clustertemplates/aws/template-parameters.md +++ b/docs/clustertemplates/aws/template-parameters.md @@ -2,7 +2,7 @@ ## AWS AMI -By default AMI id will be looked up automatically using the latest Amazon Linux 2 image. +By default AMI ID will be looked up automatically using the latest Amazon Linux 2 image. You can override lookup parameters to search your desired image automatically or use AMI ID directly. diff --git a/docs/clustertemplates/azure/hosted-control-plane.md b/docs/clustertemplates/azure/hosted-control-plane.md index 84995f4..5d6f5e6 100644 --- a/docs/clustertemplates/azure/hosted-control-plane.md +++ b/docs/clustertemplates/azure/hosted-control-plane.md @@ -22,43 +22,43 @@ If you deployed your Azure Kubernetes cluster using Cluster API Provider Azure **Location** ```bash -kubectl get azurecluster -o go-template='{{.spec.location}}' +kubectl get azurecluster -o go-template='{{.spec.location}}' ``` **Subscription ID** ```bash -kubectl get azurecluster -o go-template='{{.spec.subscriptionID}}' +kubectl get azurecluster -o go-template='{{.spec.subscriptionID}}' ``` **Resource group** ```bash -kubectl get azurecluster -o go-template='{{.spec.resourceGroup}}' +kubectl get azurecluster -o go-template='{{.spec.resourceGroup}}' ``` **vnet name** ```bash -kubectl get azurecluster -o go-template='{{.spec.networkSpec.vnet.name}}' +kubectl get azurecluster -o go-template='{{.spec.networkSpec.vnet.name}}' ``` **Subnet name** ```bash -kubectl get azurecluster -o go-template='{{(index .spec.networkSpec.subnets 1).name}}' +kubectl get azurecluster -o go-template='{{(index .spec.networkSpec.subnets 1).name}}' ``` **Route table name** ```bash -kubectl get azurecluster -o go-template='{{(index .spec.networkSpec.subnets 1).routeTable.name}}' +kubectl get azurecluster -o go-template='{{(index .spec.networkSpec.subnets 1).routeTable.name}}' ``` **Security group name** ```bash -kubectl get azurecluster -o go-template='{{(index .spec.networkSpec.subnets 1).securityGroup.name}}' +kubectl get azurecluster -o go-template='{{(index .spec.networkSpec.subnets 1).securityGroup.name}}' ``` @@ -112,7 +112,7 @@ spec: Then you can render it using the command: ```bash -kubectl get azurecluster -o go-template="$(cat template.yaml)" +kubectl get azurecluster -o go-template="$(cat template.yaml)" ``` ## Cluster creation @@ -124,7 +124,7 @@ the `AzureCluster` object due to current limitations (see To do so you need to execute the following command: ```bash -kubectl patch azurecluster --type=merge --subresource status --patch 'status: {ready: true}' +kubectl patch azurecluster --type=merge --subresource status --patch 'status: {ready: true}' ``` ## Important notes on the cluster deletion @@ -139,7 +139,7 @@ which will cause cluster deletion to stuck indefinitely. To place finalizer you can execute the following command: ```bash -kubectl patch azurecluster --type=merge --patch 'metadata: {finalizers: [manual]}' +kubectl patch azurecluster --type=merge --patch 'metadata: {finalizers: [manual]}' ``` When finalizer is placed you can remove the `ManagedCluster` as usual. Check that diff --git a/docs/clustertemplates/vsphere/hosted-control-plane.md b/docs/clustertemplates/vsphere/hosted-control-plane.md index 9bb2923..9c0a7ef 100644 --- a/docs/clustertemplates/vsphere/hosted-control-plane.md +++ b/docs/clustertemplates/vsphere/hosted-control-plane.md @@ -14,13 +14,12 @@ reside in the management cluster. Hosted CP template has mostly identical parameters with standalone CP, you can check them in the [template parameters](template-parameters.md) section. -> NOTE: **Important note on control plane endpoint IP** -> Since vSphere provider requires that user will provide control plane endpoint -> IP before deploying the cluster you should make sure that this IP will be the -> same that will be assigned to the k0smotron LB service. Thus you must provide -> control plane endpoint IP to the k0smotron service via annotation which is -> accepted by your LB provider (in the following example `kube-vip` annotation -> is used) +> NOTE: **Important Note on Control Plane Endpoint IP Address** +> The vSphere provider requires the control plane endpoint IP to be specified +> before deploying the cluster. Ensure that this IP matches the IP assigned to +> the k0smotron load balancer (LB) service. Provide the control plane endpoint +> IP to the k0smotron service via an annotation accepted by your LB provider +> (e.g., the `kube-vip` annotation in the example below). ```yaml apiVersion: hmc.mirantis.com/v1alpha1 diff --git a/docs/glossary.md b/docs/glossary.md index 5707fcc..6215f4d 100644 --- a/docs/glossary.md +++ b/docs/glossary.md @@ -11,10 +11,26 @@ controller, CNI, and/or CSI. While from the perspective of how they are deployed they are no different from other Kubernetes services, we define them as distinct from the apps and services deployed as part of the applications. +### Cluster API (CAPI) +CAPI is a Kubernetes project that provides a declarative way to manage the +lifecycle of Kubernetes clusters. It abstracts the underlying infrastructure, +allowing users to create, scale, upgrade, and delete clusters using a +consistent API. CAPI is extensible via providers that offer infrastructure- +specific functionality, such as AWS, Azure, and vSphere. + ### CAPI provider (see also [Infrastructure provider](#infrastructure-provider-see-also-capi-provider)) A CAPI provider is a Kubernetes CAPI extension that allows 2A to manage and drive the creation of clusters on a specific infrastructure via API calls. +### CAPA +CAPA stands for Cluster API Provider for AWS. + +### CAPV +CAPV stands for Cluster API Provider for vSphere. + +### CAPZ +CAPZ stands for Cluster API Provider for Azure. + ### Cloud Controller Manager Cloud Controller Manager (CCM) is a Kubernetes component that embeds logic to manage a specific infrastructure provider. @@ -30,6 +46,15 @@ references other CRs with infrastructure-specific credentials such as access keys, passwords, certificates, etc. This means that a credential is specific to the CAPI provider that uses it. +### Hosted Control Plane (HCP) +An HCP is a Kubernetes control plane that runs outside of the clusters it +manages. Instead of running the control plane components (like the API server, +controller manager, and etcd) within the same cluster as the worker nodes, the +control plane is hosted on a separate, often centralized, infrastructure. This +approach can provide benefits such as easier management, improved security, and +better resource utilization, as the control plane can be scaled independently +of the worker nodes. + ### Infrastructure provider (see also [CAPI provider](#capi-provider-see-also-infrastructure-provider)) An infrastructure provider (aka `InfrastructureProvider`) is a Kubernetes custom resource (CR) that defines the infrastructure-specific configuration needed for diff --git a/docs/template/byo-templates.md b/docs/template/byo-templates.md index cde6fab..d401a29 100644 --- a/docs/template/byo-templates.md +++ b/docs/template/byo-templates.md @@ -7,7 +7,7 @@ external Helm repository. Label it with `hmc.mirantis.com/managed: "true"`. 2. Create a [HelmChart](https://fluxcd.io/flux/components/source/helmcharts/) object referencing the `HelmRepository` as a `sourceRef`, specifying the name and version of your Helm chart. Label it with `hmc.mirantis.com/managed: "true"`. 3. Create a `ClusterTemplate`, `ServiceTemplate` or `ProviderTemplate` object referencing this helm chart in -`spec.helm.chartRef`. `chartRef` is a field of the +`.spec.helm.chartRef`. `chartRef` is a field of the [CrossNamespaceSourceReference](https://fluxcd.io/flux/components/helm/api/v2/#helm.toolkit.fluxcd.io/v2.CrossNamespaceSourceReference) kind. For `ClusterTemplate` and `ServiceTemplate` configure the namespace where this template should reside (`metadata.namespace`). @@ -75,7 +75,7 @@ spec: The `*Template` should follow the rules mentioned below: -`spec.providers` should contain the list of required Cluster API providers: `infrastructure`, `bootstrap` and +`.spec.providers` should contain the list of required Cluster API providers: `infrastructure`, `bootstrap` and `control-plane`. As an alternative, the referenced helm chart may contain the specific annotations in the `Chart.yaml` (value is a list of providers divided by comma). These fields are only used for validation. For example: @@ -153,7 +153,7 @@ Given compatibility attributes will be then set accordingly in the `.status` fie Compatibility contract versions are key-value pairs, where the key is **the name of the provider**, and the value is the provider contract version required to be supported by the provider. - Example with the `spec`: + Example with the `.spec`: ```yaml apiVersion: hmc.mirantis.com/v1alpha1 @@ -171,7 +171,7 @@ and the value is the provider contract version required to be supported by the p infrastructure-aws: v1beta2 ``` - Example with the `annotations` in the `Chart.yaml`: + Example with the `.annotations` in the `Chart.yaml`: ```yaml annotations: @@ -186,7 +186,7 @@ and the value is the provider contract version required to be supported by the p Kubernetes version to match against the related `ClusterTemplate` objects. Given compatibility values will be then set accordingly in the `.status` field. - Example with the `spec`: + Example with the `.spec`: ```yaml apiVersion: hmc.mirantis.com/v1alpha1 diff --git a/docs/template/main.md b/docs/template/main.md index 7c51e47..a690f74 100644 --- a/docs/template/main.md +++ b/docs/template/main.md @@ -23,7 +23,7 @@ and the upgrade sequences for them. The example of the Cluster Template Management: 1. Create `ClusterTemplateChain` object in the system namespace (defaults to `hmc-system`). Properly configure - the list of `availableUpgrades` for the specified `ClusterTemplate` if the upgrade is allowed. For example: + the list of `.spec.supportedTemplates[].availableUpgrades` for the specified `ClusterTemplate` if the upgrade is allowed. For example: ```yaml apiVersion: hmc.mirantis.com/v1alpha1 @@ -39,7 +39,7 @@ spec: - name: aws-standalone-cp-0-0-2 ``` -2. Edit `TemplateManagement` object and configure the `spec.accessRules`. +2. Edit `TemplateManagement` object and configure the `.spec.accessRules`. For example, to apply all templates and upgrade sequences defined in the `aws` `ClusterTemplateChain` to the `default` namespace, the following `accessRule` should be added: