I don't think it's odd that it's getting upvotes, but centralized logging is already a feature (as an addon) of k8s. I have a helm chart that's a one-shot for setting up ELK and FluentD as a system service that aggregates all docker stdout logs and tags each stream with k8s metadata, so you can very easily slice/dice your logs even at scale. It includes a cronjob running es-curator so that logs older than some configurable threshold are automatically deleted.

e.g. output from my dev cluster:

      ~CK/elk/templates git:(master)  kc cluster-info 
    Kubernetes master is running at https://192.168.16.16:8443
    Elasticsearch is running at https://192.168.16.16:8443/api/v1/proxy/namespaces/kube-system/services/elasticsearch-logging
    Heapster is running at https://192.168.16.16:8443/api/v1/proxy/namespaces/kube-system/services/heapster
    KubeDNS is running at https://192.168.16.16:8443/api/v1/proxy/namespaces/kube-system/services/kube-dns
    monitoring-grafana is running at https://192.168.16.16:8443/api/v1/proxy/namespaces/kube-system/services/monitoring-grafana

I think people want easy management of this, but I do wonder how successful this particular integration will be with such low-hanging self-managed alternatives. Where I think LogDNA will have a win is that you probably also have things running outside k8s that LogDNA helps integrate. So if you want all your k8s and non-k8s logs aggregated, and don't want to mess with it, then you might go with LogDNA.

Yes that's true for many things in Kubernetes but not as frequent in the logging space for Kubernetes. Many still rely on Fluentd as a parsing filter first to extract metadata like pod name or container name. And most of the logging ones require you to edit your yaml in some way first. Ours is almost copy-pasteable, provided you have a LogDNA API key. :)