Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a v1beta1 version for kubeadm config API types #911

Closed
luxas opened this issue Jun 12, 2018 · 6 comments · Fixed by kubernetes/kubernetes#71008
Closed

Create a v1beta1 version for kubeadm config API types #911

luxas opened this issue Jun 12, 2018 · 6 comments · Fixed by kubernetes/kubernetes#71008
Assignees
Labels
area/ecosystem area/upgrades area/UX kind/design Categorizes issue or PR as related to design. kind/feature Categorizes issue or PR as related to a new feature. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.
Milestone

Comments

@luxas
Copy link
Member

luxas commented Jun 12, 2018

Follow up from #750 (comment).

For beta, we need to

  • update the KEP to reflect the current state
  • improve the structure of our API types further (gdocs proposal)
  • decide whether to embed other components' ComponentConfig in our types or not

There is way more needed here wrt details, but I don't have time to write up that all now, it will go into the KEP and be discussed during kubeadm Office Hours in the v1.12 cycle.

Edit: The KEP gdoc proposal for this is here

@luxas luxas added area/ecosystem area/upgrades priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. area/UX kind/feature Categorizes issue or PR as related to a new feature. kind/design Categorizes issue or PR as related to design. labels Jun 12, 2018
@luxas luxas added this to the v1.12 milestone Jun 12, 2018
@fabriziopandini
Copy link
Member

@luxas
This document is still the starting point for this discussion?

@luxas
Copy link
Member Author

luxas commented Jun 15, 2018

@fabriziopandini yes

k8s-github-robot pushed a commit to kubernetes/kubernetes that referenced this issue Jul 4, 2018
Automatic merge from submit-queue (batch tested with PRs 65776, 64896). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.

kubeadm: Stop using/supporting the v1alpha1 Config API

**What this PR does / why we need it**:
In v1.10 and earlier, kubeadm only had the v1alpha1 API.
In v1.11, kubeadm could read v1alpha1 configs, but only write v1alpha2 configs
In v1.12, kubeadm can read v1alpha2 configs, but only write v1alpha3 or v1beta1 configs.

**Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*:
Part of #65628
ref: kubernetes/kubeadm#911

**Special notes for your reviewer**:

**Release note**:

```release-note
NONE
```
@kubernetes/sig-cluster-lifecycle-pr-reviews 
/assign @timothysc
k8s-github-robot pushed a commit to kubernetes/kubernetes that referenced this issue Jul 4, 2018
Automatic merge from submit-queue (batch tested with PRs 65628, 65573). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.

kubeadm: Remove the v1alpha1 API 

**What this PR does / why we need it**:
In v1.10 and earlier, kubeadm only had the `v1alpha1` API.
In v1.11, kubeadm could read `v1alpha1` configs, but only write `v1alpha2` configs
In v1.12, kubeadm can read `v1alpha2` configs, but only write `v1alpha3` or `v1beta1` configs.

**Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*:
ref: kubernetes/kubeadm#911
Depends on: #65776

**Special notes for your reviewer**:

**Release note**:

```release-note
[action required] kubeadm: The `v1alpha1` config API has been removed.
Please convert your `v1alpha1` configuration files to `v1alpha2` using the
`kubeadm config migrate` command of kubeadm v1.11.x
```
@kubernetes/sig-cluster-lifecycle-pr-reviews
k8s-github-robot pushed a commit to kubernetes/kubernetes that referenced this issue Jul 5, 2018
Automatic merge from submit-queue (batch tested with PRs 64593, 65117, 65629, 65827, 65686). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.

kubeadm: Add a `v1alpha3` API

**What this PR does / why we need it**:
Adds a (now duplicated) v1alpha3 API. Equal to `v1alpha2` now, but will be changed later.
Hopefully we'll graduate this to `v1beta1` during the v1.12 cycle.

**Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*:
ref: kubernetes/kubeadm#911
Depends on:
 - [x] #65776
 - [x] #65628

**Special notes for your reviewer**:

These commits should be reviewed:
 - `Add a duplicated v1alpha3 API`: A pure directory copy of the `v1alpha2` folder, only changed the package name in the Go files
 - `Register the v1alpha3 API in the scheme, and update the roundtrip API tests`, started registering the new API and using it internally
 - `Automated bump from v1alpha2 references to v1alpha3`: Replaced all v1alpha2 references with v1alpha3

**Release note**:

```release-note
kubeadm: Add a `v1alpha3` API.
```
@kubernetes/sig-cluster-lifecycle-pr-reviews
k8s-github-robot pushed a commit to kubernetes/kubernetes that referenced this issue Jul 5, 2018
Automatic merge from submit-queue (batch tested with PRs 65822, 65834, 65859, 65631). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.

kubeadm: Add support for reading multiple YAML documents

**What this PR does / why we need it**:
In preparation for splitting the kubelet and kube-proxy componentconfigs out of the MasterConfiguration API struct, add support for reading multiple YAML documents

**Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*:
ref: kubernetes/kubeadm#911
Depends on:
 - [x] #65776
 - [x] #65628
 - [x] #65629

**Special notes for your reviewer**:
Please only review the `Refactor a bit of the config YAML loading code, and support loading multiple YAML documents` commit

**Release note**:

```release-note
NONE
```
@kubernetes/sig-cluster-lifecycle-pr-reviews
luxas pushed a commit to luxas/kubernetes that referenced this issue Jul 8, 2018
…nentconfigs

Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.

kubeadm: Start using internal versions for ComponentConfigs in the internal API

**What this PR does / why we need it**:
This PR changes kubeadm to store the internal API versions of the ComponentConfig APIs, in order to in the future be able to read multiple external versions with conversion. It also moves all the ComponentConfigs to a common struct instead of splitting them out in many. This makes it possible to more easily host more ComponentConfigs in the future. In v1alpha3, the ComponentConfigs will later be removed from the external version of the API (see: kubernetes#65787), but for this PR no changes to the external API are made.

**Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*:
ref: kubernetes/kubeadm#911
Depends on:
 - [x] kubernetes#65776
 - [x] kubernetes#65628
 - [x] kubernetes#65629
 - [x] kubernetes#65631

**Special notes for your reviewer**:

**Release note**:

```release-note
NONE
```
@kubernetes/sig-cluster-lifecycle-pr-reviews
k8s-github-robot pushed a commit to kubernetes/kubernetes that referenced this issue Jul 8, 2018
…om_api

Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.

kubeadm: Use separate YAML docs for the kubelet and kube-proxy ComponentConfigs

**What this PR does / why we need it**:
This PR makes kubeadm load the ComponentConfig for the kubelet and kube-proxy from separate YAML documents in the `kubeadm init` config file. This is backwards-compatible with `v1alpha2`. The ComponentConfigs are stored internally in the internal kubeadm `MasterConfiguration` struct, but when marshalling the componentconfigs are written as separate YAML documents.

**Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*:
ref: kubernetes/kubeadm#911
Depends on:
 - [x] #65776
 - [x] #65628
 - [x] #65629
 - [x] #65631
 - [x] #65940

**Special notes for your reviewer**:
Only review the last five commits please. (The last commit is purely autogenerated, so can be skipped)

**Release note**:

```release-note
kubeadm: Use separate YAML documents for the kubelet and kube-proxy ComponentConfigs
```
@kubernetes/sig-cluster-lifecycle-pr-reviews 
/assign @timothysc
k8s-github-robot pushed a commit to kubernetes/kubernetes that referenced this issue Aug 22, 2018
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.

[reissue] kubeadm: Split out ClusterConfiguration from InitConfiguration

As @luxas is not able to take care of #66219, I am reissuing the same change here. There are a few minor things added by me:

- The original PR is rebased on latest master.
- Some broken tests were fixed.
- Some TODOs were added.
- Run update-bazel and update-gofmt

Below is the text of the original PR by Lucas.

-----

**What this PR does / why we need it:**

Splits MasterConfiguration to InitConfiguration and ClusterConfiguration as outlined in the kubeadm Config KEP. InitConfiguration holds init-only information, and ClusterConfiguration holds cluster-wide information. In the internal representation InitConfiguration wraps ClusterConfiguration as a field, but in serialized format they're different YAML documents.

**Which issue(s) this PR fixes** (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
ref: kubernetes/kubeadm#911
Depends on:

- [X] #65776
- [X] #65628
- [X] #65629
- [X] #65631
- [X] #65940
- [X] #65787
- [X] #65945
- [X] #65951
- [X] #65952

**Special notes for your reviewer:**

**Release note**:
```release-note
kubeadm: InitConfiguration now consists of two structs: InitConfiguration and ClusterConfiguration
```

@kubernetes/sig-cluster-lifecycle-pr-reviews
hh pushed a commit to ii/kubernetes that referenced this issue Aug 24, 2018
…ig-ControlPlaneEndpoint

Automatic merge from submit-queue (batch tested with PRs 67776, 67503, 67679, 67786, 67830). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.

kubeadm config move ControlPlaneEndpoint to ClusterConfiguration

**What this PR does / why we need it**:
This PR moves `ControlPlaneEndpoint` from the `API` config struct to `ClusterConfiguration`.

This change is required as initial step for enabling management of more than one control plane instances in kubeadm

**Which issue(s) this PR fixes** :
refs kubernetes/kubeadm#911, refs kubernetes/kubeadm#963

**Special notes for your reviewer**:
just an appetizer, the main dish will be the next PR...

**Release note**:
```release-note
kubeadm: ControlPlaneEndpoint was moved from the API config struct to ClusterConfiguration
```

/cc @kubernetes/sig-cluster-lifecycle-pr-reviews
/sig cluster-lifecycle
/area kubeadm
/kind api-change
/kind enhancement
/assign @luxas
/assign @timothysc
/cc @chuckha @rosti @neolit123 @liztio
@timothysc timothysc modified the milestones: v1.12, v1.13 Aug 25, 2018
@timothysc
Copy link
Member

Pushing to 1.13

hh pushed a commit to ii/kubernetes that referenced this issue Aug 27, 2018
…ig-APIEndpoint

Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.

kubeadm config add support for more than one APIEndpoint

**What this PR does / why we need it**:
This PR completes the changes in kubeadm for management of more than one control plane instances introducing the possibility to configure more than one APIEndpoints

**Which issue(s) this PR fixes** :
refs kubernetes/kubeadm#911, refs kubernetes/kubeadm#963

**Special notes for your reviewer**:
Depends on:
- [x] kubernetes#67830

**Release note**:
```release-note
kubeadm: The kubeadm configuration now support definition of more than one control plane instances with their own APIEndpoint. The APIEndpoint for the "bootstrap" control plane instance should be defined using `InitConfiguration.APIEndpoint`, while the APIEndpoints for additional control plane instances should be added using `JoinConfiguration.APIEndpoint`.  
```

/cc @kubernetes/sig-cluster-lifecycle-pr-reviews
/sig cluster-lifecycle
/area kubeadm
/kind api-change
/kind enhancement
/assign @luxas
/assign @timothysc
/cc @chuckha @rosti @neolit123 @liztio
dims pushed a commit to dims/kubernetes that referenced this issue Sep 4, 2018
…ig-configMap

Automatic merge from submit-queue (batch tested with PRs 63011, 68089, 67944, 68132). If you want to cherry-pick this change to another branch, please follow the instructions here: https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md.

Kubeadm upload and fetch of kubeam config v1alpha3

**What this PR does / why we need it**:
This PR implements upload and fetch of kubeam config v1alpha3 from cluster.

More in detail:
In upload, `kubeadm-config` gets
- `ClusterConfiguration` (without components config which are already stored in separated ConfigMaps)
- `ClusterStatus`(initialised or updated with the API endpoint of the current node)

During fetch `InitConfiguration` is composed with:
- `ClusterConfiguration` from `kubeadm-config`
- The `APIEndpoint` of the current node from `ClusterStatus` in `kubeadm-config`
- Component configs from corresponding ConfigMaps

**Which issue(s) this PR fixes** :
refs kubernetes/kubeadm#911, refs kubernetes/kubeadm#963

**Special notes for your reviewer**:
In order to implement this it was necessary to extend current component config management with a new GetFromConfigMap operation. This is implemented in a separated commit "
implement component configs GetFromConfigMap".
The real change build on this (commi "upload and fetch kubeadm v1alpha3")

**Release note**:
```release-note
NONE
```

/cc @kubernetes/sig-cluster-lifecycle-pr-reviews
/sig cluster-lifecycle
/area kubeadm
/kind enhancement
/assign @luxas
/assign @timothysc
/cc @chuckha @rosti @neolit123 @liztio
@fabriziopandini
Copy link
Member

fabriziopandini commented Sep 18, 2018

After v1.12 the remaining activities are:

@neolit123
Copy link
Member

@rosti and @fabriziopandini
please babysit this issue when we are done to close it!

@timothysc
Copy link
Member

Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/ecosystem area/upgrades area/UX kind/design Categorizes issue or PR as related to design. kind/feature Categorizes issue or PR as related to a new feature. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants