ref: https://blog.devgenius.io/disaster-recovery-on-kubernetes-98c5c78382bb
作者認為即使那些知名的託管K8s服務(AKS/EKS/GKE)本身有提供各種機制來強化系統的存取性,但是作為一個正式生產環境的 Kubernetes 勢必還是要有一套災難復原的機制,因為有些災難並不是底層架構導致,有可能是人員的操作錯誤導致叢集內發生問題(譬如刪除整個 namespace).
隨者愈來愈多的團隊會將跨地區當作解決方案的一個考量時,要如何能夠找到一個簡單的備份還原機制來面對 Kubernetes 則是一個複雜的問題。 而本篇文章將會探討如何使用 Velero 來針對 Kubernetes 叢集進行備份,還原甚至是災難復原等操作,透過這類型的機制實際上也可以做到遷移 Kubernetes 叢集。
文章開頭作者提出了一個很值得注意的論點,就是高可用性(HA)的環境並不代表該環境擁有備份與還原機制。
HA 用來確保單一底層架構出現問題時整體服務不受影響,還是有能夠繼續存取既有的服務。但是假如遇到資料損毀或是其他意外刪除的,HA 的機制並沒有辦法讓這些服務可以復原。
所以就算系統是運行到 HA 的環境下,對於備份相關的解決方案還是需要準備,而且最重要的是這類型的解決方案不能只有準備,而是需要真的練習,嘗試復原,確保團隊熟悉整個還原的步驟,否則當問題發生時有可能會變成不知道要如何從備份資料來進行有效還原。
文章後半部分探討關於 Velero 的架構與使用,同時也列舉其他相關的專案,如
kube-backup
Cohesity
Kasten 10
Portworx PX-Backup]
Rancher Longhorn
對於 Kubernetes 備份還不熟悉或是團隊尚未導入的讀者可以嘗試使用看看 Velero
「k8s namespace」的推薦目錄:
- 關於k8s namespace 在 矽谷牛的耕田筆記 Facebook 的最佳貼文
- 關於k8s namespace 在 矽谷牛的耕田筆記 Facebook 的最佳解答
- 關於k8s namespace 在 矽谷牛的耕田筆記 Facebook 的最佳解答
- 關於k8s namespace 在 Hierarchical Namespace Controller (HNC) - GitHub 的評價
- 關於k8s namespace 在 [Kubernetes] 如何管理Resource Object | 小信豬的原始部落 的評價
- 關於k8s namespace 在 Namespaces in Kubernetes - YouTube 的評價
- 關於k8s namespace 在 How many namespace can a cluster k8s hold? - Stack Overflow 的評價
k8s namespace 在 矽谷牛的耕田筆記 Facebook 的最佳解答
本篇文章是一個經驗分享文,作者探討使用 Rancher 遇到的問題,以及最後是如何使用 Kubecost 來解決成本使用的分析問題。
作者認為 Rancher 對自己公司的 DevOps Team 來說是個非常好用的工具,透過 Rancher 的視覺化工具,任何人都可以清楚的去管理以及檢視當前 K8s 叢集內的各種資訊,對於任何加入團隊還不熟悉 Kubernetes 的開發者來說,Rancher 的特色讓這些新開發者容易上手,熟悉概念後再轉往理解 kubectl 等工具的使用。
不過作者公司團隊遇到的問題是 Kubernetes 內不同專案彼此的成本用量難以計算,雖然 Rancher 內有再提供一個 Project 的抽象介面,可以控管 Project 底下的 CPU/Memory 以及相關物件的分配。
但是這樣還是有三個問題沒有辦法解決
1. 無法有效且快速的知道每個 namsepace 底下於 Node 上所佔的資源比例
2. 當一個 Team 本身會使用到多個 namespace 時上述的計算會變得更加麻煩。
3. 團隊看透過 kubectl top 去計算,或是使用 Prometheus/Grafana 來整合計算,但是實際上還是一個困難的麻煩事
作者最後從 Rancher 的線上研討會中,聽到了 Kubecost 有趣的專案,該專案可以順利的與 Rancher 整合,基於 Rancher Project 作為基本分類,來檢視每個 Project 底下各種資源的使用量,同時搭配金額的分配還可以把使用量轉換成實際的金額,團隊更有能力去估算使用量。
有興趣的可以閱讀全文並且嘗試看看 kubecost 這個工具
https://itnext.io/kubecost-rancher-saved-df30fe77135b
k8s namespace 在 矽谷牛的耕田筆記 Facebook 的最佳解答
本文是一篇 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
k8s namespace 在 [Kubernetes] 如何管理Resource Object | 小信豬的原始部落 的推薦與評價
而若是要在同一個namespace 為不同的resource 進行分門別類,則可搭配Label 來完成。 檢視cluster 中的namespace. 此外,namespace 其實也是K8s ... ... <看更多>
k8s namespace 在 Namespaces in Kubernetes - YouTube 的推薦與評價
Share a Cluster with Namespaces → https://goo.gle/2SZfABKWorking with ... your namespace will see your ... ... <看更多>
k8s namespace 在 Hierarchical Namespace Controller (HNC) - GitHub 的推薦與評價
Home of the Hierarchical Namespace Controller (HNC). Adds hierarchical policies and delegated creation to Kubernetes namespaces for improved in-cluster ... ... <看更多>