We continue with the essay on comparison of Kubernetes with platform as a service framework. We compare one of the core functionalities from such frameworks to see the differences between what they offer. We study logging as applicable to container frameworks and PaaS.
Logging is a side-car model of deployment  in Kubernetes so that apps can focus on their logic while having the benefits of managed logging.
In this model, a fluentd configuration is used to pool in the logging from different log files produced by the application. The logging format and print specifiers can be directly added to the fluentd configuration along each source These configurations are essentially collections for individual log sources. The logging thus collected is then merged to a persistent volume source. This is accessible for read only operations without affecting individual sources. The separation of read only logs from their publication from log sources helps in the formation of a reporting stack downstream which can create beautiful charts and graphs.
These log files can also be indexed into an external log analysis product to help with querying based on shell like commands.
The separation of indexing and reporting concerns into downstream products alleviates the maintenance logic for containers and applications while allowing their stacks to vary as per customer convenience.

Logging as  described above is therefore much more gradual and methodical than adding a log analysis product and hardwiring the data sources in the PaaS framework. Their the logging was specified by syslog drain and the timestamp in individual entries were that of the host. This had been limiting to the application since they had to specify additional logging information per entry. The logging improved significantly with separation of concerns and worked across load balancing and auto-scaling. Liveness and readiness probe could also be added to the deployments and the use of Elasticsearch-Fluentd-Kibana significantly improve monitoring.