關於 kubernetes docker 棄 用 ，我們在網路上蒐集到這些相關的討論、資訊與評價

NT590 特價中

Kubernetes(也被稱為”K8S”)是目前最熱門的話題之一，職場需要許多擁有 K8S 技能的工程師。

透過本課程獲得這些技能！ 這是一個非常好的機會去做一個真正的 K8S 專案，讓自己在真正的專案上達到高專業的水準。

在整個課程中，你將就真實的需求工作 – 但你不需要已懂如何寫程式或懂任何特定的程式語言 – 課程已經為你準備了一套 Docker images，你的工作是使用 Kubernetes 讓這些 images 執行。

該系統是一個基於微服務( Microservice )的架構，在這個課程中，我們將研究在管理這些複雜系統時需要做出的設計決策和權衡。 請注意，本課程不是關於如何設計微服務(儘管我們肯定會討論這一點) ; 開發工作已經完成，我們需要讓系統在營運叢集( production cluster )上執行。

經由分析叢集的執行時期效能( run time performance )，我們還將發現開發人員在程式碼中犯了一些糟糕的錯誤！

你可以在你的本地開發電腦(PC/Mac/筆記本電腦)上完成課程的第一部分。 第二部分(從第 13 章開始)將移到雲端。 你將使用一個真正的 AWS 帳戶，我們將繼續使用 ELK/Elastic Stack 設立監控，並使用 Prometheus 和 Grafana 進行監管。

我為各種不同的人設計這門課程——無論你是 DevOps 工程師，還是開發人員，或者你對整個領域還很陌生，我都會一路解釋。 只需要一些使用電腦的基本知識，或許一點命令行經驗就足夠了。

在 13 – 17 章，你將需要一個 AWS 帳戶，如果你想自己在系統上實驗的話。 如果你是 AWS 的新手，請不用擔心，課程講師將一路罩你——但是亞馬遜會在你運用系統時跟你收費(就像所有 /大多數雲端供應商一樣)。 預估為此支付不超過10美元(這是一個安全的高估) ，但是你需要自己管理這個花費，並且必須在會話( session )結束時刪除你的 Kubernetes 叢集。 不要因此而放棄，這是很好的投資。

https://softnshare.com/kubernetes-microservices/

本篇文章的標題很聳動，看起來是要人完全放棄 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。

5. Others:

當然這篇文章內就沒有花太多篇幅介紹 CRI-O 以及 ContainerD 的關係與概念，如果你對於 CRI/CRI-O/ContainerD 有興趣的話，也可以參考我之前的線上 meetup 錄影: https://www.youtube.com/watch?v=5JhQOjSSnzQ&t=2s

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

本篇文章要來探討 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