EKS vs Cycle: Comparing Cluster Setup

Last week I talked in depth about control planes and the differences between EKS and Cycle. In this weeks blog we'll dive into what it takes to spin up a cluster and get things rolling.

Cluster Setup

Setup and Preparation

EKS:

Before creating the cluster there are a few resources that need to be created. Namely a VPC and an IAM role with a security group. AWS has these guidelines for the VPC, summarized for brevity:

1. Have enough IPs for all the nodes and services.
2. Subnets are difficult to change and need to also have appropriate CIDRs to satisfy internal networking requirements.
3. If you want IPv6 plan ahead.
4. Know your networking.

Cycle:

Setup and preparation on Cycle is a bit different than EKS. For Cycle users, the only choices that need to be made ahead of time are:

• Which providers to integrate with (can be changed later).
• Generate the correct credentials to integrate that provider.
• Create the hub.

Users connect to an existing, managed control plane cluster so the provider level integrations are used to deploy infrastructure (worker nodes), create VPCs and networks (all automatic), and generally interact with the provider in the ways that the Cycle platform needs to, in order to manage those compute resources.

Configure Cluster:

EKS:

Clusters can be created through command line tools or through the console. The user will have to select a Kubernetes version and then select an IAM role/policy to the cluster. Generally in the role you will have attached an AmazonEKSClusterPolicy, unless you'd like to create a custom policy.

One main thing to decide on is what version of Kubernetes you'd like to run. You can see on this list of EKS versions that only the most recent versions of Kubernetes are supported under the "standard support" tier. If you choose an older version, or if you do not constantly update your cluster you'll fall into "extended support" which costs an extra $365.00 a month per cluster.

Once all of these things are in place, the cluster can be created. This process takes about 15 minutes, and once it is complete worker nodes can start to be added to the pool.

Cycle:

With Cycle, a user will create a hub through the portal. The Cycle control plane already exists and is ready to be used. There's no need to configure or prepare:

• IPs
• Subnets
• A VPC

All of these pieces are automatically created and configured for the user at the provider. The one thing that is needed is an IAM user with EC2FullAccess. This is used in combination with an access key to programmatically integrate your AWS account (or other provider) with Cycle.

While EKS requires creating and managing a control plane per region, Cycle's federated and managed model allows the user to just plug straight in and get to work. It's also always up to date, so theres never any overhead of trying to decide if and when you can take an update.

Next Steps

Two of the most important differences between Cycle and EKS highlighted in the last two articles:

• Cycle's federated control plane vs EKS regionally static control planes.
• Cycle's always up to date model vs EKS manual updates.

With Kubernetes, scaling beyond regions, much less scaling to multiple providers, becomes a huge lift. On Cycle, the control plane is your friend, giving organizations a standardized interface that works the same regardless of provider, region, or node type.

If you enjoyed this article, check back next week when I'll be diving into worker nodes.

💡 Interested in trying the Cycle platform? Create your account today! Want to drop in and have a chat with the Cycle team? We'd love to have you join our public Cycle Slack community!