Kubernetes中HTTP请求的代理和转发使用场景比较多，这里对代理和转发各举一个例子。

• 环境

笔者这里使用的Ingress Controller是“NGINX Ingress Controller”，版本是“1.7.1”，Kubernetes的版本是“1.25.6”。

• 转发配置

因业主的要求，对原本运行在数据中心A的服务做了迁移，服务迁移后，原有的域名因已广播出去，短期内不做下线处理，客户访问老的域名也需要跳转到服务，这里通过配置转发来解决，具体的配置如下，

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: "https://www.b-site.com/$2"
  name: rewrite-target
  namespace: my-app
spec:
  rules:
  - host: www.a-site.com
    http:
      paths:
      - backend:
          service: 
            name: outer-service
            port: 
               number: 80
        path: /outer/(/|$)(.*)
        pathType: Prefix

通过配置重写，新的域名可以提供服务，老的域名也得以保留。原理很简单，它是通过Nginx的rewrite指令实现的302重定向。

• 代理配置

Kubernetes中，实际的服务可以不用运行在集群内。人为配置“endpoints”和“service”，通过内部的服务名来访问运行在集群外的服务。

私有化部署的服务，需要访问一个外部第三方接口，其仅能通过http访问，而部署在Kubernetes中的服务都通过https访问，为了解决Chrome浏览器报出的“Mixed Content”异常，

这里配置代理访问，前端页面便可以使用https来请求第三方接口，配置如下，

---
apiVersion: v1
kind: Endpoints
metadata:
  name: external-service
  namespace: my-app
subsets:
  - addresses:
      - ip: 123.123.123.123 #第三方接口ip
    ports:
      - port: 8000              # 第三方服务的端口
---
apiVersion: v1
kind: Service
metadata:
  name: external-service
  namespace: my-app
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8000
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: external-ingress
  namespace: my-app
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - '*.a-site.com'
    secretName: ssl-key
  rules:
  - host: www.a-site.com
    http:
      paths:
      - path: /outer/
        pathType: Prefix
        backend:
          service:
            name: external-service
            port:
              number: 80

上面配置中，“www.a-site.com”是使用https访问的，通过配置代理，请求路径以“/outer/”开头的链接都将代理到第三方的接口，这样Chrome就不会报“Mixed Content”异常了。

在Kubernetes中，service使用selector来绑定和自己同名的endpoints，这里我们手动配置同名的endpoints和service来实现service与endpoints的绑定。

文章对Kubernetes中“NGINX Ingress Controller”的转发和代理配置做了简单举例，希望能对你平时的工作有所启发，感谢阅读和评论！