This commit moves away from using a global variable for default
configuration checking, and instead exposes a method on LoadingRules to
determine whether a particular restclient.Config should be considered
"default". This allows kubectl to provide its own defaults (the same
as before, KUBERNETES_MASTER and the static localhost:8080 values) while
allowing other clients to avoid defining them.
In-cluster config defaulting is now easier to read.
Automatic merge from submit-queue
Check init containers in PodContainerRunning
Sometimes when an init container runs and terminates quickly, PodContainerRunning can go into a
state where the pod indicates it's still running, but the container is already terminated. Handle
that condition by returning ErrContainerTerminated when it happens.
See also #29952
@smarterclayton @fabianofranz
Automatic merge from submit-queue
Fix clientcmd for a non-host cluster client running in a pod.
This is based on @errordeveloper's PR #32438. It fixes a case where default config is invalid and original config, i.e. `mergedConfig` is empty. It also adds a test for the case where default config is invalid and original config is neither invalid nor empty.
cc @errordeveloper @kubernetes/sig-cluster-federation @pwittrock @colhom
Automatic merge from submit-queue
Allow namespace to be loaded from in-cluster config
This is a follow on from the previous commit that fixed ClientConfig.
Namespace can also be defaulted from ICC, and this correctly handles
that logic. Also add two debugging lines to ensure that it is easier in
the future to uncover problems here.
Fixes#32352
@deads2k
Automatic merge from submit-queue
Add a check in ConfirmUsable() to validate the contextName
**What this PR does / why we need it**:
When a context name is provided, but can't be found (miss spelling), it currently
uses the defaults. This PR will cause the command to fail, to prevent unexpected side effects
of using the wrong configuration.
**Which issue this PR fixes**
fixes#21062
**Special notes for your reviewer**:
None
**Release note**:
```release-note
Error if a contextName is provided but not found in the kubeconfig.
```
Automatic merge from submit-queue
Use scale subresource
Fixes#29698
Use scale subresource for ReplicationController, ReplicaSet and Deployment.
Couldn't do Jobs and PetSet since they live in a different group.
Automatic merge from submit-queue
Example of unversioned pkg uses correct Config struct
Currently this Doc has incorrect example - https://godoc.org/k8s.io/kubernetes/pkg/client/unversioned
So when developers use it they are confused why `client` pkg has no `Config` struct, actually this is a struct from `restclient` pkg.
Also pkg name and variable name should be equal:
`client, err := client.New(config)`
Thanks,
Alex
Changes made in #31947 cause kube-proxy to ignore `--kubeconfig`
and `--master` flags and use in-cluster configuration, which is
unusable due to the fact that VIP hasn't been created yet.
This is a follow on from the previous commit that fixed ClientConfig.
Namespace can also be defaulted from ICC, and this correctly handles
that logic. Also add two debugging lines to ensure that it is easier in
the future to uncover problems here.
Automatic merge from submit-queue
Move StorageClass to a storage group
We discussed the pros and cons in sig-api-machinery yesterday. Choosing a particular group name means that clients (including our internal code) require less work and re-swizzling to handle promotions between versions. Even if you choose a group you end up not liking, the amount of work remains the same as the incubator work case: you move the affected kind, resource, and storage.
This moves the `StorageClass` type to the `storage.k8s.io` group (named for consistency with authentication, authorization, rbac, and imagepolicy). There are two commits, one for manaul changes and one for generated code.
By removing the default "localhost:8080" behavior several paths in
client config began returning err == ErrEmptyConfig rather than err ==
nil. The code checking for in cluster config was wrong - the logic
should be:
1. If loading the underlying config returns a non-empty error, fail
2. If the underlying config is not equal to the default config,
return that config (it's got user input)
3. If it is possible to use in cluster config, do so
4. Otherwise return the default config (and or default EmptyConfig
error).
This changes clientcmd to skip the default cluster, but preserves the
behavior in kubectl. This prevents the possibility of an administrator
misconfiguration in kubelet or other server component from allowing a
third party who can bind to 8080 on that host from potentially
impersonating an API server and gaining root access.
Sometimes when an init container runs and terminates quickly, PodContainerRunning can go into a
state where the pod indicates it's still running, but the container is already terminated. Handle
that condition by returning ErrContainerTerminated when it happens.
Automatic merge from submit-queue
Add initial support for TokenFile to to the client config file.
@smarterclayton @deads2k @cjcullen @krousey
Part of the fix for #28260
Automatic merge from submit-queue
Return the current kubeconfig as the starting config in ClientConfigGetter.
This fixes issue #30790.
cc @kubernetes/sig-cluster-federation
Automatic merge from submit-queue
Basic scaler/reaper for petset
Currently scaling or upgrading a petset is more complicated than it should be. Would be nice if this made code freeze on friday. I'm planning on a follow up change with generation number and e2es post freeze.
Automatic merge from submit-queue
Add a short `-n` for `kubectl --namespace`
fixes#24078
`--namespace` is a very common flag for nearly every `kubectl` command we have. We should claim `-n` for it.
Convert single GV and lists of GVs into an interface that can handle
more complex scenarios (everything internal, nothing supported). Pass
the interface down into conversion.
Automatic merge from submit-queue
Handle container terminated but pod still running in conditions
Sometimes when you have a pod with more than one container, and the container runs and terminates really fast, `PodContainerRunning` can go into a state where the pod indicates it's still running, but the container is already terminated. Handle that condition by returning `ErrContainerTerminated` when it happens.
deads2k