17个应该了解的Kubernetes优化

云云众生s

发布于 2024-03-28 14:56:00

930

发布于 2024-03-28 14:56:00

Kubernetes 持续发展，提供可以显著增强集群性能、效率和安全性的新功能和优化。对于高级工程师，掌握这些优化可以带来更强大、更可扩展且更具成本效益的部署。以下是 18 个高级 Kubernetes 节点优化的精选列表，按其在 2024 年的预期实用性和受欢迎程度排序。

译自 13 Kubernetes Node Optimizations You Should Know in 2024，作者 DavidW (skyDragon)。

1. 优化镜像大小

大容器镜像会导致更长的拉取时间、更慢的 Pod 启动以及增加的网络和存储资源消耗。优化镜像大小可以显著提高部署效率和应用程序可扩展性。

如何优化

使用多阶段构建：Docker 中的多阶段构建允许你将构建环境与运行时环境分开，只在最终镜像中包含必要的工件。

# Build stage
FROM golang:1.16 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp .

# Final stage
FROM alpine:latest  
COPY --from=builder /app/myapp .
ENTRYPOINT ["./myapp"]

选择更精简的基础镜像：Alpine Linux 等基础镜像提供最小的占用空间。迁移到此类镜像可以大幅减小容器镜像的整体大小。

最佳实践

定期扫描镜像以查找可以删除的未使用层或依赖项。
在适当的情况下利用镜像压缩工具和技术。

应避免的陷阱

过度优化可能会导致运行时问题，如果删除了必要的包或库。确保对经过优化的镜像进行彻底测试。

进一步阅读

Docker 多阶段构建：https://docs.docker.com/develop/develop-images/multistage-build/
选择 Docker 基础镜像：https://hub.docker.com/_/alpine

2. 清理未使用的镜像

未使用的容器镜像会消耗节点上的宝贵磁盘空间，可能导致影响新部署和 Kubernetes 集群整体运行状况的资源限制。

清理策略

手动清理：Kubernetes 不会自动清理未使用的镜像。通过docker image prune或 Kubernetes 作业进行手动清理可以回收空间。

docker image prune -a --filter "until=168h"

此命令删除所有未被任何容器引用的镜像，且时间超过一周。
自动化清理工具：kube-janitor 等工具可以自动清理未使用的资源，包括镜像。

最佳实践

在非高峰时段安排定期清理，以最大程度地减少对集群性能的影响。
实施监控以对磁盘空间阈值发出警报，根据需要触发清理。

应避免的陷阱

确保不要删除不经常使用但仍然必要的镜像，这可能会导致不必要的镜像拉取操作。

进一步阅读

Docker 清理：https://docs.docker.com/config/pruning/

3. 节点亲和性和反亲和性

节点亲和性和反亲和性是 Kubernetes 中的强大功能，可以对 Pod 在集群中的放置位置进行精细控制。这些功能对于优化资源利用、确保高可用性以及在不同工作负载之间强制分离关注点至关重要。让我们深入了解它们的功能、用例以及如何在 Kubernetes 部署中有效实施这些策略。

了解节点亲和性

节点亲和性允许你指定规则，将 Pod 的放置限制在具有特定标签的节点上。这对于特定工作负载需要具有特定特征的节点（例如特定硬件或软件配置）的情况特别有用。

节点亲和性的类型

RequiredDuringSchedulingIgnoredDuringExecution：Pod 在调度时必须满足亲和性规则，但如果由于节点的变化导致规则不再满足，则不会驱逐 Pod。
PreferredDuringSchedulingIgnoredDuringExecution：调度程序尝试满足亲和性规则，但不保证。

实施节点亲和性

以下示例演示如何使用节点亲和性将 Pod 调度到标记为disktype=ssd的节点上，确保这些 Pod 受益于 SSD 存储的性能特征。

apiVersion: v1
kind: Pod
metadata:
  name: ssd-affinity-pod
spec:
  containers:
  - name: nginx
    image: nginx
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd

了解反亲和性

虽然节点亲和性将 Pod 吸引到具有特定标签的节点，但节点反亲和性将 Pod 从具有特定标签的节点中排斥出去，或确保 Pod 不与具有特定特征的其他 Pod 放置在同一节点上。这对于通过在不同的故障域中分布 Pod 来维护高可用性和灾难恢复协议至关重要。

实现节点反亲和性

以下代码段说明了如何使用节点反亲和性来避免在同一节点上调度 Pod，如果它们被标记为 app=frontend，通过将它的实例分散在不同的节点上，增强前端服务的弹性。

apiVersion: v1
kind: Pod
metadata:
  name: frontend-pod
spec:
  containers:
  - name: frontend
    image: frontend-image
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - frontend
        topologyKey: "kubernetes.io/hostname"

高级用例

地理分布：使用节点亲和性在位于特定地理区域的节点上调度 Pod，以遵守数据主权法或减少区域用户的延迟。
工作负载分离：利用反亲和性规则将敏感工作负载与安全性较低的工作负载分离，增强安全态势。
资源优化：在高性能节点上调度计算密集型应用程序，而要求较低的服务可以在标准节点上运行，优化资源使用和成本。

最佳实践

在受限环境中使用软亲和性（preferredDuringSchedulingIgnoredDuringExecution）以避免不可调度的 Pod。
与 Pod 反亲和性结合使用以分散类似的 Pod，增强容错性。

应避免的陷阱

过于严格的亲和性规则会导致 Pod 调度失败，尤其是在具有异构节点的集群中。

4. 用于工作负载分离的污点和容忍

污点和容忍提供了一种强大的机制来控制节点上的 Pod 放置，确保只有容忍特定污点的 Pod 才能在被污染的节点上调度。此功能对于隔离工作负载至关重要，尤其是在多租户环境中或特定节点专用于特定任务时。

实现污点和容忍

对节点应用污点：

kubectl taint nodes node1 key=value:NoSchedule

此命令对 node1 应用污点，防止 Pod 在此节点上调度，除非它们具有匹配的容忍度。

在 Pod 中定义容忍度：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: myimage
  tolerations:
  - key: "key"
    operator: "Equal"
    value: "value"
    effect: "NoSchedule"

此 Pod 规范包括与 node1 上的污点匹配的容忍度，允许它在那里调度。

用例

专用硬件：通过对这些节点应用污点，确保只有特定的 Pod 可以在具有专用硬件（例如 GPU）的节点上调度。
敏感工作负载：通过污染节点并向敏感 Pod 添加相应的容忍度来隔离敏感工作负载，增强安全性和合规性。

应避免的陷阱

过度污染：应用过多的污点会导致复杂的调度挑战和资源利用不足。
容忍度不匹配：确保 Pod 中的容忍度正确匹配节点上的污点，以防止意外的调度问题。

5. 用于 Pod 平衡的 Descheduler

Descheduler 是一个外部组件，它根据当前的调度策略和集群状态帮助优化集群中的 Pod 放置。它驱逐违反新更新策略或可以更好地放置在其他节点上的 Pod，从而提高整体集群效率和资源利用率。

实现 Descheduler

Descheduler 需要一个策略配置来确定要驱逐哪些 Pod。以下是一个示例策略，用于驱逐 Pod 以实现更好的平衡：

apiVersion: "k8s.descheduler.io/v1alpha1"
kind: "DeschedulerPolicy"
strategies:
  "LowNodeUtilization":
    enabled: true
    params:
      nodeResourceUtilizationThresholds:
        thresholds:
          cpu: 20
          memory: 20
          pods: 20
        targetThresholds:
          cpu: 50
          memory: 50
          pods: 50

此策略旨在平衡节点利用率，将 Pod 从利用率低节点驱逐到利用率目标较高的节点。

用例

资源优化：定期在节点之间平衡 Pod 以确保最佳资源利用。
亲和性/反亲和性调整：重新平衡 Pod 以遵守在初始调度期间未应用的更新的亲和性/反亲和性规则。

应避免的陷阱

关键工作负载中断：使用 Pod 中断预算和仔细的策略配置来防止 Descheduler 驱逐关键工作负载。
过度 Pod 驱逐：避免过于激进的 Descheduler 策略，这可能导致频繁的 Pod 驱逐，从而导致不稳定。

6. 针对增强网络性能的内核调优

内核参数调优允许系统管理员优化其 Kubernetes 节点的网络性能。对 Linux 内核设置的调整可以显著提高吞吐量并降低延迟，这对网络密集型应用程序至关重要。

实施内核调优

调整网络缓冲区：增加网络缓冲区的大小有助于容纳大量流量，从而减少丢包和延迟。

sysctl -w net.core.rmem_max=26214400
sysctl -w net.core.wmem_max=26214400

增加最大打开文件描述符数：高性能服务器可能需要比默认限制更多的打开文件描述符。

sysctl -w fs.file-max=100000

使用案例

高性能 Web 应用程序：减少 TCP 堆栈延迟并增加缓冲区大小可以带来更流畅、更快的 Web 应用程序性能。
数据密集型工作负载：传输大量数据的应用程序受益于优化的网络吞吐量和减少的传输时间。

应避免的陷阱

过度优化：过大的缓冲区大小会导致资源浪费，并可能降低整体系统性能。
缺乏测试：内核参数的更改应在负载下进行测试，以确保它们具有所需的效应而不会产生不利影响。

最佳实践

增量更改：逐步应用更改并监控其影响，以找到最佳设置。
文档和版本控制：保留更改文档，并对应用这些设置的脚本使用版本控制，以确保可重现性和责任制。

7. 自定义 Kubelet 垃圾回收策略

垂直 Pod 自动伸缩器 (VPA) 根据历史使用数据自动调整 Kubernetes 集群中 Pod 的 CPU 和内存预留，确保 Pod 拥有所需的资源，而不会浪费资源。

实施 VPA

安装 VPA：VPA 安装在集群中，并要求为其应管理的每个应用程序定义一个 VPA 对象。

apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: myapp-vpa spec: targetRef: apiVersion: "apps/v1" kind: Deployment name: myapp updatePolicy: updateMode: "Auto"

此 VPA 对象自动调整 myapp 部署的资源请求。

使用案例

动态工作负载：随着时间的推移，资源需求不断变化的工作负载受益于 VPA，因为它会调整资源以满足当前需求。
内存密集型应用程序：VPA 有助于自动扩展具有零星内存消耗模式的应用程序的内存资源。

应避免的陷阱

忽略初始请求：最初将资源设置得太低可能会导致 Pod 被 OOMKilled，如果 VPA 无法足够快地调整资源。
过度依赖 VPA：VPA 不应成为性能调优的唯一解决方案；特定于应用程序的优化也至关重要。

最佳实践

监控和警报：实施全面的监控和警报，以快速识别 VPA 调整问题。
在暂存环境中测试：在生产环境中启用 VPA 之前，在暂存环境中测试其效果，以确保其按预期行为。

8. 使用 Cilium 实现细粒度网络策略

Cilium 是 Kubernetes 的 CNI（容器网络接口）插件，提供高级网络功能，包括细粒度网络策略、负载均衡和加密。它利用 eBPF（扩展 Berkeley 数据包过滤器）技术来提供高度可扩展和安全的网络策略。

实施 Cilium

安装 Cilium：Cilium 可以通过 Helm 图表或基于操作员的部署安装在 Kubernetes 集群中。

helm install cilium cilium/cilium --version <version> --namespace kube-system

定义网络策略：Cilium 允许您定义网络策略，这些策略可以根据标签、命名空间甚至应用程序协议控制 Pod 级别的入站和出站流量。

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "restrictive-policy"
spec:
  endpointSelector:
    matchLabels:
      app: myapp
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: database

使用案例

微服务安全性：通过定义基于标签限制服务之间流量的策略来保护微服务架构。
多租户隔离：通过隔离不同租户命名空间之间的网络流量来增强多租户环境中的安全性。
复杂策略管理：随着微服务数量的增长，管理单个网络策略可能会变得复杂。利用 Cilium 的能力对策略进行分组，以便更轻松地进行管理。
重叠策略：确保明确的优先级和非冲突策略，以避免意外的网络访问或阻止。

最佳实践

策略审计：定期审计网络策略及其影响，以确保它们满足您的安全和连接要求。
利用 Cilium 的 eBPF 功能：使用 Cilium 基于 eBPF 的可观察性实时监控网络策略和流量。

9. 使用本地临时存储进行临时存储管理

Kubernetes 中的临时存储管理是指节点上的 Pod 分配和使用临时存储。此类存储用于存储瞬态的应用程序数据，例如日志、缓存或 Pod 需要与在同一节点上运行的其他 Pod 共享的文件。使用 Kubernetes，您可以管理本地临时存储，以优化节点资源利用率并确保应用程序拥有所需的必要临时存储，而不会影响节点的稳定性。

实施本地临时存储

指定临时存储请求和限制：在定义 Pod 时，您可以为临时存储指定请求和限制，类似于您对 CPU 和内存资源所做的那样。这可确保 Pod 被调度到具有足够可用临时存储的节点上，并且单个 Pod 不会消耗过多的节点级资源。

apiVersion: v1
kind: Pod
metadata:
  name: ephemeral-storage-pod
spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      requests:
        ephemeral-storage: "1Gi"
      limits:
        ephemeral-storage: "2Gi"

在此示例中，Pod 请求 1Gi 的临时存储，并限制为 2Gi，超过此限制后，Kubernetes 将采取纠正措施，以确保 Pod 不超过分配的存储。

使用案例

缓存存储：缓存数据以快速访问的 Pod 可以使用临时存储来存储这些缓存。如果数据丢失，可以重新生成，这使得临时存储成为理想的选择。
日志文件：存储应用程序生成的日志文件，然后再将其发送到集中式日志记录服务。
临时空间：应用程序的临时工作空间，用于执行批处理作业等操作，其中中间结果会临时存储。

应避免的陷阱

Pod 驱逐时数据丢失：当 Pod 被驱逐或终止时，存储在临时存储中的数据将丢失。如果需要，请确保将重要数据持久化到持久存储。
过度利用：超过节点的临时存储容量可能会触发 Pod 驱逐。密切监控使用情况，以避免中断。

最佳实践

监控使用情况：实施监控以跟踪节点上的临时存储使用情况。对阈值发出警报，以主动管理容量并防止问题。
优化存储使用：定期清理应用程序中未使用的或临时文件，以释放临时存储空间。
用于适当的工作负载：仅将临时存储用于可以重新创建或可以接受丢失的数据，例如临时文件或缓存。

10. 使用 Pod 拓扑扩展约束进行高级 Pod 调度

Pod 拓扑扩展约束是 Kubernetes 中的一项复杂功能，它增强了调度机制，允许开发人员和管理员控制 Pod 在集群拓扑中分布的方式。此功能旨在通过在不同拓扑域（例如节点、可用区或自定义定义的区域）中均匀分布 Pod 来提高应用程序的弹性和效率。它对于高可用性配置、容错和优化分布式计算环境中的资源利用率特别有用。

实施 Pod 拓扑扩展约束

在 Pod 规格中定义拓扑扩展约束：要利用此功能，您需要在 Pod 规格中定义 topologySpreadConstraints。以下是一个示例，它确保 Pod 均匀分布在不同的可用区中：

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
  - name: myapp
    image: myapp:latest
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: "ScheduleAnyway"
    labelSelector:
      matchLabels:
        app: myapp

在此配置中，maxSkew 定义了允许的最大 Pod 不平衡。topologyKey 指定要考虑的拓扑域（在本例中为云提供商区域）。whenUnsatisfiable 表示在无法实现所需分布时应采取的措施；“ScheduleAnyway”表示即使调度程序无法完全满足约束条件，它仍会调度 Pod。labelSelector 用于确定应考虑进行扩展的 Pod。

使用案例

高可用性部署：通过将副本分布在多个区域中，确保关键服务在区域故障期间保持可用。
跨节点负载均衡：通过在节点间均匀分布 Pod，实现更有效的资源利用率并降低资源争用的风险。
工作负载隔离：对于多租户集群，将不同租户的工作负载分布在节点或机架上，以增强安全性并实现隔离。

应避免的陷阱

过度约束：设置过于严格的约束可能会导致调度失败或 Pod 放置不理想。在扩展和调度可行性之间取得平衡至关重要。
忽略集群更改：随着集群的发展，请检查并调整约束，以确保它们保持有效并与您的拓扑保持一致。

最佳实践

全面测试：在生产环境中应用拓扑扩展约束之前，请在暂存环境中对其进行彻底测试，以了解它们对调度和集群利用率的影响。
监控和调整：定期监控工作负载的分布，并根据需要调整约束，以响应集群拓扑或工作负载模式的变化。
将约束与其他调度策略相平衡：考虑拓扑扩展约束与其他调度策略（例如污点和容忍、节点亲和性）的交互，以避免冲突或意外行为。

11. 利用垂直 Pod 自动伸缩器 (VPA) 进行资源优化

垂直 Pod 自动伸缩器 (VPA) 是 Kubernetes 中用于动态管理资源分配的不可或缺的工具。它根据 Pod 的使用情况自动调整 Pod 的 CPU 和内存请求和限制，确保应用程序拥有在不过度配置的情况下以最佳方式执行所需的资源。这对于具有可变资源需求的应用程序特别有益，因为它有助于减少资源浪费，并有可能降低成本。

实施 VPA

设置 VPA：VPA 可以通过自定义资源定义 (CRD) 部署到您的集群。安装后，您可以为要自动调整其资源的每个应用程序定义一个 VPA 资源。

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: myapp-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  updatePolicy:
    updateMode: Auto

在此示例中，VPA 被配置为自动调整 myapp 部署的资源。

使用案例

性能优化：对于工作负载随时间变化的应用程序，VPA 确保它们始终拥有实现最佳性能所需的资源。
成本效率：通过自动调整资源请求和限制，VPA 可以帮助最大程度地减少与过度配置容器相关的云资源成本。

应避免的陷阱

缺乏微调：仅依赖 VPA 而没有手动监督有时会导致配置不理想，尤其是对于复杂应用程序。
潜在中断：如果配置不正确，VPA 可能会在不恰当的时间导致 Pod 重新启动，从而可能导致服务中断。

最佳实践

监控和监督：持续监控 VPA 的调整和性能影响，以确保它们满足您的应用程序需求。
分阶段推出：在将 VPA 广泛部署到您的生产工作负载之前，在受控环境中对其进行测试，以了解其影响。
与 HPA 结合使用：考虑将 VPA 与水平 Pod 自动伸缩器 (HPA) 结合使用，以实现全面的扩展策略，调整 Pod 的大小和容量。

12. 使用 WireGuard 保护节点间通信

WireGuard 是一种现代、高性能的 VPN 协议，可用于保护 Kubernetes 集群中的节点间通信。其简单性和效率使其成为加密节点间流量的理想选择，确保集群中传输的数据对潜在窃听者来说是私密且安全的。

实施 WireGuard

设置 WireGuard：可以通过安装 WireGuard 软件并在其上配置必要的密钥和网络设置，在 Kubernetes 节点上设置 WireGuard。

在节点上安装 WireGuard：集群中的每个节点都需要安装 WireGuard。这通常可以通过操作系统的包管理器来完成。

apt install wireguard # On Debian/Ubuntu

生成密钥：WireGuard 使用公钥密码术。在每个节点上生成密钥：

wg genkey | tee privatekey | wg pubkey > publickey

配置 WireGuard 接口：在每个节点上创建一个 WireGuard 配置文件 ( /etc/wireguard/wg0.conf) 并设置私钥和对等方（集群中的其他节点）。

[Interface]
Address = 10.0.0.1/24
PrivateKey = <node-private-key>
[Peer]
PublicKey = <peer-public-key>
Endpoint = <peer-ip-address>:51820
AllowedIPs = 10.0.0.2/32

启动 WireGuard：在每个节点上启用并启动 WireGuard 接口。

wg-quick up wg0

使用案例

数据隐私：保护在节点之间传输的敏感数据不被未经授权的方拦截。
跨云安全：保护跨多个云提供商或数据中心分布的节点之间的通信。
合规性：满足 Kubernetes 集群内传输中数据加密的法规要求。

应避免的陷阱

配置错误：配置错误的 WireGuard 对等方或 AllowedIPs 可能会导致网络分区或数据泄露。
密钥管理：安全地管理 WireGuard 使用的私钥；泄露这些密钥可能会损害整个集群的安全性。

最佳实践

自动化配置：使用自动化工具管理集群中 WireGuard 的配置，以降低人为错误的风险。
定期轮换密钥：实施定期轮换 WireGuard 密钥的流程以增强安全性。
监控连接：为 WireGuard 连接设置监控，以确保它们正常运行并具有良好的性能，并快速识别任何问题。

进一步阅读

WireGuard 文档：https://www.wireguard.com/documentation/

13. 使用 CSI 卷克隆优化存储

CSI（容器存储接口）卷克隆允许 Kubernetes 用户在同一存储类中克隆现有的持久卷声明 (PVC)。此功能简化了存储层的数据复制和备份流程，使其比传统的应用程序级数据复制方法更有效。

实施 CSI 卷克隆

创建 PVC 克隆：要创建现有 PVC 的克隆，请定义一个新的 PVC 并指定要克隆的现有 PVC。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: cloned-pvc
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: standard
  resources:
    requests:
      storage: 5Gi
  dataSource:
    kind: PersistentVolumeClaim
    name: original-pvc
    apiGroup: ""

使用案例

快速环境复制：快速克隆卷以用于开发或测试环境，确保环境相同，而无需漫长的数据传输时间。
高效数据备份：利用克隆实现更有效的数据备份策略，在数据丢失时实现更快的恢复时间。

应避免的陷阱

存储容量规划：确保您的存储基础设施有足够的容量来容纳克隆，而不会影响性能或可用性。
克隆管理：跟踪克隆卷，以避免孤立卷不必要地消耗资源。

最佳实践

标签克隆：使用标签明确标识克隆卷及其与源卷的关系，以便于管理和跟踪。
选择性克隆：仅克隆必要的数据，以避免在未使用或不必要的信息上浪费存储资源。
自动清理：实施自动化策略来清理不再需要的克隆卷，以释放存储资源。

14. 使用 OPA/Gatekeeper 进行动态准入控制

使用开放策略代理 (OPA) 和 Gatekeeper 进行动态准入控制提供了一种强大的方法，可以在运行时对 Kubernetes 资源强制执行自定义策略。这允许集群管理员在所有 Kubernetes 对象上实施治理和合规规则，确保只有符合特定条件的资源才能在集群内运行。

实施 OPA/Gatekeeper

设置 Gatekeeper：Gatekeeper 是 OPA 的准入控制器 webhook，可与 Kubernetes 无缝集成。

安装 Gatekeeper：在您的集群中部署 Gatekeeper，通常使用 Helm 图表或直接应用 YAML 文件。

kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/release-3.1/deploy/gatekeeper.yaml

定义约束和约束模板：创建约束模板以定义自定义策略 (Regos) 和约束以对特定 Kubernetes 对象强制执行这些策略。

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels
        violation[{"msg": msg, "details": {"missing_labels": missing}}] {
          provided := {label | input.review.object.metadata.labels[label]}
          required := {label | label := input.parameters.labels[_]}
          missing := required - provided
          count(missing) > 0
          msg := sprintf("you must provide labels: %v", [missing])

使用案例

安全强制：确保所有已部署容器都来自受信任的注册表或具有特定的安全配置设置。
合规性和治理：强制执行群集范围的策略，例如限制资源分配或要求标签以进行成本跟踪。

应避免的陷阱

过于严格的策略：创建过于严格的策略会阻碍合法资源的部署，影响开发速度和敏捷性。
策略管理中的复杂性：随着自定义策略数量的增加，管理和理解其含义可能变得具有挑战性。

最佳实践

渐进式策略实施：从一小组策略开始，随着您了解其影响并完善您的要求，逐步扩展。
策略即代码：将您的策略存储为代码，保存在版本控制存储库中，以跟踪更改并促进团队成员之间的协作。
定期策略审查：定期审查和测试您的策略，以确保它们仍然相关，并且不会无意中阻止合法资源的部署。

15. 利用用户命名空间增强安全性

Kubernetes 中的用户命名空间是一项功能，它通过允许容器拥有与主机系统不同的用户和组 ID 来增强容器隔离。此功能通过限制容器逃逸漏洞的潜在影响来提高安全性。

实施用户命名空间

启用用户命名空间：对用户命名空间的支持因容器运行时而异。对于 Docker，您可以通过配置 Docker 守护进程来启用用户命名空间。

配置 Docker 守护进程：编辑 Docker 守护进程配置文件 ( /etc/docker/daemon.json) 启用用户命名空间。

{
"userns-remap": "default"
}

重启 Docker：通过重启 Docker 服务应用更改。

systemctl restart docker

使用案例

改善容器隔离：使用独立用户命名空间运行容器可降低容器内 root 权限提升相关的风险。
增强安全态势：用户命名空间增加了额外的安全层，使得恶意行为者更难控制主机系统或其他容器。

应避免的陷阱

兼容性问题：由于硬编码 UID/GID 依赖项，某些应用程序或容器在用户命名空间重新映射下可能无法正常运行。
配置复杂性：正确配置用户命名空间可能很复杂，需要很好地了解容器与主机系统交互的方式。

最佳实践

部署前测试：在暂存环境中彻底测试启用用户命名空间的容器，以识别并解决任何兼容性问题。
监控异常：使用监控和日志记录工具检测任何异常行为，这些行为可能表明在独立用户命名空间中运行的容器存在问题。

16. 利用用户命名空间增强安全性

用户命名空间是 Linux 中的一项功能，允许在主机和容器之间隔离用户 ID 和组 ID。这种隔离通过确保在容器内作为 root 运行的进程在主机机上没有 root 权限来增强安全性。将 pod 中的用户映射到节点内核中的不同用户会创建额外的安全层，使得恶意行为者更难利用容器漏洞来获取主机访问权限。

实现用户命名空间

在 Kubernetes 中配置用户命名空间：

在容器运行时中启用用户命名空间：确保容器运行时支持用户命名空间并配置为使用它们。对于 Docker，这涉及编辑 Docker 守护程序配置以启用用户命名空间重新映射。
配置 Kubernetes Pod 以使用用户命名空间：根据容器运行时和 Kubernetes 版本，您可能需要指定安全上下文或使用支持用户命名空间的运行时类。
Pod 安全上下文的示例：

apiVersion: v1
kind: Pod
metadata:
  name: userns-pod
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
  containers:
  - name: example
    image: nginx

使用案例

多租户集群：在多个租户共享集群资源的环境中，用户命名空间在工作负载之间提供了额外的安全边界。
增强权限分离：对于需要提升权限的应用程序，用户命名空间有助于将这些权限的范围限制在容器环境中。

应避免的陷阱

兼容性问题：某些应用程序，特别是那些需要特定用户 ID 才能运行的应用程序，在启用用户命名空间重新映射时可能无法正常运行。
复杂性增加：管理用户 ID 映射并理解对文件权限的影响会增加容器操作的复杂性。

最佳实践

彻底测试：在广泛实施用户命名空间之前，使用您的工作负载进行彻底测试，以识别任何兼容性或操作问题。
监控和审计：使用监控和审计工具跟踪使用用户命名空间运行的容器的行为，并检测任何未经授权的权限提升尝试。

17. 使用结构化日志记录进行高级日志记录

结构化日志记录将传统日志消息转换为结构化格式，例如 JSON，使其更易于分析和查询。这种日志记录方法在 Kubernetes 等分布式系统中特别有益，在这些系统中，了解微服务之间的交互对于调试和监控至关重要。

实现结构化日志记录

将结构化日志记录集成到应用程序中：

选择一个结构化日志记录库：为您的应用程序的编程语言选择一个支持结构化日志记录的日志记录库。例如，Go 的 Logrus、.NET 的 Serilog 和 Node.js 的 Bunyan。
采用结构化日志记录实践：将现有的日志记录语句转换为结构化日志，确保关键信息作为单独的字段捕获，而不是嵌入在非结构化文本消息中。
使用 Go 中的 Logrus 的示例：

import log "github.com/sirupsen/logrus"

func main() {
    log.SetFormatter(&log.JSONFormatter{})
    log.WithFields(log.Fields{
        "event": "create",
        "topic": "topic_name",
        "key": "key_value",
    }).Info("Message about creating an item")
}

使用案例

改进调试：结构化日志可以轻松导入到 Elasticsearch 等日志管理系统中，从而使开发人员能够更有效地查询日志并查明问题。
更好的监控：使用结构化日志，可以基于特定的日志字段或值设置监控和警报，从而增强可观察性。

应避免的陷阱

不一致的日志格式：确保应用程序的所有组件都使用相同的日志格式以简化日志分析。
过度记录：记录太多信息会导致难以管理和分析的大量数据。仅记录调试和监控所需的日志。

最佳实践

标准化日志字段：定义一组标准字段以包含在应用程序中的所有日志条目中，以保持一致性。
利用日志管理工具：利用 ELK Stack（Elasticsearch、Logstash、Kibana）或 Grafana Loki 等工具来聚合、分析和可视化结构化日志。

结论

随着 Kubernetes 的不断发展，对于希望提高其集群性能、效率和安全性的工程师来说，紧跟最新的节点优化至关重要。本综合指南涵盖了一系列高级优化，从优化镜像大小和管理临时存储到使用 WireGuard 保护节点通信以及使用 Cilium 实施细粒度网络策略。通过采用这些策略以及利用垂直 Pod 自动伸缩器和结构化日志等工具，Kubernetes 管理员和开发人员可以确保其部署不仅健壮且可扩展，而且还为 2024 年及以后的挑战做好准备。采用这些优化将带来更具成本效益、更安全和性能更高的 Kubernetes 环境，使组织能够充分利用云原生技术的优势。随着 Kubernetes 生态系统的不断发展，持续探索和整合这些高级实践将成为维护最先进部署的关键。

本文参与腾讯云自媒体分享计划，分享自作者个人站点/博客。

原始发表：2024-03-042，如有侵权请联系 cloudcommunity@tencent.com 删除

容器

本文分享自作者个人站点/博客前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与腾讯云自媒体分享计划，欢迎热爱写作的你一起参与！