-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Preserve runtime from container statuses in Kubernetes autodiscover #6456
Preserve runtime from container statuses in Kubernetes autodiscover #6456
Conversation
Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually? |
9c907ac
to
1a5a4a9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@vjsamuel Do you have a mix of runtimes deployed?
jenkins, test it |
@ruflin we do not but it is definitely possible to have it in a Kube cluster. (I think) |
@vjsamuel Interesting, was not aware that in one cluster you can mix the two. |
A single node can have only one runtime but there can be carved out nodes that do docker and some that do rkt if im not mistaken. |
// that there is not an attempt to spin up a docker input for a rkt container and when a | ||
// rkt input exists it would be natively supported. | ||
if runtime, ok := container["runtime"]; ok { | ||
e[runtime.(string)] = common.MapStr{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've second thoughts about our current field names. I think we should rename docker.container.*
to container.*
for 7.0. container.runtime
will give you docker
, rkt
or any other.
For the time being, I'm ok with this I think, as removing the docker
prefix would be a breaking change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about this @vjsamuel? I'm thinking we could apply the change for autodiscover already, somehow duplicating docker.container
== container
.
Then in 7.0 we update metadata processor to use the new fields
@@ -111,19 +111,22 @@ func (p *Provider) emitEvents(pod *kubernetes.Pod, flag string, containers []kub | |||
containerstatuses []kubernetes.PodContainerStatus) { | |||
host := pod.Status.PodIP | |||
|
|||
// Collect all container IDs | |||
// Collect all container IDs and runtimes from status information. Kubernetes has both docker and rkt |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
minor thing here, but it could be others at some point (apart from docker and rkt)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should i update this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if you want :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
75a0608
to
f3fdb8f
Compare
f3fdb8f
to
fff50d8
Compare
jenkins, test this please |
Thanks for the changes @vjsamuel 🎉 |
The initial implementation assumed always that containers come from docker. There are kube clusters that run
rkt
as the container runtime. Atleast we would not spin up docker prospectors/inputs by default when Beats is run in them and based onrkt
behavior we can atleast manually set a config template on thelogs
builder config.