Add port annotations to know what protocols a port will support for pods, maybe services

[jwforres]

There are several use cases where knowing what protocols a port on a container in a pod actually supports would affect information presented to end users.

Ex 1:
I have a container in a pod exposing port 8080, do we show a clickable link in the GUI? Right now we have to assume it exposes http(s) and always show the link, or never show a link. If the port was annotated to say that it supported http(s) we would know for sure.

Ex 2:
I have a container in a pod exposing port 8080, I don't have any services routing to the pod. Should I recommend to the end user that they create a service? If the port were annotated to say that it exposes http(s) then we would be more likely to suggest they create a service than if it was annotated to expose a different protocol.

[jwforres]

CC @danmcp @smarterclayton

[smarterclayton]

It gets complicated very fast to define a "protocol" language other than by convention. Some things that we've considered in the past

Most people want to know whether a port is HTTP or HTTPS, and some people want to know whether that supports web sockets (or should support web sockets). A few people want to know whether a port is mysql, and some want to know whether it's really mysql+tls. A lot of people want to annotate ports that are debugging ports so that automation tools don't expose them automatically.

[erictune]

In the gui, how about show a link if the port is 80, 443, 8008, or 8080, and not otherwise?
Should do something reasonable in a lot of cases?

[jwforres]

The http(s) links were just an example, there are more use cases than that.

An annotation could let us know that the port is an admin console port, letting us show a special icon next to that link. Same with a debug port.

Or lets say I support ftp on the port, and I want to actually make the URL in the GUI have the ftp:// protocol.

[smarterclayton]

A lot of web frameworks these days choose completely random ports - for instance rails defaults to 3000, django is 8000, etc. 80 is usually http, but 443 can be anything. Mysql is 3306, but might not be.

I think the idea is more to allow metadata to decorate endpoints that can be interpreted by programs, rather than not being able to attach metadata at all. That metadata might also be something like the default timeout, or something else that a consumer might reasonably need to know.

This also applies to service ports, pods were just one place to start.

----- Original Message -----

The http(s) links were just an example, there are more use cases than that.

An annotation could let us know that the port is an admin console port,
letting us show a special icon next to that link. Same with a debug port.

Or lets say I support ftp on the port, and I want to actually make the URL in
the GUI have the ftp:// protocol.

---

Reply to this email directly or view it on GitHub:
#6908 (comment)

[thockin]

Ports have names. We can define best-practices there (eg naming your port
"http" is a clue that it supports http. Once we have SRV fixed up (if you
all would just stop emailing me :) you will be able to do do SRV lookups
for _http._tcp.mysvc.myns.kubernetes.local - but the _http is only known
insofar as the port name.

I'm open to proposals how to annotate more or better.

On Thu, Apr 16, 2015 at 12:13 PM, Clayton Coleman notifications@github.com
wrote:

A lot of web frameworks these days choose completely random ports - for
instance rails defaults to 3000, django is 8000, etc. 80 is usually http,
but 443 can be anything. Mysql is 3306, but might not be.

I think the idea is more to allow metadata to decorate endpoints that can
be interpreted by programs, rather than not being able to attach metadata
at all. That metadata might also be something like the default timeout, or
something else that a consumer might reasonably need to know.

This also applies to service ports, pods were just one place to start.

----- Original Message -----

The http(s) links were just an example, there are more use cases than
that.

An annotation could let us know that the port is an admin console port,
letting us show a special icon next to that link. Same with a debug port.

Or lets say I support ftp on the port, and I want to actually make the
URL in
the GUI have the ftp:// protocol.

---

Reply to this email directly or view it on GitHub:

#6908 (comment)

—
Reply to this email directly or view it on GitHub
#6908 (comment)
.

[bgrant0607]

cc @janetkuo

[bgrant0607]

Example use case: Determine whether to construct a proxy or portforward URL to the application.

I think this should be more than just annotations -- we should extend the API. I haven't had time to think about a concrete proposal, though.

There's other application information we'll want. For example, see #5721.

[bgrant0607]

Proposal: #14828

[bgrant0607]

cc @ggogolowicz

[bgrant0607]

https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/service-discovery.md

[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

[thockin]

We have application-protocol coming (annotation for now)