May 02, 2019
Alex Hisaka
D2iQ
Kubernetes provides efficiencies while also introducing new complexities:
- The Kubernetes landscape is vast
- It can be hard distinguishing between a Kubernetes feature and a Kubernetes community project
- You need to understand other sophisticated technologies to deliver Kubernetes-as-a-Service
- Day 2 operations are difficult
- Kubernetes falls short in some regards
1. Getting a grasp on the Kubernetes landscape
Understanding the Kubernetes landscape is a critical component to getting started since you need to include a variety of other technologies and services to deliver an end-to-end solution.
But the state of each supplemental technology varies significantly.
For instance, some solutions date back to the days when Unix reigned supreme, and other solutions are less than a year old with low commercial adoption and support.
So, in addition to figuring out which ones you can safely include in your implementation, you need to understand how each component fits into a larger solution. While you can find plenty of information and documentation about this, it's scattered and tough to distill. As a result, it's difficult to figure out the best solution for a particular job. Even once you nail down the solutions you'll use, you need a solid plan around how to deliver these as-a-service and manage them on an ongoing basis.
2. Understanding the difference between features and projects
The challenges don't end there. While it's helpful (yet difficult) to find advice on how to manage the lifecycle of a project, it doesn't resolve the confusion that arises when it comes to distinguishing between a Kubernetes feature and a Kubernetes community project.
The beauty of an open-source technology, like Kubernetes, is that the community of users can create and share innovative uses. However, that same benefit can also muddy the waters. While special interest groups can develop features that are added to core Kubernetes, other standalone projects remain just that--outside of the core. Projects contributed by an individual developer or vendor might not be ready for prime time. In fact, many are in different stages of development. (Note: If it isn't in GitHub, it's not an official Kubernetes feature.)
3. Becoming knowledgeable on more than Kubernetes
All this confusion is compounded by the complexity of delivering solutions. Kubernetes itself is sophisticated. But organizations also want to deliver other elaborate solutions—like distributed data stores—as-a-service. Combining and managing all these services can further amplify the challenges. Not only do you need to be an expert in Kubernetes, you need to be skilled in everything you're going to deliver as part of an end-to-end service.
4. Day 2 operations are difficult
Going live with Kubernetes is one thing; managing it is another. Kubernetes management is a largely manual exercise because all you get with Kubernetes is Kubernetes. The platform doesn't come with anything to run it, so you need to figure out how to deliver resources to Kubernetes itself—no easy feat.
When it comes to serving the needs of the enterprise, you'll need to security harden Kubernetes and integrate it with your existing infrastructure. Besides handling upgrades, patches, and other infrastructure-specific management tasks, you'll need the right knowledge, expertise, processes, and tools to operate and scale Kubernetes effectively. Consider that in order to deliver Kubernetes to different lines of business and different users as-a-service, you need to resolve the following management challenges:
- Multiple Kubernetes clusters are difficult to manage: Managing multiple Kubernetes clusters puts more pressure on your internal teams, requiring a big time and resource investment.
- Monitoring and troubleshooting Kubernetes is difficult: As with any complex system, things can and do break. With Kubernetes you can't test at scale, it's difficult to fix if something goes wrong, and you can't automate upgrades.
- Difficult to support at scale: For an enterprise organization, scale is critical. But it's tough to support scale with out-of-the-box Kubernetes. Versioning multiple clusters is time consuming and difficult, and requires special resource planning. Plus, in order to truly scale the platform, you need to manually run configuration scripts.
5. Understanding where Kubernetes falls short
It's wise to understand the top concerns of Kubernetes users that the Cloud Native Computing Foundation (CNCF) uncovered in a recent poll. Besides easy management, they noted the following:
- Better security. Users want to see more security baked into Kubernetes for wider deployments. This is especially critical for enterprise deployments, as noted above. As an example, the Kubernetes administrative console can serve as a conduit for attacks—if an attacker gains access to a single cluster, he can potentially control all of your clusters. In fact, hackers can even identify an unprotected Kubernetes' back-end database simply by searching on web crawlers.
- Better interoperability. Organizations can and do deploy Kubernetes clusters in a variety of ways. While 42% of Kubernetes clusters are on premise, another 57% are deployed on Amazon Web Services, and 37% are deployed on multiple clouds. You don't want to run Kubernetes differently in each environment, using the discrete processes and templates unique to each provider. Learning and maintaining different management approaches could quickly become overwhelming. Ideally you can run Kubernetes anywhere—such as on-premise and in the public cloud—with the same API, same user interface, the same command line.
Learn how to navigate through these challenges by downloading "Kubernetes Bootcamp: How to Deliver an End-to-End Solution."
