24、Kubernetes 集群的策略治理与多集群应用部署

最新推荐文章于 2025-11-10 01:54:02 发布

backprop5master

最新推荐文章于 2025-11-10 01:54:02 发布

阅读量30

点赞数

CC 4.0 BY-SA版权

分类专栏： Kubernetes实战精要文章标签： Kubernetes Gatekeeper 策略治理

本文链接：https://blog.youkuaiyun.com/backprop5master/article/details/152261628

Kubernetes实战精要专栏收录该内容

27 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

Kubernetes 集群的策略治理与多集群应用部署

1. Gatekeeper 策略治理

1.1 策略审计

在 Kubernetes 集群中，使用 Gatekeeper 可以进行策略审计。以下是一个策略配置示例：

spec:
  enforcementAction: dryrun
  match:
    kinds:
    - apiGroups:
      - ""
      kinds:
      - Pod
    namespaces:
    - default
  parameters:
    repos:
    - gcr.io/kuar-demo/
status:
  auditTimestamp: "2021-07-14T20:05:38Z"
...
  totalViolations: 1
  violations:
  - enforcementAction: dryrun
    kind: Pod
    message: container <nginx> has an invalid image repo <nginx>, allowed repos
      are ["gcr.io/kuar-demo/"]
    name: nginx-noncompliant
    namespace: default

在 status 部分， auditTimestamp 表示最后一次审计的时间， totalViolations 列出违反此约束的资源数量， violations 部分列出具体的违规情况。使用 dryrun 执行动作和审计结合，能有效确认策略是否达到预期效果，还能创建使资源符合要求的工作流程。

1.2 资源突变

Gatekeeper 除了验证资源是否合规，还能通过突变功能修改资源使其合规。默认情况下，Gatekeeper 仅作为验证准入 Webhook 部署，但可配置为突变准入 Webhook。不过，突变功能目前处于测试阶段，可能会有变化。

以下是一个将所有 Pod 的 imagePullPolicy 设置为 “Always” 的示例：

apiVersion: mutations.gatekeeper.sh/v1alpha1
kind: Assign
metadata:
  name: demo-image-pull-policy
spec:
  applyTo:
  - groups: [""]
    kinds: ["Pod"]
    versions: ["v1"]
  match:
    scope: Namespaced
    kinds:
    - apiGroups: ["*"]
      kinds: ["Pod"]
    excludedNamespaces: ["system"]
  location: "spec.containers[name:*].imagePullPolicy"
  parameters:
    assign:
      value: Always

操作步骤如下：
1. 创建突变分配：

$ kubectl apply -f imagepullpolicyalways-mutation.yaml
assign.mutations.gatekeeper.sh/demo-image-pull-policy created

创建一个 Pod：

$ kubectl apply -f compliant-pod.yaml
pod/kuard created

验证 imagePullPolicy 是否已成功更改为 “Always”：

$ kubectl get pods kuard -o=jsonpath="{.spec.containers[0].imagePullPolicy}"
Always

删除 Pod：

$ kubectl delete -f compliant-pod.yaml
pod/kuard deleted

删除突变分配：

$ kubectl delete -f imagepullpolicyalways-mutation.yaml
assign.mutations.gatekeeper.sh/demo-image-pull-policy deleted

突变准入在验证准入之前进行，因此需要创建约束来验证预期应用于特定资源的突变。与验证不同，突变能自动修复不符合要求的资源。

1.3 数据复制

编写约束时，可能需要比较不同资源字段的值。例如，确保集群中 Ingress 主机名唯一。默认情况下，Gatekeeper 只能评估当前资源内的字段，若需跨资源比较，则需进行配置。可以将特定资源缓存到 Open Policy Agent 中，以实现跨资源比较。

以下是配置 Gatekeeper 缓存 Namespace 和 Pod 资源的示例：

apiVersion: config.gatekeeper.sh/v1alpha1
kind: Config
metadata:
  name: config
  namespace: "gatekeeper-system"
spec:
  sync:
    syncOnly:
      - group: ""
        version: "v1"
        kind: "Namespace"
      - group: ""
        version: "v1"
        kind: "Pod"

应仅缓存执行策略评估所需的特定资源，过多资源缓存会增加内存需求并可能带来安全风险。

以下是一个用于比较 Ingress 主机名唯一性的约束模板示例：

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8suniqueingresshost
  annotations:
    description: Requires all Ingress hosts to be unique.
spec:
  crd:
    spec:
      names:
        kind: K8sUniqueIngressHost
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8suniqueingresshost
        identical(obj, review) {
          obj.metadata.namespace == review.object.metadata.namespace
          obj.metadata.name == review.object.metadata.name
        }
        violation[{"msg": msg}] {
          input.review.kind.kind == "Ingress"
          re_match("^(extensions|networking.k8s.io)$", input.review.kind.group)
          host := input.review.object.spec.rules[_].host
          other := data.inventory.namespace[ns][otherapiversion]["Ingress"][name]
          re_match("^(extensions|networking.k8s.io)/.+$", otherapiversion)
          other.spec.rules[_].host == host
          not identical(other, input.review)
          msg := sprintf("ingress host conflicts with an existing ingress <%v>"...
        }

数据复制是进行跨 Kubernetes 资源比较的强大工具，仅在策略需要时进行配置，并将其范围限定在相关资源。

1.4 指标监控

Gatekeeper 以 Prometheus 格式发出指标，可用于持续监控资源合规性。可以查看关于 Gatekeeper 整体健康状况的简单指标，如约束数量、约束模板数量和发送给 Gatekeeper 的请求数量。此外，还能获取策略合规性和治理的详细信息，如下表所示：
| 指标 | 描述 |
| ---- | ---- |
| 审计违规总数 | 所有审计中发现的违规数量 |
| 按执行动作划分的约束数量 | 不同执行动作下的约束数量 |
| 审计持续时间 | 每次审计所花费的时间 |

建议从外部监控系统监控 Gatekeeper，并根据资源合规性设置警报，以实现策略和治理过程的自动化。

1.5 策略库

Gatekeeper 项目的核心原则之一是创建可重用的策略库，供不同组织共享。这能减少重复的策略编写工作，使集群管理员专注于应用策略。Gatekeeper 项目有一个很棒的策略库，包括通用策略库和模拟 PodSecurityPolicy API 功能的 Pod 安全策略库。该库不断扩展且开源，可贡献自己编写的策略。

2. 多集群应用部署

2.1 多集群部署的必要性

尽管在单个 Kubernetes 集群中构建和运行应用已很复杂，但多集群应用部署仍是大多数应用的现实需求，原因主要有以下几点：
- 冗余和弹性 ：无论是云环境还是本地环境，单个数据中心通常是单一故障域。单个 Kubernetes 集群可能与单个位置绑定，成为单一故障域。即使是区域集群，Kubernetes 本身也可能成为单点故障，如集群升级可能导致应用故障，Kubernetes API 的变更或版本升级可能影响应用。
- 区域亲和性 ：某些业务或应用有区域亲和性需求，如游戏服务器需靠近玩家以减少网络延迟，部分应用受法律或监管要求，数据必须位于特定地理区域。
- 隔离需求 ：虽然单个集群中有多种隔离用户的方式，但对于一些团队和产品，不同团队意外影响应用的风险不可接受，因此更愿意管理多个集群。

2.2 部署前的基础准备

在考虑向多集群部署迁移之前，必须在单集群部署中建立正确的基础。具体包括以下方面：
- 自动化 ：自动化是关键，包括应用部署自动化和集群创建与管理自动化。使用自动化可确保所有集群的一致性，避免版本差异、监控和日志代理版本不同等问题。不要使用 GUI 或 CLI 工具创建集群，应通过源代码控制和 CI/CD 推动所有更改。
- 基础组件管理 ：部署到集群中的基础组件，如监控、日志和安全扫描器，需使用基础设施即代码工具（如 Helm）进行管理，并通过自动化部署。
- 单一身份系统 ：建议使用与全局身份提供商（如 Azure Active Directory 或其他 OpenID Connect 兼容的身份提供商）集成的单一身份系统，确保所有人在访问所有集群时使用相同身份，增强安全性。
- 一致的访问控制 ：在大多数云环境中，使用基于云的 RBAC，将 RBAC 角色和绑定存储在中央云位置。对于本地集群，可使用 Azure Arc for Kubernetes 等解决方案，若不可用，则在源代码控制中定义 RBAC 并使用基础设施即代码应用规则。
- 统一的策略定义 ：在单个位置定义集群策略，并使用单一仪表板查看所有集群的合规状态。对于本地集群，可使用基础设施即代码工具弥补全局服务的不足。

2.3 负载均衡方法

多集群应用部署时，需考虑用户如何访问应用，通常通过域名实现。多集群负载均衡策略从 DNS 查找开始，常见的方法有 GeoDNS 和 Anycast，具体对比如下：
| 方法 | 原理 | 优点 | 缺点 |
| ---- | ---- | ---- | ---- |
| GeoDNS | 根据客户端的物理位置返回最近区域集群的 IP 地址 | 简单直接，适用于部分场景 | DNS 缓存可能导致故障时流量切换不及时，根据 IP 猜测位置可能不准确 |
| Anycast | 使用单个静态 IP 地址，网络自动将流量路由到最近的可用节点 | 能快速响应流量变化，不受 DNS 缓存影响 | 配置和管理相对复杂 |

GeoDNS 仍是许多应用中常用的方法，尤其在本地应用中可能是唯一选择，但它存在一些缺点。DNS 在互联网的各个地方被缓存，尽管可以设置 DNS 查找的生存时间（TTL），但为追求更高性能，很多地方会忽略 TTL。在稳定状态下，缓存不是问题，但在需要将流量从一个集群转移到另一个集群时，如应对特定数据中心的故障，DNS 缓存会显著延长故障持续时间和影响范围。此外，GeoDNS 根据客户端 IP 地址猜测物理位置，当多个不同地理位置的客户端通过同一防火墙 IP 地址出站时，可能会猜错位置。

Anycast 是另一种负载均衡技术，使用单个静态 IP 地址，网络会自动将流量路由到最近的可用节点。这种方法能快速响应流量变化，不受 DNS 缓存的影响，但配置和管理相对复杂。

以下是多集群应用部署的简单流程图：

graph LR
    A[确定多集群部署需求] --> B[准备单集群基础]
    B --> C[选择负载均衡方法]
    C --> D[部署应用到多集群]
    D --> E[监控和维护]

综上所述，多集群应用部署是满足现代应用需求的重要手段，但在部署过程中需要充分考虑各种因素，做好基础准备工作，并选择合适的负载均衡方法。同时，使用 Gatekeeper 进行策略治理，能确保集群资源的合规性和安全性。

2. 多集群应用部署（续）

2.4 多集群应用部署的挑战与解决方案

多集群应用部署虽然有诸多优势，但也面临一些挑战，以下是常见挑战及对应的解决方案：
| 挑战 | 描述 | 解决方案 |
| ---- | ---- | ---- |
| 配置管理复杂 | 多个集群的配置不同，管理难度大 | 使用配置管理工具，如 Helm、Kustomize 等，实现配置的集中管理和版本控制 |
| 网络通信问题 | 不同集群间的网络连接可能不稳定或存在延迟 | 采用高速网络连接，如专线；使用服务网格（如 Istio）优化网络通信 |
| 数据同步困难 | 多集群间的数据需要保持一致 | 选择合适的数据同步工具，如 MySQL 主从复制、Redis 集群等；使用分布式文件系统 |
| 监控和日志统一 | 不同集群的监控和日志数据分散，难以统一分析 | 采用集中式监控和日志系统，如 Prometheus、Grafana、ELK 栈等 |

2.5 多集群应用部署的最佳实践

为了确保多集群应用部署的顺利进行，可遵循以下最佳实践：
1. 设计弹性架构 ：应用应具备弹性，能够在不同集群间自动迁移和扩展。使用 Kubernetes 的 Deployment、StatefulSet 等资源对象实现应用的弹性部署。
2. 自动化部署和回滚 ：利用 CI/CD 工具（如 Jenkins、GitLab CI/CD 等）实现应用的自动化部署和回滚，确保部署过程的一致性和可靠性。
3. 定期演练 ：定期进行多集群故障转移演练，验证应用在不同集群间的迁移能力和弹性恢复能力。
4. 安全防护 ：加强多集群的安全防护，包括网络安全、身份认证、访问控制等。使用防火墙、入侵检测系统（IDS）、加密技术等保障集群安全。

2.6 多集群应用部署的未来趋势

随着云计算和 Kubernetes 的发展，多集群应用部署将呈现以下趋势：
- 云原生多集群管理平台 ：出现更多专门的云原生多集群管理平台，提供一站式的多集群管理解决方案，简化管理操作。
- 人工智能和机器学习的应用 ：利用人工智能和机器学习技术优化多集群的资源调度、故障预测和自动修复。
- 混合云与多云部署 ：更多企业采用混合云与多云部署策略，将应用部署在不同云提供商的多个集群中，实现资源的优化配置和风险分散。

以下是多集群应用部署未来趋势的简单流程图：

graph LR
    A[云原生多集群管理平台] --> B[简化管理操作]
    C[人工智能和机器学习应用] --> D[优化资源调度]
    C --> E[故障预测和自动修复]
    F[混合云与多云部署] --> G[资源优化配置]
    F --> H[风险分散]

3. 总结

Kubernetes 集群的策略治理和多集群应用部署是现代应用开发和运维中的重要环节。通过使用 Gatekeeper 进行策略治理，可以确保集群资源的合规性和安全性；而多集群应用部署则能满足应用的冗余、弹性、区域亲和性等需求。在实际操作中，需要做好单集群的基础准备工作，选择合适的负载均衡方法，应对多集群部署的挑战，并遵循最佳实践。同时，关注多集群应用部署的未来趋势，不断优化和改进部署方案，以适应不断变化的业务需求。