【.com快译】如果你正在使用Kubernetes并且需要日志，你可能会面临一些不同于虚拟机或裸机环境的问题和挑战。在过去的三个月里，我一直在研究PKS的可观察属性。***，我专注于Kubernetes日志系统。收集日志并将它们发送到日志服务器。这似乎是一项简单而普通的工作，不是吗？也许有时是这样。但是，与虚拟机或裸机环境相比，我注意到在使用容器时存在一些新的日志记录挑战。以下是摘要。查出！看看你的Kubernetes项目是否有同样的问题。这篇文章的动机更多是为了解释问题和技术难点。不是关于如何修复它们。如果这里有什么不对的地方，我会根据需要进行一些更改。通常，日志传输有主动和被动工作流。主动模式：进程主动将日志消息发送到远程系统日志服务器。通常，数据编码格式为rfc5424。被动模式：为每个进程指定其默认的日志路径或文件模式。日志代理系统会定期扫描它们并将捕获的日志消息发送到日志服务器。你可能认为问题已经解决了！还没有，我的朋友们。在容器中运行服务不同于运行虚拟机或裸机。因为我们将面临的新趋势是：这个过程会更加短暂。流程部署将更加分散。这对容器日志记录意味着什么？挑战一：无法收集所有关键日志当出现问题时，Pod（容器的集合）可能会被删除或快速重新创建。因此，与pod/容器关联的日志文件将被快速删除或重新创建。然而，像Fluentd或logstash这样的日志代理通常通过定期扫描文件夹或日志模式来检测新的日志文件。默认扫描间隔可能是60秒（见下图）。扫描间隔可能太长，无法捕获短期容器日志。那么如果我们将时间间隔设置的更短一些，比如1秒呢？显然这会带来更高的性能开销。这在虚拟机的旧世界中不会是一个问题。当进程以某种方式重新启动时，日志文件可能会轮换而不是删除。此时，用户可能只是接收日志的速度变慢了。但问题进程的关键日志不会丢失。我们如何解决这个问题？目前还没有所谓的最佳实践，我们还在探索中。也许我们可以启动一个订阅pod事件的Kubernetes控制器。每当触发pod创建事件时，都会立即通知日志记录代理。honeycomb-kubernetes-agent是一个有趣的GitHub项目，它实现了这个想法。如果您有更好的解决方案，请发表评论。但是，并非所有日志都重定向到stdout/stderr。如果pod中的进程将日志写入本地文件而不是stdout/stderr，则日志代理系统无法获取这些日志。为什么？日志代理系统只会监控pod相关的日志文件，如下所示。此日志文件将仅捕获容器的标准输出/标准错误。#ls-1/var/lib/docker/containers/*/*-json.logls-1/var/lib/docker/containers/*/*-json.log/var/lib/docker/containers/0470.../0470...-json.log/var/lib/docker/containers/0645.../0645...-json.log/var/lib/docker/containers/12d2.../12d2...-json.log...是的，这种日志记录行为确实是Kubernetes世界中的一种反模式。不过，云原生运动的发展还需要时间，并不是所有人都能跟得上潮流。对于数据库服务尤其如此。与虚拟机世界相比，Pod可能经常在不同的工作节点之间移动。您肯定不希望每次K8s集群中的pod更改时都需要重新加载或重新启动日志记录代理。这是新的挑战，对吧？挑战二：日志命名空间下的多租户Kubernetes工作负载通常会在共享工作虚拟机中运行。来自不同项目的工作负载被划分到不同的命名空间中。不同的项目可能对日志记录有不同的偏好。日志到哪里去，用什么工具管理等等，都需要提供简单的配置方法，不增加额外的安全隐患。事实证明，KubernetesCRD（CustomResourceDefinition）在这方面是一个非常好的工具。您需要学习的只是标准的kubectl命令。（参见kubectl备忘录）。这里可以使用RBAC来进行资源定制。安全性也能得到保证。在PKS中，我们称这个特性为资源汇。注：此想法已提交至Kubernetes社区。希望它将很快合并到Kubernetes上游。挑战三：为不同的命名空间支持不同的日志SLA为了方便，人们通常只需要部署一个日志代理作为Kubernetesdaemonset。这意味着每个Kubernetes工作节点只有一个pod。如果由于某种原因需要重新加载或重新调度此pod，它将影响此工作节点中的所有pod。从K8sv1.12开始，每个节点可以运行100个pod。因此，您需要确保您的日志记录代理足够快以从所有pod收集日志。与任何共享环境一样，您可能会遇到吵闹的邻居问题。一个pod的不当行为可能会危及同一工作节点中的所有其他pod。想要为有问题的命名空间禁用日志记录？虽然您可以轻松关闭整个日志记录系统，但您将无法继续收集所需的日志。此外，慢速磁盘可能会给日志传输带来严重的延迟。不及时处理日志反压可能导致日志代理DDoS攻击。挑战四：处理不同层级的日志记录如下图，我们有pod日志，k8s日志，平台日志。即使对于“pod日志”，我们也有来自标准工作负载或K8s附加组件的日志。您可能会猜到，不同类型的日志具有不同的特征，以及不同的优先级。不仅在层之间，有时在同一层内也有不同的SLA。为了提供一个K8s的解决方案，我们该如何解决这个问题呢？您需要最大限度地降低安全风险，同时协助项目经理和开发人员快速找到问题的根源。什么是PKS？PKS是VMware和Pivotal的企业级Kubernetes解决方案。原文地址：Kubernetes日志传输的4个挑战，作者：DennyZhang
