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.