网站制作哪家做的好,杭州网络运营公司排名,河北婚庆网站建设定制,建一个网站难不难日志架构
应用日志可以让你了解应用内部的运行状况。日志对调试问题和监控集群活动非常有用。 大部分现代化应用都有某种日志记录机制。同样地#xff0c;容器引擎也被设计成支持日志记录。 针对容器化应用#xff0c;最简单且最广泛采用的日志记录方式就是写入标准输出和标…日志架构
应用日志可以让你了解应用内部的运行状况。日志对调试问题和监控集群活动非常有用。 大部分现代化应用都有某种日志记录机制。同样地容器引擎也被设计成支持日志记录。 针对容器化应用最简单且最广泛采用的日志记录方式就是写入标准输出和标准错误流。
但是由容器引擎或运行时提供的原生功能通常不足以构成完整的日志记录方案。
例如如果发生容器崩溃、Pod 被逐出或节点宕机等情况你可能想访问应用日志。
在集群中日志应该具有独立的存储并且其生命周期与节点、Pod 或容器的生命周期相独立。 这个概念叫集群级的日志。
集群级日志架构需要一个独立的后端用来存储、分析和查询日志。 Kubernetes 并不为日志数据提供原生的存储解决方案。 相反有很多现成的日志方案可以集成到 Kubernetes 中。 下面各节描述如何在节点上处理和存储日志。
Pod 和容器日志
Kubernetes 从正在运行的 Pod 中捕捉每个容器的日志。
此示例使用带有一个容器的 Pod 的清单该容器每秒将文本写入标准输出一次。
debug/counter-pod.yaml
apiVersion: v1
kind: Pod
metadata:name: counter
spec:containers:- name: countimage: busybox:1.28args: [/bin/sh, -c,i0; while true; do echo $i: $(date); i$((i1)); sleep 1; done]要运行此 Pod请执行以下命令
kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml输出为
pod/counter created要获取这些日志请执行以下 kubectl logs 命令
kubectl logs counter输出类似于
0: Fri Apr 1 11:42:23 UTC 2022
1: Fri Apr 1 11:42:24 UTC 2022
2: Fri Apr 1 11:42:25 UTC 2022你可以使用 kubectl logs --previous 从容器的先前实例中检索日志。 如果你的 Pod 有多个容器请如下通过将容器名称追加到该命令并使用 -c 标志来指定要访问哪个容器的日志
kubectl logs counter -c count详见 kubectl logs 文档。
节点的容器日志处理方式 容器运行时对写入到容器化应用程序的 stdout 和 stderr 流的所有输出进行处理和转发。 不同的容器运行时以不同的方式实现这一点不过它们与 kubelet 的集成都被标准化为 CRI 日志格式。
默认情况下如果容器重新启动kubelet 会保留一个终止的容器及其日志。 如果一个 Pod 被逐出节点所对应的所有容器及其日志也会被逐出。
kubelet 通过 Kubernetes API 的特殊功能将日志提供给客户端访问。 访问这个日志的常用方法是运行 kubectl logs。
日志轮转
特性状态 Kubernetes v1.21 [stable]
你可以配置 kubelet 令其自动轮转日志。
如果配置轮转kubelet 负责轮转容器日志并管理日志目录结构。 kubelet使用 CRI将此信息发送到容器运行时而运行时则将容器日志写到给定位置。
你可以使用 kubelet 配置文件配置两个 kubelet 配置选项、 containerLogMaxSize 和 containerLogMaxFiles。 这些设置分别允许你分别配置每个日志文件大小的最大值和每个容器允许的最大文件数。
当类似于基本日志示例一样运行 kubectl logs 时 节点上的 kubelet 会处理请求并直接从日志文件读取。kubelet 将返回该日志文件的内容。
说明
只有最新的日志文件的内容可以通过 kubectl logs 获得。
例如如果 Pod 写入 40 MiB 的日志并且 kubelet 在 10 MiB 之后轮转日志 则运行 kubectl logs 将最多返回 10 MiB 的数据。
系统组件日志
系统组件有两种类型通常在容器中运行的组件和直接参与容器运行的组件。例如
kubelet 和容器运行时不在容器中运行。kubelet 运行你的容器 一起按 Pod 分组Kubernetes 调度器、控制器管理器和 API 服务器在 Pod 中运行 通常是静态 Pod。 etcd 组件在控制平面中运行最常见的也是作为静态 Pod。 如果你的集群使用 kube-proxy则通常将其作为 DaemonSet 运行。
日志位置
kubelet 和容器运行时写入日志的方式取决于节点使用的操作系统
LinuxWindows
在使用 systemd 的 Linux 节点上kubelet 和容器运行时默认写入 journald。 你要使用 journalctl 来阅读 systemd 日志例如journalctl -u kubelet。
如果 systemd 不存在kubelet 和容器运行时将写入到 /var/log 目录中的 .log 文件。 如果你想将日志写入其他地方你可以通过辅助工具 kube-log-runner 间接运行 kubelet 并使用该工具将 kubelet 日志重定向到你所选择的目录。
kubelet 始终指示你的容器运行时将日志写入 /var/log/pods 中的目录。
有关 kube-log-runner 的更多信息请阅读系统日志。
对于在 Pod 中运行的 Kubernetes 集群组件其日志会写入 /var/log 目录中的文件 相当于绕过默认的日志机制组件不会写入 systemd 日志。 你可以使用 Kubernetes 的存储机制将持久存储映射到运行该组件的容器中。
有关 etcd 及其日志的详细信息请查阅 etcd 文档。 同样你可以使用 Kubernetes 的存储机制将持久存储映射到运行该组件的容器中。
说明
如果你部署 Kubernetes 集群组件例如调度器以将日志记录到从父节点共享的卷中 则需要考虑并确保这些日志被轮转。 Kubernetes 不管理这种日志轮转。
你的操作系统可能会自动实现一些日志轮转。例如如果你将目录 /var/log 共享到一个组件的静态 Pod 中 则节点级日志轮转会将该目录中的文件视同为 Kubernetes 之外的组件所写入的文件。
一些部署工具会考虑日志轮转并将其自动化而其他一些工具会将此留给你来处理。
集群级日志架构
虽然 Kubernetes 没有为集群级日志记录提供原生的解决方案但你可以考虑几种常见的方法。 以下是一些选项
使用在每个节点上运行的节点级日志记录代理。在应用程序的 Pod 中包含专门记录日志的边车Sidecar容器。将日志直接从应用程序中推送到日志记录后端。
使用节点级日志代理 你可以通过在每个节点上使用节点级的日志记录代理来实现集群级日志记录。 日志记录代理是一种用于暴露日志或将日志推送到后端的专用工具。 通常日志记录代理程序是一个容器它可以访问包含该节点上所有应用程序容器的日志文件的目录。
由于日志记录代理必须在每个节点上运行推荐以 DaemonSet 的形式运行该代理。
节点级日志在每个节点上仅创建一个代理不需要对节点上的应用做修改。
容器向标准输出和标准错误输出写出数据但在格式上并不统一。 节点级代理收集这些日志并将其进行转发以完成汇总。
使用边车容器运行日志代理
你可以通过以下方式之一使用边车Sidecar容器
边车容器将应用程序日志传送到自己的标准输出。边车容器运行一个日志代理配置该日志代理以便从应用容器收集日志。
传输数据流的边车容器
利用边车容器写入到自己的 stdout 和 stderr 传输流 你就可以利用每个节点上的 kubelet 和日志代理来处理日志。 边车容器从文件、套接字或 journald 读取日志。 每个边车容器向自己的 stdout 和 stderr 流中输出日志。
这种方法允许你将日志流从应用程序的不同部分分离开其中一些可能缺乏对写入 stdout 或 stderr 的支持。重定向日志背后的逻辑是最小的因此它的开销不大。 另外因为 stdout 和 stderr 由 kubelet 处理所以你可以使用内置的工具 kubectl logs。
例如某 Pod 中运行一个容器且该容器使用两个不同的格式写入到两个不同的日志文件。 下面是这个 Pod 的清单
admin/logging/two-files-counter-pod.yaml
apiVersion: v1
kind: Pod
metadata:name: counter
spec:containers:- name: countimage: busybox:1.28args:- /bin/sh- -c- i0;while true;doecho $i: $(date) /var/log/1.log;echo $(date) INFO $i /var/log/2.log;i$((i1));sleep 1;done volumeMounts:- name: varlogmountPath: /var/logvolumes:- name: varlogemptyDir: {}不建议在同一个日志流中写入不同格式的日志条目即使你成功地将其重定向到容器的 stdout 流。 相反你可以创建两个边车容器。每个边车容器可以从共享卷跟踪特定的日志文件 并将文件内容重定向到各自的 stdout 流。
下面是运行两个边车容器的 Pod 的清单
admin/logging/two-files-counter-pod-streaming-sidecar.yaml
apiVersion: v1
kind: Pod
metadata:name: counter
spec:containers:- name: countimage: busybox:1.28args:- /bin/sh- -c- i0;while true;doecho $i: $(date) /var/log/1.log;echo $(date) INFO $i /var/log/2.log;i$((i1));sleep 1;done volumeMounts:- name: varlogmountPath: /var/log- name: count-log-1image: busybox:1.28args: [/bin/sh, -c, tail -n1 -F /var/log/1.log]volumeMounts:- name: varlogmountPath: /var/log- name: count-log-2image: busybox:1.28args: [/bin/sh, -c, tail -n1 -F /var/log/2.log]volumeMounts:- name: varlogmountPath: /var/logvolumes:- name: varlogemptyDir: {}现在当你运行这个 Pod 时你可以运行如下命令分别访问每个日志流
kubectl logs counter count-log-1输出类似于
0: Fri Apr 1 11:42:26 UTC 2022
1: Fri Apr 1 11:42:27 UTC 2022
2: Fri Apr 1 11:42:28 UTC 2022
...kubectl logs counter count-log-2输出类似于
Fri Apr 1 11:42:29 UTC 2022 INFO 0
Fri Apr 1 11:42:30 UTC 2022 INFO 0
Fri Apr 1 11:42:31 UTC 2022 INFO 0
...如果你在集群中安装了节点级代理由代理自动获取上述日志流而无需任何进一步的配置。 如果你愿意你可以将代理配置为根据源容器解析日志行。
即使对于 CPU 和内存使用率较低的 PodCPU 为几毫核内存为几兆字节将日志写入一个文件 将这些日志流写到 stdout 也有可能使节点所需的存储量翻倍。 如果你有一个写入特定文件的应用程序则建议将 /dev/stdout 设置为目标文件而不是采用流式边车容器方法。
边车容器还可用于轮转应用程序本身无法轮转的日志文件。 这种方法的一个例子是定期运行 logrotate 的小容器。 但是直接使用 stdout 和 stderr 更直接而将轮转和保留策略留给 kubelet。
集群中安装的节点级代理会自动获取这些日志流而无需进一步配置。 如果你愿意你也可以配置代理程序来解析源容器的日志行。
注意尽管 CPU 和内存使用率都很低以多个 CPU 毫核指标排序或者按内存的兆字节排序 向文件写日志然后输出到 stdout 流仍然会成倍地增加磁盘使用率。 如果你的应用向单一文件写日志通常最好设置 /dev/stdout 作为目标路径 而不是使用流式的边车容器方式。
如果应用程序本身不能轮转日志文件则可以通过边车容器实现。 这种方式的一个例子是运行一个小的、定期轮转日志的容器。 然而还是推荐直接使用 stdout 和 stderr将日志的轮转和保留策略交给 kubelet。
具有日志代理功能的边车容器
如果节点级日志记录代理程序对于你的场景来说不够灵活 你可以创建一个带有单独日志记录代理的边车容器将代理程序专门配置为与你的应用程序一起运行。
说明
在边车容器中使用日志代理会带来严重的资源损耗。 此外你不能使用 kubectl logs 访问日志因为日志并没有被 kubelet 管理。
下面是两个配置文件可以用来实现一个带日志代理的边车容器。 第一个文件包含用来配置 fluentd 的 ConfigMap。
admin/logging/fluentd-sidecar-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:name: fluentd-config
data:fluentd.conf: |sourcetype tailformat nonepath /var/log/1.logpos_file /var/log/1.log.postag count.format1/sourcesourcetype tailformat nonepath /var/log/2.logpos_file /var/log/2.log.postag count.format2/sourcematch **type google_cloud/match 说明
你可以将此示例配置中的 fluentd 替换为其他日志代理从应用容器内的其他来源读取数据。
第二个清单描述了一个运行 fluentd 边车容器的 Pod。 该 Pod 挂载一个卷flutend 可以从这个卷上拣选其配置数据。
admin/logging/two-files-counter-pod-agent-sidecar.yaml
apiVersion: v1
kind: Pod
metadata:name: counter
spec:containers:- name: countimage: busybox:1.28args:- /bin/sh- -c- i0;while true;doecho $i: $(date) /var/log/1.log;echo $(date) INFO $i /var/log/2.log;i$((i1));sleep 1;done volumeMounts:- name: varlogmountPath: /var/log- name: count-agentimage: registry.k8s.io/fluentd-gcp:1.30env:- name: FLUENTD_ARGSvalue: -c /etc/fluentd-config/fluentd.confvolumeMounts:- name: varlogmountPath: /var/log- name: config-volumemountPath: /etc/fluentd-configvolumes:- name: varlogemptyDir: {}- name: config-volumeconfigMap:name: fluentd-config从应用中直接暴露日志目录 从各个应用中直接暴露和推送日志数据的集群日志机制已超出 Kubernetes 的范围
