在 Kubernetes 上扩展 Elastic Agent

有关如何在 Kubernetes 上部署 Elastic Agent 的更多信息，请查看以下页面

可观测性规模化编辑

本文档总结了使用 Elastic 可观测性 大规模监控 Kubernetes 基础设施的一些关键因素和最佳实践。用户需要考虑不同的参数并相应地调整 Elastic Stack。随着 Kubernetes 集群规模的增长，这些元素会受到影响

本文档分为两个主要部分

配置最佳实践编辑

配置 Agent 资源编辑

Kubernetes 可观测性基于 Elastic Kubernetes 集成，它从多个组件收集指标

Controller Manager 和 Scheduler 数据流仅在基于自动发现规则实际运行的特定节点上启用

提供的默认清单将 Elastic Agent 部署为 DaemonSet，这会导致在 Kubernetes 集群的每个节点上部署一个 Elastic Agent。

此外，默认情况下，会选举出一个 Agent 作为 领导者（有关更多信息，请访问 Kubernetes LeaderElection Provider）。持有领导锁的 Elastic Agent Pod 负责收集集群范围的指标以及其节点的指标。

以上模式解释了 Elastic Agent 如何收集指标并将其发送到 Elasticsearch。由于领导者 Agent 还负责收集集群级指标，这意味着它需要额外的资源。

具有领导者选举的 DaemonSet 部署方法简化了 Elastic Agent 的安装，因为我们在清单中定义的 Kubernetes 资源更少，并且我们只需要一个单一的 Agent 策略来管理我们的 Agent。因此，它是 托管的 Elastic Agent 安装 的默认支持方法

在 Agent 清单中指定资源和限制编辑

随着 Kubernetes 集群规模的增长，Pod 的资源分配和它们的调度优先级（查看部分 调度优先级）是两个可能受到影响的主题。不断增长的资源需求可能会导致集群的 Elastic Agent 资源不足。

根据我们的测试，我们建议仅在清单中的 resources 部分配置 limit 部分。这样，resources 的 request 设置将回退到指定的 limits。 limits 是微服务进程的上限，这意味着它可以在更少的资源中运行，并保护 Kubernetes 不分配更大的使用量，并防止潜在的资源耗尽。

resources:
    limits:
      cpu: "1500m"
      memory: "800Mi"

根据我们的 Elastic Agent 扩展测试，下表提供了调整不同 Kubernetes 规模的 Elastic Agent 限制的指南

示例 Elastic Agent 配置

针对大规模的建议 Agent 安装编辑

虽然 daemonset 安装很简单，但它无法适应根据收集的指标而变化的 Agent 资源需求。在大规模情况下，需要适当的资源分配，这需要更细粒度的安装方法。

Elastic Agent 部署分为以下几组

这些 Elastic Agent 组中的每一个都将拥有与其功能相关的特定策略，并且可以在相应的清单中独立地分配资源，以满足其特定的资源需求。

资源分配导致了替代安装方法。

以下 替代配置方法 已通过验证

您可以在名为 Elastic Agent 清单，以支持 Kube-State-Metrics 分片 的文档中找到更多信息。

根据我们的 Elastic Agent 扩展测试，下表旨在帮助用户了解如何在 Kubernetes 集群扩展时配置其 KSM 分片

Agent 调度编辑

将 Elastic Agent 的优先级设置为低于其他 Pod 的优先级也可能导致 Elastic Agent 处于 Pending 状态。调度程序会尝试抢占（驱逐）较低优先级的 Pod，以使更高优先级的 Pending Pod 的调度成为可能。

尝试在其他应用程序微服务之前优先考虑 Agent 安装，建议的 PriorityClasses

Kubernetes 包配置编辑

Kubernetes 包的策略配置会严重影响收集的指标数量，最终影响摄取的指标数量。为了使您的收集和摄取更轻量级，应该考虑以下因素

仪表板和可视化编辑

仪表板指南 文档提供了有关如何实现仪表板的指导，并且会不断更新以跟踪可观测性规模化的需求。

关于仪表板响应的用户体验也会受到请求数据大小的影响。由于仪表板可以包含多个可视化，因此一般考虑是根据访问频率拆分可视化并将它们分组。可视化数量越少，用户体验往往越好。

禁用索引 host.ip 和 host.mac 字段编辑

已引入一个新的环境变量 ELASTIC_NETINFO: false，用于全局禁用在 Kubernetes 集成中索引 host.ip 和 host.mac 字段。有关更多信息，请参见 环境变量。

建议在大型部署中将此设置为 false，因为 host.ip 和 host.mac 字段的索引大小会增加。随着 Kubernetes 集群的增长，报告的 IP 和 MAC 地址数量会显著增加。这会导致索引时间大幅增加，以及对额外存储和可视化渲染的额外开销的需求。

Elastic Stack 配置编辑

在大型部署中，需要考虑 Elastic Stack 的配置。对于 Elastic Cloud 部署，选择部署的 Elastic Cloud 硬件配置文件 非常重要。

对于需要大量处理和高数据摄入率的场景，建议使用 CPU-optimised 配置文件。

验证和故障排除实践编辑

确定代理是否按预期收集数据编辑

在部署 Elastic Agent 后，我们需要验证代理服务是否健康，没有重启（稳定性），以及指标收集是否以预期速率（延迟）进行。

对于稳定性

如果 Elastic Agent 被配置为托管的，您可以在 Kibana 中的 Fleet>Agents 下观察。

此外，您可以使用以下命令验证进程状态

kubectl get pods -A | grep elastic
kube-system   elastic-agent-ltzkf                        1/1     Running   0          25h
kube-system   elastic-agent-qw6f4                        1/1     Running   0          25h
kube-system   elastic-agent-wvmpj                        1/1     Running   0          25h

查找领导者代理

❯ k get leases -n kube-system | grep elastic
NAME                                      HOLDER                                                                       AGE
elastic-agent-cluster-leader   elastic-agent-leader-elastic-agent-qw6f4                                     25h

执行到领导者代理并验证进程状态

❯ kubectl exec -ti -n kube-system elastic-agent-qw6f4 -- bash
root@gke-gke-scaling-gizas-te-default-pool-6689889a-sz02:/usr/share/elastic-agent# ./elastic-agent status
State: HEALTHY
Message: Running
Fleet State: HEALTHY
Fleet Message: (no message)
Components:
  * kubernetes/metrics  (HEALTHY)
                        Healthy: communicating with pid '42423'
  * filestream          (HEALTHY)
                        Healthy: communicating with pid '42431'
  * filestream          (HEALTHY)
                        Healthy: communicating with pid '42443'
  * beat/metrics        (HEALTHY)
                        Healthy: communicating with pid '42453'
  * http/metrics        (HEALTHY)
                        Healthy: communicating with pid '42462'

随着 Kubernetes 规模的增长，代理进程重启是一个常见的 CPU/内存资源不足问题。在代理的日志中，您

kubectl logs -n kube-system elastic-agent-qw6f4 | grep "kubernetes/metrics"
[ouptut truncated ...]

(HEALTHY->STOPPED): Suppressing FAILED state due to restart for '46554' exited with code '-1'","log":{"source":"elastic-agent"},"component":{"id":"kubernetes/metrics-default","state":"STOPPED"},"unit":{"id":"kubernetes/metrics-default-kubernetes/metrics-kube-state-metrics-c6180794-70ce-4c0d-b775-b251571b6d78","type":"input","state":"STOPPED","old_state":"HEALTHY"},"ecs.version":"1.6.0"}
{"log.level":"info","@timestamp":"2023-04-03T09:33:38.919Z","log.origin":{"file.name":"coordinator/coordinator.go","file.line":861},"message":"Unit state changed kubernetes/metrics-default-kubernetes/metrics-kube-apiserver-c6180794-70ce-4c0d-b775-b251571b6d78 (HEALTHY->STOPPED): Suppressing FAILED state due to restart for '46554' exited with code '-1'","log":{"source":"elastic-agent"}

您可以通过运行 top pod 命令来验证即时资源消耗，并确定代理是否接近您在清单中指定的限制。

kubectl top pod  -n kube-system | grep elastic
NAME                                                             CPU(cores)   MEMORY(bytes)
elastic-agent-ltzkf                                              30m          354Mi
elastic-agent-qw6f4                                              67m          467Mi
elastic-agent-wvmpj                                              27m          357Mi

验证摄入延迟编辑

Kibana 发现可以用来识别指标的摄入频率。

过滤 Pod 数据集

过滤 State_Pod 数据集

识别已发送到 Elasticsearch 的事件数量

kubectl logs -n kube-system elastic-agent-h24hh -f | grep -i state_pod
[ouptut truncated ...]

"state_pod":{"events":2936,"success":2936}

事件数量表示应在 Kibana 发现页面中显示的文档数量。

确定 Elasticsearch 是否是摄入的瓶颈编辑

在某些情况下，Elasticsearch 可能无法处理试图摄入的数据速率。为了验证资源利用率，建议安装一个 Elastic Stack 监控集群。

此外，在 Elastic Cloud 部署中，您可以导航到 管理部署 > 部署 > 监控 > 性能。与 CPU 使用率、索引响应时间 和 内存压力 相关的仪表盘可以揭示潜在问题并建议垂直扩展 Elastic Stack 资源。