-
Notifications
You must be signed in to change notification settings - Fork 115
CKS Enhancements docs #458
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
@@ -15,7 +15,10 @@ CloudStack Kubernetes Service | |||
|
|||
The Kubernetes Service plugin adds Kubernetes integration to CloudStack. The plugin is disabled by default and an admin can enable it using a Global Setting. It enables users to run containerized services using Kubernetes clusters. | |||
|
|||
With CoreOS having reached EOL, from 4.16 the Kubernetes Service Plugin will use the existing SystemVM Template for deploying kubernetes clusters. For installation of Kubernetes binaries on the cluster nodes, a binaries ISO is used for each Kubernetes version to be made available via CloudStack. This allows faster, offline installation of Kubernetes binaries and docker images along with support for adding multiple versions of Kubernetes for upgrades and running different clusters. | |||
With CoreOS having reached EOL, from 4.16 the Kubernetes Service Plugin will use the existing SystemVM Template by default for deploying kubernetes clusters. For installation of Kubernetes binaries on the cluster nodes, a binaries ISO is used for each Kubernetes version to be made available via CloudStack. This allows faster, offline installation of Kubernetes binaries and docker images along with support for adding multiple versions of Kubernetes for upgrades and running different clusters. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With CoreOS having reached EOL, from 4.16 the Kubernetes Service Plugin will use the existing SystemVM Template by default for deploying kubernetes clusters. For installation of Kubernetes binaries on the cluster nodes, a binaries ISO is used for each Kubernetes version to be made available via CloudStack. This allows faster, offline installation of Kubernetes binaries and docker images along with support for adding multiple versions of Kubernetes for upgrades and running different clusters. | |
With CoreOS having reached EOL, from 4.16 on the Kubernetes Service Plugin will use | |
the existing SystemVM Template by default for deploying kubernetes clusters. For | |
installation of Kubernetes binaries on the cluster nodes, a binaries ISO is used for each | |
Kubernetes version to be made available via CloudStack. This allows faster, offline | |
installation of Kubernetes binaries and docker images along with support for adding | |
multiple versions of Kubernetes for upgrades and running different clusters. |
With CoreOS having reached EOL, from 4.16 the Kubernetes Service Plugin will use the existing SystemVM Template by default for deploying kubernetes clusters. For installation of Kubernetes binaries on the cluster nodes, a binaries ISO is used for each Kubernetes version to be made available via CloudStack. This allows faster, offline installation of Kubernetes binaries and docker images along with support for adding multiple versions of Kubernetes for upgrades and running different clusters. | ||
|
||
.. note:: | ||
Since version 4.21.0 users can choose different templates for different types of nodes (worker, control, etcd nodes) for deploying Kubernetes clusters. These templates must be previously registered selecting the 'For CKS' option. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since version 4.21.0 users can choose different templates for different types of nodes (worker, control, etcd nodes) for deploying Kubernetes clusters. These templates must be previously registered selecting the 'For CKS' option. | |
Since version 4.21.0 users can choose different templates for different types of nodes | |
(worker, control, etcd nodes) for deploying Kubernetes clusters. These templates must | |
be previously registered selecting the 'For CKS' option. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @DaanHoogland I see most of the suggested changes are splitting the single line into multiple lines. Is this a problem on having them as single lines?
@blueorangutan docbuild |
@nvazquez a Jenkins job has been kicked to build the document. I'll keep you posted as I make progress. |
QA-Doc build preview: https://qa.cloudstack.cloud/builds/docs-build/pr/458. (QA-JID 349) |
With CoreOS having reached EOL, from 4.16 the Kubernetes Service Plugin will use the existing SystemVM Template by default for deploying kubernetes clusters. For installation of Kubernetes binaries on the cluster nodes, a binaries ISO is used for each Kubernetes version to be made available via CloudStack. This allows faster, offline installation of Kubernetes binaries and docker images along with support for adding multiple versions of Kubernetes for upgrades and running different clusters. | ||
|
||
.. note:: | ||
Since version 4.21.0 users can choose different templates and service offerings for different types of nodes (worker, control, etcd nodes) for deploying Kubernetes clusters. The templates must be previously registered selecting the 'For CKS' option. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since version 4.21.0 users can choose different templates and service offerings for different types of nodes (worker, control, etcd nodes) for deploying Kubernetes clusters. The templates must be previously registered selecting the 'For CKS' option. | |
From version 4.21.0, users can choose different templates and service offerings for different types of nodes (worker, control, etcd nodes) for deploying Kubernetes clusters. The templates must be previously registered selecting the 'For CKS' option. |
@@ -82,6 +88,17 @@ Eg: | |||
**NOTE:** | |||
From ACS 4.16 onwards, Kubernetes versions >= 1.20.x are only supported (https://endoflife.date/kubernetes). | |||
|
|||
**NOTE:** | |||
From ACS 4.21 onwards, it is possible specify the version for etcd binaries on the create-kubernetes-binaries-iso.sh script as an optional parameter ETCD_VERSION. When the ETCD_VERSION parameter is set, the specified etcd version binaries are downloaded and stored on the /etcd directory on the Kubernetes ISO. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From ACS 4.21 onwards, it is possible specify the version for etcd binaries on the create-kubernetes-binaries-iso.sh script as an optional parameter ETCD_VERSION. When the ETCD_VERSION parameter is set, the specified etcd version binaries are downloaded and stored on the /etcd directory on the Kubernetes ISO. | |
From ACS 4.21 onwards, it is possible to specify the version for etcd binaries in the create-kubernetes-binaries-iso.sh script as an optional parameter - ETCD_VERSION. When the ETCD_VERSION parameter is set, the specified etcd version binaries are downloaded and stored in the Kubernetes ISO. |
|
||
# ./create-kubernetes-binaries-iso.sh ./ 1.27.2 1.3.0 1.27.0 https://raw.githubusercontent.com/weaveworks/weave/master/prog/weave-kube/weave-daemonset-k8s-1.11.yaml https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml setup-v1.27.2 3.5.1 | ||
|
||
The Kubernetes ISOs generated with an specific etcd version are required to create separate etcd nodes on Kubernetes clusters. See :ref:`flexible-kubernetes-clusters`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Kubernetes ISOs generated with an specific etcd version are required to create separate etcd nodes on Kubernetes clusters. See :ref:`flexible-kubernetes-clusters`. | |
To deploy Kubernetes clusters with | |
Kubernetes ISOs built with a specified etcd version are necessary for creating Kubernetes clusters with separate etcd nodes. See :ref:`flexible-kubernetes-clusters`. |
@@ -92,6 +109,10 @@ Once the ISO has been built for a desired Kubernetes version, it can be added by | |||
|
|||
|cks-add-version-form.png| | |||
|
|||
.. note:: | |||
Since 4.21.0 it is possible to deploy separate dedicated etcd nodes. This requires |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since 4.21.0 it is possible to deploy separate dedicated etcd nodes. This requires | |
From 4.21.0, it is possible to deploy separate dedicated etcd nodes. This requires |
@@ -194,6 +215,17 @@ New Kubernetes clusters can be created using the API or via the UI. User will be | |||
|
|||
|cks-create-cluster-form.png| | |||
|
|||
Since 4.21.0, the Hypervisor selection is available for Kubernetes Cluster nodes. By default the Hypervisor selection is empty. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since 4.21.0, the Hypervisor selection is available for Kubernetes Cluster nodes. By default the Hypervisor selection is empty. | |
From 4.21.0, you can select the hypervisor type for Kubernetes cluster nodes. By default, no hypervisor is selected. |
|
||
- The Management Server’s SSH Public key must be added at the cloud user’s authorized_keys file at `~/.ssh/authorized_keys`. | ||
|
||
The VM Instances meeting the requirements above must be added to the Kubernetes cluster by the `addNodesToKubernetesCluster` API specifying: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The VM Instances meeting the requirements above must be added to the Kubernetes cluster by the `addNodesToKubernetesCluster` API specifying: | |
The VM Instances meeting the requirements above can be added to the Kubernetes cluster by the `addNodesToKubernetesCluster` API specifying: |
- **manualupgrade** (optional parameter that indicates if the node is marked for manual upgrade and excluded from the Kubernetes cluster upgrade operation) | ||
|
||
.. note:: | ||
Users are able to add nodes to Kubernetes cluster and mark them for manual upgrade only. Once the nodes are marked for manual upgrade, the future cluster upgrade operations will exclude these nodes and their Kubernetes version won't be upgraded. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Users are able to add nodes to Kubernetes cluster and mark them for manual upgrade only. Once the nodes are marked for manual upgrade, the future cluster upgrade operations will exclude these nodes and their Kubernetes version won't be upgraded. | |
Users will have the ability to add nodes to the Kubernetes cluster and mark them for manual upgrade. Once the nodes are marked for manual upgrade, the future cluster upgrade operations will exclude these nodes i.e., the Kubernetes version won't be upgraded. |
|
||
- Addition of port-forwarding rules and firewall rules (for isolated networks) | ||
|
||
- VM is rebooted with the Kubernetes config passed as userdata |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- VM is rebooted with the Kubernetes config passed as userdata | |
- VM is rebooted with the Kubernetes configuration passed as userdata |
Removing an external worker node from a Kubernetes cluster | ||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
|
||
External worker nodes must be removed from a Kubernetes cluster by the `removeNodesFromKubernetesCluster` API specifying: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
External worker nodes must be removed from a Kubernetes cluster by the `removeNodesFromKubernetesCluster` API specifying: | |
External worker nodes can be removed from a Kubernetes cluster by the `removeNodesFromKubernetesCluster` API specifying: |
Dedicate specific hosts/clusters to a specific domain for CKS cluster deployment | ||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
|
||
Administratos are able to dedicate hosts to a domain or account. CloudStack will take the host dedication in consideration when deploying Kubernetes clusters. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Administratos are able to dedicate hosts to a domain or account. CloudStack will take the host dedication in consideration when deploying Kubernetes clusters. | |
Administrators are able to dedicate hosts to a domain or account. CloudStack will take the host dedication into consideration when deploying Kubernetes clusters. |
@nvazquez Should we add some images for:
|
Yes, screenshots about registering cni userdata would be helpful also sample kubectl commands to verify
|
@nvazquez also can we update one test iso which has external etcd https://download.cloudstack.org/testing/custom_templates/ubuntu/22.04/ |
Docs for PR: apache/cloudstack#9102
📚 Documentation preview 📚: https://cloudstack-documentation--458.org.readthedocs.build/en/458/