Kubernetes: 在RC和Pod中指定pod时定义log-driver和log-opt

/cc@kubernetes/rh-cluster-infra

嗯，我想我们可能希望能够在整个集群范围内将这个设置为默认值，然后可能允许覆盖特定的 pod 定义。

抄送@sosiouxme @smarterclayton @liggitt @jwhonce @jcantrill @bparees @jwforres

您能描述一下您将如何在每个容器的基础上（用例）利用它吗？ 我们传统上不会直接在容器中公开 Docker 特定的选项，除非它们可以跨运行时被干净地抽象出来。 知道您想如何使用它将有助于证明它的合理性。

请注意，docker logs 仍然仅支持 json-file 和 journald 驱动程序，尽管我认为该列表可以扩展。

也许用户真正想要的是选择定义的日志写入端点，而不是公开日志驱动程序的详细信息。

@ncdc @smarterclayton我同意你们两个的看法，在重新考虑我们内部的用例后，结果证明

1. 我们的主要需求是保护我们的节点。 我们将日志发送到日志服务器，但如果失败，日志回退到 docker 内部日志。 在这种情况下，为了防止节点饱和，我们需要一个集群范围的 docker 日志行为
2. 正如@smarterclayton建议的那样，在 pod/Rc 定义中公开特定的 docker 选项并不是一个好主意。 如果可能，我们也同意允许定义高级日志行为的抽象
3. 另一种选择是对 kubelet 配置文件和代码进行更改以处理此类日志行为

更改盐模板以使其成为默认值不应该
非常困难。 这真的只是适当的守护程序配置（和
通过 fluentd 处理日志聚合的任何更改
选择不同的来源）

2015 年 10 月 13 日，星期二，上午 10:55，E​​po Jemba通知@github.com
写道：

@ncdc https://github.com/ncdc @smarterclayton
https://github.com/smarterclayton我同意你们两个，之后
在内部重新考虑我们的用例，结果是

1. 我们的主要需求是保护我们的节点。 我们将日志发送到日志
   服务器，但如果失败，则在 docker 内部日志上记录回退。 在这样的
   在这种情况下，为了防止节点饱和，我们需要一个集群范围的行为
   码头工人日志
2. 在 pod/Rc 定义中公开特定的 docker 选项不是
   好主意@smarterclayton https://github.com/smarterclayton
   建议它。 我们也同意允许定义高的抽象
   如果可能，级别日志行为
3. 另一种选择是更改 kubelet 配置文件和
   处理此类日志行为的代码

—
直接回复此邮件或在 GitHub 上查看
https://github.com/kubernetes/kubernetes/issues/15478#issuecomment -147740136
.

：竖起大拇指：

请注意，现在有9 个日志驱动程序。 把这个放进去的共识是什么？

+1

如果有人不知道，您可以在每个节点的基础上定义默认日志驱动程序，并为 Docker 守护程序 ( --log-driver ) 设置一个标志。 在我的环境中，我以这种方式将驱动程序设置为journald 。 老实说，我很难想到在每个容器的基础上覆盖它的用例。

大多数集群不希望他们的日志“带外”，那么这将提供什么功能启用。

此外，从运营的角度来看，这似乎是一种失控。 目前我们设置了默认值并配置了一个日志堆栈来聚合。

+1 对此。
无法控制 docker 日志记录的处理方式意味着唯一合理的日志记录选项是使用 k8s 附带的工具，这是一个令人难以置信的限制。

@timothysc这里是我们的用例。 我们有一个复杂的动态基础设施（约 100 台机器），上面运行着许多现有的服务，我们有自己的logstash来收集日志。 好吧，我们现在正试图将我们的服务一个一个地转移到 k8s，对我来说似乎没有干净的方法来集成我们现有的基础设施和集群在 k8s 上的容器之间的日志记录。

K8S 对收集日志的方式非常固执。 对于从头开始使用简单基础架构的人来说，这可能非常有用。 对于那些不介意深入研究并实现自定义日志记录机制的复杂基础设施工作的其他人来说，目前根本没有办法做到这一点，这非常令人沮丧。

希望这是有道理的。

因此，在您的场景中，日志确实是“每个应用程序”，但您必须
确保底层主机支持这些日志？ 这就是我们所关心的
在这里讨论 - 我们要么做集群级，要么做节点级，但如果我们做
pod 级别，那么调度程序必须知道哪些日志驱动程序
存在于何处。 我们尽可能地避免这种情况。

2016 年 5 月 23 日星期一上午 10:50，Jacopo Nardiello < [email protected]

写道：

+1 对此。
无法控制 docker 日志记录的处理方式意味着
唯一明智的日志记录选项是使用 k8s 附带的工具，这是一个
难以置信的限制。

@timothysc https://github.com/timothysc这里是我们的用例。 我们有一个
复杂的动态基础设施（约 100 台机器），有很多现有的
在它们上面运行的服务，使用我们自己的日志存储来收集日志。 嗯，我们
现在正试图将我们的服务一项一项地转移到 k8s 和我那里
似乎不是在我们现有的日志之间集成日志的干净方法
基础设施和容器集群在 k8s 上。

K8S 对收集日志的方式非常固执。 这可能很棒
对于任何从头开始使用简单基础架构的人。 为了
其他人在复杂的基础设施上工作，他们不介意
深入研究并实现自定义日志记录机制，根本没有
目前这样做的方式，这很令人沮丧。

希望这是有道理的。

—
你收到这个是因为你被提到了。
直接回复此邮件或在 GitHub 上查看
https://github.com/kubernetes/kubernetes/issues/15478#issuecomment -221002545

@smarterclayton我确实了解您的担忧，而且他们处于

这只是我的两分钱，但我们不能假设现实世界的复杂场景只是放弃了他们现有的日志记录基础设施。

您是否为每个应用程序指定自定义日志选项？ 有多少不同
每个集群有几组日志选项？ 如果有小集
config，一个选项是支持 pod 上的注释
与提供许多“标准日志”的节点级配置相关
options”。即在 kubelet 启动时定义一个“日志模式 X”（它定义了
自定义日志选项和驱动程序），并且 pod 将指定“
pod.alpha.kubernetes.io/log.mode=X”。

另一种选择是我们公开一种方法，让部署者拥有
在我们开始之前立即改变容器定义的机会
容器。 今天这更难，因为我们必须序列化
docker def out 为中间格式，执行，然后运行
再次，但将来可能会更容易。

最后，我们可以在容器接口上公开键值对
直接传递给容器引擎，不提供 API 保证
它们，并确保 PodSecurityPolicy 可以调节这些选项。 那会
成为呼叫者的逃生舱口，但我们将无法提供任何
保证这些将继续跨版本工作。

2016 年 5 月 26 日星期四上午 5:34，Jacopo Nardiello通知@github.com
写道：

@smarterclayton https://github.com/smarterclayton我确实了解
您的顾虑，他们都很好。 我不确定整个集群是否
必须意识到 pod 级日志记录的存在，我认为我们
应该做的是提供在某处记录 pod stdout/stderr 的选项（一个文件
基于他们当前的 pod 名称？）这样任何人都愿意实施他们的
自定义解决方案，将有一个持久的地方来获取内容。
尽管对数旋转并非微不足道，但这开启了一个巨大的篇章。

这只是我的两分钱，但我们不能假装现实世界的复杂性
场景只是放弃他们现有的日志记录基础设施。

—
你收到这个是因为你被提到了。
直接回复此邮件或在 GitHub 上查看
https://github.com/kubernetes/kubernetes/issues/15478#issuecomment -221823732

@smarterclayton你见过https://github.com/kubernetes/kubernetes/issues/24677#issuecomment -220735829

不，谢谢。 在那里移动讨论。

2016 年 5 月 26 日星期四上午 11:23，Andy Goldstein通知@github.com
写道：

@smarterclayton https://github.com/smarterclayton你看到了吗#24677
（评论）
https://github.com/kubernetes/kubernetes/issues/24677#issuecomment -220735829

—
你收到这个是因为你被提到了。
直接回复此邮件或在 GitHub 上查看
https://github.com/kubernetes/kubernetes/issues/15478#issuecomment -221903781

你好呀，
我认为这是 kubernetes 应该考虑的一个重要特性。
启用使用 Docker 的日志驱动程序可以解决一些非平凡的问题。

我会说记录到磁盘是一种反模式。 日志本质上是“状态”，最好不要保存到磁盘。 将日志直接从容器传送到存储库解决了许多问题。

设置日志驱动程序意味着 kubectl logs 命令无法再显示任何内容。
虽然该功能“很不错” - 当日志可从不同来源获得时，将不需要该功能。

Docker 已经为谷歌云 (gcplogs) 和亚马逊 (awslogs) 提供了日志驱动程序。 虽然可以在 Docker 守护程序本身上设置它们，但这有很多缺点。 通过能够设置两个泊坞窗选项：

--log-driver= 容器的日志驱动
--log-opt=[] 日志驱动程序选项

可以发送标签（对于 gcplogs）或 awslogs-group（对于 awslogs）
特定于 pod。 这样可以很容易地找到另一端的日志。

我一直在阅读人们如何处理 kubernetes 中的日志。 许多人似乎设置了一些精心制作的抓取器，将日志转发到中央系统。 能够设置日志驱动程序将使不必要的 - 腾出时间来处理更有趣的事情:)

我还可以补充一点，包括我在内的一些人希望通过 JSON 日志驱动程序（docker 原生）上的“--log-opt max-size”选项执行 docker 日志轮换，而不是在主机上设置 logrotate。 因此，即使只公开 '--log-opt' 选项也将不胜感激

我在创建容器配置LogConfig时修改了k8s。

+1
使用 docker 日志驱动程序进行集中日志收集看起来比为日志文件创建符号链接、将它们安装到特殊的 fluentd 容器、拖尾和管理日志轮换要简单得多。

每个容器配置的用例：我想在别处或以不同方式记录我部署的容器，我不关心（或想更改）运行 Kubernetes 所需的标准容器的日志驱动程序。

你去吧。 请让这件事发生。

另一个想法是，所有容器仍然将日志转发到同一个端点，但您至少可以为日志服务器上的

如果我们可以确保 Kubernetes 创建的 docker 容器是自定义标记的，这将适用于 gelf docker 驱动程序。 含义：某些 Pod 字段可以作为 docker 容器标签转发。 （也许这已经是可能的，但我不知道如何实现）。

没有 Kubernetes 的示例，只有 docker 守护进程和 gelf 驱动程序。 将 docker 守护进程配置为： --log-driver=gelf --log-opt labels=env,label2并创建一个 docker 容器：

docker run -dti --label env=testing --label label2=some_value alpine:3.4 /bin/sh -c "while true; do date; sleep 2; done"

和另一个码头集装箱：

docker run -dti --label env=production --label label2=some_value alpine:3.4 /bin/sh -c "while true; do date; sleep 2; done"

这样，在 Graylog 上，您可以区分env=production和env=testing容器。

目前我使用这样的 docker 守护进程选项：

--log-driver=gelf --log-opt gelf-address=udp://graylog.example.com:12201 --log-opt tag=k8s-testing --log-opt labels=io.kubernetes.pod.namespace,io.kubernetes.container.name,io.kubernetes.pod.name

@xmik ，只是确认它是现有功能或您的建议

目前我使用这样的 docker 守护进程选项：

--log-driver=gelf --log-opt gelf-address=udp://graylog.example.com:12201 --log-opt tag=k8s-testing --log-opt labels=io.kubernetes.pod.namespace,io.kubernetes.container.name,io.kubernetes.pod.name

我目前使用的那些 docker daemon 选项已经可以使用了。 Kubernetes 已经为每个 docker 容器设置了一些标签。 例如，在 kube-apiserver 容器上运行docker inspect时：

 "Labels": {
   "io.kubernetes.container.hash": "4959a3f5",
   "io.kubernetes.container.name": "kube-apiserver",
   "io.kubernetes.container.ports": "[{\"name\":\"https\",\"hostPort\":6443,\"containerPort\":6443,\"protocol\":\"TCP\"},{\"name\":\"local\",\"hostPort\":8080,\"containerPort\":8080,\"protocol\":\"TCP\"}]",
   "io.kubernetes.container.restartCount": "1",
   "io.kubernetes.container.terminationMessagePath": "/dev/termination-log",
   "io.kubernetes.pod.name": "kube-apiserver-k8s-production-master-1",
   "io.kubernetes.pod.namespace": "kube-system",
   "io.kubernetes.pod.terminationGracePeriod": "30",
   "io.kubernetes.pod.uid": "a47396d9dae12c81350569f56aea562e"
}

因此，那些 docker 守护进程选项有效。

但是，我认为现在不可能根据 Pod 规范让 Kubernetes 在 docker 容器上设置自定义标签。 所以例如--log-driver=gelf --log-opt labels=env,label2不起作用。

有这方面的消息吗？ 能够指定标签然后利用--log-opt labels<>会非常好！

@portante @jcantrill只是为了在此处捕获它，因为我们讨论了它，这是我们认为这可能对以下用途有用的用例：

当日志记录 pod 开始遇到并记录错误时，收集这些错误的基础设施将抓取它们并将它们反馈给记录机制，后者又会抛出并记录更多错误。

这种反馈回路可以通过使用过滤机制来避免，但这有点脆弱。 使用不同的日志驱动程序记录到文件并具有旋转选项似乎是一个很好的解决方案。

我的 2 美分。

当前在 k8s 中登录的解决方案是（AFAIK）：

• Sidecar 容器在某处发送日志
• 复制控制器将所有日志发送到某处
• 容器本身在某处发送日志

Sidecar 容器对我来说似乎有点矫枉过正。 复制控制器策略看起来不错，但它混合了来自所有部署的容器日志，一些用户现在可能想要这样，并且可能想要将每个应用程序记录到不同的东西。 对于这种情况，最后一个选项最有效，恕我直言，但会创建大量在所有容器中复制的代码（例如：安装和设置 logentries 守护进程）。

如果我们可以访问log-driver标志，这一切都会变得更容易，因此每个部署都将使用 docker 本机功能定义应该如何记录它。

我可以尝试实现它，但可能需要一些帮助 - 因为我对 kubernetes 代码库不熟悉。

一旦多租户变得越来越重要，就很难正确解决。

每个命名空间可能是不同的租户，因此每个命名空间的日志不一定要聚合，但允许发送到租户指定的位置。

我可以想到几种方法来做到这一点：

1. 创建一个新的卷类型，容器日志。 这允许由特定命名空间启动的守护程序集仅访问其自己容器中的日志。 然后，他们可以将带有选择的任何日志传送器的日志发送到选择的任何存储守护程序。
2. 修改一个（或多个）日志传送器，例如 fluentd-bit 以读取 Pod 所在的命名空间，并将日志从每个 Pod 重定向到作为服务在该命名空间中运行的另一个日志传送器。 如流利。 这再次允许命名空间配置自己的日志传送器以推送到他们想要支持的任何日志后端。

@caarlos0 @kfox1111我同意你的观点。 这是一个复杂的话题，因为它需要工具、存储、节点甚至更多团队的协调。 我建议首先制定一个整体日志架构的建议，然后讨论对这种一致视图的更改。 我希望这个提案在一个月左右的时间里出现，带来秩序并解决提到的所有问题。

@crassirostris我不确定我是否理解：如果我们只允许log-driver等，我们就不必处​​理存储或任何其他问题，对吗？

只是 docker 将其 STDOUT 发送到在容器基础上设置的任何日志驱动程序，对吗？ 我们有点将责任传递给容器......对我来说似乎是一个非常简单的解决方案 - 但是，正如我所说，我不知道代码库，所以也许我完全错了......

问题是 docker 中的日志驱动程序没有添加任何 k8s 元数据，这使得稍后使用日志实际上很有用。 ：/

@kfox1111嗯，有道理...

但是，如果用户只想要“应用程序”日志，而不是 kubernetes 日志，不是 docker 日志，而只是在容器日志中运行的应用程序，该怎么办？

在那种情况下，在我看来， log-driver会起作用......

@caarlos0它可能有一些含义，例如 kubelet 对服务器 kubectl 日志的日志记录格式做出了一些假设。

但除此之外， log-driver本身是特定于 Docker 的，可能不适用于其他运行时，这是不将其包含在 API 中的主要原因。

@crassirostris说得通...

由于不会添加此功能（如问题中所述），也许该问题应该关闭（或编辑或其他）？

@caarlos0但是，我们绝对想让日志设置更加灵活和透明。 您对提案的反馈将不胜感激！

来自容器的 stdout 日志记录目前在 Kubernetes 中进行带外处理。 我们目前依赖非 Kubernetes 解决方案来处理日志记录，或者使用特权容器来越狱 Kubernetes 以访问带外日志记录。 容器运行时日志记录在每个运行时（docker、rkt、Windows）都是不同的，所以选择任何一个，比如 Docker --log-driver 都会创造未来的包袱。

我建议我们需要 kubelet 将日志流带回带内。 定义或选择最小的 JSON 或 XML 日志格式，从每个容器收集 stdout 行，添加最小的集群+命名空间+pod+容器元数据，以便在 Kubernetes 空间内识别日志源，并将流定向到 Kubernetes Service+港口。 用户可以自由提供他们喜欢的任何日志消费服务。 也许 Kubernetes 会提供一个参考/默认服务来实现“kubectl 日志”支持。

如果没有指定日志消费服务，日志将被丢弃并且根本不会命中磁盘。 将日志流式传输到其他地方，或写入持久存储并轮换，所有这些都是服务的责任/决定。

kubelet 容器运行时包装器尽可能地从每个容器运行时中提取标准输出，并将其带回带内供 k8s 自托管服务使用和处理。

Deployment 或 Pod 中的容器规范可以选择为标准输出日志指定目标服务和端口。 为 cluster+namespace+pod+container 添加 k8s 元数据是可选的（因此可以选择原始/未触及或带有元数据）。 用户可以自由地将所有日志聚合到一个地方，或者按租户、命名空间或应用程序聚合。

现在最接近的是运行一个服务，该服务使用“kubectl logs -f”通过 API 服务器为每个容器流式传输容器日志。 这听起来不是很有效或可扩展。 该提案将允许更有效地从容器运行时包装器直接传输到服务或 Pod，并进行优化，例如优先在同一节点上记录部署或 Daemonset Pod，以及生成日志的容器。

对于我们在 Kubernetes 空间中创建的任何自托管、同构或异构日志记录解决方案，我建议 Kubernetes 应尽最大努力有效地将容器运行时日志带入带内。

人们怎么看？

@whereisaaron我真的不想现在就讨论这个问题，因为我们没有在一个地方拥有关于日志生态系统的所有细节。

例如，我看到网络和机器问题中断了日志流，但同样，我还不想讨论它。 等提案准备好后，我们再讨论这个怎么样？ 你觉得合理吗？

当然@crassirostris。 当提案准备好检查时，请在此处通知我们。

/ sig 可扩展性

尽管--log-driver和--log-opt都是 Docker 守护进程的选项，而不是k8s 功能的选项，但最好在 k8s pod 规范中指定它们：

1. per-pod 日志驱动程序，而不是单个节点级日志驱动程序
2. 同一节点上不同类型的特定于应用程序的日志驱动程序（fluentd、syslog、journald、splunk）
3. 设置--log-opt为 pod 配置日志轮换
4. 每个 pod --log-opt设置而不是单个节点级--log-opt

AFAIK，今天的 k8s pod 规范中不能在 pod 级别设置上述任何一项。

@vhosakot以上都不能在 Kubernetes 中的任何级别设置，因为那些不是 Kubernetes 概念

@crassirostris完全正确！ :)

如果 k8s 在 pod 级/容器级做 Docker 所做的一切，对用户来说是不是很容易？ 为什么要让用户完全使用 Docker 来处理一些 pod 级/容器级的东西？

而且，一个 k8s 爱好者而不是 Docker 粉丝可能会问同样的问题。

@vhosakot 要点是，还有许多其他容器运行时可以与 K8s 一起使用，但--log-opt仅存在于 Docker 中。 在 K8s 级别创建这样的选项会故意泄露抽象。 我不认为这是我们想要走的路。 如果存在选项，则所有容器运行时都应支持它，最好是 CRI 的一部分

我不是说不会有这样的选择，我是说它不会是到 Docker 的直接途径

@crassirostris是的，听起来可以归结为 k8s 是否应该在 pod 级别/容器级别执行 CRI 所做的/允许的操作，而不是特定于 Docker 的。

是的，完全正确

尽管我迟到了这个讨论并且我有兴趣看到这个功能的实现，但我认为在拥有漂亮的设计和拥有建立健全和统一日志记录解决方案的直接方法之间存在权衡对于集群。 是的，实现这个功能会暴露 docker internal ，这是一个很大的不，但同时我可以打赌，大多数 K8S 用户使用 docker 作为底层容器技术，docker 确实提供了一个非常全面的列表日志驱动程序。

@gabriel-tincu 我目前不相信原来的 FR 值得麻烦

docker 确实附带了一个非常全面的日志驱动程序列表

您可以在 K8s 部署步骤期间在 Docker 级别设置日志记录并使用这些日志驱动程序中的任何一个，而不会将此信息泄露给 K8s。 您今天唯一不能做的就是为每个容器/每个 Pod 设置这些选项（实际上，您可以使用专用节点进行设置并使用节点选择器），但我不确定这是一个很大的限制。

@crassirostris我同意你可以在 __before__ 设置环境之前设置它，但是如果有一种方法可以在环境已经设置后主动更新 docker 日志驱动程序，那么它目前无法实现

@gabriel-tincu @vhosakot在 >=1.5 的“旧日”中曾经存在于 k8s 和 Docker 之间的直接接口已被弃用，我相信该代码现在已完全删除。 kubelet 和 Docker 等运行时（或其他类似 rkt、cri-o、runc、lxd）之间的所有内容都通过 CRI。 现在有很多容器运行时，Docker 本身很可能很快就会被弃用和删除，取而代之的是cri-containerd + containerd 。

http://blog.kubernetes.io/2017/11/containerd-container-runtime-options-kubernetes.html

@crassirostris关于提案的任何运动，可能有带内容器日志记录的可能性？

CRI 容器日志是基于文件的（https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/kubelet-cri-logging.md），并且明确定义了日志路径：

/var/log/pods/PodUID/ContainerName/RestartCount.log

在大多数 docker 日志驱动https://docs.docker.com/config/containers/logging/configure/#supported -logging-drivers 中，我认为对于集群环境，最重要的是将容器日志引入集群的驱动日志管理系统，如splunk 、 awslogs 、 gcplogs等。

在 CRI 的情况下，不应使用“docker log driver”。 人们可以运行守护进程将容器日志从 CRI 容器日志目录中提取到他们想要的任何地方。 他们可以使用 fluentd 甚至自己编写一个守护进程。

如果需要更多元数据，我们可以考虑删除元数据文件，扩展文件路径或让 daemonset 从 apiserver 获取元数据。 关于这个https://github.com/kubernetes/kubernetes/issues/58638正在进行讨论

问题在 90 天不活动后变得陈旧。
使用/remove-lifecycle stale将问题标记为新问题。
过时的问题在额外 30 天不活动后腐烂并最终关闭。

如果现在可以安全关闭此问题，请使用/close关闭。

向 sig-testing、kubernetes/test-infra 和/或fejta发送反馈。
/生命周期陈旧

陈旧的问题在 30 天不活动后腐烂。
使用/remove-lifecycle rotten将问题标记为新问题。
在额外的 30 天不活动后，烂问题就会关闭。

如果现在可以安全关闭此问题，请使用/close关闭。

向 sig-testing、kubernetes/test-infra 和/或fejta发送反馈。
/生命周期腐烂
/remove-lifecycle 陈旧

/remove-lifecycle 腐烂的

有任何更新吗？ 那么运行带有 Docker 容器的 k8s 的人是如何将日志记录到 AWS CloudWatch 等后端的呢？

@bryan831使用 fluentd 或类似工具收集 k8s 容器日志文件并将它们聚合到您选择的后端、CloudWatch、StackDriver、Elastisearch 等中是很受欢迎的。

有现成的 Helm 图表，例如fluentd+CloudWatch , fluentd+Elastisearch , fluent-bit->fluentd->your choice , Datadog和其他可能的组合，如果你

问题在 90 天不活动后变得陈旧。
使用/remove-lifecycle stale将问题标记为新问题。
过时的问题在额外 30 天不活动后腐烂并最终关闭。

如果现在可以安全关闭此问题，请使用/close关闭。

向 sig-testing、kubernetes/test-infra 和/或fejta发送反馈。
/生命周期陈旧

能够自定义 Docker --log-opt 选项会很好。 就我而言，我想使用诸如 '--log-opt tag="{{.ImageName}}/{{.Name}}/{{.ID}}"' 之类的标签将 ImageName 发送到日志这样我就知道日志来自哪个容器版本。 （参考：https://docs.docker.com/config/containers/logging/log_tags/）

/remove-lifecycle 陈旧

@pmahalwar-intertrust 您可以将相同的 --log-opt 传递给 docker 守护进程，这将影响您的所有容器...

@pmahalwar-intertrust kubernetes 从containerd收集的日志已经包含大量元数据，包括您应用于容器的任何标签。 如果您使用fluentd收集它，您将获得所有元数据，例如在下面的日志条目中。

{
    "log": " - [] - - [25/Oct/2018:06:29:48 +0000] \"GET /nginx_status/format/json HTTP/1.1\" 200 9250 \"-\" \"Go-http-client/1.1\" 118 0.000 [internal] - - - - 5eb73997a372badcb4e3d993ceb44cd9\n",
    "stream": "stdout",
    "docker": {
        "container_id": "3657e1d9a86e629d0dccefec0c3c7624eaf0c4a11f60f53c5045ec0839c37f06"
    },
    "kubernetes": {
        "container_name": "nginx-ingress-controller",
        "namespace_name": "ingress",
        "pod_name": "nginx-ingress-dev-controller-69c644f7f5-vs8vw",
        "pod_id": "53514ad6-d0f4-11e8-a04c-02c433fc5820",
        "labels": {
            "app": "nginx-ingress",
            "component": "controller",
            "pod-template-hash": "2572009391",
            "release": "nginx-ingress-dev"
        },
        "host": "ip-172-29-21-204.us-east-2.compute.internal",
        "master_url": "https://10.3.0.1:443/api",
        "namespace_id": "e262510b-180a-11e8-b763-0a0386e3402c"
    },
    "kubehost": "ip-172-29-21-204.us-east-2.compute.internal"
}

是否仍然没有计划支持这些功能？
--log-driver= 容器的日志驱动
--log-opt=[] 日志驱动程序选项

嗨@lifubang我不能谈论任何人的计划，但是支持这些功能的守护进程dockerd不再是 Kubernetes 的一部分（请参阅上面讨论的内容）。

如果您愿意，您仍然可以选择安装它，因此您可以这样做以使用旧的dockerd日志驱动程序。 该选项在此处讨论：
https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/

但是建议使用像fluentd这样的专用日志记录服务。 您可以将其作为 sidecar 部署到集群或每个 Pod 中。 此处讨论了 Kubernetes 中的登录：
https://kubernetes.io/docs/concepts/cluster-administration/logging/

我强烈推荐 @whereisaaron 所描述的fluentd

至于这个功能请求正在处理...... kubernetes 架构路线图在“生态系统”部分下记录了不是真正“一部分”kubernetes 的东西，所以我怀疑这样的功能是否会得到本机支持。
https://github.com/kubernetes/community/blob/master/contributors/devel/architectural-roadmap.md#summarytldr

我强烈建议不要使用 fluentd，因为它有几个错误，可以在运行 k8s 时让你的生活变得糟糕

in_tail 防止 docker 移除容器https://github.com/fluent/fluentd/issues/1680。

in_tail 在启动阶段删除未跟踪的文件位置。 这意味着 pos_file 的内容在重新启动之前一直在增长，并且当您使用动态路径设置跟踪大量文件时，可能会消耗大量 CPU 扫描。
https://github.com/fluent/fluentd/issues/1126。

问题在 90 天不活动后变得陈旧。
使用/remove-lifecycle stale将问题标记为新问题。
过时的问题在额外 30 天不活动后腐烂并最终关闭。

如果现在可以安全关闭此问题，请使用/close关闭。

向 sig-testing、kubernetes/test-infra 和/或fejta发送反馈。
/生命周期陈旧

感谢您的体验@roffe。 fluent/fluentd#1680 是关于 k8s 1.5 的一个问题，出于这个原因，当时我们没有使用 'in_tail'。 自从 k8s 转移到containerd日志记录它似乎仍然不是一件事？ 我们还没有看到 fluent/fluentd#1126 有任何可检测到的影响。

您建议反对fluentd 。 你会推荐什么？ 您个人使用什么来代替fluentd与 k8s 元数据进行日志聚合？

陈旧的问题在 30 天不活动后腐烂。
使用/remove-lifecycle rotten将问题标记为新问题。
在额外的 30 天不活动后，烂问题就会关闭。

如果现在可以安全关闭此问题，请使用/close关闭。

向 sig-testing、kubernetes/test-infra 和/或fejta发送反馈。
/生命周期腐烂

烂问题在 30 天不活动后关闭。
使用/reopen重新打开问题。
使用/remove-lifecycle rotten将问题标记为新问题。

向 sig-testing、kubernetes/test-infra 和/或fejta发送反馈。
/关闭

@fejta-bot：关闭此问题。

这不应该被关闭，是吗？
功能请求对我来说仍然有意义，因为我希望为每个 pod 设置 log-opts（不在守护进程上设置它或使用 logrotate）...

我相当肯定从 k8s 内部支持 docker 特定的配置选项不是一个好主意。 如前所述，目前可以选择 fluentd daemonset 或 fluentbit side car。 我更喜欢边车，因为它更安全。

@whereisaaron您是否找到了K8s@containerd的日志记录解决方案

仍然不支持 --log-driver 、 --log-opt 吗？
我正在尝试找到一种将日志从单个 pod 转发到 Splunk 的方法。 有任何想法吗？

@sariel1212对于单个 pod，我建议在您的 pod 中包含一个侧车容器，它只是 splunk 转发代理。 您可以在 pod 中的所有容器之间共享一个 emptydir 卷，并让应用程序容器将它们的日志写入共享的 emptydir。 然后让 splunk 转发器容器从该卷读取并转发它们。

如果您想为整个集群@sariel1212收集到 Splunk，有一个官方的 Splunk helm图表可以使用Splunk HEC fluentd插件部署fluentd节点日志、容器日志和控制平面日志，以及 Kubernetes 对象和 Kubernetes 集群指标。 对于一个 Pod @coffeepac建议使用共享 emptydir 的 sidecar 是一个很好的方法。

很糟糕的是，集群所有者在这么长时间之后仍然无法使用 Docker 日志驱动程序。

我能够使用 Docker-Compose（模拟我的 K8s 集群）非常快速地进行设置，以将所有标准输出/错误通过管道传输到我的日志聚合服务。

试图在 Kubenetes 中做到这一点？ 从这个线程看来，我将不得不为每个微服务增加代码！ 不好。

嗨@ashleydavis ， dockerd在 Kubernetes 中已被弃用，因此没有必要引入对不再属于 Kubernetes 一部分的支持。 尽管您仍然可以在 Kubernetes 之外安装它。 这是背景：
https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/

除非您愿意，否则您不需要扩充容器，Kubernetes 会自动为每个容器在本地流式传输 stdout/stderr 日志。 您只需要在每个节点上部署一个容器（一个DaemonSet ）来收集这些日志流并将其发送到您选择的聚合服务。 这很容易。

https://docs.fluentd.org/container-deployment/kubernetes

这里有很多现成的fluentd +后端容器镜像和后端聚合后端的示例配置：

https://github.com/fluent/fluentd-kubernetes-daemonset

如果您使用的是 DataDog，他们可以安装自己的代理或fluentd ：

https://docs.datadoghq.com/integrations/kubernetes/

一般来说， docker倾向于kitchen sink ，在一个守护进程中包含日志和日志插件、swarm、运行时工具、构建工具、网络和文件系统挂载等。 Kubernetes 通常更喜欢松散耦合的容器/进程，每个容器/进程执行一项任务并通过 API 进行通信。 所以习惯了有点不同的风格。

感谢您的详细回复。 我肯定会调查这个。

不推荐使用 dockerd 是否意味着我将来无法将 Docker 映像部署到 Kubernetes？

@ashleydavis您当然可以继续使用“Docker”镜像（即使没有dockerd存在），并且您可以出于自己的目的继续在 Kubernetes 节点上部署dockerd （例如在 docker-in-docker 中）构建）如果你愿意。 docker 的核心部分已被提取并标准化为“OCI 容器”和containerd运行时。

https://www.opencontainers.org/
https://containerd.io/

Docker 和 Kubernetes 现在都基于这些共享标准。

https://blog.docker.com/2017/08/what-is-containerd-runtime/
https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/

谢谢，我学到了很多。

我刚刚创建了一个名为 Loggy 的微服务。 目的是让它由 Docker 日志驱动程序发送日志，然后将它们（通过 webhook）转发到 Slack。

你可以在这里看到代码： https :

非常简单，接收日志并通过 HTTP POST 将其转发到 Slack。

什么是适应这种情况的最快方法，以便我可以从我的 pod 中收集和聚合日志？

@ashleydavis你可以构建一个包含该微服务的容器镜像，然后

1. 将它部署为具有服务的集群，然后集群上的所有容器都可以发送到该服务（使用

2. 将其部署为Deployment 中的附加“sidecar”容器。 同一个 Pod 中的容器共享对同一个localhost私有访问，因此应用程序容器可以在localhost:12201上发送到您的微服务容器边车。 或者，同一 Pod 中的容器可以为共享日志文件或命名管道

这在这里变得离题了，并不是每个人都想要这个，所以也许可以在 Github 上研究一些Slack 频道寻求建议。

https://github.com/ramitsurana/awesome-kubernetes
https://slack.k8s.io/
https://kubernetes.io/

听起来不错谢谢。 我只是希望不必更改现有服务。 我只想捕获他们的标准输出/错误。 无论如何要这样做？

Docker 日志驱动程序的承诺是简单。 有没有简单的方法可以做到这一点？

当然@ashleydavis ，部署你的集群，部署fluentd ，然后砰，你就完成了😺。 您部署的每个应用程序都将其 stdout/stderr 发送到您最喜欢的聚合器。 👍

在 K8s 上投入了一些时间并进行日志记录后，我已经设置了一个不错的ELK 堆栈，而没有明确的 GELF 配置。 请看一下https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html

我的设置是 Filebeat，它将日志传送到 Logstash，Logstash 过滤和提取并将它们的内容传送到 Elasticsearch。 使用 Kibana，我可以查看日志并汇总数据。

我也很想支持日志记录到操作系统的本地 syslog 文件，例如：在 Ubuntu 上，我可以将日志写入/var/log/syslog ，它由开箱即用的 logrotate 管理。

使用 swarm / compose，我可以这样做：

version: '3.3'
services:
  mysql:
    image: mysql:5.7
    logging:
      driver: syslog
      options:
        tag: mysql

使用 emtpyDir 卷很好，但是，除非您添加一个额外的进程来旋转/截断日志文件，否则长时间运行的 pod 有填满该卷的风险。 当操作系统已经在处理 /var/log/syslog 的轮换时，我不同意这种额外的复杂性。

我同意在某些部署中使用 sidecar 是一个好主意（我已经在我的一些部署中这样做了），但是，每个人的环境都不同。

使用 emtpyDir 卷很好

小心它们——它们由 Kubernetes 管理，它们的生命周期不受你控制。 如果一个 pod 被驱逐并重新安排到另一个节点——日志将会丢失。 如果你更新一个 pod 并且它的 uid 发生变化，它不会使用旧的卷，而是创建一个新的卷并删除旧的卷。

@jsirianni并非所有系统都在运行 syslog，这意味着必须针对每个节点对可用设施进行一些注释，以确保满足给定 pod 的需求。 docker compose 可以做出这个假设，因为它只在本地运行。

@coffeepac节点可能没有系统日志并不意味着操作员不应该有选择权。 如果我打算使用 syslog，我会确保我的工作节点有 syslog。

我觉得这个问题应该重新打开，因为这个功能还有足够的用例。
/重新打开

@saiyam1814 ：重新

就个人而言，我仍然认为 Kubernetes 应该支持 Docker 日志驱动程序或其他一些简单的内置方式来配置日志记录。

我已经多次被告知在 Kubernetes 上设置日志很容易，但是现在已经完成了设置我自己的日志聚合系统的过程，我可以说这确实并不简单。

我写了一篇关于为 Kubernetes 手动滚动您自己的日志聚合系统的最简单方法的博客文章： http :

希望我的博文能帮助其他人找出他们自己的策略。

这不应该那么困难，但这就是我们所处的位置。

当然，我们需要一种直接从 stdout 和 stderr 使用 Docker 日志的方法，而不是使用日志文件。 使用 Docker 路径记录文件存在一些安全问题，因为您可以访问主机系统中的其他日志。

我们可以实现 Docker 日志驱动程序吗？ 👍

在容器中的 pod 级别（其中 pod 受客户控制）配置 docker 日志驱动程序将启用使用gelf驱动程序将日志直接重定向到灰色日志服务/pod（也受客户控制） ) 而不是必须使用另一个即时服务从主机上的文件中收集它们（与使用gelf日志驱动程序相比，这是更多的管理开销和更糟糕的抽象级别中断）或通过客户的 pod 访问容器日志目录在主机上。

因此，我很想看到在 kubernetes 中实现这个功能。

确保我们执行类似https://github.com/cri-o/cri-o/pull/1605 的操作会很有帮助，在那里我们断开日志流解释与日志驱动程序的连接，以便容器行为不会影响如何司机工作。

烂问题在 30 天不活动后关闭。
使用/reopen重新打开问题。
使用/remove-lifecycle rotten将问题标记为新问题。

向 sig-testing、kubernetes/test-infra 和/或fejta发送反馈。
/关闭

@fejta-bot：关闭此问题。

功能还需要实现
/重新打开

@M0rdecay ：除非您是作者或合作者，否则您无法重新打开问题/PR。

@M0rdecay ：除非您是作者或合作者，否则您无法重新打开问题/PR。

好的，我明白了

甚至 aws ecs 也有这个功能，可以设置 docker 日志驱动程序。
在我们的环境中，我们为每个容器服务创建了一个带有唯一令牌的单独索引。

“日志配置”：{
"logDriver": "splunk",
“选项”： {
“splunk 格式”：“原始”，
"splunk-insecureskipverify": "true",
"splunk-token": "xxxxx-xxxxxxx-xxxxx-xxxxxxx-xxxxxx",
"splunk-url": " https://xxxxx.splunk-heavyforwarderxxx.com ",
"tag": "{{.Name}}/{{.ID}}",
"splunk-verify-connection": "false",
“模式”：“非阻塞”
}
}

但是在k8s中没有找到类似的东西。 它应该在 pod 定义本身中。

选项仍需执行
/重新打开

@ejemba ：重新

/ 签名节点
/ remove-sig 检测

/remove-sig 可扩展性

@logicalhan ：这些标签没有设置在这个问题上： sig/

有什么进展吗？
我一直在寻找能够设置 pod 的容器以登录到外部日志存储的能力，指定 docker 的 gelf 日志驱动程序。 默认情况下为 /etc/docker/daemon.json 中的所有容器设置它似乎是一种开销。

烂问题在 30 天不活动后关闭。
使用/reopen重新打开问题。
使用/remove-lifecycle rotten将问题标记为新问题。

向 sig-testing、kubernetes/test-infra 和/或fejta发送反馈。
/关闭

@fejta-bot：关闭此问题。

/重新打开

@andreswebs ：除非您是作者或合作者，否则您无法重新打开问题/PR。

/重新打开

@ejemba ：重新

@ejemba ：这个问题目前正在等待分类。

如果 SIG 或子项目确定这是一个相关问题，他们将通过应用triage/accepted标签来接受它并提供进一步的指导。

组织成员可以通过在评论中写入/triage accepted来添加triage/accepted标签。

我真的很想实现这个功能。 我目前正在将工作负载从 Rancher 1.x 集群迁移到运行 k8s 的 Rancher 2.x 集群。 我们有一个部署，它在 docker-compose 配置中设置 log-driver 和 log-opt 参数。

我不想配置一个特定的主机来全局使用 gelf 驱动程序，并用标签标记 pod，用标签标记主机。

似乎我们应该更改 CRI-O 以指定两个容器日志流（stdout / stderr）都以原始形式收集，然后在读取原始数据时我们可以对日志字节流应用不同的解释。

参见https://github.com/cri-o/cri-o/pull/1605。

烂问题在 30 天不活动后关闭。
使用/reopen重新打开问题。
使用/remove-lifecycle rotten将问题标记为新问题。

向 sig-testing、kubernetes/test-infra 和/或fejta发送反馈。
/关闭

@fejta-bot：关闭此问题。