We set route_localnet so that host-network processes can connect to
<127.0.0.1:NodePort> and it still works. This, however, is too
permissive.
So, block martians that are not already in conntrack.
See: #90259
Signed-off-by: Casey Callendrello <cdc@redhat.com>
This updates cri-tools to the latest release as well as pointing the
artifacts to the new Google Cloud Bucket `k8s-artifacts-cri-tools`.
This reverts commit ce1840d253.
Signed-off-by: Sascha Grunert <sgrunert@suse.com>
* fix a number of unbounded dimensions in request metrics
* add test suite for cleanVerb and cleanContentType
* Properly validate that the content-type and charset (if applicable) are RFC compliant
* add additional test case
* truncate list of content-types
Change-Id: Ia5fe0d2e2c602e4def4b8e0849cc19f3f9251818
In case a malformed flag is passed to k8s components
such as "–foo", where "–" is not an ASCII dash character,
the components currently silently ignore the flag
and treat it as a positional argument.
Make k8s components/commands exit with an error if a positional argument
that is not empty is found. Include a custom error message for all
components except kubeadm, as cobra.NoArgs is used in a lot of
places already (can be fixed in a followup).
The kubelet already handles this properly - e.g.:
'unknown command: "–foo"'
This change affects:
- cloud-controller-manager
- kube-apiserver
- kube-controller-manager
- kube-proxy
- kubeadm {alpha|config|token|version}
- kubemark
Signed-off-by: Monis Khan <mok@vmware.com>
Signed-off-by: Lubomir I. Ivanov <lubomirivanov@vmware.com>
* Creates staging directory for common controller-manager code
* Adds the following initial files to this directory:
* .github/PULL_REQUEST_TEMPLATE.md
* code-of-conduct.md
* LICENSE
* OWNERS
* README.md
* SECURITY_CONTACTS
* Code committed to the controller-manager staging directory will be published to: https://github.com/kubernetes/controller-manager
Initial approval deads2k (sig-api-machinery chair)
The config we would expect any controller manager to need to connect to the API server, set up metrics endpoints, create per-controller-loop API clients, and spin up the individual loops could make sense under a k8s.io/controller-manager package.
Then cmd/kube-controller-manager could continue to contain the weirdnesses specific to kube-controller-manager.
This is similar to the way we split out recommended API server setup into k8s.io/apiserver and tried to limit kube-apiserver oddities to cmd/kube-apiserver and pkg/kubeapiserver
Removed extraneous release reference. Ran update-vendor.
Fixed Readme.
Added a doc.go to staging/controller-manager
Fix package to not have dash.
```
NONE
```
/kind cleanup
/sig api-machinery
/area kube-controller-manager
/area cloud-controller-manager