前言

K8S Ingress通过管理集群中的外部服务用的Service，把流量从Nginx转到对应部署的容器中，提供7层负载均衡能力。

在我们公司存在混合部署的情况，有业务同时在容器和物理机、云主机上部署服务实例，但是也需要通过K8S Ingress把外部流量转入进行，由于Ingress不支持流量转到物理机上的实例，所以我们需要做一些扩展来支持这种场景。

在Ingress Nginx主流程一文中，已经介绍了Ingress Nginx的驱动流程，系统的主要驱动逻辑是监控API Server中相关资源的变化，并通过事件回调去驱动系统的运行。

我们可以通过适当改造Ingress Nginx Controller来让他支持物理机实例。

实现思路

ingress-nginx-controller的实现是通过k8s中的资源发现，把Server或Pod的变化，实时更新配置到Nginx中，基于Nginx的反向代理服务，基于vhost子域名以及URL路由到后端的Pod中。

image.png

在K8S添加物理服务资源

K8S原生的资源无法发现物理部署的服务，所以我们需要利用K8S的资源扩展机制，给K8S添加一种新的资源：PhysicalDeployment资源，下面是一个对应的物理资源例子：

apiVersion: test.api.io/v1beta1
kind: PhysicalEndpoint
metadata:
  name: phyendpoint-example
  namespace: test
spec:
  endpoints:
  - 10.0.0.1:10001
  - 10.0.0.2:10001
  http_detect: /conf/
  interval: 10
statu:
  

phyendpoint-example有两个实例，分别是10.0.0.1:10001和10.0.0.2:1001，由于ingress中的nginx使用的lua功能来实现upstream，没有使用nginx原生的upstream，所以它暂时不具备被动探测服务不可用的功能，也就是说，当一个endpoint故障或者不能工作时，ingress无法做到想nginx原生upstream那样，先隔离该实例，10秒后重试这种被动探测能力。

ingress主要依赖于k8s原生的pod的主动探测能力来发现不可用服务，当主动探测一个endpoint不可用时，ingress能够及时（当然也不够实时）发现问题，并隔离该pod。

所以，这里还需要针对PhysicalEndpoint实现自己的控制器，在控制器中定期对PhysicalEndpoint管理的Endpoint进行探测，并及时更新它的状态。

扩展ingress-nginx-controller

ingress主要基于service来发现Endpoints，这里需要增加对PhysicalEndpoint的事件侦听服务，并与Service服务一起订阅合并Endpoints后，通过nginx的API更新到对应的upstream服务列表中。

为了合并容器与物理部署，需要对Service也做稍许扩展，增加annotation，让我们在服务发现时除了发现该service的容器Endpoint之外，还去发现对应的annotation中的PhysicalEndpoint中的Endpoint。

如下图是一个例子：

apiVersion: v1
kind: Service
metadata:
  name: test-service
  namespace: test
  annotations:
      test.api.io/physical.deployment.endpoints: phyendpoint-example     
  labels:
    deploy-type: test    
    project-name: golang-test-project
spec:
  ports:
  - port: 10001
    targetPort: 10001
    protocol: TCP
  selector:
    project-name: abc

总结

通过简单的扩展，就可以让Ingress同时把流量向容器和物理机部署的服务进行转发，不仅能够解决部分业务确实存在物理机部署的需求，同时对于我们公司的现状的容器化推广有很大帮助，排除了不少阻力。