In order to improve the UX of kubeadm, it was decided to introduce the
following subcommands:
- `kubeadm config print` - this is currently only a placeholder for subcommands
that deal printing of some kind of configuration.
- `kubeadm config print init-defaults` - prints the default combination of
InitConfiguration and ClusterConfiguration. Selected component configs can be
printed too if the `--component-configs` command line switch is used.
- `kubeadm config print join-defaults` - prints the default JoinConfiguration.
This command also supports the use of `--component-configs`.
- `kubeadm config print-defaults` is deprecated in favor of
`kubeadm config print init/join-defaults`.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
New command is now `kubectl diff` rather than `kubectl alpha diff` since
it's moving out of alpha soon, and will be using dry-run apply to
produce the diff rather than the custom merge logic.
Automatic merge from submit-queue (batch tested with PRs 67745, 67432, 67569, 67825, 67943). 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.
Move volume dynamic provisioning scheduling to beta
**What this PR does / why we need it**:
* Combine feature gate VolumeScheduling and DynamicProvisioningScheduling into one
* Add allowedTopologies description in kubectl
**Special notes for your reviewer**:
Wait until related e2e and downside plugins are ready.
/hold
**Release note**:
```release-note
Move volume dynamic provisioning scheduling to beta (ACTION REQUIRED: The DynamicProvisioningScheduling alpha feature gate has been removed. The VolumeScheduling beta feature gate is still required for this feature)
```
Automatic merge from submit-queue (batch tested with PRs 67694, 64973, 67902). 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>.
SCTP support implementation for Kubernetes
**What this PR does / why we need it**: This PR adds SCTP support to Kubernetes, including Service, Endpoint, and NetworkPolicy.
**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#44485
**Special notes for your reviewer**:
**Release note**:
```release-note
SCTP is now supported as additional protocol (alpha) alongside TCP and UDP in Pod, Service, Endpoint, and NetworkPolicy.
```
The requested Service Protocol is checked against the supported protocols of GCE Internal LB. The supported protocols are TCP and UDP.
SCTP is not supported by OpenStack LBaaS. If SCTP is requested in a Service with type=LoadBalancer, the request is rejected. Comment style is also corrected.
SCTP is not allowed for LoadBalancer Service and for HostPort. Kube-proxy can be configured not to start listening on the host port for SCTP: see the new SCTPUserSpaceNode parameter
changed the vendor github.com/nokia/sctp to github.com/ishidawataru/sctp. I.e. from now on we use the upstream version.
netexec.go compilation fixed. Various test cases fixed
SCTP related conformance tests removed. Netexec's pod definition and Dockerfile are updated to expose the new SCTP port(8082)
SCTP related e2e test cases are removed as the e2e test systems do not support SCTP
sctp related firewall config is removed from cluster/gce/util.sh. Variable name sctp_addr is corrected to sctpAddr in pkg/proxy/ipvs/proxier.go
cluster/gce/util.sh is copied from master
Automatic merge from submit-queue (batch tested with PRs 67576, 66936). 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>.
Support dry run in admission webhooks
**What this PR does / why we need it**:
Follow up to https://github.com/kubernetes/kubernetes/pull/66391
- [x] add DryRun to ```admission.k8s.io/v1beta1.AdmissionReview```
- [x] add DryRunnable to ```admissionregistration.k8s.io/v1beta1.(Valid|Mut)atingWebhookConfiguration```
- [x] add dry run support to (Valid|Mut)atingAdmissionWebhook
Includes all the api-changes outlined by https://github.com/kubernetes/community/pull/2387
/sig api-machinery
**Release note**:
```release-note
To address the possibility dry-run requests overwhelming admission webhooks that rely on side effects and a reconciliation mechanism, a new field is being added to admissionregistration.k8s.io/v1beta1.ValidatingWebhookConfiguration and admissionregistration.k8s.io/v1beta1.MutatingWebhookConfiguration so that webhooks can explicitly register as having dry-run support. If a dry-run request is made on a resource that triggers a non dry-run supporting webhook, the request will be completely rejected, with "400: Bad Request". Additionally, a new field is being added to the admission.k8s.io/v1beta1.AdmissionReview API object, exposing to webhooks whether or not the request being reviewed is a dry-run.
```
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 ha upgrade
**What this PR does / why we need it**:
This PR implements one of the actions defined by https://github.com/kubernetes/kubeadm/issues/751 (checklist form implementing HA in kubeadm). see [KEP 0015](https://github.com/kubernetes/community/blob/master/keps/sig-cluster-lifecycle/0015-kubeadm-join-master.md) for more context
With this PR, kubeadm implements a new command `kubeadm upgrade node experimental-control-plane` that managed upgrade of control plane components on a secondary control plane instance.
The entire workflow in case of HA clusters will be:
- Upgrade the control plane
- run `kubeadm upgrade apply` on a first control plane instance
- run `kubeadm upgrade node experimental-control-plane` on secondary control plane instances
- Upgrade nodes
**Special notes for your reviewer**:
/CC @timothysc @luxas @chuckha @kubernetes/sig-cluster-lifecycle-pr-reviews
**Release note**:
```
kubeadm now has the `kubeadm upgrade node experimental-control-plane` command for upgrading secondary control plane instances created with `kubeadm join --experimental-control-plane`.
```
Automatic merge from submit-queue (batch tested with PRs 67062, 67169, 67539, 67504, 66876). 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>.
Update the kubectl plugin mechanism
**Release note**:
```release-note
The plugin mechanism functionality to closely follow the git plugin design
```
Replace the existing plugin mechanism with the design proposed in https://github.com/kubernetes/community/pull/2437.
~~_The full implementation of the plugin mechanism itself is entirely contained within the first commit._~~
## Walkthrough
Under the new design, there is no plugin installation or loading required to use plugins.
A plugin is simply any executable file on a user's PATH whose name begins with `kubectl-`.
- Plugins receive the inherited environment from the `kubectl` binary. All environment variables
accessible by `kubectl` become accessible by the plugin.
- Plugins decide which command path they wish to implement based on their name. For example, a plugin wanting to provide a new command `foo`, would simply be named `kubectl-foo`.
### Creating a plugin
Below is an example plugin, that we will use for this walkthrough. Plugins may be written in any language, and handle arguments and flags in any way, optionally (as a convention) providing a way to retrieve their version via a `version` subcommand.
```bash
#!/bin/bash
# optional argument handling
if [[ "$1" == "version" ]]
then
echo "1.0.0"
exit 0
fi
# optional argument handling
if [[ "$1" == "config" ]]
then
echo $KUBECONFIG
exit 0
fi
echo "I am a plugin named kubectl-foo"
```
### Using a plugin
To use a plugin, simply make it executable:
```bash
sudo chmod +x ./kubectl-foo
```
and place it anywhere in your PATH:
```bash
sudo mv ./kubectl-foo /usr/local/bin
```
You may now invoke your plugin as a `kubectl` command:
```bash
$ kubectl foo
I am a plugin named kubectl-foo
```
All args and flags are passed as-is to the executable:
```bash
$ kubectl foo version
1.0.0
```
All environment variables are also passed as-is to the executable:
```bash
$ export KUBECONFIG=~/.kube/config
$ kubectl foo config
/home/<user>/.kube/config
$ KUBECONFIG=/etc/kube/config kubectl foo config
/etc/kube/config
```
Additionally, the first argument that is passed to a plugin will always be the full path to the location where it was invoked (`$0` would equal `/usr/local/bin/kubectl-foo` in our example above).
### Plugin discoverability
Seeing as how the `kubectl plugin` command is left as a no-op with this PR (perhaps it could serve as an entrypoint towards additional plugin functionality in the future), a small subcommand has been included that _lists all available plugin executables on a user's PATH_, along with any warnings it finds.
Example usage of this new subcommand is included below:
```bash
$ kubectl plugin list
The following kubectl-compatible plugins are available:
test/fixtures/pkg/kubectl/plugins/kubectl-foo
plugins/kubectl-foo
- warning: plugins/kubectl-foo is overshadowed by a similarly named plugin: test/fixtures/pkg/kubectl/plugins/kubectl-foo
plugins/kubectl-invalid
- warning: plugins/kubectl-invalid identified as a kubectl plugin, but it is not executable
plugins/kubectl-bar
error: 2 plugin warnings were found
```
cc @kubernetes/kubectl-maintainers @kubernetes/sig-cli-pr-reviews @soltysh @seans3 @mengqiy
fabriziopandini