Why I am writing about Kubernetes?
While there is a pile of material available discussing Kubernetes, it is hard to find something that help connect the dots and talk about getting started with enterprise implementation. I thought, I want to help others bridge this gap.
What is Kubernetes:
To understand what Kubernetes is, I would start with “Containers”. This article assumes the reader is familiar with containers. In simple words, containers host applications but to get maximum throughput out of these containers we deploy them on Kubernetes Platform. Kubernetes literally “orchestrates the container show”. The orchestration engine makes it easy for containers to scale, interact with the rest of the ecosystem for better, faster integration and run time. Yes, Kubernetes is an open-source orchestration platform, where Google has been a major contributor.
Most organizations are either piloting their workloads on containers and K8s (Kubernetes) platforms or they are getting ready to scale them. Generally, when organizations embark on containerization and Kubernetes(orchestration) journey, they are looking to target one or more of the following
- Improve time to value / faster delivery
- Accelerate Cloud migration
- Re-architect/Create applications for microservices
- Re-package legacy/COTs applications
- Improve resource utilization
To achieve any of the above goals, organizations need to “prepare” well. Just as a reference, see where containers fit on the deployment evolution graph
Now, if you have decided to use containers, does it mean you HAVE to use Kubernetes? No. There are platforms/services available that provide container orchestration but do not use Kubernetes. You can choose to use AWS ECS(no K8s) over AWS EKS. But K8s is becoming a de facto Open Source Standard. It offers certain inbuilt features. EKS has evolved tremendously in past couple of years.
Kubernetes Flavors
Focusing again on Kubernetes — There are mainly three types of Kubernetes flavors
● A pure open source K8s platform where you are responsible for every small configuration detail — this is a DIY approach. Easy to get started, harder to scale.
● Kubernetes Orchestration Platform by a vendor — Red Hat OpenShift K8 Engine and other platform features, VMWare Tanzu K8s Grid and more
● Kubernetes on PaaS — AWS EKS, Google Anthos with GKE, Azure AKS, easy to scale and can offer integration to their own platform. e.g EKS may be good fit for integrating with other AWS services
While the core of each one of them is Kubernetes, each flavor has its own advantages and disadvantages with varied maturity levels. Organizations may have their own reasons to choose one over the other.
But just in case, if you are thinking about which K8 flavor to choose, how do we determine which platform to use? Think through following list of questions
● Will you go for a licensed and supported Vs Open-Source product?
● What is the organizations’ engineering skillset, which platform can they adopt fastest?
● What type of applications are you deploying, if it is a COTs application is it supported? Does the platform support UI and LCM?
● What type of integration and Ecosystem are needed by your organization to support applications? Which K8s product will fit best?
● Are there established practices for Image scanning and security, observability, DevOps in your organization and how fast you can scaleup a specific platform?
● Are you planning to deploy stateful applications?
● Is your organization ready to invest in tooling, networking, storage, security and monitoring if needed?
Containerization and Orchestration platforms are a major shift for developer and I&O organization. Making this transition as smooth as possible for them should be a major focus.
Scaling Containers and Kubernetes environment in your organization
We talk about technology and innovation all the time, but not focusing on the “operationalization” part is a major cause of failure in most cases. So now, if I deployed my app on Kubernetes in a container, how do I create a highway for more applications to accelerate adoption?
You may be thinking of migrating existing workloads to containers and on to Kubernetes platforms for scalability and cloud migration, make sure to check how your current version of JDK integrates with containers.
Important building blocks to scale Kubernetes and containers
You may want to evaluate the chosen K8s platform to see if it meets all of your OPs, Security, DevOps requirements
DevSecOps and IaC
Containerization and Orchestration initiatives benefit most from strong DevSecOps practice. But, because we want to achieve a dynamic environment that can scale and heal automatically, it is equally important to ensure Infrastructure provisioning is not a showstopper. There is simply no alternative. Manual procedures and deployments and siloed teams simply cannot help realize value. Those efforts can be a waste.
Based on which Kubernetes platform you choose; you may come across different DevSecOps tool sets. Which may range from Helm to AWS Code Commit or even other platform vendors promoting their own app factory pipeline.
K8s and containers introduce new elements including image scanning, governance, new way to look at observability, network and storage. Traditional application teams may not have these skills, it serves the best interest of the organization to create a cross functional team with app developers, I&O and security experience who can rapidly scale K8s platform. Cross functional teams are like a slice of multi layer cake, where each layer represents individuals who bring different value to the team.
Networking and Storage
The name of the game is auto scaling which allows flexibility in the system. Generally, network and storage provisioning require large lead times in a traditional infrastructure. Application owners will be concerned about having flexibility and agility. Containerization and Orchestration provides major benefits here and creates a new learning curve.
● Containers and Kubernetes introduce layers of extraction over the network, requiring the network to be managed through software or SDN. But if the current network tech stack does not support Kubernetes network interfaces, then additional software with CNI may be needed.
● Other part is load balancing; it is important to understand if the K8s platform load balancing is supportable in your current environment
● As mentioned earlier, this is a learning curve. It would be good to ensure K8s and container enablement teams consist of developers who understand DevOps but the team also has people who understand networking very well.
● Another important infrastructure component is storage. To deploy stateful applications in an environment which allows dynamic scaling, data persistence becomes a critical requirement
● Storage and data persistence may be easily supported by a CSP; however it is important to verify the storage service or devices supports container storage interface (CSI) for the K8s distribution your organization is planning to use.
Security and Governance:
Security is everyone’s job. I can dedicate an entire article to security for Kubernetes, RBAC and more. But in general, it is a common practice to refer to CIS benchmarks for security guidance on a topic like Kubernetes.
In a traditional environment, security and admin teams may be running vulnerability scans on your servers. But now, since you are bringing your own image and packaging it for your app, you must ensure you have a “clean” container image.
● Well, integrating image scanning to your DevSecOps will be beneficial for you and your organization. Every container image that gets deployed in your environment MUST BE SCANNED before it gets deployed in the Kubernetes environment.
● Roles and responsibilities, separation of duties and RBAC are another critical ingredient to building robust security. Application pods running in a multi-tenant environment, comes with its own challenges. In order to build robust security and isolation between pods, correctly configuring RBAC is a necessary step.
● Managing secrets, credentials are another critical security element. Needless to say, sensitive information like passwords, keys should be encrypted, stored away in a repository/secrets manager and should be retrieved only at run time. Your application must be configured to integrate with the secrets repository/manager.
Kubernetes Architecture
Before we go into monitoring and observability, it would be good to understand what the different components of Kubernetes are and why monitoring requires much more than server memory and CPU.
A detailed explanation of K8s components and architecture will be available in references. But getting back to what to monitor, think about where your application will be in this picture? Your application will be running in containers within nodes and scaled automatically as needed. Application health, its interaction with other nodes, other apps, storage, networking and the rest of the ecosystem outside of K8s cluster is managed by various components of the K8 cluster.
Now as you run your workloads on K8s environment, you will want to know what is going on inside, you would want to “monitor” various interactions and get “observability” into the state of your application.
The complexity of orchestration and interaction make it critical to put more emphasis on monitoring and observability.
Monitoring and Observability
Since we deploy and run applications in containers within nodes, it becomes critical to log, observe and analyze its actions in real time. Traditional tools cannot offer deep real time observability. Observing and monitoring applications in containers and K8s require K8s aware tools.
Monitoring platforms and skill sets to support such platforms are a specialty by itself, if you have an enterprise-wide platform, I would start there and review what it offers for containers K8s observability for the type of applications you are trying to host.
If the purpose of K8s platform is to host applications as a set of services then the service mesh layer will help monitor interactions between sets of services.
Additional References
