Related Projects Page (k3s-io#211)

* Added 'Related Projects' page

Daniel Lombardi <lombardi.daniel.o@gmail.com>

Signed-off-by: Daniel Lombardi <lombardi.daniel.o@gmail.com>

Author: LombardiDaniel

docs/datastore/ha-embedded.md

@@ -11,11 +11,15 @@ Embedded etcd (HA) may have performance issues on slower disks such as Raspberry
 HA embedded etcd cluster must be comprised of an odd number of server nodes for etcd to maintain quorum. For a cluster with n servers, quorum is (n/2)+1. For any odd-sized cluster, adding one node will always increase the number of nodes necessary for quorum. Although adding a node to an odd-sized cluster appears better since there are more machines, the fault tolerance is worse since exactly the same number of nodes may fail without losing quorum but there are more nodes that can fail.
 :::
 
+:::note
+To rapidly deploy large HA clusters, see [Related Projects](/related-projects)
+:::
+
 An HA K3s cluster with embedded etcd is composed of:
 
-* Three or more **server nodes** that will serve the Kubernetes API and run other control plane services, as well as host the embedded etcd datastore.
-* Optional: Zero or more **agent nodes** that are designated to run your apps and services
-* Optional: A **fixed registration address** for agent nodes to register with the cluster
+- Three or more **server nodes** that will serve the Kubernetes API and run other control plane services, as well as host the embedded etcd datastore.
+- Optional: Zero or more **agent nodes** that are designated to run your apps and services
+- Optional: A **fixed registration address** for agent nodes to register with the cluster
 
 To get started, first launch a server node with the `cluster-init` flag to enable clustering and a token that will be used as a shared secret to join additional servers to the cluster.
 
@@ -26,6 +30,7 @@ curl -sfL https://get.k3s.io | K3S_TOKEN=SECRET sh -s - server \
 ```
 
 After launching the first server, join the second and third servers to the cluster using the shared secret:
+
 ```bash
 curl -sfL https://get.k3s.io | K3S_TOKEN=SECRET sh -s - server \
     --server https://<ip or hostname of server1>:6443 \
@@ -48,11 +53,11 @@ Now you have a highly available control plane. Any successfully clustered server
 curl -sfL https://get.k3s.io | K3S_TOKEN=SECRET sh -s - agent --server https://<ip or hostname of server>:6443
 ```
 
-There are a few config flags that must be the same in all server nodes:         
+There are a few config flags that must be the same in all server nodes:
 
-* Network related flags: `--cluster-dns`, `--cluster-domain`, `--cluster-cidr`, `--service-cidr`
-* Flags controlling the deployment of certain components: `--disable-helm-controller`, `--disable-kube-proxy`, `--disable-network-policy` and any component passed to `--disable`
-* Feature related flags: `--secrets-encryption`
+- Network related flags: `--cluster-dns`, `--cluster-domain`, `--cluster-cidr`, `--service-cidr`
+- Flags controlling the deployment of certain components: `--disable-helm-controller`, `--disable-kube-proxy`, `--disable-network-policy` and any component passed to `--disable`
+- Feature related flags: `--secrets-encryption`
 
 ## Existing single-node clusters
 
@@ -63,4 +68,3 @@ Available as of [v1.22.2+k3s1](https://github.com/k3s-io/k3s/releases/tag/v1.22.
 If you have an existing cluster using the default embedded SQLite database, you can convert it to etcd by simply restarting your K3s server with the `--cluster-init` flag. Once you've done that, you'll be able to add additional instances as described above.
 
 If an etcd datastore is found on disk either because that node has either initialized or joined a cluster already, the datastore arguments (`--cluster-init`, `--server`, `--datastore-endpoint`, etc) are ignored.
-

docs/datastore/ha.md

@@ -5,12 +5,16 @@ weight: 30
 
 This section describes how to install a high-availability K3s cluster with an external database.
 
+:::note
+To rapidly deploy large HA clusters, see [Related Projects](/related-projects)
+:::
+
 Single server clusters can meet a variety of use cases, but for environments where uptime of the Kubernetes control plane is critical, you can run K3s in an HA configuration. An HA K3s cluster is composed of:
 
-* Two or more **server nodes** that will serve the Kubernetes API and run other control plane services
-* An **external datastore** (as opposed to the embedded SQLite datastore used in single-server setups)
-* Optional: Zero or more **agent nodes** that are designated to run your apps and services
-* Optional: A **fixed registration address** for agent nodes to register with the cluster
+- Two or more **server nodes** that will serve the Kubernetes API and run other control plane services
+- An **external datastore** (as opposed to the embedded SQLite datastore used in single-server setups)
+- Optional: Zero or more **agent nodes** that are designated to run your apps and services
+- Optional: A **fixed registration address** for agent nodes to register with the cluster
 
 For more details on how these components work together, refer to the [architecture section.](../architecture/architecture.md#high-availability-k3s)
 
@@ -19,9 +23,11 @@ For more details on how these components work together, refer to the [architectu
 Setting up an HA cluster requires the following steps:
 
 ### 1. Create an External Datastore
+
 You will first need to create an external datastore for the cluster. See the [Cluster Datastore Options](datastore.md) documentation for more details.
 
 ### 2. Launch Server Nodes
+
 K3s requires two or more server nodes for this HA configuration. See the [Requirements](../installation/requirements.md) guide for minimum machine requirements.
 
 When running the `k3s server` command on these nodes, you must set the `datastore-endpoint` parameter so that K3s knows how to connect to the external datastore. The `token` parameter can also be used to set a deterministic token when adding nodes. When empty, this token will be generated automatically for further use.
@@ -52,6 +58,7 @@ Once you've launched the `k3s server` process on all server nodes, ensure that t
 The same example command in Step 2 can be used to join additional server nodes, where the token from the first node needs to be used.
 
 If the first server node was started without the `--token` CLI flag or `K3S_TOKEN` variable, the token value can be retrieved from any server already joined to the cluster:
+
 ```bash
 cat /var/lib/rancher/k3s/server/token
 ```
@@ -66,26 +73,25 @@ curl -sfL https://get.k3s.io | sh -s - server \
 
 There are a few config flags that must be the same in all server nodes:
 
-* Network related flags: `--cluster-dns`, `--cluster-domain`, `--cluster-cidr`, `--service-cidr`
-* Flags controlling the deployment of certain components: `--disable-helm-controller`, `--disable-kube-proxy`, `--disable-network-policy` and any component passed to `--disable`
-* Feature related flags: `--secrets-encryption`
+- Network related flags: `--cluster-dns`, `--cluster-domain`, `--cluster-cidr`, `--service-cidr`
+- Flags controlling the deployment of certain components: `--disable-helm-controller`, `--disable-kube-proxy`, `--disable-network-policy` and any component passed to `--disable`
+- Feature related flags: `--secrets-encryption`
 
 :::note
 Ensure that you retain a copy of this token as it is required when restoring from backup and adding nodes. Previously, K3s did not enforce the use of a token when using external SQL datastores.
 :::
 
-
 ### 4. Optional: Configure a Fixed Registration Address
 
 Agent nodes need a URL to register against. This can be the IP or hostname of any server node, but in many cases those may change over time. For example, if running your cluster in a cloud that supports scaling groups, nodes may be created and destroyed over time, changing to different IPs from the initial set of server nodes. It would be best to have a stable endpoint in front of the server nodes that will not change over time. This endpoint can be set up using any number approaches, such as:
 
-* A layer-4 (TCP) load balancer
-* Round-robin DNS
-* Virtual or elastic IP addresses
+- A layer-4 (TCP) load balancer
+- Round-robin DNS
+- Virtual or elastic IP addresses
 
 See [Cluster Loadbalancer](./cluster-loadbalancer.md) for example configurations.
 
-This endpoint can also be used for accessing the Kubernetes API. So you can, for example, modify your [kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) file to point to it instead of a specific node. 
+This endpoint can also be used for accessing the Kubernetes API. So you can, for example, modify your [kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) file to point to it instead of a specific node.
 
 To avoid certificate errors in such a configuration, you should configure the server with the `--tls-san YOUR_IP_OR_HOSTNAME_HERE` option. This option adds an additional hostname or IP as a Subject Alternative Name in the TLS cert, and it can be specified multiple times if you would like to access via both the IP and the hostname.
 

docs/quick-start/quick-start.md

@@ -13,18 +13,19 @@ For information on how K3s components work together, refer to the [architecture
 New to Kubernetes? The official Kubernetes docs already have some great tutorials outlining the basics [here](https://kubernetes.io/docs/tutorials/kubernetes-basics/).
 :::
 
-Install Script
---------------
+## Install Script
+
 K3s provides an installation script that is a convenient way to install it as a service on systemd or openrc based systems. This script is available at https://get.k3s.io. To install K3s using this method, just run:
+
 ```bash
 curl -sfL https://get.k3s.io | sh -
 ```
 
 After running this installation:
 
-* The K3s service will be configured to automatically restart after node reboots or if the process crashes or is killed
-* Additional utilities will be installed, including `kubectl`, `crictl`, `ctr`, `k3s-killall.sh`, and `k3s-uninstall.sh`
-* A [kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) file will be written to `/etc/rancher/k3s/k3s.yaml` and the kubectl installed by K3s will automatically use it
+- The K3s service will be configured to automatically restart after node reboots or if the process crashes or is killed
+- Additional utilities will be installed, including `kubectl`, `crictl`, `ctr`, `k3s-killall.sh`, and `k3s-uninstall.sh`
+- A [kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) file will be written to `/etc/rancher/k3s/k3s.yaml` and the kubectl installed by K3s will automatically use it
 
 A single-node server installation is a fully-functional Kubernetes cluster, including all the datastore, control-plane, kubelet, and container runtime components necessary to host workload pods. It is not necessary to add additional server or agents nodes, but you may want to do so to add additional capacity or redundancy to your cluster.
 
@@ -33,6 +34,7 @@ To install additional agent nodes and add them to the cluster, run the installat
 ```bash
 curl -sfL https://get.k3s.io | K3S_URL=https://myserver:6443 K3S_TOKEN=mynodetoken sh -
 ```
+
 Setting the `K3S_URL` parameter causes the installer to configure K3s as an agent, instead of a server. The K3s agent will register with the K3s server listening at the supplied URL. The value to use for `K3S_TOKEN` is stored at `/var/lib/rancher/k3s/server/node-token` on your server node.
 
 :::note

docs/related-projects/related-projects.md

@@ -0,0 +1,16 @@
+---
+title: "Related Projects"
+weight: 10
+---
+
+Projects implementing the K3s distribution are welcome additions to help expand the community. This page will introduce you to a range of projects that are related to K3s and can help you further explore its capabilities and potential applications.
+
+These projects showcase the versatility and adaptability of K3s in various environments, as well as extensions of K3s.
+
+## Bootstrapping a Multi-Node K3s cluster via Ansible
+
+For users seeking to bootstrap a multi-node K3s cluster, we recommend the use of an Ansible script. This approach simplifies the process of setting up a K3s cluester by automating the installation and configuration of each node.
+
+For this, take a look at [k3s-io/k3s-ansible](https://github.com/k3s-io/k3s-ansible) repository. These scripts provides a convenient way to install K3s on your nodes, allowing you to focus on the configuration of your cluster rather than the installation process.
+
+This approach is particularly useful for creating a High Availability (HA) Kubernetes cluster, as it can be customized to suit the specific requirements of the cluster.