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

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

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

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

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

1. 服務發(fā)現(xiàn)

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

2. 基本調(diào)用

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

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

3. 彈性

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

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

4. 日志

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

EFK 技術棧的組成如下所示：

• Elasticsearch(ES)，存儲日志內(nèi)容的對象存儲;
• Fluentd，從節(jié)點收集日志并將其發(fā)送至 Elasticsearch
• Kibana，針對 Elasticsearch 的 Web UI。

5. 監(jiān)控

盡管日志和監(jiān)控看上去解決的是相同的問題，但是它們之間是不同的。監(jiān)控是觀察、檢查、通常還有告警以及記錄，而日志則只有記錄。

Prometheus 是一個開源的監(jiān)控系統(tǒng)，它包含了時序數(shù)據(jù)庫。它可以用來存儲和查詢指標、告警，并使用可視化的方式查看系統(tǒng)內(nèi)部的運行狀況。Prometheus 可能是監(jiān)控 Kubernetes 集群方面最流行的可選方案。

6. 構(gòu)建和部署管道

對于你的應用來說，CI/CD(持續(xù)集成 / 持續(xù)交付)并不是“必備”的要求。但是，CI/CD 通常被認為是成功軟件開發(fā)和 DevOps 實踐的支柱。如果沒有經(jīng)過 CI/CD 管道的話，軟件不應該發(fā)布到生產(chǎn)環(huán)境中。Jez Humble 和 David Farley 合著的《持續(xù)交付：發(fā)布可靠軟件的系統(tǒng)方法》中是這樣描述 CD 的：“持續(xù)交付能夠?qū)⒏鞣N類型的變更發(fā)布到生產(chǎn)環(huán)境中，包括新特性、配置變化、缺陷修正以及體驗性的功能，或者說以可持續(xù)的方式將這些變更安全且快速地交到用戶的手里”。

7. 適應性

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

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

8. 認證

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

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

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

提供 key 管理系統(tǒng)，自動化 key 和證書生成、分發(fā)、輪換和撤銷。

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

9. 跟蹤

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

本文題目：為什么說Kubernetes是新的應用服務器？
分享網(wǎng)址：http://www.rwnh.cn/news/105414.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站建設、App設計、自適應網(wǎng)站、域名注冊、網(wǎng)站設計、網(wǎng)站排名

廣告

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