Add some documentation for the container environment. #1445
Conversation
| Additionally, the Kubernetes container environment defines a series of signals that are surfaced to optional signal handlers defined as part of individual containers. Container signals are somewhat analagous to operating system signals in a traditional process model. However these signals are designed to make it easier to build reliable, scalable cloud applications in the Kubernetes cluster. Containers that participate in this cluster lifecycle become *cluster native*. | ||
|
|
||
| The following sections describe both the cluster information provided to containers, as well as the signals and life-cycle that allows containers to interact with the management system. | ||
|
|
There was a problem hiding this comment.
The first thing I would have expected to see here would be something about my filesystem. Maybe link to volumes.md, and or say something like "The filesystem seen by a process in a container is a combination of its Docker image and any Volumes it requested," and so on.
|
I'm assigning Eric as final approver |
|
I'd like to put a hold on merge for me to have a chance to review (or someone else on my team). No later than tomorrow, just swamped today. |
| FOO_PORT_BAR_TCP=tcp://${FOO_PORT_BAR_TCP_ADDR}:${FOO_PORT_BAR_TCP_PORT} | ||
| ``` | ||
|
|
||
| Going forward, we expect that Services will have a dedicated IP address. In that context, we will also surface services to the container via DNS. Of course DNS is still not an enumerable protocol, so we will continue to provide environment variables so that containers can do discovery. |
There was a problem hiding this comment.
I think it's still open whether we support the environment variables or not. They are problematic, and I don't believe the enumeration they provide is useful.
There was a problem hiding this comment.
By "open whether we support the environment variables or not" do you mean, whether we support adding them automatically to every pod, instead of requiring the pod author to indicate they want them exposed? Or something else?
|
This file should be called container-environment.md rather than cluster-environment.md |
| There are two types of information that are available within the container environment. There is information about the container itself, and there is information about other objects in the system. | ||
|
|
||
| ### Container Information | ||
| Currently, the only information about the container that is available to the container is the Pod name for the pod in which the container is running. This ID is set as the hostname of the container, and is accessible through all calls to access the hostname within the container (e.g. the hostname command, or the [gethostname][1] function call in libc). Additionally, user-defined key-value environment variables from the pod definition, are also available to the container. |
There was a problem hiding this comment.
You say Pod name and then ID in the next sentence - probably say "name is set as the hostname of each container in the pod"
|
Hold withdrawn |
|
Status: awaiting author responses to comments from reviewers. |
|
Ok, I've updated to address most of the comments. Please let me know if there are any more blockers. I'd like to checkpoint this in, as I think it is largely accurate description of the state of things. |
|
Renamed to container-enviroment.md |
|
I think "signal" is an extremely poor choice of terminology, but I'm fine if it gets changed in a subsequent PR. |
Add some documentation for the container environment.
@smarterclayton @bgrant0607 @thockin @erictune
We've talked about some of this in the past. Mostly this describes what is already implemented, but there are some proposals in there as well, please take a look.