在 Kubernetes 上扩展 Elastic Agent

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

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

本文档分为两个主要部分

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

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

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

此外，默认情况下，一个 agent 被选为 领导者（有关更多信息，请访问 Kubernetes LeaderElection 提供程序）。拥有领导权锁的 Elastic Agent Pod 除了其节点的指标外，还负责收集集群范围的指标。

上面的架构说明了 Elastic Agent 如何收集指标并将其发送到 Elasticsearch。由于领导者 Agent 也负责收集集群级别的指标，这意味着它需要额外的资源。

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

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

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

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

根据我们的 Elastic Agent 扩展测试，下表提供了有关在不同 Kubernetes 大小上调整 Elastic Agent 限制的指南

示例 Elastic Agent 配置

尽管 daemonset 安装很简单，但它无法适应因收集的指标而异的 agent 资源需求。大规模适当资源分配的需求需要更细粒度的安装方法。

Elastic Agent 部署分为以下几组

每个 Elastic Agent 组都将具有其特定于其功能的策略，并且可以在适当的清单中独立设置资源，以适应其特定的资源需求。

资源分配使我们找到了替代的安装方法。

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

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

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

与其他 pod 相比，将 Elastic Agent 设置为低优先级也可能导致 Elastic Agent 处于 Pending 状态。调度程序尝试抢占（驱逐）较低优先级的 Pod，以使较高挂起的 Pod 可以进行调度。

尝试在其余应用程序微服务之前优先安装 agent，建议使用 PriorityClasses

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

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

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

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

对于 host.ip 和 host.mac 字段的索引大小增加的大规模设置，建议将其设置为 false。随着 Kubenetes 集群的增长，报告的 IP 和 MAC 地址的数量会显着增加。这会导致索引时间显着增加，以及需要额外的存储和可视化渲染的额外开销。

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

对于繁重的处理和大摄取率需求，建议使用 CPU 优化配置文件。

在 Elastic Agent 部署之后，我们需要验证 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

查找领导 Agent

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

进入领导 Agent 并验证进程状态

❯ 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 规模的增长，Agent 进程因缺乏 CPU/内存资源而重启是一个常见问题。在 Agent 的日志中

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 命令来验证即时资源消耗，并确定 Agent 是否接近您在清单中指定的限制。

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 Discovery 来识别您的指标被摄取的频率。

筛选 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 Discovery 页面中显示的文件数量。

在某些情况下，Elasticsearch 可能无法应对尝试摄取的数据速率。为了验证资源利用率，建议安装 Elastic Stack 监控集群。

此外，在 Elastic Cloud 部署中，您可以导航到 Manage Deployment > Deployments > Monitoring > Performance。 CPU Usage、Index Response Times 和 Memory Pressure 的相应仪表板可以揭示潜在的问题，并建议对 Elastic Stack 资源进行垂直扩展。