K8S Istio 入口网关 (Ingress Gateway)

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添加一种新的资源：PhysicalDeployment资源，下面是一个对应的物理资源例子：

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

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

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

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

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

如下图是一个例子：

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

你可以将 Google、Facebook和Apple帐户绑定至你的 Ingress 帐户。 绑定帐户後，你就可以透过登入其中一个已绑定的帐户来进入 Ingress。

此功能对於使用非永久性电子邮件地址 (例如学校或工作单位的电子邮件地址) 建立帐户的玩家十分方便。 如果你担心将来可能会失去此电子邮件地址的存取权限，可以将备用登入方式绑定至你的帐户，确保你永远不会失去游戏进度的存取权限。

绑定其他登入方式:

在地图画面中，轻按
主选单

轻按右上方的
设定

在帐户部分，选择你希望绑定的登入方式旁边的
连结 选项框。

依照指示绑定你的帐户。 将帐户绑定完成後，即可使用该登入方式进入你的 Ingress 帐户。 取消绑定其他登入方式:

如需取消绑定某个登入方式，请将你要取消的登入方式旁边的
取消连结 选项框 取消勾选。 取消绑定後，你就无法再使用该登入方式进入你的帐户。 请注意，你无法移除你现在用来进入游戏的登入方式。

您也可以
从Niantic简介连结或取消连结登入服务供应商。

---