Home • Explore • Blog • CI
☰



kubernetes
3rd chunk of `content/en/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout_11.md`
a941636e7f644d4c767de4fd3de47752655d88ee6189372b0000000100000951
    * resourcebuilder has concept of doing that kind of expansion depending on how we fit in targeted commands. for instance if you want to add a volume to pods and rcs, you need something to go find the pod template and change it. there's the search part of it (delete nginx -> you have to figure out what object they are referring to) and then command can say i got a pod i know what to do with a pod.

    * alternative heuristic: what if default target of all commands was deployments. kubectl run -> deployment. too much work, easier to clean up existing CLI. leave door open for that. macro objects OK but a lot more work to make that work. eventually will want index to make these efficient. could rely more on swagger to tell us types.

2\. paul/downward api: env substitution

  * create ad-hoc env var like strings, e.g. k8s_pod_name that would get sub'd by system in objects.
  * allow people to create env vars that refer to fields of k8s objects w/o query api from inside their container; in some cases enables query api from their container (e.g. pass obj names, namespaces); e.g. sidecar containers need this for pulling things from api server.
  * another proposal similar: instead of env var like names, have JSON-path-like syntax for referring to object field names; e.g. $.[metadata.name][1] to refer to name of current object, maybe have some syntax for referring to related objects like node that a pod is on. advantage of JSON path-like syntax is that it's less ad hoc. disadvantage is that you can only refer to things that are fields of objects.
  * for both, if you populate env vars then you have drawback that fields only set when container is created. but least degree of coupling -- off the shelf containers, containers don't need to know how to talk to k8s API. keeps the k8s concepts in the control plane.
  * we were converging on JSON path like approach. but need prototype or at least deeper proposal to demo.
  * paul: one variant is for env vars in addition to value field have different sources which is where you would plug in e.g. syntax you use to describe a field of an object; another source would be a source that described info about the host. have partial prototype. clean separation between what's in image vs. control plane. could use source idea for volume plugin.
  * use case: provide info for sidecar container to contact API server.
Title: Kubernetes Community Hangout: Kind Discovery Continued and Downward API Deep Dive
Summary
Continuing the discussion on 'kind discovery', the community explored using the resourcebuilder for command targeting and the possibility of defaulting command targets to deployments. A significant portion focused on the Downward API, examining environment variable substitution and JSON-path-like syntax for referencing object fields. The benefits and drawbacks of each approach were debated, with emphasis on minimizing coupling and keeping Kubernetes concepts in the control plane. A prototype for a JSON-path-like approach is desired. A proposal with different sources was also discussed, including host information. A key use case is to provide information for sidecar containers to contact the API server.