We decided to get rid of boundPods. Removing this check is
a prerequisite for that. This check had some value before we had
IP-per-Pod. However, AIUI, use of HostPort is strongly discouraged
in Kubernetes. It still exists as part of a Pod spec because
of ContainerVM, where it is used. But, this change does not affect
ContainerVM, where there is no master.
If someone did create pods with HostPort using kubernetes, the following
would happen:
- The scheduler would try not to put two conflicting pods on the same
machine (pkg/scheduler/predicates.go : PodFitsPorts() )
- I'm not sure if it is currently possible for a race to occur where
the PodFitsPorts check were bypassed. Maybe it could happen.
- If the kubelet was sent conflicting pods, it would detect them in
( pkg/kubelet/kubelet.go : filterHostPortConflicts() ). It would
arbitrarily pick one pod to run and another to ignore.
- If all of the above happened and the user filed and issue on github,
we might figure out that the user used HostPort and tell the user to stop.
TODO:
- e2e test
- Several of the demos in examples/ use hostPort. Change them to
not specify hostPort and have a service instead.
Allows POST to create a binding as a child. Also refactors internal
and v1beta3 Binding to be more generic (so that other resources can
support Bindings).
PUT /api/v1beta3/namespaces/default/pods/foo/status
{
"metadata": {...}, // allowed for valid values
"spec": {}, // ignored
"status": {...}, // allowed, except for Host
}
Exposes the simplest possibly change. Needs a slight refactoring
to RESTUpdateStrategy to split merging which can be done in a
follow up.
They will still show up in etcd. They never were available
through the API.
A subsequent PR(s) will rip out all BoundPods code.
Working in small increments.
This PR will cause users on lagging cloud providers
to not get env vars in their pods if they update to this code.
They have already been warned via email.
Removed unit tests of BasicBoundPodFactory.
There is adequate coverage in pkg/kubelet/kubelet_test.go.
Also make sure all POST operations return 201 by default.
Removes the remainder of the asych logic in RESTStorage and
leaves it up to the API server to expose that behavior.
Currently, the validation logic validates fields in an object and supply default
values wherever applies. This change factors out defaulting to a set of
defaulting callback functions for decoding (see #1502 for more discussion).
* This change is based on pull request 2587.
* Most defaulting has been migrated to defaults.go where the defaulting
functions are added.
* validation_test.go and converter_test.go have been adapted to not testing the
default values.
* Fixed all tests with that create invalid objects with the absence of
defaulting logic.
If a client says they want the name to be generated, a 409 is
not appropriate (since they didn't specify a name). Instead, we
should return the next most appropriate error, which is a 5xx
error indicating the request failed but the client *should* try
again. Since there is no 5xx error that exactly fits this purpose,
use 500 with StatusReasonTryAgainLater set.
This commit does not implement client retry on TryAgainLater, but
clients should retry up to a certain number of times.
Replaces the client public interface but leaves old references to "minions"
for a later refactor. Selects the path "nodes" for v1beta3 and "minions"
for older versions.
GetServiceEnvironmentVariables (originally in pkg/registry/service/rest.go)
is split into two parts: one that lists services, and one that turns
a ServiceList into environment vars. This will allow a subsequent PR
to add a call to the latter function with an existing ServiceList.
The former part is moved into pkg/registry/pod/bound_pod_factory.go.
The latter part is put in a new package, pkg/kubelet/envvars/envvars.go.
The new package is under kubelet because the container enviroment is more
associated with kubelet than with registry.
Test code moved too.
PUT allows an object to be created (http 201). This allows REST code to
indicate an object has been created and clients to react to it.
APIServer now deals with <-chan RESTResult instead of <-chan runtime.Object,
allowing more data to be passed through.
Allows us to define different watch versioning regimes in the future
as well as to encode information with the resource version.
This changes /watch/resources?resourceVersion=3 to start the watch at
4 instead of 3, which means clients can read a resource version and
then send it back to the server. Clients should no longer do math on
resource versions.
This includes 3 changes:
1) Use the Service.Protocol field, rather than hardcoding TCP.
2) Use Service.Port rather than ContainerPort - ContainerPort can be a string
and has absolutely no meaning to consumers.
3) Beef up tests for these env vars.
Brian Grant