集群服务

集群服务在 EKS 集群内运行，但它们不是用户工作负载。如果您使用的是 Linux 服务器，则通常需要运行 NTP、syslog 和容器运行时等服务来支持您的工作负载。集群服务类似，支持服务可帮助您实现集群的自动化和运营。在 Kubernetes 中，它们通常在 kube-system 命名空间中运行，有些则以 kube-system 命名空间运行。DaemonSets

集群服务预计会有较长的正常运行时间，并且在停机期间和故障排除时通常至关重要。如果核心群集服务不可用，您可能会无法访问有助于恢复或防止中断的数据（例如磁盘利用率高）。它们应在专用计算实例（例如单独的节点组或 AWS Fargate）上运行。这将确保共享实例上的集群服务不会受到可能正在扩展或使用更多资源的工作负载的影响。

扩展 CoreDNS

扩展 CoreDNS 有两种主要机制。减少对 CoreDNS 服务的调用次数并增加副本数量。

通过降低 ndots 来减少外部查询

ndots 设置指定域名中有多少句点（又名 “点”）被认为足以避免查询 DNS。如果您的应用程序的 ndots 设置为 5（默认），并且您从外部域（例如 api.example.com）请求资源（2 个点），则系统将针对/etc/resolv.conf 中为更具体的域名定义的每个搜索域查询 CoreDNS。默认情况下，在发出外部请求之前将搜索以下域。

api.example.<namespace>.svc.cluster.local
api.example.svc.cluster.local
api.example.cluster.local
api.example.<region>.compute.internal

namespace和region值将替换为您的工作负载命名空间和计算区域。根据您的集群设置，您可能还有其他搜索域。

您可以通过降低工作负载的 nd ots 选项来减少 CoreDNS 的请求数量，或者通过添加尾随来完全限定域名请求。 （例如api.example.com.）。如果您的工作负载通过 DNS 连接到外部服务，我们建议将 ndots 设置为 2，这样工作负载就不会在集群内进行不必要的集群 DNS 查询。如果工作负载不需要访问集群内部的服务，则可以设置不同的 DNS 服务器和搜索域。

spec:
  dnsPolicy: "None"
  dnsConfig:
    options:
      - name: ndots
        value: "2"
      - name: edns0

如果您将 ndots 降低到过低的值，或者您要连接的域名不包括足够的特异性（包括尾随字符。），那么 DNS 查找可能会失败。请务必测试此设置将如何影响您的工作负载。

水平扩展 CoreDNS

CoreDNS 实例可以通过向部署中添加其他副本来进行扩展。建议您使用 NodeLocal DNS 或集群比例自动扩缩器来扩展 CoreDNS。

NodeLocal DNS 将要求每个节点运行一个实例， DaemonSet这需要集群中的更多计算资源，但它可以避免 DNS 请求失败并缩短集群中 DNS 查询的响应时间。集群比例自动扩缩器将根据集群中的节点或内核数量扩展 CoreDNS。这与请求查询没有直接关系，但根据您的工作负载和集群大小，这可能会很有用。默认的比例比例是为集群中每 256 个内核或 16 个节点添加一个额外的副本，以先发生者为准。

垂直扩展 Kubernetes 指标服务器

Kubernetes 指标服务器支持水平和垂直扩展。通过水平扩展 Metrics Server，它将具有很高的可用性，但它不会水平扩展以处理更多的集群指标。将节点和收集的指标添加到集群后，您需要根据指标服务器的建议垂直扩展。

指标服务器将其收集、聚合和提供的数据保存在内存中。随着集群的增长，Metrics Server 存储的数据量也随之增加。在大型集群中，Metrics Server 需要的计算资源将超过默认安装中指定的内存和 CPU 预留量。你可以使用 Vertic al Pod Autoscaler (VPA) 或 Addon Resizer 来扩展 Metrics Server。Addon Resizer 根据工作节点成比例垂直扩展，VPA 基于 CPU 和内存使用率进行扩展。

CoreDNS lameduck 时长

Pod 使用该kube-dns服务进行名称解析。Kubernetes 使用目标 NAT (DNAT) 将kube-dns流量从节点重定向到 CoreDNS 后端容器。在扩展 CoreDNS 部署时，会更新节点上的 iptables 规则和链kube-proxy，将 DNS 流量重定向到 CoreDNS 容器。向上扩展时传播新的终端节点和缩小规模 CoreDNS 时删除规则可能需要 1 到 10 秒的时间，具体取决于集群的大小。

当 CoreDNS 容器被终止但该节点的 iptables 规则尚未更新时，这种传播延迟可能会导致 DNS 查找失败。在这种情况下，该节点可能会继续向已终止的 CoreDNS 容器发送 DNS 查询。

你可以通过在 CoreDNS 容器中设置 l ameduck 时长来减少 DNS 查询失败。在 lameduck 模式下，Coredns 将继续响应机上请求。设置 lameduck 持续时间会延迟 CoreDNS 的关闭过程，从而让节点有时间更新 iptables 规则和链。

我们建议将 CoreDNS lameduck 持续时间设置为 30 秒。

CoreDNS 就绪情况调查

我们建议使用/ready代替CoreDNS的就绪性探测。/health

与之前提出的将lameduck持续时间设置为30秒的建议，为节点的iptables规则在吊舱终止之前提供充足的时间进行更新，使用/ready而不是用于CoreDNS就绪探测可确保CoreDNS容器在启动时做好充分准备，可以迅速响应DNS请求。/health

readinessProbe:
  httpGet:
    path: /ready
    port: 8181
    scheme: HTTP

有关 CoreDNS Ready 插件的更多信息，请参阅 https://coredns。 io/plugins/ready/

记录和监视代理

日志和监控代理可能会给集群控制平面增加大量负载，因为代理会查询 API 服务器以使用工作负载元数据丰富日志和指标。节点上的代理只能访问本地节点资源来查看容器和进程名称之类的内容。查询 API 服务器可以添加更多详细信息，例如 Kubernetes 部署名称和标签。这对于故障排除非常有用，但不利于扩展。

由于有许多不同的日志和监控选项，因此我们无法为每个提供商展示示例。在 f luentbi t 中，我们建议启用 Use_Kubelet 从本地 kubelet 而不是 Kubernetes API 服务器获取元数据，并将其设置为Kube_Meta_Cache_TTL一个在可以缓存数据时减少重复调用的数字（例如 60）。

扩展监控和日志记录有两个常规选项：

• 禁用集成

• 采样和过滤

禁用集成通常不是一种选择，因为您会丢失日志元数据。这消除了 API 扩展问题，但由于在需要时没有所需的元数据，还会带来其他问题。

采样和过滤可以减少收集的指标和日志的数量。这将减少对 Kubernetes API 的请求量，并减少收集的指标和日志所需的存储量。降低存储成本将降低整个系统的成本。

配置采样的能力取决于代理软件，可以在不同的摄取点实现。在尽可能靠近代理的地方添加采样很重要，因为这可能是 API 服务器调用发生的地方。请联系您的提供商，了解有关采样支持的更多信息。

如果您使用的是 CloudWatch 和 CloudWatch 日志，则可以使用文档中描述的模式添加代理筛选。

为避免丢失日志和指标，您应将数据发送到能够缓冲数据的系统，以防接收端点出现故障。有了 fluentbit，你可以使用 Amazon Kinesis Data Firehose 来临时保留数据，从而减少最终数据存储位置过载的机会。