本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 集群服务
集群服务在 EKS 集群内运行，但它们不是用户工作负载。如果您有 Linux 服务器，则通常需要运行 NTP、syslog 和容器运行时等服务来支持您的工作负载。集群服务与之类似，支持服务可帮助您实现集群的自动化和运营。在 Kubernetes 中，它们通常在 kube-system 命名空间中运行，有些则以 kube-system 的身份运行。[ DaemonSets ](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)
集群服务预计会有较长的正常运行时间，通常在中断期间和故障排除中起到至关重要的作用。如果核心群集服务不可用，您可能会无法访问有助于恢复或防止停机（例如高磁盘利用率）的数据。它们应在专用计算实例上运行，例如单独的节点组或 AWS Fargate。这将确保集群服务不受可能向上扩展或使用更多资源的工作负载对共享实例的影响。
## 扩展 CoreDNS
扩展 CoreDNS 有两种主要机制。减少对 CoreDNS 服务的调用次数并增加副本的数量。
### 通过降低 ndots 来减少外部查询
ndots 设置指定域名中有多少句点（又称 “点”）被视为足以避免查询 DNS。如果您的应用程序的 ndots 设置为 5（默认），并且您从 api.example.com（2 个点）等外部域名请求资源，则将针对在 /.conf 中定义的每个搜索域查询 CoreDNS 以查找更具体的域。etc/resolv默认情况下，在发出外部请求之前，将搜索以下域名。
```
api.example..svc.cluster.local
api.example.svc.cluster.local
api.example.cluster.local
api.example..compute.internal
```
`namespace`和`region`值将替换为您的工作负载命名空间和计算区域。根据您的集群设置，您可能还有其他搜索域。
您可以通过[降低工作负载的 ndots 选项来减少对 CoreDNS ](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-dns-config) 的请求数量，或者通过添加尾随来完全限定域名请求。（例如`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 ](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/) 或[集群比例自动扩缩器](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler)来扩展 CoreDNS。
NodeLocal DNS 将要求每个节点运行一个实例， DaemonSet即集群中需要更多的计算资源，但它可以避免 DNS 请求失败并缩短集群中 DNS 查询的响应时间。集群比例自动扩缩器将根据集群中的节点或内核数量扩展 CoreDNS。这与请求查询没有直接关系，但根据您的工作负载和集群大小可能很有用。默认的比例比例是为集群中每 256 个内核或 16 个节点添加一个额外的副本，以先发生者为准。
如果使用 [ CoreDNS EKS 插件](https://docs.aws.amazon.com/eks/latest/userguide/managing-coredns.html)，请考虑启用[自动](https://docs.aws.amazon.com/eks/latest/userguide/coredns-autoscaling.html)缩放选项。CoreDNS 自动扩缩器通过监控节点数和 CPU 内核来动态调整 CoreDNS 副本的数量，使用最大值（节点 ÷ 16）或（CPU 内核/256）的公式，在需要时立即向上扩展，逐渐向下扩展以保持稳定性。
## 垂直扩展 Kubernetes 指标服务器
Kubernetes 指标服务器支持水平和垂直扩展。通过水平扩展 Metrics Server，它将具有很高的可用性，但不会横向扩展以处理更多的集群指标。当节点和收集的指标添加到集群[时，您将需要根据](https://kubernetes-sigs.github.io/metrics-server/#scaling)指标服务器的建议垂直扩展。
指标服务器将其收集、聚合和提供的数据保存在内存中。随着集群的增长，指标服务器存储的数据量也会增加。在大型群集中，Metrics Server 需要比默认安装中指定的内存和 CPU 预留更多的计算资源。您可以使用[垂直容器自动缩放器 ](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler) (VPA) 或 [ Addon Resizer ](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer) 来扩展 Metrics Server。插件调整器根据工作节点的比例垂直扩展，VPA 根据 CPU 和内存使用情况进行扩展。
## CoreDNS lameduck 持续时间
Pod 使用该`kube-dns`服务进行名称解析。Kubernetes 使用目标 NAT (DNAT) 将`kube-dns`流量从节点重定向到 CoreDNS 后端 pod。在扩展 CoreDNS 部署时，`kube-proxy`更新节点上的 iptables 规则和链，将 DNS 流量重定向到 CoreDNS 容器。在向上扩展时传播新的终端节点，在向下扩展时删除规则 CoreDNS 可能需要 1 到 10 秒，具体取决于集群的大小。
当 CoreDNS 容器终止但节点的 iptables 规则尚未更新时，这种传播延迟可能会导致 DNS 查询失败。在这种情况下，该节点可以继续向已终止的 CoreDNS Pod 发送 DNS 查询。
您可以通过在 CoreDNS 容器中设置 l [ ameduck ](https://coredns.io/plugins/health/) 持续时间来减少 DNS 查询失败次数。在 lameduck 模式下，CoreDNS 将继续响应飞行中的请求。设置 lameduck 持续时间将延迟 CoreDNS 的关闭过程，从而让节点有时间更新其 iptables 规则和链。
我们建议将 CoreDNS lameduck 的持续时间设置为 30 秒。
## CoreDNS 就绪情况调查
我们建议使用`/ready`而不是 Cor `/health` eDNS 的就绪情况调查。
与先前提出的将 lameduck 持续时间设置为 30 秒的建议一致，为节点的 iptables 规则在 pod 终止之前更新提供充足的时间，使用`/ready`代替 CoreDNS 就绪探测器可确保 CoreDNS 容器在启动时做好充分准备，可以迅速响应 DNS 请求。`/health`
```
readinessProbe:
httpGet:
path: /ready
port: 8181
scheme: HTTP
```
有关 CoreDNS Ready 插件的更多信息，请参阅 https://coredns.io/plugins/ready/
## 记录和监控代理
日志记录和监控代理会给您的群集控制平面增加大量负载，因为代理会查询 API 服务器以使用工作负载元数据丰富日志和指标。节点上的代理只能访问本地节点资源才能查看容器和进程名称等内容。查询 API 服务器时，它可以添加更多详细信息，例如 Kubernetes 部署名称和标签。这对于故障排除非常有用，但不利于扩展。
由于有许多不同的记录和监控选项，因此我们无法为每个提供商显示示例。使用 f [ luentbit，](https://docs.fluentbit.io/manual/pipeline/filters/kubernetes)我们建议启用 Use\_Kubelet 从本地 kubelet 而不是 Kubernetes API 服务器获取元数据的功能，并设置为一个`Kube_Meta_Cache_TTL`能够在数据缓存时减少重复调用的数字（例如 60）。
扩展监控和日志记录有两个常规选项：
+ 禁用集成
+ 采样和过滤
禁用集成通常不是一个选项，因为你会丢失日志元数据。这消除了 API 扩展问题，但会因为在需要时没有所需的元数据而引入其他问题。
采样和筛选减少了收集的指标和日志的数量。这将减少对 Kubernetes API 的请求量，并将减少收集的指标和日志所需的存储量。降低存储成本将降低整个系统的成本。
配置采样的能力取决于代理软件，可以在不同的摄取点实现。在尽可能靠近代理的地方添加采样非常重要，因为这很可能是 API 服务器调用发生的地方。请联系您的提供商，了解有关采样支持的更多信息。
如果您使用 CloudWatch 和 CloudWatch 日志，则可以使用文档中[描述的模式添加代理筛选](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html)。
为避免丢失日志和指标，您应将数据发送到可以缓冲数据的系统，以防接收端点出现故障。有了 fluentbit，你可以使用[亚马逊 Kinesis Data Firehose ](https://docs.fluentbit.io/manual/pipeline/outputs/firehose) 来临时保留数据，这样可以减少最终数据存储位置过载的可能性。