![]() Automatic merge from submit-queue (batch tested with PRs 39280, 37350, 39389, 39390, 39313) Refactor the certificate and kubeconfig code in the kubeadm binary into two phases **What this PR does / why we need it**: First stab at refactoring kubeadm code into logically independent phases. This defines two phases in the kubeadm init process: - certs: Takes some API values as input (the API will be refactored in a later PR), and generates certificates in the pki directory - kubeconfig: Takes the pki directory and the endpoint where the master is located and produces two kubeconfig files: admin.conf and kubelet.conf **Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: Required long-term for graduating our API **Special notes for your reviewer**: ### Old sample output The earlier kubeconfig code had a bug in it; see this example: _admin.conf:_ ```yaml apiVersion: v1 clusters: - cluster: certificate-authority-data: <data> server: https://192.168.200.x:6443 name: kubernetes contexts: - context: cluster: kubernetes user: admin name: admin@kubernetes - context: cluster: kubernetes user: kubelet name: kubelet@kubernetes current-context: admin@kubernetes kind: Config preferences: {} users: - name: admin user: client-certificate-data: <data> client-key-data: <data> - name: kubelet user: client-certificate-data: <data> client-key-data: <data> ``` kubelet.conf: ```yaml apiVersion: v1 clusters: - cluster: certificate-authority-data: <data> server: https://192.168.200.x:6443 name: kubernetes contexts: - context: cluster: kubernetes user: admin name: admin@kubernetes - context: cluster: kubernetes user: kubelet name: kubelet@kubernetes current-context: admin@kubernetes kind: Config preferences: {} users: - name: admin user: client-certificate-data: <data> client-key-data: <data> - name: kubelet user: client-certificate-data: <data> client-key-data: <data> ``` ```console $ shasum /etc/kubernetes/*.conf 2b22b25cc4c97e5619ece6c43badf42b87c4970a /etc/kubernetes/admin.conf 2b22b25cc4c97e5619ece6c43badf42b87c4970a /etc/kubernetes/kubelet.conf ``` #### New output admin.conf ```yaml apiVersion: v1 clusters: - cluster: certificate-authority-data: <data> server: https://192.168.200.x:6443 name: kubernetes contexts: - context: cluster: kubernetes user: admin name: admin@kubernetes current-context: admin@kubernetes kind: Config preferences: {} users: - name: admin user: client-certificate-data: <data> client-key-data: <data> ``` kubelet.conf ```yaml apiVersion: v1 clusters: - cluster: certificate-authority-data: <data> server: https://192.168.200.x:6443 name: kubernetes contexts: - context: cluster: kubernetes user: kubelet name: kubelet@kubernetes current-context: kubelet@kubernetes kind: Config preferences: {} users: - name: kubelet user: client-certificate-data: <data> client-key-data: <data> ``` **Release note**: ```release-note Refactor the certificate and kubeconfig code in the kubeadm binary into two phases ``` PTAL @dgoodwin @jbeda @mikedanese @errordeveloper @pipejakob @lukemarsden |
||
---|---|---|
.. | ||
apis | ||
client | ||
cluster | ||
cmd | ||
deploy | ||
develop | ||
docs/api-reference | ||
manifests | ||
pkg | ||
registry/cluster | ||
Makefile | ||
OWNERS | ||
README.md |
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
destroy
phase even in the face of errors.The bash script sets
set -e errexit
which causes the script to exit at the very first error. This should be the default mode for deploying components but not for destroying/cleanup.