This is discussed in #9356 (comment)

@dchen1107 - thanks for the link, but I don't think that applies here? (Unless there's a trick I'm missing, which is not unlikely). I know I can get the information from the API (via kubectl or curl), I was just hoping for a more direct way inside my container. In my host I have /sys/fs/cgroup/memory/, and apparently this is usually available in Docker containers also, although I don't see it in my Docker k8s containers (on AWS or GCE).

We call this "downward API". See also #386. cc @pmorie

@bgrant0607 My bad, I somehow missed being tagged into this.

@justinsb I definitely think this should be available via the downward API.

@justinsb I'm going to take a stab at this today.

@justinsb Let me make sure we're on the same page about what you want before I write code. It sounds to me like what you're asking for is: if you set the ResourceRequirements field of a container, you want to be able to consume that information via the downward API. Accurate?

@pmorie I think this would be useful for the downwards API. But: my workaround is to simply list all the pods and match podIP, and get my full pod info that way. This means that the manifest doesn't require the user to include any additional information (i.e. the downward API mapping). It's not pretty, and it isn't efficient because we can't currently filter by podIP, but I find it pretty tolerable.

It seems like the biggest challenge to doing this is getting the API right. Currently, the downward API only supports references to Pod-scoped fields, like so:

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "env" ]
      env:
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
  restartPolicy: Never

With this change we need to expand the scope of the API to container-scoped fields. There are a couple different facets to consider:

1. If you're consuming the API in environment variables, it might be natural to have a container-scoped field of the EnvVarSource
2. If you're consuming the API in a volume (see downward api volume plugin #5093, which I hope will be merged soon), the scope in which you specify fields is pod scoped, so if you want to be able to consume resource limits in a volume, we need a way to address a container's resource limits in a ObjectFieldSelector

I'm not sure that this value makes a lot of sense to consume in an environment variable.

Any thoughts @smarterclayton @bgrant0607 ?

Example of possible API:

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "env" ]
      env:
        - name: CONTAINER_MEMORY
          valueFrom:
            containerFieldRef:
              fieldPath: "resources.limits.memory"
  restartPolicy: Never

Some other little nits about this:

1. The Quantity API type supports formatting, which is something you would conceivably want to apply to the quantities for this API
2. The ResourceList type is actually a map[ResourceType]resource.Quantity -- what's right expression syntax we want for this? Do we want to parse resources.limits[memory] in an api label conversion function?

Perhaps @rjnagal, @vmarmol, or @vishh have thoughts about this. I'd prefer a non-Kubernetes-specific way to communicate resource info, if feasible. (I'd consider a kernel change to be infeasible, as an example, at least in the short term.)

@bgrant0607 Can you elaborate on what you meant by non-Kubernetes-specific way? I'm assuming you mean to decouple the container from the kubernetes API, but I want to verify.

Most of the resource isolation parameters are available through cgroups. Although some of these may require some translation to be useful (like shares). Even then it may depend on how the application sets up the containers. It may be good enough for now, but there are many details that won't work in a more "general" way.

Yes, decoupled from the Kubernetes API, both from the precise schema and also from inherently Kubernetes-specific idioms. (Arguably pods don't have to be Kubernetes-specific, as a few other systems have adopted them.)

I don't know that I buy the idea that people will take "run this external
command" as a way to get container limits and other info. It just doesn't
sound practical to me. I also don't buy that going to the kernel is the
best way to do it. I think we either offer a runtime API, a pre-pop file,
or we do something like what Paul is suggesting here.

This exposes some of what I was afraid of with fieldpath - it sounds really
general purpose, but without an anchor like "this container" it's not
really useful.

On Thu, Jul 23, 2015 at 7:08 PM, Brian Grant notifications@github.com
wrote:

Yes, decoupled from the Kubernetes API, both from the precise schema and
also from inherently Kubernetes-specific idioms. (Arguably pods don't have
to be Kubernetes-specific, as a few other systems have adopted them.)

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

Let's also be clear - upstream kernel folks have, in the past, declared
this as dangerous and broken, and not guaranteed to be supported.

On Mon, Aug 31, 2015 at 7:40 AM, Derek Carr notifications@github.com
wrote:

@vishh https://github.com/vishh @pmorie https://github.com/pmorie -
making it part of spec is useful, I just wanted to make sure that people
knew there was an alternate method to get memory limits in the interim.

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

@thockin - understood, just wanted to make sure that @justinsb knew that the original location he had been looking for the memory information should be populated in docker 1.8. This is just one potential stop-gap until real kernel solution is available.

@pmorie: How about exposing the API server APIs via the kubelet in read-only mode?

@vishh Do you need a kubeconfig and client in the container to use it?

I think so. If we ignore access control for now, since the APIs are
read-only, can we skip auth?

On Tue, Sep 1, 2015 at 10:16 AM, Paul Morie notifications@github.com
wrote:

@vishh https://github.com/vishh Do you need a kubeconfig and client in
the container to use it?

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

@pmorie: Were you able to make any progress?

This is a P1 issue-- what is the status? If no one is working on it, I will demote to P2.

I haven't had time to work on this further, we should bump down to p2

On Thursday, September 24, 2015, Daniel Smith notifications@github.com
wrote:

This is a P1 issue-- what is the status? If no one is working on it, I
will demote to P2.

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

cc @dchen1107 @davidopp

In case someone didn't notice it, the proposal is #24051

Implemented in #24179

Closed by #24179

.spec.containers[?(@.name=="test-container")].resources.limits.memory

LGTM