【重識雲原生】第六章容器6.1.7.1節——Docker核心技術cgroups綜述 1. cgroups概述 參考鏈接

  《重識雲原生系列》專題索引:

  1. 第一章——不謀全局不足以謀一域
  2. 第二章計算第1節——計算虛擬化技術總述
  3. 第二章計算第2節——主流虛擬化技術之VMare ESXi
  4. 第二章計算第3節——主流虛擬化技術之Xen
  5. 第二章計算第4節——主流虛擬化技術之KVM
  6. 第二章計算第5節——商用雲主機方案
  7. 第二章計算第6節——裸金屬方案
  8. 第三章雲存儲第1節——分佈式雲存儲總述
  9. 第三章雲存儲第2節——SPDK方案綜述
  10. 第三章雲存儲第3節——Ceph統一存儲方案
  11. 第三章雲存儲第4節——OpenStack Swift 對象存儲方案
  12. 第三章雲存儲第5節——商用分佈式雲存儲方案
  13. 第四章雲網絡第一節——雲網絡技術發展簡述
  14. 第四章雲網絡4.2節——相關基礎知識準備
  15. 第四章雲網絡4.3節——重要網絡協議
  16. 第四章雲網絡4.3.1節——路由技術簡述
  17. 第四章雲網絡4.3.2節——VLAN技術
  18. 第四章雲網絡4.3.3節——RIP協議
  19. 第四章雲網絡4.3.4節——OSPF協議
  20. 第四章雲網絡4.3.5節——EIGRP協議
  21. 第四章雲網絡4.3.6節——IS-IS協議
  22. 第四章雲網絡4.3.7節——BGP協議
  23. 第四章雲網絡4.3.7.2節——BGP協議概述
  24. 第四章雲網絡4.3.7.3節——BGP協議實現原理
  25. 第四章雲網絡4.3.7.4節——高級特性
  26. 第四章雲網絡4.3.7.5節——實操
  27. 第四章雲網絡4.3.7.6節——MP-BGP協議
  28. 第四章雲網絡4.3.8節——策略路由
  29. 第四章雲網絡4.3.9節——Graceful Restart(平滑重啓)技術
  30. 第四章雲網絡4.3.10節——VXLAN技術
  31. 第四章雲網絡4.3.10.2節——VXLAN Overlay網絡方案設計
  32. 第四章雲網絡4.3.10.3節——VXLAN隧道機制
  33. 第四章雲網絡4.3.10.4節——VXLAN報文轉發過程
  34. 第四章雲網絡4.3.10.5節——VXlan組網架構
  35. 第四章雲網絡4.3.10.6節——VXLAN應用部署方案
  36. 第四章雲網絡4.4節——Spine-Leaf網絡架構
  37. 第四章雲網絡4.5節——大二層網絡
  38. 第四章雲網絡4.6節——Underlay 和 Overlay概念
  39. 第四章雲網絡4.7.1節——網絡虛擬化與卸載加速技術的演進簡述
  40. 第四章雲網絡4.7.2節——virtio網絡半虛擬化簡介
  41. 第四章雲網絡4.7.3節——Vhost-net方案
  42. 第四章雲網絡4.7.4節vhost-user方案——virtio的DPDK卸載方案
  43. 第四章雲網絡4.7.5節vDPA方案——virtio的半硬件虛擬化實現
  44. 第四章雲網絡4.7.6節——virtio-blk存儲虛擬化方案
  45. 第四章雲網絡4.7.8節——SR-IOV方案
  46. 第四章雲網絡4.7.9節——NFV
  47. 第四章雲網絡4.8.1節——SDN總述
  48. 第四章雲網絡4.8.2.1節——OpenFlow概述
  49. 第四章雲網絡4.8.2.2節——OpenFlow協議詳解
  50. 第四章雲網絡4.8.2.3節——OpenFlow運行機制
  51. 第四章雲網絡4.8.3.1節——Open vSwitch簡介
  52. 第四章雲網絡4.8.3.2節——Open vSwitch工作原理詳解
  53. 第四章雲網絡4.8.4節——OpenStack與SDN的集成
  54. 第四章雲網絡4.8.5節——OpenDayLight
  55. 第四章雲網絡4.8.6節——Dragonflow
  56.  第四章雲網絡4.9.1節——網絡卸載加速技術綜述

  57. 第四章雲網絡4.9.2節——傳統網絡卸載技術

  58. 第四章雲網絡4.9.3.1節——DPDK技術綜述

  59. 第四章雲網絡4.9.3.2節——DPDK原理詳解

  60. 第四章雲網絡4.9.4.1節——智能網卡SmartNIC方案綜述

  61. 第四章雲網絡4.9.4.2節——智能網卡實現

  62. 第六章容器6.1.1節——容器綜述

  63. 第六章容器6.1.2節——容器安裝部署

  64. 第六章容器6.1.3節——Docker常用命令

  65. 第六章容器6.1.4節——Docker核心技術LXC

  66. 第六章容器6.1.5節——Docker核心技術Namespace

  67. 第六章容器6.1.6節—— Docker核心技術Chroot

  68. 第六章容器6.1.7.1節——Docker核心技術cgroups綜述

  69. 第六章容器6.1.7.2節——cgroups原理剖析

  70. 第六章容器6.1.7.3節——cgroups數據結構剖析

  71. 第六章容器6.1.7.4節——cgroups使用

  72. 第六章容器6.1.8節——Docker核心技術UnionFS

  73. 第六章容器6.1.9節——Docker鏡像技術剖析

  74. 第六章容器6.1.10節——DockerFile解析

  75. 第六章容器6.1.11節——docker-compose容器編排

  76. 第六章容器6.1.12節——Docker網絡模型設計

  77. 第六章容器6.2.1節——Kubernetes概述

  78. 第六章容器6.2.2節——K8S架構剖析

  79. 第六章容器6.3.1節——K8S核心組件總述

  80. 第六章容器6.3.2節——API Server組件

  81. 第六章容器6.3.3節——Kube-Scheduler使用篇

  82. 第六章容器6.3.4節——etcd組件

  83. 第六章容器6.3.5節——Controller Manager概述

  84. 第六章容器6.3.6節——kubelet組件

  85. 第六章容器6.3.7節——命令行工具kubectl

  86. 第六章容器6.3.8節——kube-proxy

  87. 第六章容器6.4.1節——K8S資源對象總覽

  88. 第六章容器6.4.2.1節——pod詳解

  89. 第六章容器6.4.2.2節——Pod使用(上)

  90. 第六章容器6.4.2.3節——Pod使用(下)

  91. 第六章容器6.4.3節——ReplicationController

  92. 第六章容器6.4.4節——ReplicaSet組件

  93. 第六章容器基礎6.4.5.1節——Deployment概述

  94. 第六章容器基礎6.4.5.2節——Deployment配置詳細說明

  95. 第六章容器基礎6.4.5.3節——Deployment實現原理解析

  96. 第六章容器基礎6.4.6節——Daemonset

  97. 第六章容器基礎6.4.7節——Job

  98. 第六章容器基礎6.4.8節——CronJob

1. cgroups概述

1.1 爲什麼需要cgroup

        在Linux裏,一直以來就有對進程進行分組的概念和需求,比如session group, progress group等,後來隨着人們對這方面的需求越來越多,比如需要追蹤一組進程的內存和IO使用情況等,於是出現了cgroup,用來統一將進程進行分組,並在分組的基礎上對進程進行監控和資源控制管理等。

1.2 cgroups簡介

        cgroups全稱是control groups,是 Linux 內核的一個功能,用來限制、控制與分離一個進程組的資源(如CPU、內存、磁盤輸入輸出等)。它是由 Google 的兩位工程師進行開發的,自 2008 年 1 月正式發佈的 Linux 內核 v2.6.24 開始提供此能力。cgroups 到目前爲止,有兩個大版本, cgroup v1 和 v2 。cgroup 主要限制的資源是、CPU、內存、網絡、磁盤 I/O。當我們將可用系統資源按特定百分比分配給 cgroup 時,剩餘的資源可供系統上的其他 cgroup 或其他進程使用。

        cgroup 的作用基本上就是控制一個進程或一組進程可以訪問或使用給定關鍵資源(CPU、內存、網絡和磁盤 I/O)的量。一個容器中通常運行了多個進程,並且您需要對這些進程實施統一控制,因此 cgroup 是容器的關鍵組件,爲容器虛擬化提供了最基本的保證,是構建docker一系列虛擬化的管理工具。Kubernetes 環境使用cgroup 在 pod 級別上部署資源請求和限制以及對應的 QoS 類。

        下圖說明了當您將特定比例的可用系統資源分配給一個 cgroup(在本例中,爲cgroup‑1)後,剩餘資源是如何在系統上其他 cgroup(以及各個進程)之間進行分配的:

cgroup 資源分配及剩餘可用資源示例圖

1.3 cgroups基本概念

        cgroups主要由task、cgroup、subsystem及hierarchy構成:

  • task:在cgroups中,task就是系統的一個進程。
  • control group(簡寫:cgroup):控制族羣就是按照某種標準劃分的進程,包含一個或多個子系統。Cgroups 中的資源控制都是以控制族羣爲單位實現。一個進程可以加入到某個控制族羣,也可從一個進程組遷移到另一個控制族羣。一個進程組的進程可以使用 cgroups 以控制族羣爲單位分配的資源,同時受到 cgroups 以控制族羣爲單位設定的限制;
  • hierarchy(層級樹):控制族羣可以組織成 hierarchical 的形式,既一顆控制族羣樹。控制族羣樹上的子節點控制族羣是父節點控制族羣的孩子,繼承父控制族羣的特定的屬性;hierarchy由一系列cgroup以一個樹狀結構排列而成,每個hierarchy通過綁定對應的subsystem進行資源調度;hierarchy中的cgroup節點可以包含零或多個子節點,子節點繼承父節點的屬性;整個系統可以有多個hierarchy。
  • subsystem:Cgroups中的subsystem就是一個資源調度控制器(Resource Controller),比如CPU子系統可以控制CPU時間分配,內存子系統可以限制cgroup內存使用量;子系統必須附加(attach)到一個層級上才能起作用,一個子系統附加到某個層級以後,這個層級上的所有控制族羣都受到這個子系統的控制。但是資源調度控制器這個說法也不完全準確,因爲有時我們將進程分組只是爲了做一些監控,觀察一下他們的狀態,比如perf_event subsystem。到目前爲止,Linux支持12種subsystem,比如限制CPU的使用時間,限制使用的內存,統計CPU的使用情況,凍結和恢復一組進程等。

1.3.1 相互關係

  • 每次在系統中創建新層級時,該系統中的所有任務都是那個層級的默認 cgroup(我們稱之爲 root cgroup,此 cgroup 在創建層級時自動創建,後面在該層級中創建的 cgroup 都是此 cgroup 的後代)的初始成員;
  • 一個子系統最多隻能附加到一個層級;
  • 一個層級可以附加多個子系統;
  • 一個任務可以是多個 cgroup 的成員,但是這些 cgroup 必須在不同的層級;
  • 系統中的進程(任務)創建子進程(任務)時,該子任務自動成爲其父進程所在 cgroup 的成員。然後可根據需要將該子任務移動到不同的 cgroup 中,但開始時它總是繼承其父任務的 cgroup。

        如圖所示,CPU 和 Memory 兩個子系統有自己獨立的層級系統,而又通過 Task Group 取得關聯關係

1.3.2 cgroups子系統

        cgroups 爲每種可以精細化控制的資源定義了一個子系統,典型的子系統如下:

  • cpu 子系統: 主要限制進程cpu的使用率(也可以理解爲限制分配給cpu的core,最終限制是cpu 利用率的限制;比如一共32core 分配4core ,那這個進程cpu 最大佔用率 = 12.5%,所以一個進程可以申請< 1core,因爲最後是轉換成比率來控制的;
  • cpu 子系統,主要限制進程的 cpu 使用率。
  • cpuacct 子系統:統計每個進程cpu 使用率的報告,如果達到預定的上限,可以採取一定的措施;
  • cpuset 子系統:可以爲進程分配單獨的cpu節點或者mem節點,可以理解爲爲進程分配指定的額cpu佔有率,就是精細化控制cpu資源;
  • memery 子系統:可以限制進程memery 最大的使用量;
  • blkio 子系統:可以限制進程訪問的塊設備io;
  • device 子系統:可以控制訪問的設備;
  • net_cls 子系統:標記cgroups 中的網絡數據包,然後可以使用tc模塊(traffice control) 系統對數據包進行控制;比如namespace NET 的可以通過這個系統讓namespace 內進程可以獨立進行網絡通信,功能類似於自己單獨的網卡、單獨的帶寬;
  • net_prio子系統:這個子系統用來設計網絡流量的優先級
  • freezer 子系統,可以stop或者start cgroups 管理的進程,就是監控進程的狀態,如果設置了一直是start狀態,就去確定環境是否是ok,如果ok就啓動服務;
  • ns子系統: 可以控制cgroup的進程訪問不同的namespace;這個配合namespace的功能實現容器的隔離效果;
  • hugetlb子系統:這個子系統主要針對於HugeTLB系統進行限制,這是一個大頁文件系統。

        這裏每一個子系統都需要跟內核的其他模塊配合來完成資源的控制,比如對cpu資源的控制,需要內核的進程調度模塊根據cpu子系統的配置來完成;內存資源的限制需要內核的內存模塊根據memery子系統的配置來完成。

1.3.3 如何查看當前系統支持哪些subsystem

        可以通過查看/proc/cgroups(since Linux 2.6.24)知道當前系統支持哪些subsystem,下面是一個例子:

         從左到右,字段的含義分別是:

  1. subsystem的名字
  2. subsystem所關聯到的cgroup樹的ID,如果多個subsystem關聯到同一顆cgroup樹,那麼他們的這個字段將一樣,比如這裏的cpu和cpuacct就一樣,表示他們綁定到了同一顆樹。如果出現下面的情況,這個字段將爲0:
    • 當前subsystem沒有和任何cgroup樹綁定
    • 當前subsystem已經和cgroup v2的樹綁定
    • 當前subsystem沒有被內核開啓
  1. subsystem所關聯的cgroup樹中進程組的個數,也即樹上節點的個數
  2. 1表示開啓,0表示沒有被開啓(可以通過設置內核的啓動參數“cgroup_disable”來控制subsystem的開啓).

1.4 cgroups提供的功能

  • 限制進程組可以使用的資源(Resource limiting ):比如memory子系統可以爲進程組設定一個memory使用上限,進程組使用的內存達到限額再申請內存,就會出發OOM(out of memory)
  • 進程組的優先級控制(Prioritization ):比如可以使用cpu子系統爲某個進程組分配cpu share
  • 統計進程組使用的資源量(Accounting ):比如使用cpuacct子系統記錄某個進程組使用的cpu時間
  • 進程組隔離(Isolation):比如使用ns子系統可以使不同的進程組使用不同的namespace,以達到隔離的目的,不同的進程組有各自的進程、網絡、文件系統掛載空間
  • 進程組控制(Control):比如使用freezer子系統可以將進程組掛起和恢復

參考鏈接 

徹底搞懂容器技術的基石: cgroup

linux 容器(LXC) 第4章 cgroups_caoshuming_500的博客-CSDN博客

Cgroup原理及使用 - zhrx - 博客園

Linux 基礎:cgroup 原理與實現_CGroup_層級_控制

【docker 底層知識】cgroup 原理分析_張忠琳的博客-CSDN博客_cgroup

CGroup的原理和使用_書笑生的博客-CSDN博客_cgroup原理

Docker核心原理之 Cgroup詳解

Linux Cgroups詳解(二) - lisperl - 博客園

Linux Cgroup系列(04):限制cgroup的內存使用(subsystem之memory)

Linux Cgroup系列(04):限制cgroup的內存使用(subsystem之memory) - SegmentFault 思否

Linux Cgroup系列(01):Cgroup概述

Linux Cgroup系列(01):Cgroup概述 - SegmentFault 思否

深入理解 Linux Cgroup 系列(一):基本概念

深入理解 Linux Cgroup 系列(一):基本概念 - SegmentFault 思否

深入理解 Linux Cgroup 系列(二):玩轉 CPU

深入理解 Linux Cgroup 系列(二):玩轉 CPU - SegmentFault 思否

深入理解 Linux Cgroup 系列(三):內存 - SegmentFault 思否

本文由[mdnice](https://mdnice.com/?platform=6)多平臺發佈
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章