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