Linux教程FG574-大规模K8s应用高可用架构设计

Part01-基础概念与理论知识

1.1 高可用架构基础

高可用（High Availability，HA）是指系统在规定的时间内能够正常运行的能力，通常以百分比表示，如99.99%（即4个9）的可用性意味着每年停机时间不超过52.6分钟。在Kubernetes环境中，高可用架构设计需要考虑多个层面：

基础设施层：服务器、网络、存储的冗余
Kubernetes集群层：控制平面和数据平面的高可用
应用层：应用的多副本部署和故障转移
服务层：服务发现、负载均衡和健康检查

1.2 Kubernetes高可用组件

Kubernetes集群的高可用主要依赖以下组件：

etcd集群：分布式键值存储，保存集群状态，需要至少3个节点
kube-apiserver：集群的API入口，可水平扩展
kube-controller-manager：管理控制器，确保集群状态符合期望
kube-scheduler：负责Pod调度，可多实例运行
kubelet：运行在每个节点上，管理Pod生命周期
kube-proxy：维护网络规则，实现服务发现

1.3 应用高可用策略

应用高可用策略包括：

多副本部署：通过Deployment或StatefulSet创建多个Pod副本
健康检查：使用liveness、readiness和startup探针
自动扩缩容：基于HPA（Horizontal Pod Autoscaler）实现
Pod Disruption Budget：控制Pod中断，确保服务可用性
亲和性和反亲和性：将Pod分布到不同节点，提高容错能力

Part02-生产环境规划与建议

2.1 高可用架构规划

在生产环境中，高可用架构规划应考虑以下因素：

集群规模：根据应用需求确定节点数量，生产环境建议至少3个控制平面节点和多个工作节点
网络架构：使用多网络平面，分离控制流量和业务流量
存储方案：使用持久化存储，确保数据可靠性
灾备策略：定期备份etcd数据，制定灾难恢复计划

风哥提示：高可用架构设计应根据业务重要性和预算进行平衡，核心业务系统建议采用多区域部署。

2.2 资源规划

资源规划包括：

CPU和内存：根据应用需求和集群规模分配资源
存储：为etcd和应用数据配置足够的存储空间
网络带宽：确保节点间通信和外部访问的带宽需求

2.3 网络规划

网络规划应考虑：

网络插件选择：根据业务需求选择合适的网络插件（如Calico、Flannel、Cilium）
网络策略：配置网络策略，加强网络安全
负载均衡：为API服务器和应用服务配置负载均衡器

from Linux:www.itpux.com

Part03-生产环境项目实施方案

3.1 集群高可用配置

实施Kubernetes集群高可用配置：

3.1.1 配置etcd集群

# 部署etcd集群（3节点）
$ kubeadm init phase etcd local –config=etcd-config.yaml

3.1.2 配置控制平面高可用

# 部署第一个控制平面节点
$ kubeadm init –control-plane-endpoint “lb.fgedu.net.cn:6443” –upload-certs

# 加入其他控制平面节点
$ kubeadm join lb.fgedu.net.cn:6443 –token <token> –discovery-token-ca-cert-hash <hash> –control-plane –certificate-key <key>

3.1.3 配置负载均衡器

# 使用HAProxy配置负载均衡
$ cat /etc/haproxy/haproxy.cfg
frontend kubernetes
bind *:6443
mode tcp
option tcplog
default_backend kubernetes-master

backend kubernetes-master
mode tcp
balance roundrobin
option tcp-check
server master1 192.168.1.10:6443 check fall 3 rise 2
server master2 192.168.1.11:6443 check fall 3 rise 2
server master3 192.168.1.12:6443 check fall 3 rise 2

3.2 应用高可用部署

部署高可用应用：

3.2.1 配置Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
name: fgedu-api
spec:
replicas: 3
selector:
matchLabels:
app: fgedu-api
template:
metadata:
labels:
app: fgedu-api
spec:
containers:
– name: api
image: fgedu/api:v1.0
ports:
– containerPort: 8080
resources:
requests:
cpu: “1”
memory: “1Gi”
limits:
cpu: “2”
memory: “2Gi”
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 10
periodSeconds: 5

3.2.2 配置HPA

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: fgedu-api-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: fgedu-api
minReplicas: 3
maxReplicas: 10
metrics:
– type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
– type: Resource
resource:
name: memory
target:
type: Utilization
averageUtilization: 70

3.3 服务发现与负载均衡

配置服务发现与负载均衡：

3.3.1 配置Service

apiVersion: v1
kind: Service
metadata:
name: fgedu-api-service
spec:
selector:
app: fgedu-api
ports:
– port: 80
targetPort: 8080
type: ClusterIP

3.3.2 配置Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: fgedu-api-ingress
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: “false”
spec:
rules:
– host: api.fgedu.net.cn
http:
paths:
– path: /
pathType: Prefix
backend:
service:
name: fgedu-api-service
port:
number: 80

Part04-生产案例与实战讲解

4.1 电商平台高可用架构

电商平台高可用架构案例：

4.1.1 架构设计

前端服务：多副本部署，使用Ingress暴露
API服务：多副本部署，使用Service负载均衡
数据库：使用StatefulSet部署，配置持久化存储
缓存：使用Redis集群
消息队列：使用Kafka集群

4.1.2 实施步骤

# 部署前端服务
$ kubectl apply -f frontend-deployment.yaml

# 部署API服务
$ kubectl apply -f api-deployment.yaml

# 部署数据库
$ kubectl apply -f mysql-statefulset.yaml

# 部署Redis集群
$ kubectl apply -f redis-cluster.yaml

# 部署Kafka集群
$ kubectl apply -f kafka-cluster.yaml

4.1.3 验证高可用性

# 查看Pod状态
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
frontend-7f89b7f5c9-2k8z5 1/1 Running 0 10m
frontend-7f89b7f5c9-5q7x4 1/1 Running 0 10m
frontend-7f89b7f5c9-8p9z7 1/1 Running 0 10m
api-6f75c9d6f4-2b4x5 1/1 Running 0 10m
api-6f75c9d6f4-5c7z8 1/1 Running 0 10m
api-6f75c9d6f4-8d9x7 1/1 Running 0 10m

# 模拟节点故障
$ kubectl cordon node1
$ kubectl drain node1 –ignore-daemonsets

# 查看Pod重新调度情况
$ kubectl get pods -o wide

4.2 金融系统高可用架构

金融系统高可用架构案例：

4.2.1 架构设计

多区域部署：跨可用区部署集群
数据同步：使用主从复制或多活架构
安全加固：配置网络策略，限制访问
监控告警：实时监控系统状态

4.2.2 实施步骤

# 部署跨区域集群
$ kubectl config use-context region1
$ kubectl apply -f financial-app.yaml

$ kubectl config use-context region2
$ kubectl apply -f financial-app.yaml

# 配置跨区域服务发现
$ kubectl apply -f multi-cluster-service.yaml

from PG视频:www.itpux.com

4.3 大规模微服务高可用架构

大规模微服务高可用架构案例：

4.3.1 架构设计

服务网格：使用Istio管理服务通信
多集群部署：分散风险，提高可用性
自动扩缩容：根据流量自动调整资源
故障注入：定期测试系统容错能力

4.3.2 实施步骤

# 安装Istio
$ istioctl install –set profile=default

# 部署微服务应用
$ kubectl apply -f microservices.yaml

# 配置服务网格规则
$ kubectl apply -f istio-rules.yaml

# 配置自动扩缩容
$ kubectl apply -f hpa-config.yaml

Part05-风哥经验总结与分享

在大规模Kubernetes集群中设计应用高可用架构时，需要注意以下几点：

分层设计：从基础设施到应用层，每一层都要考虑高可用性
冗余设计：关键组件要有多个副本，分布在不同节点或可用区
健康检查：合理配置探针，及时发现和处理故障
自动恢复：利用Kubernetes的自愈能力，自动处理故障
监控告警：建立完善的监控体系，及时发现问题
灾备方案：制定完善的灾难恢复计划，定期演练
性能优化：根据应用特点，优化资源配置和网络性能
安全防护：配置网络策略，加强访问控制

风哥提示：高可用架构设计需要综合考虑业务需求、技术可行性和成本效益，选择适合的方案。