Kubernetes Day-2 Operations, Part I

Kubernetes is the de-facto standard for container clustering and orchestration. Its adoption is soaring in cloud-native applications, on-premises, edge-locations to the cloud; and in test, staging, and production environments. CNFC Survey 2019 suggests a dramatic increase in Kubernetes usage in production, with 78% of the respondents using Kubernetes in 2019 versus only 58% in 2018. The acceptance of Kubernetes is also at an all-time high with the survey indicating 58% of respondents evaluate the container orchestration platform already in production. As Kubernetes evolves as a technology, grows in user adoption, and becomes more accepted within the developer community, it is also experiencing some complexities as it matures. As the survey report puts it, “While cultural challenges with the development team remain the top challenge, security (40%) and complexity (38%) remained high on the list. Despite being an open-source project to a large community for almost half a decade, even today, Kubernetes feels like it is built for everybody else but developers.” To begin, anybody with some help can set up a Kubernetes cluster and get up and running with the software implementation, but running its day-to-day operations is not as straightforward as it seems. Indeed, it is on day 2 going live that you realize Kubernetes operations are all about challenges. As the application stack and the underlying software architecture mature with a constant onslaught of code over the CI/CD pipeline, the environment tends to induce layers of complexities and with it a number of zero-day vulnerabilities. As it comes with the culture of IT administration, developers feel pressured to figure out those bugs when things go awry in the sea of countless complexities or release patches to that security vulnerability before it ends up on a security bulletin or in the hand of a digital intruder. No developer appreciates the amount of manual work Kubernetes management puts them through. Since everything tends to be code these days: infrastructure, production environment, testing, application security, developers have no choice but to step in. If we talk about Kubernetes, it is too naked, to begin with: developers have to figure out absolutely everything which invites a series of redundant manual steps or, on the flipside, missteps. When delivering Kubernetes to different lines of business and different users as-a-service, they need to resolve the following management challenges 1: Manifest Management Management of Kubernetes revolves a lot around the creation of YAML manifest and config files. YAML is already complex, and Kubernetes makes advanced use of it. Perhaps, having worked with YAML, you are still not sure how to work with blobs of text. Have you ever created an “array in a hash of an array” type of structure? Manifest management in Kubernetes involves you at another level, except you need to create an endless number of config files manually, and YAML or JSON manifests for each Docker container to correct account syntax and all attributes. At the end of the day, you have a huge mesh of small YAML files tied to resources in the environment to reverse-map. Occasionally, they grow at an unprecedented volume, making their management at a manual scale impossible. Automation is a must in this situation. 2: Application Lifecycle Management Containerization and all the toolings around it, allows developers to push new software releases per week, month, or every day per hour, minute, or in real-time. Too many commits to the repository originating from multiple sources may break the codebase and trigger an unexpected user response. An uninterrupted application lifecycle management requires containerization and DevOps automation tools like CI and CD to work together. A Continuous Integration tool like Jenkins or CircleCI can automate that. Manually integrating CI with each Docker container to deploy it can take an eternity. On the other end, developers tend to rely on Canary and Blue-Green strategies for a controlled delivery process. Kubernetes expects multiple deployments for each container and switches between these deployments by upscaling or downscaling each container in Blue/Green Deployment. Canary deployment requires developers to manually review and analyze application statistics and manually change the weight for each stage based on those statistics. These processes, even if they solve important problems related to deployment, require a lot of manual, time-consuming, and susceptible to human error configuration changes from the developer at the time of rollout and rollback. 3: Volume Management Kubernetes has the concept of volumes (storage) to work with persistent data. A volume can be attested to AWS Elastic Block Store (EBS), Azure Disk, GCE Persistent Disk, etc. Volume management in Kubernetes requires developers to configure storage class, persistent volume claims, and persistent volumes for each Docker container. Also, binding persistent volume with claims depends on allocated size and storage class. Every cloud vendor has its own persistent storage structure and expects the developer to learn it. Each Docker container can be designed with multiple persistent volumes. Containers in large numbers add complexities, which make management time-consuming in many cases (e.g: large volumes). If a developer misconfigured a persistent volume claim, persistent volume, or storage class, the volume will fail to attach to the container and remain in limbo. CloudPlex: Kubernetes is the easy way CloudPlex lets you build, debug, and deploy Kubernetes applications with minimal effort and without the blood, sweat, and tears that come with the manual use of Kubernetes. If we talk about manifest management, CloudPlex offers an intuitive visual drag and drop interface to eliminate the need for you to create YAML manifest and config files manually. This makes YAML files a breeze to manage. CloudPlex builds upon your existing cloud-managed solutions for Kubernetes in order to enhance the experience and make Kubernetes approachable and developer-friendly. CloudPlex makes designing, developing, testing, and running Kubernetes applications painless and fast. With CloudPlex, you no longer need to write the manifest files, nor search for valid parameters and supported values. You can configure services using a visual interface, in a single view. The interface validates and generates all needed manifest and config files. It can be downloaded and used on any K8s cluster. CloudPlex brings automation to the application update, and it supports all major CI tools you can think of: Jenkins, CircleCI, Bitbucket, etc. You just have to integrate a webhook in your CI pipeline. With CloudPlex, you just need to copy/paste code. Deploying Blue/Green, Canary, and highlander version upgrades are super easy with Cloudplex. You can design multi-stage deployment pipelines and deployment strategies visually. CloudPlex handles all the configuration files. When it comes to volume management, CloudPlex configures storage class, persistent volume, persistent volume claim, and their associations. You just have to provide basic information about the size of the volume and the identity of the container with which to associate. Moreover, CloudPlex provides a uniform interface for all public clouds, including AWS, Microsoft Azure, and Google Cloud. While Kubernetes provides a huge relief to the enterprise stuck in endless chaos around container management, it has added tasks to the to-do lists of busy developers running from one deadline to another deadline. The All-in-One Visual Kubernetes Application Platform from CloudPlex addresses these challenges faced by developers and eases their day-to-day burdens. Asad Faizi Founder CEO , Inc CloudPlex.io asad@cloudplex.io