在容器流行起來之前，應用服務器提供了一些非功能性需求(NFR，non-functional requirement)，比如安全性、隔離性、容錯、配置管理等等。打個比方，應用服務器和應用之間的關系就像 CD 播放器和 CD 之間的關系一樣。

作為開發人員，你應該遵循預定義的標準并按照特定的格式分發應用，而應用服務器會“執行”你的應用并帶來一些額外的功能，這些功能因服務器“品牌”的差異而有所不同。

與 CD 播放器的類比方式相似，隨著容器的流行，容器鏡像成為了新的 CD 格式。實際上，容器鏡像僅僅是用來分發容器的格式。

容器的真正收益在你需要為應用添加企業級功能時才體現出來。為容器化的應用提供這些功能的好方式就是使用 Kubernetes 作為它們的平臺。另外，Kubernetes 平臺還為其他項目提供了很棒的基礎實施，這些項目包括 Red Hat OpenShift、Istio 以及 Apache OpenWhisk，基于這些基礎設施能夠更容易的構建和部署健壯的生產級質量的應用。

接下來，我們探討九個這樣的功能：

1. 服務發現

服務發現指的是確定如何連接服務的過程。要獲得容器以及云原生應用的很多收益，我們需要將配置從容器鏡像中移除出去，這樣的話，我們就能把相同的容器鏡像應用到所有的環境中。將配置提取到應用外部是 12 要素應用的核心原則之一。服務發現是從運行時環境中獲取配置信息的方式之一，這樣能夠避免將其硬編碼到應用之中。Kubernetes 自帶了服務發現。Kubernetes 還提供了 ConfigMaps 和 [Secrets] (https://kubernetes.io/docs/concepts/configuration/secret/) 用來將配置從應用容器中移除。在運行時環境中，如果要連接數據庫這樣的服務，我們會存儲憑證信息，Secrets 解決了一些這方面所面臨的挑戰。借助 Kubernetes，我們無需使用外部的服務器或框架。

2. 基本調用

容器中的應用可以通過 Ingress 進行訪問，也就是從外部世界路由到你所暴露的服務。OpenShift 提供了基于 HAProxy 的 route objects，它具有各項功能和負載均衡策略。你可以使用路由功能進行輪流部署。這可以作為一些非常復雜的 CI/CD 策略的基礎。參見下文的“6. 構建和部署管道”。

如果你想運行一次性的任務，比如一個批處理或者只是使用集群來計算一個結果(比如計算 Pi 的位數)，那該怎么辦呢?針對這種場景，Kubernetes 提供了 job objects。同時還有一個 cron job，能夠管理基于時間的任務。

3. 彈性

在 Kubernetes 中，彈性(elasticity)是通過 ReplicaSets(它過去被稱為 Replication Controllers)解決的。與面向 Kubernetes 的大多數配置類似，ReplicaSet 是一種協調所需狀態的方式：你告訴 Kubernetes，系統應該處于各種狀態，Kubernetes 就能知道如何達到該狀態。在任意時間，ReplicaSet 都能控制副本的數量或應用程序精確的實例數量。

但是，如果你所構建的服務受歡迎程度超出了預先的規劃，計算資源耗盡了該怎么辦呢?你可以借助 Kubernetes Horizontal Pod Autoscaler，它會基于觀測到的 CPU 利用率(或所支持的自定義指標，以及應用提供的指標)擴展 pod 的數量。

4. 日志

因為 Kubernetes 集群能夠運行容器化應用的多個副本，所以將這些日志聚合起來，以便于在同一個地方進行查看就變得非常重要了。同時，為了利用自動擴展(以及其他云原生應用的功能)所帶來的收益，容器應該是不可變的。所以，我們應該將日志存儲在容器之外，這樣它們才能跨運行時持久化。OpenShift 允許我們部署 EFK 技術棧來聚合來自主機和應用的日志，即便這些日志來自多個容器甚至已刪除的 pod 均是可以的。

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 為集群本身提供了適應性(resilience)方案，它還提供了 PersistentVolumes 來支持卷(volume)的副本，從而幫助應用實現適應性。Kubernetes 的 ReplicationControllers/ 部署能夠確保指定數量的 pod 副本在整個集群中始終正常運行，它會自動處理任何可能出現的節點故障。

結合適應性，容錯能夠作為一種有效的方式來處理用戶對于可靠性和可用性的關切。運行在 Kubernetes 上的應用還可以通過 Istio 的重試規則、斷路器和池彈射(pool ejection，即移除掉出現故障的容器——譯注)來實現容錯。

8. 認證

在 Kubernetes 中，認證可以通過 Istio 的 mutual TLS 認證來實現，它致力于增強微服務及其通信的安全性，而無需服務代碼的變更。它會負責：

為每個服務提供一個代表其角色的強標識(identity)，從而允許它能夠跨集群和云進行互操作;

保護服務與服務之間的通信，以及終端用戶與服務之間的通信;

提供 key 管理系統，自動化 key 和證書生成、分發、輪換和撤銷。

另外，值得一提的是，我們還可以在 Kubernetes/OpenShift 集群中運行 Keycloak 以提供認證和授權。Keycloak 是 Red Hat Single Sign-on 的上游產品。

9. 跟蹤

基于 Istio 的應用可以配置為使用 Zipkin 或 Jaeger 收集跟蹤的 span。不管使用什么語言、框架或平臺來構建應用，Istio 都能支持分布式跟蹤。

文章標題：為什么說Kubernetes是新的應用服務器？
轉載注明：http://www.js-pz168.com/news14/105414.html

成都網站建設公司_創新互聯，為您提供網站設計、手機網站建設、網站維護、網站策劃、網站設計公司、網站建設

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯