Automatic merge from submit-queue (batch tested with PRs 63151, 63795, 63553, 64068, 64113). 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 .AuthorizationModes in the v1alpha2 API
**What this PR does / why we need it**:
Now that we have https://github.com/kubernetes/kubernetes/pull/63879, we don't actually need to have `:AuthorizationModes` in our API anymore. This PR removes support for `.AuthorizationModes` in the v1alpha2 API, but keeps an upgrade path available (automatic conversion) from the v1alpha1 version.
**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 kubernetes/community#2131
**Special notes for your reviewer**:
Depends on:
- [x] https://github.com/kubernetes/kubernetes/pull/63879
- [x] https://github.com/kubernetes/kubernetes/pull/63917
**Release note**:
```release-note
[action required] kubeadm: Support for `.AuthorizationModes` in the kubeadm v1alpha2 API has been removed. Instead, you can use the `.APIServerExtraArgs` and `.APIServerExtraVolumes` fields to achieve the same effect. Files using the v1alpha1 API and setting this field will be automatically upgraded to this v1alpha2 API and the information will be preserved.
```
@kubernetes/sig-cluster-lifecycle-pr-reviews @liztio
Automatic merge from submit-queue (batch tested with PRs 63969, 63902, 63689, 63973, 63978). 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>.
Add a 'kubeadm config print-default' command
**What this PR does / why we need it**:
Improves the UX around creating config files.
**Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*:
Fixes https://github.com/kubernetes/kubeadm/issues/829
**Special notes for your reviewer**:
**Release note**:
```release-note
kubeadm: A `kubeadm config print-default` command has now been added that you can use as a starting point when writing your own kubeadm configuration files
```
@kubernetes/sig-cluster-lifecycle-pr-reviews @liztio
Automatic merge from submit-queue (batch tested with PRs 63314, 63884, 63799, 63521, 62242). 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: Restructure internal config usage and fix bugs
**What this PR does / why we need it**:
- Moves the generic LoadYAML function from the versioned, external API package to a helper library so it can be consumed more easily
- Makes the upgrading code use the internal version of the API (which always should be used anyway)
- Moves all config-loading code to `configutil`, together with the migration code needed. This way we have everything in one centralized place, instead of duplicating that logic N times.
- Makes `kubeadm init` use `configutil` for the reasons mentioned above.
This PR is needed in order to support multiple external API groups (like v1alpha2)
**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 https://github.com/kubernetes/community/pull/2131
**Special notes for your reviewer**:
This PR depends on:
- https://github.com/kubernetes/kubernetes/pull/63782
- https://github.com/kubernetes/kubernetes/pull/63783
**Please review only the last (third) commit**
**Release note**:
```release-note
NONE
```
@kubernetes/sig-cluster-lifecycle-pr-reviews @liztio
Automatic merge from submit-queue (batch tested with PRs 63272, 63782, 63715, 63811, 63803). 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>.
Stop installing kubeadm types in the generic, legacy scheme
**What this PR does / why we need it**:
Right now the kubeadm API types are (wrongly from a correctness perspective) installed in the "catch-all" and now legacy `pkg/api/legacyscheme`. Instead, we should use our own, kubeadm-specific `scheme` where our API types are registered. Doing this also cuts one dependency on the internal core API types.
**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 https://github.com/kubernetes/community/pull/2131
**Special notes for your reviewer**:
**Release note**:
```release-note
NONE
```
@kubernetes/sig-cluster-lifecycle-pr-reviews @sttts @liztio
Currently kubeadm only performs an upgrade if the etcd cluster is
colocated with the control plane node. As this is only one possible
configuration, kubeadm should support upgrades with etcd clusters
that are not local to the node.
Signed-off-by: Craig Tracey <craigtracey@gmail.com>
Automatic merge from submit-queue (batch tested with PRs 63492, 62379, 61984, 63805, 63807). 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>.
Sort arguments before joining them, for reproducible return string
**What this PR does / why we need it**:
This PR makes kubeadm static pod manifest generation consistent. Right now when `kubeadm init` is called repeatedly, the generated pod manifest files under /etc/kubernetes/manifest/ are changing. Its really hard to test how a configuration change effects the manifest files.
The current implementation is ranging over a map[string]string which will be happening in a random order, generating different pod manifests even without changing any configuration.
The suggested solution makes pom manifest generation idempotent. It opens up integration test possibilities, like testing whole yaml result of `kubeadm alpha phase controlplane`.
**Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*:
Fixes #
**Special notes for your reviewer**:
**Release note**:
```release-note
NONE
```
/sig cluster-lifecycle
/assign @luxas
Automatic merge from submit-queue (batch tested with PRs 55511, 63372, 63400, 63100, 63769). 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>.
Improve kubeadm upgrade path for CoreDNS
**What this PR does / why we need it**:
This PR achieves the following:
1. Retains the CoreDNS ConfigMap defined by the user during `kubeadm upgrade`.
2. Removes the CoreDNS deployment when user decides to install kube-dns during `kubeadm upgrade`.
**Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*:
Fixes #
**Special notes for your reviewer**:
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue (batch tested with PRs 63783, 63734). 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 marshal tests
**What this PR does / why we need it**:
Adds tests for the marshalling utilities in kubeadm.
**Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*:
Fixes: kubernetes/kubeadm#802
**Special notes for your reviewer**:
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue (batch tested with PRs 63367, 63718, 63446, 63723, 63720). 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>.
finish new dynamic client and deprecate old dynamic client
Builds on a couple other pulls. This completes the transition to the new dynamic client.
@kubernetes/sig-api-machinery-pr-reviews
@caesarxuchao @sttts
```release-note
The old dynamic client has been replaced by a new one. The previous dynamic client will exist for one release in `client-go/deprecated-dynamic`. Switch as soon as possible.
```
We should stop special casing "ci-cross" and just use the
configuration in test-infra to dictate where we pick up
the builds from.
For 1.8,1.9,1.10 branches, we need to load the latest
version from ci/latest*.txt.
For master, 1.11 etc, we need to load from ci-cross/latest*.txt.
We need to update test-infra configs if things fail.
try these to verify:
```
gsutil cat gs://kubernetes-release-dev/ci/latest-1.9.txt
gsutil cat gs://kubernetes-release-dev/ci-cross/latest.txt
```
Automatic merge from submit-queue (batch tested with PRs 62655, 61711, 59122, 62853, 62390). 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>.
Modify the kubeadm upgrade DAG for the TLS Upgrade
**What this PR does / why we need it**:
This adds the necessary utilities to detect Etcd TLS on static pods from the file system and query Etcd.
It modifies the upgrade logic to make it support the APIServer downtime.
Tests are included and should be passing.
```bash
bazel test //cmd/kubeadm/... \
&& bazel build //cmd/kubeadm --platforms=@io_bazel_rules_go//go/toolchain:linux_amd64 \
&& issue=TLSUpgrade ~/Repos/vagrant-kubeadm-testing/copy_kubeadm_bin.sh
```
These cases are working consistently for me
```bash
kubeadm-1.9.6 reset \
&& kubeadm-1.9.6 init --kubernetes-version 1.9.1 \
&& kubectl apply -f https://git.io/weave-kube-1.6
/vagrant/bin/TLSUpgrade_kubeadm upgrade apply 1.9.6 # non-TLS to TLS
/vagrant/bin/TLSUpgrade_kubeadm upgrade apply 1.10.0 # TLS to TLS
/vagrant/bin/TLSUpgrade_kubeadm upgrade apply 1.10.1 # TLS to TLS
/vagrant/bin/TLSUpgrade_kubeadm upgrade apply 1.9.1 # TLS to TLS /w major version downgrade
```
This branch is based on top of #61942, as resolving the hash race condition is necessary for consistent behavior.
It looks to fit in pretty well with @craigtracey's PR: #62141
The interfaces are pretty similar
/assign @detiber @timothysc
**Which issue(s) this PR fixes**
Helps with https://github.com/kubernetes/kubeadm/issues/740
**Special notes for your reviewer**:
278b322a1c
[kubeadm] Implement ReadStaticPodFromDisk
c74b56372d
Implement etcdutils with Cluster.HasTLS()
- Test HasTLS()
- Instrument throughout upgrade plan and apply
- Update plan_test and apply_test to use new fake Cluster interfaces
- Add descriptions to upgrade range test
- Support KubernetesDir and EtcdDataDir in upgrade tests
- Cover etcdUpgrade in upgrade tests
- Cover upcoming TLSUpgrade in upgrade tests
8d8e5fe33b
Update test-case, fix nil-pointer bug, and improve error message
97117fa873
Modify the kubeadm upgrade DAG for the TLS Upgrade
- Calculate `beforePodHashMap` before the etcd upgrade in anticipation of
KubeAPIServer downtime
- Detect if pre-upgrade etcd static pod cluster `HasTLS()==false` to switch
on the Etcd TLS Upgrade if TLS Upgrade:
- Skip L7 Etcd check (could implement a waiter for this)
- Skip data rollback on etcd upgrade failure due to lack of L7 check
(APIServer is already down unable to serve new requests)
- On APIServer upgrade failure, also rollback the etcd manifest to
maintain protocol compatibility
- Add logging
**Release note**:
```release-note
kubeadm upgrade no longer races leading to unexpected upgrade behavior on pod restarts
kubeadm upgrade now successfully upgrades etcd and the controlplane to use TLS
kubeadm upgrade now supports external etcd setups
kubeadm upgrade can now rollback and restore etcd after an upgrade failure
```
- Test HasTLS()
- Instrument throughout upgrade plan and apply
- Update plan_test and apply_test to use new fake Cluster interfaces
- Add descriptions to upgrade range test
- Support KubernetesDir and EtcdDataDir in upgrade tests
- Cover etcdUpgrade in upgrade tests
- Cover upcoming TLSUpgrade in upgrade tests
- Update kubeadm static pod upgrades to use the
kubetypes.ConfigHashAnnotationKey annotation on the mirror pod rather
than generating a hash from the full object info. Previously, a status
update for the pod would allow the upgrade to proceed before the
new static pod manifest was actually deployed.
Signed-off-by: Jason DeTiberus <detiber@gmail.com>
Automatic merge from submit-queue (batch tested with PRs 62726, 60085, 62583). 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>.
Refactor kubeadm api validation.
**What this PR does / why we need it**:
This PR refactor kubeadm api validation to use field json name. When users get a validation error, they can easily know which field is invalid in their config files.
**Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*:
Fixes #
**Special notes for your reviewer**:
@fabriziopandini I remember we mentioned this refactoring in some comment. I didn't see this change was done, so I send this PR to address this.
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue (batch tested with PRs 58540, 62314). 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>.
Add ability to specify port for kubeadm `API.ControlPlaneEndpoint`
**What this PR does / why we need it**:
When `API.ControlPlaneEndpoint` is used, the `BindPort` of the
apiserver is currently assumed, which means a load balancer cannot
listen on a different port than the apiserver. This extends the
`ControlPlaneEndpoint` to take an optional port which may differ
from the apiserver's `BindPort`.
**Release note**:
```release-note
The kubeadm config option `API.ControlPlaneEndpoint` has been extended to take an optional port which may differ from the apiserver's bind port.
```
