跳到主要內容

【K8S】Service服務詳解,看這一篇就夠了!!

k8s用命名空間namespace把資源進行隔離,默認情況下,相同的命名空間里的服務可以相互通訊,反之進行隔離。


1.1 Service


Kubernetes中一個應用服務會有一個或多個實例(Pod,Pod可以通過rs進行多複本的建立),每個實例(Pod)的IP地址由網絡插件動態隨機分配(Pod重啟后IP地址會改變)。為屏蔽這些後端實例的動態變化和對多實例的負載均衡,引入了Service這個資源對象,如下所示:


apiVersion: v1
kind: Service
metadata:
name: nginx-svc
labels:
app: nginx
spec:
type: ClusterIP
ports:
- port: 80
targetPort: 80
selector: #service通過selector和pod建立關聯
app: nginx

根據創建Service的type類型不同,可分成4種模式:



  • ClusterIP: 默認方式。根據是否生成ClusterIP又可分為普通Service和Headless Service兩類:

    • 普通Service:通過為Kubernetes的Service分配一個集群內部可訪問的固定虛擬IP(Cluster IP),實現集群內的訪問。為最常見的方式。

    • Headless Service:該服務不會分配Cluster IP,也不通過kube-proxy做反向代理和負載均衡。而是通過DNS提供穩定的絡ID來訪問,DNS會將headless service的後端直接解析為podIP列表。主要供StatefulSet使用。


  • NodePort:除了使用Cluster IP之外,還通過將service的port映射到集群內每個節點的相同一個端口,實現通過nodeIP:nodePort從集群外訪問服務。

  • LoadBalancer:和nodePort類似,不過除了使用一個Cluster IP和nodePort之外,還會向所使用的公有雲申請一個負載均衡器(負載均衡器後端映射到各節點的nodePort),實現從集群外通過LB訪問服務。

  • ExternalName:是 Service 的特例。此模式主要面向運行在集群外部的服務,通過它可以將外部服務映射進k8s集群,且具備k8s內服務的一些特徵(如具備namespace等屬性),來為集群內部提供服務。此模式要求kube-dns的版本為1.7或以上。這種模式和前三種模式(除headless service)最大的不同是重定向依賴的是dns層次,而不是通過kube-proxy。
    比如,在service定義中指定externalName的值"my.database.example.com":


此時k8s集群內的DNS服務會給集群內的服務名 ..svc.cluster.local 創建一個CNAME記錄,其值為指定的"my.database.example.com"。
當查詢k8s集群內的服務my-service.prod.svc.cluster.local時,集群的 DNS 服務將返回映射的CNAME記錄"foo.bar.example.com"。


備註: 前3種模式,定義服務的時候通過selector指定服務對應的pods,根據pods的地址創建出endpoints作為服務後端;Endpoints Controller會watch Service以及pod的變化,維護對應的Endpoint信息。kube-proxy根據Service和Endpoint來維護本地的路由規則。當Endpoint發生變化,即Service以及關聯的pod發生變化,kube-proxy都會在每個節點上更新iptables,實現一層負載均衡。 而ExternalName模式則不指定selector,相應的也就沒有port和endpoints。 ExternalName和ClusterIP中的Headles Service同屬於Headless Service的兩種情況。Headless Service主要是指不分配Service IP,且不通過kube-proxy做反向代理和負載均衡的服務。


1.2 Port


Service中主要涉及三種Port: * port 這裏的port表示service暴露在clusterIP上的端口,clusterIP:Port 是提供給集群內部訪問kubernetes服務的入口。



  • targetPort


containerPort,targetPort是pod上的端口,從port和nodePort上到來的數據最終經過kube-proxy流入到後端pod的targetPort上進入容器。



  • nodePort


nodeIP:nodePort 是提供給從集群外部訪問kubernetes服務的入口。


總的來說,port和nodePort都是service的端口,前者暴露給從集群內訪問服務,後者暴露給從集群外訪問服務。從這兩個端口到來的數據都需要經過反向代理kube-proxy流入後端具體pod的targetPort,從而進入到pod上的容器內。


1.3 IP


使用Service服務還會涉及到幾種IP:



  • ClusterIP


Pod IP 地址是實際存在於某個網卡(可以是虛擬設備)上的,但clusterIP就不一樣了,沒有網絡設備承載這個地址。它是一個虛擬地址,由kube-proxy使用iptables規則重新定向到其本地端口,再均衡到後端Pod。當kube-proxy發現一個新的service后,它會在本地節點打開一個任意端口,創建相應的iptables規則,重定向服務的clusterIP和port到這個新建的端口,開始接受到達這個服務的連接。



  • Pod IP


Pod的IP,每個Pod啟動時,會自動創建一個鏡像為gcr.io/google_containers/pause的容器,Pod內部其他容器的網絡模式使用container模式,並指定為pause容器的ID,即:network_mode: "container:pause容器ID",使得Pod內所有容器共享pause容器的網絡,與外部的通信經由此容器代理,pause容器的IP也可以稱為Pod IP。



  • 節點IP


Node-IP,service對象在Cluster IP range池中分配到的IP只能在內部訪問,如果服務作為一個應用程序內部的層次,還是很合適的。如果這個service作為前端服務,準備為集群外的客戶提供業務,我們就需要給這個服務提供公共IP了。指定service的spec.type=NodePort,這個類型的service,系統會給它在集群的各個代理節點上分配一個節點級別的端口,能訪問到代理節點的客戶端都能訪問這個端口,從而訪問到服務。


 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理



【其他文章推薦】

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!



網頁設計公司推薦不同的風格,搶佔消費者視覺第一線



※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整



南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!



※教你寫出一流的銷售文案?



※超省錢租車方案



Orignal From: 【K8S】Service服務詳解,看這一篇就夠了!!

留言

這個網誌中的熱門文章

有了四步解題法模板,再也不害怕動態規劃!(看不懂算我輸)

導言 動態規劃問題一直是算法面試當中的重點和難點,並且動態規劃這種通過空間換取時間的算法思想在實際的工作中也會被頻繁用到,這篇文章的目的主要是解釋清楚 什麼是動態規劃 ,還有就是面對一道動態規劃問題,一般的 思考步驟 以及其中的注意事項等等,最後通過幾道題目將理論和實踐結合。 什麼是動態規劃 如果你還沒有聽說過動態規劃,或者僅僅只有耳聞,或許你可以看看 Quora 上面的這個 回答 。 How to explain dynamic 用一句話解釋動態規劃就是 " 記住你之前做過的事 ",如果更準確些,其實是 " 記住你之前得到的答案 "。 我舉個大家工作中經常遇到的例子。 在軟件開發中,大家經常會遇到一些系統配置的問題,配置不對,系統就會報錯,這個時候一般都會去 Google 或者是查閱相關的文檔,花了一定的時間將配置修改好。 過了一段時間,去到另一個系統,遇到類似的問題,這個時候已經記不清之前修改過的配置文件長什麼樣,這個時候有兩種方案,一種方案還是去 Google 或者查閱文檔,另一種方案是借鑒之前修改過的配置,第一種做法其實是萬金油,因為你遇到的任何問題其實都可以去 Google,去查閱相關文件找答案,但是這會花費一定的時間,相比之下,第二種方案肯定會更加地節約時間,但是這個方案是有條件的,條件如下: 之前的問題和當前的問題有着關聯性,換句話說,之前問題得到的答案可以幫助解決當前問題 需要記錄之前問題的答案 當然在這個例子中,可以看到的是,上面這兩個條件均滿足,大可去到之前配置過的文件中,將配置拷貝過來,然後做些細微的調整即可解決當前問題,節約了大量的時間。 不知道你是否從這些描述中發現,對於一個動態規劃問題,我們只需要從兩個方面考慮,那就是 找出問題之間的聯繫 ,以及 記錄答案 ,這裏的難點其實是找出問題之間的聯繫,記錄答案只是順帶的事情,利用一些簡單的數據結構就可以做到。 概念 上面的解釋如果大家可以理解的話,接    動態規劃 算法是通過拆分問題,定義問題狀態和狀態之間的關係,使得問題能夠以遞推(或者說分治)的方式去解決。它的幾個重要概念如下所述。    階段: 對於一個完整的問題過程,適當的切分為若干個相互聯繫的子問題,每次在求解一個子問題...

我的USB為什麼總是無法識別,到底是為甚麼呢?這真的讓我好困擾

其實判斷軟件硬件問題很簡單,在別的機器或換個系統試試就可以了.有些小的問題不妨先用專門軟件格式化下.還有提醒你WINDOWS下格式化時要選擇FAT,不要選FAT32。 倘若插入後,在右下角彈出電腦正在嘗試連接此USB設備的一些信息,有時會彈出對話框讓用戶選擇,有些用戶還沒看清就點了否,或者因為電腦一些初始的設置問題,禁止了USB的一些功能。解決辦法:右鍵點"我的電腦",選"屬性"--"硬件"--"驅動器簽名",在此選擇"忽略",點"確定"。然後重新插上usb,還是不連的話,再右鍵點"我的電腦"--"屬性"--"硬件"--"設備管理器",從中找到"通用串行總線控制器",右鍵,然後"掃描檢測硬件改動"。如果都不行那就是USB識別程序或U盤的問題從控制面板進入添加或刪除硬件將所有USB設備都刪除,重新安裝需要使用的USB設備驅動程序,重新啟動電腦 USB CONNECTOR   USB CONNECTOR  USB CONNECTOR Orignal From: 我的USB為什麼總是無法識別,到底是為甚麼呢?這真的讓我好困擾

為何 Amazon 併購 Oracle 的可能性很大 ?

  2019 年 9 月份 Trefis 團隊建議《Trefis 建議:谷歌可以斥資 90 億美元收購 Nutanix》,最近又建議亞馬遜收購 Oracle。此文是其和《福布斯》雜誌的 Great Speculations 合作撰寫。   根據 Trefis 分析,亞馬遜併購 Oracle 有望帶來巨大的價值。雖然這個想法聽起來很雄心勃勃,但是為了使自己處於雲技術食物鏈的頂端,Oracle 可能是亞馬遜有史以來最好的收購對象。我們詳細說明為什麼亞馬遜可能會收購 Oracle,還在交互式儀錶板中估計了潛在交易的價值。我們的估計基於 Oracle 的獨立價值以及它作為與亞馬遜合併后的實體中一部分而具有的價值。    為何我們認為亞馬遜會收購 Oracle?      兩家公司的概況: 亞馬遜可能是在 2000 年代中期第一家打造公共雲生態系統的供應商,但 Oracle 從事數據庫業務已有近 40 年的歷史。 AWS 的想法是可以將基礎設施出租給希望存儲和計算資源方面減少費用的客戶。根據 Trefis 的估計,AWS 的企業價值高達 4930 億美元,EV/EBITDA 是 27 倍(2020 年 EBITDA 為 180 億美元)。 Oracle 因第一代雲產品失敗而很晚進入雲市場,該公司隨後在開發方面投入大量資金,旨在向市場推出第二代雲。根據 Trefis 的估計,Oracle 的企業價值應為 2510 億美元,EV/EBITDA 是 12.7 倍(2020 年 EBITDA 為 200 億美元)。 AWS 的方法是創建產品,然後讓用戶採用它。Oracle 已經長期擁有這樣的用戶群,卻無法滿足 AWS 能夠滿足的要求。結果是,儘管 Oracle 運行着全球近 50% 的數據庫,但如今 AWS 在公共雲市場的份額超過 40%,而 Oracle 甚至沒有躋身前五名。   理由1:客戶將獲得第二代架構的安全性和 AWS 的客戶服務,因而導致差異化產品與競爭。 由於市場上面臨微軟 Azure(已成為微軟 B2B 和 B2C 產品的底層結構)、谷歌雲(迎來新的掌門人)和 IBM 雲產品(收購 Red Hat 之後)的競爭,AWS 的先行優勢如今可能在減弱。 對老牌雲領導企業構成不利的另一個因素是,原本可以遷移到...