Logging as a side car model:
There are various levels and areas of emphasis in the stack to support rich analytics over logging. At the Kubernetes system level, among the popular options, we could prioritize fluentD logging sidecar as a way to collect logs from across the pods. This will be beneficial to the applications as it alleviates the concerns from them and at the same time provides a consistent model across the applications. At the store level, we recommend that the logs have their own storage whether it is the file storage or an index store. This will allow uniform aging, archiving and rolling of logs based on timeline and will work across all origins
At the analytics level, we can outsource the reporting stack, charts, graphs and dashboards to the application that is best to analyze machine data. Although StorageApplication, SmartAnalytics, metrics, charts and graphs can be used to store, search and render results, it will take a longer round-trip time between the user query and the results.

There is usually only one sidecar  per service in a sidecar proxy deployment. A sidecar can be in the same pod as the one hosting the service. The number of instances of sidecars can scale as appropriate. A smaller resource profile is necessary for allowing the explosion of sidecar instances.  If the target of a sidecar is available as a daemonset, there will only be one sidecar per host rather than one sidecar per pod.
#codingexercise
Task getNext(List<Task> tasks) {
For (Task task :tasks) {
If (task.Completed == false) {
Return task;
}
}
Return null;
}