上次 Meetup 的影片出爐囉，這次影片的主題是關於 GitOps 的介紹，從 GitOps 的來由，觀念到用兩個開源專案進行 Demo, 讓大家瞭解看看 GitOps 跟平常使用的 CD 部署方式有什麼不同
除了影片之外，下方還有投影片及相關入門文章
https://www.youtube.com/watch?v=1n2JsOIiHP8
相關投影片: https://www.slideshare.net/hongweiqiu/introduction-to-gitops
相關文章: https://www.hwchiu.com/gitops.html

九月份的線上活動來囉

這次的活動主要是跟大家探討一下關於 Container 的設計，到底 Dockerd 與 Containerd 的差異是什麼
知名熱門的 CRI-O 與 Podman 這些與 Docker 又有什麼不同
Kubernetes 所制定的 CRI 有什麼功用以及最後 Kubernetes 中我們要如果不用 Docker, 那應該選擇哪一套 Container solution?

歡迎有興趣的朋友可以參加該線上活動，活動連結會在活動前幾天公布

日期: 2020/09/26
時間: 21:00 (UTC+8)

https://www.facebook.com/events/4383015405104982/

我認為非常好用的專案，可以一眼看出目前運行應用所消耗的資源
對於規劃 Resource Limit 來說是個滿好的開始，畢竟要先瞭解自己的服務會用到多少資源，也才會有一個底去思考到底你的 soft/hard limit 要設定多少

https://github.com/davidB/kubectl-view-allocations

之前撰寫過關於 Kubernetes 的科普文，主要是用來探討 Kubernetes 能夠做什麼，以及不能夠做什麼

該篇文章現在有朋友翻譯成英文版本
https://medium.com/teamzerolabs/do-you-really-know-kubernetes-d936a093bbcc

一年一度的 ITHOME 鐵人 30天寫作大賽準備開始了!

去年首次參賽主要介紹 Kubernetes 的底層實作，而今年則打算介紹 CI/CD 與 Kubernetes 的一切整合與使用方式

鐵人賽的文章目前都收集於此，未來的章節也會記錄在這邊，詳細的內容也可以參閱部落格或是 ITHOME 網頁

https://ithome.hwchiu.com

https://k8syaml.com/

Yaml工程師即將失業? 還好對方資源的 Resource Type 不夠多 :)

Kubernetes 支援多副本資源運行，特別是當這些資源是透過 Deployment/ReplicaSet 產生時，名稱中間都會包含者不易閱讀的字串。這種情況下要如何快速且方便的讀取多副本 logs?

除了使用原生 kubectl 加上 --all-containers=true 參數來處理外
這邊跟大家分享其他開源工具，分別是 kail , stern,  k8stail 以及 kubetail

有任何使用經驗跟心得都歡迎分享!
https://github.com/wercker/stern
https://github.com/boz/kail
https://github.com/dtan4/k8stail
https://github.com/johanhaleby/kubetail

#小編

各位使用 Kubernetes 是怎麼部署Database的呢？

參考四步驟部署 Database 輕鬆上 Kubernetes

https://twitter.com/memenetes/status/1303075743774248960?s=21

#小編

Kubernetes 小品, 週五下班時間輕鬆一下，改編自帝國毀滅元首的憤怒之經典橋段【船長的憤怒】😂

裡面的埋了各種 Kubernetes 相關專案的梗，身為苦命 DevOps/SRE 的你看懂了幾個呢?

https://www.youtube.com/watch?v=9wvEwPLcLcA

摘自 Wiki 元首的憤怒：元首地堡內躲藏的希特勒最後孤注一擲的作戰失敗後，與戈培爾一家在最後時刻自殺。

這次跟大家分享一個有趣的反面議題，探討 GitOps 部署策略所帶來的痛點與負荷，本文主要內容翻譯自 Container-Solutions 的原始文章，已獲得原作者同意

原作者列出了數個實際採用 GitOps 遇到的麻煩與痛點，並講述期望的解決方案，最後則提供了一些不同的開源軟體來讓大家去嘗試

如同我不停強調的就是沒有最好的解決方案，只有最適合你環境的解決方案，我們要培養的一直都是如何分析自己的情境，找到對的工具並整合，一昧的追求最新最潮流的東西往往不會是最穩定且最有用的。

有興趣的人可以點選本文內的連結來瞭解更多原作者的思考 https://www.hwchiu.com/gitops-bad-and-ugly.html

CNCF 使用者社群 (CNCF End User Technology Radar) 今天針對可觀測性這個議題發布了九月份的報告，
是針對幾個常見的技術分析投票結果，看看不同的產業公司對於這些軟體是什麼樣的態度
主要分成已經 Adopt, Trial, Assess 三個不同的等級來幫每個專案/產品評論

如果你目前正在觀望各種工具，快來看看大家怎麼說

重點整理
1. 最常被使用的工具都是開源專案
2. 目前沒有一個一統天下的工具，大部分使用者都是會用多項工具一起
3. Prometheus 與 Grafana 通常會一起使用
https://radar.cncf.io/2020-09-observability

跟大家分享一個由 CNCF 組織所發起的 CD 工具調查報告
面向的使用者都是 CNCF 社群的廠商，主要針對各種廣為人知的 CD 工具給予評價，大致上就是推不推薦使用

在 Kubernetes 應用程式部署工具方面, Helm > Kustomize > Jsonnet
至於對於 CD 系統的選擇各有秋色，不論是開源軟體或是 SaaS 服務都有上榜
其中正反意見最多，完全看不出共識的就是我們的老牌 Jenkins, 將近一半的受訪者都推薦停止使用 Jenkins.

有更多興趣可以點選下列文章來閱讀，有興趣也可以到粉絲團留言討論
https://www.hwchiu.com/cncf-tech-radar-cd.html

YAML Templating 工具生態現況

不知道大家是否都有使用 Network Policy 來設定 Kubernetes 內部的 ACL?

這邊有個叫做 OPA 的工具可以用幫你驗證你的 Network Policy 是否運作良好，甚至當有新的應用服務要部署的時候，也會確定是否有跟 Network Policy 衝突
有興趣的人可以研究看看

https://www.cncf.io/blog/2020/09/09/how-to-enforce-kubernetes-network-security-policies-using-opa/

#小編 #深夜讀物

一篇關於 Service Mesh 的好文，發布已經有段時間了不過還是值得一讀， 文章作者是非常早期 Service Mesh 項目: Linkerd 的核心開發成員之一也是新創公司 Buoyant 公司的 CEO。
相信大家應該對於 Service Mesh 一詞已經不陌生，可能對於這個名詞比較熟悉的朋友大多是從另一個 Service Mesh 項目: Istio 去了解 Service Mesh 的面貌，從這篇文章你可以從不同觀點認識 Service Mesh ，全文非常長內容涵蓋
• Service Mesh 詳盡介紹
• 為什麼 Service Mesh 可以被施行？
• 為什麼 Service Mesh 是個好的 idea (比起其他方法)？
• Service Mesh 幫助了什麼？
• Service Mesh 有解決掉所有問題嗎？
• 為什麼在現今 Service Mesh 可以被施行？
• 為什麼人們那麼愛談論 Service Mesh？
• 身為一個謙虛的開發者需要關注 Service Mesh 嗎?
• 一系列F&Q

這裡對 Service Mesh 的需求做個小結，Service Mesh 帶來了三大好處：
1. Reliability: 包含提供請求重試、超時、金絲雀部署(Traffic shifting/splitting) 等功能
2. Observability: 包含提供請求成功率、延時、粒度到個別服務等級的請求量、個別服務等級路由、服務等級拓墣圖等功能
3. Security: ACL 及 Mutual TLS (客戶端及服務端互信）

值得一提的是，本篇作者 William Morgan 對於 istio 持負面的態度，並不是因為 istio 與 linkerd 處於競爭關係的兩個產品，而是對於 istio 在 service mesh 做了太多的商業性 marketing 操作（大部分來自Google的操作)

文章來源: https://servicemesh.io/

有興趣的朋友也可以在 Podcast 上聽到作者在 Podcast 上的訪談: https://reurl.cc/N6GbW9

從 Gitlab 出發探討 GitOps 的概念，有興趣的可以閱讀這篇由 Cheng Wei Chen 於 ITHOME Cloud Edge Summit 2020 的精彩分享

https://blog.chengweichen.com/2020/09/from-devops-to-gitops-with-gitlab.html?fbclid=IwAR3gJJZ_J3hsX7rOJ6MYcIOoDuqwuz2J3xLJxANnvIsvkhra02UfzktjC9Q

七個邁向 Cloud Native 的挑戰!!

本篇文章列出了七個企業想要踏入 Cloud Native 之路上最常遇到的問題
以下幫大家總結並節錄一點小內文
1. 過於緩慢的發布週期
創新需要有能力很快速地針對每次的修改去快速發布。

2. 使用過時的技術
作者認為時時關注當前這個迅速發展的世界是非常重要的，特別是的相關開源專案。

3. 綁定特定服務供應商且成長方面缺乏彈性
當服務與特定廠商的解決方案綁定太深時，很容易遇到所有功能都由該廠商綁定，想要做什麼都會綁手綁腳。

4. 缺乏專業性人才
根據 2019 一篇調查，只有 7% 的 IT 主管再招聘與慰留人才方面沒有遇到困難

5. 安全性
人們總是當問題發生的時候才會開始注意安全性的問題，但是往往這些問題的代價都很高。儘管安全防護是一個複雜且困難的領域，但是擁有一個資安的實踐守則還是非常重要。

6. 過高的運營與技術成本
滿多企業都會使用雲端服務來減少自行維護伺服器所需的成本，然而 Cloud Native 的環境常常會用到各式各樣的元件，這些元件所消耗的成本都會隨者規模放大而有所影響，如何去最佳化你的雲端資源使用量來盡可能的減少你的花費也是一大挑戰

7. Cloud Native 的概念難以溝通
Cloud Native 的觀念難以溝通與理解，對於任何想要導入 Cloud Native 到團隊中的企業來說，領導團隊必須要先理解到底這些解決方案的重要性與複雜性。
甚至可能還會因為微服務，容器等其他概念的認知不同而花時間理解。


https://www.cncf.io/blog/2020/09/15/top-7-challenges-to-becoming-cloud-native/