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直接改解析到新集群即可

ingress調用其他命名空間配置

免責聲明！