e49f44d89c
Automatic merge from submit-queue (batch tested with PRs 41146, 41486, 41482, 41538, 41784) client-gen: independent scheme for clientsets This PR adds a clientset internal scheme instead of using `pkg/api.Scheme`. **The clientset API stays the same.** In detail: - introduce a scheme for each clientset, i.e. do not use `pkg/api.Scheme+Registry+Codec+ParameterCodecs`. This makes it easier to compose client-go's clientset (which is rewritten in `staging/copy.sh` and therefore hardcoded to use `k8s.io/client-go/pkg/api.Scheme+Registry+Codecs+ParameterCodecs`) with third-party clientsets (kube-aggregator, openshift, federation) which are not rewritten using `copy.sh` as all of them are self-contained and therefore relocatable. This fixes https://github.com/kubernetes/kubernetes/pull/41403/files#diff-76edfb07dee54ff7ddeda25c33c10d29R81 and prepares client-gen for use in OpenShift. - register types into the clientset scheme via `AddToScheme` for versioned clientsets. This decouples the client-go clients from announce+registration (internal clients continue using announce+registry and apigroup installers). This reduces complexity for client-go, possibly remove the necessity for the announce+register machinery for many use-cases, maybe even to delete it mid-term. - port federation and testgroup `install/install.go` to `announced.GroupMetaFactory` in order to have a proper `Install.Install(...)` func for registration. With the first change it's easy to add the types of one clientset to the scheme of the other using the `clientset/scheme.AddToScheme` method. This allows to use cross-clientset `runtime.RawExtensions`: ```golang import ( "k8s.io/client-go/kubernetes" clientsetscheme "k8s.io/client-go/kuberentes/scheme" aggregatorclientsetscheme "k8s.io/kube-aggregator/pkg/client/clientset_generated/clientset/scheme" ) kclientset, _ := kubernetes.NewForConfig(c) aggregatorclientsetscheme.AddToScheme(clientsetscheme.Scheme) ``` Kubernetes types with a `RawExtension` can en/decode aggregator types after this. TODO: - [x] fix fake clientsets - [x] get the `*Options` types registered correctly for core, compare DO-NOT-MERGE commit. - [x] get prefered version right in internal client. Do we need all versions registered in the internal client to support negotiation? - [x] run `staging/copy.sh` and run tests: https://github.com/kubernetes/kubernetes/pull/41744 - ~~[ ] fixup usage through-out the code-base~~ - **Follow-up**: move `import_known_versions.go` files somewhere such that import of the `api.Scheme` package automatically installs the apigroups. It looks like we depended on the import fo the clientset for this purpose.
Cluster Federation
Kubernetes Cluster Federation enables users to federate multiple Kubernetes clusters. Please see the user guide and the admin guide for more details about setting up and using the Cluster Federation.
Building Kubernetes Cluster Federation
Please see the Kubernetes Development Guide
for initial setup. Once you have the development environment setup
as explained in that guide, you also need to install jq
Building cluster federation artifacts should be as simple as running:
make build
You can specify the docker registry to tag the image using the KUBE_REGISTRY environment variable. Please make sure that you use the same value in all the subsequent commands.
To push the built docker images to the registry, run:
make push
To initialize the deployment run:
(This pulls the installer images)
make init
To deploy the clusters and install the federation components, edit the
${KUBE_ROOT}/_output/federation/config.json file to describe your
clusters and run:
make deploy
To turn down the federation components and tear down the clusters run:
make destroy
Ideas for improvement
-
Continue with
destroyphase even in the face of errors.The bash script sets
set -e errexitwhich causes the script to exit at the very first error. This should be the default mode for deploying components but not for destroying/cleanup.