聊聊如何利用ingress-nginx实现应用层容灾

前言

容灾是一种主动的风险管理策略，旨在通过构建和维护异地的冗余系统，确保在面临灾难性事件时，关键业务能够持续运作，数据能够得到保护，从而最大限度地减少对组织运营的影响和潜在经济损失。因此容灾的重要性不言而喻，今天的话题主要是聊下如何利用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保持一致

示例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:annotations:nginx.ingress.kubernetes.io/default-backend: lybgeek-backupname: lybgeek-ingressnamespace: lybgeek
spec:rules:- host: lybgeek.comhttp:paths:- backend:service:name: lybgeek-masterport:number: 8001path: /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示例配置

apiVersion: v1
kind: Endpoints
metadata:name:  lybgeek-backupnamespace: lybgeek
subsets:
- addresses:- ip: 192.168.1.2- ip: 192.168.1.3ports:- port: 80---apiVersion: v1
kind: Service
metadata:name: lybgeek-backupnamespace: lybgeek-backup
spec:type: ClusterIPports:- port: 80

总结

利用以上2种方式，就可以实现一个简易版的应用层容灾，实际上的容灾远比上述的复杂，因为可能还涉及到数据备份同步等，不过利用k8s确实能减轻我们实现层面上的一些负担