Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2017 (Berlin), 6 Apr 2017

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: Flexible Logging Pipelines with Fluentd and Kubernetes - Jakob Karalus, codecentric

Description

Lightning Talk: Flexible Logging Pipelines with Fluentd and Kubernetes - Jakob Karalus, codecentric

Log forwarding from containers in kubernetes with fluentd works like a charm. But most applications require more than just forwarding, various applications require different parsing patterns, outputs, formats etc. Managing these in a large multi tenant cluster can be challenging and usually require an additional shared forwarding/parsing infrastructure. Otherwise manual configuration changes by a cluster operator are needed. Both ways can be problematic when many different teams share the same cluster.

In this Lighting Talk attendees will learn how to leverage the tools to automatically load specifications/grok patterns from kubernetes at runtime. This leads developers to define those on their own in their pod definition without the existence of a cluster operator or an extra infrastructure. Because of this new possibility the developer gains more flexibility in his application without the necessity to coordinate with cluster operators or other teams.

About Jakob Karalus
Jakob is a IT-Consultant at codecentric focussing on DevOps. His main interest is to play with exciting and evolving technologies around orchestration and automation. Currently he helps a large Enterprise as a cluster operator at running a multi tenant kubernetes cluster with supporting infrastructure like logging and monitoring.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.

A

Please welcome Jacob Carles of code centric.

A

So hey, my name is Jacob I'm for an IT consulting at concentric and I'm gonna talk about logging pipelines with Faludi and kubernetes, so the default way to do lock, forwarding in kubernetes, is to deploy flew in D as a daemon set. So it wants on every node since kubernetes rights locks to this fluid and and can pick up these blocks from the days you can use a filter plugin to in which some metadata like namespace and part etcetera and then Wow to one or a couple of endpoints. This is fine.

A

If you in a signal, cluster was one team, but if you have a cluster with multiple teams for it's something like 20 teams and everyone shares the global config affluent D. This can be quite a problem because you have a coordination problem and every team updates. One part of the config, the whole diamond set, has to be redeployed till 1.6. This was also really ugly. So, overall, if you have a shared cluster, this can be really get complicated quickly. So there are the common solutions for this.

A

The first solution is to port like an extra Flutie or lock stash and for another it. This makes logging or the coordination problem. Still there it's still there, but it makes a bit better, but then you have extra piece of infrastructure in front of it, which it's just extra event see. A second common solution is like let every team rolls their own solution, which is fine for the developers, because then they have a huge kind of flexibility.

A

They can do whatever the warmth, but on the downside, you waste a lot of resource and especially manpower, since everyone has to reinvent wheel on its own and certain solution which I'm like voting for today or presenting today is like let developers define the locking target and passing patterns, attributes and then dynamically generates lundi config from these attributes. So the attribute developers have like huge, huge flexibility yeah.

A

So how to do that? Basically, you first need to get developers to define the logging attributes like where the one to lock. If they want elasticsearch or something else and housing patterns in the inside, set employment or pot specification, then you need to create some kind of template at Flutey config.

A

Then you need to read the annotations from the API and generate the full. Config was a template and together and then we load the fluent in config, for example, on the right.

A

You can see an example pot spec, where you put like saloon T target where the output of these parts should be routed to, in this case, like an elastic search instance or something else, and then you create template if lundi config in this case I use : template language where you loop over a report, look for the targets, annotations filter, some informations out like container ID, and then just the TV Flutie config from out of that components, pretty straight straightforward, and then you need to just glue these two things together for that I use qkn, which is basically a go long tool which watches the AP api of server.

A

Look for changes if changes triggers the rendering process of the template and then triggers in this case here a TD agent. We load, which is sea treasure a treasure, data distribution or fluent II, and that's we loads of unity config. So in final, the output of a few years looks like then, and you can see at the bottom. The elasticsearch staff has been pro tenza, so that's basically it you can find it all on Qatar, because it's a little bit faster to all saying I hope.

A

Somebody learns because I think it's really useful pattern for developers and operators, because it lets developers define their logging, constructs its deployment definitions and they can make use of the whole loon the ecosystem and not just like statically about everything to elasticsearch or something and the operators are scared more free time, because you don't have to change the config for every team which wants to do another passing point or something.

A

You can also do this with speeds, and basically is that.