歡迎光臨
每天分享高質量文章
當前位置：知識星球 > 後端 > 正文

為什麼說Kubernetes是新一代的應用伺服器 ？

2018-07-18 分類：後端 閱讀(438) 評論(0)

你有沒有想過為什麼你要使用容器部署你的多平臺應用程式？這隻是“跟隨炒作”的問題嗎？在本文中，我將要問一些挑釁性的問題，以說明為什麼Kubernetes是新一代的應用伺服器。
您可能已經註意到大多數語言都是被interpreted並使用runtime來執行您的原始碼。 理論上，大多數Node.js、Python和Ruby程式碼可以輕鬆地從一個平臺（Windows、Mac、Linux）遷移到另一個平臺。 Java應用程式更進一步，透過將編譯後的Java類轉換為位元組碼，能夠在具有JVM（Java虛擬機器）的任何地方執行。
Java生態系統提供了一種標準格式，用於分發屬於同一應用程式的所有Java類。 您可以將這些類打包為包含嵌入的前端，後端和庫的JAR（Java歸檔），WAR（Web歸檔）和EAR（企業歸檔）。 那麼我問你：為什麼要使用容器來分發你的Java應用程式？ 難道它不應該在環境之間輕鬆移植嗎？
從開發人員的角度回答這個問題並不是顯而易見的。 但請考慮一下您的開發環境以及由它與生產環境之間的差異引起的一些可能問題：

  • 你使用的是Mac、Windows還是Linux？ 您是否遇到過與’\’vs’/’作為檔案路徑分隔符相關的問題？

  • 你使用的是什麼版本的JDK？ 你是否在開發中使用Java 10，但生產使用JRE 8？ 您是否遇到過JVM差異引入的錯誤？

  • 你使用的是什麼版本的應用伺服器？ 生產環境是否使用相同的配置，安全補丁和庫版本？

  • 在生產部署期間，您是否遇到過由於驅動程式或資料庫伺服器的版本不同而導致的JDBC驅動程式問題，而在開發環境中卻沒有出現？

  • 你有沒有遇到當你要求應用伺服器管理員建立一個資料源或一個JMS佇列的時候，它卻包含一個錯誤的字元？

上述所有問題都是由應用程式外部因素引起的，容器最重要的一點是您可以部署所有應用程式（例如，Linux發行版，JVM，應用程式伺服器，庫，配置以及您的最終應用程式）在預先構建好的容器中。 另外，執行一個內建了所有內容的容器比將程式碼移動到生產環境並嘗試在不工作時解決差異要容易得多。 由於它很容易執行，因此將同一容器水平擴充套件多個副本也變得很容易。


強化你的應用

在容器變得非常流行之前，應用程式伺服器提供了幾個Non-functional requirement[1]，例如安全性，隔離性，容錯性，配置管理等。 做個類比，應用程式好比CD，應用程式伺服器就好比是CD播放器。
作為開發人員，您將負責遵循預定義的標準，並以特定格式分發應用程式，而另一方面，應用程式伺服器將“執行”您的應用程式，並提供可能因不同“品牌”而異的其他功能。 在Java世界中，應用程式伺服器提供的企業功能標準最近已在Eclipse基礎之下有了新的發展。 基於Eclipse Enterprise for Java（EE4J）的工作已經誕生了Jakarta EE。 （欲瞭解更多資訊，請閱讀文章Jakarta EE正式釋出[2]或觀看DevNation影片Jakarta EE：Java EE的未來[3]。）
繼續CD播放器的類比，隨著容器的提升，容器映象已經成為新的CD格式。 事實上，容器映象只不過是分發容器的格式。（如果您需要更好地處理容器映象以及它們如何分發，請參閱容器術語的實用介紹[4]。）
當您需要嚮應用程式新增企業級功能時，才能體會到容器的真正好處。 向容器化應用程式提供這些功能的最佳方式是使用Kubernetes作為它們的平臺。 此外，Kubernetes平臺為其他專案（如Red Hat OpenShift，Istio和Apache OpenWhisk）提供了良好的基礎，可以構建和部署強大的生產級別質量的應用程式。
讓我們來探索其中的九個功能：

1、服務發現
服務發現是確定如何連線到某個服務的過程。 要獲得容器和雲原生應用程式的諸多好處，您需要從容器映象中隔離配置，以便在所有環境中使用相同的容器映象。 應用程式的外部化配置是12-factor應用程式的關鍵原則之一。 服務發現是從執行時環境獲取配置資訊的方法之一，而不是在應用程式中進行硬編碼。 Kubernetes提供開箱即用的服務發現。 Kubernetes還提供ConfigMaps和Secrets以從應用程式容器中隔離配置。 Secerets解決了當您需要儲存憑據以連線到執行時環境中的資料庫等服務時出現的一些挑戰。
使用Kubernetes，不需要使用外部伺服器或框架。 儘管您可以透過Kubernetes YAML檔案管理每個執行時環境的環境設定，但紅帽OpenShift提供了一個GUI和CLI，可以讓DevOps團隊更容易管理。
2、基本呼叫
在容器內部執行的應用程式可以透過Ingress訪問進行訪問——換句話說，就是從外部世界到您正在暴露的服務。 OpenShift使用HAProxy提供路由物件，HAProxy具有多種功能和負載均衡策略。 您可以使用路由功能進行滾動部署。 這是一些非常複雜的CI / CD策略的基礎。 請參閱下麵的“6、構建和部署管道”。
如果您需要執行一次性作業（例如批處理），或者只是利用群集來計算結果（例如計算Pi的小數位），該怎麼辦？ Kubernetes為這個用例提供了job物件。 還可以使用cron job來管理基於時間的job。
3、伸縮性
Kubernetes透過使用ReplicaSets（以前稱為Replication Controllers）來解決彈性問題。 就像Kubernetes的大多數配置一樣，ReplicaSet是協調所需狀態的一種方式：您告訴Kubernetes系統應該處於什麼狀態，Kubernetes會如何實現它。 ReplicaSet可以隨時控制應執行的應用程式的副本數量或確切副本數量。
但是，如果您構建的服務比您計劃的更受歡迎或者計算資源耗盡，會發生什麼？ 您可以使用Kubernetes Horizontal Pod Autoscaler，它根據觀察到的CPU利用率（或者透過自定義度量標準支援，或者根據某些其他應用程式提供的度量標準）來自動伸縮Pod數量。
4、日誌
由於您的Kubernetes叢集執行著容器化應用程式的多個副本，因此集中這些日誌以便可以在一個位置檢視它們變得非常重要。 此外，為了利用自動縮放（以及其他雲原生功能）等優勢，您的容器必須是不可變的。 所以你需要將你的日誌儲存在你的容器之外，這樣它們將在整個執行期間保持不變。 OpenShift允許您部署EFK堆疊以聚合來自主機和應用程式的日誌，無論它們來自多個容器，還是來自已經刪除的容器。
EFK堆疊由以下部分組成：

  • Elasticsearch（ES），一個儲存所有日誌的物件儲存系統

  • Fluentd，從節點收集日誌並將其提供給Elasticsearch

  • Kibana，Elasticsearch的Web使用者介面

5、監控
雖然日誌和監控看起來是為瞭解決同樣的問題，但它們彼此不同。監控是觀察，檢查，異常報警，以及記錄。 而日誌僅僅是記錄。
Prometheus是一個開源的監控系統，包含時序資料庫。 它可用於儲存和查詢度量標準，提醒並使用視覺化來深入瞭解您的系統。 Prometheus可能是監控Kubernetes叢集最流行的選擇。 在Red Hat Developers[5]部落格上，有幾篇文章涉及如何使用Prometheus進行監控。 您還可以在OpenShift部落格上找到Prometheus相關的文章。
您也可以透過https://learn.openshift.com/servicemesh/3-monitoring-tracing與Istio一起參與Prometheus。
6、編譯和部署管道
CI / CD（持續整合/持續交付）管道不是嚴格的“必備要求”。 但是，CI / CD通常被視為成功的軟體開發和DevOps實踐的支柱。 所有軟體都應該透過CI / CD管道部署到生產環境中。 Jez Humble和David Farley撰寫的持續交付：透過構建，測試和部署自動化實現可靠的軟體釋出[6]一書中如此描述CD：“持續交付是能夠獲取所有型別的更改——包括新功能，配置更改，錯誤修複和實驗——以可持續的方式安全快速地投入到生產或使用者手中。”
OpenShift將CI / CD流水線作為“構建策略”且開箱即用。請檢視我兩年前錄製的一個影片[7]，一個新微服務的Jenkins CI / CD管道的示例。
7、彈性
雖然Kubernetes為群集本身提供了彈性選項，但它還可以透過提供支援replicated volumes的PersistentVolumes來幫助應用程式變得更加具有彈性。 Kubernetes的ReplicationController / deployments可確保指定數量的Pod副本在整個群集中一致地部署，從而自動處理任何可能的節點故障。
結合彈性，容錯功能是解決使用者可靠性和可用性問題的有效手段。 透過它的重試規則，斷路器和pool ejection，也可以透過Istio為執行在Kubernetes上的應用程式提供容錯功能。 請參閱https://learn.openshift.com/servicemesh/7-circuit-breaker上的Istio Circuit Breaker教程。
8、鑒權
Istio還可以透過其相互TLS身份驗證來提供Kubernetes中的身份驗證，該身份驗證旨在增強微服務及其通訊的安全性，而無需更改服務程式碼。 它負責：

  • 為每個服務提供基於角色的身份，以實現跨群集和雲的互操作性

  • 確保服務到服務的通訊和終端使用者到服務的通訊的安全性

  • 提供金鑰管理系統，自動化金鑰和證書生成，分發，輪換和撤銷

此外，值得一提的是，您也可以在Kubernetes / OpenShift群集中執行Keycloak以提供身份驗證和授權。 Keycloak是Red Hat Single Sign-on的上游產品。 有關更多資訊，請閱讀使用Keycloak輕鬆實現單點登入[8]。 如果您使用的是Spring Boot，請觀看DevNation影片：使用Keycloak安全部署Spring Boot Microservices[9]或閱讀部落格文章[8]。
9、鏈式追蹤
啟用Istio的應用程式可以使用Zipkin或Jaeger實現分散式追蹤。 無論您使用何種語言，框架或平臺構建應用程式，Istio都可以啟用分散式跟蹤。 請訪問https://learn.openshift.com/servicemesh/3-monitoring-tracing檢視詳情。 另請參閱Laptop上的Istio和Jaeger入門[10]以及最近的DevNation影片：使用Jaeger跟蹤高階微服務[11]。


應用程式伺服器已經成為明日黃花？

透過這些功能，您可以瞭解Kubernetes + OpenShift + Istio如何真正為您的應用程式提供支援，並提供過去由應用程式伺服器或Netflix OSS等軟體框架負責的功能。 這是否意味著應用伺服器已經死亡？
在新的容器化世界裡，應用伺服器正在變得越來越像框架。軟體開發的發展很自然地導致了應用伺服器的發展。 這種演變的一個很好的例子是Eclipse MicroProfile規範，它將WildFly Swarm作為應用程式伺服器，為開發人員提供容錯，配置，跟蹤，REST（客戶端和伺服器）等功能。 但是，WildFly Swarm和MicroProfile規範設計得非常輕巧。 WildFly Swarm沒有完整的Java企業應用程式伺服器所需的大量元件。 相反，它專註於微服務，並擁有足夠的應用程式伺服器，來構建和執行您的應用程式，就像一個可執行.jar檔案那麼簡單。 您可以在部落格上閱讀有關MicroProfile[12]的更多資訊。
此外，Java應用程式可以具有諸如Servlet引擎，資料源池，依賴註入，事務，訊息傳遞等功能。 當然，框架可以提供這些功能，但是應用程式伺服器還必須擁有在任何環境中構建，執行，部署和管理企業應用程式所需的一切，無論它們是否在容器內。 事實上，應用伺服器可以在任何地方執行，例如，裸機，虛擬化平臺（如Red Hat Virtualization），私有雲環境（如Red Hat OpenStack Platform），以及公共雲環境（如Microsoft Azure或Amazon Web Service）。
一個好的應用程式伺服器可以確保提供的API與其實現之間的一致性。 開發人員可以確定部署其業務邏輯（需要的各種功能）將正常工作，因為應用程式伺服器開發人員（以及定義的標準）已確保這些元件協同工作並一起發展。 此外，一個好的應用伺服器還負責最大化吞吐量和可擴充套件性，因為它將處理來自使用者的所有請求；減少延遲並縮短載入時間，因為它有助於您的應用程式的可處置性；輕量級，記憶體佔用少，可最大限度地減少硬體資源和成本；最後，要足夠安全以避免任何安全漏洞。 對於Java開發人員，Red Hat提供了紅帽JBoss企業應用程式平臺，它滿足了現代模組化應用程式伺服器的所有要求。
結論

容器映象已成為分散式雲原生應用程式的標準打包格式。 雖然容器“本身”不能為應用程式提供真正的業務優勢，但Kubernetes及其相關專案（如OpenShift和Istio）提供了以前屬於應用程式伺服器的非功能性需求。
開發人員過去從應用程式伺服器或諸如Netflix OSS之類的庫中獲得的大多數非功能性需求都系結到特定語言，例如Java。 另一方面，當開發人員選擇使用Kubernetes + OpenShift + Istio滿足這些要求時，他們不會附加到任何特定語言，這可以鼓勵為每個用例使用最佳技術/語言。
最後，應用伺服器仍然在軟體開發中佔有一席之地。 但是，它們正在變得更像是特定於語言的框架，這是開發應用程式時的一個很好的捷徑，因為它們包含許多已經編寫和測試過的功能。
遷移到容器，Kubernetes和微服務的最好的事情之一就是，您不必為您的應用程式選擇單個應用程式伺服器，框架，架構風格甚至語言。 您可以使用執行現有Java EE應用程式的JBoss EAP輕鬆部署容器，也可以使用Wildfly Swarm或Eclipse Vert.x進行響應式程式設計的新微服務。 這些容器都可以透過Kubernetes進行管理。 要瞭解這個概念，請檢視Red Hat OpenShift Application Runtimes[13]。 講述瞭如何利用Launcher Service[14]來線上構建和部署一個使用WildFly Swarm，Vert.x，Spring Boot或Node.js的示例應用程式。 還可以透過選擇Externalized Configuration任務以瞭解如何使用Kubernetes ConfigMaps。 這將是您開始學習雲原生應用程式的良好開端。
你可以說Kubernetes/OpenShift是新的Linux，也可以說Kubernetes是新的應用程式伺服器。但事實是應用程式伺服器/執行時+OpenShift/ Kubernetes + Istio已成為“事實上的”雲原生應用程式平臺！
相關連結：

  1. https://en.wikipedia.org/wiki/Non-functional_requirement#Examples

  2. https://developers.redhat.com/blog/2018/04/24/jakarta-ee-is-officially-out/

  3. https://developers.redhat.com/videos/youtube/f2EwhTUmeOI/

  4. https://developers.redhat.com/blog/2018/02/22/container-terminology-practical-introduction/

  5. https://developers.redhat.com/blog/

  6. https://www.amazon.com/dp/0321601912?tag=contindelive-20

  7. https://www.youtube.com/watch?v=N8R3-eNVoEc

  8. https://developers.redhat.com/blog/tag/keycloak/

  9. https://developers.redhat.com/videos/youtube/Bdg_DjuoX0A/

  10. https://developers.redhat.com/blog/2018/05/08/getting-started-with-istio-and-jaeger-on-your-laptop/

  11. https://developers.redhat.com/blog/2018/06/20/next-devnation-live-advanced-microservices-tracing-with-jaeger-june-21st-12pm-edt/

  12. https://developers.redhat.com/blog/tag/microprofile/

  13. https://developers.redhat.com/products/rhoar/overview/

  14. https://developers.redhat.com/launch/

原文連結：https://developers.redhat.com/blog/2018/06/28/why-kubernetes-is-the-new-application-server/
Kubernetes入門與進階實戰培訓

本次培訓包括：Docker介紹、Docker映象、網路、儲存、容器安全；Kubernetes架構、設計理念、常用物件、網路、儲存、網路隔離、服務發現與負載均衡；Kubernetes核心元件、Pod、外掛、微服務、雲原生、Kubernetes Operator、叢集災備、Helm等，點選下方圖片檢視詳情。

8月17日正式上課，點選閱讀原文連結即可報名。
贊(0)
標籤：

相關推薦

熱門標籤

iOS (11238)微軟 (4955)Linux (4274)安全 (4180)Python (4161)效能 (3165)運維 (2774)最佳化 (2419).NET (2262)Google (2136)機器學習 (1795)併發 (1613)分散式 (1559)叢集 (1240)SQL (1174)Mysql (1060)區塊鏈 (1017)Docker (977)微服務 (922)面試 (919)Apache (743)NLP (725)Redis (719)Android (668)Git (640)架構師 (632)Nginx (630)Facebook (599)JVM (595)爬蟲 (476)

熱門文章

分享創造快樂