Files
kubernetes/staging
Kubernetes Submit Queue 23226c24d4 Merge pull request #58070 from weekface/weekface/aggregator-proxy-fix
Automatic merge from submit-queue (batch tested with PRs 57896, 58070). 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>.

Don't remove APIService from apiHandlerManager when its Available Conditions is not True

**What this PR does / why we need it**:

I use my own apiserver works together with `kube-apiserver`, i have a custom resource: `databases` and created a `database` named: `db-name-1`.

When this apiserver is down(for example: OOMKilled), `kubectl get databases db-name-1 -v 10` returns `404 NotFound`:

```
[{
  "metadata": {},
  "status": "Failure",
  "message": "the server could not find the requested resource (get databases.core.example.com db-name-1)”,
  "reason": "NotFound",
  "details": {
    "name": “db-name-1”,
    "group": "core.example.com",
    "kind": “databases”,
    "causes": [
      {
        "reason": "UnexpectedServerResponse",
        "message": "404 page not found"
      }
    ]
  },
  "code": 404
}]
```

But it is not really `NotFound`.

So if the APIService is not available, just return 503.

There was a PR related with this: #57943 

**Release note**:


```release-note
kube-apiserver: requests to endpoints handled by unavailable extension API servers (as indicated by an `Available` condition of `false` in the registered APIService) now return `503` errors instead of `404` errors.
```
2018-01-21 20:25:31 -08:00
..
2018-01-17 16:23:03 +08:00

External Repository Staging Area

This directory is the staging area for packages that have been split to their own repository. The content here will be periodically published to respective top-level k8s.io repositories.

Repositories currently staged here:

The code in the staging/ directory is authoritative, i.e. the only copy of the code. You can directly modify such code.

Using staged repositories from Kubernetes code

Kubernetes code uses the repositories in this directory via symlinks in the vendor/k8s.io directory into this staging area. For example, when Kubernetes code imports a package from the k8s.io/client-go repository, that import is resolved to staging/src/k8s.io/client-go relative to the project root:

// pkg/example/some_code.go
package example

import (
  "k8s.io/client-go/dynamic" // resolves to staging/src/k8s.io/client-go/dynamic
)

Once the change-over to external repositories is complete, these repositories will actually be vendored from k8s.io/<package-name>.