Re-design how Fluentd should be deployed as a Daemonset

[edsiper]

Current structure of this suggested way to deploy Fluentd as a daemonset is generating some complications to maintain different based distro, plugins and different setups.

Taking in count @chancez suggestions, I think this could work as:

• One debian base image:
  • Deprecate Alpine because of: cannot work with systemd, hard to maintain with Jemalloc enabled (required to reduce memory usage because of high glibc memory fragmentation).
  • Debian image by Google (gcr.io/google-containers/debian-base-amd64:0.1) is really secure,
• Use ConfigMaps instead of configuration files inside the images
• Similar documentation to the one existing by CoreOS/Tectonic: Logging

Please share your thoughts and ideas.

[chancez]

One of the biggest pain points is plugins. I'd like to experiment with a few ideas, when I find some more time, but I'll put them here so others can feel free to try it if they like:

1. Create a base image with most plugins people might need, not including most outputs (install fluent-plugin-rewrite-tag-filter, fluent-plugin-prometheus, fluent-plugin-kubernetes_metadata_filter, fluent-plugin-rewrite-tag-filter, the forwarder plugins, maybe a few more).
2. Creating an image based on the base image with most output plugins pre-installed. This image will be necessarily larger, but it will be an "all-in-one" for most people.
3. Creating an image based on the base image which can dynamically install plugin gems based on a list of gems in an environment variable, at startup.

I'm not a huge fan of option 3, but I am curious to see how well it works in practice since the pods only need to install the gems the first time they're started, restarts wouldn't need to re-download the gem, only if the pod is re-created does it need to re-download, so this may work for some use cases.

By building a base image containing everything except output plugins specific to usage with Kubernetes, it's really easy to extend the image with your own modifications, for your specific logging destination, and if you don't care about the size as much, the all-in-one image would have most output plugins people need already installed.