當k8s遇上長連線：
長連線是指在乙個tcp連線上可以連續傳送多個資料報，在tcp連線保持期間，如果沒有資料報傳送，需要雙方發檢測包以維持此連線；
短連線則是指通訊雙方有資料互動時，就建立乙個tcp連線，資料傳送完成後，則斷開此tcp連線，
其實長連線相較於通常的短連線，是長時間保持客戶端與服務端的連線狀態。
短連線的使用步驟：
建立連線→資料傳輸→關閉連線
長連線的使用步驟：
連線→資料傳輸→保持連線→資料傳輸→保持連線→……→關閉連線；
所以，這就要求長連線在沒有資料通訊時，定時傳送資料報，以維持連線狀態，而短連線在沒有資料傳輸時直接關閉即可。
對於長連線來說，無疑可以幫使用者省去很多tcp連線建立和關閉操作，從而節約時間。所以對於頻繁請求資源的客戶來說，比較適合用長連線，在長連線的應用場景下，客戶端一般不會主動關閉它們之間的連線，客戶端與服務端之間的連線如果一直不關閉的話，隨著客戶端連線越來越多，服務端的效能會受到影響；對於短連線來說，不需要考慮這個問題，因為存在的連線都是有用的連線，但是如果客戶請求頻繁，那麼在tcp的建立和關閉操作上會浪費較多的時間和頻寬。
所以長連線適用於請求頻繁且連線數不能太多的場景，例如資料庫連線；而短連線適用於併發量大且每個客戶端不會頻繁操作的場景，例如**的http服務。
在k8s中，提供了兩種方式來部署應用程式：services和deployments，其中：
deployments描述了需要執行的應用程式的副本數量，每乙個應用程式部署為乙個pod，並為其分配乙個ip位址；
services則類似於負載均衡器，其旨在將流量分配到一組pod。如下圖所示，可以將services理解成是乙個ip位址集合,每次對services發出請求時，都會從這個集合中選擇其中乙個ip位址並將其作為目標位址。客戶端發出請求時，無需知道後端服務連線了多少個pod，也不需要知道後端pod的ip位址， 只需要將請求傳送到ip位址不變的後端services位址即可。
目前解決長連線負載均衡問題的方案有：
一、在客戶端實現負載均衡
該方式需要修改客戶端程式，這裡可以根據具體需求設定乙個時間值或者請求量的值，當建立的長連線超過時間閾值或者請求量閾值時，斷開連線，再與服務端重新建立連線，從而實現負載均衡；
二、在服務端實現負載均衡
該方式需要修改服務端程式，這裡可以根據具體需求設定乙個時間值或者請求量的值，當建立的長連線超過時間閾值或者請求量閾值時，斷開連線，客戶端會再與服務端建立連線，從而實現負載均衡；
三、使用服務網格實現負載均衡
service mesh 其中乙個關鍵功能是負載均衡，具體可參考相關文件；
四、通過nginx實現負載均衡
對於這種方式，在k8s中有較為簡單且方便的實現方式，即為後端pod建立乙個ingress，通過配置均衡策略將請求**到後端pod，預設是輪詢策略，經過實驗驗證，ingress確實可以實現長連線的負載，注意需要確保nginx配置裡有proxy_http_version 1.1，因為http長連線的支援是從1.1版本後才有的。
K8S中的資源
k8s中所有的內容都抽象為資源，資源例項化之後，叫做物件 pod replicaset deployment,statefulset,daemonset,job,cronjob replicationcontroller 在v.11版本被廢棄 service,ingress.volume 儲存卷 c...
k8s中解決容器時差問題
解決k8s的pod容器的時差常用的兩種方式 1 通過設定pod 模板中的環境變數 env解決 在pod的模板中新增以下 apiversion v1 kind pod metadata name pod name spec containers name name image image name i...
k8s中的dns服務
kubernetes中有乙個很重要的特性，服務自發現。一旦乙個service被建立，該service的service ip和service port等資訊都可以被注入到pod中供它們使用。kubernetes主要支援兩種service發現 機制 環境變數和dns。沒有dns服務的時候，kuberne...