From cbd87b375a1be548937cc4a740996eeaa6b6cc7d Mon Sep 17 00:00:00 2001 From: Brendan Burns Date: Mon, 2 Feb 2015 16:27:47 -0800 Subject: [PATCH] Update docs to reflect reality. --- docs/container-environment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/container-environment.md b/docs/container-environment.md index fa96fe52e53..aba02f024e1 100644 --- a/docs/container-environment.md +++ b/docs/container-environment.md @@ -72,7 +72,7 @@ For hooks which have parameters, these parameters are passed to the event handle ### Hook Handler Implementations Hook handlers are the way that hooks are surfaced to containers.  Containers can select the type of hook handler they would like to implement.  Kubernetes currently supports two different hook handler types: - * Exec - Executes a specific command (e.g. pre-stop.sh) inside the cgroup and namespaces of the container.  Resources consumed by the command are counted against the container.  Commands which return non-zero values are treated as container failures (and will cause kubelet to forcibly restart the container).  Parameters are passed to the command as traditional linux command line flags (e.g. pre-stop.sh --reason=HEALTH) + * Exec - Executes a specific command (e.g. pre-stop.sh) inside the cgroup and namespaces of the container.  Resources consumed by the command are counted against the container.  Commands which print "ok" to standard out (stdout) are treated as healthy, any other output is treated as container failures (and will cause kubelet to forcibly restart the container).  Parameters are passed to the command as traditional linux command line flags (e.g. pre-stop.sh --reason=HEALTH) * HTTP - Executes an HTTP request against a specific endpoint on the container.  HTTP error codes (5xx) and non-response/failure to connect are treated as container failures. Parameters are passed to the http endpoint as query args (e.g. http://some.server.com/some/path?reason=HEALTH)