国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

伸縮Kubernetes到2500個節點中遇到的問題和解決方法

JaysonWang / 1904人閱讀

摘要:自從起便號稱可以承載個以上的節點,但是從數十到的路上,難免會遇到問題。本片文章即分享在之路上的經驗,包括遇到的問題嘗試解決問題以及找到真正的問題。

Kubernetes自從1.6起便號稱可以承載5000個以上的節點,但是從數十到5000的路上,難免會遇到問題。

本片文章即分享Open API在kubernetes 5000之路上的經驗,包括遇到的問題、嘗試解決問題以及找到真正的問題。

遇到的問題以及如何解決 問題一:1 ~ 500個節點之后

問題:

kubectl 有時會出現 timeout(p.s. kubectl -v=6 可以顯示所有API細節指令)

嘗試解決:

一開始以為是kube-apiserver服務器負載的問題,嘗試增加proxy做replica協助進行負載均衡

但是超過10個備份master的時候,發現問題不是因為kube-apiserver無法承受負載,GKE通過一臺32-core VM就可以承載500個節點

原因:

排除以上原因,開始排查master上剩下的幾個服務(etcd、kube-proxy)

開始嘗試調整etcd

通過使用datadog查看etcd吞吐量,發現有異常延遲(latency spiking ~100 ms)

通過Fio工具做性能評估,發現只用到10%的IOPS(Input/Output Per Second),由于寫入延遲(write latency 2ms)降低了性能

嘗試把SSD從網絡硬盤變為每臺機器有個local temp drive(SSD)

結果從~100ms —> 200us

問題二:~1000個節點的時候

問題:

發現kube-apiserver每秒從etcd上讀取500mb

嘗試解決:

通過Prometheus查看container之間的網絡流量

原因:

發現Fluentd和Datadog抓取每個節點上資料過于頻繁

調低兩個服務的抓取頻率,網絡性能從500mb/s降低到幾乎沒有

etcd小技巧:通過--etcd-servers-overrides可以將Kubernetes Event的資料寫入作為切割,分不同機器處理,如下所示

--etcd-servers-overrides=/events#https://0.example.com:2381;https://1.example.com:2381;https://2.example.com:2381
問題三:1000 ~ 2000個節點

問題:

無法再寫入數據,報錯cascading failure

kubernetes-ec2-autoscaler在全部的etcd都停掉以后才回傳問題,并且關閉所有的etcd

嘗試解決:

猜測是etcd硬盤滿了,但是檢查SSD依舊有很多空間

檢查是否有預設的空間限制,發現有2GB大小限制

解決方法:

在etcd啟動參數中加入--quota-backend-bytes

修改kubernetes-ec2-autoscaler邏輯——如果超過50%出現問題,關閉集群

各種服務的優化 Kube masters 的高可用

一般來說,我們的架構是一個kube-master(主要的 Kubernetes 服務提供組件,上面有kube-apiserver、kube-scheduler 和kube-control-manager)加上多個slave。但是要達到高可用,要參考一下方式實現:

kube-apiserver要設置多個服務,并且通過參數--apiserver-count重啟并且設定

kubernetes-ec2-autoscaler可以幫助我們自動關閉idle的資源,但是這跟Kubernetes scheduler的原則相悖,不過通過這些設定,可以幫助我們盡量集中資源。

{
"kind" : "Policy",
"apiVersion" : "v1",
"predicates" : [
  {"name" : "GeneralPredicates"},
  {"name" : "MatchInterPodAffinity"},
  {"name" : "NoDiskConflict"},
  {"name" : "NoVolumeZoneConflict"},
  {"name" : "PodToleratesNodeTaints"}
  ],
"priorities" : [
  {"name" : "MostRequestedPriority", "weight" : 1},
  {"name" : "InterPodAffinityPriority", "weight" : 2}
  ]
}

以上為調整kubernetes scheduler范例,通過調高InterPodAffinityPriority的權重,達到我們的目的。更多示范參考范例.

需要注意的是,目前Kubernetes Scheduler Policy并不支持動態切換,需要重啟kube-apiserver(issue: 41600)

調整scheduler policy造成的影響

OpenAI使用了KubeDNS ,但不久后發現——

問題:

經常出現DNS查詢不到的情況(隨機發生)

超過 ~200QPS domain lookup

嘗試解決:

嘗試查看為何有這種狀態,發現有些node上跑了超過10個KuberDNS

解決方法:

由于scheduler policy造成了許多POD的集中

KubeDNS很輕量,容易被分配到同一節點上,造成domain lookup的集中

需要修改POD affinity(相關介紹),盡量讓KubeDNS分配到不同的node之上

affinity:
 podAntiAffinity:
   requiredDuringSchedulingIgnoredDuringExecution:
   - weight: 100
     labelSelector:
       matchExpressions:
       - key: k8s-app
         operator: In
         values:
         - kube-dns
     topologyKey: kubernetes.io/hostname
新建節點時Docker image pulls緩慢的問題

問題:

每次新節點建立起來,docker image pull都要花30分鐘

嘗試解決:

有一個很大的container image Dota,差不多17GB,影響了整個節點的image pulling

開始檢查kubelet是否有其他image pull選項

解決方法:

在kubelet增加選項--serialize-image-pulls=false來啟動image pulling,讓其他服務可以更早地pull(參考:kubelet啟動選項)

這個選項需要docker storgae切換到overlay2(可以參考docker教學文章)

并且把docker image存放到SSD,可以讓image pull更快一些

補充:source trace

// serializeImagePulls when enabled, tells the Kubelet to pull images one
// at a time. We recommend *not* changing the default value on nodes that
// run docker daemon with version  < 1.9 or an Aufs storage backend.
// Issue #10959 has more details.
SerializeImagePulls *bool `json:"serializeImagePulls"`
提高docker image pull的速度

此外,還可以通過以下方式來提高pull的速度

kubelet參數--image-pull-progress-deadline要提高到30mins
docker daemon參數max-concurrent-download調整到10才能多線程下載

網絡性能提升

Flannel性能限制

OpenAI節點間的網絡流量,可以達到10-15GBit/s,但是由于Flannel所以導致流量會降到 ~2GBit/s

解決方式是拿掉Flannel,使用實際的網絡

hostNetwork: true

dnsPolicy: ClusterFirstWithHostNet

這里還有一些注意事項需要詳細閱讀


想要簡單易用、生產就緒的Kubernetes?試試好雨Rainbond——以應用的方式包裝Kubernetes,理解和使用更簡單,各種管理流程開箱即用!

好雨Rainbond(云幫)是一款以應用為中心的開源PaaS,深度整合基于Kubernetes的容器管理、Service Mesh微服務架構最佳實踐、多類型CI/CD應用構建與交付、多數據中心資源管理等技術,為用戶提供云原生應用全生命周期解決方案,構建應用與基礎設施、應用與應用、基礎設施與基礎設施之間互聯互通的生態體系,滿足支撐業務高速發展所需的敏捷開發、高效運維和精益管理需求。

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/32659.html

相關文章

  • LC3視角:Kubernetes下日志采集、存儲與處理技術實踐

    摘要:下需要為每個單獨進行采集配置采集日志目錄,采集規則,存儲目標等,不易維護。日志服務的日志架構實踐我們提出基于阿里云日志服務的日志處理架構,用以補充社區的方案,來嘗試解決場景下日志處理的一些細節體驗問題。 摘要: 在Kubernetes服務化、日志處理實時化以及日志集中式存儲趨勢下,Kubernetes日志處理上也遇到的新挑戰,包括:容器動態采集、大流量性能瓶頸、日志路由管理等問題。本文...

    Guakin_Huang 評論0 收藏0
  • Kubernetes Autoscaling是如何工作

    摘要:是如何工作的這是最近我們經常被問到的一個問題。是一個控制循環,用于監視和縮放部署中的。最早版本僅支持作為可監控的度量標準。是版本以上的首選方法。 Kubernetes Autoscaling是如何工作的?這是最近我們經常被問到的一個問題。 所以本文將從Kubernetes Autoscaling功能的工作原理以及縮放集群時可以提供的優勢等方面進行解釋。 什么是Autoscaling 想...

    zhunjiee 評論0 收藏0
  • 關于容器,你不能不看這篇

    摘要:其次,青云的負載均衡器能感知到容器網絡,而傳統的方案在內部還需要再做一層虛擬網絡,層的負載均衡器無法感知容器網絡。 前言 容器技術目前的市場現狀是一家獨大、百花齊放。 關于容器技術,看看青云QingCloud 王淵命(老王)是如何看待它的,本文來自他在青云QingCloud 深圳站實踐課堂的演講。全文 2780字,閱讀時長約為 11 分鐘。 容器是什么 容器的概念外延比較廣,討論的時候...

    zzzmh 評論0 收藏0
  • Kubernetes容器編排三大支柱

    摘要:在這種情況下,以防干擾其他集群租戶,調度器可能會考慮將作為驅逐的候選對象。其結果是負載均衡和調度之間交互作用。 每當談及Kubernetes,我們經常聽到諸如資源管理、調度和負載均衡等術語。雖然Kubernetes提供了許多功能,但更關鍵的還是要了解這些概念,只有這樣才能更好地理解如何放置、管理并恢復工作負載。在這篇文章中,我提供了每個功能的概述,并解釋了它們是如何在Kubernete...

    劉厚水 評論0 收藏0

發表評論

0條評論

最新活動
閱讀需要支付1元查看
<