#kubernetes1.20 #dockerbye

隨著 kubernetes 1.20 相關消息愈來愈多，目前一個引起廣泛討論的就是 docker support 將被標示為棄用，並且於未來版本的中將正式移除。

到底這個未來的改變對於開發以及維運人員來說，到底會有什麼樣的衝擊，這邊就來跟大家分享一下我的看法。

❗ 開發人員

Q1: 我需要重新學習新的工具嗎？ 能不能繼續使用 Docker?

A1: 大部分情況下，你不需要重新學習任何工具，可以繼續
使用 Docker 作為本地開發，你產生的 Image 依然可以讓 Kubernetes 去運行。

Q2: Kubernetes 一旦不支援 Docker，那我的 Image 還可以放 Docker Hub 嗎?

A2: 這個沒有問題，因為目前的 Container Registry 都基於
OCI 標準來設計，因此格式相容的情況下， Kubernetes 是可以繼續使用 Docker Hub 上的 image.

Q3: 我的開發環境是 Mac，使用的是 Docker for Desktop 並且用 Docker 內建的 Kubernetes 來開發，請問我會被影響嗎

A3: 這個開發環境比較特別，可以讓 docker build 產生的 image 直接給 kubernetes 使用。一旦 Kubernetes 底下使用別套，也許這條路徑會出問題。 因此這個問題值得關注。

❗維運人員

Q1: 我的公有雲 Kubernetes 服務會被影響嗎？

A1: 三大公有雲目前都有提供除了 Docker 以外的解決方案，可以參閱相關文件來切換。
如果已經使用 containerd/cri-o 這些解決方案的話，基本上什麼都不用做。但是如果本來使用的是 docker 的話，那就要注意一下你的服務提供者有沒有提供轉移方式。

Q2: 自架 Kubernetes 會被影響嗎

A2: 這取決於你的使用方案，譬如你使用 Rancher 的話，預設是使用 Docker，因此勢必未來一定會有一波轉移問題要處理。
另外如果 Kubernetes 節點是由自己處理的，那要注意需要自行安裝其他的 Container Runtime。單純只有安裝 docker.io 是不夠。

Q3: 維運上會有什麼改變?

A3: 未來若 k8s 不再支持 docker，勢必你將不能於節點上使用 docker 這個指令來觀察相關的運行資訊。這部分可能需要改用 ctr 或是 crictl 等不同的 CLI 工具來觀察。
全新的工具，全新的用法勢必需要學習

Q4: 這樣切換有什麼好處?

A4: 不論是切換到 Containerd 或是 CRI-O ，效能上會提升，與資源消耗會下降，整個容器處理流程也會變得更加精銳

❗結論

1. Kubernetes 不是 Docker 管理平台，是容器管理平台。定義 CRI 標準就是為了支援多種容器技術。

2. Docker 被移除是可以考慮的，未來我認為 CRI-O 都有可能變成預設解決方案，因為其本身的設計就是為了 K8s 而最佳化，同時也與 Kubernetes 版本對齊，

3. 1.20 只是警告，將要退役，並不代表完全移除。但是不久的將來就會正式移除。

4. 如果有時間，就提早進行準備，永遠都不要到最後一刻才決定處理。大量仰賴 Open Source 的情況下，每個專案的開發能量也都很重要，一個不再維護的專案用起來會很令人提心跳膽。

本篇文章著重於 Terraform 的實戰使用，將 Terraform 這種 IaC 的工具給整合到 Pipeline 系統中，透過 CI/CD 的概念讓 Terraform 來幫基礎建設達到自動更新。

作者使用 Azure 雲端環境作為範例，搭配 Azure DevOps 與 Terraform 來搭建出基於 Infrastructure 的 CI/CD 實作範例。

以下節錄自文章結論
1. 除了 Terraform 之外，其他的 IaC 工具譬如 Ansible, Pulumi 等也都可以搭建出這種 IaC x CI/CD 的模式，當然大部分的雲端服務商也都沒有問題。作者列出了這種模式下帶來的好處
2. 針對 Infrastructure 的改變，可以更輕鬆的再測試環境測試，而且整個架構也相對於彈性，可以加入更多的測試來確保架構改變後，整體服務不受影響
3. 透過測試的步驟，可以確保任何失敗的修改都只會停留在 Testing 的環境，而不會直接更新正式生產環境。
4. 透過 pipeline 的架構，更容易實現 Singe source of truth 的精神，所有 Infrastructure 的修改都要從程式碼著手，並且經由 Review 來確保品質，同時當正式生產環境有出現問題時，也更容易地去發覺到底是什麼修改造成問題。
5. 程式化的執行減少的人員操作的失誤，同時也提供了運行結果的一致性，未來有問題發生時都可以重複執行pipeline來除錯與驗證。
 

https://blog.ardanis.com/ci-cd-for-infrastructure-7d9553b32be0

談論到如何對生產環境進行升級更新時，總是會有幾種方式不停的被討論，譬如 Rolling, Recreate, Blue-Green, A/B, Canary 及 Recreate。 每種策略方法都有其適合場景，底層需要的技術也完全不同，所以使用上除了評估情境之外，也要看看目前團隊現有的工具是否達到你想要的更新策略。

本篇文章要介紹的是 flagger 這套由 weave network 工具，作者於文章中一步一步的介紹如何透過 flagger 來達成 Canary(金絲雀)部署策略。

另外如果你本身是採用 flux 來作為 GitOps 的解決方案的話， flagger 與 flux 出自於同個團隊，因此相關的整合與官方教學文章會更多，有興趣的也可以看一下。

文章的範例清楚簡單，一步一步的介紹使用方式，並且透過不同的情境，譬如更新成功，更新失敗來展示一下 flagger 的部署情況，同時也提到可以透過自定義 Prometheus Exporter 的方式來幫你的應用程式定義什麼叫做服務正常，藉此讓 Flagger 幫你達成 Canary 部署。

有興趣的記得點選全文觀看

https://medium.com/expedia-group-tech/flagger-canary-deployments-on-kubernetes-94364146ff94

過去服務提供者都很喜歡談論 SLA，而現在，更多的討論則是 Service Level Objectives (SLO)。 今天要介紹的文章是個入門文章，帶領大家用簡單的範例來學習什麼是 SLO，裡面牽扯到哪些概念以及元件，以及最後該如何跟相關的監控解決方案整合，來達到提醒與通知的效果。

重點整理
1. 文章使用 Prometheus + Linkerd + Grafana 來示範
2. 如何安裝 Linkerd 以及基本驗證
3. 介紹失敗預算 (Error Budget) 的概念，除了文字敘述之外，還有用實際 PromeQL 的範例
4. 將上述 Error Budget 的資訊給整合到 Grafana 達到更方便的追蹤當前 SLO 的程度

文章內還有提及其他文章來介紹 SLO，連結如下
https://buoyant.io/2020/09/24/service-level-objectives-for-kubernetes/


https://www.cncf.io/blog/2020/11/13/a-guide-to-setting-up-kubernetes-service-level-objectives-slos-with-prometheus-and-linkerd/

對於 CD 操作來說，機密資訊管理一直以來都是重要的議題，我們都知道 Kubernetes Secret 本身只有編碼，沒有加密，因此要如何安全的管理這些機密資訊是個不可忽視的挑戰。

本篇文章採用的是 Helm Secret 的方式來處理這些機密資訊，Helm Secret 本身是基於 Helm Plugin 的架構而開發的，整體使用上就是基於 Helm Chart，這也意味者如果你採用的原生的 Yaml 格式，或是使用 Kustomize，那本篇的內容可能就對你沒太幫助。

作者強調本文不介紹太多關於 Helm Secret 的安裝與使用，相反的，透過一個範例來介紹 Helm Secret 的使用範例，並且針對每一個步驟都有經驗分享，避免大家踩雷

除了 Helm Secret 之外，其實也有非常多的套件再解決這類型的問題，而每個解決方案所採用的架構都不同，有集中管理，有將解密階段移到 Kubernetes 內，各自都有使用者，有機會的話可以每套都玩玩看，看看彼此的差異性與好處。

https://medium.com/@Devopscontinens/encrypting-helm-secrets-7f37a0ccabeb

今天這篇文章主要是探討常見的架構模式，這些架構模式並非侷限於特定的領域或是軟體，而是一個日積月累根據需求而產生的用法。作者開宗明義就說 "A pattern is a solution to a problem in a context."，所以可以想成，每個模式都有針對性，專門用來解決某些脈絡下的問題，
因此本篇文章就針對這個概念介紹了六種不同的架構模式，每個模式都會包含
1. 脈絡情境介紹
2. 遇到什麼問題
3. 可以怎麼採用相關架構模式解決
4. 可能的痛點與缺陷

探討的模式有

- Layered Architecture
- Pipe and Filter
- Client Server
- Model View Controller
- Event Driven Architecture
- Microservices Architecture




文章內容篇長，大概 10min 的閱讀量，推薦吃飯時可以搭配一起看看，有興趣的記得點選下列全文閱讀

https://levelup.gitconnected.com/software-architecture-the-important-architectural-patterns-you-need-to-know-a1f5ea7e4e3d

就是今天！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