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.

Reply via email to