18、Kubernetes多集群管理与服务集成策略-优快云博客

本文链接：https://blog.youkuaiyun.com/arduino9maker/article/details/152509172

Kubernetes多集群管理与服务集成策略

在当今的云计算和容器化技术领域，Kubernetes已经成为了管理容器化应用的事实标准。然而，随着业务的发展和需求的多样化，我们常常需要面对多集群管理以及与外部服务集成的挑战。下面将详细介绍相关的策略和方法。

多集群管理策略

管理多个Kubernetes集群可能会很复杂，因此需要有完善的策略来处理异步和同步工作负载。以下是一些建议：
- 利用Kubernetes操作符 ：使用像Prometheus操作符或Elasticsearch操作符这样的Kubernetes操作符来处理自动化运维任务。
- 设计多集群策略 ：在设计多集群策略时，要考虑如何进行集群间的服务发现和网络连接。可以使用像HashiCorp的Consul或Istio这样的服务网格工具来实现跨集群的网络连接。
- CD策略 ：确保你的持续部署（CD）策略能够处理跨区域或多集群的多次部署。
- GitOps方法 ：考虑使用GitOps方法来管理多个集群的运维组件，以确保集群之间的一致性。虽然GitOps方法并非适用于所有环境，但至少应该对其进行研究，以减轻多集群环境的运维负担。

与外部服务集成

在实际应用中，大多数服务都需要与Kubernetes集群外部的系统和服务进行交互。这可能是因为我们正在构建的新服务需要被传统基础设施访问，或者我们的服务需要访问现有的数据库或其他运行在本地数据中心物理基础设施上的服务。因此，将服务暴露、共享和构建跨越Kubernetes集群边界的能力是构建现实世界应用的重要部分。

导入外部服务到Kubernetes

将Kubernetes与外部服务连接的最常见模式是让Kubernetes服务消费集群外部的服务。通常，这是因为Kubernetes用于一些新的应用开发或作为传统资源（如本地数据库）的接口。这种模式对于云原生服务的渐进式开发非常有意义。

要使外部服务在Kubernetes中可访问，首先要解决网络连接问题。一般来说，基于云的Kubernetes提供商允许将集群部署到用户提供的虚拟网络（VNET）中，这些虚拟网络可以与本地网络进行对等连接以实现连通性。建立网络连接后，下一步是让外部服务看起来像Kubernetes服务。在Kubernetes中，服务发现是通过域名系统（DNS）查找实现的，因此需要让外部数据库在相同的DNS中可被发现。

以下是几种实现方法：
- 无选择器服务（Selector-Less Services） ：用于稳定IP地址的情况。创建无选择器的Kubernetes服务时，没有匹配的Pod，因此不会进行负载均衡。可以将该服务配置为具有外部资源的特定IP地址。例如：

apiVersion: v1
kind: Service
metadata:
  name: my-external-database
spec:
  ports:
  - protocol: TCP
    port: 3306
    targetPort: 3306

当服务存在后，需要更新其端点以包含数据库的IP地址：

apiVersion: v1
kind: Endpoints
metadata:
  # 重要！此名称必须与服务名称匹配
  name: my-external-database
subsets:
  - addresses:
      - ip: 24.1.2.3
    ports:
      - port: 3306

基于CNAME的服务（CNAME-Based Services） ：用于具有稳定DNS名称的情况。如果外部资源没有稳定的IP地址，但有稳定的DNS名称，可以定义基于CNAME的Kubernetes服务。例如：

kind: Service
apiVersion: v1
metadata:
  name: myco-database
spec:
  type: ExternalName
  externalName: database.myco.com

使用这种方式定义的服务，任何对 myco-database 进行查找的Pod都会递归解析为 database.myco.com 。但要确保外部资源的DNS名称可以从Kubernetes DNS服务器解析。如果外部服务的DNS位于公司本地DNS服务器，可能需要调整Kubernetes集群DNS服务器的配置。
- 基于主动控制器的方法（Active Controller-Based Approaches） ：在某些情况下，上述两种方法都不可行，例如外部服务既没有稳定的DNS地址也没有单一稳定的IP地址。此时，需要了解Kubernetes服务的底层工作原理。Kubernetes服务由服务资源和端点资源组成，通常Kubernetes控制器管理器会根据服务中的选择器填充端点。但如果创建无选择器的服务，端点资源将不会被填充，需要自己提供控制循环来创建和填充正确的端点资源。具体步骤如下：
1. 动态查询基础设施以获取要集成的Kubernetes外部服务的IP地址。
2. 将这些IP地址填充到服务的端点中。
3. Kubernetes的机制将接管并正确配置DNS服务器和kube-proxy，以将流量负载均衡到外部服务。

以下是一个简单的流程图，展示了导入外部服务到Kubernetes的过程：

graph LR
    A[建立网络连接] --> B[使外部服务像Kubernetes服务]
    B --> C{选择导入方法}
    C -->|稳定IP地址| D[无选择器服务]
    C -->|稳定DNS名称| E[基于CNAME的服务]
    C -->|无稳定IP和DNS| F[基于主动控制器的方法]

从Kubernetes导出服务

除了导入外部服务，有时还需要将Kubernetes中的服务导出到现有的环境中。这可能是因为传统的内部应用程序需要访问在云原生基础设施中开发的新API，或者由于内部策略或监管要求，需要将新构建的微服务API与现有的传统Web应用防火墙（WAF）进行接口。

导出服务的核心挑战在于，在许多Kubernetes安装中，Pod的IP地址在集群外部是不可路由的。因此，建立传统应用程序与Kubernetes Pod之间的路由是实现导出服务的关键任务。

以下是几种导出服务的方法：
- 使用内部负载均衡器 ：这是从Kubernetes导出服务的最简单方法。大多数云提供商都提供内部负载均衡器，它可以将虚拟IP地址映射到一组Pod，但该虚拟IP地址来自内部IP地址空间，因此只能在虚拟网络内路由。通过在服务负载均衡器上添加特定于云的注释来激活内部负载均衡器。例如，在Microsoft Azure中，添加 service.beta.kubernetes.io/azure-load-balancer-internal: "true" 注释；在Amazon Web Services（AWS）中，注释为 service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0 。示例如下：

apiVersion: v1
kind: Service
metadata:
  name: my-service
  annotations:
    # 根据需要在其他环境中替换此注释
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
...

使用内部负载均衡器导出服务后，会获得一个稳定的、可路由的IP地址，可以直接使用该IP地址或设置内部DNS解析来为导出的服务提供发现功能。
- 使用NodePort服务 ：在本地安装中，云基内部负载均衡器不可用，此时使用基于NodePort的服务是一个不错的解决方案。NodePort类型的服务会在集群的每个节点上导出一个监听器，将流量从节点的IP地址和选定的端口转发到定义的服务中。示例YAML文件如下：

apiVersion: v1
kind: Service
metadata:
  name: my-node-port-service
spec:
  type: NodePort
...

创建NodePort类型的服务后，Kubernetes会自动为服务选择一个端口，可以通过查看 spec.ports[*].nodePort 字段获取该端口。如果想自己选择端口，需要确保该端口在集群配置的范围内（默认范围是30000到30999）。Kubernetes完成服务在该端口的暴露后，需要（或网络管理员）使该服务在现有应用程序外部可发现。根据应用程序的配置方式，可以给应用程序提供一个 ${node}:${port} 对的列表，应用程序将执行客户端负载均衡；或者需要在网络中配置物理或虚拟负载均衡器，将流量从虚拟IP地址导向这个 ${node}:${port} 后端列表。

以下是一个表格，总结了导出服务的两种方法：
| 导出方法 | 适用场景 | 操作步骤 |
| ---- | ---- | ---- |
| 使用内部负载均衡器 | 云环境 | 1. 在服务负载均衡器上添加特定于云的注释。
2. 获取稳定的、可路由的IP地址。
3. 直接使用IP地址或设置内部DNS解析。 |
| 使用NodePort服务 | 本地安装 | 1. 创建NodePort类型的服务。
2. 选择或获取端口。
3. 使服务在现有应用程序外部可发现。 |

集成外部机器和Kubernetes

如果上述两种解决方案都不适用，例如需要更紧密的集成以实现动态服务发现，最后的选择是将运行应用程序的机器直接集成到Kubernetes集群的服务发现和网络机制中。这比前两种方法更具侵入性和复杂性，应仅在必要时使用。

要将外部机器集成到集群进行网络连接，需要确保Pod网络路由和基于DNS的服务发现都能正常工作。以下是两种实现方法：
- 运行kubelet ：在要加入集群的机器上运行kubelet，但禁用集群中的调度。具体步骤如下：
1. 运行kubelet将节点加入集群（具体方法可参考其他资料）。
2. 使用 kubectl cordon ... 命令立即将节点标记为不可调度，以防止任何额外的工作被调度到该节点。
3. 这样，KubeProxy和网络路由的Pod将部署到该机器上，使运行在该机器上的任何应用程序都能发现Kubernetes服务。
- 运行kube-proxy ：这是一种轻量级但更复杂的方法，只在机器上运行kube-proxy进程并调整机器的DNS服务器。假设可以正确设置Pod路由，运行kube-proxy将设置机器级别的网络，使Kubernetes服务的虚拟IP地址重新映射到组成该服务的Pod。如果还将机器的DNS指向Kubernetes集群DNS服务器，就可以在不属于Kubernetes集群的机器上实现Kubernetes发现功能。

跨Kubernetes集群共享服务

除了与外部服务集成，连接Kubernetes集群之间的服务也是一个重要的用例。这可能是为了实现不同区域Kubernetes集群之间的东西向故障转移，或者将不同团队运行的服务链接在一起。实现这种交互的过程实际上是前面所述设计的组合。

总之，在管理Kubernetes集群和与外部服务集成时，需要根据具体的需求和场景选择合适的策略和方法。通过合理运用这些技术，可以构建出更加灵活、高效和可靠的应用系统。

Kubernetes多集群管理与服务集成策略

多集群管理策略的深入考量

在实际的多集群管理中，我们还需要深入思考一些关键因素。首先，要明确自身的需求是否真正匹配多集群拓扑。例如，是否真的需要严格的多租户环境，因为这将自动需要采用多集群策略。如果不需要，那么就要考虑合规性需求以及是否有足够的运维能力来承担多集群架构带来的额外开销。

以下是一个决策流程图，帮助我们在多集群管理时做出选择：

graph TD
    A[明确需求] --> B{是否需要硬多租户}
    B -->|是| C[采用多集群策略]
    B -->|否| D{考虑合规需求}
    D --> E{是否有运维能力}
    E -->|是| F[可考虑多集群架构]
    E -->|否| G[谨慎采用多集群架构]

另外，如果选择使用更多更小的集群，一定要围绕它们的交付和管理实现自动化，以减轻运维负担。可以使用Kubernetes操作符，如Prometheus操作符或Elasticsearch操作符，来处理自动化运维任务。同时，在设计多集群策略时，要考虑如何进行集群间的服务发现和网络连接，像HashiCorp的Consul或Istio这样的服务网格工具可以帮助实现跨集群的网络连接。

服务集成的最佳实践总结

在服务集成方面，无论是导入外部服务到Kubernetes，还是从Kubernetes导出服务，都有一些最佳实践值得遵循。

导入外部服务的最佳实践

网络连接优先 ：在导入外部服务时，首先要确保网络连接正常。对于云环境，云提供商通常允许将集群部署到用户提供的虚拟网络（VNET）中，并与本地网络进行对等连接。
选择合适的导入方法 ：根据外部服务的特点选择合适的导入方法。如果外部服务有稳定的IP地址，可使用无选择器服务；如果有稳定的DNS名称，可使用基于CNAME的服务；如果两者都没有，则考虑基于主动控制器的方法。
DNS配置 ：确保外部服务的DNS名称可以从Kubernetes DNS服务器解析。如果需要，调整Kubernetes集群DNS服务器的配置。

导出服务的最佳实践

根据环境选择方法 ：在云环境中，优先使用内部负载均衡器；在本地安装中，使用NodePort服务。
服务发现 ：导出服务后，要确保服务在现有应用程序外部可发现。可以通过提供 ${node}:${port} 对列表或配置负载均衡器来实现。

以下是一个总结表格，展示服务集成的最佳实践：
| 服务集成类型 | 最佳实践 |
| ---- | ---- |
| 导入外部服务 | 1. 优先确保网络连接。
2. 根据外部服务特点选择导入方法。
3. 配置好DNS。 |
| 导出服务 | 1. 根据环境选择导出方法。
2. 确保服务可发现。 |