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.
e.g. output from my dev cluster:
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.