為什麼Kubernetes是新的應用伺服器?
你有沒有想過為什麼要使用容器部署多平臺應用程式？這只是“追隨炒作”的問題嗎？在本文中，我將提出一些挑釁性的問題來說明為什麼Kubernetes是新的應用程式伺服器。
您可能已經注意到大多數語言都被解釋並使用“執行時”來執行原始碼。理論上，大多數Node.js，Python和Ruby程式碼可以輕鬆地從一個平臺（Windows，Mac，Linux）移動到另一個平臺。通過將已編譯的Java類轉換為位元組碼，Java應用程式更進一步，能夠在任何具有JVM（Java虛擬機器）的地方執行。
Java生態系統提供了一種標準格式，用於分發屬於同一應用程式的所有Java類。您可以將這些類打包為JAR（Java Archive），WAR（Web Archive）和EAR（Enterprise Archive），其中包含前端，後端和嵌入的庫。所以我問你：為什麼使用容器來分發你的Java應用程式？難道它不應該在環境之間輕鬆移植嗎？
從開發人員的角度回答這個問題並不總是顯而易見的。但請考慮一下您的開發環境以及由它與生產環境之間的差異引起的一些可能問題：
- 你使用Mac，Windows還是Linux？你有沒有遇到相關的問題 \與/作為檔案路徑分隔符？
- 您使用的是哪個版本的JDK？您是否在開發中使用Java 10，但生產使用JRE 8？您是否遇到過JVM差異引入的任何錯誤？
- 您使用的是哪個版本的應用程式伺服器？生產環境是使用相同的配置，安全修補程式和庫版本嗎？
- 在生產部署期間，您是否遇到過由於驅動程式或資料庫伺服器的不同版本而未在開發環境中遇到的JDBC驅動程式問題？
- 你有沒有要求應用伺服器管理員建立一個數據源或一個JMS佇列，它有一個錯字？
上面的所有問題都是由應用程式外部的因素引起的，容器的最大優點之一是您可以部署所有內容（例如，Linux發行版，JVM，應用程式伺服器，庫，配置，最後，您的應用程式）在預先構建的容器內。此外，執行一個內建了所有內容的容器比將程式碼移動到生產環境並嘗試在不起作用時解決差異要容易得多。由於它易於執行，因此也可以輕鬆地將同一容器映像擴充套件為多個副本。
增強您的應用程式
在容器變得非常流行之前，應用程式伺服器提供了幾個ofollow,noindex" target="_blank">NFR（非功能性要求）， 例如安全性，隔離性，容錯性，配置管理等。作為類比，應用伺服器類似CD（光碟）播放器對CD的應用。
作為開發人員，您將負責遵循預定義的標準並以特定格式分發應用程式，而另一方面，應用程式伺服器將“執行”您的應用程式並提供可能因不同“品牌”而異的其他功能。 ：在Java世界中，應用程式伺服器提供的企業功能標準最近已在Eclipse基礎之下發生變化。關於Eclipse Enterprise for Java（EE4J ）的工作已經產生了 Jakarta EE 。
按照類似CD播放器作為類比，隨著容器的提升，容器映象 已成為新的CD格式。實際上，容器映象只不過是用於分發容器的格式。
當您需要嚮應用程式新增企業功能時，容器的真正好處就會發生。為容器化應用程式提供這些功能的最佳方法是使用Kubernetes作為它們的平臺。此外，Kubernetes平臺為其他專案（如Red Hat OpenShift ，Istio 和Apache OpenWhisk） 提供了良好的基礎，可以構建和部署強大的生產質量應用程式。
讓我們探討其中的九個功能：
1 - 服務發現
服務發現是確定如何連線服務的過程。要獲得容器和雲原生應用程式的許多好處，您需要從容器映像中刪除配置，以便在所有環境中使用相同的容器映像。應用程式的外部化配置是12因子應用程式 的關鍵原則之一。
。服務發現是從執行時環境獲取配置資訊的方法之一，而不是在應用程式中進行硬編碼。Kubernetes提供開箱即用的服務發現 。Kubernetes還提供ConfigMaps 和Secrets 從應用程式容器中刪除配置。當您需要儲存用於連線到執行時環境中的資料庫之類的服務的憑證時，祕密可以解決一些挑戰。
使用Kubernetes，無需使用外部伺服器或框架。可以通過Kubernetes YAML檔案管理每個執行時環境的環境設定。
2 - 基本呼叫
可以通過Ingress 訪問來訪問在容器內執行的應用程式 - 換句話說，從外部世界到您正在公開的服務的路由。
如果您需要執行一次性作業（例如批處理），或者只是利用群集來計算結果（例如計算Pi的數字），該怎麼辦？Kubernetes 為此用例提供了作業物件 。還有一個管理基於時間的工作的cron工作 。
3 - 彈性
通過使用ReplicaSets （以前稱為複製控制器）在Kubernetes中解決彈性問題。就像Kubernetes的大多數配置一樣，ReplicaSet是一種協調所需狀態的方法：你告訴Kubernetes系統應該處於什麼狀態，Kubernetes會弄清楚如何製作它。ReplicaSet控制應該在任何時間執行的應用程式的副本數或精確副本數。
但是，如果您構建的服務比您計劃的更受歡迎並且計算機耗盡，會發生什麼？您可以使用KubernetesHorizontal Pod Autoscaler ，它根據觀察到的CPU利用率
4 - 記錄
由於您的Kubernetes叢集可以並將執行容器化應用程式的多個副本，因此彙總這些日誌以便在一個位置檢視它們非常重要。此外，為了利用自動縮放（以及其他雲原生功能）等優勢，您的容器必須是不可變的。因此，您需要將日誌儲存在容器之外，以便它們在執行期間保持不變。
EFK堆疊包括：
- Elasticsearch （ES），一個儲存所有日誌的物件儲存庫
- Fluentd ，從節點收集日誌並將其提供給Elasticsearch
- Kibana ，Elasticsearch的Web UI
5 - 監測
雖然日誌記錄和監控似乎解決了同樣的問題，但它們彼此不同。監控是觀察，檢查，經常警報以及記錄。記錄僅記錄。
Prometheus 是一個開源監控系統，包括時間序列資料庫。它可用於儲存和查詢指標，警報和使用視覺化，以深入瞭解您的系統。Prometheus 可能是監測Kubernetes叢集最受歡迎的選擇。
6 - 構建和部署管道
CI / CD（持續整合/持續交付）管道不是您的應用程式的嚴格“必須”要求。但是，CI / CD通常被認為是成功的軟體開發和DevOps 實踐的支柱。沒有CI / CD管道，不應將任何軟體部署到生產環境中。由Jez Humble和David Farley 撰寫的“ 持續交付：通過構建，測試和部署自動化釋出的可靠軟體 ”一書對CD說：“持續交付是能夠更改所有型別 - 包括新功能，配置更改，錯誤以可持續的方式安全快速地修復和實驗 - 進入生產或使用者手中。“
7 - 恢復力
雖然Kubernetes為群集本身 提供了彈性選項，但它還可以通過提供支援複製卷的PersistentVolumes 來幫助應用程式恢復彈性。Kubernetes的ReplicationControllers / deploymentments確保在群集中一致地部署指定數量的pod副本，從而自動處理任何可能的節點 故障。
與彈性一起，容錯是解決使用者可靠性和可用性問題的有效手段。通過其重試規則，斷路器和池彈出，也可以通過Istio 在Kubernetes上執行的應用程式提供容錯。你想親眼看看嗎？請參閱https://learn.openshift.com/servicemesh/7-circuit-breaker上 的Istio Circuit Breaker教程。
8 - 認證
Istio還可以通過其相互TLS身份驗證 來提供Kubernetes中的身份驗證 ，該身份驗證 旨在增強微服務及其通訊的安全性，而無需更改服務程式碼。它負責：
- 為每個服務提供強大的身份，代表其角色，以實現跨群集和雲的互操作性
- 確保服務到服務通訊和終端使用者到服務通訊
- 提供金鑰管理系統，以自動化金鑰和證書生成，分發，輪換和撤銷
9 - 追蹤
可以將啟用了Istio的應用程式配置為使用Zipkin 或Jaeger 收集跟蹤跨度。無論您使用何種語言，框架或平臺構建應用程式，Istio都可以啟用分散式跟蹤。
應用程式伺服器死了嗎
通過這些功能，您可以瞭解Kubernetes + OpenShift + Istio如何真正為您的應用程式提供支援，並提供以前由應用程式伺服器或Netflix OSS 等軟體框架負責的功能 。這是否意味著應用伺服器已經死了？
在這個新的集裝箱化世界中，應用伺服器正在變得更像框架。軟體開發的發展很自然地導致了應用伺服器的發展。這種演變的一個很好的例子是具有WildFly Swarm 的Eclipse MicroProfile 規範作為應用程式伺服器，它為開發人員提供容錯，配置，跟蹤，REST（客戶端和伺服器）等功能。但是，WildFly Swarm和MicroProfile規範設計得非常輕巧。WildFly Swarm沒有完整的Java企業應用程式伺服器所需的大量元件。相反，它專注於微服務，並擁有足夠的應用程式伺服器來構建和執行您的應用程式作為一個簡單的可執行.jar檔案。
此外，Java應用程式可以具有諸如Servlet引擎，資料來源池，依賴注入，事務，訊息傳遞等功能。當然，框架可以提供這些功能，但是應用程式伺服器還必須擁有在任何環境中構建，執行，部署和管理企業應用程式所需的一切，無論它們是否在容器內。事實上，應用伺服器可以在任何地方執行，例如，裸機，虛擬化平臺（如Red Hat Virtualization） ，私有云環境（如 Red Hat OpenStack Platform） ，以及公共雲環境（如 Microsoft Azure 或Amazon Web）服務 。
良好的應用程式伺服器可確保提供的API與其實現之間的一致性。開發人員可以確定部署其業務邏輯（需要某些功能）將起作用，因為應用程式伺服器開發人員（以及定義的標準）已確保這些元件協同工作並一起發展。此外，一個好的應用伺服器還負責最大化吞吐量和可擴充套件性，因為它將處理來自使用者的所有請求; 減少延遲並縮短載入時間，因為它有助於您的應用程式的可處置性 ; 重量輕，佔地面積小，可最大限度地減少硬體資源和成本; 最後，要足夠安全以避免任何安全漏洞。
結論
容器映象已成為分發雲原生應用程式的標準打包格式。雖然容器“本身”不能為應用程式提供真正的業務優勢，但Kubernetes及其相關專案（如OpenShift和Istio）提供了以前屬於應用程式伺服器的非功能性需求。
開發人員過去從應用程式伺服器或諸如Netflix OSS之 類的庫中獲得的大多數非功能性需求 都繫結到特定語言，例如Java。另一方面，當開發人員選擇使用Kubernetes + OpenShift + Istio滿足這些要求時，他們不會附加到任何特定語言，這可以鼓勵為每個用例使用最佳技術/語言。
最後，應用伺服器仍然在軟體開發中佔有一席之地。但是，它們正在變得更像是特定於語言的框架，這是開發應用程式時的一個很好的捷徑，因為它們包含許多已經編寫和測試過的功能。
遷移到容器，Kubernetes和微服務的最好的事情之一是，您不必為您的應用程式選擇單個應用程式伺服器，框架，架構風格甚至語言。您可以使用執行現有Java EE應用程式的JBoss EAP輕鬆部署容器，以及使用Wildfly Swarm或Eclipse Vert.x進行反應式程式設計的新微服務的其他容器。這些容器都可以通過Kubernetes進行管理。
你可以說Kubernetes / OpenShift是新的Linux 甚至是：
“Kubernetes是新的應用程式伺服器。”
但事實是應用程式伺服器/執行時+ OpenShift / Kubernetes + Istio已成為“事實上的”雲原生應用程式平臺！