Notes: reviewed KEP-281 ~ Dynamic Kubelet Configuration, explored kubeLinter ~ static analysis tool for Kubernetes #18
May 26, 2021
Quick notes from today:
reviewed KEP-281 ~ Dynamic Kubelet Configuration
- As part of my weekly regular exercises for getting really up-to-date with what’s going on in the kubernetes enhancements area, I try to read one KEP, per week. This time, I have picked up ~ KEP-281: Dynamic Kubelet Configuration.
- Major points from the KEP:
Dynamic Kubelet Configuration
allows a new Kubelet configurations to be rolled out in a live cluster.- The motivation, goals & design pattern is documented here
- I’m still reading this above document.
- The feature is deprecated at the version v1.22 due to lack of interest in promoting it to stable. Read here:
Dynamic Kubelet Configuration feature was promoted to beta in v1.11, 3 July 2018. As per the Avoiding Permanent Beta policy this feature is marked for deprecation as there were no interest expressed to promote the feature to stable. Removal of Dynamic Kubelet Configuration logic will simplify code and improve code reliability.
- Major points from the KEP:
- So, this KEP was around deprecating a long-standing beta feature. I learnt lots of new things while reading this so far. Major ones are:
- KEPs doesn’t necessarily means always proposing for new features. This also could mean deprecating old features for reasons like not enough feedback from community for the feature version promotion, removing the feature might increase code-readability, etc.
- I learnt about Avoiding Permanent Beta policy, which says:
For Kubernetes REST APIs, when a new feature’s API reaches beta, that starts a countdown. The beta-quality API now has three releases (about nine calendar months) to either:
- reach GA, and deprecate the beta, or
- have a new beta version (and deprecate the previous beta).
If a beta API has not graduated to GA after three Kubernetes releases, then the next Kubernetes release will deprecate that API version. There’s no option for the REST API to stay at the same beta version beyond the first Kubernetes release to come out after the release window.
- I got to read about the Kubernetes Deprecation Policy document.
explored kubeLinter ~ static analysis tool for Kubernetes
- This is in continuation to the DVO (deployment validation operator) project, I’ve been working on. The operator basically aims at running various validation checks against the kubernetes resource yaml manifest, thus performing a static analysis.
- The DVO project already have some validation checks like
minimum replica count
,resource request/limit
etc, defined under it. - The next goal here is to leverage the wide catalouge of validation checks that comes with this kubernetes go static analysis tool, KubeLinter.
- So, as part of the same goal, today, I spent time exploring the entire
kubeLinter
source code, broadly understanding the various levels of checks that are defined under it.- check templates are defined here ~ stackrox/kube-linter/pkg/templates
- Followed by that, I spent time understanding the new DVO operator’s controller & reconcillation logic.
- Understood how to use
kubeLinter
plugin to construct GVK (Group-Version-Kind) for different objects (like service, DeploymentLike, ReplicationController, Registry & All) usingobjectkinds.AllObjectKinds()
method. - Understood how to create a set of api groups/versions sorted with priority versions using
scheme.PrioritizedVersionsAllGroups()
method.
- Understood how to use
- The DVO project already have some validation checks like
This much helped me, in resolving couple of Jira tickets in the related EPIC as the validation checks asked in those tickets are already included in the kubeLinter
library.
That’s all for the day!
PS: Find here, the links to all the kubernetes-contributions for the month of May, 2021.