Automatic merge from submit-queue
use in-cluster kubeconfig for genericapiserver
Allow the use of the in-cluster config to communicate with the core API server for delegated authn/authz for an addon API server.
@kubernetes/sig-api-machinery @sttts
Automatic merge from submit-queue
Remove dead code in `pkg/registry/generic/registry/store.go`
Fixes#38822
Depending on the intent of the original code, the correct fix may instead be:
```go
if name, ok := p.MatchesSingle(); ok {
key, err := e.KeyFunc(ctx, name)
if err != nil {
return nil, err
}
w, err := e.Storage.Watch(ctx, key, resourceVersion, p)
if err != nil {
return nil, err
}
if e.Decorator != nil {
return newDecoratedWatcher(w, e.Decorator), nil
}
return w, nil
// if we cannot extract a key based on the current context, the optimization is skipped
}
```
Signed-off-by: Monis Khan <mkhan@redhat.com>
cc @deads2k
Automatic merge from submit-queue
genericapiserver: turn APIContainer.SecretRoutes into a real ServeMux
The secret routes `Mux` is actually a `http.ServeMux` and we are type-casting to it. For downstream we want to wrap it into a restful container which also needs a real `http.ServeMux`.
Automatic merge from submit-queue
Fix Recreate for Deployments and stop using events in e2e tests
Fixes https://github.com/kubernetes/kubernetes/issues/36453 by removing events from the deployment tests. The test about events during a Rolling deployment is redundant so I just removed it (we already have another test specifically for Rolling deployments).
Closes https://github.com/kubernetes/kubernetes/issues/32567 (preferred to use pod LISTs instead of a new status API field for replica sets that would add many more writes to replica sets).
@kubernetes/deployment
Automatic merge from submit-queue
Migrated fluentd addon to daemon set
fix#23224
supersedes #23306
``` release-note
Migrated fluentd addon to daemon set
```
Automatic merge from submit-queue
daemonset: bail out after we enqueue once
This isn't terrible because we dedup in the queue but it's a waste of
cycles.
Automatic merge from submit-queue
kubeadm: refactor discovery behind an interface
This adds support for alternative discovery methods using discovery urls. It is a breaking change. This is a WIP.
Example usage:
```
$ kubeadm init --discovery token://
$ kubeadm join --discovery token://c05de9:ab224260fb3cd718@192.168.0.1:6555,191.168.0.2:6443
$ kubeadm join --discovery file:///etc/kubernetes/cluster.json
$ kubeadm join --discovery https://storage.google.apis.com/kube-discovery/98ea6e4/kubeconfig.json
```
@kubernetes/sig-cluster-lifecycle
Automatic merge from submit-queue
make kubectl factory composeable
Alternate resolution of https://github.com/kubernetes/kubernetes/pull/38524.
Currently, the kubectl factory cannot be cleanly composed because without polymorphism, any calls which delegate to other factory methods cannot injected. We cannot reasonably predict everything a composer would want to override, so enumeration of individual "we think this field is important" function is untenable. On the other hand, having a method registry func and attaching methods to it resulted in chaos before 1.5 and the cleaner interface.
This pull takes the approach of building the factory in "rings" of subfactories. RingN relies on RingN-1 and the overall factory is a set of nested factories. No function in a "ring" is allowed to reference a peer function, but it may reference a parent ring's function. This allows us to easily compose one chain for raw kube, but an extender can simply wrap a particular ring with his custom handling of particular functions and then continue the chain as normal. This allows customization of each individual function.
It turns out that we have three rings.
1. discovery, negotiation, and no-dep functions
1. object typing and type mapping
1. stuff that relies on type mapping (builder)
This pull does nothing split apart the dependencies. No behavior changes. There's more cleanup that could be done (particularly in naming), but I'd like to defer that to a later step.
@kubernetes/sig-cli @fabianofranz @AdoHe this is going to be a pain to rebase, so quick reviews are appreciated.
@ncdc @smarterclayton
Automatic merge from submit-queue
Don't eat 403 in service controller
I haven't done a stress run of Services e2es locally yet, but I did verify that this fixes the specific "stuck in pending bug"
Automatic merge from submit-queue (batch tested with PRs 38818, 38813, 38820)
update for controller RBAC roles
Role and binding updates from running e2e using RBAC during the tests in https://github.com/kubernetes/kubernetes/pull/38626
@sttts should be quick. No obvious typos. Nothing that looks off.
Automatic merge from submit-queue (batch tested with PRs 38818, 38813, 38820)
AWS: Add sequential allocator for device names.
On AWS, we should not reuse device names as long as possible, see https://aws.amazon.com/premiumsupport/knowledge-center/ebs-stuck-attaching/
> "If you specify a device name that is not in use by EC2, but is being used by the block device driver within the EC2 instance, the attachment of the EBS volume does not succeed and the EBS volume is stuck in the attaching state."
This patch adds a device name allocator that tries to find a name that's next to the last used device name instead of using the first available one. This way we will loop through all device names ("xvdba" .. "xvdzz") before a device name is reused.
Fixes: #31891
@wongma7, @gnufied, @childsb PTAL
On AWS, we should not reuse device names as long as possible, see
https://aws.amazon.com/premiumsupport/knowledge-center/ebs-stuck-attaching/
"If you specify a device name that is not in use by EC2, but is being used by
the block device driver within the EC2 instance, the attachment of the EBS
volume does not succeed and the EBS volume is stuck in the attaching state."
This patch adds a device name allocator that tries to find a name that's next
to the last used device name instead of using the first available one.
This way we will loop through all device names ("xvdba" .. "xvdzz") before
a device name is reused.
