It’s been a long journey for Kubernetes over the last year. We first talked about Kubernetes here on 24 x7 IT Connection in August of 2015. Back then, Kubernetes was just a year old, with its 1.0 release landing in June of 2015.
Now, we’re up to Kubernetes 1.3, which was announced on July 6, 2016. The name of the game for this release is speed and scale, among a host of other feature updates and performance improvements. With the launch of Kubernetes 1.3, we are seeing a 2000 node, 60000 pod architecture on display which shows that performance and size are clearly targets for the platform.
With this release, we also see the move to add multiple namespaces for the 2000 node deployment sizes whereas previous clusters would have been configured under a single namespace. The reason for this as noted in the recent blog is that “we believe that users of such very large clusters are likely to use many namespaces, certainly at least 8 in the cluster in total.” according to the Kubernetes team at Google.
Moving from JSON to a Protocol Buffer solution for serializing data means that the launch performance was significantly improved in this release, and will continue to be rolled into future releases and subsystems to make sure that this fast-growing orchestration platform continues to be adapt to the needs of even the largest consumers. Some are concerned of the switch only because it opens the door to a new standard in the industry.
Google has a tendency to break new ground, and of there is any doubt on the abilities of the search giant to do so, just look at the wide reach of the Go programming language. There is no doubt that every aspect of Google internal and external architecture is targeted towards speed and scale. When it comes to Google speed measurement, nanoseconds are the new microseconds.
Kubernetes is clearly the hot topic lately, and with good reason. There are significant contributions to the ecosystem from dozens of vendors in the open source arena. This is a clear sign that Kubernetes is winning over the market place at the moment. The choice to make the Minikube project available is also a good one. Easing the onramp to getting started with Kubernetes will ensure that having a simple, fully-featured local deployment of the platform, is definitely what helps to bring more and more developers on board.
Opening the ecosystem to support the CoreOS rkt along with the OCI (Open Container Initiative) and CNI (Container Network Initiative) is another good move on the part of the Kubernetes team. This gives another nod to the OCI and could also help to speed some development on the standards being built around containers across the board.
There is much more within the release, but two more feature that stand out are the “PetSet” object addition and the updates to the Kubernetes GUI. The PetSet objet gives the ability to support persistent storage, permanent hostnames during pod restarts, and cluster startup options to bring certain containers up to support clustered application environments. The updates to the GUI also reflect that, while the API is the interaction of choice for many developers, that the need to provide a GUI management platform is table stakes in today’s environments.
Both the PetSet and GUI additions have a rather “Enterprise” feel too them. When it comes down to it, the Enterprise is a significant portion of the potential customer base for the future. It is good to see that the Kubernetes team is responding to the needs of the more persistent workloads which will help to entice the “legacy” clients towards the ecosystem.
All in all, it was a big release for Kubernetes. The momentum continues to increase, and the presence of Kubernetes at every other conference is surely a sign that we all need to take note and make sure that we start to evaluate where Kubernetes fits into our plans for now, or for the future.