Merge pull request #1353 from salasberryfin/improve-book-structure

Improve book structure and add clusterclass examples

Author: k8s-ci-robot

docs/book/src/SUMMARY.md

@@ -1,18 +1,24 @@
 # Summary
 
 [Introduction](./introduction.md)
-- [Getting Started](./getting-started.md)
-- [Topics](./topics/index.md)
-    - [Prerequisites](./topics/prerequisites.md)
+- [Quick Start](./quick-start.md)
+- [Prerequisites](./prerequisites.md)
+- [Self-managed clusters](./self-managed/index.md)
+    - [Provisioning a Cluster](./self-managed/provision.md)
+    - [CNI](./self-managed/cni.md)
+- [Managed clusters - GKE](./managed/index.md)
+    - [Provisioning a Cluster](./managed/provision.md)
+    - [Cluster Upgrades](./managed/upgrades.md)
+    - [Enabling](./managed/enabling.md)
+    - [Disabling](./managed/disabling.md)
+- [ClusterClass](./clusterclass/index.md)
+    - [Provisioning a Cluster](./clusterclass/provision.md)
+    - [Enabling](./clusterclass/enabling.md)
+    - [Disabling](./clusterclass/disabling.md)
+- [General Topics](./topics/index.md)
     - [Conformance](./topics/conformance.md)
-    - [GKE Support](./topics/gke/index.md)
-        - [Creating a Cluster](./topics/gke/creating-a-cluster.md)
-        - [Cluster Upgrades](./topics/gke/cluster-upgrades.md)
-        - [Enabling](./topics/gke/enabling.md)
-        - [Disabling](./topics/gke/disabling.md)
     - [Machine Locations](./topics/machine-locations.md)
     - [Preemptible VMs](./topics/preemptible-vms.md)
-    - [Flannel](./topics/flannel.md)
 - [Developer Guide](./developers/index.md)
     - [Development](./developers/development.md)
     - [Try unreleased changes with Nightly Builds](./developers/nightlies.md)

docs/book/src/clusterclass/disabling.md

@@ -0,0 +1,3 @@
+# Disabling ClusterClass Support
+
+Support for ClusterClass is disabled by default when you use the GCP infrastructure provider.

docs/book/src/clusterclass/enabling.md

@@ -0,0 +1,8 @@
+# Enabling ClusterClass Support
+
+Enabling ClusterClass support is done via the **ClusterTopology** feature flag by setting it to true. This can be done before running `clusterctl init` by using the **CLUSTER_TOPOLOGY** environment variable:
+
+```shell
+export CLUSTER_TOPOLOGY=true
+clusterctl init --infrastructure gcp
+```

docs/book/src/clusterclass/index.md

@@ -0,0 +1,16 @@
+# ClusterClass
+
+- **Feature status:** Experimental
+- **Feature gate:** `ClusterTopology=true`
+
+[ClusterClass](https://cluster-api.sigs.k8s.io/tasks/experimental-features/cluster-class/index.html) is a collection of templates that define a topology (control plane and machine deployments) to be used to continuously reconcile one or more Clusters. It is built on top of the existing Cluster API resources and provides a set of tools and operations to streamline cluster lifecycle management while maintaining the same underlying API.
+
+<aside class="note warning">
+
+<h1>Warning</h1>
+
+ClusterClass is an experimental core CAPI feature and, as such, it may behave unreliably until promoted to the main repository. It is expected to be graduated with the release of [CAPI v1.9](https://github.com/kubernetes-sigs/cluster-api/milestone/38).
+
+</aside>
+
+CAPG supports the creation of clusters via Cluster Topology for **self-managed clusters only**.

docs/book/src/clusterclass/provision.md

@@ -0,0 +1,87 @@
+# Provisioning a Cluster via ClusterClass
+
+<aside class="note warning">
+
+<h1>Warning</h1>
+
+We recommend you take a look at the [Prerequisites](./../prerequisites.md) section before provisioning a workload cluster. 
+
+**You should be familiar with the ClusterClass feature and its core concepts: [CAPI book on ClusterClass and Managed Topologies](https://cluster-api.sigs.k8s.io/tasks/experimental-features/cluster-class/write-clusterclass).**
+
+</aside>
+
+
+**This guide uses an example from the `./templates` folder of the CAPG repository. You can inspect the yaml file for the `ClusterClass` [here](https://raw.githubusercontent.com/kubernetes-sigs/cluster-api-provider-gcp/refs/heads/main/templates/cluster-template-clusterclass.yaml) and the cluster definition [here](https://raw.githubusercontent.com/kubernetes-sigs/cluster-api-provider-gcp/refs/heads/main/templates/cluster-template-topology.yaml).**
+
+
+## Templates and clusters
+
+ClusterClass makes cluster templates more flexible and versatile as it allows users to create cluster flavors that can be reused for cluster provisioning.
+
+In this case, while inspecting the sample files, you probably noticed that there are references to two different yaml:
+- `./templates/cluster-template-clusterclass.yaml` is the class definition. It represents the template that define a topology: control plane and machine deployment but it won't provision the cluster.
+- `./templates/cluster-template-topology.yaml` is the cluster definition that references the class. This workload cluster definition is considerably simpler than a regular CAPI cluster template that does not use ClusterClass, as most of the complexity of defining the control plane and machine deployment has been removed by the class.
+
+## Configure ClusterClass
+
+While inspecting the templates you probably noticed that they contain a number of parameterized values that must be substituted with the specifics of your use case. This can be done via environment variables and `clusterctl` and effectively make the templates more flexible to adapt to different provisioning scenarios. These are the environment variables that you'll be required to set before deploying a class and a workload cluster from it:
+
+```sh
+export CLUSTER_CLASS_NAME=sample-cc
+export GCP_PROJECT=cluster-api-gcp-project
+export GCP_REGION=us-east4
+export GCP_NETWORK_NAME=default
+export IMAGE_ID=projects/cluster-api-gcp-project/global/images/your-image
+```
+
+## Generate ClusterClass definition
+
+The sample ClusterClass template is already prepared so that you can use it with `clusterctl` to create a CAPI ClusterClass with CAPG.
+
+```bash
+clusterctl generate cluster capi-gcp-quickstart-clusterclass --flavor clusterclass -i gcp > capi-gcp-quickstart-clusterclass.yaml
+```
+
+In this example, `capi-gcp-quickstart-clusterclass` will be used as class name.
+
+## Create ClusterClass
+
+The resulting file represents the class template definition and you simply need to apply it to your cluster to make it available in the API:
+
+```
+kubectl apply -f capi-gcp-quickstart-clusterclass.yaml
+```
+
+## Create a cluster from a class
+
+ClusterClass is a powerful feature of CAPI because we can now create one or multiple clusters that are based on the same class that is available in the CAPI Management Cluster. This base template can be parameterized so clusters created from it can make slight changes to the original configuration and adapt to the specifics of the use case, e.g. provisioning clusters for different development, staging and production environments.
+
+Now that the class is available to be referenced by cluster objects, let's configure the workload cluster and provision it.
+
+```sh
+export CLUSTER_NAME=sample-cluster
+export CLUSTER_CLASS_NAME=sample-cc
+export KUBERNETES_VERSION=1.29.3
+export CONTROL_PLANE_MACHINE_COUNT=1
+export WORKER_MACHINE_COUNT=1
+export GCP_REGION=us-east4
+export GCP_CONTROL_PLANE_MACHINE_TYPE=n1-standard-2
+export GCP_NODE_MACHINE_TYPE=n1-standard-2
+export CNI_RESOURCES=./cni-resource
+```
+
+You can take a look at CAPG's CNI requirements [here](./../self-managed/cni.md)
+
+You can use `clusterctl` to create a cluster definition.
+
+```bash
+clusterctl generate cluster capi-gcp-quickstart-topology --flavor topology -i gcp > capi-gcp-quickstart-topology.yaml
+```
+
+And by simply applying the resulting template, the cluster will be provisioned based on the existing ClusterClass.
+
+```
+kubectl apply -f capi-gcp-quickstart-topology.yaml
+```
+
+You can now experiment with creating more clusters based on this class while applying different configurations to each workload cluster.

docs/book/src/getting-started.md

@@ -3,6 +3,14 @@
 - **Feature status:** Experimental
 - **Feature gate (required):** GKE=true
 
+<aside class="note warning">
+
+<h1>Warning</h1>
+
+Provisioning managed clusters (GKE) is an experimental feature and, as such, it may behave unreliably until promoted to the main repository.
+
+</aside>
+
 ## Overview
 
 The GCP provider supports creating GKE based cluster. Currently the following features are supported:
@@ -24,4 +32,4 @@ And a new template is available in the templates folder for creating a managed w
 * [Enabling GKE Support](enabling.md)
 * [Disabling GKE Support](disabling.md)
 * [Creating a cluster](creating-a-cluster.md)
-* [Cluster Upgrades](cluster-upgrades.md)
+* [Cluster Upgrades](cluster-upgrades.md)

docs/book/src/topics/gke/disabling.md renamed to docs/book/src/managed/disabling.md

@@ -0,0 +1,64 @@
+# Provisioning a GKE cluster
+
+<aside class="note warning">
+
+<h1>Warning</h1>
+
+We recommend you take a look at the [Prerequisites](./../prerequisites.md) section before provisioning a workload cluster. 
+
+</aside>
+
+**This guide uses an example from the `./templates` folder of the CAPG repository. You can inspect the yaml file [here](https://raw.githubusercontent.com/kubernetes-sigs/cluster-api-provider-gcp/refs/heads/main/templates/cluster-template-gke.yaml).**
+
+## Configure cluster parameters
+
+While inspecting the cluster definition in `./templates/cluster-template-gke.yaml` you probably noticed that it contains a number of parameterized values that must be substituted with the specifics of your use case. This can be done via environment variables and `clusterctl` and effectively makes the template more flexible to adapt to different provisioning scenarios. These are the environment variables that you'll be required to set before deploying a workload cluster:
+
+```sh
+export GCP_PROJECT=cluster-api-gcp-project
+export GCP_REGION=us-east4
+export GCP_NETWORK_NAME=default
+export WORKER_MACHINE_COUNT=1
+```
+
+## Generate cluster definition
+
+The sample cluster templates are already prepared so that you can use them with `clusterctl` to create a GKE cluster with CAPG.
+
+To create a GKE cluster with a managed node group (a.k.a managed machine pool):
+
+```bash
+clusterctl generate cluster capi-gke-quickstart --flavor gke -i gcp > capi-gke-quickstart.yaml
+```
+
+In this example, `capi-gke-quickstart` will be used as cluster name.
+
+## Create cluster
+
+The resulting file represents the workload cluster definition and you simply need to apply it to your cluster to trigger cluster creation:
+
+```
+kubectl apply -f capi-gke-quickstart.yaml
+```
+
+## Kubeconfig
+
+When creating an GKE cluster 2 kubeconfigs are generated and stored as secrets in the management cluster.
+
+### User kubeconfig
+
+This should be used by users that want to connect to the newly created GKE cluster. The name of the secret that contains the kubeconfig will be `[cluster-name]-user-kubeconfig` where you need to replace **[cluster-name]** with the name of your cluster. The **-user-kubeconfig** in the name indicates that the kubeconfig is for the user use.
+
+To get the user kubeconfig for a cluster named `managed-test` you can run a command similar to:
+
+```bash
+kubectl --namespace=default get secret managed-test-user-kubeconfig \
+   -o jsonpath={.data.value} | base64 --decode \
+   > managed-test.kubeconfig
+```
+
+### Cluster API (CAPI) kubeconfig
+
+This kubeconfig is used internally by CAPI and shouldn't be used outside of the management server. It is used by CAPI to perform operations, such as draining a node. The name of the secret that contains the kubeconfig will be `[cluster-name]-kubeconfig` where you need to replace **[cluster-name]** with the name of your cluster. Note that there is NO `-user` in the name.
+
+The kubeconfig is regenerated every `sync-period` as the token that is embedded in the kubeconfig is only valid for a short period of time.