Kubernetes & How to use a Developer Control Plane like CTO.ai

One of the latest additions to the technical jargon soup is Kubernetes. It gets thrown around quite a bit, "Kubernetes this, Kubernetes that, do you even deploy bro???", but what does it actually mean and should you be using it in your day to day software development job? *Spoiler Alert: You might not directly interface with it, but your DevOps team should, or at least be thinking about it if you are not a fan of the 3pm War Room deployment every Monday.

Kubernetes is a DevOps software development tool built and supported by Google to enable teams to simplify the management of deploying updates and services in a distributed system. Phew, that is a lot of techy words, but to simplify that; Gone are the days for having to have 1 giant compute machine on Amazon to support all your running containers (or worse, multiple identical giant compute machines holding everything because you needed more services that help user John_63_xyz to see his dashboard... but you get the point)! If you are hungup on what containers are, I strongly encourage you to give this article by Docker a read and then come back.

The advantages of running containerized code are innumerable and it is well established in industry to follow this practice, so I'm not going to go into those details. Getting back to Kubernetes and what it is, it is a tool used for container orchestration. Meaning that it is one point of reference that you can "talk to" to access ANY of the services that you have running on your kubernetes cluster, even if those services are across machines!

What does Kubernetes do for me exactly?

EVERYTHING, for deployment and maintenance needs anyways... Historically (not speaking ftp), the deployment process looked something like this:

  1. Code review is approved and changes are merged into master
  2. ssh into your Amazon EC2 instance holding the git repo for your application
  3. cd into your project directory
  4. ^C to stop application
  5. git pull origin master
  6. <application start command>
  7. Hope it works out 🤞

Over the years, the process has improved with Docker and docker-compose to run images of the application in containers (see Docker article if feeling lost) instead of the application on bare metal, but it still follows the same steps as above.

Alternatively, if using kubernetes, you can run kubectl apply -f {deployment yaml} to directly target ALL services on ALL machines of the specified type in your deployment yaml file and apply the new image(s) from your local machine (*depending on the priviledges you setup for the connection to your cluster). On top of it being one line, it applies the update in a rollout fashion, meaning that it shuts down the services one at a time as it applies the new changes.

That's pretty good, but what if I need to add new services not defined in this cluster?

Simple, create a new deployment yaml file for the new service and run the apply command.

What if I need more than 1 of the same service?

Even easier, each service (called a deployment) has a number of pods representing the number of "service instances" that are running that application. Just set that value to be greater then 1, or even better set the "autoscaling" limit to be the maximum number of service instances you want running at a time and let Kubernetes scale the number of instances up and down based on traffic.

Is there a limit on the number of services that I can run?!

Yes and no. Your kubernetes cluster manages which machines (called nodes) the new pods get deployed to (and yes you can pair up applications that need to be together), which isn't a problem until there isn't enough space on any of the nodes you have allocated to your cluster. You can correct this by adding more nodes, so the sky and your wallet are the limit.

How do I setup a Kubernetes cluster for my application?

There are a number of ways for setting up a Kubernetes cluster for your application ranging from bare metal to managed cloud provider solutions. In this article I'm going to point you in the right direction for setting up a managed solution in each of the major cloud providers as well as how to use The Ops Platform to make it simpler.

Amazon Web Services (AWS) EKS

According to AWS's documentation, there are 2 ways to create a new EKS managed Kubernetes cluster. The first being an officially supported CLI developed by Weaveworks called eksctl. With eksctl, you can spin up a new managed cluster with reasonable defaults just by running eksctl create cluster. Pretty easy right? You can also customize the settings on the cluster via the command line or a configuration yaml if you know what you are doing, which adds some complexity. From their website it looks like this tool does the heavy lifting from the setup side, but doesn't provide any abstractions over kubectl for pod or deployment maintenance.

$ eksctl create cluster
[ℹ]  using region us-west-2
[ℹ]  setting availability zones to [us-west-2a us-west-2c us-west-2b]
[ℹ]  subnets for us-west-2a - public:192.168.0.0/19 private:192.168.96.0/19
[ℹ]  subnets for us-west-2c - public:192.168.32.0/19 private:192.168.128.0/19
[ℹ]  subnets for us-west-2b - public:192.168.64.0/19 private:192.168.160.0/19
[ℹ]  nodegroup "ng-98b3b83a" will use "ami-05ecac759c81e0b0c" [AmazonLinux2/1.11]
[ℹ]  creating EKS cluster "floral-unicorn-1540567338" in "us-west-2" region
[ℹ]  will create 2 separate CloudFormation stacks for cluster itself and the initial nodegroup
[ℹ]  if you encounter any issues, check CloudFormation console or try 'eksctl utils describe-stacks --region=us-west-2 --cluster=floral-unicorn-1540567338'
[ℹ]  2 sequential tasks: { create cluster control plane "floral-unicorn-1540567338", create nodegroup "ng-98b3b83a" }
[ℹ]  building cluster stack "eksctl-floral-unicorn-1540567338-cluster"
[ℹ]  deploying stack "eksctl-floral-unicorn-1540567338-cluster"
[ℹ]  building nodegroup stack "eksctl-floral-unicorn-1540567338-nodegroup-ng-98b3b83a"
[ℹ]  --nodes-min=2 was set automatically for nodegroup ng-98b3b83a
[ℹ]  --nodes-max=2 was set automatically for nodegroup ng-98b3b83a
[ℹ]  deploying stack "eksctl-floral-unicorn-1540567338-nodegroup-ng-98b3b83a"
[✔]  all EKS cluster resource for "floral-unicorn-1540567338" had been created
[✔]  saved kubeconfig as "~/.kube/config"
[ℹ]  adding role "arn:aws:iam::376248598259:role/eksctl-ridiculous-sculpture-15547-NodeInstanceRole-1F3IHNVD03Z74" to auth ConfigMap
[ℹ]  nodegroup "ng-98b3b83a" has 1 node(s)
[ℹ]  node "ip-192-168-64-220.us-west-2.compute.internal" is not ready
[ℹ]  waiting for at least 2 node(s) to become ready in "ng-98b3b83a"
[ℹ]  nodegroup "ng-98b3b83a" has 2 node(s)
[ℹ]  node "ip-192-168-64-220.us-west-2.compute.internal" is ready
[ℹ]  node "ip-192-168-8-135.us-west-2.compute.internal" is ready
[ℹ]  kubectl command should work with "~/.kube/config", try 'kubectl get nodes'
[✔]  EKS cluster "floral-unicorn-1540567338" in "us-west-2" region is ready

Example command and outputs. Taken from https://eksctl.io

Alternatively, you can go through the AWS Management Console or AWS CloudFormation and set it up from there but you then have to be exposed to a lot more technical depth for setting up the cluster VPC, installing and setting up kubectl, setting up the cluster configs so that you can reach it and nodes communicate properly, et cetera, et cetera. There is nothing wrong with taking that path, and if you are a tried and true AWS console user, maybe you take joy in that, but for the rest of us, why bother?

Google Cloud Provider (GCP) GKE

Similar to AWS, Google Cloud offers 2 paths to get up and running with a new GKE managed Kubernetes cluster, a quick start path, using an online console and a full install guided path. Both paths are valid, but highly technical. They will get you there step by step but you might want to dip into the official Kubernetes docs to fully understand the components that you are putting in place in the walkthrough.

gcloud beta container clusters create cluster-name \\
    --zone compute-zone \\
    --release-channel channel

Example command for setting up a new cluster through Google Cloud's CLI

Microsoft Azure (AKS)

Following the same pattern, Azure also has 2 paths for setting up a new AKS managed Kubernetes cluster. This time it is a quickstart guide followed by a full fledged tutorial that walks you through testing your containerized application all the way up to scaling the application in your Kubernetes cluster. Similar to GKE, Kubernetes is less abstracted and the technical understanding is left up to the user.

az group create --name myResourceGroup --location eastus
az aks create --resource-group myResourceGroup --name myAKSCluster --node-count 1 --enable-addons monitoring --generate-ssh-keys

Example 2 step process to create a new cluster through Azure's online CLI

The Ops Platform - A Cloud Native Developer Control Plane

On The Ops Platform we currently support setting up and tearing down managed Kubernetes clusters on AWS (EKS) and GCP (GKE). Support for Azure is planned and will be coming in the not too distant future. To be able to acheive this we have 2 opensource Workflows, an EKS Workflow and a GKE Workflow that can be run from both the terminal and Slack. They provide you with a guided experience by asking you questions about how you want your cluster to be setup, reducing the amount of technical knowledge required. The objective is to make your life easier, while still providing you with some of the most powerful tools.

To run the EKS or GKE Workflow in the CLI, you need to first have The Ops CLI installed (accessible via the Dashboard on our website https://cto.ai in the signed in view) and then type:

ops run @cto.ai/eks

OR

ops run @cto.ai/gke

Depending on your Cloud Provider of choice.

Alternatively you can run these in slack, after installing our Slack App (also found on the signed in Dashboard) using:

/ops run cto.ai/eks

OR

/ops run cto.ai/gke

Running the Workflow, greets you with friendly messaging and a heads up as to pieces that you need to have available (either in your local configs or in the secret store registered to your CTO.ai Team). In the case of the EKS Workflow, you need the following to be able to connect to your AWS account to create or destroy a Kubernetes cluster.

  • AWS Account Number
  • AWS Access Key Id
  • AWS Secret Access Key
  • SSH key pair

Output from running ops run @cto.ai/eks

After selecting "Create a Cluster", the workflow will fetch the necessary configs if they are available or ask for them via the secret interface, and then follow up with questions regarding how you want your cluster setup including: the name of your cluster, region, machine sizes, and autoscaling settings. This is an improved experience, because you now longer need to go back to the created cluster to "add-on" the features that should have been available up front. In addition, we also package in setting up monitoring and logging, as well as specifying users that you want to have access to your cluster.

Iterative steps walking through the setup process for new EKS cluster.

Before sending you off to the races and spinning up the new cluster, we provide a detailed printout to show what is being setup and giving you the option to continue or not. Worst case if you are unhappy with you cluster, or don't want to use it anymore, you can use the same Workflow to destroy it and start again or create something at a later date.

Final output before creating new cluster, to allow you to review the settings.

The GKE Workflow provides a very similar experience, so I encourage you to try it on your own! Get hacking!

Maintaining your Kubernetes Cluster in Slack

Great, you now have a new Kubernetes cluster in one of the Cloud Providers, so how do you maintain it and check that all your pods are up and running happily? Easy, Kubernetes provides you with some tools like its Kubernetes dashboard to see all your pods, view your configs and secrets, and apply updates.

Alternatively, if you created your cluster using our EKS Workflow or GKE W, you can use our **k8s Workflow** to view and maintain your Workflow in the CLI or Slack.

To run the workflow in Slack, type in:

/ops run cto.ai/k8s

on any channel (if you are running it from a private channel, be sure to invite the bot user @invite cto.ai).

Iterative steps to walk you through getting access to your cluster.

The k8s workflow allows you to:

  • Configure your cluster (create kubernetes config file in your secrets)
  • List out the cluster resources: deployments, pods, etc
  • Install useful k8s tools such as NGINX ingress (allow external connections) or grafana (provide observability performance metrics dashboard)
  • Deploy new or update existing applications in your cluster

I'm not going to go into too much detail, the registry page for the Op provides additional content and videos to better represent the features.

What's Next?

I hope that this post provides you with enough of an understanding of Kubernetes to help you get started with it. If there is enough interest in this post, we will be sure to publish follow ups showing new extensions to make Kubernetes work and managment even easier and provide more details into how you can eke out more power from this tool.

Be sure to join our Slack Community and let us know what you think of articles like this one. Or better yet:

  • Browse our Docs to better understand The Ops Platform
  • Get Started running these workflows or build your own based on their source code