修复Amazon EKS集群中的DataDog代理拥塞问题 [英] Fixing DataDog agent congestion issues in Amazon EKS cluster

问题描述

几个月前，我使用DaemonSet配置将DataDog集成到我的Kubernetes集群中。从那以后，我一直收到拥堵警报，消息如下：

请调整热拍设置 https://github.com/brightcove/hot-shots#errors

通过尝试以我有限的编排/DevOps知识遵循文档，我可以收集到的是我需要将以下内容添加到我的DaemonSet配置中：

spec
.
.
  securityContext:
        sysctls:
          - name: net.unix.max_dgram_qlen
            value: "1024"
          - name: net.core.wmem_max
            value: "4194304"

我尝试将该配置片段直接添加到其中一个自动部署的DataDog Pod中，只是为了尝试一下，但它无限期挂起并且没有保存配置(而不是添加到DaemonSet并冒着关闭所有代理的风险)。

该热点文档还提到，上述sysctl配置要求在包含Pod的节点中启用不安全的sysctls：

kubelet --allowed-unsafe-sysctls 
  'net.unix.max_dgram_qlen, net.core.wmem_max'

我正在使用的群集通过使用AWS中的仪表板完全部署了EKS(对它的配置知之甚少)。上述情况似乎适用于手动部署和管理的群集。

• 为什么我尝试应用于单个DataDog代理Pod的配置不保存/应用？是因为它由DaemonSet管理，还是因为它没有适当的unsafe sysctl允许？还有别的吗？
• 如果我需要在我的集群的所有节点上启用建议的unsafe sysctl。既然该集群已由Amazon EKS完全部署和管理，我该如何着手？

推荐答案

所以我们设法通过使用带有托管节点组的自定义启动模板，然后传递一个自定义引导脚本来实现这一点。然而，这确实意味着您需要自己提供AMIID，并在它过期时丢失控制台中的警报。在Terraform中，它将如下所示：

resource "aws_eks_node_group" "group" {
  ...
  launch_template {
    id      = aws_launch_template.nodes.id
    version = aws_launch_template.nodes.latest_version
  }
  ...
}

data "template_file" "bootstrap" {
  template = file("${path.module}/files/bootstrap.tpl")
  vars = {
    cluster_name        = aws_eks_cluster.cluster.name
    cluster_auth_base64 = aws_eks_cluster.cluster.certificate_authority.0.data
    endpoint            = aws_eks_cluster.cluster.endpoint
  }
}

data "aws_ami" "eks_node" {
  owners      = ["602401143452"]
  most_recent = true

  filter {
    name   = "name"
    values = ["amazon-eks-node-1.21-v20211008"]
  }
}

resource "aws_launch_template" "nodes" {
  ...
  image_id = data.aws_ami.eks_node.id
  user_data = base64encode(data.template_file.bootstrap.rendered)
  ...
}

则bootstrap.hcl文件如下所示：

#!/bin/bash

set -o xtrace

systemctl stop kubelet
/etc/eks/bootstrap.sh '${cluster_name}' 
  --b64-cluster-ca '${cluster_auth_base64}' 
  --apiserver-endpoint '${endpoint}' 
  --kubelet-extra-args '"--allowed-unsafe-sysctls=net.unix.max_dgram_qlen"'

下一步是在您的群集中设置PodSecurityPolicy、ClusterRole和RoleBinding，以便您可以如上所述使用securityContext，然后该命名空间中的Pod将能够在没有SysctlForbidden消息的情况下运行。

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: sysctl
spec:
  allowPrivilegeEscalation: false
  allowedUnsafeSysctls:
  - net.unix.max_dgram_qlen
  defaultAllowPrivilegeEscalation: false
  fsGroup:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  volumes:
  - '*'

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: allow-sysctl
rules:
- apiGroups:
  - policy
  resourceNames:
  - sysctl
  resources:
  - podsecuritypolicies
  verbs:
  - '*'

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: allow-sysctl
  namespace: app-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: allow-sysctl
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:serviceaccounts:app-namespace

如果使用DataDog Helm图表，则可以设置以下值以更新代理的securityContext。但您必须手动更新图表PSP才能设置allowedUnsafeSysctls

datadog:
  securityContext:
    sysctls:
      - name: net.unix.max_dgram_qlen"
        value: 512"

这篇关于修复Amazon EKS集群中的DataDog代理拥塞问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！