Platform teams are expecting an increase in Kubernetes cluster count within their environments.
This is clear from the hyper-growth of cluster implementation that was reported in our latest State of Kubernetes survey (read this blog for more information), as well as the fact that we heard it directly from our customers during VMware Explore 2022. In these conversations, many explained that although they are early in their containerization journey, they expect their environments to become a massive fleet of clusters within the next year or two.
So, for those in the same spot, have you thought about the right time to adopt a Kubernetes management tool?
Well, if you are a system administrator or platform engineer in that scenario, your day-to-day may look like this:
1.You use tickets to trigger infrastructure requests from internal teams and add various tools manually or via script.
2.You have a few big clusters and use namespaces to isolate workloads for development, testing, or production, even though it does not offer the expected security isolation or resource control that your application needs.
3.You are manually managing clusters in multiple clouds, so you need to access multiple screens and cluster consoles just to assign one role binding. If you need to update that access, you’ll need to repeat this process for each cluster.
4.You don’t have a consistent process to back up your clusters. Every cloud is different and everything is very manual. You have not tested restoring from backup in all environments.
5.You don’t have a good strategy to automate the configuration of Kubernetes clusters and your process is laborious and error-prone.
To create consistency and improve some of those tasks, your organization may have a platform engineering team that starts to stitch together a few open source tools. This will ultimately pave a consistent path to production expected by the development teams, but the key here is to define whether or not this is a worthwhile undertaking for your team and your organization.
*Benefits and drawbacks of DIY (do-it-yourself)
*
We see a lot of companies starting on the DIY route to build a platform and leveraging open source software because there are a lot of benefits:
Cost – Using free, open source software is a cost-effective solution, which is especially appealing for small businesses or low-budget organizations that can't commit to expensive commercial software.
Customization – The platform can be customized to fit your specific needs and preferences, which is useful if you need a highly tailored solution with specific processes or workflows.
Control – You have complete control over the platform when you do things yourself, which is crucial if you have specific requirements that are not easily met by off-the-shelf solutions.
However, there are also relevant drawbacks that can impact an organization's time to market and derail its success:
Stress – Building a DIY platform is time-consuming and requires a significant amount of effort, which may mean dealing with bugs and handling trial and error yourself when integrating diverse tools.
Skills – For complex software, you will need a certain level of technical knowledge to be able to use it effectively. If you do not possess that expertise in-house, it may be costly to hire. Also, you may become dependent on a single person or system if the inner workings of the platform are not well documented.
Support – Open source software usually does not have access to the same level of support as commercial software. This can make it more difficult, or sometimes even impossible, to get the help you need in a timely fashion.
Teams must be willing to put in the work to define which tools and open source projects are needed in order to ease the burden on development teams. This is frequently a very complex and drawn-out process, as there are several options for building out each piece of the platform. Additionally, staying up to date with those projects is a massive undertaking since the Cloud Native Landscape is constantly evolving, not to mention personal preferences for a given tool or platform.
Mauricio Salatino, a former staff engineer at VMware, wrote a four-part blog series on the challenges of platform building on top of Kubernetes, starting with an internal development environment (IDE) and moving to a production path, including a self-service approach to infrastructure with abstractions in place.
For this blog, we will focus on the path to production only, assuming organizations are growing their Kubernetes cluster count, facing the complexities of multi-cloud, and trying to ensure security is embedded in their platforms.
The path to production: How do I get there?
As we mentioned earlier, there are several pieces in the Kubernetes management puzzle and many tools and decisions must come together to form a comprehensive platform that can support developers with a simplified, consistent, and secure path to production. Those pieces must include the following, based on the listed considerations:
Identity and access management
Who has access to what, and what are their permissions to see or create resources? Can you connect your environments to a centralized identity management solution? Do you know Pinniped?
Managing environments and cloud providers integrations
Where will things run? What level of isolation do you need between different teams and applications? Do you want to enable teams to request environments on demand? How will you manage cluster lifecycle operations?
Policy management
How will you prevent "noisy neighbor" issues? How will you control container images that may be deployed on your clusters? Do you know Open Policy Agent (OPA) Gatekeeper? Are you aware pod security policies (PSPs) will be removed from Kubernetes in v1.25?
Continuous deployment
How will you deploy new versions of your applications when they are ready? Do you want to implement different release strategies (e.g., blue/green, feature flags, canary release, A/B testing, etc.)? Do you want to implement GitOps? Do you know Argo CD or Flux CD?
Infrastructure as code
How will you facilitate the consistent provisioning and management of clusters in different environments? How do you make it easier to track changes and roll back if needed? Do you know Terraform?
Security
Do you need encryption and transport layer security (TLS) enabled at the infrastructure level? For all environments? Do you allow privileged containers to run in your environments?
Backups
How do you prevent outages or human error? How do you ensure data is protected and restorable? Can you easily restore or move workloads to different clusters? Do you know Velero?
As your organization understands this list of requirements and what is desired by your team, you will be able to choose between a DIY approach or a partnership with a vendor who can provide a platform that addresses some of those challenges out of the box.
The right time to invest in a Kubernetes management tool
There are a few key factors to consider when deciding whether or not to invest in a Kubernetes management tool:
Scale – If you are running a production-grade Kubernetes service(s), a management tool can help you with deployment, scaling, and monitoring.
Complexity – If your environment is complex with many different components and microservices, a management tool can help you with cluster configuration, management, rollouts, and rollbacks.
Team size – If you have a large team of engineers working on Kubernetes clusters, a management tool can help you with collaboration, access control, and auditing. Conversely, if you have a small team that needs to be efficient, being able to create once and apply many becomes very valuable.
Ultimately, the right time to invest in such a tool will depend on your specific needs; but one thing is certain, and that is that the Tanzu team can help you upgrade your day-to-day to this:
1.You are able to offer pre-built clusters, namespaces, or workspaces to your development team with the desired versions of applications or tools they need.
2.You can easily spin up new clusters or even multiple clusters in a single deployment, either on-premises or in clouds, and have the flexibility to support the security isolation and resource control your application needs.
3.You have multiple clusters attached to your management hub and can apply identity and access management easily. You can also apply policies for security, networking, and quota to a group of clusters that will inherit the same configuration.
4.You automate your backup and recovery processes and can move applications between any cluster and run on any cloud or on-premises data center.
5.You manage your cluster configuration in a single reusable YAML file and apply it to a cluster group so that all clusters inherit the same configuration.
With that upgrade, you will have more time to focus on providing real value to your end customers. When the economy is tough, your time is even more precious and you must focus on your core business.
This is becoming increasingly clear to our customers as they express that they are now willing to pay for services and support for essential Kubernetes tools such as data security, cluster lifecycle management, platform monitoring, and platform automation for a platform experience that can introduce consistency and agility to their operations.
Top comments (0)