使用 Sematext 记录和监控 Kubernetes 容器 (使用 Sematext 记录和监控 Kubernetes 容器)

管理容器中的微服务通常使用集群管理器和编排工具来完成。每个容器平台都有一组略有不同的选项来在每个集群节点上部署容器或调度任务。因为我们在 Sematext 进行容器监控和日志记录，所以我们的部分工作是分享我们对这些工具的知识，尤其是与容器可观察性和开发运维相关的知识。今天，我们将展示一个关于 Kubernetes 上的容器监控和日志收集的教程。

动态部署需要动态监控

容器和微服务生命周期的高度自动化使得 Kubernetes 的监控比更传统的、更静态的部署更具挑战性。任何用于监控特定应用程序容器的静态设置都将不起作用，因为 Kubernetes 会根据定义的部署规则自行做出决策。不仅需要监控已部署的微服务，还需要监控 Kubernetes 核心服务本身的指标和日志，例如运行 etcd、controller-manager、scheduler 和 apiserver 的 Kubernetes Master，以及运行 kubelet 和代理服务的 Kubernetes Worker（以前的 minion）。拥有一个集中的位置来监控所有这些服务、它们的指标和日志，有助于发现集群基础设施中的问题。Kubernetes 核心服务可以安装在裸机、虚拟机或使用 Docker 的容器中。在容器中部署 Kubernetes 核心服务可能有助于部署和监控操作 - 容器监控工具将涵盖核心服务和应用程序容器。那么如何监控如此复杂和动态的环境呢？

用于 Kubernetes 指标和日志的代理

有许多开源 Docker 监控和日志记录项目可以拼凑在一起构建一个监控和日志收集系统（或多个系统）。优点是代码都是免费的。缺点是这需要时间 - 初始设置时和以后维护时都需要时间。这就是我们构建Sematext Docker Agent的原因 - 一个现代的、Docker 感知的指标、事件和日志收集代理。它在每个 Docker 主机上作为一个小容器运行，并收集所有集群节点和所有容器的日志、指标和事件。它会发现所有容器（一个 pod 可能包含多个容器），包括 Kubernetes 核心服务的容器（如果核心服务部署在 Docker 容器中）。让我们看看如何部署此代理。

**将代理部署到所有 Kubernetes 节点**

Kubernetes 提供了DaemonSet，它确保将 pod 添加到节点，因为节点被添加到集群中。我们可以使用它轻松地将 Sematext Agent 部署到每个集群节点！
为 Kubernetes 配置 Sematext Docker Agent
假设您已经为 Kubernetes 指标和事件创建了一个 SPM 应用程序，并为 Kubernetes 日志创建了一个 Logsene 应用程序，每个应用程序都有自己的令牌。Sematext Docker Agent 的README列出了所有配置（例如，过滤特定 pod/image/container），但我们在这里保持简单。

• 获取最新的 sematext-agent-daemonset.yml（原始纯文本）模板（如下所示）
• 将其保存在磁盘上的某个位置
• 将 SPM_TOKEN 和 LOGSENE_TOKEN 占位符替换为您的 SPM 和 Logsene 应用程序令牌

apiVersion: extensions/v1beta1  
kind: DaemonSet  
metadata:  
  name: sematext-agent  
spec:  
  template:  
    metadata:  
      labels:  
        app: sematext-agent  
    spec:  
      selector: {}  
      dnsPolicy: "ClusterFirst"  
      restartPolicy: "Always"  
      containers:  
      - name: sematext-agent  
        image: sematext/sematext-agent-docker:latest  
        imagePullPolicy: "Always"  
        env:  
        - name: SPM\_TOKEN  
          value: "REPLACE THIS WITH YOUR SPM TOKEN"  
        - name: LOGSENE\_TOKEN  
          value: "REPLACE THIS WITH YOUR LOGSENE TOKEN"  
        - name: KUBERNETES  
          value: "1"  
        volumeMounts:  
          - mountPath: /var/run/docker.sock  
            name: docker-sock  
          - mountPath: /etc/localtime  
            name: localtime  
      volumes:  
        - name: docker-sock  
          hostPath:  
            path: /var/run/docker.sock  
        - name: localtime  
          hostPath:  
            path: /etc/localtime

将代理作为 DaemonSet 运行

使用 *kubectl* 激活 Sematext Agent Docker

\> kubectl create -f sematext-agent-daemonset.yml

daemonset "sematext-agent-daemonset" created

现在让我们检查代理是否已部署到所有节点

\> kubectl get pods

NAME                   READY     STATUS              RESTARTS   AGE

sematext-agent-nh4ez   0/1       ContainerCreating   0          6s

sematext-agent-s47vz   0/1       ImageNotReady       0          6s

状态“ImageNotReady”或“ContainerCreating”可能在短时间内可见，因为 Kubernetes 必须首先下载 sematext/sematext-agent-docker 的镜像。sematext-agent-daemonset.yml 中指定的 imagePullPolicy: "Always" 设置确保 Sematext Agent 使用 Docker-Hub 中的镜像自动更新。

如果我们再次检查，我们将看到 Sematext Docker Agent 已部署到（所有）集群节点

\> kubectl get pods -l sematext-agent

NAME                   READY     STATUS    RESTARTS   AGE

sematext-agent-nh4ez   1/1       Running   0          8s

sematext-agent-s47vz   1/1       Running   0          8s

部署后不到一分钟，您应该会看到 Kubernetes 指标和日志！以下是各种开箱即用报告的屏幕截图以及各种指标含义的说明。

Kubernetes 指标的解释

来自所有 Kubernetes 节点的指标收集在一个 SPM 应用程序中，该应用程序在多个级别聚合指标

• 集群 - 在 SPM 概述中显示的所有节点上聚合的指标
• 主机/节点级别 - 每个节点聚合的指标
• Docker 镜像级别 - 按镜像名称聚合的指标，例如所有 nginx webserver 容器
• Docker 容器级别 - 为单个容器聚合的指标

| | | 来自 Kubernetes 集群的主机和容器指标 |

每个详细图表都有针对节点、Docker 镜像和 Docker 容器的过滤选项。由于 Kubernetes 在 Docker 容器的名称中使用 pod 名称，因此在 Docker 容器过滤器中按 pod 名称进行搜索可以轻松选择特定 pod 的所有容器。

让我们看一下 SPM 提供的一些 Kubernetes（和 Docker）关键指标。

主机指标，例如 CPU、内存和磁盘空间使用情况。Docker 镜像和容器比主机上安装的常规进程消耗更多的磁盘空间。例如，一个应用程序镜像可能包含一个 Linux 操作系统，大小可能在 150-700 MB 之间，具体取决于基础镜像的大小和容器中安装的工具。数据容器也会占用主机上的磁盘空间。根据我们的经验，监控磁盘空间和使用清理工具对于 Docker 主机的持续运行至关重要。

容器数量 - 表示每个主机上运行的容器数量

| | | 每个 Kubernetes 节点随时间变化的容器计数器 |

容器内存和内存失败计数器。这些指标对于监控非常重要，对于调整应用程序也至关重要。内存限制应与已部署 pod（应用程序）的占用空间相符，以避免 Kubernetes 使用默认限制（例如为命名空间定义的限制）的情况，这可能导致容器的 OOM kill。内存失败计数器反映容器中内存分配失败的次数，如果发生 OOM kill，则会触发 Docker 事件。由于 Sematext Docker 代理 会收集所有 Docker 事件，因此该事件会显示在 SPM 中。最佳实践是通过几次迭代来调整内存设置

• 监控应用程序容器的内存使用情况
• 根据观察结果设置内存限制
• 继续监控内存、内存失败计数器和内存不足事件。如果发生 OOM 事件，则可能需要增加容器内存限制，或者需要进行调试以找出内存消耗过高的原因。

| | | 容器内存使用情况、限制和失败计数器 |

容器 CPU 使用率和受限 CPU 时间。CPU 使用率可以通过 CPU shares 进行限制 - 与内存不同，CPU 使用率不是硬性限制。只要资源可用，容器可能会使用更多 CPU，但在其他容器需要 CPU 的情况下，限制将适用，并且 CPU 将被限制在限制范围内。

还有更多需要监控的 Docker 指标，例如磁盘 I/O 吞吐量、网络吞吐量和容器的网络错误，但接下来让我们看看 Kubernetes 日志。

了解 Kubernetes 日志

Kubernetes 容器的日志与 Docker 容器日志没有太大区别。但是，Kubernetes 用户需要查看已部署 pod 的日志。这就是为什么拥有 Kubernetes 特定的信息（例如以下信息）可用于日志搜索非常有用的原因：

• Kubernetes 命名空间
• Kubernetes pod 名称
• Kubernetes 容器名称
• Docker 镜像名称
• Kubernetes UID

Sematext Docker 代理从 Docker 容器名称中提取此信息，并使用上述信息标记所有日志。将这些数据提取到各个字段中，可以非常轻松地监控已部署 pod 的日志，根据日志构建报告，在故障排除时快速缩小到有问题的 pod，等等！如果 Kubernetes 核心组件（例如 kubelet、proxy、api 服务器）是通过 Docker 部署的，则 Sematext Docker 代理也将收集 Kubernetes 核心组件日志。

| | | Logsene 中 Kubernetes 容器的所有日志 |

Logsene 和 Sematext Docker 代理还提供了许多其他开箱即用的功能，例如：

• 自动检测和解析日志格式

  • Sematext Docker 代理包含用于识别和解析多种日志格式的模式

• 针对特定镜像和应用程序类型的自定义模式定义

• 容器日志的自动 Geo-IP 丰富

• 过滤日志，例如排除嘈杂的服务

• 屏蔽特定日志字段中的敏感数据（电话号码、付款信息、身份验证令牌）

• 基于日志的警报和计划报告

• 结构化日志的分析，例如在 Kibana 或 Grafana 中

我们 Docker 日志管理 文章中介绍了大多数主题，这些主题也与 Kubernetes 日志管理相关。如果您想了解有关 Docker 监控 的更多信息，请阅读我们 博客 上的更多内容。

• 下载 Kubernetes
• 在 GitHub 上参与 Kubernetes 项目
• 在 Stack Overflow 上发布问题（或回答问题）
• 在 Slack 上与社区联系
• 在 Twitter 上关注我们 @Kubernetesio 获取最新更新

• ←上一页
下一页→