Merge pull request #2488 from davidnuzik/channel-server

[K3s] Update docs to mention channel server for installs and upgrades

content/k3s/latest/en/installation/install-options/_index.md

@@ -29,14 +29,17 @@ When using this method to install K3s, the following environment variables can b
 |-----------------------------|---------------------------------------------|
 | `INSTALL_K3S_SKIP_DOWNLOAD` | If set to true will not download K3s hash or binary. |
 | `INSTALL_K3S_SYMLINK` | By default will create symlinks for the kubectl, crictl, and ctr binaries if the commands do not already exist in path. If set to 'skip' will not create symlinks and 'force' will overwrite. |
+| `INSTALL_K3S_SKIP_ENABLE` | If set to true will not enable or start K3s service. |
 | `INSTALL_K3S_SKIP_START` | If set to true will not start K3s service. |
-| `INSTALL_K3S_VERSION` | Version of K3s to download from Github. Will attempt to download the latest version if not specified. |
+| `INSTALL_K3S_VERSION` | Version of K3s to download from Github. Will attempt to download from the stable channel if not specified. |
 | `INSTALL_K3S_BIN_DIR` | Directory to install K3s binary, links, and uninstall script to, or use `/usr/local/bin` as the default. |
 | `INSTALL_K3S_BIN_DIR_READ_ONLY` | If set to true will not write files to `INSTALL_K3S_BIN_DIR`, forces setting `INSTALL_K3S_SKIP_DOWNLOAD=true`. |
 | `INSTALL_K3S_SYSTEMD_DIR` | Directory to install systemd service and environment files to, or use `/etc/systemd/system` as the default. |
 | `INSTALL_K3S_EXEC` | Command with flags to use for launching K3s in the service. If the command is not specified, and the `K3S_URL` is set, it will default to "agent." If `K3S_URL` not set, it will default to "server." For help, refer to [this example.]({{<baseurl>}}/k3s/latest/en/installation/install-options/how-to-flags/#example-b-install-k3s-exec) |
 | `INSTALL_K3S_NAME` | Name of systemd service to create, will default to 'k3s' if running k3s as a server and 'k3s-agent' if running k3s as an agent. If specified the name will be prefixed with 'k3s-'. |
 | `INSTALL_K3S_TYPE` | Type of systemd service to create, will default from the K3s exec command if not specified.
+| `INSTALL_K3S_CHANNEL_URL` | Channel URL for fetching K3s download URL. Defaults to https://update.k3s.io/v1-release/channels.
+| `INSTALL_K3S_CHANNEL` | Channel to use for fetching K3s download URL. Defaults to "stable". Options include: `stable`, `latest`, `testing`. |
 
 
 Environment variables which begin with `K3S_` will be preserved for the systemd and openrc services to use.
@@ -67,4 +70,4 @@ For details on configuring the K3s server, refer to the [server configuration re
 
 ### Registration Options for the K3s Agent
 
-For details on configuring the K3s agent, refer to the [agent configuration reference.]({{<baseurl>}}/k3s/latest/en/installation/install-options/agent-config)
+For details on configuring the K3s agent, refer to the [agent configuration reference.]({{<baseurl>}}/k3s/latest/en/installation/install-options/agent-config)

content/k3s/latest/en/upgrades/automated/_index.md

@@ -94,14 +94,14 @@ Third, the server-plan targets server nodes by specifying a label selector that
 
 Fourth, the `prepare` step in the agent-plan will cause upgrade jobs for that plan to wait for the server-plan to complete before they execute.
 
-Fifth, both plans have the `version` field set to v1.17.4+k3s1. Alternatively, you can omit the `version` field and set the `channel` field to a URL that resolves to a release of K3s. This will cause the controller to monitor that URL and upgrade the cluster any time it resolves to a new release. This is designed specifically to work with the [latest release functionality of GitHub](https://help.github.com/en/github/administering-a-repository/linking-to-releases). Thus, you can configure your plans with the following channel to ensure your cluster is always automatically upgraded to the latest release of K3s:
+Fifth, both plans have the `version` field set to v1.17.4+k3s1. Alternatively, you can omit the `version` field and set the `channel` field to a URL that resolves to a release of K3s. This will cause the controller to monitor that URL and upgrade the cluster any time it resolves to a new release. This works well with the [channel server](https://github.com/rancher/channelserver). Thus, you can configure your plans with the following channel to ensure your cluster is always automatically upgraded to the newest stable release of K3s:
 ```
 apiVersion: upgrade.cattle.io/v1
 kind: Plan
 ...
 spec:
   ...
-  channel: https://github.com/rancher/k3s/releases/latest
+  channel: https://update.k3s.io/v1-release/channels/stable
 
 ```
 

content/k3s/latest/en/upgrades/basic/_index.md

@@ -7,6 +7,10 @@ You can upgrade K3s by using the installation script, or by manually installing
 
 >**Note:** When upgrading, upgrade server nodes first one at a time, then any worker nodes.
 
+### About the Channel Server
+
+The [channel server](https://github.com/rancher/channelserver) allows the install script to install or upgrade K3s within specific channels such as `stable` (default), `latest`, or `testing`. For additional channels, see [https://update.k3s.io/v1-release/channels](https://update.k3s.io/v1-release/channels).
+
 ### Upgrade K3s Using the Installation Script
 
 To upgrade K3s from an older version you can re-run the installation script using the same flags, for example:
@@ -14,8 +18,14 @@ To upgrade K3s from an older version you can re-run the installation script usin
 ```sh
 curl -sfL https://get.k3s.io | sh -
 ```
+This will upgrade to a newer version in the stable channel by default.
 
-If you want to upgrade to specific version you can run the following command:
+If you want to upgrade to a newer version in a specific channel (such as latest) you can specify the channel:
+```sh
+curl -sfL https://get.k3s.io | INSTALL_K3S_CHANNEL=latest sh -
+```
+
+If you want to upgrade to a specific version you can run the following command:
 
 ```sh
 curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=vX.Y.Z-rc1 sh -