DEV Community

Cover image for Kubernetes on AWS with JavaScript
K for Fullstack Frontend

Posted on

Kubernetes on AWS with JavaScript

You mastered JavaScript with years of frontend development. Now you want to do some full-stack development and build everything on your own. Well, you're lucky, because JavaScript is so popular that almost every technology has a JavaScript integration today. You can even define a whole Kubernetes (K8s) cluster with JavaScript if you want.

How are Things Looking on AWS?

There are at least three products by AWS that help with K8s. AWS EKS, AWS Fargate, and AWS CDK.

The Managed Service Side of Things

In 2018 AWS released the Elastic Kubernetes Service or short EKS. It's a K8s service where AWS manages the control plane for you. All the master nodes are taken care of—no need to install, set up, or maintain K8s or the VMs it's running on.

AWS also offers its container orchestration service called Elastic Container Service (ECS), but seemingly people weren't very fond of it, they preferred to use their K8s knowledge.

Anyway, while EKS eliminates control plane troubles with K8s, Fargate helps with the worker nodes. Fargate is not a stand-alone product; it has to be used in combination with ECS or EKS.

The idea behind Fargate is to let AWS take care of VM provisioning for your worker nodes. Fargate tries to move a K8s deployment more into a serverless direction. You get on-demand pricing and don't have to worry about what machine your containers run on.

With AWS EKS+Fargate, you define your Services, Deployments, and PersistentVolumeClaims, and AWS takes care of the rest for you.

The Tooling side of Things

Now, we also want to define our K8s clusters and deploy them to the AWS cloud. Preferably with as many tools we already know!

The Cloud Development Kit, or CDK, is a CLI tool that allows one to write infrastructure as code with different languages, one of the JavaScript.

It's a tool that sits between you and CloudFormation. You write JavaScript, specifically classes called "constructs", and the CDK converts them to CloudFormation resources in YAML.

The beautiful thing is, this also works with K8s YAML, so you can write your K8s manifest in the same place where you define the other services your system uses. Create an EKS+Fargate cluster and put your deployments on it.

Let's look at an example for a service:

const appLabel = { app: "my-app" };
const msqlTierLabel = { ...appLabel, tier: "mysql" };
const sqlPassword = "...";

const mysqlService = {
  apiVersion: "v1",
  kind: "Service",
  metadata: { name: "mysql" },
  spec: {
    type: "ClusterIP",
    ports: [{ port: 3306 }],
    selector: appLabel,
  },
};

const mysqlPvc = {
  apiVersion: "v1",
  kind: "PersistentVolumeClaim",
  metadata: { name: "mysql-pv-claim", labels: appLabel },
  spec: {
    accessModes: ["ReadWriteOnce"],
    resources: { requests: { storage: "20Gi" } },
  },
};

const mysqlDeployment = {
  apiVersion: "apps/v1",
  kind: "Deployment",
  metadata: { name: "wordpress-mysql", labels: appLabel },
  spec: {
    selector: { matchLabels: msqlTierLabel },
    strategy: { type: "Recreate" },
    template: {
      metadata: { labels: msqlTierLabel },
      spec: {
        containers: [
          {
            image: "mysql:5.6",
            name: "mysql",
            env: [{ name: "MYSQL_ROOT_PASSWORD", value: sqlPassword }],
            ports: [{ containerPort: 3306, name: "mysql" }],
            volumeMounts: [
              {
                name: "mysql-persistent-storage",
                mountPath: "/var/lib/mysql",
              },
            ],
          },
        ],
        volumes: [
          {
            name: "mysql-persistent-storage",
            persistentVolumeClaim: { claimName: mysqlPvc.metadata.name },
          },
        ],
      },
    },
  },
};
Enter fullscreen mode Exit fullscreen mode

This is the K8s YAML converted to JavaScript.

While a simple example, we can already see the possibilities this approach brings. We can get the names of the resources directly from their definition objects, but we can also define other variables to remove repetition.

It doesn't stop there; if we need another service that consists of the same kinds of resources, we could write a function that will create the definitions automatically and link them up.

With some CDK helper constructs, you can even query K8s resources at creation time to get info about them that you can use in other AWS services. For example, when you want to sprinkle some Lambda functions that help with some tasks around your cluster.

const myServiceAddress = new KubernetesObjectValue(this, 'LoadBalancerAttribute', {
  cluster: cluster,
  resourceType: 'service',
  resourceName: 'my-service',
  jsonPath: '.status.loadBalancer.ingress[0].hostname'
});
Enter fullscreen mode Exit fullscreen mode

Summary

AWS EKS, AWS Fargate, and AWS CDK can be the trinity of managed K8s for people with JavaScript skills.

K8s is still no piece of cake to get right, and even when you don't have to look after master and worker nodes, things can get hairy; but these services lower the bar quite a bit to get a cluster deployed in the cloud.

Another great thing is, you can also use TypeScript with the CDK, and its static typing will give you excellent autocomplete features that JavaScript can't provide. This way, you can probably cut down on half the documentation lookups it usually takes to get up to speed.

What do you use to deploy your K8s clusters? Tell me in the comments!

Top comments (0)