Tina Nolte
Tina Nolte is VP of Product at Spectro Cloud. She has been in and around cloud native and scale-out technologies for the better part of a decade at startups focused on cloud infrastructure and rack-scale architectures as well as at more established infrastructure companies. She has a Ph.D. in distributed computing from MIT and enjoys reading science fiction and building large Lego Star Wars kits.
I see it all the time.
Imagine this. There’s a Zoom call with a Kubernetes user and a Kubernetes vendor. At some point, the conversation turns to how the user’s Kubernetes deployment is managed.
Eventually, somebody is going to throw the term “lifecycle management” out there. Everybody is going to nod and agree that this is very important. Somehow most conversations don’t get into what exactly “Kubernetes lifecycle management” means.
If you ask somebody about lifecycle management in the context of an IT product you tend to hear about Day 0, Day 1, and Day 2. Day 0 is roughly the “Design” phase, where you determine what you’ll be deploying. Day 1 is the “Deploy” phase, or the first day the product is hands-on in your environment. Day 2 is the “Operate” phase; it would more accurately be termed “Day 2+”, but I digress.
What’s this mean in the context of Kubernetes lifecycle management? Let’s break it down by day:
Day 0 ‘Design’
In this stage, you need to answer critical questions about which Kubernetes platform you’ll be using as well as the environment it will exist in. You might even be considering the specifics of a particular application if the cluster is targeted at a very specific use case.
Key questions to ask yourself at this stage are:
- What integrations do you need, up and down your stack? OS, storage, network, load balancers, security, logging, monitoring…
- How much security investment will you make within the infrastructure itself? Security is a many-layered thing, but within the infrastructure itself will you utilize a security-hardened OS? How will you configure your network security and ingress policies?
- How will you perform the integrations? Do you need to write and maintain scripts? Are you ceding some of the integrations to a service provider? Will your chosen Kubernetes platform aid you in the integrations?
- How will your platform integrate with the GitOps or CI/CD toolchains that your organization uses today?
- How much work would be required if you needed to introduce a different set of technologies for some of your clusters? Keeping your options open in a universe where there is rapid development of new projects to help you in your tasks can help you accelerate the time to deployment for new projects.
Day 1 ‘Deploy’
After you’ve set all your plans in place, deployment is the next stage to tackle. You’ll get to see your plans take life.
- Key things to get right in this stage are:
- Being clear on what your multicloud and multicluster strategy is going to be and making sure you are managing how to support it. Your needs will inevitably evolve but having a roadmap can help to ensure that your investments today carry you into tomorrow. What’s the strategy for how large clusters will be? When do new ones need to be started? Are you in just one cloud today or multiple? Might that change? You’ll want to ensure that you deploy in a manner that can be kept consistent no matter how your strategy evolves.
- Configuring and deploying into your various environments — private cloud, public cloud, edge, or bare metal. Different environments have different stacks and very different needs for the management of infrastructure components. For example, you’ll need a plan to manage down to the OS layer in edge or bare-metal environments. In each case, it’s critical that you deploy with a methodology that can span the different environments. Operationally, consistency and familiarity help to keep things manageable.
- Setting up cloud accounts and settings. Each deployment environment has its own accounts that will need management. What is the way in which those credentials are stored and utilized? How are you and your vendors protecting your secrets so that a compromise is limited in impact?
- If you’re on the public cloud, setting up your preferences for utilizing spot or reserved instances. You’ll want to ensure that you understand how your choices impact your budget and make sure that you have systems in place to control spend.
Day 2 ‘Operate’
Many people earlier in their Kubernetes journey focus on Day 0 and Day 1, but don’t manage to afford enough time to think through Day 2 issues. Day 2 is focused on what happens once everything is deployed — how do you maintain your infrastructure? Onboard new users? Ensure the health of applications? Day 2 is all about keeping systems alive and healthy over time.
Key things to consider for this stage are:
- How does the solution you are using support your governance needs? Kubernetes is fast, which is part of its appeal. That doesn’t mean it shouldn’t be safe. You should ask how RBAC works in your new environment. Are you able to centralize policy across your organization and guarantee that provisioned clusters abide by your organization’s best practices? How about IAM and authentication? Can you manage policies across namespaces?
- What kind of SLA does the solution provide? Do you know what your level of support is and how to get it? Is the support level aligned to your needs? If you have applications in production then you need to understand your SLA levels.
- How will you provide visibility across deployments? Most organizations find that it is useful to be able to view their deployments from one location. Any solution you choose should enable you to do this easily.
- Are you able to track utilization? Do you have limits in place? The dynamism of cloud native workloads can unfortunately make costs difficult to predict. Make sure that you have a plan for understanding your utilization as well as your costs. Tracking should be granular enough that you have the ability to make actionable decisions based on the data. You should also be able to use quotas and limits to prevent yourself from being surprised.
- How do you plan on monitoring your solution? There should be monitoring available across your clusters so that you can get the information you need quickly and respond to changes in availability.
How do upgrades work in your solution? Technology doesn’t stand still; what you deploy you will need to upgrade. What’s your strategy for upgrades up and down your stack? How often will upgrades happen? How do they get pushed out? What happens if you encounter a problem; are rollbacks possible? How will they impact your application workloads?
- How does scaling work when your applications need more resources? Will your solution manage scaling automatically? Help support you in manual scaling decisions?
- What are your security-related procedures? Beyond technology, security requires clear processes and communication plans. These need to be revisited on a regular basis.
- What will help you ensure consistency in your deployments over time? Configuration drift happens over time, but can make maintenance and troubleshooting difficult. How do you ensure that your deployed clusters and associated infrastructure look the way that you intended them to?
- What is your plan for backups and restores? Sometimes, things just happen. What’s your plan for how to be ready if the worst happens?
Conclusion
This whirlwind tour of key questions and things to keep in mind while you consider lifecycle management for your Kubernetes deployments is just a start, but hopefully gives you a couple of things to think about. At Spectro Cloud, we designed a system from the ground up to help people through each stage, from Day 0 to Day 2. Spectro Cloud’s cluster profile concept provides an easy way to design, deploy, and operate whole Kubernetes stacks, while the system overall is designed with an enterprise in mind.
Want to talk about any of these questions? Suggest others that are your favorite? Drop us a line.
Feature image via Pixabay.
