Author: Eric Chiang
https://coreos.com/blog/kubernetes-1.8-announcement
Today, along with the rest of the Kubernetes community, we’re cheering the release of Kubernetes 1.8. The momentum within the community continues to grow as organizations embrace Kubernetes as the leading platform for container orchestration, and this release delivers a version with the richest feature set yet.
As always, much credit is due to the leadership of the Special Interest Groups (SIGs) that guide feature planning and development for Kubernetes. CoreOS is actively involved in most of these SIGs, playing a significant role in this release from its product management to overseeing development of specific features in groups like SIG Auth.
Caleb Miles and I would also like to acknowledge our release team peers – especially release lead Jaice Singer DuMars, Kubernetes ambassador for Microsoft – for their often herculean efforts. CoreOS led the release of Kubernetes 1.6, the first time a release was managed outside of Google. The release team for Kubernetes 1.8, which included representatives of Avi Networks, the Cloud Native Compute Foundation (CNCF), CoreOS, Google, Heptio, Microsoft, and Samsung, reaffirms that Kubernetes development is now truly a cross-company, community effort.
The 1.8 release continues the Kubernetes community’s commitment to security and extensibility with work on stabilizing existing features, even as new ones are added. Here are some of the highlights.
RBAC graduates to Stable
Over the past few releases, there’s been significant effort to improve the security mechanisms built into Kubernetes. One such mechanism is role-based access control (RBAC), which lets admins control access to the Kubernetes API. Following extensive testing and production use, RBAC graduated from beta to GA with no API changes to the core types, and in a major milestone, has officially been granted Stable status in Kubernetes 1.8.
As one of the early adopters, CoreOS has shipped RBAC since Kubernetes 1.3 as part of our Tectonic platform. Today, many distributions enable RBAC by default, and its new Stable status ensures more apps and users can depend on this advanced security feature.
The Kubernetes community will continue to develop features that complement and improve the usability of RBAC in future versions. For example, new APIs that let individual users determine what actions they can take and reason about their own permissions.
Advanced auditing is Beta
Advanced auditing, an important part of ongoing security operations, has been promoted to beta after being introduced as alpha in Kubernetes 1.7. This feature introduces formatted audit logs, policies to control what’s audited, and a webhook to send events to external services. Audit events can now be configured to include entire request payloads, aggregated in a central location.
Promoting this feature to Beta declares that the audit event format will only make backward compatible changes. This creates an opportunity for the community to start experimenting with ways of consuming, displaying, and acting on events from the audit log webhook. An early example of this is theaudit2rbac tool, which consumes audit events and to automatically create RBAC profiles.
Workload APIs are maturing
Also promoted to beta in the 1.8 release delivers are the Workload APIs, which provide the abstractions required to manage applications deployed to Kubernetes. There are four kinds:
- DaemonSets manage the complexity of running a Pod on all nodes, or a subset of nodes based on user specified criteria.
- A ReplicaSet provides a basic high availability primitive to ensure a specified number of copies of a Pod are running.
- The Deployment controller enables declarative updates to Pods and ReplicaSets, providing critical functionality such as canaries and rolling deployments.
- A StatefulSet is one mechanism for supporting Pods that require persistence by imbuing them with a unique identity to enforce ordering and persistent volume access guarantees.
The Workload APIs provide a powerful toolbox for application developers. One example of a project which relies on the Workload APIs is Bootkube, created by CoreOS, which bootstraps highly available self hosted clusters.
For Kubernetes 1.8, these APIs have been moved out of theextensions/v1beta1 API group into a dedicatedapps/v1beta2, laying the groundwork for workloads to be promoted to GA in a future release. The change comes with several cleanups to the APIs, as well. Workloads API should now work better with update strategies such as kubectl apply, and certain inconsistent behaviors that were allowed in previous versions of the API have now been deprecated.
Alpha support for CRD schema validation
Work on CustomResourceDefinitions (CRDs), which allow third-party applications such as Operators to register custom API types, is also moving forward. For the 1.8 release, CRDs have added schema validation in Alpha for a more robust client experience. This change lets CRDs define server-side validation of their resources, instead of the current schema-less “bag of values” that clients use today.
Validation brings CRDs closer in line to real API resources and is part of ongoing efforts to make Kubernetes more extensible. Extension points like CRDs enable other projects to provide value on top of Kubernetes without complicating core components, and CoreOS uses them extensively in Tectonic for coordinating upgrades, driving dynamic monitoring, and orchestrating complicated apps on top of Kubernetes. We’ve seen a healthy community of projects already using CRDs, and validation comes as a welcome improvement.
As always, however, Alpha features come with caveats – mainly that the Kubernetes project reserves the right to remove or change this feature in backward-incompatible ways. Still, while it shouldn’t be used for production work, CRD validation is functionality worth keeping an eye on for future releases.
Kubernetes development continues
Plenty of other features received attention in Kubernetes 1.8, including new features introduced as Alpha for this release and others that have graduated to Beta or Stable. To see a full breakdown, consult the release notes on GitHub.
CoreOS will continue to work alongside the greater Kubernetes community to ensure that Kubernetes users benefit from the most advanced, stable, and secure platform available for container orchestration.
What does this mean for Tectonic?
Tectonic is CoreOS’s enterprise-ready Kubernetes platform that delivers production-ready orchestration for containers. Because Tectonic is based on pure, upstream open source Kubernetes, the CoreOS engineering team is able to incorporate the latest Kubernetes features into our platform quickly, while still delivering the essential enterprise features on top of Kubernetes that only Tectonic provides. That process is ongoing, so Tectonic customers can expect a version that incorporates Kubernetes 1.8 soon.