WIP: Add v1alpha1 to v1alpha2 config migration doc #9124
Conversation
k8s-ci-robot
added
do-not-merge/work-in-progress
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Assign the PR to them by writing The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/assign @Bradamant3 |
|
Deploy preview for kubernetes-io-master-staging ready! Built with commit dd82d5d https://deploy-preview-9124--kubernetes-io-master-staging.netlify.com |
1 similar comment
|
Deploy preview for kubernetes-io-master-staging ready! Built with commit dd82d5d https://deploy-preview-9124--kubernetes-io-master-staging.netlify.com |
|
|
||
| - The `v1alpha1` and `v1alpha2` APIs **aren't marked stable** yet, so their semantics will (possibly significantly) change before reaching `v1beta1`. Between `v1beta1` and `v1` the delta is expected to be small/non-existent. | ||
| - **All your `v1alpha1` configuration files can be read by kubeadm v1.11 and are automatically upgraded to `v1alpha2` internally**. This means you don't _technically_ need to read this document and upgrade each field separately, kubeadm takes care of this automatically under the hood. | ||
| - The policy is the follwing: If a given API version `v1alphaY` was released in kubeadm v1.Z to replace the existing `v1alphaX` API version, reading `v1alphaX` files in kubeadm v1.Z will work, but kubeadm v1.Z will only _write_ the newer API version `v1alphaY` |
| #### The `.CloudProvider` and `.PrivilegedPods`fields are gone | ||
|
|
||
| In-tree cloud providers that `.CloudProvider` once enabled on a best-effort, experimental | ||
| basis are deprecated, and use of [out-of-tree cloud providers](#TODO) is encouraged instead. |
There was a problem hiding this comment.
The experimental usage of in-tree cloud providers with the
.CloudProviderfield is deprecated. Usage of out-of-tree cloud providers is encouraged instead.
There was a problem hiding this comment.
not explicitly mentioned in any public docs... in-tree has a deprecation warning but does not support the assertion that out-of-tree is the thing to use and the cloud controller manager really doesn't really say that external is encouraged over in-tree, it just tells you how to use external provider running in-tree code.
I wonder if this decision was explicitly stated and documented somewhere. The opening paragraphs in this document almost get at it...
|
|
||
| #### Important notes | ||
|
|
||
| - The `v1alpha1` and `v1alpha2` APIs **aren't marked stable** yet, so their semantics will (possibly significantly) change before reaching `v1beta1`. Between `v1beta1` and `v1` the delta is expected to be small/non-existent. |
There was a problem hiding this comment.
s/delta is expected to be small/non-existent./
api-policies are adhered to (link to api-policy reference)
|
|
||
| ### API Changes between `v1alpha1` and `v1alpha2` | ||
|
|
||
| #### The `.CloudProvider` and `.PrivilegedPods`fields are gone |
There was a problem hiding this comment.
space after .PrivilegedPods
possibly:
s/gone/deprecated/
|
|
||
| The `.PrivilegedPods` boolean field made the API Server and controller manager Static | ||
| Pods be privileged Pods, as there is one cloud provider that needs that. However, this can be | ||
| equally well by editing the Static Pod manifests after `kubeadm init` has been run. |
There was a problem hiding this comment.
However, this can be -> missing controlled ?
| ``` | ||
|
|
||
| The `.PrivilegedPods` boolean field made the API Server and controller manager Static | ||
| Pods be privileged Pods, as there is one cloud provider that needs that. However, this can be |
There was a problem hiding this comment.
possibly either specify the CP by name or omit the second part.
not sure.
|
|
||
| There are two modes of hosting etcd for kubeadm clusters: locally or externally. Still, this | ||
| wasn't reflected in the `v1alpha1` config, hosting fields from both modes under the same | ||
| `.Etcd` struct like this: |
There was a problem hiding this comment.
In the
v1alpha1configuration, hosting fields for both modes are sharing the.Etcdstructure, like so:
| that it's not possible to specify several bootstrap tokens at once, and that similar fields should | ||
| not be hosted in the top-level `MasterConfiguration` struct. | ||
|
|
||
| In `v1alpha2`, there is a slice of called `.BootstrapTokens` that contains `BootstrapToken` objects that look like this: |
|
/assign @neolit123 |
|
@luxas if this is for 1.11, it should be rebased against the |
|
I'm not gonna be able to finish this work as I'm going into the military, can someone help out and carry this over to the kubeadm repo please? |
|
@luxas no problem. we are going to handle it! |
|
I'm going to close out this issue for now. |
Part of kubernetes/kubeadm#849
cc @kubernetes/sig-cluster-lifecycle-pr-reviews @Bradamant3 @neolit123