我目前配置了 deamon docker 的logging_driver来写入journald，以便使用kubernetes pod中的Fluentd来解析它们。在节点端，我有一个使用以下默认配置运行的 rsyslog：
# Default rules for rsyslog.
#
# For more information see rsyslog.conf(5) and /etc/rsyslog.conf
#
# First some standard log files. Log by facility.
#
auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
#cron.* /var/log/cron.log
#daemon.* -/var/log/daemon.log
kern.* -/var/log/kern.log
#lpr.* -/var/log/lpr.log
mail.* -/var/log/mail.log
#user.* -/var/log/user.log
#
# Logging for the mail system. Split it up so that
# it is easy to write scripts to parse these files.
#
#mail.info -/var/log/mail.info
#mail.warn -/var/log/mail.warn
mail.err /var/log/mail.err
#
# Logging …我目前在管道中使用Docker Swarm模式,我使用大量docker stack deploy -c compose-file.yml name-of-the-stack的命令来更新堆栈与最新的docker镜像.它完全有效,除非我不从yaml文件中删除服务.在这种情况下,stack deploy命令应该在更新另一个的映像之上删除不再存在的服务,但行为是它使容器保持运行并且这不是预期的行为.由于这个结果我有改变了它docker stack rm name-of-the-service,然后docker stack deploy -c compose-file.yml name-of-stack.但这有另一个可怕的副作用,随机影响容器:命令docker stack rm name-of-the-stack经常使nginx容器代理的可靠性完全不可靠(似乎与此问题相关https://github.com/docker/docker/issues/24244).事实上,nginx容器(在另一个堆栈中,但在相同的覆盖网络中),负责处理容器之间的所有请求,并使用Docker Swarm模式的路由网格功能在它们之间进行代理传递.重新创建部署的堆栈,无法代理请求,就好像它试图将流量转发到没有更多的现有容器,这使得集成和行为测试失败.是否有一种方法可以在不使用docker stack rm的情况下进行一致的部署(到目前为止看起来非常错误)但是应用了yml compose文件的最新状态？