This will be a short blog that will hopefully help you to be aware of the nuances of Kubernetes features, how some of the major public Cloud providers consider them and what resources you can access for reference. This may help in situations when deciding whether certain features are appropriate for a given release and flavour of Kubernetes & Viya.
As a reminder the Kubernetes (K8s) documentation is a rich set of materials that goes into various levels of details. There is also a set of useful blog posts https://kubernetes.io/blog/. With all this this content, you’re very likely to find most of the information you need. But 😊 if like me you sometimes skim read to get to the answers you are looking for, you should take a moment to ensure you have the complete context regarding the K8s features. An example I was excited to see a feature “CPUManager” that allow K8s pods to have exclusive use of CPUS/cores (“exclusive” versus “shared pool”, within the Guaranteed QoS category) . What I did not know/appreciate initially is this K8s feature is at Beta release. And then having read some more I realized (I know, I’m not the fastest at putting 2 + 2 together) that there are also Alpha levels features available.
Before we move on, did you know that SAS Viya users can see which features have been switched on in their release of SAS Viya? See this SAS documentation for more information.
From the K8s documentation pages, there’s an excellent description of Feature Stages:
K8s Feature stages (taken from the official K8s documentation)
A feature can be in Alpha, Beta or GA stage. An Alpha feature means:
- Disabled by default.
- Might be buggy. Enabling the feature may expose bugs.
- Support for feature may be dropped at any time without notice.
- The API may change in incompatible ways in a later software release without notice.
- Recommended for use only in short-lived testing clusters, due to increased risk of bugs and lack of long-term support.
A Beta feature means:
- Enabled by default.
- The feature is well tested. Enabling the feature is considered safe.
- Support for the overall feature will not be dropped, though details may change.
- The schema and/or semantics of objects may change in incompatible ways in a subsequent beta or stable release. When this happens, we will provide instructions for migrating to the next version. This may require deleting, editing, and re-creating API objects. The editing process may require some thought. This may require downtime for applications that rely on the feature.
- Recommended for only non-business-critical uses because of potential for incompatible changes in subsequent releases. If you have multiple clusters that can be upgraded independently, you may be able to relax this restriction.
Note: Please do try Beta features and give feedback on them! After they exit beta, it may not be practical for us to make more changes.
A General Availability (GA) feature is also referred to as a stable feature. It means:
- The feature is always enabled; you cannot disable it.
- The corresponding feature gate is no longer needed.
- Stable versions of features will appear in released software for many subsequent versions.
So just from this page you can quickly see points of interest.
Alpha features are disabled by default, but beta features are enabled by default.
Customers wanting to use K8s in production/business critical use cases, need to understand the impact of using alphas and betas. In summary alpha features should not be used with production systems, but beta features can be if multiple K8s clusters of differing K8s versions are available.
By now you might ask:
- “Where can I find a list of features by feature stages?” Answer can be found here.
- “How does the K8s deprecation policy work?” Answer can be found here.
- “Where can I find the list of features which graduated to GA or were deprecated?” Answer can be found here.
- “How or does this impact SAS Viya deployments in anyway?” See the last section of the blog below.
As an FYI, my colleague Raphael Poumarede (@RPoumarede) is currently working on a SAS Communities post. This discusses the impact a recent deprecation of K8s APIs has on current Viya releases.
Which then leads us on to the public Cloud providers and K8 specific providers. What’s their current (as of March 1st, 2022) approach to dealing with alpha and beta features. The table below provides a quick summary but if you want more detail, you’ll need to reach out to a Cloud provider support page/team.
|
|
AKS (Azure)
|
EKS (AWS)
|
GKE (GCP)
|
Openshift
|
|
Supports beta features?
|
Yes
|
Yes
|
*Yes
|
Yes, if the beta is well documented.
|
|
Supports use of alpha features?
|
No
|
No
|
Yes but in specific alpha cluster instance(s).
|
To some degree. Contact RedHat for specifics
|
|
Additional notes
|
|
|
*In some cases, GKE may have disabled a beta feature for a specific GKE control plane version.
|
|
In addition, some public Cloud providers also provide “preview” access to upcoming features. For Azure, AKS updates on previews and features that have become GA can be found here:
With this information in front of us, what does this mean for SAS teams and SAS Viya? Well it probably helps if we are being specific about the “which teams at SAS”. 😊
For customers and SAS professional services consultants, hosting teams, technical support, and pre-sales engineers the use of GA features is a given. However, if a given beta feature proves to be useful and beneficial in the usage and operations experience of a SAS Viya environment, then both the customer and SAS team should note that the feature is beta and that customer needs to monitor any graduation or deprecation of that feature. Knowing what flavour of K8s and what version is a good starting point. This is especially important for open source flavours of K8s. This is because customers have the flexibility to turn on and off both alpha and beta features.
The other teams at SAS are of course the R&D and product management teams. In short, SAS’s R&D engineering approach will be to use K8’s GA features only when developing Viya features.
Thanks to my colleagues at SAS for their contributions to this blog.
Find more articles from SAS Global Enablement and Learning here.
