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
..
2016-12-29 13:04:10 -08:00
2016-12-29 13:04:10 -08:00
2016-12-29 13:04:10 -08:00
2016-12-29 13:04:10 -08:00
2016-12-29 13:04:10 -08:00
2016-12-29 13:04:10 -08:00
2016-12-29 13:04:10 -08:00
2016-12-29 13:04:10 -08:00
2016-12-29 13:04:10 -08:00
2016-12-29 13:04:10 -08:00
2017-01-03 15:50:12 -05:00
2017-01-02 08:04:29 -08:00
2016-12-29 13:04:10 -08:00
2016-12-29 13:04:10 -08:00
2016-12-29 13:04:10 -08:00
2017-01-03 23:40:07 +02:00
2016-12-29 13:04:10 -08:00
2016-12-30 18:26:53 +02:00
2016-12-29 13:04:10 -08:00
2017-01-03 14:57:33 +01:00
2017-01-01 23:11:09 -08:00
2016-12-29 13:04:10 -08:00
2016-12-29 13:04:10 -08:00
2016-05-11 13:34:51 -07:00