前言
容灾是一种主动的风险管理策略，旨在通过构建和维护异地的冗余系统，确保在面临灾难性事件时，关键业务能够持续运作，数据能够得到保护，从而最大限度地减少对组织运营的影响和潜在经济损失。因此容灾的重要性不言而喻，今天的话题主要是聊下如何利用ingress-nginx实现应用层容灾
应用层容灾前提
1、冗余多套应用
2、应用无状态
3、同种应用最好能分区域部署
如何利用ingress-nginx实现
1、利用ingress-nginx的灰度发布能力
该方案的实现可以参考我之前写的文章聊聊部署在不同K8S集群上的服务如何利用nginx-ingress进行灰度发布
不过该方案有个缺点是手动挡，出现故障时，需要手动切换
2、利用default-backend
上述官方说明的核心表述如下
注解 | 说明 |
|---|---|
nginx.ingress.kubernetes.io/default-backend | 容灾服务。当Ingress定义的服务没有可用节点时，请求会自动转发该容灾服务。 |
nginx.ingress.kubernetes.io/custom-http-errors | 该注解和default-backend一起工作。当后端服务返回指定HTTP响应码，原始请求会被再次转发至容灾服务。注意：转发至容灾服务时，请求的Path会被重写为/，该行为与ingress-nginx保持一致 |
示例：
代码语言：yaml复制apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/default-backend: lybgeek-backup
name: lybgeek-ingress
namespace: lybgeek
spec:
rules:
- host: lybgeek.com
http:
paths:
- backend:
service:
name: lybgeek-master
port:
number: 8001
path: /
pathType: Prefix注： lybgeek-backup需要和lybgeek-master处于同个命名空间下。其次上文说了同个级别的应用应该是分区域部署的，因此 lybgeek-backup背后的pod应该是来自其他集群。那要如何实现呢
这边提供两种思路，一种部署nginx-pod应用，该nginx-pod和lybgeek-master归属同个命名空间，通过该nginx-pod的nginx.conf配置要转发其他集群pod，最后该nginx-pod通过label和lybgeek-backup绑定一起。另外一种是使用endpoint。通过创建endpoint，同时需要创建同名service并且selector为空，可以用来引用集群外的ip，当然也可以引用集群内的ip
创建endpoint示例配置
代码语言：yaml复制apiVersion: v1
kind: Endpoints
metadata:
name: lybgeek-backup
namespace: lybgeek
subsets:
- addresses:
- ip: 192.168.1.2
- ip: 192.168.1.3
ports:
- port: 80
---
apiVersion: v1
kind: Service
metadata:
name: lybgeek-backup
namespace: lybgeek-backup
spec:
type: ClusterIP
ports:
- port: 80
总结
利用以上2种方式，就可以实现一个简易版的应用层容灾，实际上的容灾远比上述的复杂，因为可能还涉及到数据备份同步等，不过利用k8s确实能减轻我们实现层面上的一些负担
