今天聊聊lstio這個感受高大尚的服務網格到底爲啥這麼受歡迎?
順便看看官方1.7.1的版本都解決了哪些bug以及功能穩定性上的提高前端
看官方如何定義lstio的,它是這麼說的:它是一個徹底開源的服務網格,做爲透明的一層接入到現有的分佈式應用中。它也是一個平臺,能夠與任何日誌、遙測和策略系統進行集成。lstio多樣化的特性讓你可以成功且高效的運行微服務架構,並提供保護、鏈接和監控微服務的統一方法。數據庫
這個定義看起來比較長,咱們能夠抽取其中比較重要的,好比後端
一、它依然是一個服務網格產品
二、它就是擁有服務網格的基本特性,也就是對應用層是透明的
三、它是爲微服務架構來服務的
四、它的核心功能,能夠鏈接、控制、保護、觀測微服務安全
它們爲何要用lstio來命名呢,我找到答案,這個詞它並非一個英語單詞,而是它是源於希臘語,它的意思是揚帆起航,能夠看出它的標誌是一個帆,那麼由此你可能會聯想起另一個很著名的產品kubernetes,這個詞其實也起源於希臘語,它的意思跟它的logo是同樣的,就是舵手的意思,google爲何用lstio來給這個產品命名,實際上是很是有深意的,它的意思你不只有kubernetes這個舵,還有有lsitio的帆,由它們一塊兒駕駛着你的雲原生應用,揚帆起航,駛向彼岸,說的比較方言了。。。網絡
另外lstio還有一個很是重要的特性,它被稱做是第二代的Service Mesh,在原有的數據平面的基礎上,增長了控制平面,它爲現代的Service Mesh的產品定義了一個新的形態架構
17年的時候你可能不知道lstio是什麼,如今能夠說是頭號網紅了,紅的緣由也可想而知,
咱們能夠看它的版本歷史週期
一、它的發佈時間(20170501)發佈0.1版本oracle
它是在17年的5月份發佈了0.1版本,那麼第一個service mesh產品叫Linkerd,大家也許早就據說過,它是17年4月份發佈的,那麼lstio在緊接着Linkerd發佈以後,馬上就發佈了0.1版本,你想它的意圖很明顯,就是但願可以儘快的阻擊Linked穩步的發展,但願讓你們都知道有lstio這個產品的產生app
二、三巨頭光環加身
另外沒錯人家還有三個巨頭加深,能夠說是兩個巨頭分別是,lyft這家公司明顯是抱大腿的
google、IBM、lyft
運維
那麼這三家公司爲istio做爲背書,不只他們的研發資源,研發投入以及社區影響力。都是linkerd這樣的初創公司沒法比擬的,所以一經推出就擁有了大量的粉絲,有這樣的光環可想而知分佈式
三、屬於第二代的service mesh產品
毋庸置疑第二代要比第一代有碾壓優點
四、envoy的加入讓istio如虎添翼
原本envoy和linkerd它都是一個基於數據平面的產品,沒有控制平面
istio自己也沒有開發本身的數據平面,因此它直接聯合了lyft公司,直接使用envoy做爲本身默認的數據平面,envoy自己就經歷了一年多的開發,很是的穩定性能也很是的可靠,它對linkerd仍是有比較大的優點的,envoy的加入直接讓istio擁有了一個能夠和linkerd抗衡的數據平面,省去了本身的開發的麻煩,對於lyft公司其實也有一個很大的好處,能夠抱着IBM和google着兩條大粗腿,爲本身的產品保駕護航,反過來這兩家公司也能夠坐享其成,直接可使用envoy做爲本身的數據平面,能夠說是一個共贏的策略
五、istio的自己的功能也很是強大
能夠在它的發佈列表中看到使人眼花繚亂的這樣的功能點,同時istio也受到了一些廠商的支持,包括IBM和google自家的雲平臺的支持,以及像redhat、還有oracle這樣的公司主動站出來支持,因而可知受到了很是多的追捧,以上都是它的一些優勢,有人認爲它們是過分營銷,linkerd的創始人也就是buoyant公司的CEO williamMorgan,曾經說過這樣的話,目前來講service mesh有一些處於不幸的狀態,有一些產品過分的營銷,致使市場超過了技術自己,那咱們能夠認爲williamMorgan這些話是針對istio來講的,畢竟是它最重要的競爭對手,所以它說這句話也無可後非,那麼至因而不是過分營銷的狀況產生。無論怎麼樣,istio已經站穩了C位,對於它本身來講是一個件好事。
學習lstio最好的就是官方,看看istio是如何營銷本身的
首先它說有兩大優點
一、能夠輕鬆的構建服務網格
咱們其實不要覺得service mesh是一個很是高深離你很遠的技術,你去構建一個mesh是很是容易的。
二、它對應用代碼是透明的,不須要去修改本身的應用代碼
其實它說的這個兩個優點都是service mesh自己的優點
其餘的產品也能作到這幾點
固然它提供的功能仍是很是強大的
而lstio的核心功能就是service mesh的功能,主要有如下四個方面
1、流量控制
一、第一點路由咱們常常聽到的灰度發佈,像藍綠髮布、AB測試這些均可以把它概括到路由這一點
二、第二點就是流量的轉移
三、第三點是爲網絡增長彈性的能力,好比說超時、重試熔斷這樣的機制
四、最後它還提供了一些調試網格的一些特性,好比說故障注入,還有流量鏡像的功能
2、安全
一、lstio對認證受權兩方面,提供了一些安全機制
3、可觀察性
一、在這一點lstio是安裝比較經典的可觀察性三方面提供了功能,分別是指標、日誌、追蹤
4、策略
像限流黑白名單這樣的功能,在1.5的版本里把這個功能去掉了,由於是廢棄了一個負責功能的模塊叫Mixer,它把一些功能都轉移到envoy功能裏面去了,後續策略相關功能也會逐步發佈出來
說說目前的版本發佈,關注2020年的lstio的版本變化的話,你就知道lstio今年但是變化的真快
lstio從17年5月進行發佈開始,能夠歸列爲四個重要的版本以及三個階段
首先看看都有哪四個版本
第一個版本就是17年5月的0.1版本,像世人宣告lstio產生,第二個版本是18年的7月份發佈了1.0版本,號稱是能夠應用於生產環境,第三個版本是1.1版本,它跟前一個版本間隔了有半年多的時間,緣由是進行對底層架構的一個重構,這個版本宣稱是企業級可用,最後一個版本是前不久2020年8月21號發佈的1.7.1版本
而前不久2020年5月21日,情人節那天在1.6版本發佈,版本更新了很多功能
好比
這個新模塊,經過組合多個服務的功能來減小Istio安裝中的組件數量。而在Istio 1.6中,已完成此過渡,並將功能徹底移至Istiod。這使可以刪除Citadel,Sideca的injector和Galley來實現單獨部署。
而在命令行工具istioctl可提供更好的診斷信息,更簡單的安裝命令,甚至提供彩色狀態!
升級Istio的功能也獲得了改善。首先,如今支持Istio控制平面自己的金絲雀。這意味着能夠在現有版本旁邊安裝新版本的控制平面,並有選擇地讓代理使用新版本。固然官方也給出了示例博客
好比使用Canary Control Plane部署安全地去升級Istio
https://istio.io/latest/blog/2020/multiple-control-planes/
還有一條istioctl upgrade命令能夠在集羣中執行就地升級(仍然能夠控制本身更新代理)
許多公司僅採用Istio是爲了更好地觀察分佈式應用程序,所以在這塊也進行了投資。好比會看到更多的可配置性,更好地控制跟蹤採樣率的能力,並更新Grafana儀表盤
https://istio.io/latest/docs/reference/config/networking/workload-entry/
固然這裏官方也給出了示例
對於那些將非Kubernetes工做負載添加到網格的人員(例如,部署在VM上的工做負載),新資源比以往任什麼時候候都更容易實現。建立了API,目的是爲非Kubernetes工做負載提供表示,它將VM或裸機工做負載提高到與Kubernetes相同的級別,而不只僅是具備IP地址的端點。如今甚至能夠定義由Pods和VM支持的服務。
爲何這樣有用?好比如今能夠將同一服務的部署(VM和Pods)混合在一塊兒使用,從而提供了一種絕佳的方式,能夠將VM工做負載遷移到Kubernetes集羣,而不會中斷往返於該集羣的流量。
固然小版本都是一些bug的修復,這裏你們能夠去官網查看
固然此次更新的發行版仍是繼續按照路線圖中概述的方向導航,從而提升了可用性,安全性,可靠性,尤爲是在VM(非Kubernetes)用例上進行了改進,這樣注意的是,在虛擬機的層面上增長了改進
如下是此版本的一些要點
一、確保目標規則證書能夠經過文件掛載,也能夠經過SDS(尤爲是自動循環)得到安全祕密分發,這是重要的安全性的一個最佳實踐
二、上面的項目適用於網關網格。這是如今能夠爲 那些TLS出口網關/ MTLS起源於提供客戶端證書的密鑰
三、還改進了信任域驗證來驗證TCP流量。之前只有HTTP流量通過驗證。目前新版本資源中如今也支持「信任域驗證trustDomainAliases 」 「config"
四、如使用ECC加密還有助於在提供高安全性的同時提升效率。增長了使用ECC的證書頒發機構進行通訊的功能。
五、最佳實踐安全性的重要組成部分是不要以超出其所需權限的權限運行進程,例如,防止混淆的副***。所以,還將Gateway部署修改成默認狀況下以非root用戶身份運行。
六、若是使用的是基於源主體的安全策略,則Istio Gateway和mTLS可能存在一個錯誤,這個須要知道
一、Istio這樣的系統,易於很大一部分人去使用,尤爲是在幫助發現潛在問題的能力方面。增長了很是有用的istioctl分析工具的功能:
二、警告可能不安全的DestinationRule配置
三、警告已棄用的Mixer資源使用狀況
四、對於istioctl的頻繁用戶,自定義默認配置可能有用,而不是每次都鍵入它。增長了將我的默認值放入主目錄的功能。
五、易於閱讀的文本比數字更容易-這就是咱們擁有DNS的緣由!所以還爲端口號添加了它。如今可使用如http的助記符(而不是80)來指定端口類型。
六、另外還添加了 「 istioctl x卸載」以使其變得很是容易。
鑑於Istio在生產系統中的普遍使用,另外對可用性進行了一些改進:
一、能夠將應用程序啓動延遲到Sidecar啓動。這提升了部署的可靠性,在該部署中,應用程序須要在啓動時當即經過其代理訪問資源。
二、有時,陳舊的端點可能會使Pilot變得不健康,另外對這塊也進行了改善於修復
三、Istio操做是安裝Istio一個偉大的方式,由於它能夠配置數量。金絲雀控制面的部署也很重要。它們容許對Istio進行超安全的升級。不幸的是,直到如今都不能一塊兒使用它們。
四、Istio-agent公開了指標,所以能夠觀察它的運行狀況。
五、對Prometheus指標管道進行了多項改進,以一種更輕鬆,更有效的方式在那裏獲取了更多數據。
一、自Istio成立以來,社區一直致力於將VM上的工做負載合併到服務網格中的支持。儘管如今有多個版本的用戶都在使用它,但在Istio 1.7中,傾向於添加一些改進。請注意,這仍然是Alpha功能。
二、Istio最經常使用的功能之一是其安全功能集。其核心是以短時間證書的形式爲每一個工做負載分配一個強大的身份。在此版本中,確保網格中VM上運行的工做負載具備安全的自舉過程以及自動證書輪換。
例如,擁有一個Kubernetes集羣,該集羣託管無狀態Web服務(前端),該服務提供來自Kubernetes外部VM中運行的有狀態數據庫(後端)的數據。你仍然但願使用mTLS加密前端對這些後端的訪問。經過此更改,能夠輕鬆地作到這一點。此外,這是以「零信任」方式完成的,其中一個前端或後端的妥協不容許模仿或損害其餘前端或後端,由於自舉和證書輪換遵循着最佳實踐。
三、還擴展了istioctl以便可以驗證基於VM的工做負載的代理狀態,之前驗證僅適用於基於Kubernetes的工做負載。
四、最後,添加了正式的RPM軟件包以及已經存在的Debian軟件包。這應該使在基於Red Hat的映像上進行安裝很是容易。
一、刪除了一些無效的控制平面指標,並 默認狀況下中止安裝遙測插件。
二、解決了SNI路由的問題。
Istio如今能夠與無頭服務更好地協做,由於它將再也不將mTLS流量發送到沒有sidecar的無頭服務上面。
那麼咱們想想目前lstio已經這幾年的變化,它會不會成爲下一個現象級的kubernetes產品,咱們能夠來分析一下
首先第一點來看看lstio產生了哪些意義?
一、lstio的出現實際上讓你從新定義了微服務的開發方式,讓你能夠輕鬆的在你的微服務架構中注入service Mesh技術
二、它能夠大幅下降微服務應用的開發門檻,讓你只關注業務自己
不用考慮如何添加不少網絡控制的相關功能或者類庫
三、它用統一的運維和開發方式,來簡化微服務的開發流程
那麼Istio一經推出,其實是揹負了這幾家公司的使命,而對於IBM和google的這樣的雲廠商來講,lstio是一個戰略級產品,它的推出爲這兩家廠商的雲平臺,提供一個殺手級的特性
它能夠延續google的雲原生市場上一個戰略佈局,咱們能夠在這張圖能夠看到在容器層面google已經有了kubernetes,那麼在通信層面已經有了google grpc的協議,而微服務這個層面,google也就是打算使用lstio這樣的一個產品來佔領市場,整個這三方面組成了google的一個雲原生的戰略,另外lstio還受到了不少雲廠商的支持,包括自家的G cloud,IBM的cloud,以及國內的現幾大廠商,它們如今的產品也都是基於lstio二次開發的,另外它可能還會受到一些其餘廠商的阻擊,好比說亞馬遜的AWS使用的本身的app Mesh這樣的產品,好比微軟本身的雲平臺Azure,它也有本身的service mesh產品,可能在將來雲平臺的生態閉環,可能會有不一樣的service mesh產品並存,目前還不能直接看出lstio一家獨大。