2017-01-02 231 views
3

我對網絡,SSL和NGINX有點新鮮,因此如果我錯過了某些明顯的東西,那麼這些東西就會裸露出來。爲了說明這一點,我正在研究GCE和Kuberenetes。我的目標僅僅是通過SSL公開羣集上的所有微服務。理想情況下,它的工作方式與通過type ='LoadBalancer'公開部署並獲取單個外部IP時的工作方式相同。這是我的目標,但SSL不適用於這些基本的負載平衡器。Kubernetes,GCE,負載均衡,SSL

從我的研究中,當前最好的解決方案是設置一個nginx入口控制器,使用入口資源和服務來公開我的微服務。下面是我對這個過程的理解所繪製的圖表。

enter image description here

我已經得到了這一切能夠成功通過HTTP。我從這裏部署了默認的nginx控制器:https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx。以及缺省後端的默認後端和服務。我自己的微服務的入口將規則設置爲我的域名和路徑:/。

這很成功,但有兩件事讓我感到困惑。

  1. 當暴露的服務資源爲我的後端(微服務)一個導向我跟着常用的類型=「NodePort」,另一隻是把一個端口到達服務。兩者都將目標端口設置爲後端應用程序端口。我嘗試了這兩種方式,他們都似乎工作。引導一個是從上面的鏈接。指南2:http://blog.kubernetes.io/2016/03/Kubernetes-1.2-and-simplifying-advanced-networking-with-Ingress.html。這裏有什麼不同?

  2. 另一個混淆之處是我的入口總是有兩個IP。我最初的思考過程是應該只有一個外部IP,這會打到我的入口,然後由nginx指導路由。或者是直接向nginx的ip?無論如何,創建的第一個IP地址似乎給了我訪問第二個IP失敗的預期結果。

儘管我很困惑,但事情似乎在HTTP上正常工作。通過HTTPS不是那麼多。起初,當我通過https發起網絡請求時,事情就會掛起。我在我的防火牆規則上打開了443個似乎可行的工作,但是我打到了默認的後端而不是我的微服務。

閱讀引導我從Kubernetes文檔中得知:目前,Ingress資源僅支持http規則。 這可以解釋爲什麼我點擊默認後端,因爲我的規則只適用於HTTP。但是,如果是這樣,我應該如何使用SSL的這種方法?

我注意到的另一件事是,如果我編寫一個沒有規則的入口資源,並給它我想要的後端,我仍然被定向到我原來的默認後端。這更奇怪,因爲kubectl描述更新,並指出我的默認後端是我想要的後端...

任何幫助或指導將不勝感激。謝謝!

+0

您可以將您的JSON/YAML文件入口和服務的配置? –

回答

4

因此,對於#2,您可能最終會配置Google HTTP(S)LoadBalancer,可能是因爲您缺少kubernetes.io/ingress.class: "nginx"註釋,如此處所述:https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx#running-multiple-ingress-controllers

GKE擁有自己的入口控制器,您需要通過在nginx部署上粘貼該註釋來重寫。 This article對這些東西有很好的解釋。

kubernetes docs有什麼NodePort意味着一個很好的說明 - 基本上,該服務將從高範圍在羣集中的每個節點分配一個端口和節點會轉發流量從該端口爲你服務。這是在不同環境中設置負載均衡器的一種方式,但對於您的方法而言,這不是必需的。您可以省略微服務的服務的type字段,它將被分配默認類型,即ClusterIP

至於SSL,它可能是一些不同的東西。我會確保你已經設置了祕密,就像他們在nginx controller docs中所描述的那樣,例如使用tls.certtls.key字段。

我也會檢查nginx控制器的日誌 - 找出它運行的是哪個pod,與kubectl get pods一樣,然後拖拽它的日誌:kubectl logs nginx-pod-<some-random-hash> -f。這將有助於確定您是否配置了任何錯誤,例如服務沒有配置任何端點。大部分時間我都搞砸了入侵的東西,這是由於服務/部署的一些非常基本的錯誤配置。

您還需要設置DNS記錄爲您的主機名指向負載均衡器的靜態IP,否則ping通與捲曲的-Hflag as they do in the docs您服務,否則你可能最終得到路由到默認後端404

1

直接回應你的問題,因爲這是整個點...免責聲明:我是一個n00b,所以把這一切都用一粒鹽。

對於#2,博客文章我鏈接下面提示如下結構:

  • 創建部署nginx的控制器莢
  • 創建一個類型負載平衡器和靜態的服務的部署IP的路由流量控制器莢
  • 創建一個入口的資源,被使用nginx的控制器莢
  • 創建被使用nginx的控制器莢終止SSL
  • 祕密
  • 和其他的東西太

據我瞭解,在HTTP和https的事情發生與nginx的控制器豆莢。我的所有入口規則也都是http,但是nginx入口控制器強制SSL並負責所有這些,終止控制器上的SSL,以便低於它的所有入口內容都可以是HTTP。我有所有http規則,但是通過LoadBalancer服務的所有流量都被迫使用SSL。

再次,我是一個n00b。把這一切都用一粒鹽。我用外行人的話來說,因爲我是一個外行人,試圖把這一切都弄清楚。

我遇到你的問題,同時尋找一些自己的問題的答案。我遇到了很多與你碰到的相同的問題(我假設過去時已經過去了)。我想指出你(和/或其他有類似問題的人)的博客文章,我發現在學習nginx控制器時很有幫助。到目前爲止(我還處於早期階段,正在使用這篇文章),帖子中的所有內容都起作用了。

你可能已經過去了,現在已經過了幾個月了。但也許這將幫助別人,即使它不能幫助你:

https://daemonza.github.io/2017/02/13/kubernetes-nginx-ingress-controller/

它幫助我理解需要什麼樣的資源來創建,如何部署控制器吊艙,以及如何公開控制器莢(創建一個靜態IP控制器莢負載均衡器服務),也迫使SSL。它幫助我跳過一些障礙,讓過去的「如何做所有的運動部件結合在一起」。

的Kubernetes技術文檔是如何使用每件有益的,但像他這樣的博客文章確實不一定把錢全出來,一巴掌拼在一起。免責聲明:博客文章的模式可能不是最好的辦法,雖然這樣做(我沒有足夠的經驗來打這通電話),但它確實幫助我至少也得強迫Nginx上進入控制器的工作示例SSL。

希望這可以幫助別人也說不定。

安德魯