融數(shù)數(shù)據(jù)基于Kubernetes的微服務(wù)治理和構(gòu)建平臺(tái)

融數(shù)數(shù)據(jù)基于Kubernetes的微服務(wù)治理和構(gòu)建平臺(tái)

DNS：A——IP地址CName——主機(jī)名PTR——與A相反SRV——DNSSRV是DNS記錄中一種，用來(lái)指定服務(wù)地址。與常見的A記錄、cname不同的是，SRV中除了記錄服務(wù)器的地址，還記錄了服務(wù)的端口，并且可以設(shè)置每個(gè)服務(wù)地址的優(yōu)先級(jí)和權(quán)重。訪問(wèn)服務(wù)的時(shí)候，本地的DNSresolver從DNS服務(wù)器查詢到一個(gè)地址列表，根據(jù)優(yōu)先級(jí)和權(quán)重，從中選取一個(gè)地址作為本次請(qǐng)求的目標(biāo)地址。

我們都知道CAP是EricBrewer提出的分布式系統(tǒng)三要素：

強(qiáng)一致性(Consistency)

可用性(Availability)

分區(qū)容忍性(PartitionTolerance)幾乎所有的服務(wù)發(fā)現(xiàn)和注冊(cè)方案都是CP系統(tǒng)，也就是說(shuō)滿足了在同一個(gè)數(shù)據(jù)有多個(gè)副本的情況下，對(duì)于數(shù)據(jù)的更新操作達(dá)到最終的效果和操作一份數(shù)據(jù)是一樣的，但是在出現(xiàn)網(wǎng)絡(luò)分區(qū)（分區(qū)間的節(jié)點(diǎn)無(wú)法進(jìn)行網(wǎng)絡(luò)通信）這樣的故障的時(shí)候，在節(jié)點(diǎn)之間恢復(fù)通信并且同步數(shù)據(jù)之前，一些節(jié)點(diǎn)將會(huì)無(wú)法提供服務(wù)（一些系統(tǒng)在節(jié)點(diǎn)丟失的情況下支持stalereads）。

服務(wù)發(fā)現(xiàn)之EtcdVSConsul

值得注意的是，分布式系統(tǒng)中的數(shù)據(jù)分為控制數(shù)據(jù)和應(yīng)用數(shù)據(jù)。使用etcd的場(chǎng)景默認(rèn)處理的數(shù)據(jù)都是控制數(shù)據(jù)，對(duì)于應(yīng)用數(shù)據(jù)，只推薦數(shù)據(jù)量很小，但是更新訪問(wèn)頻繁的情況。

抄自這里

************************************************************************************************網(wǎng)上找來(lái)找去都是zk和etcd的比較，和consul的比較很少，這個(gè)感覺(jué)還算靠譜，也在別的地方看到過(guò)對(duì)consul的吐槽，記錄下************************************************************************************************

導(dǎo)語(yǔ)在分布式微服務(wù)架構(gòu)中，一個(gè)應(yīng)用可能由一組職責(zé)單一化的服務(wù)組成。這時(shí)候就需要一個(gè)注冊(cè)服務(wù)的機(jī)制，注冊(cè)某個(gè)服務(wù)或者某個(gè)節(jié)點(diǎn)是可用的，還需要一個(gè)發(fā)現(xiàn)服務(wù)的機(jī)制來(lái)找到哪些服務(wù)或者哪些節(jié)點(diǎn)還在提供服務(wù)。在實(shí)際應(yīng)用中，通常還都需要一個(gè)配置文件告訴我們一些配置信息，比如數(shù)據(jù)連接的地址，redis的地址等等。但很多時(shí)候，我們想要?jiǎng)討B(tài)地在不修改代碼的情況下得到這些信息，并且能很好地管理它們。有了這些需求，于是發(fā)展出了一系列的開源框架，比如ZooKeeper,Etcd,Consul等等。這些框架一般會(huì)提供這樣的服務(wù)：服務(wù)注冊(cè)

主機(jī)名，端口號(hào)，版本號(hào)，或者一些環(huán)境信息。服務(wù)發(fā)現(xiàn)

可以讓客戶端拿到服務(wù)端地址。一個(gè)分布式的通用k/v存儲(chǔ)系統(tǒng)

基于Paxos算法或者Raft算法領(lǐng)導(dǎo)者選舉(LeaderElection)其它一些例子：

分布式鎖(Distributedlocking)

原子廣播(Atomicbroadcast)

序列號(hào)(Sequencenumbers)

…我們都知道CAP是EricBrewer提出的分布式系統(tǒng)三要素：

強(qiáng)一致性(Consistency)

可用性(Availability)

分區(qū)容忍性(PartitionTolerance)幾乎所有的服務(wù)發(fā)現(xiàn)和注冊(cè)方案都是CP系統(tǒng)，也就是說(shuō)滿足了在同一個(gè)數(shù)據(jù)有多個(gè)副本的情況下，對(duì)于數(shù)據(jù)的更新操作達(dá)到最終的效果和操作一份數(shù)據(jù)是一樣的，但是在出現(xiàn)網(wǎng)絡(luò)分區(qū)（分區(qū)間的節(jié)點(diǎn)無(wú)法進(jìn)行網(wǎng)絡(luò)通信）這樣的故障的時(shí)候，在節(jié)點(diǎn)之間恢復(fù)通信并且同步數(shù)據(jù)之前，一些節(jié)點(diǎn)將會(huì)無(wú)法提供服務(wù)（一些系統(tǒng)在節(jié)點(diǎn)丟失的情況下支持stalereads）。ZooKeeper作為這類框架中歷史最悠久的之一，是由Java編寫。Java在許多方面非常偉大，然而對(duì)于這種類型的工作還是顯得有些沉重，也正因?yàn)槠鋸?fù)雜性和對(duì)新鮮事物的向往，我們第一時(shí)間就放棄了選擇它。本文將從協(xié)議和應(yīng)用層來(lái)比較Etcd和Consul，并最終給出了筆者的偏好。EtcdEtcd是一個(gè)使用go語(yǔ)言寫的分布式k/v存儲(chǔ)系統(tǒng)?？紤]到它是coreos公司的項(xiàng)目，以及在GitHub上的star數(shù)量(9000+)，Google著名的容器管理工具Kuberbetes就是基于Etcd的。我們最先考慮的就是它。在介紹Etcd之前，我們需要了解一些基本的概念。我們知道在單臺(tái)服務(wù)器單個(gè)進(jìn)程中維護(hù)一個(gè)狀態(tài)是很容易的，讀寫的時(shí)候不會(huì)產(chǎn)生沖突。即便在多進(jìn)程或者多線程環(huán)境中，使用鎖機(jī)制或者協(xié)程（coroutine）也可以讓讀寫有序地進(jìn)行。但是在分布式系統(tǒng)中，情況就會(huì)復(fù)雜很多，服務(wù)器可能崩潰，節(jié)點(diǎn)間的機(jī)器可能網(wǎng)絡(luò)不通等等。所以一致性協(xié)議就是用來(lái)在一個(gè)集群里的多臺(tái)機(jī)器中維護(hù)一個(gè)一致的狀態(tài)。很多的分布式系統(tǒng)都會(huì)采用Paxos協(xié)議，但是Paxos協(xié)議難以理解，并且在實(shí)際實(shí)現(xiàn)中差別比較大。所以Etcd選擇了Raft作為它的一致性協(xié)議。Raft是DiegoOngaro和JohnOusterhout在‘InSearchofanUnderstandableConsensusAlgorithm’中提出的。它在犧牲很少可用性，達(dá)到相似功能的情況下，對(duì)Paxos做了很大的優(yōu)化，并且比Paxos簡(jiǎn)單易懂很多。它主要集中在解決兩個(gè)問(wèn)題：領(lǐng)導(dǎo)者選舉(LeaderElection)

Raft先通過(guò)領(lǐng)導(dǎo)選舉選出一個(gè)Leader，后續(xù)的一致性維護(hù)都由Leader來(lái)完成，這就簡(jiǎn)化了一致性的問(wèn)題。Raft會(huì)保證一個(gè)時(shí)間下只會(huì)有一個(gè)Leader，并且在超過(guò)一半節(jié)點(diǎn)投票的情況下才會(huì)被選為L(zhǎng)eader。當(dāng)Leader掛掉的時(shí)候，新的Leader將會(huì)被選出來(lái)。日志復(fù)制(LogReplication)

為了維護(hù)狀態(tài)，系統(tǒng)會(huì)記錄下來(lái)所有的操作命令日志。Leader在收到客戶端操作命令后，會(huì)追加到日志的尾部。然后Leader會(huì)向集群里所有其它節(jié)點(diǎn)發(fā)送AppendEntriesRPC請(qǐng)求，每個(gè)節(jié)點(diǎn)都通過(guò)兩階段提交來(lái)復(fù)制命令，這保證了大部分的節(jié)點(diǎn)都能完成。在實(shí)際的應(yīng)用中，一般Etcd集群以5個(gè)或者7個(gè)為宜，可以忍受2個(gè)或者3個(gè)節(jié)點(diǎn)掛掉，為什么不是越多越好呢？是出于性能的考慮，因?yàn)楣?jié)點(diǎn)多了以后，日志的復(fù)制會(huì)導(dǎo)致CPU和網(wǎng)絡(luò)都出現(xiàn)瓶頸。Etcd的API比較簡(jiǎn)單，可以對(duì)一個(gè)目錄或者一個(gè)key進(jìn)行GET，PUT，DELETE操作，是基于HTTP的。Etcd提供watch某個(gè)目錄或者某個(gè)key的功能，客戶端和Etcd集群之間保持著長(zhǎng)連接(longpolling)?；谶@個(gè)長(zhǎng)連接，一旦數(shù)據(jù)發(fā)生改變，客戶端馬上就會(huì)收到通知，并且返回的結(jié)果是改變后的值和改變前的值，這一點(diǎn)在實(shí)際應(yīng)用中會(huì)很有用（這也是后面的Consul的槽點(diǎn)之一）。Etcd的watch和在一般情況下不會(huì)漏掉任何的變更。因?yàn)镋tcd不僅存儲(chǔ)了當(dāng)前的鍵值對(duì)，還存儲(chǔ)了最近的變更記錄，所以如果一個(gè)落后于當(dāng)前狀態(tài)的watch還是可以通過(guò)遍歷歷史變更記錄來(lái)獲取到所有的更新。Etcd還支持CompareAndSwap這個(gè)原子操作，首先對(duì)一個(gè)key進(jìn)行值比較，只有結(jié)果一致才會(huì)進(jìn)行下一步的賦值操作。利用這個(gè)特性就像利用x86的CAS實(shí)現(xiàn)鎖一樣可以實(shí)現(xiàn)分布式鎖。在Etcd中有個(gè)proxy的概念，它其實(shí)是個(gè)轉(zhuǎn)發(fā)服務(wù)器，啟動(dòng)的時(shí)候需要指定集群的地址，然后就可以轉(zhuǎn)發(fā)客戶端的請(qǐng)求到集群，它本身不存儲(chǔ)數(shù)據(jù)。一般來(lái)說(shuō)，在每個(gè)服務(wù)節(jié)點(diǎn)都會(huì)啟動(dòng)一個(gè)proxy，所以這個(gè)proxy也是一個(gè)本地proxy，這樣服務(wù)節(jié)點(diǎn)就不需要知道Etcd集群的具體地址，只需要請(qǐng)求本地proxy。之前提到過(guò)一個(gè)k/v系統(tǒng)還應(yīng)該支持leaderelection，Etcd可以通過(guò)TTL(timetolive)key來(lái)實(shí)現(xiàn)。ConsulConsul和Etcd一樣也有兩種節(jié)點(diǎn)，一種叫client(和Etcd的proxy一樣)只負(fù)責(zé)轉(zhuǎn)發(fā)請(qǐng)求，另一種是server，是真正存儲(chǔ)和處理事務(wù)的節(jié)點(diǎn)。Consul使用基于Serf實(shí)現(xiàn)的gossip協(xié)議來(lái)管理從屬關(guān)系，失敗檢測(cè)，事件廣播等等。gossip協(xié)議是一個(gè)神奇的一致性協(xié)議，之所以取名叫g(shù)ossip是因?yàn)檫@個(gè)協(xié)議是模擬人類中傳播謠言的行為而來(lái)。要傳播謠言就要有種子節(jié)點(diǎn)，種子節(jié)點(diǎn)每秒都會(huì)隨機(jī)向其它節(jié)點(diǎn)發(fā)送自己所擁有的節(jié)點(diǎn)列表，以及需要傳播的消息。任何新加入的節(jié)點(diǎn)，就在這種傳播方式下很快地被全網(wǎng)所知道。這個(gè)協(xié)議的神奇就在于它從設(shè)計(jì)開始就沒(méi)想要信息一定要傳遞給所有的節(jié)點(diǎn)，但是隨著時(shí)間的增長(zhǎng)，在最終的某一時(shí)刻，全網(wǎng)會(huì)得到相同的信息。當(dāng)然這個(gè)時(shí)刻可能僅僅存在于理論，永遠(yuǎn)不可達(dá)。Consul使用了兩個(gè)不同的gossippool，分別叫做LAN和WAN，這是因?yàn)镃onsul原生支持多數(shù)據(jù)中心。在一個(gè)數(shù)據(jù)中心內(nèi)部，LANgossippool包含了這個(gè)數(shù)據(jù)中心所有的節(jié)點(diǎn)，包括proxy和servers。WANpool是全局唯一的，所有數(shù)據(jù)中心的servers都在這個(gè)pool中。這兩個(gè)pool的區(qū)別就是LAN處理的是數(shù)據(jù)中心內(nèi)部的失敗檢測(cè)，事件廣播等等，而WAN關(guān)心的是跨數(shù)據(jù)中心的。除了gossip協(xié)議之外，Consul還使用了Raft協(xié)議來(lái)進(jìn)行l(wèi)eaderelection，選出leader之后復(fù)制日志的過(guò)程和Etcd基本一致?；氐綉?yīng)用層面上來(lái)說(shuō)，Consul更像是一個(gè)fullstack的解決方案，它不僅提供了一致性k/v存儲(chǔ)，還封裝了服務(wù)發(fā)現(xiàn)，健康檢查，內(nèi)置了DNSserver等等。這看上去非常美好，簡(jiǎn)直可以開箱即用。于是，我們初步選定了Consul作為我們的服務(wù)發(fā)現(xiàn)和動(dòng)態(tài)配置的框架。但現(xiàn)實(shí)往往是冰冷的，在深入研究它的API之后發(fā)現(xiàn)了比較多的坑，可能設(shè)計(jì)者有他自己的考慮。在使用獲取所有services的API的時(shí)候返回的只是所有服務(wù)的名字和tag，如果想要每個(gè)服務(wù)的具體信息，你還需要挨個(gè)去請(qǐng)求。這在客戶端就會(huì)十分不方便，因?yàn)樵诠P者看來(lái)，獲取所有服務(wù)的列表以及具體信息應(yīng)該是一個(gè)很常見的需求，并且請(qǐng)求的次數(shù)越少越好。如果watch服務(wù)是否有變化，當(dāng)值發(fā)生改變的時(shí)候，返回的結(jié)果居然是相當(dāng)于重新讀取所有services，沒(méi)有能夠體現(xiàn)出服務(wù)信息的變化，這會(huì)導(dǎo)致客戶端很難進(jìn)行更新操作。健康檢查是Consul的內(nèi)置功能，在注冊(cè)一個(gè)服務(wù)的時(shí)候可以加上自定義的健康檢查，這聽上去很不錯(cuò)。但是如果你忘記給你某個(gè)服務(wù)加上健康檢查，那它在各種API的返回結(jié)果中變得難以預(yù)料。

…結(jié)語(yǔ)在折騰了數(shù)天之后，最終我們決定回歸Etcd，事實(shí)證明這個(gè)決定是正確的。我們基于Etcd實(shí)現(xiàn)了穩(wěn)定的服務(wù)發(fā)現(xiàn)和動(dòng)態(tài)配置功能，當(dāng)然還有一些比較細(xì)節(jié)的問(wèn)題沒(méi)有在文中闡述，歡迎一起探討。

傳輸層安全(TLS)是SSL的繼承協(xié)議。TLS是SSL的升級(jí)版。其工作方式與SSL極為相似，都是通過(guò)加密來(lái)保護(hù)數(shù)據(jù)和信息的傳輸。盡管SSL的應(yīng)用仍然非常廣泛，在業(yè)內(nèi)這兩個(gè)術(shù)語(yǔ)通?？梢曰Q使用。

隧道協(xié)議（TunnelingProtocol）是一類網(wǎng)絡(luò)協(xié)議，它是一種數(shù)據(jù)包封裝技術(shù)，它是將原始IP包（其報(bào)頭包含原始發(fā)送者和最終目的地）封裝在另一個(gè)數(shù)據(jù)包（稱為封裝的IP包）的數(shù)據(jù)凈荷中進(jìn)行傳輸。使用隧道的原因是在不兼容的網(wǎng)絡(luò)上傳輸數(shù)據(jù)，或在不安全網(wǎng)絡(luò)上提供一個(gè)安全路徑。隧道協(xié)議通常（但并非總是）在一個(gè)比負(fù)載協(xié)議還高的層級(jí)，或同一層。---------------------

備注：說(shuō)白了，通過(guò)網(wǎng)絡(luò)隧道技術(shù)，使隧道兩端的網(wǎng)絡(luò)組合成一個(gè)更大的內(nèi)部網(wǎng)絡(luò)。

終止協(xié)議意味著客戶端使用期望的協(xié)議連接代理服務(wù)器，比如TLS或HTTP/2，然后代理服務(wù)器再去連接應(yīng)用服務(wù)器、數(shù)據(jù)庫(kù)服務(wù)器等，但不需要使用相同的協(xié)議，如下圖所示。/2015-11-13_56455e89a4a1f.png

使用獨(dú)立的服務(wù)器終止協(xié)議意味著使用多服務(wù)器架構(gòu)。多服務(wù)器可能是多個(gè)物理服務(wù)器、多個(gè)虛擬服務(wù)器，或者AWS這樣的云環(huán)境中的多個(gè)虛擬服務(wù)器實(shí)例。多服務(wù)器就比單服務(wù)器復(fù)雜，或者比應(yīng)用服務(wù)器/數(shù)據(jù)庫(kù)服務(wù)器的組合復(fù)雜。不過(guò)，多服務(wù)器架構(gòu)有很多好處，而且很多流量大的網(wǎng)站也必須用這種架構(gòu)。配置了服務(wù)器或者虛擬服務(wù)器之后，很多事情都成為可能。新服務(wù)器可以分擔(dān)其他服務(wù)器的負(fù)載，可用于負(fù)載平衡、靜態(tài)文件緩存和其他用途。另外，也可以讓添加和替換應(yīng)用服務(wù)器或其他服務(wù)器更容易。NGINX和NGINXPlus經(jīng)常被用來(lái)終止TLS和HTTP/2協(xié)議、負(fù)載平衡。已有環(huán)境不必改動(dòng)，除非要把NGINX服務(wù)器挪到前端。

Service實(shí)現(xiàn)了基于iptables的分布式負(fù)載均衡iptables是Linux防火墻工作在用戶空間的管理工具，是netfilter/iptablesIP信息包過(guò)濾系統(tǒng)是一部分，用來(lái)設(shè)置、維護(hù)和檢查L(zhǎng)inux內(nèi)核的IP數(shù)據(jù)包過(guò)濾規(guī)則。iptables可以檢測(cè)、修改、轉(zhuǎn)發(fā)、重定向和丟棄IP數(shù)據(jù)包。其代碼已經(jīng)內(nèi)置于內(nèi)核中，并且按照不同的目的被組織成表（table）的集合。表由一組預(yù)先定義的鏈(chain)組成，鏈包含遍歷順序規(guī)則。每一條規(guī)則包含條件匹配和相應(yīng)的動(dòng)作（稱為目標(biāo)），如果條件匹配為真，該動(dòng)作會(huì)被執(zhí)行。

谷歌計(jì)算引擎(GCE)

融數(shù)數(shù)據(jù)基于Kubernetes的微服務(wù)治理和構(gòu)建平臺(tái).pdf

第一代監(jiān)控：Zipkin+BraveDapper：小型ORM之王

pinpoint分布式性能監(jiān)控工具(docker安裝)在做性能壓測(cè)的時(shí)候，你是不是有只能看到測(cè)試報(bào)告？在做性能壓測(cè)的時(shí)候，你是不是想知道每一個(gè)方法執(zhí)行了多長(zhǎng)時(shí)間？Pinpoint幾乎可以幫助你查看你想看到的每一個(gè)細(xì)節(jié)。

Pinpoint是什么？Pinpoint是一款全鏈路分析工具，提供了無(wú)侵入式的調(diào)用鏈監(jiān)控、方法執(zhí)行詳情查看、應(yīng)用狀態(tài)信息監(jiān)控等功能?；贕oogleDapper論文進(jìn)行的實(shí)現(xiàn)，與另一款開源的全鏈路分析工具Zipkin類似，但相比Zipkin提供了無(wú)侵入式、代碼維度的監(jiān)控等更多的特性。Pinpoint支持的功能比較豐富，可以支持如下幾種功能：服務(wù)拓?fù)鋱D：對(duì)整個(gè)系統(tǒng)中應(yīng)用的調(diào)用關(guān)系進(jìn)行了可視化的展示，單擊某個(gè)服務(wù)節(jié)點(diǎn)，可以顯示該節(jié)點(diǎn)的詳細(xì)信息，比如當(dāng)前節(jié)點(diǎn)狀態(tài)、請(qǐng)求數(shù)量等實(shí)時(shí)活躍線程圖：監(jiān)控應(yīng)用內(nèi)活躍線程的執(zhí)行情況，對(duì)應(yīng)用的線程執(zhí)行性能可以有比較直觀的了解請(qǐng)求響應(yīng)散點(diǎn)圖：以時(shí)間維度進(jìn)行請(qǐng)求計(jì)數(shù)和響應(yīng)時(shí)間的展示，拖過(guò)拖動(dòng)圖表可以選擇對(duì)應(yīng)的請(qǐng)求查看執(zhí)行的詳細(xì)情況請(qǐng)求調(diào)用棧查看：對(duì)分布式環(huán)境中每個(gè)請(qǐng)求提供了代碼維度的可見性，可以在頁(yè)面中查看請(qǐng)求針對(duì)到代碼維度的執(zhí)行詳情，幫助查找請(qǐng)求的瓶頸和故障原因。應(yīng)用狀態(tài)、機(jī)器狀態(tài)檢查：通過(guò)這個(gè)功能可以查看相關(guān)應(yīng)用程序的其他的一些詳細(xì)信息，比如CPU使用情況，內(nèi)存狀態(tài)、垃圾收集狀態(tài)，TPS和JVM信息等參數(shù)。Java在1.5引入java.lang.instrument，你可以由此實(shí)現(xiàn)一個(gè)Java

agent,通過(guò)此agent來(lái)修改類的字節(jié)碼即改變一個(gè)類。

Pinpoint是一個(gè)分析大型分布式系統(tǒng)的平臺(tái)，提供解決方案來(lái)處理海量跟蹤數(shù)據(jù)。

Pinpoint,2012年七月開始開發(fā)，在2015年1月作為一個(gè)開源項(xiàng)目啟動(dòng),是一個(gè)為大型分布式系統(tǒng)服務(wù)的n層架構(gòu)跟蹤平臺(tái)。Pinpoint的特點(diǎn)如下:分布式事務(wù)跟蹤，跟蹤跨分布式應(yīng)用的消息自動(dòng)檢測(cè)應(yīng)用拓?fù)洌瑤椭愀闱宄?yīng)用的架構(gòu)水平擴(kuò)展以便支持大規(guī)模服務(wù)器集群提供代碼級(jí)別的可見性以便輕松定位失敗點(diǎn)和瓶頸使用字節(jié)碼增強(qiáng)技術(shù)，添加新功能而無(wú)需修改代碼

無(wú)法識(shí)別從Node1發(fā)送的第N個(gè)消息和Node2接收到的N'消息之間的關(guān)系——Googledapper實(shí)現(xiàn)了一個(gè)簡(jiǎn)單的解決方案來(lái)解決這個(gè)問(wèn)題。這個(gè)解決方案通過(guò)在發(fā)送消息時(shí)添加應(yīng)用級(jí)別的標(biāo)簽作為消息之間的關(guān)聯(lián)。例如，在HTTP請(qǐng)求中的HTTPheader中為消息添加一個(gè)標(biāo)簽信息并使用這個(gè)標(biāo)簽跟蹤消息。

Pinpoint中的數(shù)據(jù)結(jié)構(gòu)Pinpoint中，核心數(shù)據(jù)結(jié)構(gòu)由Span,Trace,和TraceId組成。Span:RPC(遠(yuǎn)程過(guò)程調(diào)用/remoteprocedurecall)跟蹤的基本單元;當(dāng)一個(gè)RPC調(diào)用到達(dá)時(shí)指示工作已經(jīng)處理完成并包含跟蹤數(shù)據(jù)。為了確保代碼級(jí)別的可見性，Span擁有帶SpanEvent標(biāo)簽的子結(jié)構(gòu)作為數(shù)據(jù)結(jié)構(gòu)。每個(gè)Span包含一個(gè)TraceId。Trace:多個(gè)Span的集合;由關(guān)聯(lián)的RPC(Spans)組成.在同一個(gè)trace中的span共享相同的TransactionId。Trace通過(guò)SpanId和ParentSpanId整理為繼承樹結(jié)構(gòu).TraceId:由TransactionId,SpanId,和ParentSpanId組成的key的集合.TransactionId指明消息ID，而SpanId和ParentSpanId表示RPC的父-子關(guān)系。TransactionId(TxId):在分布式系統(tǒng)間單個(gè)事務(wù)發(fā)送/接收的消息的ID;必須跨整個(gè)服務(wù)器集群做到全局唯一.SpanId:當(dāng)收到RPC消息時(shí)處理的工作的ID;在RPC請(qǐng)求到達(dá)節(jié)點(diǎn)時(shí)生成。ParentSpanId(pSpanId):發(fā)起RPC調(diào)用的父span的SpanId.如果節(jié)點(diǎn)是事務(wù)的起點(diǎn)，這里將沒(méi)有父span-對(duì)于這種情況，使用值-1來(lái)表示這個(gè)span是事務(wù)的根span。GoogleDapper和NAVERPinpoint在術(shù)語(yǔ)上的不同Pinpoint中的術(shù)語(yǔ)"TransactionId"和googledapper中的術(shù)語(yǔ)"TraceId"有相同的含義。而Pinpoint中的術(shù)語(yǔ)"TraceId"引用到多個(gè)key的集合。

作者：小清新同學(xué)

鏈接：/p/a803571cd570

來(lái)源：簡(jiǎn)書

簡(jiǎn)書著作權(quán)歸作者所有，任何形式的轉(zhuǎn)載都請(qǐng)聯(lián)系作者獲得授權(quán)并注明出處。Dapper和

Zipkin,Twitter的一個(gè)分布式系統(tǒng)跟蹤平臺(tái),生成隨機(jī)TraceIds(Pinpoint是TransactionIds)并將沖突情況視為正常。然而,在Pinpiont中我們想避免沖突的可能，因此實(shí)現(xiàn)了上面描述的系統(tǒng)。有兩種選擇：一是數(shù)據(jù)量小但是沖突的可能性高，二是數(shù)據(jù)量大但是沖突的可能性低。我們選擇了第二種。

AgentId：64位長(zhǎng)度整型

可能有更好的方式來(lái)處理transaction。我們起先有一個(gè)想法，通過(guò)中央key服務(wù)器來(lái)生成key。如果實(shí)現(xiàn)這個(gè)模式，可能導(dǎo)致性能問(wèn)題和網(wǎng)絡(luò)錯(cuò)誤。因此，大量生成key被考慮作為備選。后面這個(gè)方法可能被開發(fā)?，F(xiàn)在采用簡(jiǎn)單方法。在pinpoint中，TransactionId被當(dāng)成可變數(shù)據(jù)來(lái)對(duì)待。

使用字節(jié)碼增強(qiáng)技術(shù)，我們就不必?fù)?dān)心暴露跟蹤API而可以持續(xù)改進(jìn)設(shè)計(jì)，不用考慮依賴關(guān)系?！褪强梢韵笿B變了撒

針對(duì)PinPoint的擴(kuò)展和改造：-通信機(jī)制異步化調(diào)整；-探針引導(dǎo)程序premain改造；-gRPC探針；

DDD領(lǐng)域驅(qū)動(dòng)／CQRS讀寫分離／ES事件溯源這些前沿的時(shí)髦的技術(shù)理念匯聚在一次，落地到一套完整實(shí)現(xiàn)方案。這就是Axon

Command執(zhí)行過(guò)程：Command通過(guò)mandhandling.CommandBus分發(fā)，其中DistributedCommandBus實(shí)現(xiàn)了分布式的派發(fā)，它可以適配SpringCloud.主要邏輯是通過(guò)

AggregateIdentifier做一致性HASH。確保次對(duì)同一個(gè)聚合根發(fā)到同一臺(tái)機(jī)器，這樣保證了緩存的命中。Aggregate本質(zhì)上在應(yīng)用內(nèi)緩存了當(dāng)前狀態(tài)，如果該服務(wù)宕機(jī)。另一臺(tái)機(jī)器會(huì)通過(guò)事件溯源重新構(gòu)造出當(dāng)前狀態(tài)。Command的事務(wù)處理：Axon通過(guò)UnitofWork控制一致性，其中嵌入了JDBC事務(wù)。并且在回滾時(shí)會(huì)清除Aggregate緩存，下次會(huì)重新加載。當(dāng)然對(duì)于遠(yuǎn)程的子事務(wù)無(wú)法保證一致性。這是個(gè)大的隱患Saga最終一致性，補(bǔ)償機(jī)制。Saga的理念沒(méi)問(wèn)題，當(dāng)是實(shí)現(xiàn)起來(lái)問(wèn)題很大。一個(gè)是每個(gè)command都要?jiǎng)?chuàng)建event非常繁瑣，并且saga來(lái)來(lái)回回非常多另一個(gè)是沒(méi)有考慮到冪等，本地宕機(jī)，狀態(tài)，分布事務(wù)等細(xì)節(jié)的處理。自己實(shí)現(xiàn)也不靈活確保分布式事務(wù)一致性是個(gè)非常繁瑣的事情，請(qǐng)參考轉(zhuǎn)賬交易這件小事，是如何被程序員玩壞的.說(shuō)說(shuō)其他實(shí)現(xiàn)困難的情況如果Aggregate存在繼承關(guān)系，或者實(shí)現(xiàn)一些通用的行為接口?？蚣懿⒉恢С譄o(wú)法實(shí)現(xiàn)延遲觸發(fā)的功能對(duì)大量聚合實(shí)現(xiàn)批量操作不太容易幾乎所有的操作都要靠command觸發(fā)，然后轉(zhuǎn)成event,非常繁瑣。取其思想，尋找替代在交易中的訂單模型，本質(zhì)上就是ES中的Event.賬戶余額是用訂單累加出來(lái)的。只不過(guò)訂單不止記錄事件。還用來(lái)記錄更新審核狀態(tài)，系統(tǒng)狀態(tài)，事務(wù)狀態(tài)等，不那么純粹。通過(guò)訂單回溯賬戶狀態(tài)是個(gè)人工過(guò)程而不是自動(dòng)的。在這方面，Axon對(duì)事件的存儲(chǔ)采用統(tǒng)一的表，事件序列化到表中，并不有利于數(shù)據(jù)庫(kù)的查看。需要額外的記錄一個(gè)查詢視圖快照模型也在交易對(duì)賬中有所體現(xiàn)。每日對(duì)賬后生成當(dāng)日的一個(gè)快照，第二天的交易從快照開始累計(jì)Command模型配合只insert沒(méi)有update的操作，可以在高并發(fā)下實(shí)現(xiàn)無(wú)鎖處理。這個(gè)可以通過(guò)Kafka?；蛘邤?shù)據(jù)庫(kù)先插入，后異步讀取處理的方式來(lái)實(shí)現(xiàn)。充血模型是Axon的一個(gè)特色。不過(guò)并不難實(shí)現(xiàn)。通過(guò)自定義一個(gè)SpringCloudLoadBalancerRule實(shí)現(xiàn)哈希一致也可以實(shí)現(xiàn)。另外傳統(tǒng)的失血模型使用無(wú)狀態(tài)服務(wù)更簡(jiǎn)單，它可以在數(shù)據(jù)庫(kù)層面通過(guò)一致性hash來(lái)存儲(chǔ)數(shù)據(jù)，比如mongodb。對(duì)于訂單這樣的單一記錄低頻操作完全可以處理。對(duì)于同一記錄的高頻處理Axon也是有其優(yōu)勢(shì)的，不過(guò)Akka可能也是不錯(cuò)的選擇Saga異常難寫，在網(wǎng)絡(luò)異常，冪等，重試方面并不友好總結(jié)：DDD領(lǐng)域驅(qū)動(dòng)／CQRS讀寫分離／ES事件溯源，這些思想都很棒，但是并不用拘泥于特定的實(shí)現(xiàn)。Axon對(duì)于學(xué)習(xí)這些概念具有非常大的幫助，但是在實(shí)踐的過(guò)程中并不高效、靈活

作者：黃大海

鏈接：/p/4a7854e4b8f2

來(lái)源：簡(jiǎn)書

簡(jiǎn)書著作權(quán)歸作者所有，任何形式的轉(zhuǎn)載都請(qǐng)聯(lián)系作者獲得授權(quán)并注明出處。

Reveno是一個(gè)全新的無(wú)鎖事務(wù)處理框架，它支持JVM平臺(tái)，并基于CQRS及事件溯源模式實(shí)現(xiàn)。雖然它只是一個(gè)簡(jiǎn)單而強(qiáng)大的工具，但在性能方面也毫不遜色。所有事務(wù)都被持久化為只讀的日志，并且可以通過(guò)按順序重演事件的方式恢復(fù)領(lǐng)域模型的最新狀態(tài)。所有的運(yùn)行時(shí)操作都是在內(nèi)存中執(zhí)行的，從而使其吞吐量可達(dá)到每秒種幾百萬(wàn)次事務(wù)的數(shù)量級(jí)，平均延遲時(shí)間則限制在微秒級(jí)。雖然Reveno的功能如此強(qiáng)大，但它仍然是一個(gè)通用目的的框架，涵蓋了大量不同種類的用例，并提供了豐富的引擎配置選項(xiàng)。舉例來(lái)說(shuō)，你可以調(diào)整它的持久性配置，在極其隨意（為了提高系統(tǒng)吞吐量）與高度受限（對(duì)于數(shù)據(jù)丟失的情況具有較低的容忍度）之間進(jìn)行選擇。對(duì)于不同的用例來(lái)說(shuō)，其需求也是千差萬(wàn)別的。作為一個(gè)通用框架，它需要考慮所有不同的可能性。在本文中，我將通過(guò)示例為讀者展現(xiàn)如何使用Reveno框架開發(fā)一個(gè)簡(jiǎn)單的交易系統(tǒng)。首先讓我們來(lái)了解一下Reveno如何處理你的領(lǐng)域模型。作為一個(gè)基于CQRS的框架，Reveno會(huì)將你的領(lǐng)域切分為事務(wù)模型與查詢模型。對(duì)這兩個(gè)模型的定義沒(méi)有任何限制，你無(wú)需使用任何強(qiáng)制性的注解、基類，甚至不需要實(shí)現(xiàn)Serializable接口，只需使用最簡(jiǎn)單的POJO就可以完成任務(wù)。沒(méi)有任何一種單一的途徑能夠應(yīng)對(duì)所有不同的用例，因此應(yīng)用程序的設(shè)計(jì)者需要決定如何處理事務(wù)模型的回滾操作。Reveno為實(shí)現(xiàn)模型對(duì)象提供了兩種主要方式：可變與不可變模型。這兩種方式各有不同的底層處理機(jī)制，并且各有其優(yōu)缺點(diǎn)。在Java中，不可變對(duì)象的開銷很低，并且無(wú)需進(jìn)行同步操作，這種方式目前非常流行。Reveno能夠非常高效地處理不可變對(duì)象，但每種使用不可變類型的領(lǐng)域都會(huì)產(chǎn)生額外的垃圾對(duì)象，Reveno也不例外。因此，如果你能夠接受一些額外的GC開銷，那么就應(yīng)當(dāng)將這種方式作為默認(rèn)的選擇。反之，如果使用可變模型，那么在進(jìn)行事務(wù)運(yùn)行時(shí)，就要為已使用的對(duì)象生成額外的序列化快照，而這將影響到你的性能。幸運(yùn)的是，如果你堅(jiān)持使用可變模型，并且仍需要保證性能的最大化及GC影響的最小化，那么你可以選擇一種額外的可變模型特性，“補(bǔ)償行為”（CompensatingActions）。簡(jiǎn)單來(lái)說(shuō)，補(bǔ)償行為是指在實(shí)現(xiàn)常規(guī)的事務(wù)處理函數(shù)時(shí)，一并實(shí)現(xiàn)的一種手動(dòng)回滾行為。如果讀者想了解這方面的更多細(xì)節(jié)，請(qǐng)參考Reveno的官方文檔頁(yè)面。

Kubernetes

的核心概念講解入門Kubernetes

是非常困難的，因?yàn)檫@會(huì)涉及到許多的概念和新理念，本文以圖文并茂的形式總結(jié)了Kubernetes

中的核心概念。

它本不必如此困難？掌握Kubernetes

是非常困難的，因?yàn)榛ヂ?lián)網(wǎng)上有如此多的信息，有時(shí)候很難找到理解Kubernetes

的“核心”信息，當(dāng)我們看到

kubernetes.io

站點(diǎn)上概念頁(yè)面和文檔如此密集時(shí)更會(huì)如此。在本文中，我們將會(huì)探索Kubernetes

的核心概念，以便于獲取關(guān)于它的基礎(chǔ)知識(shí)，這樣我們就可以一起揭開Kubernetes

的神秘面紗。

什么是Kubernetes？Kubernetes

提供了基礎(chǔ)設(shè)置和構(gòu)造，幫助我們的團(tuán)隊(duì)構(gòu)建適用于開發(fā)和部署的可用平臺(tái)。用戶可以通過(guò)圖形化的用戶界面以及命令式和聲明式命令行接口管理Kubernetes

集群，Kubernetes

旨在管理容器化應(yīng)用程序和服務(wù)的整個(gè)生命周期。借助Kubernetes，我們可以擴(kuò)展和收縮應(yīng)用程序、執(zhí)行滾動(dòng)部署并管理由哪些服務(wù)處理特定的請(qǐng)求。它還提供了一個(gè)可擴(kuò)展的開發(fā)框架，允許我們的團(tuán)隊(duì)擴(kuò)展核心的Kubernetes

原語(yǔ)（primitive）以滿足個(gè)性化的需求。同時(shí)，它還支持創(chuàng)建自己的概念。但是，與大多數(shù)框架一樣，它的缺點(diǎn)之一是缺少許多現(xiàn)成的功能，無(wú)法被視為交鑰匙（turn-key）解決方案。在標(biāo)準(zhǔn)發(fā)行版中，它不包含服務(wù)如何相互通信的方法（甚至不包含網(wǎng)絡(luò)組件!），因此存在其他的發(fā)行版，另外我們也可以構(gòu)建自己的版本。容器容器是獨(dú)立、可執(zhí)行的軟件，它包含了運(yùn)行所需的所有內(nèi)容，比如代碼、庫(kù)和所有的外部依賴。它會(huì)確保運(yùn)行的內(nèi)容是完全相同的，即便是位于不同的環(huán)境中也是如此。這是通過(guò)將要運(yùn)行的代碼與它的運(yùn)行上下文隔離開實(shí)現(xiàn)的。在Linux

中，這是通過(guò)使用名為cgroups

的API

來(lái)分割Linux

內(nèi)核的一個(gè)子集來(lái)實(shí)現(xiàn)的。這種方式提供了與操作系統(tǒng)的高度隔離，但不會(huì)帶來(lái)像虛擬化環(huán)境（如VMWare、KVM

等）那樣的性能損耗。

Podpod

是Kubernetes

中最基本的對(duì)象。pod

是容器的集合，它們共享存儲(chǔ)和網(wǎng)絡(luò)，并且具備如何運(yùn)行它們的規(guī)范。每個(gè)pod

會(huì)分配自己的IP

地址。pod

中的容器會(huì)共享這個(gè)IP

地址、端口空間，并且能夠使用localhost

實(shí)現(xiàn)彼此查找。pod

應(yīng)該被視為短暫存活的原子單元。

Replicaset根據(jù)給定的模板，replicaset

可以運(yùn)行n

個(gè)pod。replicaset

并不會(huì)直接使用，但是需要理解這種資源，因?yàn)樵贙ubernetes

構(gòu)建應(yīng)用的時(shí)候，它是基礎(chǔ)的構(gòu)建塊。（按照指令）replicaset

可以按需擴(kuò)展和收縮pod

的數(shù)量。

Service因?yàn)閜od

是短期存活的（replicaset

通過(guò)擴(kuò)展和收縮pod

的數(shù)量實(shí)現(xiàn)這一點(diǎn)），那么這就帶來(lái)了一個(gè)問(wèn)題，現(xiàn)在，除非使用非常復(fù)雜的邏輯，否則我們幾乎不可能引用單個(gè)pod

以便于跟蹤拓?fù)浣Y(jié)構(gòu)的變化。Service

通過(guò)在pod

之上提供抽象來(lái)解決這個(gè)問(wèn)題，它提供了一個(gè)可尋址的方法來(lái)與pod

進(jìn)行通信。Service

操作的是OSI

模型之中的“第4

層”（IP

之上的TCP/UDP）。

DeploymentDeployment

管理replicaset，可以在應(yīng)用的不同版本間執(zhí)行滾動(dòng)更新。這是最常用的資源類型，它通過(guò)一個(gè)接口提供了對(duì)replicaset

和pod

的抽象。

在更新Deployment

的時(shí)候，換句話說(shuō)，也就是部署應(yīng)用的新版本，Deployment

控制器會(huì)創(chuàng)建一個(gè)新的replicaset，并管理新版本替換舊版本的滾動(dòng)更新。

在Kubernetes1.11

版本中，Deployment

目前不會(huì)自動(dòng)處理回滾。ConfigMap設(shè)計(jì)良好的應(yīng)用應(yīng)該遵循十二要素應(yīng)用宣言，應(yīng)用的配置應(yīng)該保存到“環(huán)境”中。盡管現(xiàn)在通用的安全實(shí)踐指出，在環(huán)境中存儲(chǔ)配置可能會(huì)導(dǎo)致私密的意外泄漏，因?yàn)橐恍?yīng)用程序在失敗時(shí)會(huì)暴露了它們的環(huán)境信息，但是無(wú)論如何，如果配置隨環(huán)境（開發(fā)、staging、生產(chǎn)）而變化的話，那么就應(yīng)該將它們與要構(gòu)建的應(yīng)用分開進(jìn)行存儲(chǔ)。ConfigMaps

允許將配置文件作為環(huán)境變量或文件系統(tǒng)掛載到Pod

中，從而解決了這個(gè)問(wèn)題。

SecretSecret

與ConfigMap

非常類似，顧名思義，它們對(duì)應(yīng)的是“Secret”信息。

DaemonsetDaemonset

會(huì)確保所有的節(jié)點(diǎn)都運(yùn)行特定的Pod。如果要在所有節(jié)點(diǎn)上運(yùn)行像日志代理（如fluentd）這樣的內(nèi)容的話，這是非常有用的。

它還能夠通過(guò)使用Taints

忽略特定的節(jié)點(diǎn)。Kubernetes之Taints與Tolerations污點(diǎn)和容忍作者：Flywithmeto

2018-04-10

來(lái)源：51CTO

NodeAffinity節(jié)點(diǎn)親和性，是Pod上定義的一種屬性，使Pod能夠按我們的要求調(diào)度到某個(gè)Node上，而Taints則恰恰相反，它可以讓Node拒絕運(yùn)行Pod，甚至驅(qū)逐Pod。

Taints(污點(diǎn))是Node的一個(gè)屬性，設(shè)置了Taints(污點(diǎn))后，因?yàn)橛辛宋埸c(diǎn)，所以Kubernetes是不會(huì)將Pod調(diào)度到這個(gè)Node上的，

于是Kubernetes就給Pod設(shè)置了個(gè)屬性Tolerations(容忍)，只要Pod能夠容忍N(yùn)ode上的污點(diǎn)，那么Kubernetes就會(huì)忽略Node上的污點(diǎn)，就能夠(不是必須)把Pod調(diào)度過(guò)去。

因此

Taints(污點(diǎn))通常與Tolerations(容忍)配合使用。

Ingress在大多數(shù)情況下，Service

和Pod

的IP

地址只能在Kubernetes

集群中進(jìn)行訪問(wèn)。Service

是與互聯(lián)網(wǎng)流量隔離的?！癐ngress

是一組規(guī)則集合，它允許入站的連接訪問(wèn)集群Service。”它可以用于負(fù)載平衡、終止TLS、為外部提供可路由的URL

等等。Ingress

只是另外一種Kubernetes

資源，但是，在大多數(shù)情況下,

它需要有一個(gè)Ingress

控制器，如Nginx

或Tr?fik

等。Kubernetes

是一個(gè)自動(dòng)化容器編排平臺(tái)，能夠允許應(yīng)用程序在大型平臺(tái)上大規(guī)模運(yùn)行，這些平臺(tái)可以包含不同處理器體系結(jié)構(gòu)和操作系統(tǒng)的組合，這完全由實(shí)現(xiàn)者決定。借助這些核心概念，Kubernetes

可以將Pod

安排到適當(dāng)?shù)墓?jié)點(diǎn)上，以確保Pod

的最大密度，這會(huì)由Kubernetes

實(shí)現(xiàn)的多種算法來(lái)控制，比如BinPacking，從而實(shí)現(xiàn)更高的硬件利用率。參考資料：[1]

/google-cloud/kubernetes-configmaps-and-secrets-68d061f7ab5b[2]

/google-cloud/kubernetes-configmaps-and-secrets-part-2-3dc37111f0dc[3]

https://kubernetes.io/docs/concepts/configuration/secret/[4]

https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/本文最初發(fā)表于

云原生計(jì)算基金會(huì)

官方博客，由InfoQ

中文站翻譯分享。KubernetesGitBook

https://kubernetes.feisky.xyz/he-xin-yuan-li/architecture

Kubernetes提供了兩種探針（Probe，支持exec、tcp和http方式）來(lái)探測(cè)容器的狀態(tài)：Kubelet使用livenessprobe（存活探針）來(lái)確定何時(shí)重啟容器。例如，當(dāng)應(yīng)用程序處于運(yùn)行狀態(tài)但無(wú)法做進(jìn)一步操作，liveness探針將捕獲到deadlock，重啟處于該狀態(tài)下的容器，使應(yīng)用程序在存在bug的情況下依然能夠繼續(xù)運(yùn)行下去（誰(shuí)的程序還沒(méi)幾個(gè)bug呢）。Kubelet使用readinessprobe（就緒探針）來(lái)確定容器是否已經(jīng)就緒可以接受流量。只有當(dāng)Pod中的容器都處于就緒狀態(tài)時(shí)kubelet才會(huì)認(rèn)定該P(yáng)od處于就緒狀態(tài)。該信號(hào)的作用是控制哪些Pod應(yīng)該作為service的后端。如果Pod處于非就緒狀態(tài)，那么它們將會(huì)被從service的loadbalancer中移除。

一個(gè)Kubernetes集群由分布式存儲(chǔ)

etcd、控制節(jié)點(diǎn)controller以及服務(wù)節(jié)點(diǎn)Node組成。

Play-with-k8s提供了一個(gè)免費(fèi)的k8s體驗(yàn)環(huán)境K8splayground

K8s借鑒了Borg->Omega的設(shè)計(jì)理念（谷歌），比如Pod、Service、Labels和單Pod單IP等。容器的資源隔離特性使得谷歌的資源使用率遠(yuǎn)遠(yuǎn)高出業(yè)界同行。例如，Borg使用容器將對(duì)延遲敏感、面向用戶的任務(wù)和批量任務(wù)放在相通的物理機(jī)上，并會(huì)為它們預(yù)留更多的資源，這樣可以解決loadspikes、fail-over等問(wèn)題。容器提供的資源管理工具使這些得以實(shí)現(xiàn)，穩(wěn)定的內(nèi)核層面的資源隔離也使進(jìn)程之間不互相干擾。我們通過(guò)在研發(fā)Borg的同時(shí)加強(qiáng)Linux容器的方式來(lái)獲得成功。然而，隔離并不是完美的，容器在內(nèi)核操作系統(tǒng)不能管理的資源隔離方面鞭長(zhǎng)莫及，比如level3processorcaches、內(nèi)存帶寬、以及容器需要被一個(gè)額外的安全層支持以抵抗云端的各種惡意攻擊。

Kubernetes主要由以下幾個(gè)核心組件組成：etcd保存了整個(gè)集群的狀態(tài)；kube-apiserver提供了資源操作的唯一入口，并提供認(rèn)證、授權(quán)、訪問(wèn)控制、API注冊(cè)和發(fā)現(xiàn)等機(jī)制；kube-controller-manager負(fù)責(zé)維護(hù)集群的狀態(tài)，比如故障檢測(cè)、自動(dòng)擴(kuò)展、滾動(dòng)更新等；kube-scheduler負(fù)責(zé)資源的調(diào)度，按照預(yù)定的調(diào)度策略將Pod調(diào)度到相應(yīng)的機(jī)器上；kubelet負(fù)責(zé)維持容器的生命周期，同時(shí)也負(fù)責(zé)Volume（CVI）和網(wǎng)絡(luò)（CNI）的管理；Containerruntime負(fù)責(zé)鏡像管理以及Pod和容器的真正運(yùn)行（CRI），默認(rèn)的容器運(yùn)行時(shí)為Docker；kube-proxy負(fù)責(zé)為Service提供cluster內(nèi)部的服務(wù)發(fā)現(xiàn)和負(fù)載均衡；除了核心組件，還有一些推薦的Add-ons：kube-dns負(fù)責(zé)為整個(gè)集群提供DNS服務(wù)IngressController為服務(wù)提供外網(wǎng)入口Heapster提供資源監(jiān)控Dashboard提供GUIFederation提供跨可用區(qū)的集群Fluentd-elasticsearch提供集群日志采集、存儲(chǔ)與查詢分層架構(gòu)：Kubernetes設(shè)計(jì)理念和功能其實(shí)就是一個(gè)類似Linux的分層架構(gòu)，如下圖所示

核心層：Kubernetes最核心的功能，對(duì)外提供API構(gòu)建高層的應(yīng)用，對(duì)內(nèi)提供插件式應(yīng)用執(zhí)行環(huán)境應(yīng)用層：部署（無(wú)狀態(tài)應(yīng)用、有狀態(tài)應(yīng)用、批處理任務(wù)、集群應(yīng)用等）和路由（服務(wù)發(fā)現(xiàn)、DNS解析等）管理層：系統(tǒng)度量（如基礎(chǔ)設(shè)施、容器和網(wǎng)絡(luò)的度量），自動(dòng)化（如自動(dòng)擴(kuò)展、動(dòng)態(tài)Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）——（k8s實(shí)踐利用storageclass實(shí)現(xiàn)pvc的動(dòng)態(tài)provision(volume使用cephrbd)）——存儲(chǔ)(Storage)是運(yùn)行有狀態(tài)容器的關(guān)鍵要素，Kubernetes提供了強(qiáng)大的原語(yǔ)來(lái)管理存儲(chǔ)。動(dòng)態(tài)卷配置(Dynamicprovisioning)是Kubernetes的獨(dú)有功能，它可以根據(jù)需要?jiǎng)討B(tài)的創(chuàng)建存儲(chǔ)卷。在動(dòng)態(tài)配置之前，集群管理員必須手動(dòng)調(diào)用云/存儲(chǔ)服務(wù)提供商的接口來(lái)配置新的存儲(chǔ)卷，然后創(chuàng)建PersistentVolume對(duì)象以在Kubernetes中表示和使用他們。通過(guò)動(dòng)態(tài)配置，可以實(shí)現(xiàn)兩個(gè)步驟的自動(dòng)化，無(wú)須集群管理員預(yù)先配置存儲(chǔ)資源，而是使用StorageClass對(duì)象制定的供應(yīng)商來(lái)動(dòng)態(tài)配置存儲(chǔ)資源，具體請(qǐng)參考用戶指南）。StorageClass本質(zhì)上是為底層存儲(chǔ)提供者描繪了藍(lán)圖，以及各種參數(shù)，例如磁盤類型（例如固態(tài)和標(biāo)準(zhǔn)磁盤）?！猀uotaResourceQuotas資源配額（ResourceQuotas）是用來(lái)限制用戶資源用量的一種機(jī)制。它的工作原理為資源配額應(yīng)用在Namespace上，并且每個(gè)Namespace最多只能有一個(gè)

ResourceQuota

對(duì)象開啟計(jì)算資源配額后，創(chuàng)建容器時(shí)必須配置計(jì)算資源請(qǐng)求或限制（也可以用

LimitRange

設(shè)置默認(rèn)值）用戶超額后禁止創(chuàng)建新的資源開啟資源配額功能首先，在APIServer啟動(dòng)時(shí)配置準(zhǔn)入控制

--admission-control=ResourceQuota然后，在namespace中創(chuàng)建一個(gè)

ResourceQuota

對(duì)象資源配額的類型計(jì)算資源，包括cpu和memorycpu,limits.cpu,requests.cpumemory,limits.memory,requests.memory存儲(chǔ)資源，包括存儲(chǔ)資源的總量以及指定storageclass的總量requests.storage：存儲(chǔ)資源總量，如500Gipersistentvolumeclaims：pvc的個(gè)數(shù).storageclass.storage.k8s.io/requests.storage.storageclass.storage.k8s.io/persistentvolumeclaimsrequests.ephemeral-storage和limits.ephemeral-storage（需要v1.8+）對(duì)象數(shù)，即可創(chuàng)建的對(duì)象的個(gè)數(shù)pods,replicationcontrollers,configmaps,secretsresourcequotas,persistentvolumeclaimsservices,services.loadbalancers,services.nodeports——PSP：Pod安全策略；——接口層：kubectl命令行工具、客戶端SDK以及集群聯(lián)邦生態(tài)系統(tǒng)：在接口層之上的龐大容器集群管理調(diào)度的生態(tài)系統(tǒng)，可以劃分為兩個(gè)范疇Kubernetes外部：日志、監(jiān)控、配置管理、CI、CD、Workflow、FaaS、OTS應(yīng)用、ChatOps等Kubernetes內(nèi)部：CRI、CNI、CVI、鏡像倉(cāng)庫(kù)、CloudProvider、集群自身的配置和管理等——OTS：offtheshell？——

核心組件：核心API：

生態(tài)系統(tǒng)：Etcd是CoreOS基于Raft開發(fā)的分布式key-value存儲(chǔ)，可用于服務(wù)發(fā)現(xiàn)、共享配置以及一致性保障（如數(shù)據(jù)庫(kù)選主、分布式鎖等）。

DaemonSet保證在每個(gè)Node上都運(yùn)行一個(gè)容器副本，常用來(lái)部署一些集群的日志、監(jiān)控或者其他系統(tǒng)管理應(yīng)用。典型的應(yīng)用包括：日志收集，比如fluentd，logstash等系統(tǒng)監(jiān)控，比如PrometheusNodeExporter，collectd，NewRelicagent，Gangliagmond等系統(tǒng)程序，比如kube-proxy,kube-dns,glusterd,ceph等

PersistentVolume(PV)和PersistentVolumeClaim(PVC)提供了方便的持久化卷：PV提供網(wǎng)絡(luò)存儲(chǔ)資源，而PVC請(qǐng)求存儲(chǔ)資源。這樣，設(shè)置持久化的工作流包括配置底層文件系統(tǒng)或者云數(shù)據(jù)卷、創(chuàng)建持久性數(shù)據(jù)卷、最后創(chuàng)建PVC來(lái)將Pod跟數(shù)據(jù)卷關(guān)聯(lián)起來(lái)。PV和PVC可以將pod和數(shù)據(jù)卷解耦，pod不需要知道確切的文件系統(tǒng)或者支持它的持久化引擎。

Kubernetes在設(shè)計(jì)之初就充分考慮了針對(duì)容器的服務(wù)發(fā)現(xiàn)與負(fù)載均衡機(jī)制，提供了Service資源，并通過(guò)kube-proxy配合cloudprovider來(lái)適應(yīng)不同的應(yīng)用場(chǎng)景。隨著kubernetes用戶的激增，用戶場(chǎng)景的不斷豐富，又產(chǎn)生了一些新的負(fù)載均衡機(jī)制。目前，kubernetes中的負(fù)載均衡大致可以分為以下幾種機(jī)制，每種機(jī)制都有其特定的應(yīng)用場(chǎng)景：Service：直接用Service提供cluster內(nèi)部的負(fù)載均衡，并借助cloudprovider提供的LB提供外部訪問(wèn)IngressController：還是用Service提供cluster內(nèi)部的負(fù)載均衡，但是通過(guò)自定義IngressController提供外部訪問(wèn)ServiceLoadBalancer：把loadbalancer直接跑在容器中，實(shí)現(xiàn)BareMetal的ServiceLoadBalancerCustomLoadBalancer：自定義負(fù)載均衡，并替代kube-proxy，一般在物理部署Kubernetes時(shí)使用，方便接入公司已有的外部服務(wù)

網(wǎng)絡(luò)插件：https://kubernetes.feisky.xyz/cha-jian-kuo-zhan/network

Cilium是一個(gè)基于eBPF和XDP的高性能容器網(wǎng)絡(luò)方案，提供了CNI和CNM插件。

Frakti是一個(gè)基于KubeletCRI的運(yùn)行時(shí)，它提供了hypervisor級(jí)別的隔離性，特別適用于運(yùn)行不可信應(yīng)用以及多租戶場(chǎng)景下。Frakti實(shí)現(xiàn)了一個(gè)混合運(yùn)行時(shí)：特權(quán)容器以Dockercontainer的方式運(yùn)行而普通容器則以hypercontainer的方法運(yùn)行在VM內(nèi)

服務(wù)治理：

一般準(zhǔn)則分離構(gòu)建和運(yùn)行環(huán)境使用dumb-int等避免僵尸進(jìn)程不推薦直接使用Pod，而是推薦使用Deployment/DaemonSet等不推薦在容器中使用后臺(tái)進(jìn)程，而是推薦將進(jìn)程前臺(tái)運(yùn)行，并使用探針保證服務(wù)確實(shí)在運(yùn)行中推薦容器中應(yīng)用日志打到stdout和stderr，方便日志插件的處理由于容器采用了COW，大量數(shù)據(jù)寫入有可能會(huì)有性能問(wèn)題，推薦將數(shù)據(jù)寫入到Volume中不推薦生產(chǎn)環(huán)境鏡像使用latest標(biāo)簽，但開發(fā)環(huán)境推薦使用并設(shè)置imagePullPolicy為Always推薦使用Readiness探針檢測(cè)服務(wù)是否真正運(yùn)行起來(lái)了使用activeDeadlineSeconds避免快速失敗的Job無(wú)限重啟引入Sidecar處理代理、請(qǐng)求速率控制和連接控制等問(wèn)題

分離構(gòu)建和運(yùn)行環(huán)境注意分離構(gòu)建和運(yùn)行環(huán)境，直接通過(guò)Dockerfile構(gòu)建的鏡像不僅體積大，包含了很多運(yùn)行時(shí)不必要的包，并且還容易引入安全隱患，如包含了應(yīng)用的源代碼?？梢允褂肈ocker多階段構(gòu)建來(lái)簡(jiǎn)化這個(gè)步驟。

COW：copyonwrite技術(shù)

https://juejin.im/post/5bd96bcaf265da396b72f855寫入時(shí)復(fù)制（英語(yǔ)：Copy-on-write，簡(jiǎn)稱COW）是一種計(jì)算機(jī)程序設(shè)計(jì)領(lǐng)域的優(yōu)化策略。其核心思想是，如果有多個(gè)調(diào)用者（callers）同時(shí)請(qǐng)求相同資源（如內(nèi)存或磁盤上的數(shù)據(jù)存儲(chǔ)），他們會(huì)共同獲取相同的指針指向相同的資源，直到某個(gè)調(diào)用者試圖修改資源的內(nèi)容時(shí)，系統(tǒng)才會(huì)真正復(fù)制一份專用副本（private