Kubernetes 1.2 Offers Rolling Updates, Persistent Volumes
At the Google GCP Next conference last week in San Francisco, the company demonstrated how it was possible with Kubernetes to update a heavily used distributed application while keeping that app running.
For a Kubernetes 1.2 on-stage demo, Greg DeMichillie, director of program management for Google Cloud Platform spun up a service and then used load testing software to dispatch 20,000 requests-per-second to the service.
“Now if I did this demo 18 months ago, this would have been considered an amazing thing — who would have had the ability to run services at this scale? Now, it’s my ‘Hello World,’” DeMichillie said.
— The New Stack (@thenewstack) March 23, 2016
The exercise was set to show off the latest capability of Kubernetes — to show how the software could update a service with zero downtime. For the Internet services companies where even a minute of downtime could cost dearly in lost revenue, the capability showed off the powerful benefits of microservices-based container architecture.
In the process of a couple of minutes, DeMichillie was able to upgrade all the pods of the distributed application, without incurring any downtime.
Google continues to invest heavily in the development and marketing of Kubernetes, its container orchestration tool designed to work not only with the Google Cloud Platform (GCP) but can be used to set up private cloud and other cloud-based container-based services.
The role of Kubernetes, noted Brendan Burns, is to abstract away the data center configurations that developers and administrators typically have to wrangle with when deploying a new application.
With Kubernetes, “the machines disappear below the infrastructure,” Burns said at the conference.
The most recent release of the software, which the company showed off at GCP Next, comes with some new features, including rolling updates, persistent storage, and security enhances, all of which enable a more seamless deployment process.
In one GCP technical session, Tim Hockin, Google senior staff software engineer and engineering manager, talked more about the rolling upgrades and several other new features.
The rolling update feature came about as a refinement from the Google’s Borg, an earlier generation container orchestration software the company used internally. With the Borg, the company learned not to couple the update system too tightly to the rest of the software. “Updating Different types of applications have different types of updates,” Hockin said.
The update process works as a service. The update operation is conducted server-side, and the user sets the parameters, including how fast the update should go and what to do if there is a problem.
This service can be used in conjunction with another Kubernetes service, that of the graceful termination of pods. With graceful termination, pods are discontinued when the last user finishes the session. New users are redirected to the newer, updated pods.
Kubernetes 1.2 also tackles one of the most difficult challenges of working in containers these days, namely how to deal with storage. Containers, or pods, which is what Google calls groups of containers working on a similar task, may come or go, depending on the workloads. But the application data needs to be stored permanently.
Currently, this requires the developers to provision storage manually, usually by putting in a ticket request or some other manual process. Ideally, “We like to talk about treating your storage like cattle,” Hockin said, referring to how storage should be managed in en mass, not as individual partitions.
Container software providers are beginning to make life easier for the developer. The first product release of Mesosphere Marathon supports persistent storage, and Crate recently released a database system that can be encapsulated in containers.
With this release of Kubernetes 1.2, users can auto-provision storage. A developer can request storage from Kubernetes, which will provision it if readily available, or even create new blocks of storage if no storage is available — assuming the system has back-end storage services, such as GCP, AWS, or a private instance of OpenStack. Kubernetes supports about 20 different storage formats.
“You can write all this data to a persistent volume, and then you can kill your application. You can hand off that data to a different pod because you still own that data. We never destroy it until you tell us it O.K,” Hockin said.
Multi-Zone Clustering and Security
Hockin discussed some other new Kubernetes features as well.
To further aid in making applications as seamless as possible, Kubernetes now supports multi-zone clustering. A cluster can run across multiple availability zones, such as the regional zones offered by GCP or AWS.
“It’s 2 AM, Sunday night. Do you want your pager to go off because Google brought a zone down?” Hockin asked, rhetorically.
This work is part of an ongoing project codenamed “Ubernetes,” to build a federated model of container orchestration across multiple clusters, Hockin said.
To boost security, the Kubernetes development team also took a page from the 12-Factor App, a widely circulated manifesto on the most efficient way of building cloud services. One of the suggestions, #12, includes including the configuration work in within the app itself.
To this end, Kubernetes now offers an API to manage sensitive authentication information, such as an SSH key, API token. “We are giving you an API to manage your secrets,” Hockin said. When a user starts an application, the security API is then called to provide the authentication credentials at runtime.
This last feature, however, may need some more work. It stores the passwords and other sensitive information as plain-text, which if accessed by a malicious hacker could compromise security, pointed out Richard Steenberg, principal software engineer at WePay, which uses Kubernetes for its operations.
Feature Image: Brendan Burns, senior staff software engineer at Google.