Hacker News Reader

Comment by thockingoog | Hacker News Reader

I don;t think that is really what happened. :) As part of the runtime abstraction, kubernetes must necessarily decide how to handle stdout/stderr logs. Not having a decision for something at a given point in time is not exactly a bad thing.

View on HN

Thanks, this seemed to be quite unusual decision to be made by the Kubernetes dev community, that's why I've asked.

Hi, I'm from sig-node. We just don't have enough time/people to cover all log management in 1.6, this is just a temp workaronud so we can ship CRI in time. Log mgmt, together with some other missing parts will be definitely picked up after CRI fully released.

I recommend that you learn from the world around you. This is a long since addressed problem. This is the way that the daemontools world has been addressing logging since the middle 1990s, and there is a lot of design and implementation experience to draw upon and learn from.

The ideas of decoupling logs from lifetimes of the the things being logged, desynchronized log-watcher services that ship logs to central off-machine log stores, logging chains, shims for things that talk to syslog over AF_LOCAL or UDP sockets, shims for things that talk to the systemd journal using its idiosyncratic logging protocol, compartmentalized logging services that are protected by the operating system from compromises to the logged services, and persistent log pipes that do not lose log data; have all been designed and implemented.

* http://jdebp.eu./FGA/daemontools-family.html#Logging

* http://jdebp.eu./FGA/do-not-use-logrotate.html

* http://jdebp.eu./Softwares/nosh/guide/logging.html

* http://skarnet.org/software/s6/s6-log.html#diesyslogdiedie

* http://skarnet.org/software/s6/s6-log.html#loggingchain

* http://tinydns.org/#ContributedLogging

Reply on news.ycombinator.com