Change the signature of GuaranteedUpdate so that TTL can
be more easily preserved. Allow a simpler (no ttl) and
more complex (response and node directly available, set ttl)
path for GuaranteedUpdate. Add some tests to ensure this
doesn't blow up again.
Makes it possible to access the following subresources:
/namespaces/<ns>/pods/<pod-name>[:port]/proxy
/namespaces/<ns>/pods/<pod-name>/exec?container=<container>&command=<cmd>
/namespaces/<ns>/pods/<pod-name>/portforward
PodExecOptions represents the URL parameters used to invoke an
exec request on a pod. PodProxyOptions contains the path parameter
passed to a proxy request.
Allows REST consumers to build paths like:
/api/v1beta3/namespaces/foo/webhookresource/<name>/<encodedsecretinurl>
Also fixes parameter exposure for subresources (was only fixed for
v1beta3).
Adds a Log subresource to Pod storage. The Log subresource implements
rest.GetterWithOptions and produces a ResourceStreamer resource that
will stream the log output from the pod's host node.
Convert the return value of pods rest.NewStorage to a struct.
This will allow returning more storage objects for a pod (sub resources)
without awkwardly adding more return values.
This commit adds support to core resources to enable deferred deletion
of resources. Clients may optionally specify a time period after which
resources must be deleted via an object sent with their DELETE. That
object may define an optional grace period in seconds, or allow the
default "preferred" value for a resource to be used. Once the object
is marked as pending deletion, the deletionTimestamp field will be set
and an etcd TTL will be in place.
Clients should assume resources that have deletionTimestamp set will
be deleted at some point in the future. Other changes will come later
to enable graceful deletion on a per resource basis.
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.
