• It’s been around for a while but is now being adopted at speed for managing applications at the edge
• But many believe that Kubernetes was written to maximise developer productivity at the expense of security
• That apparent drawback may already be slowing adoption

Kubernetes is popping up everywhere this year and by now should be a very bright blip on the digital service provider (DSP) radar. Whatever roles and alliances form at the busy intersection of 5G, cloud, the edge and corporate networks, it’s now clear that Kubernetes will likely play a huge part in the way the applications, and the ways in which they are used, evolves. That, in turn, means that telcos with aspirations to “go beyond connectivity” need to be taking notice of what looks like the primary way of getting those manageable and secure applications out to users via edge platforms and containers.

Kubernetes was originally Google’s own container orchestration platform, enabling it to horizontally scale its applications to ensure availability. Google Cloud claims the Kubernetes mission was, and is, to “automate the operational tasks of container management, and it includes built-in commands for deploying applications, rolling out changes, scaling them up and down to fit changing needs, and monitoring them for ease of management.”

Google ‘open sourced’ the code in 2014 and it’s now being developed and administered by the Cloud Native Computing Foundation (CNCF). The CNCF claims its research shows that one sign of Kubernetes’ increasing adoption is the rate at which back-end developers have made it the most widely used orchestration platform, with around a third of them having adopted it.

According to Daniel Bartholomew, the founder and CTO at ‘edge-as-a-service’ specialist Section, the finding shouldn’t come as a surprise. Writing a post in Thenewstack – which is sponsored by the CNCF – he outlines why he thinks edge developers in particular are embracing Kubernetes (or K8s as it is known – eight letters in the name after ‘K’ and before ‘s’) having chalked up an 11% increase in adoption in the past year. For context, Bartholomew says that the level of new adoption is three times the overall increase in the number of developers.

Why so popular?

Bartholomew maintains the key is that “the light-weight portability of containers makes them ideally suited to distribution, while their abstraction means they can be deployed to heterogeneous computer networks.” Kubernetes provides the much-needed orchestration required to coordinate the “distributed multi-region, multi-cluster, multi-provider topology” that is increasingly the norm.

So, the industry and its users appear to be adopting Kubernetes, and developers, being a bright bunch, have sensed the way the wind is blowing and are getting to grips with Kubernetes to be on hand as the industry scrambles to find the necessary expertise.

But it’s not all unfettered growth and sunny uplands. Kubernetes as currently arrayed comes with an alleged complexity and security downside, according to Red Hat and others. Red Hat says its OpenShift 4.10 Application platform was actually built around containers and Kubernetes, but it reports that deployment is difficult and that much of the problem centres on security.

Its State of Kubernetes security for 2022 report compiled from responses by 300 DevOps, engineering, and security professionals, found that 55% of the respondents said they’d had to delay the launch of an application during the past year because of security concerns, with more than 90% reporting at least one security incident in their Kubernetes environment in the past 12 months.

The report concludes that Kubernetes and containers, while powerful, were often designed for developer productivity at the expense of security. Respondents said they worried far more about misconfigurations in their container and Kubernetes environments than about cyberattacks.

Red Hat says it’s working hard to overcome these problems by giving its OpenShift platform some extra capabilities: top of the list is configuration management automation, which it claims should radically reduce the impact of human error. And it has decided to open source its Advanced Cluster Security (ACS) for Kubernetes, acquired last year via its purchase of StackRox. Red Hat claims the StackRox project aims to help simplify DevSecOps (DevOps with security built in) by integrating security capabilities within the development and deployment lifecycle.

Complexity Central

But the complexity problem may run deeper than this fix might imply. According to Bartholomew, security is at risk wherever complexity starts to get out of hand.

What happens, he asks, when you have an evolving and growing ‘distributed edge’ with its hundreds of endpoints, with different microservices being served from different edge locations at different times, running across heterogeneous infrastructure and a multiplicity of different providers?

On top of this there is significant developer specialization which compounds the problem since engineers tend to become extremely adept in specific areas where they focus on higher-level languages, tools and applications. When you add in machine learning specialization you end up with teams skilled at pushing models into production but possessing little expertise on the interactions of applications, hardware and networking to troubleshoot issues when they arise.

This might mean that some potential users of the distributed edge are “shying away” from the approach. But at present, interest in Kubernetes appears to have solidified and user growth and industry support is strong and growing.

For instance Microsoft says it’s looking to enable Kubernetes for “lightweight Windows edge devices,” powering Linux and Windows containerized workloads: The details of this move – known as Project Haven – were discussed at the recent Microsoft's ‘Build 2022’ event. We’ll be discussing the MS move in our next article on K8s.