前言
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中。
在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同时把流量向容器和物理机部署的服务进行转发，不仅能够解决部分业务确实存在物理机部署的需求，同时对于我们公司的现状的容器化推广有很大帮助，排除了不少阻力。
