区块链技术

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

本文主要是介绍聊聊如何利用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-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确实能减轻我们实现层面上的一些负担

这篇关于聊聊如何利用ingress-nginx实现应用层容灾的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!