Document what docker image (Dockerfile) features we support

[yujuhong]

For example, we don't support HEALTHCHECK.

We support STOPSIGNAL when using docker daemon (#30051).

/cc @thockin @kubernetes/sig-node

[thockin]

I was thinking more about healthcheck. Especially in a CRI world, could we
make "healthiness" be a responsibility of the plugin? Then this could work
(as awkward as it is). Anyway, just an idea.

On Wed, Aug 3, 2016 at 5:22 PM, Yu-Ju Hong [email protected] wrote:

For example, we don't support HEALTHCHECK.

/cc @thockin https://github.com/thockin @kubernetes/sig-node
https://github.com/orgs/kubernetes/teams/sig-node

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#30039, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AFVgVA3taXR81NC04-Q-vW1k8CdPCj0Mks5qcTC5gaJpZM4JcOWk
.

[yujuhong]

Especially in a CRI world, could we
make "healthiness" be a responsibility of the plugin?

To support this, we don't necessarily have to push healthcheck down to the runtime. We could augment the container status in CRI by adding an "unhealthy" state, and let kubelet decides whether to kill/restart the container. kubelet can still perform the liveness/healthness checks kubernetes API.

What I really don't like is that nothing in our pod spec reflects the fact that there are health checks hidden in the image already...

[thockin]

On Thu, Aug 4, 2016 at 10:25 AM, Yu-Ju Hong [email protected] wrote:

Especially in a CRI world, could we
make "healthiness" be a responsibility of the plugin?

To support this, we don't necessarily have to push healthcheck down to the runtime. We could augment the container status in CRI by adding an "unhealthy" state, and let kubelet decides whether to kill/restart the container. kubelet can still perform the liveness/healthness checks kubernetes API.

What I really don't like is that nothing in our pod spec reflects the fact that there are health checks hidden in the image already...

ACK. But I think that's less bad than not supporting it at all. I
think. I haven't estimated the work, and it's certainly not URGENT
yet. :)

[yujuhong]

Sure, and we don't support docker v1.12 (yet).

Another concern is whether other runtimes which supports docker images will also perform the health checks. If not, the behavior will be completely runtime-dependent, and even more confusing for the users.

[thockin]

yeah, many issues to resolve here.

On Thu, Aug 4, 2016 at 10:34 AM, Yu-Ju Hong [email protected]
wrote:

Sure, and we don't support docker v1.12 (yet).

Another concern is whether other runtimes which supports docker images
will also perform the health checks. If not, the behavior will be
completely runtime-dependent, and even more confusing for the users.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#30039 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVPreSFnVC4ysi49YOr-REJSRydMxks5qciKugaJpZM4JcOWk
.

[agadelshin]

@yujuhong could you please refer to issues related with 1.12 support? I haven't met problem with 1.12 yet on test environment.

[yujuhong]

@pondohva my comments above was outdated. Kubernetes 1.4 is compatible with docker 1.12, so it should be fine for you to use it. See the 1.4 release note for more information. That said, kubernetes doesn't support all features in Dockerfile, and many of those already existed in the kubernetes API (e.g., health checks).

The recommended docker version (i.e., the version we tested most thoroughly in the GCE+containerVM/GCI environment) for kubernetes 1.4 is docker 1.11.2.

[yujuhong]

Let's see if we can take on this in v1.7.

/cc @Random-Liu, this information would be good to have for containerd integration as well.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[yujuhong]

Marking it 1.10 tentatively since this would be good for non-docker CRI runtimes.

[jberkus]

If this is going into 1.10, can you please add a priority/ to it? Thanks!

[jberkus]

Has there been any work on this issue? Do you expect to get it done in the next 5 days for 1.10?

[yujuhong]

https://docs.docker.com/engine/reference/builder

Instruction	Description	Supported	Comment
ENTRYPOINT	Executable to run	Y	Supported by the runtime(s)
CMD	Arguments to supply to the ENTRYPOINT	Y	Supported by the runtime(s)
EXPOSE	Ports that container intends to listen for informative purpose only	N/A	Does not have an actual effect
VOLUME	Mount points for volumes from host or other containers	Y and N	Supported by runtime(s); no proper resource accounting and is not exposed in the Kubernetes API
USER	User name (or UID) and optionally the user group (or GID) to use	Y	Supported (and partially checked) by Kubelet
WORKDIR	Working directory	Y	Supported by the runtime(s)
STOPSIGNAL	System call signal to send	Y	Supported by the runtime(s)
HEALTHCHECK	Container health checks	N	Explicitly disabled

Image building instructions that are not relevant in this context: FROM, ADD, COPY, MAINTAINER, LABEL, ARG, ONBUILD, SHELL

[Random-Liu]

@yujuhong We don't support GID now, in CRI we only return Username and UID. We should add the support.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[dims]

long-term-issue (note to self)

[adisky]

/remove lifecycle-frozen
/triage accepted

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

[k8s-ci-robot]

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[dims]

/close

[k8s-ci-robot]

@dims: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.