就是今天！21:00 會進行一場Kubernetes 未來移除Docker runtime 的議題座談，歡迎各位參加！

https://www.meetup.com/CloudNative-Taiwan/events/275020442/

Meetup連結：https://redhat.bluejeans.com/629862972

本篇文章要來探討 Kubernetes/Docker 一些關於 connection timeout 的事情，文章非常長，這邊幫大家重點整理

1. 跟我之前分享的 DNS timeout 問題類似，都會踩到 Kernel 的 race condition，都是 __ip_conntrack_confirm 這個人丟掉大家封包的
2. 本文著重於怎麼發現這個問題，如何減緩這個問題。對於喜歡研究細節的人值得一看。
3. 2017年底作者團隊開始將服務遷移到 Kubernetes (v1.8), Flannel(1.9.0)，開始發現團隊中基於 Scala 的應用程式出現封包 timeout 的問題，這導致部分請求回應都延遲1-3秒
4. 決定認真調查網路問題，經由研究與錄製封包後發現 TCP 重送(SYN)的現象，該現象導致第一個封包會特別慢
5. 接下來要縮小範圍，使用環境中的一個VM作為基底，上面安裝 docker，開始觀察相關的網路流量與封包，發現可以重製這個行為，第一個封包從容器出去後，宿主機上面的真實網卡卻看不到，直到下次第二個封包就可以。藉由這個行為他們判斷，問題出在VM上，跟底層其餘硬體架構無關，藉此縮小問題範圍。
6. 介紹 iptalbes + SNAT + conntrack
7. 問題發生在 Kernel 裡面針對 SNAT 去選擇對外 source IP 時會出錯，因為(1)挑選一個適當的 source port, (2)將該紀錄寫到 conntrack 這兩個步驟中間會有落差，因此如果兩個封包同時進入(1)，選到一樣的結果，後續要跑(2)就會有一個人寫不進去，導致封包被丟棄
8. 一種解決方法是告訴 kernel 請隨機幫我挑選對外的 source port, 這樣就算大家同時執行(1)，有很大的機會會挑到不同的 source port，藉此減少衝突的機會。
9. iptables 執行 --masquerate 的時候可以下 --random-fully 這個參數
10. 團隊當時客製化 Flannel 來解決這個問題


註: 對 SNAT 有興趣瞭解的可以參考我之前撰寫的 SNAT Kernel 原始碼閱讀文章
https://www.hwchiu.com/iptables-masquerade.html
https://www.hwchiu.com/iptables-masquerade-handson.html

https://tech.xing.com/a-reason-for-unexplained-connection-timeouts-on-kubernetes-docker-abd041cf7e02

今天這篇文章的內容比較主觀，是作者列出自己認為 DevOps/SRE 2021 需要注意的工具

1. Managing Cloud Services via Kubernetes CRDs.
三大公有雲廠商目前也都推出透過 CRD 的方式來管理 Cloud Services，譬如 AWS Controllers for Kubernetes, Azure Service Operator, GCP Config Connector。一旦這些工具逐漸成熟，管理人員可以使用管理 kubernetes 的方式一併來管理相關的雲端資源。

個人看法:目前大家習慣用 Terraform, Ansible 等 IaC 等工具來管理，如果往這個方向走去，等於就是逐漸使用一個方式去管理一切。
此外也滿好奇最初的 Kubernetes Service Catalog 搭配 Broker 的方式其實也已經可以用 Yaml 等方式來管理雲端資源了，沒有仔細看 Service Catalog 目前的發展狀況，這兩者的差異有哪些

2. Pulumi
Terraform 作為 IaC 工具的龍頭老大勢必會有挑戰者對其虎視眈眈， Pulumi 這家公司就是挑戰者之一，該公司的產品提供的 IaC 工具能夠採用常見的程式語言來撰寫，避免所有開發者都要額外學習全新的 DSL。此外 Pulumi 今年度也有推出自己的 GitOps 相關工具，不過儘管如此，目前其使用社群都還是不及 Terraform.

個人看法: 當 CDK + Terraform 整合逐漸穩定後， Pulumi 的特色就會減少一項，這場戰爭目前還是看好 Terraform

3. Terragrunt & TFSEC
Terraform 因為其開放原始碼社群的緣故，有愈來愈多的整合工具來幫忙 Terraform 去處理不同的議題，這種合作模式會讓 Terraform 的功能愈來愈強大。 Terrafrunt 則是一個用來管理大型 Terraform 專案的好工具，能夠幫助開發者更友善的管理眾多設定檔案。此外 TFSEC 則是一個針對安全性議題的整合工具，幫助開發者透過靜態分析的方式去檢查當前 Terraform 的內容是否會有潛在的安全性問題。隨者 DevSecOps 的概念慢慢出來，開發與維運者也要多注重些關於安全性的整合工具。

4. Tekton
CI/CD 市場上能夠選擇的工具實在太多，而 Tekton 則是一個基於 Kubernetes 的 CI/CD pipeline 系統，相對於大部分的系統是透過單一 Yaml 去描述 Pipelin， Tekton 則是透過 CRD 的方式於去定義每個 Stage，其帶來的好處就是相同的 stage 可以重複利用，不需要針對每個 pipeline 都去重新設計

個人看法: Tekton 的架構有好有壞，隨者所有的 stage 都變成單一小CRD，管理者想要一目瞭然整個 pipeline 變得非常繁瑣，使用上也常搭配 JenkinsX 來提供複雜的 CI/CD 功能

5. Trivy
如同前面提過，DevSecOps 的概念出來後，任何部分都要去考慮安全性，而 Container Image 本身也是個不容忽視的地方。因此也有不少的開源專案針對 Container Image 來進行掃描與偵測。有些 Contianer Image Registry 直接整合相關的掃描工具，自動掃描所有更新的 Image 並且提供報告給管理人員。 掃描工具諸如 Trivy, Falco, Clair, Anchore Engine 等都值得大家多多注意。

6. ShellCheck
儘管現在有愈來愈多的工具幫助開發者來管理整個叢集，然而 shell script 的定位還是不可動搖，太多時候我們還是需要自行撰寫相關的 shell scrtip 來完成一些任務。 ShellCheck 則是一個針對 shll script 的靜態分析工具，透過 lint 與常見錯誤等分析，讓開發者能夠寫出有更好品質且更好維護的 shell script.

7. Litmus
2011 Netflix 提出 Chaos Monkey 這類型的環境檢測工具，這方面的議題就沒有減少過，即是到了充滿 Kubernetes 的今日，還是有不少的開源專案或是商業平台在提供這方面的服務，譬如 chaoskube, kube-monkey, PowerfulSeal 以及 Gremlin.
作者這邊想要強調另外一套更容易使用且容易擴充的專案 Litmus，該專案基於 Kubernetes Operator 的概念去開發，透過 ChaosEngine, ChaosExperiment 以及 ChaosResult

原文: https://medium.com/dev-genius/technologies-tools-to-watch-in-2021-a216dfc30f25

Kuberentes 支援的運算資源種類繁多，諸如 Pod, Job, ReplicaSet, DaemonSet, Deployment 以及 StatefulSet.
其中 StatefulSet 則是特別針對 stateful 應用程式所設計的，實際使用上會有些許小地方與 Deployment 用法不同，譬如
1. Storage 使用的是 Template 的概念，希望每個 StatefulSet Pod 可以綁定固定的 PV
2. 名稱採取流水號設計，相對於 Deployment -> ReplicaSet -> Pod 兩層亂數來說， StatefulSet 的名稱更加顯眼
3. StatefulSet 的 Pod 有網路存取唯一性，搭配  Headless Service，就可以使用固定一組的 DNS 名稱來存取固定 Pod(預設情況下，Pod 重啟 IP 就會不同，要做到固定一致需要不少修改)

今天這篇文章算是一個入門教學文，主要是跟大家探討什麼是 StatefulSet，以及於 Kubernetes 內該如何使用，使用上有什麼要注意的，以下幫大家節錄部分資訊

1. StatefulSet 的設計是安全優先，所以預設情況下刪除 StatefulSet 不會連帶刪除使用的 Volume
2. 使用 StatefulSet 的時候，要記得處理當 Pod 被停止，被刪除時，相關資料的寫入與同步
3. 預設情況下, StatefulSet 的創建與移除都是一個一個來，創建時由 0-N-1, 移除則反過來。
4. 對於多節點的 StatefulSet 來說，這些應用程式可能都會需要一些初始化的操作，甚至 leader-election 等相關算法。這意味者 Container(s) Running 不等於 Pod 以及準備好了。
5. 針對上述概念，使用者一定要仔細的去設定 liveness 以及 readiness，來確保
6. PostStart/PreStop 的用法與時機也要考慮進去，特別是 PreStop 用得好還可以減少使用端封包無故重送
7. 研究 disruption budgets 的用法，來確保你的 StatefulSet 運行得更安心
8. 針對特定的儲存空間使用權限問題，可以考慮使用 fsGroup 來修改，而不用自己寫一堆 shellScript 來做。當然要注意儲存空間檔案過多內容過大的情況，預設的 fsGroup 行為可以會導致你的 Pod 花太多時間來啟動

原文: https://itnext.io/stateful-applications-in-kubernetes-808a60bc109

想學習更多關於 Kubernetes 的實戰經驗與基礎設計，可參閱我的線上課程: https://technologynoteniu.github.io/awesome-notes/linux/network/

本篇文章的標題很聳動，看起來是要人完全放棄 Docker，實際上則是詳細的跟大家介紹 Docker 生態系中各種潛在的替換工具，這個生態系主要可以分成 Container Engines, Building Images, Container Runtime 以及 Image Inspection and Distribution.

文章內容偏長，但是偏向系統與概念的去介紹，也是非常推薦吃飯時的良好讀物。
這篇就簡單重點整理一下，詳細的還是請點選全文去觀看

1. Container Engines
作者列出了幾個競爭對手，譬如 podman, lxd, cri-o 以及 rkt. 不過介紹都是以 podman 為主，其特色有(1)daemonless, (2) non-root container, (3) 支援 pod 的概念
此外 podman 的指令完全相容於 docker，因此也可以透過 aliase docker=podman 的方式去運行。

2. Building Images
這邊提到了 Buildah, Kaniko 以及 buildkit.
Buildah 是由 RedHat 所推廣的開源專案，天生整合到 podman 裡面，而 Kaniko 則是 Google 所推出的解決方案，主要應用場景是於 Kubernetes 內建置 contianer image。最後 buildkit 則是 moby 目前開發的下一代 docker build 解決方案，期望能夠提供更多的功能及來提升建置的效率

3. Contianer Runtime
這邊的選擇性列出兩個，最常使用的 runc 以及 RedHat 開源的 crun，兩者都遵循 OCI 標準，因此上述的 Container Engine 都必須要可以輕鬆的於兩者之間切換。

當然除了這些之外，還有不同的 Contaienr Runtime，譬如 gVisor, Kata Container 等安全性更高的解決方案。


4. Image Inspection and Distribution
這邊則是提到了 Skopeo，一樣是由 RedHat 所推廣的開源專案，Skopeo 甚至支援同步不同節點的 Container Registry 而不需要將其內容可複製到本地端，使用上有滿多有趣的功能。

此外還有一個叫做 Dive 的工具也非常棒，能夠幫你檢視 Docker Image 每一層的內容，譬如使用的空間大小等，讓你有機會好好的認識你的 imagea。





原文: https://towardsdatascience.com/its-time-to-say-goodbye-to-docker-5cfec8eff833

今天這篇文章探討的是 JVM 於 Kubernetes 下的使用經驗，對於基於 JVM 的應用程式來說，其需要一點暖身時間，暖身完畢以前，這些應用程式沒有辦法發揮百分百的能力去處理流量與請求，這樣的概念導入到 Kubernetes 後就會使得事情惡化。當今天發現過多流量近來，需要動態產生新的 Pod 來分攤流量，然而這些 Pod 都還在慢慢暖身，這些暖身過程會導致對應的請求時間變得非常長，甚至 timeout。

因此作者要跟大家分享他們團隊是怎麼處理這個問題，嘗試過哪些手段，哪些有效，哪些無效以及這些過程中到底學到了什麼

1. 第一次遇到這個問題時，團隊沒有太多心力去研究，當下解法就是，那我就開更多的 Pod，繼續降低每個 Pod 可能要負責的請求數量 (RRM)。經過團隊測試，這種方式奏效但是帶來的資源浪費的問題，團隊最後部署的資源量是真正理想情況下的三倍之多，這意味者用三倍的金錢，來處理一倍的請求量。

2. 階段二中，團隊打算嘗試增加一個 Warm-up 的腳本去發送一些流量，期盼這種機制可以加速暖身機制。該做法同時也要修改 Readiness 來確保 Warm-up 完成前 Readiness 不會讓真實流量封包導入到 Pod裡面。結果來說，是個不管用的效果，有一點點的長進，但是帶來更多的問題，譬如一個 Pod要花三分鐘 才可以起來，結論就是弊大於利

3. 階段三中，決定從 JVM 本身開始研究起，發現提升 CPU 的資源量可以明顯地縮短暖身時間，讓這些 Pod 可以更快的加入戰場服務。根據作者團隊的觀察，過往使用 1000m 的 CPU 使用量，大概需要 5-7 分鐘的暖身時間，透過將 CPU 使用量提升到 3000m，能夠將整體時間縮短不到 4 秒，效果顯著。因此提升 CPU 使用量就是一個可行的解決方案。 然而因為過往採用的是 Guareanteed Class 的 QoS 設定 (limited == request)，這樣 3000m 的CPU 使用量反而會造成資源浪費，最後造成節點不夠觸發自動新增節點的機制，然後花更多的錢

4. 重新探索 CPU Resource 的用法，決定採取 Burstable Class 的概念，針對 Limit 設定 3000m, request 則是 1000m，這樣可以確保 Schedule 時會用 1000m 來找資源，系統上有足夠 CPU 時也可以讓 JVM 使用到 3000m.

詳細內容請參考下列全文:
原文: https://tech.olx.com/improving-jvm-warm-up-on-kubernetes-1b27dd8ecd58

今天這篇文章是一個經驗文，作者列出了 DevOps 面試時可能會被問的八大問題，並且針對這八大問題給出了其答案，讓我們來看看如果今天是你，你會怎麼回答這些問題。

個人看法: 對我來說看看這類型的文章有時候也是幫你重整思路，看看自己目前哪一個環節還不熟悉，哪個環節還可以更好

首先作者認為， DevOps 面試的題目大致上分成七類，分別是

a. General questions — defining terms/etc.
b. Version control
c. Continuous integration
d. Continuous testing
e. Configuration management
f. Continuous monitoring
g. Containerization and virtualization

根據這七項整合，作者列出了八個問題，這邊就節錄一兩個問題，有興趣的記得點選全文觀看

1. 請解釋當瀏覽器輸入 URL 時，整個的運作過程 (這問題的答案可以簡單也可以男，完全取決於你對於他的認知)
2. 你過往有使用過哪些 DevOps 的相關工具，這些工具是如何整合的？
3. 請解釋一下 IaaS, PaaS 以及 SaaS 的差異性
4. 你會如何定義 Configuration as a code? 這種模式可以帶來什麼好處?
5. 從商業角度來看，採用 DevOps 能夠帶來什麼好處與壞處？


https://medium.com/better-programming/top-8-devops-interview-questions-and-answers-9120f554d1b9

隨者資安意識的提升， Container Image 的安全性檢查變得愈來愈重要，最基本的想法就是針對 Image 本身去檢查是否有任何已知的 CVE 與 vulnerabilities，透過這類型的機制來確保我們要部署到生產環境的 Container Image 是足夠安全的。

目前至少有三種方法可以來達成這目標，第一種是直接使用相關的 CLI 工具掃描，第二種是將工具整合到 Container Registry 中，根據情況自動掃描，第三種則是將工具整合到 CI/CD pipeline 過程中，只有符合標準的 Container Image 才有資格被推到團隊所使用的 Container Image。

本文作者透過 Trivy 以及 GitlabCI 等工具來示範如何於 CI/CD pipeline 中完成 image 的安全性檢查(也就是方式三)。

# 重點整理
1. Trivy 掃出來的安全性有四種，分別是 Low, Medium, High 以及 Critical
2. Trivy 本身不定義什麼樣的結果叫做安全或不安全，完全是根據使用者自己決定。作者認為這個標準取決於團隊對於資安的重視性。範例中，作者定義只要有任何一個 Critical 等級的安全性漏洞，就將該 Image 視為不安全
3. 透過 Gitlab CI 的流程，來建置 Container Image，並且透過 Trivy 掃描，如果不符合安全定義就透過 exit-code 來結束該 stage，同時也會將 Trivy 的掃描結果給一併上傳。


如果對於(2)透過 container registry 來掃描的，可以參考我今年針對 ITHOME 鐵人賽所撰寫的文章: https://www.hwchiu.com/ithome/2020/registry/day21.html

原文：
https://medium.com/alterway/adding-image-security-scanning-to-a-ci-cd-pipeline-2faff072d

最近跟大家分享一個 2020 年初左右的問題，這個問題的徵狀使用者透過 service 去存取相關服務時，會一直遲遲連接不上，直到 63 秒後服務才會通。
這個問題有兩種類型，一個是 63 秒後服務會通，一個則是 1 秒後會通，兩個背後的原因都一樣，這邊就來稍微簡介一下這個問題

# 發生條件
1. 使用 VXLAN 作為底層 Overlay Network，最常見的就是 Flannel 這套 CNI
2. Kubernetes 的版本不能太舊，至少要 1.16 以後，不過目前這個問題已經修復，所以現在要撞到除非特別指定版本
3. 使用的 Linux Kernel 版本也不能太新，目前該問題已經修復於大部分的 upstream

# 發生原因
1. VXLAN 本身是一個基於 UDP 的封裝協議，有一個已知的 bug 會使得其 checksum 發生錯誤，導致封包不會被遠端接收方給接收
2. kube-proxy 內關於 iptables 的設定沒有妥善，導致 VXLAN 封包會進行二次 SNAT
3. 第二次的 SNAT 就會觸發(1) 的 bug(當然還有其他條件，但是那些條件也剛好符合)
，最後導致封包的 checksum 不同，因此送到遠方就被拒絕
4. 底層的 TCP 建立連線時，會不停地嘗試，每次失敗都會等待更多時間，分別是1,2,4,8,16,32秒
5. 五次都失敗後， TCP 就會觸發重傳機制，下一次的重傳就不會進入到第二次的 SNAT，因此封包就不會踩到問題，因此通過

# 解決方法
1. 基本上這個問題要踩到要各方一起努力才會踩到，也因此修復方式也是多元化
2. Kernel 本身修復了關於 UDP 封裝的 Checksum 計算
3. Kubernetes 這邊則是針對 kube-proxy 進行強化，其使用的 iptables 規則會避免二次 SNAT 的情況

# 其他問題
1. 為什麼 TCP 重送後就不會踩到二次 SNAT? 這部分我看了相關的 issue 以及諸多文章都沒有看到解釋，都在探討 SNAT 後產生的 checksum，至於為什麼 TCP 重送後就通則是一個謎底
2. 為了解決這個謎體，我特別指定 kubernetes 版本並且重新編譯 Ubuntu 的 Linux Kernel 版本，盼望從 Kernel 中來觀察並且理解這個問題，目前已經有一些初步的進度。之後完成後會在撰寫文章跟大家分享這個問題
 
這個問題我認為非常有趣，也許自己的環境剛好沒有踩到，但是可以透過觀察不同的 issue 來研究各式各樣問題，也藉由這些過程來學習

相關 PR: https://github.com/kubernetes/kubernetes/pull/92035

這是一篇幻想文，幻想如果你可以重新設計 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