kubernetes微服务实战pdf,k8s架构原理

文章目录1 .容器日志Kubernetes日志2.1应用(Pod ) 2.2节点2.3群集2.3.1节点代理方法2.3.2使用sidecar容器日志代理2.3.3日志代理

1 .容器日志

Docker日志分为两类，一类是http://www.Sina.com，另一类是Docker引擎日志引擎日志，它们通常传递到系统日志中，并根据操作系统的不同而位于不同的位置。本文主要介绍容器日志。容器日志可以理解为由容器内部运行的APP应用程序输出的日志。默认情况下，docker logs显示当前运行的容器的日志信息。内容包括STOUT (标准输出)和STDERR (标准错误输出)。所有日志均以json-file格式显示/var/lib/docker/containers/容器id/容器id-json.log，容器日志

.默认情况下，容器日志不限制日志文件的大小。容器继续写日志，磁盘已满，影响系统APP应用程序。【docker log-driver支持日志文件的rotate】对于Docker Daemon收集容器的标准输出，过多的日志量会使Docker Daemon成为日志收集瓶颈，从而限制日志的收集速度。如果日志文件太多，在docker logs -f中查看时会直接阻止Docker Daemon，从而导致docker ps等命令没有响应。 Docker提供了日志记录驱动程序配置，用户可以根据需要配置不同的日志驱动程序，但上述配置的日志收集也由Docker Daemon收集，日志收集速度仍然是瓶颈。

日志-驱动程序日志收集速度

syslog 14.9 MB/SJ son-file 37.9 MB/s是否可以找到不通过Docker Daemon收集日志而直接将日志内容重定向到文件并自动进行旋转的工具？答案肯定地采用S6[2]基镜。

S6-log将CMD的标准输出重定向到/./default/current，而不是发送到Docker Daemon，从而避免了Docker Daemon收集日志的性能瓶颈

2 .关于kubernetes日志，kubernetes日志收集方案分为三个层次

2.1应用(Pod )级别的Pod级别日志默认输出到标准输出和标志输入，实际上与Docker容器匹配。在kubectl logs pod-name -n namespace中查看。具体参考： https://kubernetes.io/docs/reference/generated/kube CTL/kube CTL-commands

2.2配置容器的log-driver来管理节点级的Node级日志。这需要与logrotare配合使用，如果日志超过最大限制，将自动执行rotate操作。

缺省情况下，当容器重新启动时，kubelet将保留已关闭的容器日志。如果在工作节点上驱逐Pod，则该Pod中的所有容器(包括容器日志)也将被驱逐。

节点级日志记录应侧重于实现日志轮换，以避免日志占用节点上的所有可用空间。 Kubernetes不负责日志轮换，而是使用部署工具构建解决问题的解决方案。例如，使用kube-up.sh部署的Kubernetes群集具有每小时运行一次的logrotate。也可以将APP应用程序日志配置为在容器运行时自动轮换。

例如，kube-up.sh可以找到设置GCP环境中COS镜像日志的详细信息。脚本是配置帮助器脚本。

在使用一个CRI容器运行时，kubelet负责轮换日志并管理日志目录的结构。当kubelet将此信息发送到CRI容器并运行时，后者将容器日志写入指定位置。可以使用kubelet标志container-log-max-size和container-log-max-files设置每个日志文件的最大长度和每个容器可以生成的最大日志文件数。

运行kubectl logs时，节点上的kubelet会处理请求，直接读取日志文件，并在响应中返回日志文件的内容。

2.3集群级别集群级别的日志收集有3种。

使用在每个节点上运行的节点级日志记录代理。 “APP应用程序”的Pod包含用于记录日志的“侧车”(Sidecar )容器。将日志从APP应用程序直接推入日志记录的后端。 2.3.1节点代理方式在节点代理方式、节点级别进行日志收集。通常，使用DaemonSet部署到每个节点。这种方法的优点是，只需在节点上部署，就不会侵入APP应用程序，因此资源消耗很少。缺点是容器中的所有APP应用程序日志都必须是标准输出。

日志代理通常作为DaemonSet在节点上运行，装载主机上的容器模拟目录，最后日志代理传输日志。

举个例子，我们可以通过 Fluentd 项目作为宿主机上的 logging-agent，然后把日志转发到远端的 ElasticSearch 里保存起来供将来进行检索。

优点：在于一个节点只需要部署一个 agent，并且不会对应用和 Pod 有任何侵入性。所以，这个方案，在社区里是最常用的一种。缺点：这种方案的不足之处就在于，它要求应用输出的日志，都必须是直接输出到容器的 stdout 和 stderr 里。 2.3.2 使用 sidecar 容器运行日志代理

也就是在Pod中跟随应用容器起一个日志处理容器，有两种形式：

一种是直接将应用容器的日志收集并输出到标准输出（叫做Streaming sidecar container），但需要注意的是，这时候，宿主机上实际上会存在两份相同的日志文件：一份是应用自己写入的；另一份则是sidecar的stdout和stderr对应的JSON文件。这对磁盘是很大的浪费，所以说，除非万不得已或者应用容器完全不可能被修改。

在这种情况下，你用 kubectl logs 命令是看不到应用的任何日志的。而且我们前面讲解的、最常用的方案一，也是没办法使用的。那么这个时候，我们就可以为这个 Pod 添加两个 sidecar 容器，分别将上述两个日志文件里的内容重新以 stdout 和 stderr 的方式输出出来，这个 YAML 文件的写法如下所示：

apiVersion: v1kind: Podmetadata: name: counterspec: containers: - name: count image: busybox args: - /危机的滑板/sh - -c - > i=0; while true; do echo "$i: $(date)" >> /var/log/1.log; echo "$(date) INFO $i" >> /var/log/2.log; i=$((i+1)); sleep 1; done volumeMounts: - name: varlog mountPath: /var/log - name: count-log-1 image: busybox args: [/危机的滑板/sh, -c, 'tail -n+1 -f /var/log/1.log'] volumeMounts: - name: varlog mountPath: /var/log - name: count-log-2 image: busybox args: [/危机的滑板/sh, -c, 'tail -n+1 -f /var/log/2.log'] volumeMounts: - name: varlog mountPath: /var/log volumes: - name: varlog emptyDir: {}

这时候，你就可以通过 kubectl logs 命令查看这两个 sidecar 容器的日志，间接看到应用的日志内容了，如下所示：

kubectl logs counter count-log-1输出为：0: Mon Jan 1 00:00:00 UTC 20011: Mon Jan 1 00:00:01 UTC 20012: Mon Jan 1 00:00:02 UTC 2001kubectl logs counter count-log-2输出为：Mon Jan 1 00:00:00 UTC 2001 INFO 0Mon Jan 1 00:00:01 UTC 2001 INFO 1Mon Jan 1 00:00:02 UTC 2001 INFO 2

由于 sidecar 跟主容器之间是共享 Volume 的，所以这里的 sidecar 方案的额外性能损耗并不高，也就是多占用一点 CPU 和内存罢了。

但需要注意的是，这时候，宿主机上实际上会存在两份相同的日志文件：一份是应用自己写入的；另一份则是 sidecar 的 stdout 和 stderr 对应的 JSON 文件。这对磁盘是很大的浪费。所以说，除非万不得已或者应用容器完全不可能被修改，否则我还是建议你直接使用方案一，或者直接使用下面的第三种方案。

2.3.3 具有日志代理功能的边车容器

就是通过一个 sidecar 容器，直接把应用的日志文件发送到远程存储里面去。也就是相当于把方案一里的 logging agent，放在了应用 Pod 里。这种方案的架构如下所示：

在这种方案里，你的应用还可以直接把日志输出到固定的文件里而不是 stdout，你的 logging-agent 还可以使用 fluentd，后端存储还可以是 ElasticSearch。只不过， fluentd 的输入源，变成了应用的日志文件。一般来说，我们会把 fluentd 的输入源配置保存在一个 ConfigMap 里，如下所示：
第一个文件包含用来配置 fluentd 的 ConfigMap。
要进一步了解如何配置 fluentd，请参考 fluentd 官方文档。

apiVersion: v1kind: ConfigMapmetadata: name: fluentd-configdata: fluentd.conf: | <source> type tail format none path /var/log/1.log pos_file /var/log/1.log.pos tag count.format1 </source> <source> type tail format none path /var/log/2.log pos_file /var/log/2.log.pos tag count.format2 </source> <match **> type google_cloud </match>

后，我们在应用 Pod 的定义里，就可以声明一个 Fluentd 容器作为 sidecar，专门负责将应用生成的 1.log 和 2.log 转发到 ElasticSearch 当中。。

apiVersion: v1kind: Podmetadata: name: counterspec: containers: - name: count image: busybox args: - /危机的滑板/sh - -c - > i=0; while true; do echo "$i: $(date)" >> /var/log/1.log; echo "$(date) INFO $i" >> /var/log/2.log; i=$((i+1)); sleep 1; done volumeMounts: - name: varlog mountPath: /var/log - name: count-agent image: k8s.gcr.io/fluentd-gcp:1.30 env: - name: FLUENTD_ARGS value: -c /etc/fluentd-config/fluentd.conf volumeMounts: - name: varlog mountPath: /var/log - name: config-volume mountPath: /etc/fluentd-config volumes: - name: varlog emptyDir: {} - name: config-volume configMap: name: fluentd-config

可以看到，这个 Fluentd 容器使用的输入源，就是通过引用我们前面编写的 ConfigMap 来指定的。这里我用到了 Projected Volume 来把 ConfigMap 挂载到 Pod 里。

需要注意的是，这种方案虽然部署简单，并且对宿主机非常友好，但是这个 sidecar 容器很可能会消耗较多的资源，甚至拖垮应用容器。并且，由于日志还是没有输出到 stdout 上，所以你通过 kubectl logs 是看不到任何日志输出的。

3. 日志位置

有两种类型：在容器中运行的和不在容器中运行的。例如：

在容器中运行的 kube-scheduler 和 kube-proxy。不在容器中运行的 kubelet 和容器运行时。

在使用 systemd 机制的服务器上，kubelet 和容器容器运行时将日志写入到 journald 中。如果没有 systemd，它们将日志写入到 /var/log 目录下的 .log 文件中。容器中的系统组件通常将日志写到 /var/log 目录，绕过了默认的日志机制。他们使用 klog 日志库。你可以在日志开发文档找到这些组件的日志告警级别约定。

和容器日志类似，/var/log 目录中的系统组件日志也应该被轮转。通过脚本 kube-up.sh 启动的 Kubernetes 集群中，日志被工具 logrotate 执行每日轮转，或者日志大小超过 100MB 时触发轮转。

参考链接：
https://kubernetes.io/zh/docs/concepts/cluster-administration/system-logs/
https://mp.weixin.qq.com/s/XSTvxCrZPJUbATlXGscttA