容灾是一种主动的风险管理策略,旨在通过构建和维护异地的冗余系统,确保在面临灾难性事件时,关键业务能够持续运作,数据能够得到保护,从而最大限度地减少对组织运营的影响和潜在经济损失。因此容灾的重要性不言而喻,今天的话题主要是聊下如何利用ingress-nginx实现应用层容灾
1、冗余多套应用
2、应用无状态
3、同种应用最好能分区域部署
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-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示例配置
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确实能减轻我们实现层面上的一些负担