Operations with a classic cluster
In this article:
Operations with a classic cluster#
Attention
This section describes how to handle the previous version of Kubernetes clusters in К2 Cloud. This version does not support automatically scaled node groups and will not be developed further. We strongly recommend you to use EKS clusters when creating new Kubernetes clusters.
In the web interface of the service Kubernetes clusters you have the following actions:
Creating a cluster#
Creating a cluster can be divided into two parts: infrastructure creation and cluster installation. Currently, the infrastructure creation consists of creating the required number of instances of a given configuration from a prepared image. When the instances successfully start, the cluster installation process begins. Upon successful installation, the cluster gets the Ready status.
A cluster in the Ready status is considered ready for operation. Any other cluster status indicates that the cluster creation process has not been completed yet. Additional services are Ingress controller, Docker Registry, and EBS Provider. The process of creating a cluster involves creating instances, installing Kubernetes components on them, and (optionally) installing additional services. If your create a cluster with additional services, the Ready status indicates that they also have been installed successfully.
К2 Cloud facilitates the use of Kubernetes and enables you to deploy the entire infrastructure for the cluster in one click. To create a Kubernetes cluster, go to Kubernetes clusters Clusters, click on the down arrow beside the Create button and select Create cluster.
On the first step of creating a new cluster set the required parameters:
Name.
Version of Kubernetes that will be installed on all nodes.
VPC where the cluster will be created.
Option High Availability cluster. If you select this option, then a high availability cluster will be deployed. Its three nodes may be placed in three availability zones or a placement group within one availability zone. If any of these nodes fails, the cluster will continue to run on the remaining nodes.
The Certificate auto-renewal option. If you select this option, the certificates required for the Kubernetes cluster to run will be renewed automatically.
Pod subnet address. You can specify an IP address block in CIDR notation (X.X.X.X/Y), which will be allocated to the pod subnet. If you do not specify this parameter, a default range of IP addresses will be allocated.
Service subnet address. You can specify an IP address block in CIDR notation (X.X.X.X/Y), which will be allocated to the service subnet. If you do not specify this parameter, a default range of IP addresses will be allocated.
At the second step, set the network parameters required for the cluster operation:
Subnets where the cluster will be deployed.
SSH key for connecting to the cluster.
Security groups for controlling traffic via instance interfaces to a subnet.
The Allocate Elastic IP for API Server option. If you select this option, an Elastic IP will be allocated to a master node. This enables external access to the cluster’s API server.
At the third step, select a configuration of the master node, which will host service applications required for the cluster operation. This configuration will be applied to all master nodes if you select the High Availability cluster option. Specify the instance type and the volume type, size and IOPS (if available for the type you choose).
Note
Master node components are performance sensitive. We recommend using high performance volumes gp2: Universal (SSD), io2: Ultimate (SSD)
At the fourth step, specify a configuration of worker nodes, which will run user tasks. Specify the required number of worker nodes, instance type, and volume parameters: type, size and IOPS (if available for the type you choose). Selecting the Use placement groups option will create placement groups, in which instances with the cluster worker node will be then started.
At the fifth step, you can select additional services to be installed in the cluster:
Ingress Controller to route request. You can select the Associate Elastic IP with Ingress Сontroller option.
Docker Registry, for which you should set the volume configuration (type, size, IOPS ) to store your container images.
Note
If High-availability cluster is selected, then Docker Registry service cannot be installed.
EBS provider, in which you set the volume management user.
Note
To enable the EBS provider, EKSCSIPolicy (and only this policy) should be attached to at least one user in the project where the cluster is planned to be created.
NLB Provider, for which you need to select a K2 Cloud user account to connect the network load balancer. The NLB Provider automatically deploys the network load balancer in K2 Cloud when a load balancer is specified by Kubernetes (for details, see description of service). This allows you, among other things, to improve fault tolerance by distributing TCP traffic between the Kubernetes cluster pods. .. note:
To enable the NLB Provider, EKSNLBPolicy (and only this policy) should be attached to at least one user in the project where the cluster is planned to be created.
In the last step, you can specify user data to describe operations that will be automatically performed when the cluster nodes are created. User data is useful when you need, for example, to install packages, create and modify files, and execute shell scripts. To add user data, you need to specify the following information in the form:
User data type. Two user data types are currently supported: x-shellscript and cloud-config.
User data. If you have selected the x-shellscript type, enter your shell script to this field. If you have selected the cloud-config type, enter a configuration for cloud-config in YAML format to this field. For examples of operations that cloud-config allows and the corresponding configurations, please see the official cloud-init documentation.
The specified user data will be applied to all cluster nodes.
After completing the previous steps, click Create.
Note
The process of creating a new Kubernetes cluster can take from 5 to 15 minutes.
The Cluster-manager application will be installed in the cluster for proper monitoring functioning and for editing the count of worker nodes in cluster. Deleting it may cause the Kubernetes Clusters service incorrect work with the cluster.
To ensure correct cluster operation, a new security group is automatically created when a cluster is created. The following rules will be added to the group:
the rule to permit inbound traffic from interfaces that are in the same security group;
the rule to enable all outbound IPv4 traffic.
If the cluster is deleted, the security group will also be deleted.
Cluster node placement options#
If High-availability cluster option is selected, the following options to place cluster nodes are available:
Placement in three availability zones was selected, and the Use placement groups flag was set at the worker node configuration step. This combination of options guarantees that the nodes will be placed on different computing nodes in each availability zone.
Placement in three availability zones was selected, but the Use placement groups flag was not set at the worker node configuration step. In this combination, master nodes and worker nodes will be distributed across three availability zones. Still, it is not guaranteed that worker nodes will be distributed across different computing nodes within an availability zone.
Placement in one availability zone was selected, and the Use placement groups flag was set at the worker node configuration step. This combination guarantees that nodes will be placed on different computing nodes in an availability zone, though they will be distributed independently of each other. Therefore, a master node may be placed on the same computing node as a worker node.
Placement in one Availability Zone was selected, but the Use placement groups flag was not set at the worker node configuration step. In this combination, master nodes will be placed on different computing nodes in an availability zone. Still, it is not guaranteed that worker nodes will be distributed across different computing nodes within the availability zone.
Changing cluster parameters#
Change the number of worker nodes in the cluster#
You can change the number of worker nodes in the cluster, if necessary. To do this, go to the cluster page and edit the Number of worker nodes field in the Information tab. In the dialog window, you can specify the number of worker nodes to add or remove and change the instance type for the added nodes, if necessary. If you change the instance type, it will remain the same for existing worker nodes.
If you increase the number of worker nodes, a new instance is created, the required cluster components are installed on it, and the cluster is reconfigured to accommodate the new node. During this process, the cluster is in Not Ready state. After successful completion of this process, the cluster will go to the Ready state.
If you reduce the number of worker nodes, the nodes launched first are deleted first. The desired number of nodes is switched to the maintenance mode and then removed from the cluster using the Kubernetes API. After that, the released instances are deleted. During this process, the cluster is in Not Ready state. After the successful completion of this process, the cluster will go to the Ready state.
Note
To guarantee that a certain worker node is not deleted upon scaling, you can reduce the cluster size by selecting a specific node for deletion.
If the attempt to change the number of worker nodes fails, the cluster will continue to operate. A record with the failure details will be displayed on the Warnings tab.
Enable/disable certificate auto-renewal#
Kubernetes cluster uses PKI to securely exchange messages between its components. For the normal operation of the cluster, the certificates in use must be renewed in a timely manner.
The cluster-manager utility regularly checks the lifetime of certificates. If the remaining lifetime is less than two weeks, warnings are sent to the user.
You can renew certificates by yourself or enable the Certificate auto-renewal option. To enable or disable certificate auto-renewal on cluster master nodes, go to the cluster page and change the value of the Certificate auto-renewal field in the Information tab.
By default, certificate auto-renewal is available for all new clusters. If you have Kubernetes clusters where automatic renewal is not available (the Certificate auto-renewal field is not displayed), but you want to use this option, leave a request on the support portal or email at support@k2.cloud.
Attention
When certificate renewal is enabled, it is not recommended to renew them manually, since in case of an error, the cluster may fail.
When automatic renewal is disabled, you should monitor the certificate lifetime yourself and renew them when necessary.
Edit user data#
User data can be changed after the Kubernetes cluster has been created. In particular, this automatically executes new scripts when launching additional nodes to scale the cluster. User data can be edited in the Information tab on the cluster page. To do this, click the edit icon next to User data to edit parameters. In the dialog window, select the data type and enter the data.
Deleting resources#
Delete a worker node#
If a worker node is no longer needed (for example, you have transferred all its pods to another node) then it can be deleted. You can delete a worker node only when a Kubernetes cluster has the “Running” status and is in the “Ready” state.
Note
A worker node cannot be deleted if the “Scheduling disabled” option is enabled for all other worker nodes.
Attention
Before deleting a worker node, make sure that there are no pods to which Persistent Volumes are binded. Deleting a worker node with such volumes may render applications that use them temporarily unavailable. Recovery can take up to 10 minutes until the Kubernetes service mounts the volumes on another worker node.
To delete a worker node:
Go to Kubernetes Clusters Clusters.
Find the cluster in the table and click the cluster ID to go to its page.
Open the Instances tab.
Select the instance where the worker node is deployed, in the resource table.
Click Delete and confirm the action in the dialog window.
Deleting a Kubernetes cluster#
Deleting a cluster is deleting all instances, created for it. Instances, created for additional services are also deleting. Volumes created by EBS-provider will be available for deletion in the Volumes subsection of the Storage section.
To delete a Kubernetes cluster and related services (Container Registry, EBS-provider), go to Kubernetes clusters Clusters, select the cluster and click Delete.
Attention
When you delete a cluster, the volume with the Docker Registry images will also be deleted!