Skip to content
logo
Percona Operator for MongoDB
Install on Amazon Elastic Kubernetes Service (AWS EKS)
Initializing search
    percona/k8spsmdb-docs
    percona/k8spsmdb-docs
    • Welcome
      • System requirements
      • Design and architecture
      • Comparison with other solutions
      • Install with Helm
      • Install with kubectl
      • Install on Minikube
      • Install on Google Kubernetes Engine (GKE)
      • Install on Amazon Elastic Kubernetes Service (AWS EKS)
        • Prerequisites
        • Create the EKS cluster
        • Install the Operator and deploy your MongoDB cluster
        • Verifying the cluster operation
        • Troubleshooting
        • Removing the EKS cluster
      • Install on Microsoft Azure Kubernetes Service (AKS)
      • Generic Kubernetes installation
      • Install on OpenShift
      • Application and system users
      • Changing MongoDB options
      • Anti-affinity and tolerations
      • Labels and annotations
      • Exposing the cluster
      • Local storage support
      • Arbiter and non-voting nodes
      • MongoDB sharding
      • Transport encryption (TLS/SSL)
      • Data at rest encryption
      • Telemetry
        • About backups
        • Configure storage for backups
        • Making scheduled backups
        • Making on-demand backup
        • Storing operations logs for point-in-time recovery
        • Restore from a previously saved backup
        • Delete the unneeded backup
      • Upgrade MongoDB and the Operator
      • Horizontal and vertical scaling
      • Multi-cluster and multi-region deployment
      • Monitor with Percona Monitoring and Management (PMM)
      • Add sidecar containers
      • Restart or pause the cluster
      • Debug and troubleshoot
      • OpenLDAP integration
      • How to use private registry
      • Creating a private S3-compatible cloud for backups
      • Restore backup to a new Kubernetes-based environment
      • How to use backups to move the external database to Kubernetes
      • Install Percona Server for MongoDB in multi-namespace (cluster-wide) mode
      • Upgrading Percona Server for MongoDB manually
      • Custom Resource options
      • Percona certified images
      • Operator API
      • Frequently asked questions
      • Old releases (documentation archive)
      • Release notes index
      • Percona Operator for MongoDB 1.14.0 (2023-03-13)
      • Percona Operator for MongoDB 1.13.0 (2022-09-15)
      • Percona Operator for MongoDB 1.12.0 (2022-05-05)
      • Percona Distribution for MongoDB Operator 1.11.0 (2021-12-21)
      • Percona Distribution for MongoDB Operator 1.10.0 (2021-09-30)
      • Percona Distribution for MongoDB Operator 1.9.0 (2021-07-29)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.8.0 (2021-05-06)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.7.0 (2021-03-08)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.6.0 (2020-12-22)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.5.0 (2020-09-07)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.4.0 (2020-03-31)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.3.0 (2019-12-11)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.2.0 (2019-09-20)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.1.0 (2019-07-15)
      • Percona Kubernetes Operator for Percona Server for MongoDB 1.0.0 (2019-05-29)

    • Prerequisites
    • Create the EKS cluster
    • Install the Operator and deploy your MongoDB cluster
    • Verifying the cluster operation
    • Troubleshooting
    • Removing the EKS cluster

    Install Percona Server for MongoDB on Amazon Elastic Kubernetes Service (EKS)¶

    This guide shows you how to deploy Percona Operator for MongoDB on Amazon Elastic Kubernetes Service (EKS). The document assumes some experience with the platform. For more information on the EKS, see the Amazon EKS official documentation.

    Prerequisites¶

    The following tools are used in this guide and therefore should be preinstalled:

    1. AWS Command Line Interface (AWS CLI) for interacting with the different parts of AWS. You can install it following the official installation instructions for your system.

    2. eksctl to simplify cluster creation on EKS. It can be installed along its installation notes on GitHub.

    3. kubectl to manage and deploy applications on Kubernetes. Install it following the official installation instructions.

    Also, you need to configure AWS CLI with your credentials according to the official guide.

    Create the EKS cluster¶

    To create your cluster, you will need the following data:

    • name of your EKS cluster,
    • AWS region in which you wish to deploy your cluster,
    • the amount of nodes you would like tho have,
    • the desired ratio between on-demand and spot instances in the total number of nodes.

    Note

    spot instances are not recommended for production environment, but may be useful e.g. for testing purposes.

    The most easy and visually clear way is to describe the desired cluster in YAML and to pass this configuration to the eksctl command.

    The following example configures a EKS cluster with one managed node group:

    apiVersion: eksctl.io/v1alpha5
    kind: ClusterConfig
    
    metadata:
        name: test-cluster
        region: eu-west-2
    
    nodeGroups:
        - name: ng-1
          minSize: 3
          maxSize: 5
          instancesDistribution:
            maxPrice: 0.15
            instanceTypes: ["m5.xlarge", "m5.2xlarge"] # At least two instance types should be specified
            onDemandBaseCapacity: 0
            onDemandPercentageAboveBaseCapacity: 50
            spotInstancePools: 2
          tags:
            'iit-billing-tag': 'cloud'
    

    When the cluster configuration file is ready, you can actually create your cluster by the following command:

    $ eksctl create cluster -f ~/cluster.yaml
    

    Install the Operator and deploy your MongoDB cluster¶

    1. Deploy the Operator. By default deployment will be done in the default namespace. If that’s not the desired one, you can create a new namespace and/or set the context for the namespace as follows (replace the <namespace name> placeholder with some descriptive name):

      $ kubectl create namespace <namespace name>
      $ kubectl config set-context $(kubectl config current-context) --namespace=<namespace name>
      

      At success, you will see the message that namespace/<namespace name> was created, and the context was modified.

      Deploy the Operator using the following command:

      $ kubectl apply --server-side -f https://raw.githubusercontent.com/percona/percona-server-mongodb-operator/v1.14.0/deploy/bundle.yaml
      
      Expected output
      customresourcedefinition.apiextensions.k8s.io/perconaservermongodbs.psmdb.percona.com serverside-applied
      customresourcedefinition.apiextensions.k8s.io/perconaservermongodbbackups.psmdb.percona.com serverside-applied
      customresourcedefinition.apiextensions.k8s.io/perconaservermongodbrestores.psmdb.percona.com serverside-applied
      role.rbac.authorization.k8s.io/percona-server-mongodb-operator serverside-applied
      serviceaccount/percona-server-mongodb-operator serverside-applied
      rolebinding.rbac.authorization.k8s.io/service-account-percona-server-mongodb-operator serverside-applied
      deployment.apps/percona-server-mongodb-operator serverside-applied
      
    2. The operator has been started, and you can deploy your MongoDB cluster:

      $ kubectl apply -f https://raw.githubusercontent.com/percona/percona-server-mongodb-operator/v1.14.0/deploy/cr.yaml
      
      Expected output
      perconaservermongodb.psmdb.percona.com/my-cluster-name created
      

      Note

      This deploys default MongoDB cluster configuration, three mongod, three mongos, and three config server instances. Please see deploy/cr.yaml and Custom Resource Options for the configuration options. You can clone the repository with all manifests and source code by executing the following command:

      $ git clone -b v1.14.0 https://github.com/percona/percona-server-mongodb-operator
      

      After editing the needed options, apply your modified deploy/cr.yaml file as follows:

      $ kubectl apply -f deploy/cr.yaml
      

      The creation process may take some time. When the process is over your cluster will obtain the ready status. You can check it with the following command:

      $ kubectl get psmdb
      
      Expected output
      NAME              ENDPOINT                                           STATUS   AGE
      my-cluster-name   my-cluster-name-mongos.default.svc.cluster.local   ready    5m26s
      

    Verifying the cluster operation¶

    It may take ten minutes to get the cluster started. When kubectl get psmdb command finally shows you the cluster status as ready, you can try to connect to the cluster.

    1. You will need the login and password for the admin user to access the cluster. Use kubectl get secrets command to see the list of Secrets objects (by default the Secrets object you are interested in has my-cluster-name-secrets name). Then kubectl get secret my-cluster-name-secrets -o yaml command will return the YAML file with generated Secrets, including the MONGODB_DATABASE_ADMIN_USER and MONGODB_DATABASE_ADMIN_PASSWORD strings, which should look as follows:

      ...
      data:
        ...
        MONGODB_DATABASE_ADMIN_PASSWORD: aDAzQ0pCY3NSWEZ2ZUIzS1I=
        MONGODB_DATABASE_ADMIN_USER: ZGF0YWJhc2VBZG1pbg==
      

      Here the actual login name and password are base64-encoded. Use echo 'aDAzQ0pCY3NSWEZ2ZUIzS1I=' | base64 --decode command to bring it back to a human-readable form.

    2. Run a container with a MongoDB client and connect its console output to your terminal. The following command will do this, naming the new Pod percona-client:

      $ kubectl run -i --rm --tty percona-client --image=percona/percona-server-mongodb:4.4.18-18 --restart=Never -- bash -il
      

      Executing it may require some time to deploy the correspondent Pod.

    3. Now run mongo tool in the percona-client command shell using the login (which is normally databaseAdmin), a proper password obtained from the Secret, and a proper namespace name instead of the <namespace name> placeholder. The command will look different depending on whether sharding is on (the default behavior) or off:

      $ mongo "mongodb://databaseAdmin:databaseAdminPassword@my-cluster-name-mongos.<namespace name>.svc.cluster.local/admin?ssl=false"
      
      $ mongo "mongodb+srv://databaseAdmin:databaseAdminPassword@my-cluster-name-rs0.<namespace name>.svc.cluster.local/admin?replicaSet=rs0&ssl=false"
      

    Troubleshooting¶

    If kubectl get psmdb command doesn’t show ready status too long, you can check the creation process with the kubectl get pods command:

    $ kubectl get pods
    
    Expected output
    NAME                                               READY   STATUS    RESTARTS   AGE
    my-cluster-name-cfg-0                              2/2     Running   0          11m
    my-cluster-name-cfg-1                              2/2     Running   1          10m
    my-cluster-name-cfg-2                              2/2     Running   1          9m
    my-cluster-name-mongos-0                           1/1     Running   0          11m
    my-cluster-name-mongos-1                           1/1     Running   0          11m
    my-cluster-name-mongos-2                           1/1     Running   0          11m
    my-cluster-name-rs0-0                              2/2     Running   0          11m
    my-cluster-name-rs0-1                              2/2     Running   0          10m
    my-cluster-name-rs0-2                              2/2     Running   0          9m
    percona-server-mongodb-operator-665cd69f9b-xg5dl   1/1     Running   0          37m
    

    If the command output had shown some errors, you can examine the problematic Pod with the kubectl describe <pod name> command as follows:

    $ kubectl describe pod my-cluster-name-rs0-2
    

    Review the detailed information for Warning statements and then correct the configuration. An example of a warning is as follows:

    Warning FailedScheduling 68s (x4 over 2m22s) default-scheduler 0/1 nodes are available: 1 node(s) didn’t match pod affinity/anti-affinity, 1 node(s) didn’t satisfy existing pods anti-affinity rules.

    Removing the EKS cluster¶

    To delete your cluster, you will need the following data:

    • name of your EKS cluster,
    • AWS region in which you have deployed your cluster.

    You can clean up the cluster with the eksctl command as follows (with real names instead of <region> and <cluster name> placeholders):

    $ eksctl delete cluster --region=<region> --name="<cluster name>"
    

    The cluster deletion may take time.

    Warning

    After deleting the cluster, all data stored in it will be lost!

    Contact Us

    For free technical help, visit the Percona Community Forum.

    To report bugs or submit feature requests, open a JIRA ticket.

    For paid support and managed or consulting services , contact Percona Sales.


    Last update: 2023-03-14
    Percona LLC and/or its affiliates, © 2009 - 2023
    Made with Material for MkDocs

    Cookie consent

    We use cookies to recognize your repeated visits and preferences, as well as to measure the effectiveness of our documentation and whether users find what they're searching for. With your consent, you're helping us to make our documentation better.