OK i think i understand... So I would need to place the generated Deployment ID in the POD template (somehow?) at deployment time? Then I could read the metadata and use the normal Kube API to query for all the objects with same id?
On Mon, Mar 27, 2017 at 5:02 PM, 'Tim Hockin' via Kubernetes user discussion and Q&A <kubernetes-users@googlegroups.com> wrote: > Every object in the Kube API has a metadata block and labels field > therein. You can put any metadata you like in there. Additionally, > Deployment's pod template has the same field, which will be used when > stamping out replicas. > > Once labelled, any resource can be selected by label. > > Does that do what you want? > > On Mar 27, 2017 4:53 PM, <jhay...@gmail.com> wrote: > >> I have a _very_ n00b question as I'm just getting into Kubernetes (from >> docker swarm land). >> >> As part of our deployment we have a script that will generate a unique ID >> (Deployment ID) when deploying a new swarm deployment and as part of this >> deployment all services and containers in the swarm deployed as part of the >> deployment will have this ID. The ID as both part of the service label and >> each container as this as a label. This label is added post docker build >> (i.e. it's not on the container when build and pushed to the registry, only >> when its deployed as an instance in a swarm by the Swarm using the >> ServiceSpec). >> >> We use this ID to track unique containers across various deployments so >> we can track lifecycle statistics, deployments, etc. We can also link the >> metadata around each container and deployment with this ID. >> >> I'm trying to see how this could translate into the Kubernetes world. >> What would be the canonical way to do something like this in Kubernetes? >> Since it seems like Kubernetes as the concept of a deployment (where Swarm >> really doesn't) object I assume that theres a way to easily figure out all >> the pods, etc as part of that? Or maybe a reverse question, if a container >> had access to the Kubernetes API at runtime, could it query using this ID >> (somehow it would need to know it's own deployment ID) and then get all the >> Pods from it? >> >> Any directions, recommendations, suggestions very welcome. >> >> Thank you. >> Jeff >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Kubernetes user discussion and Q&A" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to kubernetes-users+unsubscr...@googlegroups.com. >> To post to this group, send email to kubernetes-users@googlegroups.com. >> Visit this group at https://groups.google.com/group/kubernetes-users. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "Kubernetes user discussion and Q&A" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/kubernetes-users/TLTJpJAIsxI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > kubernetes-users+unsubscr...@googlegroups.com. > To post to this group, send email to kubernetes-users@googlegroups.com. > Visit this group at https://groups.google.com/group/kubernetes-users. > For more options, visit https://groups.google.com/d/optout. > -- Jeff Haynie medium.com/@jhaynie @jhaynie -- You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group. To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscr...@googlegroups.com. To post to this group, send email to kubernetes-users@googlegroups.com. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.