Installing EKS

    +
    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:

    $ 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 config at ~/.kube/config to ensure that all variables look correct:

    $ kubectl config view

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

    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:

    $ 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 Accepter 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.