Kubernetes Day-2 Operations – Part II

In part-1 of this series, we covered 3 Kubernetes pain points Manifest Management, Application Lifecycle Update, and Volume Management. In this 2nd part, I will cover three more pain points that any developer should relate to — Dynamic Parameters, Kubernetes Cluster Bootstrapping & Kubernetes RBAC.

While every developer wishes to build, debug, and deploy Kubernetes applications in easy steps, that’s not the case most of the time. As you may have already noticed, Kubernetes is unlike your typical software stack.

It is not only complex to begin with, but also to master. It is undeniably confusing if you’re unfamiliar with infrastructure technologies, and having a leaning towards DevOps principles will further complicate the situation.

DevOps approach requires you to get Kubernetes access and deployment as early as possible during the development lifecycle. You need to shift software testing left on the development pipeline to avert costly mistakes during the staging and production stage.

Greenfield applications with Kubernetes are not always an option for companies since they have invested in existing applications. The challenge is to take your existing applications and run them on Kubernetes. Another option might be to run your existing applications as legacy, but have them interact seamlessly with greenfield Kubernetes applications. Even with Kubernetes veterans on your team, the adoption of Kubernetes is still a pain. It might suck out a substantial amount of energy and time from your DevOps team.

Kubernetes could be cheaper to use and deploy, but not when your engineers time is spent figuring it out rather than generating new “tangible” business value.

Nevertheless, Kubernetes day-2 operations were never easy. In the first part of the three blog series, we covered three pain points of Kubernetes day-2 operations: Manifest Management, Volume Management, Kubernetes Cluster Bootstrapping, and how CloudPlex fixes them for you.

Dynamic Parameters

While putting together an application, how you configured your containers says a lot about its performance in production and is, thus, a critical part. The environment variables play an important role inside a Kubernetes cluster when configuring your application to key-value pairs. Except, passing environment variables in Kubernetes is not as straightforward as most developers make us believe. If your application deployment comprises a large number of containers that need to interact with each other every now and then, then even reassigning value to a single variable becomes a long, complicated task for DevOps teams.

If you were using your own managed MySQL container shared across a large number of Docker containers at the time of development, you might pass on some exceptions while passing environment variables in Kubernetes in production. Your decision to switch to a provider-managed MySQL server might not go well with your existing container implementations. Unless you’re comfortable changing the connection string in every Docker container, sometimes manually. There will come the point where this all becomes too complex to maintain and pass on updates.

Kubernetes Cluster Bootstrapping

A setup of comprehensive Kubernetes infrastructure consists of a number of variables. These include a proper DNS address, load balancing policies, security certificates, and robust role-based access control (RBAC). Alongside a slew of auxiliary components, these make the deployment process possible.

In a nutshell, deploying your own Kubernetes cluster (or DIY Kubernetes) from scratch is a long setup and not a cup of tea for every developer. It requires a particular degree of understanding.

Provider-managed Kubernetes clusters might be the first preference of most developers at the time of production, although they often introduce restrictions absent in DIY-Kubernetes: you’re not allowed to use custom machine images or have ssh access to machines. Hence, you can’t configure certain parts of the cluster at a time when launching a Kubernetes cluster from scratch.

Deploying a cluster is already a slow process on certain cloud providers. Even automation tools like Terraform are of little help when deploying a Kubernetes cluster from scratch amidst these challenges. While Terraform automates a part of K8 cluster deployment, it still takes multiple steps and a lot of manual configurations. This is how you may deploy a Kubernetes cluster from scratch.

Kubernetes RBAC

This is a built-in role access control (RBAC) mechanism that allows you to configure fine-grained and specific sets of permissions inside a Kubernetes cluster. Kubernetes RBAC permissions define how you interact with a Kubernetes object in the cluster or within a particular namespace of the cluster. While Kubernetes RBAC makes managing permissions inside a cluster a cakewalk, it is not very friendly to developers since they have to manually create the roles, role bindings, and service accounts. To make matters worse, each container or service may need a different RBAC configuration. That is, you have to go through the nightmare of creating bindings between service accounts and roles for each service. Did Kubernetes creators have a grudge against developers?

Developers! Bring CloudPlex to your rescue.

Luckily for developers, CloudPlex addresses not one but all of the above three pain points. Who says Kubernetes day-2 operation must be a nightmare for developers? Not when CloudPlex is at your rescue.

If dynamic parameters are ruining your life one environment variable at a time, you need a way to define dynamic parameters within your services. Fortunately, CloudPlex gives you one. It resolves the value of these parameters itself and replaces them at deployment time on a Kubernetes cluster.

And when moving from a self-managed MySQL container to a provider-managed MySQL server, you can do that with an intuitive, simple drag and drop gesture of CloudPlex’s tools to replace the container without changing any variable in the service.

CloudPlex uncomplicates what it takes to deploy a K8 cluster from scratch. You can run your own cluster without the limitations set by managed providers like GKE, AKS, and EKS. Any developer can start a Kubernetes cluster from scratch, with CloudPlex providing a rich set of K8s and infrastructure configuration options. Using a custom machine image and ssh into machines to install additional configurations is not a hassle.

Not to mention, CloudPlex allows you to use the provider-managed Kubernetes clusters (GKE, AKS, EKS) to deploy applications as well.

If Kubernetes’ default RBAC settings are giving you trouble sleeping, with CloudPlex, you only have to provide information about resources and permissions. It automatically creates and configures the Service Accounts, Roles, and Role Bindings.

CloudPlex makes designing, developing, testing, and running Kubernetes applications painless and fast. It saves you time in deploying your cluster. It is a tool for developers by developers.

Get started now and create your first Kubernetes cluster for free in a few minutes.

Asad Faizi

Founder CEO

CloudPlex.io, Inc

[email protected]