ingress调用其他命名空间配置
例如:
我在a空间 配置了ingress 想要把b空间的service(
prometheus-k8s
)通过a空间的
ingress
代理出来,配置如下
kind: Ingress
apiVersion: extensions/v1beta1
metadata:
name: prome-ingress
namespace: test
spec:
rules:
- host: test-prometheus.mlamp.cn
http:
paths:
- pathType: ImplementationSpecific
backend:
serviceName: prometheus-k8s
servicePort: 9090
Ingress配置
kind: Ingress
apiVersion: extensions/v1beta1
metadata:
name: prome-ingress
namespace: test
spec:
rules:
- host: test-prometheus.mlamp.cn
http:
paths:
- pathType: ImplementationSpecific
backend:
serviceName: prometheus-k8s
servicePort: 9090
externalName介绍
externalName Service是k8s中一个特殊的service类型,它不需要指定selector去选择哪些pods实例提供服务,而是使用DNS CNAME机制把自己CNAME到你指定的另外一个域名上,你可以提供集群内的名字,比如mysql.db.svc这样的建立在db命名空间内的mysql服务,也可以指定http://mysql.example.com这样的外部真实域名。
CNAME是很有用的一个功能,在不同的域名之间搭建桥梁达到明一个域名暗另一个域名,比如github就通过CNAME机制来达到为用户提供私有域名站点的功能,云服务商也都是使用CNAME为用户提供各种各样的服务。作为明域名的所有者,我可以用A云来提供服务,哪天我口味变了,我换成B云提供服务,对我的用户的来说没有任何感知。
这么好的功能,k8s当然要加以利用,那就是externalName Service。从External这个名字看,把外部服务引入集群的意味相当浓烈吧,我提供给pod一个mysql.db.svc这样一个数据库服务,至于真实的数据库是运行在同一个集群内,还是在集群外部,pod不在意也不需要关心,反正能用就成。这就是extenalName的主要用途。
另外,externalName既然是Service,它就可以被Ingress作为backend。这样做的话,就等于直接在我们的ingress上反向代理了exernalName Service上的服务。哦耶,我可以用k8s的语法来配置反向代理,哈哈。不过看着也就是个不疼不痒的功能。除了这个还有别的应用么?
别说,还真有,一般我们为了方便都直接把一个解析域名解析到集群,比如我把*.http://renwei.net解析到我的ingress集群,我http://blog.renwei.net是一个集群内的服务,我http://wiki.renwei.net是另一个集群的服务。等某一天,我想把http://blog.renwei.net迁到另外一个地方算了,可能是另外的物理机或者另外的集群。很简单在新址搭建好后,新建一条http://blog.renwei.net的单独DNS解析到新址就可以了。这一条或几条DNS记录还好说,如果我用.http://renwei.net搭建了好多二级域名服务呢?都要迁到另一个集群上,我就这么一条一条改配DNS记录么(配DNS当然也很简单)?有externalName Service就可以不必配这么多DNS记录了,我在新集群上给服务配上两个域名(一个原域名,一个临时的新域名,用这个新域名是因为externalName只支持域名),在原集群里,把老服务的service修改成externalName类型,值就是临时的新域名。等我一个一个把服务都这么迁过去后,我就可以*.http://renwei.net直接改解析到新集群即可