kubernetes/federation
Kubernetes Submit Queue 27850a79d9 Merge pull request #39280 from luxas/kubeadm_api_proto
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
2017-01-03 18:25:08 -08:00
..
apis Generated part for ObservedGeneration 2017-01-02 15:00:05 +01:00
client Update generated for 2017 2017-01-01 23:11:09 -08:00
cluster autogenerated 2016-12-29 13:04:10 -08:00
cmd refactored admission to avoid internal client references 2017-01-03 15:50:12 -05:00
deploy Update charts image version. 2016-10-12 00:15:01 -07:00
develop [Federation] Remove unnecessary functions from develop.sh as part of deploy.sh deprecation. 2016-12-16 13:19:24 -08:00
docs/api-reference [scheduling] Auto-generated file updates from moving node affinity from 2016-12-16 11:42:43 -05:00
manifests [Federation][init-11.2] use USE_KUBEFED env var to choose bw old and new federation deployment 2016-12-16 11:22:44 +05:30
pkg Refactor the pki, cert, kubeconfig code in the kubeadm binary into two separate and logically independent phases 2017-01-03 23:40:07 +02:00
registry/cluster Move pkg/api.{Context,RequestContextMapper} into pkg/genericapiserver/api/request 2017-01-03 14:57:33 +01:00
Makefile Separate the build recipe in federation Makefile into separate phases. 2016-08-29 14:16:39 -07:00
OWNERS Add colhom to federation OWNERS 2016-06-27 13:16:43 -07:00
README.md Fix doc links in Federation readme 2016-11-07 11:31:08 +00:00

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

  1. 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.

Analytics