0%

[閱讀筆記] - Week 2

七個邁向 Cloud Native 的挑戰!!

Ref: https://www.facebook.com/technologynoteniu/posts/125741595926648

本篇文章列出了七個企業想要踏入 Cloud Native 之路上最常遇到的問題
以下幫大家總結並節錄一點小內文

  1. 過於緩慢的發布週期
    創新需要有能力很快速地針對每次的修改去快速發布。
  2. 使用過時的技術
    作者認為時時關注當前這個迅速發展的世界是非常重要的,特別是的相關開源專案。
  3. 綁定特定服務供應商且成長方面缺乏彈性
    當服務與特定廠商的解決方案綁定太深時,很容易遇到所有功能都由該廠商綁定,想要做什麼都會綁手綁腳。
  4. 缺乏專業性人才
    根據 2019 一篇調查,只有 7% 的 IT 主管再招聘與慰留人才方面沒有遇到困難
  5. 安全性
    人們總是當問題發生的時候才會開始注意安全性的問題,但是往往這些問題的代價都很高。儘管安全防護是一個複雜且困難的領域,但是擁有一個資安的實踐守則還是非常重要。
  6. 過高的運營與技術成本
    滿多企業都會使用雲端服務來減少自行維護伺服器所需的成本,然而 Cloud Native 的環境常常會用到各式各樣的元件,這些元件所消耗的成本都會隨者規模放大而有所影響,如何去最佳化你的雲端資源使用量來盡可能的減少你的花費也是一大挑戰
  7. Cloud Native 的概念難以溝通
    Cloud Native 的觀念難以溝通與理解,對於任何想要導入 Cloud Native 到團隊中的企業來說,領導團隊必須要先理解到底這些解決方案的重要性與複雜性。
    甚至可能還會因為微服務,容器等其他概念的認知不同而花時間理解。

Contaienr 底層實作與 CVE 介紹

Ref: https://teamt5.org/tw/posts/container-escape-101/

這篇分享一篇非常有趣的問題,從 Container 的實作開始介紹,最後介紹幾個與 Container 相關的 CVE
對於資安有興趣的可以研究看看

Kubernetes CNI 效能比較

Ref: https://www.hwchiu.com/cni-performance-2020.html

  1. Kube-OVN 不但資源吃很多,效能還很不好
  2. Canal/Calico/Flannel 三者的運算資源使用量都不多,且效能都很好
  3. Kube-Router 的效能都很差,資源使用方便也不是特別出色
  4. WeaveNet 與 Cilium 效能都不差,但是 Cilium 吃的效能很高,可說跟 Kube-OVN 同等級,而 WeaveNet 用到的資源少
  5. 這次的實驗評比我認為其實能看到的東西有限,主要是不同的 CNI 所搭配的解決方案不同,目標要配合的情境也不同,雖然從圖表中可以看到 Kube-OVN 的綜合評比最差,但是其要用的場景本>身就不太一樣,單純用最原始的流量互打來判別優劣其實不太對
  6. 如果今天要選擇網路 CNI 的時候,可以看到效能跟資源方面, Flannel/Calico/Canal 幾乎等級都差不多,而且 Calico 還支援加密與 Network Policy 等功能。
  7. 此外,目前 Flannel 也從 Kubeadm 的官方教學頁面中移除,因為太多問題且維護者沒有要修復。所以我認為如果沒有特別使用情境需求的話,可以考慮使用 Calico.
  8. Cilium 對於安全性以及 load-balancing 方面也有別的功能,就如同(5)點所提到,不同的場景有不同的需求,有些功能是獨占的。

CI/CD 部署策略比較

Ref: https://thenewstack.io/deployment-strategies/

這邊跟大家分享一個有趣的入門文章,介紹各種不同部署方式的差異,譬如Ramped, A/B, Green/Blue, Shadow, Canary 等等
每個更新方式帶來的效果不同,同時需要的環境建置也不同,這部分還會影響到整體的預算成本,最後還有一張簡易的表來快速介紹其差異性,有興趣的可以看看

CPU Limit 造成的效能低落

Ref: https://l.facebook.com/l.php?u=https%3A%2F%2Ferickhun.com%2Fposts%2Fkubernetes-faster-services-no-cpu-limits%2F%3Ffbclid%3DIwAR14o68De2Dn_klR54oxkz86qGrIHarTWOiBUW_igRP51LL84DeCl0-xNVw&h=AT2XwJxAJPaUSIP8IjBI0WfG5w-To3TbEq8QyNeQ_0esqg3Glgy1AhPWw1ZeaTiW8l_Vyhw_KjLssJH0fzrrCslweuOIZ4FsQASVjAPtDcpmPreBm5Lr0mSL9gCODO3jl4e86TdNFw&__tn__=-UK-R&c[0]=AT1RVdlTV9uw1_I0_id8krTGh54VBwBsXbzD4yYuvtP9EdueQSrAV0MYFpD4I-3OH7klI3ZdwjzA8rAGwjHjPc8JxLByGWBY083XIwV3NXzYHfDqfk4cWv1SRfSvMtDpAbckEfZ_iljWNFkIyRuSz6YEneirvn-UV-I8U-bKh16XIUWg-4e5jR29b3yc4g

想必大家一定都有使用過 CPU Limit 的經驗,透過這個機制能夠確保每個 Container 使用的 CPU 資源量,也可以保證每個節點上面會有足夠 CPU 供 Kubernetes 原生服務 (kubelet) 使用。
然而本篇文章就要來跟大家分享一個設定 CPU Limit 反而造成效能更差的故事,故事中當 CPU 設定為 800ms 的時候,卻發現實際運行的 Container 最高大概就只有 200ms 左右,這一切的一切都是因為 Liniux Kernel 的臭蟲導致!
一個直接的做法就是針對那些本來就沒有過高 CPU 使用量服務取消其 CPU Limit,作者於文章中也探討了一些機制要如何保護與應對這些被移除 CPU 限制的服務。
這個臭蟲於 Linux Kernel 4.19 後已經修復,但是要注意你使用的發行版本是否有有包含這個修復,作者列出一些已知的發行版本修復狀況
Debian: The latest version buster has the fix, it looks quite recent (august 2020). Some previous version might have get patched.
Ubuntu: The latest version Ubuntu Focal Fosa 20.04 has the fix.
EKS has the fix since December 2019, Upgrade your AMI if necessary.
kops: Since June 2020, kops 1.18+ will start using Ubuntu 20.04 as the default host image.
GKE: THe kernel fix was merged in January 2020. But it does looks like throttling are still happening.

個人資訊

我目前於 Hiskio 平台上面有開設 Kubernetes 相關課程,歡迎有興趣的人參考並分享,裡面有我從底層到實戰中對於 Kubernetes 的各種想法

詳細可以參閱
線上課程詳細資訊: https://course.hwchiu.com/

另外,歡迎按讚加入我個人的粉絲專頁,裡面會定期分享各式各樣的文章,有的是翻譯文章,也有部分是原創文章,主要會聚焦於 CNCF 領域
https://www.facebook.com/technologynoteniu

如果有使用 Telegram 的也可以訂閱下列頻道來,裡面我會定期推播通知各類文章
https://t.me/technologynote

你的捐款將給予我文章成長的動力

Welcome to my other publishing channels