Add Fluentd

[matthewadams]

Issue Type
FEATURE REQUEST

Description
Adding an optional Fluentd chart makes it easy to achieve a complete initial logging solution. The current chart only configures half of the solution.

Version of Helm and Kubernetes:

$ helm version
Client: &version.Version{SemVer:"v2.8.0", GitCommit:"14af25f1de6832228539259b821949d20069a222", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.8.0", GitCommit:"14af25f1de6832228539259b821949d20069a222", GitTreeState:"clean"}

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.3", GitCommit:"d2835416544f298c919e2ead3be3d0864b52323b", GitTreeState:"clean", BuildDate:"2018-02-09T21:51:54Z", GoVersion:"go1.9.4", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"9+", GitVersion:"v1.9.2-gke.1", GitCommit:"4ce7af72d8d343ea2f7680348852db641ff573af", GitTreeState:"clean", BuildDate:"2018-01-31T22:30:55Z", GoVersion:"go1.9.2b4", Compiler:"gc", Platform:"linux/amd64"}

What happened:
I installed the chart & none of my containers were ingesting logs to ElasticSearch.

What you expected to happen:
I expected my containers' logs to appear in ElasticSearch.

How to reproduce it:

1. Install the chart.
2. Deploy a container that produces logs to stdout and/or stderr.
3. Open Kibana, use * as the index and elect not to use timestamping.
4. Fail to see any logs from the deployed container.

Anything else we need to know:
My PR, based on https://github.com/fluent/fluentd-kubernetes-daemonset/blob/master/fluentd-daemonset-elasticsearch.yaml, makes the user opt-in in order to remain backward compatible with the current behavior.

[sagikazarmark]

Thanks for this issue, but to be honest I don't think it's a good idea to bundle fluentd with this chart:

1. Elasticsearch can be used for a number of other things, adding fluentd would move things towards logging
2. I think it's enough to maintain Elasticsearch in this chart, adding fluentd complicates things
3. There is already an official fluent-bit chart, which is recommended for using on Kubernetes. It has a lower memory footprint (since it's written in C++, not ruby) and has a special plugin for k8s collecting information about pods.
4. As I said in a few other issues, running Elasticsearch on k8s is not like next, next, finish. If you are not cautious you can easily make your elastic or the whole k8s crash. By default k8s itself ingests a huge amount of logs. So the log collector requires a lot of fine tuning to work properly and adding it here would make that harder and would make people care less about it.

[matthewadams]

Fair enough. Obvi, I didn't know about fluent-bit, so I'll look into that.

One of the things I did in the PR was to make external exposure of things optional. Perhaps that's worth taking. Up to you.

Thanks for looking.

[sagikazarmark]

Personally I had enough issues with ELK on k8s to know that it's not particularly easy to maintain and there are no two exactly identical setups.

Because of that and the other arguments above I'm against bundling Elastic and Fluent together, but let's wait for other opinions.

Thanks for contributing anyway!