Add first version of Pod proto #30
Conversation
mfpierre
force-pushed
the
mfpierre/collect-pods
branch
from
c06680b to
df92f7a
Compare
mfpierre
force-pushed
the
mfpierre/collect-pods
branch
from
df92f7a to
a2b0dc5
Compare
proto/process/agent.proto
Outdated
| string IP = 4; | ||
| string nominatedNodeName = 5; | ||
| string nodeName = 6; | ||
| int32 restartCount = 7; |
There was a problem hiding this comment.
nit, does this need to be an int32? is there a smaller type that we could use?
There was a problem hiding this comment.
I matched the original definition https://github.com/kubernetes/kubernetes/blob/cb19b56831d54d1d31249949318ef0b07bf00df9/staging/src/k8s.io/api/core/v1/generated.proto#L902 I guess it could be smaller
proto/process/agent.proto
Outdated
| } | ||
|
|
||
| message OwnerReference { | ||
| string apiVersion = 5; |
There was a problem hiding this comment.
nit, if we're intentionally omitting field 2, can we mark it as reserved?
There was a problem hiding this comment.
weird, it's copy pasted from https://github.com/kubernetes/kubernetes/blob/006378fcc1c8db4f7063812b67a59969fc0d09f0/staging/src/k8s.io/apimachinery/pkg/apis/meta/v1/generated.proto#L699 I guess I can reorder the ids
| message ContainerStatus { | ||
| string name = 1; | ||
| string containerID = 2; | ||
| bool ready = 3; |
There was a problem hiding this comment.
are ready and started mutually exclusive? It might be better to use an enum for this.
There was a problem hiding this comment.
the slight difference is that started is for the startup probe and ready the readiness probe, so you could be in started:true, ready:false and later started:true, ready:true
There was a problem hiding this comment.
edit: removed the started for now as it's k8s > 1.16
| string namespace = 2; | ||
| int64 age = 3; | ||
| string IP = 4; | ||
| string nominatedNodeName = 5; |
There was a problem hiding this comment.
would it be better to use the node UUID? My understanding is that it's technically possible for node names to be re-used within an org if you have multiple kubernetes clusters, and that would make getting the node for a pod tricky.
There was a problem hiding this comment.
Good point, I don't think we have this info at the pod level though, with cluster-name + hostname we should be fine though 🤔 (although I'm not sure how we can enforce cluster-name to be unique between clusters)
proto/process/agent.proto
Outdated
| string nodeName = 6; | ||
| int32 restartCount = 7; | ||
| repeated ContainerStatus containerStatuses = 8; | ||
| repeated string labels = 9; |
There was a problem hiding this comment.
Are labels and tags the same thing or different? I currently see both in here.
There was a problem hiding this comment.
yes labels are the pod labels and tags are our internal tags stored in the tagger for this particular pod object some info will be duplicated with what we collect from pod already but some will not (ie kube_service)
There was a problem hiding this comment.
I see. Maybe put a comment on tag to mark it for internal use so people don't ask this question again.
mfpierre
force-pushed
the
mfpierre/collect-pods
branch
from
cdfeb40 to
2994d48
Compare
mfpierre
changed the title
No description provided.