Over the course of recent development of the `componentconfigs` package, it became evident that most of the tests in this package cannot be implemented without using a component config. As all of the currently supported component configs are external to the kubeadm project (kubelet and kube-proxy), practically all of the tests in this package are now dependent on external code. This is not desirable, because other component's configs may change frequently and without much of a notice. In particular many configs add new fields without bumping their versions. In addition to that, some components may be deprecated in the future and many tests may use their configs as a place holder of a component config just to test some common functionality. To top that, there are many tests that test the same common functionality several times (for each different component config). Thus a kubeadm managed replacement and a fake test environment are introduced. The new test environment uses kubeadm's very own `ClusterConfiguration`. ClusterConfiguration is normally not managed by the `componentconfigs` package. It's only used, because of the following: - It's a versioned API that is under the control of kubeadm maintainers. This enables us to test the componentconfigs package more thoroughly without having to have full and always up to date knowledge about the config of another component. - Other components often introduce new fields in their configs without bumping up the config version. This, often times, requires that the PR that introduces such new fields to touch kubeadm test code. Doing so, requires more work on the part of developers and reviewers. When kubeadm moves out of k/k this would allow for more sporadic breaks in kubeadm tests as PRs that merge in k/k and introduce new fields won't be able to fix the tests in kubeadm. - If we implement tests for all common functionality using the config of another component and it gets deprecated and/or we stop supporting it in production, we'll have to focus on a massive test refactoring or just continue importing this config just for test use. Thus, to reduce maintenance costs without sacrificing test coverage, we introduce this mini-framework and set of tests here which replace the normal component configs with a single one (`ClusterConfiguration`) and test the component config independent logic of this package. As a result of this, many of the older test cases are refactored and greatly simplified to reflect on the new change as well. The old tests that are strictly tied to specific component configs (like the defaulting tests) are left unchanged. Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com> |
||
---|---|---|
.github | ||
api | ||
build | ||
CHANGELOG | ||
cluster | ||
cmd | ||
docs | ||
hack | ||
LICENSES | ||
logo | ||
pkg | ||
plugin | ||
staging | ||
test | ||
third_party | ||
translations | ||
vendor | ||
.bazelrc | ||
.bazelversion | ||
.generated_files | ||
.gitattributes | ||
.gitignore | ||
.kazelcfg.json | ||
BUILD.bazel | ||
CHANGELOG.md | ||
code-of-conduct.md | ||
CONTRIBUTING.md | ||
go.mod | ||
go.sum | ||
LICENSE | ||
Makefile | ||
Makefile.generated_files | ||
OWNERS | ||
OWNERS_ALIASES | ||
README.md | ||
SECURITY_CONTACTS | ||
SUPPORT.md | ||
WORKSPACE |
Kubernetes

Kubernetes is an open source system for managing containerized applications across multiple hosts. It provides basic mechanisms for deployment, maintenance, and scaling of applications.
Kubernetes builds upon a decade and a half of experience at Google running production workloads at scale using a system called Borg, combined with best-of-breed ideas and practices from the community.
Kubernetes is hosted by the Cloud Native Computing Foundation (CNCF). If your company wants to help shape the evolution of technologies that are container-packaged, dynamically scheduled, and microservices-oriented, consider joining the CNCF. For details about who's involved and how Kubernetes plays a role, read the CNCF announcement.
To start using Kubernetes
See our documentation on kubernetes.io.
Try our interactive tutorial.
Take a free course on Scalable Microservices with Kubernetes.
To use Kubernetes code as a library in other applications, see the list of published components.
Use of the k8s.io/kubernetes
module or k8s.io/kubernetes/...
packages as libraries is not supported.
To start developing Kubernetes
The community repository hosts all information about building Kubernetes from source, how to contribute code and documentation, who to contact about what, etc.
If you want to build Kubernetes right away there are two options:
You have a working Go environment.
mkdir -p $GOPATH/src/k8s.io
cd $GOPATH/src/k8s.io
git clone https://github.com/kubernetes/kubernetes
cd kubernetes
make
You have a working Docker environment.
git clone https://github.com/kubernetes/kubernetes
cd kubernetes
make quick-release
For the full story, head over to the developer's documentation.
Support
If you need support, start with the troubleshooting guide, and work your way through the process that we've outlined.
That said, if you have questions, reach out to us one way or another.