EKS cluster operations
In this article:
EKS cluster operations#
EKS clusters allow you to create node groups that are scaled up or down automatically to meet changing workload. One EKS cluster can have multiple node groups, each with its specific parameters and scaling policies. These clusters also have AWS-compatible API, so that standard AWS CLI and boto3 utility are enough to manage them.
Usage specifics#
When using EKS clusters, mind the following restrictions and operation aspects:
A node group cannot be assigned other security groups once it is created. Therefore, when you change the cluster security groups, only the security groups of master nodes and Ingress controllers are changed.
Changing the minimum and maximum capacities and other parameters of an Auto Scaling group directly in the corresponding section or changing the launch template or its version will make the node group inoperable (its state will change to Degraded). The only way to restore it is to contact the support service.
Deploying additional worker nodes when scaling a group takes time. If the alarm threshold is too high, the EKS cluster may become overloaded, as the worker nodes being created may not be ready yet when the critical load is reached.
The recommended alarm threshold for a scaling policy is 50-60% of the average node group CPU utilization. This will allow a smoother node scaling in the group during higher load.
You cannot disable automatic certificate updates for EKS clusters, so they will always be enabled by default.
The EKS cluster will continue to operate even if a worker node in any of its node groups is not deployed correctly. In this case, the cluster will remain Unready until the corresponding instance is deleted or restarted manually.
If user data was specified when a cluster was created, such data will be used when all cluster nodes and node groups are launched.
The size of the created volume must be a multiple of 8 GB, otherwise it will be increased to the nearest multiple.
EKS cluster management#
Create an EKS cluster#
The cluster creation process can be divided into three phases: infrastructure preparation, cluster installation, and node group creation. Infrastructure preparation consists of launching the required number of instances with the specified configuration from a given image. When instances are successfully launched, the cluster installation process starts. When the installation is successfully completed, the cluster state changes to Running. Now you can add a node group to the cluster.
A cluster in the Running state is considered ready for operation. Any other cluster state indicates that either the cluster creation process has not been completed yet, or automatic recovery is in progress (in case of a High Availability cluster with a failed master node). The cluster creation includes creation of instances, installation of Kubernetes components, and optional installation of additional services. Such services include Ingress controller, Docker Registry, and EBS provider. If you create a cluster with additional services, the Running state also indicates that these services have been successfully installed.
К2 Cloud makes using Kubernetes easier and allows you to deploy the entire cluster management infrastructure in just a click. To create an EKS cluster, go to Kubernetes clusters Clusters and click Create, or click the down arrow next to the button and select Create EKS cluster.
At the Parameters step, set the parameters as follows:
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 of three master nodes will be deployed. The nodes may be placed in three availability zones or in a placement group within one availability zone. To do so, select a respective option (Three Availability Zones or One Availability Zone). If any of these nodes fails, the cluster will continue running on the remaining nodes.
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* Network* step, set the network parameters required for the cluster to operate:
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 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 Master node 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 Services step, you can select additional services to be installed in the cluster:
Ingress controller for request routing. For this service, you can select Elastic IP, specify the instance type on which it can be installed, and select volume parameters (type, size, IOPS).
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 manage the load balancer. The NLB Provider automatically deploys the network load balancer in K2 Cloud if a load balancer is specified in Kubernetes (for details, see service description). This allows you, among other things, to improve fault tolerance by distributing TCP traffic among 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.
At the User data 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.
At the Tags step, you can set the keys and tag values to be assigned to the master nodes of the Kubernetes cluster .
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 are 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.
Get settings for connecting to the cluster#
To download the settings needed for configuring kubectl:
Go to Kubernetes Clusters Clusters.
In the resource table, find the cluster to which access should be configured and click on the cluster name to go to its page.
In the Information tab, click Get settings and save the settings.
Assign tags to an EKS cluster#
To add, modify or delete EKS cluster tags:
Go to Kubernetes Clusters Clusters.
In the resource table, find the cluster for which tags should be edited and click on the cluster name to go to its page.
Open the Tags tab.
To add a tag, click Add tag and specify the Key and Value fields.
To modify a tag, edit the required fields (Value and/or Key) of the respective tag.
To delete a tag, click the icon next to the tag you no longer need.
Note
If no tags have been set earlier, you can add the Name tag by clicking Add Name tag and specifying its value.
Note
You can also modify the Name tag in the Information tab by editing the corresponding field.
Click Apply to save the changes.
Deleting a cluster#
Attention
Deleting the cluster will also delete all the node groups related to it and instances with volumes that are part of these groups.
Go to Kubernetes clusters Clusters and select an EKS cluster to be deleted.
Click Delete.
In the dialog window, confirm the action.
Managed node groups#
Node groups use the Auto Scaling service. You can create both static and dynamic node groups. In case of scalable node groups, the number of nodes in a group changes depending on the specified scaling policy.
Along with a node group, a launch template is created. It is used to create new instances in the group. The template contains the instance and volume parameters that you specified for the node group when it was created. The launch template for a node group can be viewed in the Virtual machines Compute Launch templates section: its name is nodegroup-<UUID> and the template description contains the group name.
Note
The launch template parameters cannot be changed, otherwise the node group will become inoperable.
Create a node group#
Note
A node group can only be added when the EKS cluster is in the Running state.
To create a node group:
Go to Kubernetes clusters Clusters, select the EKS cluster for which you want to create a node group, and click on the cluster name to go to its page.
Open the Node groups tab and click Create.
Set the parameters for a worker node:
Node group name.
Type of the instance on which the worker node will be deployed.
Worker node volume size.
The subnets where the instances will be deployed. To distribute nodes across different availability zones in the case of a High Availability cluster, you can specify subnets in each zone. Only subnets you specified when creating the cluster are available for selection.
Note
If automatic association is enabled for Elastic IPs in the selected subnet, then an available allocated Elastic IP address will be automatically associated with the instance when it is created in that subnet.
SSH key to access the instance.
Click Next to proceed to the next step.
Set the worker node scaling parameters:
Minimum group capacity
Maximum group capacity
Desired group capacity
When the load changes, the desired capacity of the node group will automatically change within the range limited by the specified minimum and maximum values.
In addition, here you can specify how many worker nodes are permitted to be unavailable when the EKS cluster is updated, for example when a new Kubernetes version is applied. You can specify a particular value or percentage of nodes that are permitted to be unavailable.
If you need to set labels, taints or tags, click Add labels to continue configuring.
If not, click Create to create a node group.
You can skip this step. To add a label, click Add label and set the label key and value. If additional labels are required, click Add.
Note
The key and value may consist of Latin letters, numbers, hyphens
-, underscores_and should start with a letter or number. The key may also contain dots.as a separator between domain names and should end with a letter or number. In addition, the key should not include names of the official domainskubernetes.ioork8s.ioand may optionally start with a slash followed by DNS subdomain prefix. If the key has the domain name format (contains.and/), it cannot contain the underscore character_.The key and value can contain up to 63 characters; the value cannot be blank.
If you want to set taints or tags, click Add taints to carry on with the setup.
If not, click Create to create a node group.
You can skip this step. To add a taint, click Add taint and set the taint key, value and effect. To learn more about the taint effects, see the section on adding taints. If additional taints are required, click Add.
Note
The key and value may consist of Latin letters, numbers, hyphens
-, underscores_and should start with a letter or number. The key may also contain dots.as a separator between domain names and should end with a letter or number. Moreover, the key may optionally start with a DNS subdomain prefix followed by slash. If the key has the domain name format (includes.and/), it cannot contain the underscore character_.The key and value can contain up to 63 characters; the value can be left blank.
If you want to set tags, click Add tags to carry on with the setup.
If not, click Create to create a node group.
To add a tag for a node group, click Add tag and set the tag key and value. If additional tags need to be set, click Add tag.
By default, all the group nodes, when created, are assigned tags with Name and nodegroup keys and nodegroup-<group name>-worker and <group name> values, respectively.
To create a node group, click Create.
Change scaling parameters#
You can change scaling parameters for a node group. If you want the number of workers in a node group to change dynamically, setup and enable the scaling policy for the corresponding Auto Scaling group.
Go to Kubernetes clusters Clusters, select the EKS cluster which the node group is related to and click on the cluster name to go to its page.
Open the Node groups tab, select the group in the resource table and click Modify.
In the dialog window, modify the scaling parameters:
Minimum group capacity
Maximum group capacity
Desired group capacity
In addition, you can modify the method how to calculate the number of nodes that will be unavailable when updating the EKS cluster:
Absolute number
Percentage ratio
and/or change their threshold value.
Once you have made all the required modifications, click Save.
Setup a scaling policy#
Scaling policy is executed when an alarm is triggered and allows the cloud to dynamically alter the number of group nodes depending on the current load.
Attention
To setup a scaling policy and alarms, a user should have the AutoScalingFullAccess project grants.
For details on the use of scaling policies, see the corresponding Auto Scaling documentation. You can access scaling policy management options in the Information tab, on the node group page by clicking Policies. Alternatively, you can open the Policies tab directly on the respective Auto Scaling group page.
See the example below of how to create a scaling policy for a node group.
Go to Kubernetes clusters Clusters, select the EKS cluster which the node group is related to and click on the cluster name to go to its page.
Open the Node groups tab and click on the group name in the resource table to go to its page.
In the Information tab, click Policies to go to the page of the Auto Scaling group, which corresponds to the node group.
Click Create and set necessary parameters:
Type — The policy type. Currently, only the SimpleScaling type is supported, and it cannot be changed.
Name — The policy name. It must be unique within the corresponding Auto Scaling Group.
Cooldown – Time after which the policy can be executed again.
Action — The action to be performed when the alarm is triggered.
Instances — The number of instances to be added to or terminated in the group. This parameter is available when you select the Add instances, Remove instances, or Set capacity equal to action.
Percentage — The percentage by which the group capacity changes. This parameter is available only when you select the Add capacity percentage or Remove capacity percentage action.
Number of instances, at least — The number of instances by which the group capacity will change if the number of instances calculated by percentage, turns out to be zero. This parameter is available only when you select the Add capacity percentage or Remove capacity percentage action.
Click Create.
For the scaling policy to be executed automatically, create an alarm for the selected metric and associate the scaling policy with it. To learn how to create an alarm for an Auto Scaling group and associate a policy, read the alarm documentation.
Add labels#
To add labels to Kubernetes nodes in a node group:
Go to Kubernetes clusters Clusters, select the EKS cluster which the node group is related to and click on the cluster name to go to its page.
Open the Node groups tab and click on the group name in the resource table to go to its page.
Open the Labels tab and click Add.
Set tge label key and value.
If you need to add more labels, repeat two previous steps.
To assign labels, click Apply.
Add taints#
To add a taint for a worker node:
Go to Kubernetes clusters Clusters, select the EKS cluster which the node group is related to and click on the cluster name to go to its page.
Open the Node groups tab and click on the group name in the resource table to go to its page.
Open the Taints tab and click Add.
Set the key, value, and effect of the taint. Effects can be as follows:
NoSchedule means that the scheduler will not place new pods that do not tolerate this taint, on the worker node.
NoExecute means that the scheduler evicts pods that do not tolerate this taint, from a worker node if they are already running on it, and does not place such pods on this node.
PreferNoSchedule means that the scheduler, if possible, will not place new pods that do not tolerate this taint, on the worker node.
If you need to add more taints, repeat two previous steps.
To apply taints, click Apply.
Add tags#
To add a tag for a node group:
Go to Kubernetes clusters Clusters, select the EKS cluster which the node group is related to and click on the cluster name to go to its page.
Open the Node groups tab and click on the group name in the resource table to go to its page.
Open the Tags tab and click Add.
Set the tag key and value.
If you need to add more tags, repeat two previous steps.
To assign tags, click Apply.
Delete a node group#
Note
If the node group is deleted, all nodes that belong to it will also be deleted. The data volumes will also be deleted along with the instances on which the worker nodes are deployed.
Go to Kubernetes clusters Clusters, select the EKS cluster which the node group is related to and click on the cluster name to go to its page.
Open the Node Groups tab and select the group to be deleted in the resource table.
Click Delete.
In the dialog window, confirm the action.