TF+K8s輕鬆上手丨經過Kubernetes Ingress進行高級外部應用程序鏈接

本文全部相關連接pdf：https://tungstenfabric.org.cn/assets/uploads/files/tf-ceg-case-2.pdf

Kubernetes的Ingress文檔頁面將其描述爲：

「用於管理對集羣中服務的外部訪問的API對象，一般是HTTP。Ingress能夠提供負載均衡、SSL終結和基於名稱的虛擬主機。」

CNI不提供Ingress功能。這意味着Kubernetes集羣管理者一般要爲其集羣安裝、管理和支持單獨的Ingress控制器解決方案。

對於沒有內置Ingress支持的本地和公共雲中的Kubernetes部署，Tungsten Fabric捆綁了本身的Ingress控制器。它在後臺使用HAProxy並實現了Kubernetes Ingress文檔頁面中所述的全部基本功能。

在AWS上運行時，能夠將Kubernetes 配置爲使用AWS的Application Load Balancer （ALB）爲其Ingress服務。經過這種方式的設置，沙箱中的Kubernetes能夠最緊密地反映典型的現實部署場景。

下圖概述了示例應用程序的最終部署架構：

使用場景

Ingress控制器選項僅與使用HTTP或HTTPS的應用程序兼容。若是您的應用程序是這種狀況，可能須要考慮使用Ingress來實現如下目標：

• 使用HTTPS保護應用程序，而後經過配置Ingress進行SSL卸載來將程序公開在網絡上；和/或
• 基於請求中的HTTP路徑，將傳入請求定向到不一樣的Kubernetes Services，例如，/blog/能夠轉到Service A，而/account/能夠轉到Service B，等等。和/或
• 經過基於名字的虛擬主機，應用程序服務於多個DNS域，例如Host:頭設置爲test.project.com的應用去Service C，而那些具備prod.project.com的去Service D。

經過Ingress公開示例應用

在探討上述三種狀況以前，讓咱們部署一個簡單的Ingress示例應用程序，相似於咱們對 LoadBalancer的作法，而後在此基礎上進行構建。

確保您位於沙箱控制節點上，以root用戶身份登陸，而且位於正確的目錄中：

#確認您是root帳戶

whoami | grep root || sudo -s

#切換爲清單目錄

cd /home/centos/yelb/deployments/platformdeployment/Kubernetes/yaml

#部署具備Ingress的示例程序

kubectl create -f cnawebapp-ingress-alb.yaml

幾分鐘後，部署過程應該完成了，咱們應該可以從Internet訪問示例應用程序。首先找到Ingress的DNS名稱：

根據上面的輸出，如今能夠從Internet上的http://539db10e-default-yelbui-3c9c-1330819777.us-west-1.elb.amazonaws.com上訪問咱們的示例應用程序。

利用在環境中運行上述命令得到的DNS名稱訪問Yelb，以確保其有效。

使用HTTPS保護應用程序的安全

對於此練習，咱們須要生成自簽名證書，並將其添加到AWS Certificate Manager。提供Ingress功能的AWS Application Load Balancer（ALB）須要使用此功能來執行加密。

注意：對於生產用途，可能須要經過AWS Certificate Manager的相應功能來得到完整註冊域名的「適當」證書。因爲咱們只是在進行練習，所以將使用自簽名的虛構域。

步驟1：生成自簽名證書，並將其添加到AWS Certificate Manager

在安裝了具備Access和Secret密鑰的AWS CLI工具的主機上執行如下步驟。這裏的密鑰容許您對Certificate Manager進行更改。

#爲虛構的域名（yelb.mydomain.com）生成自簽名證書：

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=yelb.mydomain.com"

#將新的證書加入到AWS Certificate Manager
#注意「--region」 -這必須是同一個AWS區域
#在咱們的例子中，運行Tungsten 沙箱時，它是「us-west-1」

aws acm import-certificate --certificate file://tls.crt --private-key file://tls.key --region us-west-1

若是一切順利，最後一條命令將顯示相似內容：

{
"CertificateArn": "arn:aws:acm:us-west-1:180612498884:certificate/e7341ff5-52ef-4a7b-94b5-05643ef6ab46"
}

咱們將須要CertificateArn後面的值，以進行下一步。

步驟2：創建Ingress定義

確保您位於沙箱控制節點上，以root用戶身份登陸，而且位於正確的目錄中：

#肯定您是root身份

whoami | grep root || sudo -s

#切換爲清單目錄

cd /home/centos/yelb/deployments/platformdeployment/Kubernetes/yaml

如今，讓咱們建立一個新的Ingress定義：

接下來，咱們將CertificateArn放入。在運行該命令以前對其進行編輯，並用執行步驟1時得到arn:aws:acm:us-west-1:180612498884:certificate/e7341ff5-52ef-4a7b-94b5-05643ef6ab46的值替換該命令CertificateArn。

sed-i"s#INSERT_CERT_ARN_HERE#arn:aws:acm:us-west-1:180612498884:certificate/e7341ff5-52ef-4a7b-94b5-05643ef6ab46#" ingress-https.yaml

若是命令成功運行，則ingress-https.yaml文件將具備自簽名證書的ARN，而不是字符串INSERT_CERT_ARN_HERE。

步驟3：創建HTTPS Ingress並進行測試

#建立新的 Ingress

kubectl create -f ingress-https.yaml

運行上述命令後，請等待幾分鐘，以使新的ALB Ingress出現。而後，讓咱們找到已爲其分配的DNS名稱，並嘗試鏈接到它：

從上面的輸出中，咱們能夠看到新Ingress的地址；讓咱們看看它是否有效：

這說明它有效——咱們能夠經過加密鏈接訪問Yelb應用程序！

新拓撲看起來像這樣（請注意，咱們仍然具備未在此圖中顯示的原始HTTP Ingress）：

總結：爲何要這樣作？

除了增長最終用戶的鏈接安全性、隱私性和數據完整性外，實現HTTPS Ingress還有一些好處：

• 應用程序消耗較少的計算資源，由於加密開銷已轉移到ALB；
• 應用程序如今支持HTTP / 2，這是一件好事；
• 能夠輕鬆實現將 HTTP 自動重定向到HTTPS的功能。

清理

讓咱們刪除添加的HTTPS Ingress，由於在本章的其他部分中咱們再也不須要它：

kubectl delete -f ingress-https.yaml

而後，在執行步驟1（生成自簽名證書並將其安裝到AWS Certificate Manager中）的計算機上，運行如下命令以刪除該證書，並確保使用您本身的值CertificateArn：

aws acm delete-certificate --certificate-arn arn:aws:acm:us-west-1:180612498884:certificate/e7341ff5-52ef-4a7b-94b5-05643ef6ab46

根據URL路徑定向請求

在某些狀況下，您可能想在同一個DNS域名下運行多個應用程序。例如，www.corp.com可能支持您的主應用程序，而諸如WordPress之類的其餘應用程序可能正在處理www.corp.com/blog。

對於本練習，咱們假設您在「經過Ingress公開示例應用程序」這一章的開頭按照說明運行了Yelb副本。若是您是從頭開始，請跳至該部分，按照說明進行部署，而後再回來。

爲了演示經過URL路徑進行的路由，咱們將在環境中添加另外一個部署，並相應地更新Ingress的配置。在此新配置下，Ingress會將對/路徑的請求定向到咱們的主應用程序yelb，而對/echo的路徑請求將定向爲新的應用程序EchoServer。

這是目標狀態的圖：

咱們應該已經將Yelb的部分放置到位，因此咱們添加EchoServer：

#建立EchoServer Deployment and Service 清單:

#如今部署它:

kubectl create -f echoserver.yaml

接下來，咱們將爲Ingress建立一個更新的配置。爲此，咱們將從中複製Ingress資源cnawebapp-ingress-alb.yaml，並在路由部分進行兩項更改：

1. 將yelb的路徑從/*更新到/以避免干擾echoserver；和

2. 添加新的/echo路徑指向echoserver

注意：咱們之因此要包含完整的資源定義而不是僅僅應用差別部分，是由於Ingress對象不支持戰略性合併修補。

#更新的Ingress資源:

#如今部署它:

kubectl apply -f ingress-paths.yaml

這裏會顯示一個關於kubectl apply的警告，這個警告能夠忽略。由於咱們的更新資源在本質上與rules配置相同。

更新的配置在幾秒鐘內生效，以後咱們就能夠檢查基於URL的路由是否有效。當咱們請求基本URL /（或爲空）時，咱們應該到達Yelb，若是請求/echo，咱們應該返回的輸出是EchoServer。

#得到Ingress的基本URL

baseUrl=$(kubectl get ing yelb-ui | grep amaz | awk '{print $3}')
echo "Our Ingress is at: ${baseUrl}"

#嘗試訪問$baseUrl ; 應當能夠獲得Yelb UI頁面的內容

curl http://${baseUrl}

#如今嘗試/echo ; 應當獲得EchoServer的輸出

curl http://${baseUrl}/echo

服務多個DNS域

當您擁有多個域名，而且爲每一個域提供不一樣的應用程序，同時但願共享相同的Ingress基礎結構，此場景中的解決方案就頗有用。這有助於節省成本，而且在某些狀況下，與每一個域名擁有專用的Ingress實例相比，其複雜性更低。

此練習創建在上一個基於URL定向請求的練習的基礎上。若是還沒有完成，請回顧此前步驟，簡單地剪切並粘貼建立和部署echoserver.yaml清單的步驟。咱們將爲Ingress新建一個，所以無需建立和部署ingress-paths.yaml。

準備好後，您應該已經有了yelb的副本和echoserver的副本。您的Ingress配置是什麼都無所謂，由於咱們將覆蓋它。

在咱們的目標狀態下，Ingress將定義兩個域名yelb.mydomain.com和echo.mydomain.com，並將根據Host:HTTP頭中的值來路由傳入的請求，Web瀏覽器會自動爲您請求的URL的主機部分插入這些請求。

這是目標狀態的圖：

讓咱們爲Ingress建立並部署配置，該配置將執行所需的路由：

#更新的Ingress 資源:

#如今部署它：

kubectl apply -f ingress-hosts.yaml

配置成功應用後，咱們就能夠進行測試了。因爲域名和主機造成映射，所以咱們將利用curl添加正確的Host:標頭。當設置爲yelb.mydomain.com，應該到達Yelb，設置爲echo.mydomain.com時，應該返回輸出EchoServer。

#Get the base URL of our Ingress

baseUrl=$(kubectl get ing yelb-ui | grep amaz | awk '{print $3}')
echo "Our Ingress is at: ${baseUrl}"

#訪問Ingress Host: 設置成 yelb; 咱們應當能夠獲得Yelb UI頁面的內容

curl http://${baseUrl} -H "Host: yelb.mydomain.com"

#現場嘗試訪問Host:設置成 echo;咱們應當能夠獲得 EchoServer的輸出

curl http://${baseUrl} -H "Host: echo.mydomain.com"

清理

一旦進行了足夠的測試，請隨時清理：

#刪除「yelb」和「hoserver」應用:

kubectl delete -f cnawebapp-ingress-alb.yaml
kubectl delete -f echoserver.yaml

#刪除咱們建立的額外的清單:

rm -f echoserver.yaml ingress-paths.yaml ingress-hosts.yaml

回顧和下一步

Kubernetes提供了三種將應用程序公開給外界的基本方式：LoadBalancer或NodePort服務類型以及Ingress。前兩個協議支持任意協議，但在協議智能方面並無增長太多。另外一方面，Ingress提供了基於協議的功能，這使其僅與HTTP或HTTPS的應用程序兼容。

與其餘功能相似，Kubernetes須要一個控制器來實現實際的Ingress功能——簡單地在Kubernetes API中建立Ingress資源並不能執行任何操做。Ingress控制器是Kubernetes集羣管理員必須安裝、監視、修補和升級的軟件的一部分。Tungsten Fabric隨附有Ingress控制器，這將使此過程更加容易。

一旦肯定了應用程序該如何公開於Internet，就須要考慮如何處理有關網絡訪問控制的問題。閱讀本指南中的用例3和用例4，咱們將介紹其中的一些場景。

（本公衆號將陸續發佈幾個用例的詳細內容，敬請關注）

---

MORE
更多TF+K8s文章
第一篇：TF Carbide 評估指南--準備篇
第二篇：經過Kubernetes的服務進行基本應用程序鏈接

關注微信：TF中文社區