這是一篇幻想文，幻想如果你可以重新設計 Kubernetes，你會希望有什麼樣的改動。也因為是幻想文，所以以下所提的東西不一定真的可以實作，也沒有考慮實作上可能會有什麼困難。原文非常的長，所以這邊就稍微列出一些內容

# 前提
作者(David Anderson, MetalLB 的主要貢獻者)認為 Kubernetes 真的很複雜，從 MetalLB 的開發經驗來看，幾乎無法開發出一個永遠不會壞且與 k8s 整合的軟體。
k8s 發展快速，一些不相容的修改也很難除錯，往往導致這些整合應用程式一起壞掉。
此外，作者使用 GKE 的經驗讓他覺得就算是這些k8s專家，也很難大規模環境中平安順利的使用 k8s.

作者認為 k8s 就像是管理平台內的 c++，功能非常強大，什麼都可以做，但是它會一直傷害你，直到你奉獻餘生該領域內。
作者期盼有一天，可以出現一個像是 go 語言的管理平台，簡單，優雅，容易學習

接下來就來看一下如果時光倒流，作者會希望 k8s 有哪些功能

# Mutalbe Pod
不像其他的資源一樣， Pod 這個資源基本上是不能修改的，有任何的更動都需要先刪除，後重新部署這樣兩步走來處理。
作者希望可以有一種 Pod 是可以支援即時修改的。
舉例來說，我透過 kubectl edit 修改了 Pod Image，然後只要透過 SIGTERM 送給 Runc 底層容器，然後當該 Container 被重啟，就會使用新的設定。這一切的發生都在同一個 Pod 的資源內，而不是重新產生一個新的 Pod

# Version control all the things
當 Pod 可以修正後，下一個作者想要的功能就是基於 Pod 本身的 Rollback。這意味希望叢集內可以有這些資訊可以去紀錄每次的變化

為了實現這個功能，可能每個節點上面也要去紀錄過往的所有 image 版本資訊，並且加上 GC 等概念來清除過期或是太舊的內容


# Replace Deployment with PinnedDeployment
相對於 Deployment， PinnedDeployment 最大的改動就是一個 Deployment 內可以同時維護兩個版本的 Pod。

舉例來說，我今天要將 Nginx 從 1.16 升級到 1.17，我可以透過 PinnedDeployment 去部署 Nginx，其中 1.16 佔了 60% ，而新版本 1.17 佔了 40%。

當一切轉移都沒有問題後，可以逐漸地將新版本的比例遷移到 100% 來達成真正的移轉。
原生的 Deployment 要達到這個功能就要創建兩個 Deployment 的物件來達到這個需求。

# IPv6 only, mostly
作者期望能的話，想要把 k8s networking 內的東西全部移除，什麼 overlay network, serivce, CNI, kube-proxy 通通移除掉。

k8s 全面配置 IPv6，而且也只有 IPv6，通常來說你的 LAN 都會有 /64 這麼多的地址可以分配 IPv6，這個數量多到你根本不可能用完 (2^64)。
也因為都有 public IPv6 的緣故，所有的存取都採用 Routing 的方式，封裝之類的玩法也不需要了。

文章內還提了很多東西，譬如說如果今天真的需要導入 IPv4 於這個純 IPv6 的系統上，可以怎麼做，如何設計 NAT64 等，算是非常有趣的想法

# Security is yes
作者認為安全性方面要最大強化，預設情況下要開啟 AppArmor, seccomp profile 等控管機制，同時也要全面禁止用 Root 來運行容器， 基本上就是用非常嚴格的方式來設定安全性方面的規則。

目前 Kubernetes 內的資源， Pod Security Policy 非常類似作者想要完成的東西，通過這種機制確保所有部署的 Pod 都會符合這些條件。唯一美中不足的是 Pod Security Policy 也不是預設就有的規則。

# gVisor? Firecracker?
從安全性考量出發，是否預設改使用 gVisor 或是 Firecracker 這類型的 OCI Runtime 而非 Runc，同時搭配上述的各種安全性條件來打造非常嚴苛的運行環境

# VMs as primitives
是否可以讓 kubernetes 同時管理 container 以及 virtual machine，也許就會像是將 kubevirt 變成一個內建的功能，讓 kubernetes 更加靈活的使用


除了上面之外，文章內還有許多其他的想法，但是內容都滿長的，如果有興趣的可以點選下列連結參考看看

https://blog.dave.tf/post/new-kubernetes/

Service Mesh 這幾年的話題沒有停過，不論是 Linkerd, istio 或是其他解決方案都有各自的支持者。今天這篇文章是 Linkerd 官方文章，來跟大家解釋說明為什麼 Linkerd 沒有像其他解決方案一樣直接採用 Enovy 做為底層 proxy，而是要自行開發一個名為 Linkerd2-proxy 的取代方案

# 前提
1. Linkerd 是一個由工程團隊打造給工程團隊使用的產品，所有的決定都是基於工程方面的考量，而不是市場壓力
2. Envoy 很棒，但是對於 Linkerd 來說並沒有辦法透過 Envoy 打造一個簡單，輕量且安全的 Service Mesh 解決方案
3. 透過重新打造 Linkerd2-proxy，針對自己的需求重新設計才有機會讓 Linkerd 變得簡單且好用

# 想法
1. Linkerd2-proxy 是一個完全不考慮使用者面向的 Proxy 實作，跟 Envoy, Nginx 以及 Apache 這類型的實作是完全不同考慮。 Linkerd2-proxy 就是一個專門給 Linkerd 內部使用的
2. Envoy 超級彈性，同時是一個多用途的 Proxy，這種框架導致 Envoy 非常熱門，但帶來的就是其底層複雜。對於 Linked 來說需要的功能沒有這麼多。簡單來說就是殺雞焉用牛刀
3. 根據 Linkerd 內部的效能壓測，於 4,000 RPS(Request Per Second) 的前提下， Istio's Envoy 使用的 CPU 量相對於 Linkerd2-proxy 是 50% ~ 1000% 的增長，而 Memory 則是 1000%
4. Linkerd2-proxy 採用 Rust 開發，相對於 C++ 來說再安全性方面的開發會比較輕鬆一點，這個並不代表 Envoy 不安全，因為 Enovy 的社群龐大，CVE跟 bug 的修復也是很快。

# 其他
1. 相對於重新開發一個類似 Linkerd2-proxy 的專案，直接使用 Envoy 做為底層的 proxy 是非常簡單且省時的。並不是所有的 Service Mesh 解決方案都有足夠的能力與時間去開發屬於自己的 Proxy，因此整合 Enovy 並非錯誤
2. 目前使用 Linkerd 解決方案的使用者，其底層都是使用 Linkerd2-proxy
3. 其他的 Service Mesh 並不太能直接改採用 Linkerd2-proxy，畢竟其本身的設計就不是一個市場與使用者面向的專案。作者建議可以考慮使用 Rust 的 network library 來打造一個自己的方案

這篇文章並不是教你如何使用 Service Mesh，反而是分享更多一些設計上的哲學思考，個人覺得非常有趣，有興趣的可以點選下列連結觀看全文
https://linkerd.io/2020/12/03/why-linkerd-doesnt-use-envoy/

今天這篇文章是一個介紹文，跟大家分享 Kubernetes 內的一個有趣玩法，Service Catalog。

探討 Service Catalog 之前，我們先來看看 Kubernetes 的一個使用情境。今天我們團隊需要一個 SQL 的 database，請問我需要將該服務放到 Kubernetes 去維護還是直接使用 Cloud Provider 所維護的? 考量到如果 DB 需要有 HA, SLA 等要求，花錢使用 Cloud Provider 就會簡單，如果想要全部自己處理，其實這方面並不簡單，畢竟每種 DB 的架構都不同，要搭建出 HA， Active/Active, Active/Passive 的方式也都不同，當然這選擇都取決於團隊。

假設今天想要使用的是 Cloud Proivder 提供的 DB 服務(PaaS)，那下一個問題就是，我要怎麼管理這些資源?

一個直覺的想法就是我可以使用 Terraform 來管理，但是如果你有一種慾望，想要使用 YAML 一統世界的概念，甚至全部都整合到 Helm/Kustomize 來管理，這方面有沒有機會？

如果有，你可以花點時間研究看看 Service Catalog 的生態，Kubernetes 透過 Service Catalog 的整合，讓你有能力透過 Yaml 的方式去創建這些由 Cloud Provider 所維護的資源。

Service Catalog 基本上也是仰賴各家 provider 是否有實現 Open Service Broker API，有的話，就可以於 Kubernetes 內先部署一些相關資源，將你的 Kubernetes 與 Cloud 連動，接者透過這些 API 來創建相關資源

該文章主要是展示如何透過 Kubernetes + Service Catalog 來創建 Azure Database，有興趣的請點選下列連結來觀賞全文

https://medium.com/@HoussemDellai/introduction-to-kubernetes-service-catalog-37317b15670

如果你跟我一樣，是 kubectl 愛好者，對於其他操作介面譬如 k9s 等都不習慣的人，那我認為一定要來瞭解一下 kubectl plugin 的用法

1. kubectl plugin 本身的設計使得大家非常容易的擴充，並不需要修改 kubectl 的任何原始碼或是重新編譯。相反的只需要準備相關的執行檔案，並且依據特定規則命名即可
2. krew 是一套管理 kubectl plugin 的套件，能夠幫你整理目前官方收集的 plugin 並且提供指令讓你去安裝與刪除
3. 本文列出了幾個作者認為好用的指令，譬如 whoami，可以讓你知道你當前透過 KUBECONFIG 連接到遠方 cluster 時是以什麼樣的身份被認證
4. access-matrix 幫你列出目前系統中 RBAC 的相關權限，用一個比較易閱讀的方式呈現
5. neat 是一個清除工具，可以幫忙將 kubectl get pods xxx -o yaml 中那些由 controller 所添加的資源給移除，讓你得到一個乾淨的輸出
6. node-shell 是個非常好用的工具，可以幫你掛載一個 shell 到任意的 k8s node 之中，讓你透過該 shell 來操作該節點

除了這些之外，我認為 ksniff 也是個滿有趣的工具，可以幫忙運行 tcpdump 來錄製封包

如果有興趣的可以直接到 krew 的官方文件去看看目前收錄的 plugin 有哪些，然後可以都玩看看來找到一些對自己工作有幫助的指令

https://www.padok.fr/en/blog/kubectl-plugins

今天這篇是一個 Operator 的介紹文，該文分成三大部分，分別是 What, Why 以及 How

如果你本身對於 Operator 的概念還不是很熟悉的，會非常推薦閱讀這篇文章，幫助你從頭瞭解到底什麼是 Operator，其背後的實作原理以及我們可以透過 Opeator 做什麼事情，對於維運團隊能夠帶來什麼好處

# What
1. Operator 這個詞是由 CoreOS 工程師於 2016 提出的，目的是希望簡化應用程式的管理，特別是 Stateful 類型的
2. Operator 背後是一個 Controller，該 Controller 會根據當前應用程式的狀態而自動地進行一系列的處理，譬如創建，刪除，管理等各式各樣資源，當然這些操作都是基於 Kubernetes API 完成
3. 根據目前官方 (kubernetes.io) 的說明，要理解 Operator 就會需要理解兩個概念，分別是 CRD (Custom Resource Definition) 以及 Control-Loop
4. CRD 提供一個方式讓開發者能夠定義屬於自己的 resource，包含了 apiversion, kind 等欄位。舉例來說，你可以自己定義一個跟 Pod 幾乎完全一樣的資源，然後擴充或是減少一些欄位

# Why
1. Kubernetes 內建的機制與資源對於是非常適合於無狀態應用程式(Stateless)的，這些資源足夠滿足無狀態應用程式的需求，譬如自動擴展數量，提供流量的負載平衡
2. 但是當 Kubernetes 的應用場景愈來愈多， Stateful 應用程式的需求就出現了，這時候原生的機制就稍嫌不足，使用起來不夠順暢。
3. 透過 Operator 的概念 (CRD + Control-Loop)，使用 CRD 來定義你的資源狀態，並且透過 Controller 來幫你維護你的運作邏輯，譬如什麼時候該產生/刪除 Pod，什麼時候該創立/刪除其他資源，這些邏輯的實現都隱藏到 Controller 之中，但是同時也透過 CRD 提供一些介面參數讓開發者與維運者有能力對其進行一些調整

# How
1. 如何撰寫一個 Operator，有一些現成的工具可以幫忙，譬如 Kudo, Operator SDK, Kubebuilder 等
2. 有興趣觀看這些工具的介紹與使用，可以看全文

# Operator 的必要性

1. 2020 北美 Kubecon 上有非常多關於 Operator 的討論，作者特別提出由 HashiCorp 所分享的議程 Stop Writing Operators ，並且針對幾點來討論
2. 如果你的自動化是一個每個月執行10分鐘這種工作，那花上數週來維護與撰寫這種自動化其實非常不值得
3. 實際上開發一個 Operator 會遇到滿多問題，即使你使用 Kubebuilder 等這類型工具也還是會有很多小問題
4. 如果能的話，作者覺得有時候寫一些醜陋的 shell script 會比客製化各式各樣的 operator 還來得好。

https://medium.com/swlh/kubernetes-operator-for-beginners-what-why-how-21b23f0cb9b1

#小編

【矽谷牛的耕田筆記 - 時間軸 】正式上線！！

https://technologynoteniu.github.io/timeline/

最近收到來自粉絲的來信反應說耕田筆記更新太快來不及跟上更新的進度，經過了解我們發現 Facebook 粉絲頁的其實對於單純只想看技術文章的觀眾不夠友善，非常難回去查過去曾經看過的貼文，此外上面有太多東西會讓觀眾分心的內容。

這這些背景下，我們決定提供一個乾淨的耕田筆記時間軸，讓大家可以專注於技術內容。目前這個網站對行動裝置訪問也是友好的。

此外我們也有提供按照主題分類的文件型網站，收錄了過去所有貼文。

【矽谷牛的耕田筆記 - 主題分類 】https://technologynoteniu.github.io/awesome-notes/

這邊跟大家分享一下一個 GitHub 於 2021 的小更動

2020/08/13 之後， GitHub 將停止所有基於密碼的操作授權，這邊來談一下相關的影響及改動

# 改變內容
1. GitHub 將要使用 Token-based 的方式來取代原本密碼的認證系統，但是要注意的是這邊指的是相關應用程式的整合，你原生網頁登入都還是使用你的密碼


# 影響層面
1. CLI 方面你如果是使用 HTTPS 這個方式搭配帳號密碼來存取 GitHub
2. 任何第三方應用程式如果是基於帳號密碼來連動 GitHub 的，全部都會失效

# 不被影響的使用情境
1. 如果你本身已經有開啟兩階段 (2FA)認證，那你其實已經被要求使用 Token 或是 SSH 的方式來認證
2. 如果你是 GitHub App 的維護者，因為 GitHub App 本身就不支援密碼的認證，所以你不會受到影響
3. GitHub 企業版本用戶，對於地端自架環境不影響


# 時程
1. 2021/06/30 - 2021/07/28
這個階段是鼓勵所有受到影響的用戶與App趕緊進行修正以避免下個階段直接遇到不相容的問題，因此會暫時的要求所有操作都要使用 Git/SSH 來授權。
3. 2021/08/13
這個階段開始，所有 Git 相關操作都要基於 Token/SSH 兩種方式

# 該怎麼做
1. 對於開發人員來說，如果你本來有使用密碼來授權任何 GitHub 相關的操作，請立刻改為使用 Personal Access Token 或是 SSH key 的方式
2. 對於系統整合人員來說，請參閱 Authorizing OAuth Apps 相關的操作來修改


原文連結:
https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/

今天這篇文章來分享 knative 這套 Kubernetes 內的 serverless 解決方案
該文章分成幾個部分
1. 什麼是 Serverless, 帶來的好處是什麼
2. 什麼是 knative，該專案的特色有什麼
3. 透過實際範例，安裝 knative 到你的 kubernetes cluster 中，並且透過一個簡單的 golang 應用程式來展示 knative 是如何運作的

作者認為 serverless 最大的好處就是可以讓開發者專心寫程式，不需要考慮太多底層的架構，譬如說什麼是 Kubernetes，如果要部署我寫的程式，我應該怎麼做
Knative 該專案基於 Kubernetes而開發，希望能夠提供簡單且靈活的 serverless 解決方案。

採用 Knative 的話，開發者可以專心寫程式，並且使用一行指令去部署你的程式到 Kubernetes 中， Knative 會幫你把剩下的事情完成，譬如創建相關的 Deployment/Service/Ingress 這些資源。

Knative 收到相關創建請求時，本身並不會馬上創建相關資源，反而是等到該應用程式第一次被呼叫時，才會開始創建相關資源，同時也能夠根據當前的流量而自動調整需要的 instance 數量。藉由這個機制可以提供更好的資源管理


對於該專案有興趣的，記得點選下列連結觀看全文來瞭解更多

https://medium.com/better-programming/go-serverless-on-kubernetes-with-knative-b3aff3dbdffa

今天這篇文章要探討的是關於 Kubernetes 內應用程式版本的一些議題。
Kubernetes 提供一個平台供開發者與維運者去安裝各式各樣的應用來滿足各種不同的工作，然而這些應用程式本身都由不同的組織或公司維護，且都有屬於自己的版本發行。

對於維運人員來說，要將這些應用程式安裝到 Kubernetes 內也有眾多選擇，不論是 Helm, Kustomize, Jsonnet 甚至是原生 Yaml，這也意味者一個 Kubernetes 叢集內，可能同時使用多套工具來安裝應用程式

作者的公司遇到的問題就是，我要怎麼知道目前哪些應用程式有新的版本可以更新? 有沒有一個類似 Maven 或是 Scala Steward 之類的工具，可以幫忙檢查所有使用軟體的版本狀態是否有新版需要更新。

作者沒有看到一個適合於 Kubernetes 內的解決方案，但是找到了一個名為 nvchecker (new version chekcer) 的開源專案，並且嘗試使用該開源專案來解決版本更新問題

對於使用 Helm 的應用程式來說，我們可以透過 helm repo 的方式來觀察最新版本，這部分簡單。
但是對於其他的安裝方式，有些可能只能觀察 Github/GitLab 的頁面，或是相關的 Tag 來知道最新的 image 有哪些。

作者於文中示範如何使用 nvcheckr 來檢查不同軟體的最新版本，並且輸出可更新的選項讓管理員人知道有哪些需要處理。

對該議題有興趣的可以點選下列連結觀看全文
https://medium.com/bigdatarepublic/software-versioning-on-kubernetes-806a48480832

本篇文章是由一個微軟的工程師所分享的，如何視覺化團隊中 GitOps 的運作過程。

文章前半段描述與介紹微軟的開源專案 Bedrock，該專案重新包裝了 Flux 這套 GitOps 的工具，並且根據過往的實戰經驗重新調整而成的最佳實戰組合包

後半段作者開始介紹如何使用這套工具來搭建一個簡單的 GitOps 流程，並且介紹一個由微軟開發的視覺化工具，希望透過這套視覺化工具來解答下列問題


- 誰是這次修改的作者
- 哪個服務
- 哪個環境
- 哪個Branch
- CI/CD 的日誌
- 誰同意這次的部署
- 什麼時間發生的

針對 Flux 這套 GitOps 的工具，也會想要知道
- Flux 是否同步成功
- 叢集中的應用程式狀態是否如 Git Repo 內文件所描述的一致
- 有沒有任何 Pod 失敗
- 有沒有規模擴大的需求？
- 節點的狀態

為了解決這些問題，微軟開發了 Spektate 這套開源專案，這些內容都可以於 Bedrock 這套大補包內找到


原文: https://samiyaakhtar.medium.com/gitops-observability-visualizing-the-journey-of-a-container-5f6ef1f3c9d2

今天這篇文章是個基礎介紹文，跟大家介紹一下 Kubernetes 裡面的 Job，不同於 Pod 這種屬於 daemon 的運算資源， Kubernetes 提供了 Job 以及 CronJob 這種一次性的運算資源。 

Job 以及 CronJob 差異就是什麼時候該執行，Job 就如同其他資源一樣，創建到 Kubernetes 內後就會開始執行，而 CronJob 則是可以制定一個時間點，去定期反覆的執行

雖說 Job 是一次性的工作流程，但是對於 Kubernetes 來說，最小的工作資源就是 Pod，所有更高階的抽象資源都是基於 Pod 配上不同的 Controller 來完成。
Job 的設計也是如此，最終運行勢必是叫起一個 Pod 來幫忙運行，但是 Job 則會期望該 Pod 最後可以進入 Completed 的狀態。

什麼情況下我們可能會使用 Job 而非其他資源如 deployment/daemonset/statefulset ?
譬如說一個 AI 的模型訓練，一次物件的偵測 甚至是一些系統資源的檢查與清除，這類型的工作都可以考慮用 Job。而那些 Server 類型需要長時間存活的服務則應該使用其他高階類型的資源來部署。

原文算是非常清楚的介紹 Job 的使用，包含了諸如 backofflimit, parallelism, activedeadlineseconds 等參數的含義，並且也有透過實際的範例來展示怎麼使用。

如果對於 Job 這種物件不熟系的，可以參考一下原文來學習一下怎麼使用
https://levelup.gitconnected.com/understanding-jobs-in-kubernetes-541614ccd796

文章開頭借用了日文的 Poka-Yokes 來分享有哪一些準則或是技巧可以讓你打造一個具 Mistake-Proof 的 Terraform 程式。

文章內列舉了四個準則，這邊簡單列舉了一下每個準則的概念，詳細資訊可以閱讀全文

# Rule 1: Use Terraform Modules to abstract specific pieces of infrastructure into logical groupings
1. 針對需求與架構去拆分你的 Terraform Module，舉例來說，創建一個名為 ECS Service 的 Module，而該 Modules 內其實會創建如 ECS, autoscaling target, metrics 等諸多資源。也正式這些資源相互合作才真正的搭建出 ECS 的服務
2. 上層的應用接下來都會以 ECS 服務為考量去使用，本身不需要去考慮太多底層創建的資源，透過變數的方式來讓不同的呼叫者有不同的 EC 服務


# Rule 2: Use Terraform Data calls to provide information
1. 人類其實很容易犯錯，特別是一些反覆執行的工作。但是電腦非常擅長這類型的工作
2. 相對於要求使用者或是開發者維護各類資源的 ID 或是資訊，更好的做法是利用 Terraform 內的 data 功能，主動地從遠方抓取這些資訊，並且搭配 filter 來過濾不必要的資訊。


# Rule 3: Be Smart About Where Interpolation and Concatenation Happens
- 創建應用時，很容易透過 Copy/Paste 等方式來創建相關資源，這時候就要特別注意資源的名稱是否有重複，是否忘了修改
- 透過變數的方式幫資源命名，但是要注意如果你今天想要修改命名的規則，每個有用到該資源的檔案都要去修改
- 有使用 Module 的話，可以考慮於 Module 呼叫時去組合相關名稱，而不是 Module 內組合。

# Rule 4: Implement State Locking for Ease of Deployments
- Lock 非常重要，透過 lock 機制我們可以避免同時有多個更新造成狀態不一致


有興趣的可以點選連結來觀看全文
原文: https://medium.com/capital-one-tech/terraform-poka-yokes-writing-effective-scalable-dynamic-and-error-resistant-terraform-dcbd6a0ada6a

本篇文章是個入門介紹文，主要探討 Liveness 以及 Readiness 這兩個非常實用且重要的觀念。
由於這兩個元件並不是一個基本 Pod 所要的基本元素，所以如果沒有特別研究與使用時，可能也不清楚原來還有這兩種不同的探針可以幫忙我們更友善與彈性的去管理 Pod，準確來說更是 Container 的行為。

過往我們在運行一些應用程式的時候，可能都會有所謂的暖身期，應用程式起來到真正可以提供服務中間會有一些初始化的過程要跑，可能需要幾秒，甚至到一分鐘都有可能。

但是當應用程式給容器化後，對於最上層的管理平台來說，如果我今天只用 Continaer 是否叫起來 當作該應用程式的狀態，實際上遠遠不夠的，就如同上述提到的，會有一些初始化等暖身時間需要等待，而這兩個探針就是從不同角度去幫忙輔助，讓 Kubernetes 有更多方式去判別到底當前 Container 是否已經準備就緒，是否可以認定已經是運行狀態甚至可以接受網路流量

如果對這兩個概念還不熟的，可以參考原文搭配一些範例學習一下

https://devops4solutions.medium.com/kubernetes-pod-health-check-liveness-and-readiness-probe-1118a265c193

今天這篇文章是作者過去三年多來維護 kubernetes 叢集下的經驗談，作為一個每天維護 400 台以上機器，超過 20 多個 Kubernetes 叢集的管理人員，要如何有效率的去控管與查看不同叢集，不同 namespace 則是一個值得注意的議題

作為一個 kubectl 工具愛好者，作者整理了自己使用的四個小技巧來幫助自己每天有效率的去管理多個 kubernetes 叢集。

1. 善用其他 log 工具來同時監控多個 pod
如果常用 kubectl logs 的人不知道有沒有過下列經驗，(1)每次要觀看特定一個 pod 的時候都要用滑鼠去複製貼上那些充滿亂數的名稱，(2)想要同時監控多個 Pod，也許這些 Pod 也不屬於同樣的 deployment，(3) 有時候根本記不得這些 pod 有哪些 label 可以用，所以還是採用最預設的參數使用

如果有這些問題的可以考慮使用看看一些針對 log 的解決方案，不論是本篇文章提到的 kubetail, 或是其他的方案如 stern, kail 等，都可以嘗試使用看看

2. 提供一個動態方式去修改預設的 namespace 而不是每次指令都要一直不停的輸入 "-n"
當今天已經很明確接下來的指令操作都會固定於某個 namespace 內來管理時，可以直接切換預設的 namespace，這樣操作上可以很下一些時間，同時也可以避免中間有任何指令不小心忘了輸入 namespace 導致不預期的操作

3. 修改 shell 讓其顯示必要資訊
這也是我非常推崇且自己一直都有使用的方式，透過修改 shell prompt 的方式讓其告知當前使用的 context 以及 namespace 是誰

如果你本身有管理多個 Cloud Provider 帳戶的，我認為也可以透過這種方式來幫忙提醒自己

4. 將常用的指令透過 alias 的方式給縮寫
透過此方式可以減少打字的時間，同時指令愈長，不小心打錯的機會也就愈高

整體而言就是，想盡辦法讓自己工作更有效率，能省則省，同時也要尋找一些機制降低錯誤發生率。

https://medium.com/better-programming/4-simple-kubernetes-terminal-customizations-to-boost-your-productivity-deda60a19924

「I will always choose a lazy person to do a difficult job because a lazy person will find an easy way to do it. Frank B. Gilbreth Sr.」

如果可以，誰不想更輕鬆的完成工作

今天分享的這篇文章是作者從自己過去的工作經驗擷取出來一些關於自動化的思維，畢竟人本來就不擅長反覆執行工作，還容易因為粗心，恍神等造成差錯。這是電腦相反，其非常適合處理這種枯燥且反覆的工作。

作者認為作為一個開發者，我們必須要先理解與釐清，日常生活中，到底有哪些事項與流程是有機會自動化的，有機會讓電腦幫我們完成。

文章內，作者分享了四個他覺得值得自動化處理的流程，當然這些只是冰山一角，做重要的還是自己能否從中擷取有用的知識與概念，並且套用到自己的團隊與日常生活中，透過這些自動化的處理，讓自己能夠更專心的處理更重要的工作，而這些重複且瑣碎的事項就讓電腦來幫忙吧

作者列舉了四個自動化的範例，詳細內容可以參考全文
1. Code Style Checks
2. Automation on GitHub
3. Localization Integration
4. Deployment Pipeline


https://medium.com/dev-genius/4-automation-ideas-for-developers-5e0985fd83b9

本篇文章探討的是 Terraform 12.20 所推出的兩個新功能， can() 以及 try()，來聊聊這兩個新功能對於開發者來說能夠帶來什麼樣的效益

can 這個功能主要是用在變數的簡單測試，譬如幫你確認變數的數值是否符合預期，這邊也可以搭配 regex 這種正規表達式的方式來幫你驗證輸入值是否符合規範。

try 這個功能目前使用起來跟大家寫程式所習慣的 try/catch 有點類似， try 之中要傳入一系列的參數，然後 try 會回傳第一個沒有發生錯誤的參數。因此如果今天有一些資料處理比較複雜的部分，可以考慮使用 try 來幫忙驗證。
舉例來說，今天需要透過 yamldecode/jsondecode 的方式來處理一些動態資料，我們可以撰寫類似下列的程式碼

locals {
  raw_value = yamldecode(file("${path.module}/example.yaml"))
  normalized_value = {
    name   = tostring(try(local.raw_value.name, null))
    groups = try(local.raw_value.groups, [])
  }
}

來幫忙判斷到底該資料有沒有成功抓取並且解析，此外我們也可以透過 try 的方式來達到一些變數的兼容性。
譬如說我希望當某個變數是字串時，回傳一個長度是一的陣列，當變數是一個陣列時，直接回傳一個陣列。 參考用法如下

locals {
  example = try(
    [tostring(var.example)],
    tolist(var.example),
  )
}


點選下列文章或是官方文件來學習更多！

https://levelup.gitconnected.com/using-terraforms-try-can-and-input-validation-eb45037af2b2

今天這篇文章要探討的是如何透過 helmfile 這個專案來管理你的 helm charts，你如果目前是採用 helm charts 來管理 kubernetes 內的應用程式，同時單純使用 helm charts 覺得卡卡的，想要探索更多不同的管理工具，那非常推薦來研究看看 helmfile

# 可能問題
過往使用 Helm 來管理應用程式時，你會需要使用 helm 這個指令來進行管理，不論是安裝，解除，升版，降版，甚至是傳遞不同的參數，這一系列的操作都需要透過 helm 的指令來安裝。
當今天目標叢集內有多個應用程式都需要透過 helm 來處理時，你會怎麼做？

一種可能的做法就是撰寫相關的 script，把所有會用到的 helm 指令都包進來，接下來於 CI/CD 的過程中去呼叫這個 script 來處理

那有沒有一個現成的工具，可以更優雅的幫忙處理這個問題，甚至透過這個方式讓我們也可以採用 Infrastructure as Code 的方式來部署與管理 Helm Charts.

如果你對於這個議題有興趣，可以快速的看看下列原文，原文中用一個簡單的範例去示範如何使用 helmfile 來安裝與管理多個 helm charts.

https://medium.com/swlh/how-to-declaratively-run-helm-charts-using-helmfile-ac78572e6088

今天這篇文章探討的是 Git 的 pre-commit hook 系統，透過這種 pre-commit 的系統，能夠幫助開發者與本地開發時，先行進行一些處理，避免什麼問題都要丟到遠方的 CI/CD pipeline 去檢查。畢竟程式碼更新，觸發 CI/CD 流程，等待結果告知，這部分有時候都要花上數分鐘，往往就是檢查到一個格式錯誤，譬如拼字錯誤，多一個空白，格式錯誤等。

如果今天可以將一些常用的檢查給複製一份到本地端去執行，這樣開發者可以更快地找出錯誤，同時也可以節省很多等待的時間，因此本篇文章就要針對 git pre-commit hook 來介紹。

本篇文章要介紹的並不是直接使用 git 的 pre-commit hook，而是要使用 python 的套件 git pre-commit hook，其龐大的生態系可以幫助使用者輕鬆的使用常見的 yaml 格式來管理 git 本身的 pre-commit hook。舉例來說，可以於專案底下放置一個有下列內容的檔案

repos:
-   repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v3.2.0
    hooks:
    -   id: trailing-whitespace
    -   id: end-of-file-fixer
    -   id: check-yaml
    -   id: check-added-large-files

透過 python 的 pre-commit hook 系統，會將其中描述的四個功能 (trailing-whitespace....check-added-large-files)實際的程式碼給轉換並且安裝到 .git/hooks/pre-commit 底下。

同時透過這種框架，開發者也可以自行開發屬於自己的 pre-commit hook並整合到該 yaml 檔案之中。整個使用的方式非常簡單

1. 透過 python 的方式安裝 git pre-commit 
2. 準備一個名為 .pre-commit-config.yaml 的檔案，並且描述你希望使用的 hook
3. 透過 pre-commit install 的方式將該 yaml 的內容轉換為真正 git 所使用的內容
4. 可以開始透過 git commit 來幫助你進行本地檢查囉

如果對於提升本地開發效率有興趣的人，不要錯過研究看看 git pre-commit 這種機制，不論是直接撰寫 git 或是透過這種 python 的 git pre-commit 框架，只要能夠幫忙解決相關問題，提升效率就會是一個值得研究的方法。
更多的 hook 參考以及該框架介紹，請點選下列全文來觀賞囉
https://towardsdatascience.com/pre-commit-hooks-you-must-know-ff247f5feb7e

今天這篇文章是一個 Jenkins Container 的特殊玩法，作者使用五個連續的 Jenkins Job 來打造一個測試應用程式的環境，期望透過這種機制來打造出一個符合不同程式語言的流水線。

第一個 Job 會先嘗試抓取遠方的程式碼，譬如 GitHub Repo 遠方的 code.
第二個 Job 會根據該專案的程式語言呼叫起不同的 Container 來運行測試環境
第三個 Job 則會根據前述的環境來進行測試，根據結果來判別本次的修改是否正確
後面兩個 Job 主要偏向監控以及通知用的，如果本次修改導致測試失敗，會將 log 訊息以及相關資訊傳送給 admin 告知有工作失敗

註:我個人是覺得與其這樣弄，不然專心讓每個 job 對應一個程式語言，然後使用 Jenkins Job Builder (JJB)來管理這些 Job，這樣每個 Job 的工作也明確也專一，維護起來也方便。
不過文章就是多看也不錯，也許用不到，不過至少可以知道會有人這樣弄，也可以從中反思這樣的優缺點。

https://medium.com/@fmirikar5119/deploying-applications-with-jenkins-container-34fd0348282f

今天這篇文章是一個入門介紹文，跟大家介紹一下 Secret 這個物件。與 ConfigMap 一樣， Secret 也是 Kubernetes 內建的一個特別儲存單元，用法完全與 ConfigMap 類似，但是最大的差異在於其本身的內容必須要透過 base64 進行編碼以及該物件本身會放在 tmpfs 而非真正的檔案系統下。
但是也就是這個編碼以及 Secret 這個名詞很容易讓人搞混，以為把所有的東西都放到 Secret 就安全無誤，實際使用上才會發現這並沒有很安全。
因此本篇介紹完會探討 Secret 的使用方式，以及實務上可以怎麼使用

1. 透過 yaml 這種 declarative 的方式來描述 secret 的內容，這種格式下也有多種用法
a. [removed] tls, docker-registry。
如果你有使用過 imagePullSecrets 這種類型來存取非公開的 contaienr registry 的話，就會需要使用 docker-registry 這種類型來存放相關的存取資訊。

由於上面提到的 base64 都是編碼，並非加密，因此如果有任何加密的需求，請一定要考慮使用不同的解決方案，譬如 Vault, Sealed Secrets, Helm Secrets 等不同的解決方案，千萬不要把 secrets 的內容直接編碼就放到公開的 git repo 上，這樣是完全沒有安全性可言的。


如果對於 secrets 這個物件還不太熟的，可以參考這篇文章看看各種基本用法

https://medium.com/better-programming/how-to-use-kubernetes-secrets-for-storing-sensitive-config-data-f3c5e7d11c15

容器的蓬勃發展使得現在大部分的開發者都一定聽過 docker 甚至是 container 這類型的名詞，但是對於維運人員來說這完全不夠，他們更在意的是如果要將這些容器化的應用程式給部署到生產環境上，要如何面對千變萬化的環境並且能夠處理得妥妥穩穩的。

為了解決這個問題，勢必要有一套容器協同合作方案，能夠處理至少下列四個功能
1. Scheduling: 決定哪些 container 要運行到哪個節點
2. Management: 容器的生命週期該怎麼管理
3. Service Discovery: 不同的容器服務要如何存取彼此
4. Load Balancing: 透過負載平衡的方式來轉發各式各樣的流量

過去百家爭鳴的時代已經慢慢消退，2021 的這天，我想 Kubernetes 是所有人想到這個問題的第一直覺反應。

本篇文章是 2018 年底的文章，作者想要描述到底一個容器協同方案應該長什麼樣子，要提供什麼樣的功能，也許最後其實作與使用方式與 Kubernetes 不盡相同，但是其背後的目的都是一致，希望能夠提供的解決方案讓大家開心的使用容器化的應用程式來面對各式各樣的部署環境。

本篇文章中，作者採用了 Nomad 以及 Consul 來描述這兩個開源解決方案如何組合出一個容器協同平臺，同時簡介了一下這個架構的樣貌以及特色。
透過這兩個解決方案至少達成了 scheduling, service discovery, load balancing 等基本需求

也許現在的你都在使用 Kubernetes 來完成每日所需，但是看看這些不同解決方案的設計與樣貌，也可以幫自己補充一些廣度的知識，讓你可以理解到底這些開源軟體之間的差異

https://medium.com/@obenaus.thomas/how-a-production-ready-container-orchestration-system-could-look-like-6f92b81a3319