当前位置： 首页 > ai >正文

KubeBlocks for Redis的5种网络模式

ai 2025/8/26 13:11:21

KubeBlocks for Redis的5种网络模式

一、引言：KubeBlocks 与网络的重要性

1.1 KubeBlocks 是什么？

KubeBlocks 是专为在 Kubernetes 上管理数据库而打造的云原生解决方案，由拥有数十年经验的领域专家设计开发。它支持广泛的有状态工作负载，涵盖关系型数据库、NoSQL 数据库以及消息队列等常见组件。通过简化运维操作、增强部署灵活性以及提供强大的扩展能力，KubeBlocks 极大地提升了在云原生环境中管理和运行数据库的效率与便捷性。

1.2 为什么网络模式如此关键？

  • 集群成员发现：拓扑结构配置、高可用切换均依赖稳定的网络通信。
  • 集群服务暴露：客户端访问需要集群提供固定的访问地址。
  • 性能要求：开发测试、生产环境、边缘业务、核心业务对网络吞吐量、RT 的要求各不相同。

二、Kubernetes Service核心概念回顾

在深入分析 KubeBlocks 的网络模式之前，我们先简要回顾几个与 Kubernetes 网络相关的概念：

Pod IP

Kubenernetes会为每个 Pod 都有唯一的 IP 地址，可在集群内被其他 Pod 直接访问。

HostNetwork

容器可以直接使用宿主机网络命名空间，拥有主机网络权限。

Service

Service会为一组 Pod 提供稳定的访问入口，通常用于负载均衡，包含以下4种服务类型：

  • ClusterIP: 从你的集群中为此预留的 IP 地址池中分配一个 IP 地址。适用于服务只在Kubernetes集群内被其他 Pod 或服务调用的情况。

Headless Service：当设置 .spec.clusterIP为None时，kubernetes不会为其分配IP地址。Headless Service 可通过内部 DNS 记录报告各个 Pod 的端点 IP 地址。

  • NodePort：在每个节点上开放指定端口（默认值：30000-32767，Kubernetes可通过--service-node-port-range标志指定端口范围)，外部可通过任意<NodeIP>:<NodePort> 访问服务。
  • LoadBalancer：第三方提供的外部负载均衡器，会为服务分配一个外部IP地址。
  • ExternelName：将服务映射到一个外部 DNS 名称（如 API 网关、第三方数据库、外部服务等），不指向任何 Pod。

三、深入剖析 Redis 的 5 种网络模式

3.1 Headless Service（默认模式）

3.1.1 概述

Headless Service 是云原生有状态服务的标准网络模式，适用于绝大多数数据库。KubeBlocks 会为每个Component 创建一个 InstanceSet Workload（类似 StatefulSet 但更强大），同时默认创建一个指向此 Workload 的 Headless Service。这样可以获得 Pod 的专属 DNS 子域，格式为 ${podName}.${headlessSvcName}.${namespace}.${clusterDomain}。

3.1.2 如何使用

以下是以 Redis Sentinel 为例的 YAML 配置：

apiVersion: apps.kubeblocks.io/v1kind: Clustermetadata:  name: redis-replication  namespace: demospec:terminationPolicy: DeleteclusterDef: redistopology: replicationcomponentSpecs:    - name: redisserviceVersion: "7.2.4"disableExporter: falsereplicas: 2resources:        limits:          cpu: 1          memory: 1Gi        requests:          cpu: 1          memory: 1GivolumeClaimTemplates:- name: data          spec:            accessModes:              - ReadWriteOnce            resources:              requests:storage: 20Gi    - name: redis-sentinel      replicas: 3      resources:        limits:          cpu: 1          memory: 1Gi        requests:          cpu: 1          memory: 1GivolumeClaimTemplates:- name: data          spec:            accessModes:              - ReadWriteOnce            resources:              requests:storage: 20Gi
3.1.3 适用场景
  • 对于原生Redis Sentinel/ Redis shard Cluster，此模式只能在同一个 Kubenertes 集群内访问。
3.1.4 注意事项

当客户端从 Kubernetes 集群外部访问 Redis Sentinel 集群时，请求首先到达 Sentinel，Sentinel 会返回注册的 Redis 主节点的 announce IP（即 Headless Service 的 Pod FQDN）。如果该地址在客户端所在网络不可达，连接将会失败。

3.2 Fixed Pod IP

3.2.1 概述

Fixed Pod IP 模式适用于数据库依赖IP地址作为节点唯一标识，并进行内部通信。Kubernetes 会为每个 Pod 分配一个唯一的 IP 地址，但 Pod 重建后 IP 会重新分配，不适合作为数据库内部通信地址。Fixed Pod IP 可解决此问题，开源社区有许多方案，如 SpiderPool，KubeBlocks 基于此方案增加了对 InstanceSet controller 的支持。

3.2.2 如何使用

以下是以 Redis 主备集群为例的 YAML 配置：

apiVersion: apps.kubeblocks.io/v1
kind: Cluster
metadata:name: redis-replicationnamespace: demo
spec:
terminationPolicy: Delete
clusterDef: redis
topology: replication
componentSpecs:- name: redis
serviceVersion: "7.2.4"
disableExporter: false
replicas: 2
<mark style="background-color: #FBBFBC">      env:</mark><mark style="background-color: #FBBFBC">      - name: FIXED_POD_IP_ENABLED</mark><mark style="background-color: #FBBFBC">        value: "true"</mark>resources:limits:cpu: 1memory: 1Girequests:cpu: 1memory: 1Gi
volumeClaimTemplates:
- name: dataspec:accessModes:- ReadWriteOnceresources:requests:
storage: 20Gi- name: redis-sentinelreplicas: 3
<mark style="background-color: #FBBFBC">      env:</mark><mark style="background-color: #FBBFBC">      - name: FIXED_POD_IP_ENABLED</mark><mark style="background-color: #FBBFBC">        value: "true"</mark>resources:limits:cpu: 1memory: 1Girequests:cpu: 1memory: 1Gi
volumeClaimTemplates:
- name: dataspec:accessModes:- ReadWriteOnceresources:requests:
storage: 20Gi
3.2.3 适用场景
  • 容器网络与物理网络已打通： 对于redis 集群，如果用户的kubernetes集群已通过macvlan或者ipvlan等方式打通，使容器网络和物理网络处于同一个平面，那么Fixed Pod IP会是一个不错的选择。
3.2.4 注意事项
  • 依赖 SpiderPool 插件：需确保集群已部署并配置 SpiderPool。
  • 调度限制：Spiderpool 并不保证新扩容 Pod 能够获取到之前缩容 Pod 的 IP 地址。

3.3 HostNetwork

3.3.1 概述

HostNetwork 是 Kubernetes 中的一种网络模式，当pod 设置hostNetwork为true时，pod会使用宿主机网络命名空间，共享主机 IP 和端口。KubeBlocks 维护一个全局的 Host Port 分配表，默认端口范围为 1025-65536，排除了一些常用端口（包括NodePort 端口范围30000-32767，6443等）。用户可通过环境变量 HOST_PORT_INCLUDE_RANGES 和 HOST_PORT_EXCLUDE_RANGES 自定义端口范围。

3.3.2 如何使用

以下是以 Redis 主备集群为例的 YAML 配置：

apiVersion: apps.kubeblocks.io/v1
kind: Cluster
metadata:name: redis-replicationnamespace: demo# 指定需要使用hostNetwork模式的component name
<mark style="background-color: #FBBFBC">  annotations:</mark><mark style="background-color: #FBBFBC">    kubeblocks.io/host-network: "redis,redis-sentinel"</mark>
spec:
terminationPolicy: Delete
clusterDef: redis
topology: replication
componentSpecs:- name: redis
serviceVersion: "7.2.4"
disableExporter: false
replicas: 2
resources:limits:cpu: 1memory: 1Girequests:cpu: 1memory: 1Gi
volumeClaimTemplates:
- name: dataspec:accessModes:- ReadWriteOnceresources:requests:
storage: 20Gi- name: redis-sentinelreplicas: 3resources:limits:cpu: 1memory: 1Girequests:cpu: 1memory: 1Gi
volumeClaimTemplates:
- name: dataspec:accessModes:- ReadWriteOnceresources:requests:
storage: 20Gi
3.3.3 适用场景
  • 高性能需求：适用于需要直接使用宿主机网络栈以获得更高性能或避免网络虚拟化开销的场景。
  • 边缘计算场景：宿主机需直接暴露服务
  • 端口直连需求：如使用传统防火墙规则管理
3.3.4 注意事项
  • 端口冲突风险：由于 KubeBlocks 只能管理自身分配的 Host Port，若物理主机上其他服务占用了 KubeBlocks 分配的端口，会导致端口冲突，需确保宿主机端口未被其他服务占用。
  • 调度限制：数据库引擎通过 Host IP + Host Port 通信，Pod 重建后可能需调度到同一节点，否则可能启动失败。建议结合 Local PV 使用（如 Redis Sentinel 集群），确保 Pod 调度到同一节点。对于 Redis Shard 集群而言，一旦集群搭建完成，每个节点都会被分配唯一的 node ID。只要 nodes.conf 文件保持不变，节点在重启后会自动向集群中其他节点广播新的 Cluster Announce 信息，实现地址的动态更新与集群拓扑的自动修复。
  • 部分企业的安全团队会限制主机端口范围，在这种情况下 HostNetwork 变相地限制了每个主机能够提供的服务数。

3.4 NodePort Service

3.4.1 概述

NodePort 是一种 Kubernetes Service 类型，在集群的每个节点上开放一个静态端口（通常为 30000-32767），外部可通过 任意<NodeIP>:<NodePort> 访问服务。KubeBlocks 支持为每个 Pod 创建对应的 Service，并通过环境变量将 Service 信息注入到 Pod 容器中，Addon 开发者可据此搭建集群。

3.4.2 如何使用

以下是以 Redis 主备集群为例的 YAML 配置：

apiVersion: apps.kubeblocks.io/v1
kind: Cluster
metadata:name: redis-replicationnamespace: demo
spec:
terminationPolicy: Delete
clusterDef: redis
topology: replication
componentSpecs:- name: redis
serviceVersion: "7.2.4"
disableExporter: false
replicas: 2
<mark style="background-color: #FBBFBC">      services:</mark><mark style="background-color: #FBBFBC">      - name: redis-advertised</mark><mark style="background-color: #FBBFBC">        serviceType: NodePort</mark><mark style="background-color: #FBBFBC">        podService: true</mark>resources:limits:cpu: 1memory: 1Girequests:cpu: 1memory: 1Gi
volumeClaimTemplates:
- name: dataspec:accessModes:- ReadWriteOnceresources:requests:
storage: 20Gi- name: redis-sentinelreplicas: 3
<mark style="background-color: #FBBFBC">      services:</mark><mark style="background-color: #FBBFBC">      - name: sentinel-advertised</mark><mark style="background-color: #FBBFBC">        serviceType: NodePort</mark><mark style="background-color: #FBBFBC">        podService: true</mark>resources:limits:cpu: 1memory: 1Girequests:cpu: 1memory: 1Gi
volumeClaimTemplates:
- name: dataspec:accessModes:- ReadWriteOnceresources:requests:
storage: 20Gi
3.4.3 适用场景
  • 外部访问：适用于需要从Kubernetes集群外部访问服务的场景，例如开发测试环境或生产环境。
3.4.4 注意事项
  • 调度限制： 数据库引擎通过 Host IP + NodePort 通信，Pod 重建后可能需调度到同一节点，否则可能启动失败。建议结合 Local PV 使用（如 Redis Sentinel 集群），确保 Pod 调度到同一节点。对于 Redis Shard 集群而言，一旦集群搭建完成，每个节点都会被分配唯一的 node ID。只要 nodes.conf 文件保持不变，节点在重启后会自动向集群中其他节点广播新的 Cluster Announce 信息，实现地址的动态更新与集群拓扑的自动修复。

3.5 LoadBalancer Service

3.5.1 概述

LoadBalancer 是一种 Kubernetes Service 类型，它在集群外部提供一个负载均衡器，用于将流量分发到后端的 Pod 上。KubeBlocks 支持为每个 Pod 创建对应的 LoadBalancer Service，并通过环境变量将 Service 信息注入到 Pod 容器中，Addon 开发者可据此搭建集群。

3.5.2 如何使用

使用方式与 NodePort 类似，将 serviceType 替换为 LoadBalancer，并添加负载均衡器所需的 annotation 即可。通过该模式，Redis Sentinel 集群将无需强制依赖 Local PV，从而提升部署的灵活性和跨节点调度能力。

3.5.3 适用场景
  • 外部访问：适用于需要从Kubernetes集群外部访问服务的场景，主要是生产环境。
  • 共享存储/云盘： Redis 集群使用此模式后，无需强制依赖 Local PV，提升部署灵活性和跨节点调度能力。
3.5.4 注意事项
  • 成本较高：如果使用云厂商提供的LoadBalancer，每个 LoadBalancer 均需付费，大规模部署时需权衡成本。
  • IP消耗太多：如果使用MetaLB，每个SVC跟IP一一对应，大规模部署时会消耗大量IP地址。

四、结语

KubeBlocks 支持的 5 种网络模式，全面覆盖了从开发测试到生产部署的各类场景。深入理解每种模式的特点和适用范围，有助于我们在实际项目中做出更合理的架构选择。无论您是构建高并发 OLTP 系统、面向互联网的服务，还是私有云部署，KubeBlocks 都能凭借其灵活且强大的网络能力，为您的数据库服务提供坚实的支撑。如需进一步了解某一种网络模式的详细信息，欢迎随时提问！

http://www.xdnf.cn/news/18684.html

相关文章：

  • 计算机大数据技术不会？医院体检数据可视化分析系统Django+Vue全栈方案
  • 第二十二天-TFTLCD驱动原理介绍和配置
  • Vue3使用 DAG 图（AntV X6）
  • Vue 2 中的 v-model和Vue3中的v-model
  • 大数据毕业设计选题推荐-基于大数据的超市销售数据统计分析系统-Hadoop-Spark-数据可视化-BigData
  • 企业在做广告前，需要明确哪些问题？
  • 销售额和营业收入的区别在哪？哪个值应该更大一些？
  • 《零基础入门AI:循环神经网络（Recurrent Neural Networks）(从原理到实现)》
  • Java中的反射机制
  • MyBatis 从入门到精通：一篇就够的实战指南（Java）
  • 3-3〔OSCP ◈ 研记〕❘ WEB应用攻击▸WEB应用安全评估工具
  • 火山引擎配置CDN
  • 【Linux | 网络】多路转接IO之poll
  • 计算机网络课堂笔记
  • AutoCAD Electrical缺少驱动程序“AceRedist“解决方法
  • C++ Core Guidelines 核心理念
  • 关于单片机串口通讯的多机操作说明---单片机串口通讯如何实现多机操作？
  • 16-day13强化学习和训练大模型
  • 怎么把iphone文件传输到windows电脑？分场景选方法
  • jasperreports 使用
  • 解锁处暑健康生活
  • 企业级监控可视化系统 Prometheus + Grafana
  • LoRA（低秩适应，Low-Rank Adaptation）的 alpha 参数解析（54）
  • 雷卯针对香橙派Orange 4G-IOT开发板防雷防静电方案
  • kafka 原理详解
  • 【OpenAI】ChatGPT-4o-latest 真正的多模态、长文本模型的详细介绍+API的使用教程！
  • 深入理解 Python Scapy 库：网络安全与协议分析的瑞士军刀
  • ES6/ES2015 - ES16/ES2025
  • 在压力测试中如何确定合适的并发用户数？
  • 挖币与区块链技术有怎样的联系？