Centralised Documentation of CNCF-Conformant Kubernetes Distribution Variations in Ports, Paths, and Components #48778
Labels
kind/feature
Categorizes issue or PR as related to a new feature.
needs-sig
Indicates an issue or PR lacks a `sig/foo` label and requires one.
needs-triage
Indicates an issue or PR lacks a `triage/foo` label and requires one.
sig/docs
Categorizes an issue or PR as relevant to SIG Docs.
What would you like to be added?
[existing, however] I propose creating a centralised section in the official Kubernetes documentation that provides a comprehensive table listing CNCF-conformant Kubernetes distributions.
The table should outline key details such as:
Ports used by critical components like etcd, kube-apiserver, and kubelet.
Default PKI certificate paths for each component.
Deviations from standard Kubernetes configurations, if any.
This table would act as a reference for understanding the variations in Kubernetes distributions and help teams build tools and solutions that cater to diverse environments.
Basically a overview of distro given by the distro owners how it deviates from upstream k8s.
Why is this needed?
Monitoring and observability solutions often need to support multiple Kubernetes distributions, each of which might have slight differences in configuration, such as:
Non-standard ports for components like etcd or kubelet(if any).
Different PKI certificate paths for authentication and encryption.
Variations in component behavior or configurations that deviate from upstream Kubernetes.
Currently, there is no centralized place to find these details. This leads to challenges for organizations and solution providers who need to support multiple distributions
By documenting these variations in a standardised table, we can:
Simplify the development and deployment of observability tools across diverse Kubernetes distributions.
Reduce the troubleshooting burden for users and vendors.
Promote transparency and a better understanding of Kubernetes environments.
This enhancement aligns with Kubernetes' ethos of being distribution-agnostic while acknowledging practical deviations in implementations
Thank you.
The text was updated successfully, but these errors were encountered: