35 posts tagged with "Kubernetes"

標題: 「 談談遷移應用程式到 Kubernetes 內的失敗經驗談」 類別: Kubernetes 連結: https://medium.com/@marcong_54227/unsuccessful-experience-of-migrating-applications-to-kubernetes-a896823d9b95

作者團隊於 2019 年要開發一個全新的 API 應用程式，當時部門的 IT 團隊計畫要將既有的 VM-Based 應用程式給轉換到 Container-Based，最後團隊使用了 RedHat 的系統，並且使用 OpenShift 做為容器管理平台。

從結果來看，該專案從 2020/05 一路到 2021/05 花了整整一年也沒有順利的將應用程式轉移到 OpenShift 中，其中的一些重點有

1. 初期建設時 RedHat 有展示過如何使用 Java 基於 Fuse 開發應用程式，但是作者團隊全部都是 .Net 的經驗，因此團隊花了很多時間來學習如何使用 Fuse
2. 2020/06 時因為團隊的進度緩慢，所以 IT 團隊尋找外部的軟體顧問，尋求如何將 .Net 從 VM 轉移到 OpenShift
3. 團隊內的開發者都不擅長學習新技術，對於學習新技術這一塊非常不行。
4. 外部團隊幫忙建置了 CI/CD 系統，然後團隊內從 2020/09 開始進行程式開發與轉移，可惜直到 2021/05 依然沒有半個產品成功的用 OpenShift 作為正式生產環境
5. 與此同時，外部團隊也撰寫了幾個 .NET 示範應用程式來展示容器化的注意事項，然而團隊本身對 Container 的知識非常薄落，所以團隊人員沒有辦法參考這些範例程式來改善自己開發過程

最後團隊內又針對不同團隊給予不同的想法

1. Application Team
2. Server Team
3. Network Team
4. IT Management Team

譬如 Application Team 的開發人員都只滿足自身的技能，而且拒絕學習新技能，誇張的是一年過後團隊內的人也沒有辦法撰寫 dockerfile 或是使用 docker build.

後續還有一些針對不同團隊的想法與總體建議，整體來說非常真實，一個血淋淋的轉換案例。

標題: 「如何使用 jq 讓你的 kubectl更為強大」 類別: tools 連結: https://medium.com/geekculture/my-jq-cheatsheet-34054df5b650

作者認為 kubectl 本身提供的 label-selector, go-templates, jsonpath, custom-colume 等各式各樣功能使這個工具變得強大，能夠找到符合自己需求的各式各樣資源 然而上述的這些指令使用起來還是會覺得卡卡的，並沒有辦法滿足所有條件，而且不同選項的語法也完全不同，所以對於操作者來說其實不太便利。

順利的是 kubectl 可以透過 -o json 以 json 的格式輸出結果，這時候就可以搭配 jq 這個指令來使用，相對於前述的各種用法，作者更加推薦使用 jq 來處理，因為 jq 是一個更為廣泛的工具， 除了 kubectl 可以搭配外，很多時候都可以搭配 jq 來處理其他情況，因此掌握 jq 的語法實務上會有更多用途。

文章幾乎都是以 kubectl 為範例來介紹 jq 內的各種用法，除了基本的 read/write/filter 之外，還有各式各樣 jq 的內建函式， 有興趣的都可以使用看看

標題: 「Kubernetes 內透過 DNS-01 處理 wildcard TLS 的兩三事」 類別: introduction 連結: https://medium.com/linkbynet/dns-01-challenge-wildcard-tls-certificates-on-kubernetes-d2e7e3367328

很多人都會使用 Kubernetes 的 Ingress 讓外部可以存取的部署的應用程式，同時會透過 Ingress 搭配 Cert Manager 來處理 TLS 的憑證 大部分情況下都會使用 HTTP-01 的方式來進行域名擁有性的認證，而某些情況可能不方便透過 HTTP 來驗證的話就會採取 DNS-01 的方式透過 DNS 創建一個 TXT 的資訊來驗證域名的擁有權，本篇文章則是作者分享 DNS-01 的一些心得分享

1. 文章開頭有介紹使用的 Stack，包含透過 Terraform 來架設模擬環境，並且使用 Scaleway DNS 作為 DNS Provider
2. Cert-Manager 部分的 DNS Provider 要採用 webhook 的方式來動態處理請求，當 cert-manager 偵測到有新的 TLS 憑證 需求時就會透過 webhook 的方式去創建遠方的 DNS TXT 紀錄，接者 Let's Encrypt 就會透過 TXT 來判斷你是否真的擁有個域名

對 DNS-01 使用有興趣的可以看看本篇文章

標題: 「使用 OpenKruise v1.0 提供更進階的 workload 部署與升級」 類別: tool 連結: https://www.cncf.io/blog/2021/12/23/openkruise-v1-0-reaching-new-peaks-of-application-automation/

Openkruise 1.0 版本釋出，該專案是 CNCF 沙盒層級的專案，主要是由阿里巴巴開發與維護，不久前的 Kubeconf 中阿里巴巴的議題也有 分享到有將此專案部署到期內部的 Kubernetes 管理平台

該專案主要是強化 Kubernetes 內應用程式的自動化，包含部署，升級，維運等面向，此外其架構是基於 Operator 去設計的，因此任何的 Kubernetes 叢集都可以安裝這個功能。 相對於原生的 Deployment 等部署方式， Openkruise 提供了

1. 強化 workloads 的部署方式，包含支援原地更新，金絲雀等不同的升級策略。
2. Sidecar 容器的管理，可以更方便地去定義想要自動掛到不同 workloads 上的 sidecar 容器。
3. 提供更多方便維運的功能，譬如可以針對 container 進行重啟，可以針對不同節點進行先行下載 container image，將一個應用程式給部署到多個 namespace 甚至還可以 去定義 Pod 裏面所有 containers 的啟動優先順序，如果 Pod 內的容器彼此之間有依賴性時就可以透過這個功能讓整個啟動過程更加順暢。

有興趣的可以研究看看此專案

標題: 「透過 Kubefarm 來自動化幫實體機器打造基於 Kubernetes in Kubernetes 的 Kubernetes 環境」 類別: Kubernetes 連結: https://kubernetes.io/blog/2021/12/22/kubernetes-in-kubernetes-and-pxe-bootable-server-farm/

摘要: 本篇文章要介紹 Kubefarm 這個專案，該專案的目的是希望能夠於大量的實體機器上去創建各式各樣的 Kubernetes 叢集供不同團隊使用 為了讓整體的運作更加自動化，作者先行介紹何謂 Kubernetes in Kubernetes 這個專案，如何透過 Kubeadm 的方式於一個現存的 Kubernetes 專案 去部署 control-plane 並且透過這個 control-plane 去控管其他的 kubernetes 叢集，基本上達到的效果就如同各種 kubernetes service 服務一樣，使用者完全看不到 control-plane 的元件。

雖然透過這個方式可以很輕鬆地去創建新的 Kubernetes 叢集來使用，但是使用上覺得還是不夠方便，特別是這些實體機器還是會有不少手動的過程要處理， 為了讓整體流程更加自動化，作者團隊又基於 Kubernetes in Kubernetes 這個專案為基礎再開發更上層的專案，稱為 Kubefarm，一個如農場般可以快速於實體機器創建各式各樣 kubernetes 叢集的解決方案

Kubefarm 由三個專案組成，分別是 Kubernetes in Kubernetes, LTSP (PXE-Server) 以及 Dnsmasq-Controller 透過這三者專案的結合，實體機器會自動取得 DHCP 的 IP 地址並且透過 PXE 系統自動化安裝 OS，待一切都安裝完畢後又會自動地加入到現存的 Kubernetes 叢集中

整篇文章滿長的，是一過非常有趣的用法與研究，如果團隊是大量實體非虛擬化機器的讀者可以研究看看別人遇到什麼問題以及透過何種思路去解決的。

連結: https://matduggan.com/mistakes/

本文是作者踩過的各種 Infrastructure 雷，希望讀者能夠避免這些雷。

總共有幾大類，分別

1. Don't migrate an application from the datacenter to the cloud
2. Don't write your own secrets system
3. Don't run your own Kubernetes cluster
4. Don't Design for Multiple Cloud Providers
5. Don't let alerts grow unbounded
6. Don't write internal cli tools in python

其中第六點簡短扼要，大概就是「沒有人知道如何正確地去安裝與打包你的 python apps, 你真的要寫一個內部的 python 工具就給我讓他完全跨平台不然就給我改用 go/rust, 不要浪費生命去思考到底該如何安裝那些東西」

這讓我想到你的 Python 跟我的 Python 每次都不一樣，有已經不支援的 python 2.x, 還有各種可能會互相衝突的 python 3.x....

連結: https://medium.com/kudos-engineering/increasing-resilience-in-kubernetes-b6ddc9fecf80

今天這篇文章作者跟大家分享一些如何加強 Kubernetes 服務穩定的方式，這篇文章這邊做個簡單摘要一下 發生問題: 作者的 k8s 是基於 Google Kubernetes Service (GKE)的叢集，運作過程中有時候會發現部分節點當掉，最後導致部分的服務不能正確使用。這邊作者團隊從兩個角度出發去改善

1. 研究為什麼節點會一直當掉，與 Google Supporte Team 來回信件最後有找到問題點
2. 強化 Kubernetes 服務的韌性，就算有部分節點壞掉也要讓服務能夠繼續運行 ，本文主要的一些觀點也都是基於這邊發展 強化方式
3. 修正 Deployment 的數量，並且加上 Anti-Affinity，讓這些 Deployment 的副本能夠散落到不同的節點上，避免所有 Pod 都塞到同個節點，最後該節點出問題導致 Pod 全部出問題。
4. 所有需要被 Service 存取的服務都加上 Readess Probe 來確保這些服務都準備好後才會收到服務，避免一些請求被送過來確又不能正確處理
5. 加入 Pre-Stop 的使用，再裡面透過 sleep 10的方式，讓 Pod 要被刪除能夠將手上的封包請求給處理完畢 (請看註解補充) 註: 我個人認為第三點其實不太需要，比較漂亮的作法應該是實作 Singal Handler 去處理 SIGTERM 的訊號，收到此訊號後就不要再接受任何 Request 並且把剩下的工作處理完畢，當然如果這部份處理的時間過長，超過預設的 GracePeriod (30sec)，就會被 SIGKILL 給強制刪除。 要解決這個問題可能就要從應用程式下手去看如何改善，或是透過修改 Pod Spec 來提昇 GracePeriodTemination 的長短

連結: https://itnext.io/how-to-set-kubernetes-resource-requests-and-limits-a-saga-to-improve-cluster-stability-and-a7b1800ecff1

今天這篇文章探討的則是 resources 底下的 request/limit 問題。 本文作者之前遇到一個非常規律的服務警告問題，花了非常多時間與步驟去查詢，最後才發現是 Pod 裡面 Resource 的設定不夠嚴謹與完善。 舉例來說， resources: limit: cpu: 1000m request: cpu: 100m 今天假設有一個服務描述，我對 cpu 的最低要求是 0.1顆，但是極限是 1顆 且有一個節點本身有 3 顆 CPU，這種情況下，我們對該服務設定多副本運行(10個). 那根據 request 的要求，10個副本頂多只需要 1 顆 cpu，所以非常輕鬆的可以將 10 個服務運行起來，但是如何今天遇到尖峰流量 ，每個 pod 都瘋狂使用 CPU會發生什麼事情？ 每個副本的極限都是 1 顆，因此 10 個副本就可以衝到 10 顆 CPU..而系統上只有 3顆，這就會造成 CPU 完全不夠使用，最後導致每個應用程式都在搶 CPU 使用，如果沒有特別設定相關的 nice 值來處理，可能會造 成關鍵 process 無法回應(案例中就是kubelet)。 這案例中 limit/request = 10x，作者認為這數字太大，它覺得合理的大概是 2x ~ 5x，並且最重要的是要定期去檢視系統上資源的用量， limit 要設定的合理，如果本身有很大量需求，建議還要搭配 node select, affinity/anti-affinity 讓每個 pod 最好找到適合的配置方式，然後也要避免尖峰流量到來時，系統資源被吃光甚至影響到 kubelet/kube-proxy 等底層服務的運作。

連結: https://www.cncf.io/blog/2020/09/29/enforce-ingress-best-practices-using-opa/

不知道大家有沒有聽過 Open Policy Agent (OPA) 這個 CNCF 專案? 有滿多專案的背後都使用基於 OPA 的語言 Rego 來描述各式各樣的 Policy，譬如可以使用 conftest 來幫你的 kubernetes yaml 檢查語意是否有符合事先設定的 Policy。 本篇文章則是跟大家分享如何使用 OPA 來針對 Ingress 資源進行相關防呆與除錯，一個最基本的範例就是如何避免有多個 Ingress 使用相同的 hostname 卻指向不同的 backend service. 過往可能都是靠人工去維護 ，確保沒有一致的名稱，但是透過 OPA 的概念我們可以再佈署 Ingress 到 Kubernetes 前先進行一次動態的比對，確保當前設定符合所有 Policy，得到所謂的 Approved 後才能夠佈署進去。 有興趣的人可以看看這篇文章，甚至學習一下 OPA 的使用方式

連結: https://www.dex.dev/dex-videos/development-clusters

不知道大家第一次接觸 kubernetes 的時候都是使用哪套解決方案來打造你的 K8s 叢集？ 亦或是作為一個開發者，你平常都怎麼架設 K8s 來本地測試? 這篇文章提到了作為一個 Local Kubernetes Cluster 幾個選擇，並且點出了三個需要解決的問題

1. Container Registry, 作為一個開發環境，應該不會想要每次測試都要將 Container Image 給推到遠方，譬如 dockerHub, Quay，這樣整體效率低落
2. Builder, 如何有效率的幫忙建置你的應用程式，並且與 Kubernete 整合，讓開發者可以更專心於本地開發，而不要擔心太多 k8s 之間的設定 https://www.dex.dev/dex-videos/development-clusters
3. Runtime, 底層使用哪套 Container Runtime, 譬如 docker/containerd/cri-o 註: 我個人對第三點其實沒太多感覺，不覺得本地測試這個會影響太多 後面列舉了當前知名的相關專案，譬如 KIND, K3D, MicroK8S, Minikube 以及 Docker for desktop. 並且簡單的比較了一下這些本地開發的差異。 不知道大家平常本地開發時，都會用哪一套? 我個人是比較常使用 KIND 來測試，畢竟輕量化且同時支援多節點，環境也乾淨，測試起來也方便。