本文是一篇 2017 年的文章，雖然已經四年之久，但是我認為本篇文章值得一讀。
作者團隊於 2017 年時正在經歷如何將 VM 上的各種 Java 應用程式轉移到 Kubernetes 內的 Container，而本篇文章則是探討到底 Container 是如何透過 Linux Control Group 以及 namespace 實作的，透過對這些底層實作的瞭解，才有辦法針對 Container 效能部分去除錯與提升。
這種文章探討的都是很底層的概念，建議所有人都閱讀一遍，好好複習關於 cgroups/namespace 的概念，透過對這些概念的理解與掌握，能夠更有系統的去解釋何謂Docker Container，何謂輕量級虛擬化。
以下幫大家節錄一些重點，還是推薦自行閱讀全文
1. cgroup 用來隔離與限制 CPU,Memory,Disk,Network Bandwidth 等資源的用量
2. namespace 則是用來限制 ipc, pid, mount ,network, utc 等資訊的可視性，不同 namespace 內看到的資訊是獨立的，但是最終彼此還是屬於同一個 Kernel。
3. 任何沒有被 cgroup 規範的應用程式都會被自動包含到 root cgroup 的規範，不同發行版其位置不同，譬如 /sys/fs/cgropu.
假設今天透過 docker run 去運行一個 java 應用程式
a. Docker 會創建一個 pid namespace，接者運行 Java 前先把該應用程式給掛到新的 pid namespace 上並且賦予該 java 應用程式 PID 1
註: Host 上還是可以觀察到該 Java 應用程式，因為除了 Host 本身外，每個 pid namespace 都有自己的老爸，而老爸是可以看到小孩資訊的，這意味 docker dameon 雖然創建新的 pid namespace，但是host的pid namespace 實際是新 namespace 的老爸
b. 從老爸的視角來看，可以看到該 Java 應用程式也會有一個不同的 PID，而這個 PID 也會於 cgroup 系統中有自己的設定
4. CPU Cgroup 則是會用 share 為單位來定義每個 task 可以獲得多少相對的 CPU 時間，相對的算法是去計算 task 擁有的 share 數量佔了整個 cgroup 階層元件中的多少百分比。
舉例: 捨去其他服務單純考慮運行三個 Container 且有 4 Core CPU 的環境，三個 Container Task 分別給予 2048,1024,1024 share 的話，第一個 Container 大致是會被分配到兩個 CPU Time
5. CPU shares 沒有辦法去保證每個 task 最小用量是多少，所以需要透過 CPU Quotas 的概念來設定 CPU.cfs_quota_us(假設使用 CFS 這個排成演算法)以及 CPU.cfs_period_us(預設100ms)。
概念大概就是 cfs_period_us 定義的時間內，你最小可以使用多少時間，所以假如設定 cfs_quota_us 為 100ms，則預設情況下該 process 可以使用的量就是 100ms/100ms = 1 ~= 1 Core CPU
k8s 與上述的相關bug 可參考下列 issue
https://github.com/kubernetes/kubernetes/issues/67577
6. JVM 看到的是系統上全部的 CPU 資源，但是 Contaienr 本身當被限制 CPU 用量時，會有資訊落差，造成 GC 運行的效果不如預期，因為其認為系統有超多 CPU，而不知道自己其實被限制的CPU很少。
原文滿精彩的，推薦閱讀
https://engineering.squarespace.com/blog/2017/understanding-linux-container-scheduling
java gc 在 在Java 中啟用詳細的gc 日誌記錄 - 他山教程 的推薦與評價
通常，jvm 的垃圾收集（gc）對使用者（開發人員/工程師）是透明的。 ... package com.example.so.docs.gc.logging; import java.util. ... <看更多>