给外部服务做负载均衡

annProg commented 5 years ago

通过没有selector的Service及ingress来做外部服务的负载均衡

设计

Ingress新增属性type{intra, external}, endpoints（加提示仅external类型时有效）

annProg commented 5 years ago

endpoint管理

带selector的Service会自动创建同名endpoint
删除endpoint，重建endpoint为自定义的外部IP，在从cmdb中更新Deployment，endpoint可以恢复，因此type类型变更时endpoint不用做特殊的清理步骤
手动创建的不带selector的service和对应endpoint，删除service时对应endpoint会自动删除，所以这种情况下也不需要对endpoint做清理操作

annProg commented 5 years ago

考虑以下情况：

外部服务通过ingress创建了无selector的Service
将外部服务改造后部署到k8s，但是还需要测试之后才能正式将流量迁入k8s，此时如果创建了Service，将会覆盖无selector的Service

需要处理这种冲突情况

annProg commented 5 years ago

同一个业务，是否有可能既有外部服务，又有内部服务？是否合理，是否应该禁用这种情况？这种情况将导致Service的维护变的复杂

annProg commented 5 years ago

Deployment，Ingress新增属性 manage_svc，标识是否由本对象管理Service对象

Deployment：默认管理，如果ingress_list包含external类型，则本对象不管理Service对象
Ingress：默认不管理，如果type为external，则本对象管理Service对象。

外部服务迁入内部

前提：外部服务以及使用此负载均衡服务测试环境新增Deployment -> 使用测试域名测试是否正常 -> 迁入正式环境，此时由于存在external类型，Deployment不管理Service -> 修改Ingress type为internal，此时Deployment未管理Service，因此在监听到aChange包含type且type被设置为internal时，此时仍然由ingress来管理Service -> Deployment更新时，检测无external类型ingress，由Deployment接管Service

内部服务迁出

在外部部署服务 -> 测试正常后修改Ingress type为external，ingress接管Service。给用户加警示框（可能需要打patch来支持confirm确认框）

多ingress（域名）的内部服务部分迁移到外部

比如， Deployment adeploy 拥有2个ingress

test.a.com/
test.b.com/ 只改一个ingress， test.a.com/， Ingress接管Service，将导致test.b.com也一并迁出，这种情况是否需要处理？service name是否需要使用后缀？如果使用后缀，将导致报警需要对后缀做特殊处理，增加复杂度

annProg commented 5 years ago

增加后缀方案

Ingress manage_svc为yes时，新建后缀为 -ingress-for-external的Service
Deployment可以不做任何变更（不加manage_svc属性）
当ingress type变更为internal时，监听到此变化，设置manage_svc为clean，清理-ingress-for-external后缀的Service，当ingress 再次更新时，aChange不包含type切type为internal，manage_svc改为 no，放弃管理Service

对比以上，感觉清晰一些，也更安全一些，2套Service命名，不会存在谁覆盖谁的问题，看监控也能清晰的知道这是一个外部服务唯一需要处理的是发报警时app名称中删除-ingress-for-external

ops-itop / itop-extensions