MK
摩柯社区 - 一个极简的技术知识社区
AI 面试

Kubernetes 集群的高可用架构设计与实现

2023-11-053.8k 阅读

Kubernetes 集群高可用架构概述

Kubernetes（简称 K8s）作为容器编排领域的事实标准，在企业级应用部署与管理中扮演着关键角色。随着业务规模的增长和对服务稳定性要求的提高，构建高可用的 Kubernetes 集群变得至关重要。

高可用的 Kubernetes 集群意味着在面对部分组件故障、节点宕机等异常情况时，集群依然能够持续稳定地运行，保证应用的可用性和性能。其架构设计需要综合考虑多个方面，包括控制平面的高可用、数据存储的可靠性、节点的弹性以及网络的健壮性等。

控制平面的高可用

Kubernetes 的控制平面是整个集群的大脑，负责管理和协调集群中的各种资源。控制平面主要包含 kube - apiserver、kube - controller - manager、kube - scheduler 等核心组件。实现控制平面的高可用，关键在于对这些组件进行冗余部署，避免单点故障。

以 kube - apiserver 为例，它是控制平面与集群其他组件交互的唯一接口，所有的 API 请求都要经过它。为了实现高可用，通常会部署多个 kube - apiserver 实例，并通过负载均衡器（如 HAProxy、Nginx 等）将请求均匀分发到各个实例上。当某个 kube - apiserver 实例出现故障时，负载均衡器能够自动检测并将流量切换到其他正常实例，保证 API 服务的连续性。

控制平面高可用的具体实现

基于 HAProxy 的负载均衡实现

HAProxy 是一款广泛使用的开源负载均衡软件，具有高性能、高可靠性的特点。以下是使用 HAProxy 实现 kube - apiserver 负载均衡的基本配置示例：

global
    log /dev/log local0
    log /dev/log local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
    stats timeout 30s
    user haproxy
    group haproxy
    daemon

defaults
    log global
    mode http
    option httplog
    option dontlognull
    timeout connect 5000
    timeout client 50000
    timeout server 50000

frontend kube - apiserver - frontend
    bind *:6443
    mode tcp
    default_backend kube - apiserver - backend

backend kube - apiserver - backend
    mode tcp
    balance roundrobin
    server kube - apiserver1 192.168.1.10:6443 check
    server kube - apiserver2 192.168.1.11:6443 check
    server kube - apiserver3 192.168.1.12:6443 check

在上述配置中，frontend 部分定义了监听端口 6443，所有发往该端口的 TCP 请求都会被转发到 backend 部分。backend 部分使用 roundrobin 均衡算法将请求均匀分配到三个 kube - apiserver 实例上，并通过 check 选项对每个实例的健康状态进行监测。

etcd 集群的高可用

etcd 是 Kubernetes 集群的数据存储中心，保存着集群的所有配置信息和状态数据。为了保证数据的可靠性和高可用性，etcd 通常以集群的形式部署，一般推荐奇数个节点（如 3 个、5 个等）。

以 3 节点 etcd 集群为例，每个节点在启动时需要通过配置文件指定集群成员信息。以下是一个简单的 etcd 节点配置示例：

name: etcd1
data - dir: /var/lib/etcd
listen - peer - urls: http://192.168.1.10:2380
listen - client - urls: http://192.168.1.10:2379
initial - advertise - peer - urls: http://192.168.1.10:2380
initial - cluster: etcd1=http://192.168.1.10:2380,etcd2=http://192.168.1.11:2380,etcd3=http://192.168.1.12:2380
initial - cluster - token: my - etcd - cluster - token
initial - cluster - state: new

在这个配置文件中，name 定义了节点名称，data - dir 指定了数据存储目录，listen - peer - urls 和 listen - client - urls 分别用于节点间通信和客户端连接。initial - advertise - peer - urls 用于向集群中的其他节点宣告自己的地址，initial - cluster 则列出了整个集群的成员信息。

etcd 集群通过 Raft 一致性算法来保证数据的一致性和高可用性。在集群运行过程中，只要大多数节点（如 3 节点集群中至少 2 个节点）正常工作，集群就能继续提供服务。

节点高可用与弹性伸缩

节点的冗余与故障检测

为了提高集群的整体可用性，除了控制平面的高可用，工作节点也需要具备一定的冗余。在 Kubernetes 集群中，可以通过添加多个工作节点来实现冗余。当某个工作节点出现故障时，Kubernetes 能够自动将该节点上运行的 Pod 重新调度到其他健康的节点上。

Kubernetes 通过节点健康检查机制来检测节点的状态。kube - kubelet 会定期向 kube - apiserver 发送心跳信息，表明自己的健康状态。如果 kube - apiserver 在一段时间内没有收到某个节点的心跳，就会将该节点标记为不可用，并触发 Pod 的重新调度。

此外，还可以使用外部监控工具（如 Prometheus + Grafana）对节点的各项指标（如 CPU、内存、磁盘 I/O 等）进行实时监控，以便及时发现潜在的故障风险。

自动弹性伸缩

随着业务流量的变化，手动调整集群节点数量往往效率低下且容易出错。Kubernetes 提供了自动弹性伸缩功能，包括水平 Pod 自动伸缩（HPA）和集群自动伸缩（CA）。

水平 Pod 自动伸缩（HPA）允许根据 Pod 的 CPU 或内存使用率自动调整 Pod 的副本数量。例如，以下是一个简单的 HPA 配置示例：

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: my - app - hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my - app - deployment
  minReplicas: 2
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50

在上述配置中，scaleTargetRef 指定了要进行伸缩的 Deployment，minReplicas 和 maxReplicas 分别定义了最小和最大副本数，targetCPUUtilizationPercentage 表示当 CPU 使用率达到 50% 时触发伸缩操作。

集群自动伸缩（CA）则是根据集群中 Pod 的资源需求自动调整节点数量。当集群中资源不足时，CA 会自动添加新的节点；当部分节点上的 Pod 被移除且资源利用率较低时，CA 会自动移除这些节点。要启用集群自动伸缩，需要在云提供商（如 AWS、GCP 等）的环境中进行相应的配置，并部署集群自动伸缩器。

网络高可用设计

网络拓扑与冗余

在 Kubernetes 集群中，网络拓扑的设计对于高可用性至关重要。一个良好的网络拓扑应该具备冗余链路和设备，以避免因单点网络故障导致集群部分或全部不可用。

常见的网络拓扑结构包括二层网络的双核心交换机架构和三层网络的多出口路由器架构。在双核心交换机架构中，工作节点通过两条不同的链路连接到两个核心交换机，当其中一个核心交换机出现故障时，另一个核心交换机能够继续提供网络连接。在多出口路由器架构中，集群通过多个出口路由器连接到外部网络，当某个路由器出现故障时，流量可以自动切换到其他路由器。

网络插件的选择与配置

Kubernetes 支持多种网络插件，如 Flannel、Calico、Weave Net 等。不同的网络插件在性能、功能和高可用性方面各有特点。

以 Calico 为例，它提供了基于 BGP 的网络路由和网络策略功能，具有较好的扩展性和性能。在高可用配置方面，Calico 可以通过多节点部署和冗余 BGP 对等体来提高网络的可靠性。

以下是一个简单的 Calico 安装配置示例：

kubectl apply -f https://docs.projectcalico.org/v3.14/manifests/calico.yaml

在安装完成后，可以通过配置 Calico 的 BGP 对等体来实现网络冗余。例如：

apiVersion: projectcalico.org/v3
kind: BGPPeer
metadata:
  name: peer1
spec:
  peerIP: 192.168.1.20
  asNumber: 64512

通过配置多个 BGPPeer，可以确保在某个对等体出现故障时，网络流量仍然能够正常转发。

存储高可用设计

持久化存储的选择

在 Kubernetes 集群中，应用通常需要持久化存储来保存数据，如数据库数据、配置文件等。常见的持久化存储选项包括本地存储、网络存储（如 NFS、Ceph 等）和云存储（如 AWS EBS、GCP Persistent Disk 等）。

对于高可用性要求较高的应用，建议选择具有冗余和数据复制功能的存储方案。例如，Ceph 是一个分布式存储系统，它通过数据副本和纠删码技术来保证数据的可靠性。在 Ceph 集群中，可以配置多个 OSD（Object Storage Device）节点，当某个 OSD 节点出现故障时，数据仍然可以从其他副本中获取。

存储卷的动态供应与管理

Kubernetes 提供了存储卷的动态供应功能，允许根据应用的需求自动创建和管理存储卷。通过 StorageClass、PersistentVolumeClaim 和 PersistentVolume 的配合使用，可以实现存储资源的灵活分配和管理。

以下是一个简单的 StorageClass 配置示例：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: my - storage - class
provisioner: kubernetes.io/aws - ebs
parameters:
  type: gp2
  zone: us - west - 2a

在上述配置中，provisioner 指定了存储卷的供应者为 AWS EBS，parameters 中定义了存储卷的类型为 gp2，并指定了可用区为 us - west - 2a。

当应用创建 PersistentVolumeClaim 时，Kubernetes 会根据 StorageClass 的配置自动创建相应的 PersistentVolume，为应用提供持久化存储。

监控与故障恢复

监控系统的搭建

为了及时发现和解决 Kubernetes 集群中的问题，搭建一套完善的监控系统是必不可少的。常用的监控工具包括 Prometheus、Grafana、Alertmanager 等。

Prometheus 用于收集和存储集群的各项指标数据，如节点资源使用情况、Pod 运行状态等。Grafana 则用于将 Prometheus 收集的数据以可视化的方式展示出来，方便管理员进行数据分析和问题排查。Alertmanager 用于根据预设的告警规则发送告警信息，通知管理员集群中出现的异常情况。

以下是一个简单的 Prometheus 配置示例：

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'kubernetes - apiservers'
    kubernetes_sd_configs:
      - role: endpoints
        api_server: https://kubernetes.default.svc
        tls_config:
          ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
    relabel_configs:
      - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
        action: keep
        regex: default;kubernetes;https

在这个配置中，定义了 Prometheus 的数据采集间隔和评估间隔，并配置了对 kube - apiserver 的指标采集任务。

故障恢复策略

当集群出现故障时，快速有效的故障恢复策略能够最大限度地减少对业务的影响。故障恢复策略应包括故障诊断、故障隔离和故障修复三个主要步骤。

故障诊断阶段，通过监控系统收集的指标数据和日志信息，分析故障发生的原因和可能的影响范围。例如，如果某个 Pod 出现频繁重启的情况，可以通过查看 Pod 的日志来确定是否是应用程序代码问题或资源不足导致。

故障隔离阶段，将故障组件与其他正常组件隔离开来，防止故障扩散。例如，当某个节点出现故障时，将该节点从集群中移除，并将其上运行的 Pod 重新调度到其他健康节点。

故障修复阶段，根据故障诊断的结果采取相应的修复措施。如果是硬件故障，需要及时更换硬件设备；如果是软件问题，可以通过更新软件版本、调整配置参数等方式进行修复。在修复完成后，需要对集群进行全面的检查和测试，确保故障已经彻底解决，集群恢复正常运行。

安全性与高可用

认证与授权

在高可用的 Kubernetes 集群中，认证与授权机制是保障系统安全的重要环节。Kubernetes 支持多种认证方式，如基于证书的认证、Token 认证等。

基于证书的认证是一种常用的安全认证方式，kube - apiserver 通过验证客户端证书来确认客户端的身份。以下是生成客户端证书的基本步骤：

  1. 生成私钥：
openssl genrsa -out client.key 2048
  1. 生成证书签名请求（CSR）：
openssl req -new -key client.key -out client.csr -subj "/CN=client/O=client - group"
  1. 使用 CA 证书对 CSR 进行签名：
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt

授权方面，Kubernetes 提供了多种授权模式，如 Node 授权、RBAC（基于角色的访问控制）等。RBAC 允许管理员根据用户的角色和权限来控制对集群资源的访问。例如，可以创建一个只读角色，只允许用户查看集群中的资源信息，而不具备修改权限。

网络安全

网络安全在 Kubernetes 集群高可用中同样不容忽视。通过网络策略可以限制 Pod 之间的网络访问，防止恶意攻击和数据泄露。

例如，以下是一个简单的网络策略配置示例，只允许特定命名空间中的 Pod 访问某个服务：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow - specific - namespace - access
  namespace: my - service - namespace
spec:
  podSelector:
    matchLabels:
      app: my - service
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: allowed - namespace

在上述配置中，podSelector 指定了要保护的服务 Pod，ingress 部分定义了只允许来自 allowed - namespace 命名空间的访问。

通过合理配置认证、授权和网络安全策略，可以在保障 Kubernetes 集群高可用性的同时，提高系统的安全性。

总结

构建高可用的 Kubernetes 集群需要综合考虑控制平面、节点、网络、存储、监控和安全等多个方面。通过冗余部署、故障检测与恢复、弹性伸缩等技术手段，可以确保集群在面对各种故障和业务流量变化时，依然能够稳定、高效地运行。在实际的架构设计与实现过程中，需要根据具体的业务需求和环境特点，选择合适的技术方案和工具，并进行细致的配置和优化，以打造一个满足企业级应用需求的高可用 Kubernetes 平台。