 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Last week, the Kubernetes API Gateway Project, a humongous collaborative effort, reached its version 1.0 general release. At KubeCon+CloudNativeCon last week, two of the principal maintainers shared the lessons they acquired managing the project, which aims to unify how Kubernetes handles edge traffic.
One big take-away: Beta releases are not worth the effort.
“Our opinion is that a that just is not worth it,” said Rob Scott, Google staff engineer in charge of Kubernetes networking, in a presentation about the 1.0 release. “The value of beta version just does not add up.”
Going forward the open source project will go with a different release model, based on two release types: experimental and standard.
Four years in the making, the Kubernetes Gateway API had over 170 contributors (the most yet of any #K8s project) and 30 contributing organizations. It was “what we think is one of the most collaborative APIs in Kubernetes history,” Scott said.
To hear Scott tell it, bringing the Gateway API to 1.0 general availability was a difficult birth. “We took a hard look at this,” he said. “It was very painful, and we are trying to avoid that going forward. So one way to do that [is] it’s just not happening.”
What they learned is that every new version of the API brings with it additional overhead, to the maintainers and to the users.
Migration to a new version can be painful, Scott said, recalling the difficulty transitioning off the Ingress software to the Gateway itself was particularly aggravating for many users. It takes months before an experimental version gets before a user, and months more before they get around to using it and offering feedback. Testing across multiple API versions can also get complex quickly.
The Beta release has long been a vital part of the release process for most software packages. Upstream Kubernetes APIs have traditionally had three release cycles: Alpha first, then Beta, the General Release.
An alpha release is where new features are introduced, though they may or may not work on your machine. The beta version, which usually follows the alpha, informally offers the assurance that the software probably does work, though not officially. It offers the informal assurance that most of the bugs are sorted. The final GA release assures everything operates as it is advertised on the tin.
The API Gateway will simplify this approach somewhat, into two channels: standard and experimental. New features will be introduced, tested and hardened, under a v1alpha2 release. When they are ready to go they will move to v1. There will be no v1Beta releases.
Achieving production status for a new feature is no easy feat in this scheme, mind you.
“We’re not doing this lightly, we have a very stringent graduation criteria for anything that goes from experimental to standard,” Scott said. The feature, or object, must have full conformance testing, at least six months in the experimental channel, and no major changes for at least one release cycle and three months. It also must be pretty widely used by that point.
“If you want to try something new, maybe not in production, use the experimental channel, you can get all the new features with all our [Custom Resource Definitions]. On the other hand, if you want something production-ready, use our standard channel, and you’ll get production-ready CRDs, ” Scott said.
The release v1 included beta API versions (v1beta1) namely:
In the upcoming v1.0 release, these features will all graduate to a GA API Version, according to the documentation.
