{"id":930,"date":"2021-09-17T05:16:35","date_gmt":"2021-09-17T05:16:35","guid":{"rendered":"https:\/\/blog.ngocha.biz\/?p=930"},"modified":"2021-09-17T05:16:35","modified_gmt":"2021-09-17T05:16:35","slug":"deploy-mongodb-kubernetes","status":"publish","type":"post","link":"https:\/\/blog.ngocha.biz\/?p=930","title":{"rendered":"How To Deploy MongoDB on Kubernetes – Beginners Guide"},"content":{"rendered":"

This article aims to explain each of the components required to deploy MongoDB on Kubernetes. We will also discuss how to make the cluster accessible from outside Kubernetes.<\/p>\n

Towards the end, we will discuss how to do basic operations inside MongoDB. As a beginner, creating components one by one while understanding the steps involved is a great way to learn about Kubernetes and MongoDB. <\/p>\n

Going step by step ensures that you can focus on understanding the \u2018why\u2019 while learning the \u2018how\u2019.<\/p>\n

MongoDB Cluster Kubernetes Manifests<\/strong><\/h2>\n

All the Kubernetes Mngdb YAML manifests used in this guide are hosted on Github. Clone the repository for reference and implementation.<\/p>\n

git clone https:\/\/github.com\/techiescamp\/kubernetes-mongodb<\/code><\/pre>\n
We have explained all the MongoDB Kubernetes YAML files. If you don’t want to go through creating each manifest, just clone the repo and execute the following command from the cloned directory.<\/p>\n
kubectl apply -f .<\/code><\/pre>\n
After you deploy MongoDB on kubernetes, to clean up the deployment objects,  execute the following.<\/p>\n
kubectl delete -f .<\/code><\/pre>\n
Let’s get started with the setup.<\/p>\n
Create MongoDB Secrets<\/strong><\/h2>\n
Secrets in Kubernetes are the objects used for supplying sensitive information to containers. They are like ConfigMaps with the difference that data is stored in an encoded format.<\/p>\n
For the security of our MongoDB instance, it is wise to restrict access to the database with a password. We will use Secrets to mount our desired passwords to the containers.<\/p>\n
Save the following manifest as mongodb-secrets.yaml<\/code><\/p>\n
apiVersion: v1\ndata:\n  password: cGFzc3dvcmQxMjM= \/\/password123\n  username: YWRtaW51c2Vy \/\/adminuser\nkind: Secret\nmetadata:\n  creationTimestamp: null\n  name: mongo-creds<\/code><\/pre>\n
Create the Secret.<\/p>\n
kubectl apply -f mongodb-secrets.yaml<\/code><\/pre>\n
We’ll log in using these credentials.<\/p>\n
Tip: Decoding contents of Secret objects<\/strong><\/h3>\n
Kubernetes stores the content of all secrets in a base 64 encoded format. If you want to see how your string will appear in a base64 format, execute the following.<\/p>\n
echo \"devopscube\" | base64 \n\/\/after encoding it, this becomes ZGV2b3BzY3ViZQo=<\/code><\/pre>\n
If you want to decode a base64 string. Run<\/p>\n
echo \"ZGV2b3BzY3ViZQo=\" | base64 --decode\n\/\/after decoding it, this will give devopscube<\/code><\/pre>\n
Create MongoDB Persistent Volume<\/strong><\/h2>\n
We require volumes to store the persistent data. In this way, even if our pod goes down – the data is not lost.<\/p>\n
In Kubernetes, there are two objects which are required for creating volumes.<\/p>\n
    \n
  1. PersistentVolumes (PV)<\/strong>: are objects which map to a storage location. It’s a piece of storage in the cluster that has been provisioned by an administrator.<\/li>\n
  2. Persistent Volume Claims (PVC)<\/strong>: are Kubernetes objects that act as requests for storage. Kubernetes looks for a PV from which space can be claimed and assigned for a PVC. PVC works only if you have dynamic volume provisioning enabled in the Kubernetes cluster.<\/li>\n<\/ol>\n
    Let’s create one PVC for our MongoDB instance.<\/p>\n
    Save the following manifest as mongodb-pvc.yam<\/code>l.<\/p>\n
    apiVersion: v1\nkind: PersistentVolumeClaim\nmetadata:\n  name: pvc\nspec:\n  storageClassName: \"\"\n  accessModes:\n    - ReadWriteOnce \n  volumeName: pv\n  resources:\n    requests:\n      storage: 1Gi<\/code><\/pre>\n
    Create the PV.<\/p>\n
    kubectl create -f mongodb-pvc.yaml<\/code><\/pre>\n
    Note:<\/strong> If you dont have the option to provisiong, dynamic volumes using PVC, you can use the normal persistant volumes with the following manifest and map it to the deployment<\/p><\/blockquote>\n
    apiVersion: v1\nkind: PersistentVolume\nmetadata:\n  name: mongo-data\nspec:\n  accessModes:\n    - ReadWriteOnce\n  capacity:\n    storage: 1Gi\n  hostPath:\n    path: \/data\/mongo<\/code><\/pre>\n
    Deployments vs StatefulSets<\/strong><\/h2>\n
    People beginning their journey into containers and Kubernetes, often get confused about the use cases of Kubernetes Deployment<\/a> and Statefulset. Let’s try to understand this briefly.<\/p>\n
    A deployment is a Kubernetes object which is preferred when deploying a stateless application or when multiple replicas of pods can use the same volume.<\/p>\n
    A stateful set is a Kubernetes object which is preferred when we require each pod to have its own independent state and use its own individual volume.<\/p>\n
    Another major difference between them is the naming convention for pods. In the case of deployments,<\/strong> pods are always assigned a unique name but this unique name changes after the pod are deleted & recreated<\/strong>.<\/p>\n
    In the case of the stateful set <\/strong>\u2013 each pod is assigned a unique name and this unique name stays with it even if the pod is deleted <\/strong>& recreated.<\/p>\n
    Let's take an example of mongodb to understand the difference better.\n\nCase of deployments: name of pod initially: mongo-bcr25qd41c-skxpe  \nname of pod after it gets deleted & recreated: mongo-j545c6dfk4-56fcs \nHere, pod name got changed.\n\nCase of statefulsets: name of pod initially: mongo-0 \nname of pod after it gets deleted & recreated: mongo-0 Here, pod name remained the same.<\/code><\/pre>\n
    Here, in this example we are deploying a standalone MongoDB instance, therefore – we can use a deployment object<\/strong>. This is because only one pod will be spun up.<\/p>\n
    Deploying the MongoDB Deployment<\/strong><\/h2>\n
    Let\u2019s create the Deployment now. I have added an explanation for the MongoDB deployment file as well towards the end of this section.<\/p>\n
    Save the following manifest as mongodb-deployment.yaml<\/code>. Here we use the official mongo image<\/a> from docker hub.<\/p>\n
    apiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  creationTimestamp: null\n  labels:\n    app: mongo\n  name: mongo\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: mongo\n  strategy: {}\n  template:\n    metadata:\n      creationTimestamp: null\n      labels:\n        app: mongo\n    spec:\n      containers:\n      - image: mongo\n        name: mongo\n        args: [\"--dbpath\",\"\/data\/db\"]\n        livenessProbe:\n          exec:\n            command:\n              - mongo\n              - --disableImplicitSessions\n              - --eval\n              - \"db.adminCommand('ping')\"\n          initialDelaySeconds: 30\n          periodSeconds: 10\n          timeoutSeconds: 5\n          successThreshold: 1\n          failureThreshold: 6\n        readinessProbe:\n          exec:\n            command:\n              - mongo\n              - --disableImplicitSessions\n              - --eval\n              - \"db.adminCommand('ping')\"\n          initialDelaySeconds: 30\n          periodSeconds: 10\n          timeoutSeconds: 5\n          successThreshold: 1\n          failureThreshold: 6\n        env:\n        - name: MONGO_INITDB_ROOT_USERNAME\n          valueFrom:\n            secretKeyRef:\n              name: mongo-creds\n              key: username\n        - name: MONGO_INITDB_ROOT_PASSWORD\n          valueFrom:\n            secretKeyRef:\n              name: mongo-creds\n              key: password\n        volumeMounts:\n        - name: \"mongo-data-dir\"\n          mountPath: \"\/data\/db\"\n      volumes:\n      - name: \"mongo-data-dir\"\n        persistentVolumeClaim:\n          claimName: \"pvc\"<\/code><\/pre>\n
    Create the deployment.<\/p>\n
    kubectl apply -f mongodb-deployment.yaml<\/code><\/pre>\n
    The Deployment YAML of MongoDB has a lot of components such as env vars from secrets, probes, etc. Let us dive deeper and understand what each part is doing.<\/p>\n
    Env vars injected through secrets<\/strong><\/h3>\n
    Sometimes the containers need to know the sensitive data to use it. <\/p>\n
    E.g. to assign a password to the MongoDB database, the required password must be supplied securely to the MongoDB container.<\/p>\n
    env:\n - name: MONGO_INITDB_ROOT_USERNAME\n   valueFrom:\n      secretKeyRef:\n         name: mongo-creds\n         key: username\n - name: MONGO_INITDB_ROOT_PASSWORD\n   valueFrom:\n      secretKeyRef:\n         name: mongo-creds\n         key: password<\/code><\/pre>\n
    Probes:<\/strong> Probes ensure that the container does not get stuck in a loop due to any bug and can be restarted automatically in case an unexpected error comes up.<\/p>\n
     livenessProbe:\n          exec:\n            command:\n              - mongo\n              - --disableImplicitSessions\n              - --eval\n              - \"db.adminCommand('ping')\"\n          initialDelaySeconds: 30\n          periodSeconds: 10\n          timeoutSeconds: 5\n          successThreshold: 1\n          failureThreshold: 6\n\nreadinessProbe:\n          exec:\n            command:\n              - mongo\n              - --disableImplicitSessions\n              - --eval\n              - \"db.adminCommand('ping')\"\n          initialDelaySeconds: 30\n          periodSeconds: 10\n          timeoutSeconds: 5\n          successThreshold: 1\n          failureThreshold: 6<\/code><\/pre>\n
    Basic principle of the above probes<\/strong><\/h3>\n
    Here, we are running a MongoDB command which pings the database.<\/p>\n
    In case the container can ping – the command exits with an exit code of 0 i.e. successful execution. In case, the container is not able to ping – the command exits with an exit code of 1 i.e. unsuccessful execution.<\/p>\n
    This concept is valid for everything in Kubernetes probes. If the command exits with a code of 0 – it means success and code of 1 means unsuccessful i.e. probe may fail.<\/p>\n
    Connecting to MongoDB from Outside<\/strong><\/h2>\n
    Let’s try and access the database from outside the cluster. In order to do so, we must create another Kubernetes Service.<\/p>\n
    Services in Kubernetes are the objects that pods use to communicate with each other. ClusterIP<\/code> type services are usually used for inter-pod communication.<\/p>\n
    For a beginner, it’s important to know that there are two types of ClusterIP services<\/p>\n
      \n
    1. Headless Services<\/li>\n
    2. Services<\/li>\n<\/ol>\n
      Normal Kubernetes services act as load balancers and follow round-robin logic to distribute loads. Headless services don\u2019t act like load balancers. Also, normal services are assigned IPs by Kubernetes whereas Headless services are not. Headless services are primarily used when we deploy statefulset applications.<\/p>\n
      In the case of our MongoDB deployment example, we will use the normal service with Nodeport 32000 as we are using the type deployment.<\/p>\n
      Let’s create a NodePort type service. Save the below Kubernetes MongoDB service YAML as mongodb-nodeport-svc.yaml<\/code>.<\/p>\n
      apiVersion: v1\nkind: Service\nmetadata:\n  labels:\n    app: mongo\n  name: mongo-nodeport-svc\nspec:\n  ports:\n  - port: 27017\n    protocol: TCP\n    targetPort: 27017\n    nodePort: 32000\n  selector:\n    app: mongo\n  type: NodePort\nstatus:\n  loadBalancer: {}<\/code><\/pre>\n
      Create the svc.<\/p>\n
      kubectl create -f mongodb-nodeport-svc.yaml<\/code><\/pre>\n
      To connect from outside the Kubernetes cluster, you must use the Kubernetes cluster’s worker node IP address or a load balancer address. In case you are following on Minikube<\/a>, you can use minikube’s IP to connect.<\/p>\n
      To see minikube IP or service URLs, use the following commands<\/p>\n
      minikube ip\nminikube service --url mongo-nodeport-svc<\/code><\/pre>\n
      Command to connect:<\/p>\n
      mongo --host <ip> --port <port of nodeport svc> -u adminuser -p password123<\/code><\/pre>\n
      Exploring MongoDB shell<\/strong><\/h2>\n
      Now, that we have created our MongoDB instance, let us try to run some basic commands inside it. <\/p>\n
      Let’s create a dedicated mongo client from where we will access the MongoDB database.<\/p>\n
      Save the following manifest as mongodb-client.yaml<\/code><\/p>\n
      apiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  creationTimestamp: null\n  labels:\n    app: mongo-client\n  name: mongo-client\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: mongo-client\n  strategy: {}\n  template:\n    metadata:\n      creationTimestamp: null\n      labels:\n        app: mongo-client\n    spec:\n      containers:\n      - image: mongo\n        name: mongo-client\n        env:\n        - name: mongo-client_INITDB_ROOT_USERNAME\n          value: 'dummy'\n        - name: mongo-client_INITDB_ROOT_PASSWORD\n          value: 'dummy'\n<\/code><\/pre>\n
      Deploy the client.<\/p>\n
      kubectl create -f mongodb-client.yaml<\/code><\/pre>\n
      After the client gets created. Follow the below steps to access MongoDB.<\/p>\n
      Exec into the client.<\/p>\n
      kubectl exec deployment\/mongo-client -it -- \/bin\/bash<\/code><\/pre>\n
      Login into the MongoDB shell<\/p>\n
      mongosh --host mongo-nodeport-svc --port 27017 -u adminuser -p password123<\/code><\/pre>\n
      Display list of DBs<\/p>\n
      show dbs<\/code><\/pre>\n
      Get inside a particular DB.<\/p>\n
      use db1<\/code><\/pre>\n
      Display a list of collections inside the ‘db1’ database.<\/p>\n
      show collections<\/code><\/pre>\n
      Insert data into the db1<\/code> database.<\/p>\n
      Let’s say we want to enter data about DevOps blogs.<\/p>\n
      db.blogs.insert({name: \"devopscube\" })<\/code><\/pre>\n
      Display data from db1<\/code> database.<\/p>\n
      Let’s say we want to see data inside the blog’s collection.<\/p>\n
      db.blogs.find()<\/code><\/pre>\n
      Deploy MongoDB on Kubernetes Using Helm<\/h2>\n
      Now that, you know how to deploy MongoDB using individual manifests, you can use helm to deploy MongoDB.<\/p>\n
      If you don’t have helm installed, follow this helm tutorial<\/a> to get started.<\/p>\n
      We will use the Bitnami helm chart<\/a> to install MongoDB. It uses a deployment with persistent volume as it is a single pod setup.<\/p>\n
      First, add the bitnami helm repo.<\/p>\n
      helm repo add bitnami https:\/\/charts.bitnami.com\/bitnami<\/code><\/pre>\n
      Deploy MongoDB using the helm chart with the release name mongodb-dev<\/code><\/p>\n
      helm install mongodb-dev bitnami\/mongodb<\/code><\/pre>\n
      Once installed, you will see all the details to connect to the MongoDb deployment in the output as shown below.<\/p>\n
      \"Kubernetes<\/figure>\n
      This chart does not come with the client and NodePort service. You can use our client and Nodeport svc yamls to connect to the deployed MongoDB.<\/p>\n
      To delete the helm deployment, use the following command.<\/p>\n
      helm delete mongodb-dev<\/code><\/pre>\n
      MongoDb performance metrics<\/strong><\/h2>\n
      MongoDB provides features that show the performance characteristics of each query if required. Information such as execution success\/failure, total execution time, and no. of keys examines is accessible.<\/p>\n
      Let’s try:<\/p>\n
      use db1\ndb.blogs.find().explain(\"executionStats\")<\/code><\/pre>\n
      It will give the following information as a performance metric.<\/p>\n
      \"executionStats\" : {\n\t\t\"executionSuccess\" : true,\n\t\t\"nReturned\" : 1,\n\t\t\"executionTimeMillis\" : 0,\n\t\t\"totalKeysExamined\" : 0,\n\t\t\"totalDocsExamined\" : 1,\n\t\t\"executionStages\" : {\n\t\t\t\"stage\" : \"COLLSCAN\",\n\t\t\t\"nReturned\" : 1,\n\t\t\t\"executionTimeMillisEstimate\" : 0,\n\t\t\t\"works\" : 3,\n\t\t\t\"advanced\" : 1,\n\t\t\t\"needTime\" : 1,\n\t\t\t\"needYield\" : 0,\n\t\t\t\"saveState\" : 0,\n\t\t\t\"restoreState\" : 0,\n\t\t\t\"isEOF\" : 1,\n\t\t\t\"direction\" : \"forward\",\n\t\t\t\"docsExamined\" : 1\n\t\t}\n\t},<\/code><\/pre>\n
      Other ways to get performance metrics can be explored on the official documentation<\/a>.<\/p>\n
      Further Research<\/h2>\n
      Now that the basics have been made clear to you, feel free to explore other things about MongoDB such as arbiters, failover, and replica sets. These are things that usually come in handy when deploying to production.<\/p>\n
      When it comes to production implementation, Kubernetes custom resources and operators are used to deploy and manage MongoDB statefulset clusters due to the complexity involved in managing data. Do check out the following resources.<\/p>\n
        \n
      1. MongoDB community Operator<\/a><\/li>\n
      2. MongoDB Enterprise Operator<\/a><\/li>\n
      3. MongoDB Database Architecture in Kubernetes<\/a><\/li>\n<\/ol>\n
        Conclusion<\/h2>\n
        In this Kubernetes tutorial<\/a>, we have learned how to create a MongoDB deployment instance, a client to connect with it, ran basic operations like entering data, and also explored connecting from outside the Kubernetes cluster.<\/p>\n
        If you found this helpful, do share it among your colleagues and network.<\/p>\n
        \n
        Ngu\u1ed3n:<\/strong> How To Deploy MongoDB on Kubernetes – Beginners Guide \u2014 DevOpsCube<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
        Source: https:\/\/devopscube.com\/deploy-mongodb-kubernetes\/<\/p>\n","protected":false},"author":1,"featured_media":931,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-930","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/930","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=930"}],"version-history":[{"count":0,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/930\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/media\/931"}],"wp:attachment":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=930"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=930"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=930"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}