在 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 Provider）。持有领导锁的 Elastic Agent Pod 负责除了其节点指标之外还收集集群范围的指标。

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

带有领导者选举的 DaemonSet 部署方法简化了 Elastic Agent 的安装，因为我们在清单中定义的 Kubernetes 资源更少，并且我们只需要一个单一的 Agent 策略即可。因此，它是 托管 Elastic 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 配置示例

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

Elastic Agent 部署被划分为以下几组：

每组 Elastic Agent 都有其自己的特定于其功能的策略，并且可以在相应的清单中独立配置资源，以适应其特定的资源需求。

资源分配促使我们采用替代安装方法。

以下 替代配置方法 已得到验证：

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

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

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

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

Kubernetes 包的策略配置会严重影响收集和最终摄取的指标数量。应考虑以下因素以减轻收集和摄取的工作量：

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

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

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

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

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

对于高处理量和高数据摄入率的需求，建议使用CPU优化配置。

Elastic Agent部署后，我们需要验证Agent服务是否健康，没有重启（稳定性），并且指标收集以预期的速率继续（延迟）。

关于稳定性

如果Elastic Agent配置为托管模式，您可以在Kibana中集群 > 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 Discover可以用来识别指标的摄入频率。

过滤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 Discover页面中应显示的文档数量。

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

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