Installing EKS

March 16, 2025

+ 12

Prepare Amazon Elastic Kubernetes Service (EKS) for the Couchbase Autonomous Operator.

Tutorials are accurate at the time of writing but rely heavily on third party software. Tutorials are provided to demonstrate how a particular problem may be solved. Use of third party software is not supported by Couchbase. For further help in the event of a problem, contact the relevant software maintainer.

This guide is meant to supplement the regular Amazon EKS setup documentation, and provides recommendations up to setting up worker nodes.

Create the Cluster and Configure `kubectl`

Create the EKS cluster(s) according to the Amazon documentation, with either eksctl or via the AWS Management Console. Actual cluster creation in EKS can take some time (around 10-15 minutes per cluster).

Configure `kubectl`

The following section applies only to when using the AWS Management Console method in the Amazon EKS setup documentation.

When configuring kubectl via the AWS Management Console, pay particular attention to the following command:

console
Copy
$ aws eks --region region-code update-kubeconfig --name cluster_name

This command is vital as it sets the relevant Amazon Resource Name (ARN) variables in ~/.kube/config. Optionally, you can add --region regionName to specify a cluster in a region that is different than the default. (Your default region should have been specified when you first setup the AWS CLI through aws configure command.)

Validate `kubectl` Configuration

Once you have followed the setup instructions for either method, view the configuration at ~/.kube/config to ensure that all variables look correct:

console
Copy
$ kubectl config view

The following example shows two AWS context configurations appended to an existing Minikube one:

yaml
Copy
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: <REDACTED>
    server: https://E8A3753F682B8098CAFFAEDCF1339471.yl4.eu-west-1.eks.amazonaws.com
  name: arn:aws:eks:eu-west-1:705067739613:cluster/test1
- cluster:
    certificate-authority-data: <REDACTED>
    server: https://1B9C893E96EAA59350290F34D41A417E.yl4.us-west-2.eks.amazonaws.com
  name: arn:aws:eks:us-west-2:705067739613:cluster/oregon
- cluster:
    certificate-authority: /Users/.../.minikube/ca.crt
    server: https://192.168.99.100:8443
  name: minikube
contexts:
- context:
    cluster: arn:aws:eks:eu-west-1:705067739613:cluster/test1
    user: arn:aws:eks:eu-west-1:705067739613:cluster/test1
  name: arn:aws:eks:eu-west-1:705067739613:cluster/test1
- context:
    cluster: arn:aws:eks:us-west-2:705067739613:cluster/oregon
    user: arn:aws:eks:us-west-2:705067739613:cluster/oregon
  name: arn:aws:eks:us-west-2:705067739613:cluster/oregon
- context:
    cluster: minikube
    user: minikube
  name: minikube
current-context: arn:aws:eks:us-west-2:705067739613:cluster/oregon
kind: Config
preferences: {}
users:
- name: arn:aws:eks:eu-west-1:705067739613:cluster/test1
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      args:
      - token
      - -i
      - test1
      command: aws-iam-authenticator
      env: null
- name: arn:aws:eks:us-west-2:705067739613:cluster/oregon
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      args:
      - token
      - -i
      - oregon
      command: aws-iam-authenticator
      env: null
- name: minikube
  user:
    client-certificate: /Users/.../.minikube/client.crt
    client-key: /Users/.../.minikube/client.key

To switch between Kubernetes contexts, use kubectl config use-context <context-name>. For example:

console
Copy
$ kubectl config use-context arn:aws:eks:eu-west-1:705067739613:cluster/test1

Configuring for XDCR

If you wish to take advantage of XDCR capabilities using the Operator, there are a few extra steps to complete.

Create the Peering Connection

Follow the Amazon documentation to create a peering connection between two VPCs in the availability zones of your choosing. Bear in mind that each cluster needs to have different CIDR ranges, in the private ranges of 192.168.0.0/16, 172.16.0.0/12, or 10.0.0.0/8 as per RFC 1918.

You will need to then accept the connection request in the region of the accepting VPC to establish the connection.

Configure Route Tables and Security Groups

Once the peering connection is accepted, you must add a route to the route tables of each of the VPCs so that they can send and receive traffic across the VPC peering connection. To do this, go to Route Tables and select the route table associated with the public subnet of one of your VPCs. Select Routes and then Edit. Add the other VPC’s CIDR block as the Destination, and add the pcx- (peering connection) as the Target. Repeat these steps for the other VPC Public Subnet.

Next, find the security groups for the worker node CloudFormation stacks and edit their Inbound Rules.

Allow TCP traffic from ports 30000 - 32767 from the other cluster’s CIDR. Do this for both clusters. This will allow nodes in each cluster to talk to each other.
Allow ICMP from the same cluster’s CIDR to be able to ping the other cluster’s nodes to see if it has the desired network setup.

Installing EKS

Create the Cluster and Configure kubectl

Configure kubectl

Validate kubectl Configuration