摘要:運(yùn)行得十分好,總是使用并且返回消息。這個(gè)問(wèn)題的提出意味著通過(guò)實(shí)施你自己的函數(shù)來(lái)使用原套,從回應(yīng)到讀取。額外的緩沖是因?yàn)檎?qǐng)求使用的是原始套接字的生成文件方法從中讀取數(shù)據(jù)。手動(dòng)進(jìn)行所以如何從使用通過(guò)自己發(fā)出請(qǐng)求和處理響應(yīng)。
Kubernetes有一個(gè)之前系統(tǒng)用來(lái)做很多工作的REST-ish HTTP API。這個(gè)API是開(kāi)放的,而且文檔十分齊全,很容易整合,可以從代碼方面管理集群。然而這個(gè)API還有一個(gè)不直接映射到HTTP的概念:WATCH。resource有任何的修改,它就會(huì)通知API用戶。然而這個(gè)功能的調(diào)用,還是有一定工作量的,我們來(lái)探個(gè)究竟。
WATCH請(qǐng)求剖析從Python使用Kubernetes API,如果使用Request庫(kù)的話,就十分輕松。API運(yùn)行得十分好,總是使用并且返回JSON消息。但是發(fā)行watch請(qǐng)求就變得復(fù)雜多了。發(fā)一個(gè)watch請(qǐng)求理論上有兩種方法:一個(gè)是用流傳輸結(jié)果的普通HTTP請(qǐng)求,同時(shí)使用分塊編碼;另一種方法是使用websockets。不幸的是,當(dāng)測(cè)試Kubernetes1.1 master的時(shí)候,并沒(méi)有正確地使用websocket協(xié)議,所以使用流傳輸結(jié)果才是正確的方法。
當(dāng)使用分塊編碼流傳輸?shù)臅r(shí)候,Kubernetes master會(huì)通過(guò)發(fā)送分塊的尺寸開(kāi)始傳輸分塊。但是它不會(huì)發(fā)送一整個(gè)分塊,它只會(huì)發(fā)送一行文本,再被一行新的文本終止。這行文本是JSON編碼對(duì)象,里面還有event以及修改過(guò)的resource項(xiàng)目。所以協(xié)議是基于行的,而分塊編碼只是當(dāng)結(jié)果可得的時(shí)候一個(gè)用來(lái)分流這些結(jié)果的方法。從表面上看用請(qǐng)求來(lái)做這個(gè)似乎不那么難:
然而iter_lines方法并沒(méi)有按照你想要的方向來(lái)做,它保有一個(gè)外部緩沖,這個(gè)緩沖意味著你永遠(yuǎn)都看不到最后一個(gè)event因?yàn)槟氵€在等著填滿那個(gè)緩沖。
這個(gè)問(wèn)題的提出意味著通過(guò)實(shí)施你自己的iter_lines()函數(shù)來(lái)使用原套socket,從回應(yīng)socket到讀取socket。很不幸,那個(gè)簡(jiǎn)單的方法犯了一些錯(cuò)誤。首先,它沒(méi)有正確地處理分塊編碼,描述分塊大小的八位元數(shù)會(huì)出現(xiàn)在輸出過(guò)程。但是更加重要的是,另一個(gè)緩沖層次正在繼續(xù),一個(gè)你不能進(jìn)行應(yīng)急操作的緩沖層次。額外的緩沖是因?yàn)檎?qǐng)求使用的是原始套接字的生成文件方法從中讀取數(shù)據(jù)。這對(duì)于Requests來(lái)說(shuō)就講得通了,Python標(biāo)準(zhǔn)庫(kù)和OS都擅長(zhǎng)通過(guò)緩沖加速。然而這并不意味著在Requests解析了響應(yīng)的標(biāo)頭后,緩沖就已經(jīng)不知道使用了響應(yīng)本身多大的字節(jié),而且這些字節(jié)無(wú)法檢索。所以使用Requests來(lái)使用watch API基本上不太可能。
手動(dòng)進(jìn)行HTTP所以如何從Python使用watch API?通過(guò)自己發(fā)出請(qǐng)求和處理響應(yīng)。這個(gè)做起來(lái)其實(shí)很簡(jiǎn)單,socket編程其實(shí)沒(méi)那么嚇人。首先,你需要連接socket到服務(wù)器,然后發(fā)送HTTP request。HTTP非常簡(jiǎn)單,你只需要在socket上發(fā)送一些標(biāo)頭即可:
注意,Host標(biāo)頭被Kubernetes master要求用來(lái)接受request。
解析HTTP響應(yīng)稍微有點(diǎn)復(fù)雜。然而http-parser庫(kù)實(shí)施HTTP解析方面的東西的時(shí)候,沒(méi)有涉及到sockets或者任何類似于網(wǎng)絡(luò)的東西。所以我們可以輕松地讀取和解析響應(yīng):
現(xiàn)在我們來(lái)響應(yīng)已經(jīng)被解析的標(biāo)頭。很可能,一些本體數(shù)據(jù)已經(jīng)接收到了,這很棒,這些本體數(shù)據(jù)在解析器中仍處于緩沖好的的狀態(tài),直到我們檢索它。但是首先讓我們來(lái)保持讀取數(shù)據(jù),直到?jīng)]有剩下的為止(不要在生產(chǎn)過(guò)程中這么做,對(duì)你的存儲(chǔ)系統(tǒng)不好)。
上圖展示了如何使用select在數(shù)據(jù)可得的時(shí)候只讀數(shù)據(jù),而不是先阻斷,然后使數(shù)據(jù)再次可讀。當(dāng)然,一旦使用了所有的數(shù)據(jù),Kubernetes master 可能就會(huì)發(fā)送下一版本更新到PodList,但是讓我們現(xiàn)在先來(lái)讀一下接收到的events:
就是它!如果數(shù)據(jù)接收截至在換行符,然后lines.split() 調(diào)用會(huì)回到一個(gè)空的字符串(b"")作為最后一個(gè)項(xiàng)目。如果數(shù)據(jù)沒(méi)有在一個(gè)新的換行符那里結(jié)束,那么一個(gè)未完成的event會(huì)被接收,這樣當(dāng)我們獲得其它數(shù)據(jù)的時(shí)候我們就需要保存下來(lái)。
結(jié)論所以為了正確地使用Kubernetes watch API調(diào)用的響應(yīng),你需要?jiǎng)?chuàng)建你自己的socket連接,并且解析HTTP響應(yīng)。很幸運(yùn),這并沒(méi)有想象得那么難。你并不需要全部自己來(lái)寫!我們已經(jīng)都實(shí)施過(guò)了,而且更多信息在我們的kube項(xiàng)目里,這也給我們提供了一個(gè)相當(dāng)好的被包裝成一個(gè)迭代器API的安裝啟用。Kube本身仍然需要更多的新功能,但是watch功能的實(shí)現(xiàn)已經(jīng)十分有用了。
原文鏈接
(如果需要轉(zhuǎn)載,請(qǐng)聯(lián)系我們哦,尊重知識(shí)產(chǎn)權(quán)人人有責(zé):)
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://m.specialneedsforspecialkids.com/yun/32475.html
摘要:自定義指標(biāo)由提供,由此可支持任意采集到的指標(biāo)。文件清單的,收集級(jí)別的監(jiān)控?cái)?shù)據(jù)監(jiān)控服務(wù)端,從拉數(shù)據(jù)并存儲(chǔ)為時(shí)序數(shù)據(jù)。本文為容器監(jiān)控實(shí)踐系列文章,完整內(nèi)容見(jiàn) 概述 上文metric-server提到,kubernetes的監(jiān)控指標(biāo)分為兩種: Core metrics(核心指標(biāo)):從 Kubelet、cAdvisor 等獲取度量數(shù)據(jù),再由metrics-server提供給 Dashboar...
摘要:自定義指標(biāo)由提供,由此可支持任意采集到的指標(biāo)。文件清單的,收集級(jí)別的監(jiān)控?cái)?shù)據(jù)監(jiān)控服務(wù)端,從拉數(shù)據(jù)并存儲(chǔ)為時(shí)序數(shù)據(jù)。本文為容器監(jiān)控實(shí)踐系列文章,完整內(nèi)容見(jiàn) 概述 上文metric-server提到,kubernetes的監(jiān)控指標(biāo)分為兩種: Core metrics(核心指標(biāo)):從 Kubelet、cAdvisor 等獲取度量數(shù)據(jù),再由metrics-server提供給 Dashboar...
摘要:今天是數(shù)人云容器三國(guó)演義嘉賓演講實(shí)錄第四彈。說(shuō)完了各家容器技術(shù)的實(shí)戰(zhàn),那么最后來(lái)看容器技術(shù)的融合正在探索的一條道路。月,開(kāi)始接手,因?yàn)檎麄€(gè)產(chǎn)品都是基于這個(gè)為基礎(chǔ)的。下面是的地址,到可以找到相關(guān)的資料。但這時(shí)候是分開(kāi)的,不同的使用不同的框架。 今天是數(shù)人云容器三國(guó)演義Meetup嘉賓演講實(shí)錄第四彈。說(shuō)完了各家容器技術(shù)的實(shí)戰(zhàn),那么最后來(lái)看容器技術(shù)的融合——IBM正在探索的一條道路。 我叫馬...
摘要:今天是數(shù)人云容器三國(guó)演義嘉賓演講實(shí)錄第四彈。說(shuō)完了各家容器技術(shù)的實(shí)戰(zhàn),那么最后來(lái)看容器技術(shù)的融合正在探索的一條道路。月,開(kāi)始接手,因?yàn)檎麄€(gè)產(chǎn)品都是基于這個(gè)為基礎(chǔ)的。下面是的地址,到可以找到相關(guān)的資料。但這時(shí)候是分開(kāi)的,不同的使用不同的框架。 今天是數(shù)人云容器三國(guó)演義Meetup嘉賓演講實(shí)錄第四彈。說(shuō)完了各家容器技術(shù)的實(shí)戰(zhàn),那么最后來(lái)看容器技術(shù)的融合——IBM正在探索的一條道路。 我叫馬...
摘要:前言本文給大家分享的題目是基于微服務(wù)以及的高可用架構(gòu)探索與實(shí)現(xiàn)。比如說(shuō)年大地震的時(shí)候我正好在東京,當(dāng)時(shí)在做一個(gè)金融系統(tǒng)的相關(guān)工作。那次大地震導(dǎo)致很多很多的問(wèn)題,雖然大地震不是在東京發(fā)生,但是還是給我們的系統(tǒng)造成了影響。 前言 本文給大家分享的題目是《基于DevOps、微服務(wù)以及K8S的高可用架構(gòu)探索與實(shí)現(xiàn)》。整個(gè)企業(yè)的高可用架構(gòu)面臨很多的挑戰(zhàn),面向微服務(wù)、容器化以及敏態(tài)交付,是我們現(xiàn)在...
閱讀 3205·2021-09-29 09:34
閱讀 3560·2021-09-10 10:51
閱讀 1958·2021-09-10 10:50
閱讀 6759·2021-08-12 13:31
閱讀 3006·2019-08-30 15:54
閱讀 1577·2019-08-30 15:44
閱讀 1434·2019-08-29 12:26
閱讀 2661·2019-08-26 18:36