The following items are required to install CloudBees CI on EKS:
Amazon Web Services (AWS) requirements
The following items are required:
-
An AWS account.
-
An AWS EKS cluster with the following requirements:
-
Runs a currently supported version of Kubernetes. See Supported platforms for CloudBees CI on modern cloud platforms.
-
Has nodes that have at least 4 CPUs and 16 GiBs of memory. Be sure that the cluster meets the sizing and scaling requirements in CloudBees CI Reference Architecture - Kubernetes on AWS EKS. NOTE: Having fewer controllers on each VM means that losing a VM unexpectedly does not impact service.
-
Has N+1 worker nodes, where N is the number of managed controllers and +1 is the CloudBees operations center.
-
Has network access to container images, either a public Docker Hub or a private Docker Registry.
-
When installing CloudBees CI on EKS on AWS Outposts, there are some additional considerations:
-
Your EKS nodes must be created in the Outpost subnet.
-
You are unable to create an ELB in the same subnet as the Outpost, but it needs to be in the same VPC.
-
You must pre-create the volumes you intend to use and create the persistent volumes that connect to them.
Amazon Spot
Installing CloudBees CI agents on EKS using EKS managed node groups with Spot Instances requires significantly less operational effort compared to using self-managed nodes. Amazon EKS managed node groups follow Spot best practices by using Capacity Optimized allocation strategy to provision Spot instances from the deepest Spot pools. Amazon EKS managed node groups use Capacity Rebalancing to ensure Amazon EKS can gracefully drain and rebalance your Spot nodes automatically when a Spot node is at elevated risk of interruption.
Storage requirements
Dynamic provisioning is required to create persistent volumes. If you don’t enable dynamic provisioning, you will have to manually create a persistent volume.
Because Jenkins is highly dependent upon the filesystem, the underlying storage provider must provide minimal input/output operations per second (IOPS) and latency.
SSD disks are recommended for production usage.
Single AZ | Multiple AZ | High Availability (active/active) (HA) | |
---|---|---|---|
|
|
|
|
EFS General purpose Elastic Throughput |
|
|
|
Configure High Availability (active/active) HA on EKS
To install High Availability in EKS, you must set up a storage class with ReadWriteMany
access mode. CloudBees recommends Amazon Elastic File System (EFS). When using EFS in performance tests, both the Elastic and the Provisioned throughput modes showed good performance results.
Refer to the Amazon documentation on the EFS CSI driver to learn how to deploy it to your EKS cluster.
Amazon Elastic Block Store (EBS) volumes cannot be used for High Availability (active/active) (HA) in EKS, as they do not support ReadWriteMany access mode. |
Ingress requirements
CloudBees CI creates one Ingress object for the operations center and one for each controller.
If you are on AWS, CloudBees CI on modern cloud platforms supports both Kubernetes NGINX Ingress Community version and ALB. |
As ALB is Layer-7 Load Balancer (HTTP/HTTPS), you must verify that this configuration works for your agents. You may need to use ALB for HTTPS/HTTP and a separate load balancer set up for TCP inbound agents.
If you are running a release earlier than CloudBees CI 2.452.2.3, when using ALB as the load balancer, the annotation Starting from the June 2024 release, for managed controller running in HA mode, this annotation is automatically enabled during provisioning. |
Unsupported Ingress Controllers
If you use an unsupported Ingress controller, you may need to add additional configurations for domains, hostnames, WebSocket, or TCP pass-through. CloudBees documentation can help you with that, but CloudBees does not support this kind of controller. In this case, you must install and configure your Ingress controller and adjust your CloudBees CI chart values according to your situation.
If you plan to provide High Availability (active/active), the load balancer must be configured to enable sticky sessions or session affinity.
Amazon Elastic Container Registery (ECR)
You can optionally configure your AWS CloudBees CI on modern cloud platforms deployment to work with AWS ECR. The AWS Elastic Container Registry (ECR) can:
-
Store Docker images for faster builds.
-
Manage Docker images for better repeatability.
-
Deploy Docker images for easier development.
This installation guide gives you an overview of using ECR with CloudBees CI on modern cloud platforms. Refer to the official documentation for full coverage of ECR:
Requirements for the machine where the installation is performed
You must have the following on the machine where you plan to perform the installation:
-
The
kubectl
application. Follow the instructions on the Kubernetes website to install it. -
helm
. Follow the instructions in the Helm Quickstart Guide to install the Helm client. -
A valid kubernetes context to interact with the EKS cluster (link).
Validating system requirements
-
Run the command
kubectl version
and ensure the server version is displayed.
Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.3", GitCommit:"1e11e4a2108024935ecfcb2912226cedeafd99df", GitTreeState:"clean", BuildDate:"2020-10-14T12:50:19Z", GoVersion:"go1.15.2", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.3", GitCommit:"1e11e4a2108024935ecfcb2912226cedeafd99df", GitTreeState:"clean", BuildDate:"2020-10-14T12:41:49Z", GoVersion:"go1.15.2", Compiler:"gc", Platform:"linux/amd64"}
-
Ensure you can run the
helm
command, for example by callinghelm version
.