這篇文章要介紹的是 Jenkins Operator 這個有趣的應用程式，Operator 的概念先前有不少文章再探討其架構與意義，因此本篇文章會專注於 Jenkins Operator 這個應用程式能夠為 Jenkins 的環境與應用帶來什麼樣的變化。

首先本文開始前，要先準備三個東西
1. Kubernetes Cluster
2. Helm 安裝環境
3. 一個放有你 Jenkins pipeline 與 script 的 SCM(Source Code Management)，通常都是 Git

接下來作者透過 Helm 安裝了 Jenkins Operator 該控制器到 Kubernetes 內並且準備了相關的 CRD 用來控制 Jenkins.

範例中的 CRD 主要會做兩件事情
1. 設定 Jenkins 本身，包含要安裝哪些 Plugin 等
2. SeedJobs: 可以將外部 SCM 內所描述的 Job 內容給直接設定到 Jenkins 內

當該 CRD 給套用到 Kubernetes 後，該 Jenkins Operator 就會幫忙初始化整個 Jenkins 以及相關的 Plugin。最後將 SeedJobs 內所描述的資訊給整合到 Jenkins 中來創建相關的 Job.

透過這整個 CRD 操作帶來的好處我認為有
1. 整個過程盡量減少手動操作，全部都依賴 Yaml 與 Pipeline 等程式碼的方式去維護
2. 與 Kubernetes 整合，對於熟悉 Kubernetes 的操作人員來說，學習過程不會太痛苦。
3. 把 Jenkins 變得稍微簡單一些，一些繁瑣過程讓 Jenkins Operator 去操作

我自己看完後，目前看到的壞處有
1. Jenkins 功能太多，生態系太複雜，我懷疑這種 Operaotr 只是一時的專案，沒有一直保持更新的話一定會有些功能終究還是要手動操作
2. 設定的內容我認為不如 Jenkins 生態系中的 Configuration as Code 這套 Plugin 來的專業與強大
3. Job 的設定部分我個人還是偏好使用 Jenkins Job Builder 這套基於 YAML 的解決方案來管理與定義全部

結論:
1. 我個人是當作一個新東西看看，但是不會有想要嘗試的慾望，因為覺得事情其實沒有變得簡單多少，甚至擔心引入一個半成品，導致多一個東西要維護..

https://medium.com/swlh/introduction-to-jenkins-operator-f4cb7ebc2e0b

#備份 #Velero #etcd

今天這篇文章是作者分享其維運 Kubernetes 叢集中關於備份還原的經驗
對於 Kubernetes 來說，其控制平面由幾大元件組成，分別是 API Server, Controller, Scheduler 以及 ETCD。其中的 Controller 更是整個叢集狀態維護的推手，使用者透過各種方式，不論是 API，Yaml 或是其他方式來新增資源，其實背後的深層目的都是告訴 Controller，我想要達到什麼狀態，而 Controller 透過永無止盡的迴圈與檢查，確保叢集當前的狀態可以符合使用者預期的狀態。

作者工作的經驗中，遇到了想要對 Kubernetes 進行備份與還原的需求，因此思考如何將所有運行狀態的資源狀態給取出，並且當還原時可以將前述備份的資料都寫回去。

作者這邊採用的是一個名為 Velero 的開源工具，透過該工具去還原與備份 Kubernetes ETCD 的資料，並且可以將資料給同步到遠方的儲存空間，譬如 S3, GCS 等

如果對於 ETCD 的備份與還原有興趣的人，可以參考這篇文章，看看別人用 Velero 這個工具來處理，同時也可以想想目前團隊中有沒有這方面的解決方案


https://adrafiq-52.medium.com/kubernetes-backup-and-disaster-recovery-88d6cb8c5bf7

#ingress #network #traefikv2

今天這篇文章是一個教學文，主要是從頭開始搭建一個基於 Traefik-v2 Ingress Controller 的分享文。
熟悉 Kubernetes 的人會知道關於網路存取這一塊， Kubernetes 內部提供了兩大類型的抽象操作，分別是 Service 以及 Ingress。
Service 內部又有不同類型，譬如 ClusterIP, NodePort, LoadBalancer 以及 Headless，而部分的實作也可以分成 iptables 或是 ipvs 等不同技術。
而 Ingress 則有點不同，Kubernetes 本身則不控管與維護任何實作面的操作，只定義相關的介面，這意味所有的 Ingress 的解決方案都需要自己實作相關的 Controoler，去觀察資源的改變並作出相對應的動作。

本篇文章內容不會太艱深，從如何安裝 Traefik 開始介紹，有哪一些 kubernetes 的資源需要被安裝，而這些資源代表什麼功能提起，接者用幾個小範例去介紹如何使用 Tarefik 架構下的 IngressRoute 該如何使用。

對 Ingress 不熟的人還是可以參考參考，當作一個學習

https://pete8s.medium.com/getting-started-with-traefik-v2-on-kubernetes-c23504389f4c

本篇文章作者認為透過 Kubernetes Operator 的設計與精神，是有辦法達到夢寐以求中的 Zero-touch Ops，甚至發展到所謂的 AIOps，維運人員盡可能地減少主動去管理應用程式的部署。

一開始探討到微服務架構與 DevOps 文化的興起，愈來愈多的叢集與資源需要管理，但是如果今天應用程式本身難以管理的話，維運人員則必須要花費大量的精力與時間來部署這些應用程式，這無疑是種本末倒置的行為。

本文一開始作者先快速地複習什麼是 Operator，基本上可以當作是 k8s controller 的延伸版本，畢竟 K8s controller 其運作原理也是透過一個無止盡的迴圈，根據使用者輸入事先定義的好的資源格式，來確保當前叢集內的運行狀態有符合需求。Operator 基於這個概念上，讓使用者可以使用 CRD 這種自定義的格式來定義自己的資源，不單純只是所謂的 deployment/pod/service 等，可以是更符合應用程式需求的抽象資源，譬如 GitRepo, Network, PrometheusService 等

文章內還有更多關於 Operator 的介紹，包含如何透過 SDK 來撰寫開發一個 Operator，有興趣瞭解的
不可錯過。

文章後半部在探討關於 AIOPs 如何達成 Zero-Touch Ops 的願景，文中先以一張圖片來解釋 AIOps 的架構，最後提到如何將 AIOPs 與 Operator 的架構整合為一，該架構中整合了不少常見服務來滿足不同面向的要求，譬如 Grafana, Prometheus, ServiceMesh/istio, Ansible 等。



https://medium.com/faun/kubernetes-operators-to-realize-the-dream-of-zero-touch-ops-5bc8c3e5e11b

從本篇開始，接下來將幫大家介紹 k8s.af 裡面關於各種 Kubernetes 維運上遇到的各種問題。

本篇主題: 為什麼我們要在兩小時內從 fluent-bit 轉換到 fluentd
症狀: 某日下午，開發者通知疑似某些生產環境上面的日誌出現問題，沒有看到任何更新。

作者的團隊已經使用 fluent-bit 來轉發應用程式日誌已經三年多了，過去的經驗表示 fluent-bit 表現良好，有個良好的效能，設定也相對簡單。

問題發生時，首先觀察 fluent-bit 相關的資訊，從中得到關於 ElasticSearch 拒絕接受相關請求的錯誤訊息，最後輾轉從 ElasticSearch 去解決，再也沒有任何錯誤訊息出現了。但是實際的問題還是存在，該看到的日式

然而其實主體問題還在，日誌還是沒有被收集起來送出去，因此這時候團隊就開始思考該怎麼做。其中嘗試過升級降級已經修改不同參數，但是都沒有辦法解決問題，最後於 GitHub 上面找到一個相關 issue(https://github.com/fluent/fluent-bit/issues/2416)，問題情況一樣類似而且沒有解決方法，所以幫助不大，但是至少知道自己並不孤單。

一切都明瞭後，作者團隊知道沒有辦法針對 fluent-bit 的這個錯誤去修改，因此開始思考其他的替代方案，最後選擇使用了 fluentd 來替代。整個抽換過程是緩慢的，先從出問題的節點開始，慢慢的部署 fluentd 並且移除 fluent-bit，其中還透過了 node Affinity 以及 anti-affinity 來幫忙調整部署的選擇。 

最後有興趣的話建議點選原文，幫自己增廣見聞一下

原文: https://prometheuskube.com/why-we-switched-from-fluent-bit-to-fluentd-in-2-hours

Kubernetes 維運經驗分享篇
主題: 解除 CPU 來提升服務效能
關鍵字: CPU Limit, CPU throtting, 高延遲性

本篇文章是探討的是使用 CPU Limit 的經驗，熟悉這個機制的讀者應該都知道能夠這個設定來確保每個 Container 能夠使用的 CPU 數量，同時也可以透過這個機制去確保每個節點上都有足夠的 CPU 資源供原生服務，譬如 kubelet, kubeproxy 來使用。

本篇作者團隊要分享的是設定 CPU Limit 卻導致效能更差的故事，當 CPU 設定為 800ms 的時候，卻發現實際運行的效能最高只有 200ms，反覆查找卻得到是 Linux Kernel 的臭蟲導致。

一個直接的做法就是針對那些本來就沒有過高 CPU 使用量服務取消其 CPU Limit，作者於文章中也探討了一些機制要如何保護與應對這些被移除 CPU 限制的服務。

這個臭蟲於 Linux Kernel 4.19 後已經修復，但是要注意你使用的發行版本是否有有包含這個修復，作者也於文章中列出一些已知的發行版本修復狀況

原文: https://erickhun.com/posts/kubernetes-faster-services-no-cpu-limits/

最近都在跟網路通靈，不免最後又來跟 rp_filter 打交道，因此今天這篇文章來幫大家複習一下 rp_filter 這個系統參數

設定位置: /proc/sys/net/ipv4/conf/$iface/rp_filter

介紹:
rp_filter 全名為 Reverse Path Filtering，是一個 Linux Kernel 用來過濾封包的機制。當封包到達一個網卡時， kernel 會根據該封包的 source IP 去進行反向(Reverse Path)檢查，當系統檢查當前的 routing table 確認該 source IP 是可以轉發的，且轉發出去的網卡與收到的網卡是一致時，封包就可以正確地接收，反之則會丟棄。

目前常見系統上 rp_filter 有三種數值可以設定
0: 請關閉 rp_filter 的功能，請不要對封包的來源進行檢查，一切都收起來。
1: 如前段所述，嚴格的針對 source IP 進行反向查找
2: (1)的不嚴格版本，一樣會對 source IP 進行反向查找，但是反向的網卡不需要與收到的網卡一致，只要確認該封包可以出去即可

大部分的情況下不建議關閉 rp_filter， rp_filter 可以用來驗證 source IP 是否合法，對於抵擋 Spoffing IP 這類型的攻擊可以起到一定的效用。
此外如果有安裝 Calico CNI 的也要注意一下這個設定，因為這種基於 routing 的 CNI 解決方式很容易會因為 rp_fitler 導致功能不正常。

https://www.theurbanpenguin.com/rp_filter-and-lpic-3-linux-security/

關鍵字: EKS, AWS CNI Plugin
影響: 連結服務時頻繁地看到連線失敗

今天這個案例是作者團隊想要嘗試從 kops 轉移到 EKS 上遇到的問題，最初的症狀是整個平台運作起來非常慢。作者提到最初想要轉移到 EKS 上的一個理由就是其擁有更好的網路效能，然而當前的問題症狀很像網路問題，因此團隊最後直接諮詢 AWS 支援來尋求網路專家的支援。

再錄製封包之後終於觀察到了一些現況。所有叢集內的網路流量都運作得非常良好沒有問題，然而外界與叢集內的封包則沒有如此順利，觀察到大量的 TCP 重送封包。

中間與 AWS 來來回回長達一個月，協助錄製各種封包但是還是沒有解決問題，最後作者觀察到一些現象，有些節點會有存取變慢的問題，但是上面的Pod卻沒有事情。而有些則是節點本身沒有問題，但是上面的Pod卻有問題。

後面又有一次的視訊多人會議，中間弄弄整個網路全壞光了，這時候聽從 AWS 的建議開啟了一個 AWS_VPC_K8S_CNI_EXTERNALSNAT=true 的設定，然後網路就全面好了..

文章最後介紹一下整個事情的發生的原因，以及為什麼開啟 AWS_VPC_K8S_CNI_EXTERNALSNAT=true 就一切沒有問題了，有興趣的可以點選全文研究研究

https://yashmehrotra.com/post/2020-03-16-case-of-missing-packet/

關鍵字: conntrack, DNS, CoreDNS-autoscaler
影響: 部分正式生產環境崩壞

整個問題是簡單來說就是正式叢集再不預期的情況下，發生了 DNS 的問題，導致內部服務大概有 15000 筆 query 失敗。造成錯誤的原因是因為 kube-proxy 沒有順利地去移除過期的 conntrack，導致有些 DNS封包被導向到一個已經不存在的Pod。

這個問題的發生前提是，因為某些情境的發生，譬如系統負載過低， CoreDNS-autoscaler 就被觸發起來，將運行的 Pod 數量從三個降為兩個。所以系統上能夠處理 DNS 的Pod剩下兩個，但是如果有節點上的 conntrack 沒有順利清理乾淨，導致所有的封包都被導向那個被刪除的 CoreDNS，問題就這樣發生了。

詳細的過程跟一些學習重點可以參考原文

註:想要掌握 kubernetes 網路，對於 conntrack 的認識絕對不可以少，有太多太多的問題都跟 conntrack 有關，從 race condition, max 等眾多選項都牽扯所有運行的封包。有時間的話一定要好好的複習一下 conntrack 的概念

https://medium.com/preply-engineering/dns-postmortem-e169efd45afd

關鍵字: GKE, CPU Limit, CPU throttling
影響: 服務出現高延遲性，甚至出現錯誤

總結: 作者推薦關閉 Kubernetes 內任何 CPU Limit 的功能(或是從 kubelet 關閉 CFS quota)直到節點上的系統都已經修復 CFS 的相關問題，這個問題會導致不必要的 CPU throttling 並可能導致應用程式短暫時間卡住不回應。

這篇文章內容非常豐富，開頭介紹 container & kubernetes 的基本概念，接下來探討到底 CPU request/limit 是如何實作的，並且透過一個範例來介紹為什麼 kernel bug 會導致整個應用程式卡住


原文下方還有列出各種相關連結，包含 kernel 內的相關文件以及 kubernetes 內探討這個問題的 issue。

https://medium.com/omio-engineering/cpu-limits-and-aggressive-throttling-in-kubernetes-c5b20bd8a718

關鍵字: KIAM, DNS, AWS IAM, latency
影響: 存取服務會花上高達十倍的延遲時間

這篇文章準確的說，問題其實跟 Kubernetes 本身關係不大，反而是遷移 Kubernetes 到系統中常見的溝通問題。作者的標題是真真實實來自 Dev Team 的回饋，當應用程式搬移到 kubernetes 後得到的效果不如預期，也許最後不是 kubernetes 的問題，但是 SRE/DevOps 還是得必須針對這些質疑去探討，找出最後真正的原因。

作者團隊當初要將一個微服務從 EC2 上給整合到 Kubernetes內，卻發現存取該服務的延遲性相對於直接部署到 EC2 上大幅度上升十倍。根據團隊的調查，EC2 的應用程式只需要 20ms 左右回覆請求，而 kubernetes 版本則需要 200ms 左右。

最後來來回回除錯找到問題根源，主要是 AWS Jave SDK 裏面的用法於不同的情境下會有不同的效果。其於 Kubernetes 下會發生每個 request 都強迫去刷新當前的 certificate 資訊，因此每個 request 都還會額外發送一個新的 request 去取得 certificate。

基本上整個問題都跟 Kubernetes 的架構無關，單純是 AWS 架構的用法，如果你有使用 KIAM 相關的服務，同時也有使用 AWS Java SDK，可以參考本篇的問題

https://srvaroa.github.io/kubernetes/migration/latency/dns/java/aws/microservices/2019/10/22/kubernetes-added-a-0-to-my-latency.html

關鍵字: Weave Scope, public AWS ELB
影響: 安全漏洞，系統被挖礦

結論: 作者團隊(JW Player) 的 dev/stage 團隊被發現種植了惡意挖礦程式，因此撰寫了這篇文章來跟大家分享他們的經過，並且期許大家都可以強化自家的 Kubernetes 叢集，避免被各種惡意程式攻破。

1. 一開始是透過監控軟體發現 stage 中有過高的 CPU 使用量，然而系統服務本身就會造成這些過高的使用量，因此團隊沒有第一時間懷疑有問題。隔天於 dev 中也有相關報告，團隊也沒有特別處理，直到這些逐漸提高的 CPU 持續過久，團隊才覺得有問題，開始介入調查。
2. 發現一個名為 gcc 的應用程式是透過 docker 運行的，然而團隊中沒有任何使用 gcc 為 entrypoint 的容器，輾轉發現這個容器的 parent process 則是 weave scope.
3. Weave scope 是一個用來監控 kubernetes 的應用程式，完全沒有理由去運行 gcc，與此同時觀察到這個 gcc 是一個挖礦軟體
4. 最後發現 Weave scope 這個應用程式對應的 Load Balancer 是完全對外公開的，同時也沒有任何認證登入機制
5. Weave scope 本身提供了一個功能可以讓使用者於網頁上去跟容器互動，這邊最後就導致了惡意攻擊，被注入了挖礦程式

文章內有更多的細節關於惡意程式的探討與回顧，有興趣的別忘記點擊原文看看

https://medium.com/jw-player-engineering/how-a-cryptocurrency-miner-made-its-way-onto-our-internal-kubernetes-clusters-9b09c4704205

今天帶來的是 CNCF 使用者科技雷達第四篇的介紹，這篇報導探討的是 Storage/Database 的調查報告

報告中顯示了六個最被大家推崇的解決方案分別是
1. Redis
2. Elasticsearch
3. PostgreSQL
4. MySQL
5. Memcached
6. Kafka

同時根據調查報告， CNCF 團隊觀察到公司對於 Storage/Database 的選擇是非常謹慎小心的，沒有必要不會隨便遷移解決方案。特別是當本來的資料已經達到 TB 甚至 PB 等級時，遷移帶來的成本非常巨大，如果新專案帶來的好處沒有辦法蓋過這些成本時，很難說服團隊去遷移。

詳細的報導介紹可以參考下列原文

https://www.hwchiu.com/cncf-tech-radar-storage.html

今天帶來的是一篇 Podman 的介紹文，有關注 Container 發展的讀者想必對於 Podman 這個詞一定很熟，然而有真的實際將 podman 導入日常工作流程的我想屈指可數。
本篇文章開頭針對 Podman 與 docker 的差異進行了簡單介紹，並且分析 Podman 透過
1) 沒有 Daemon, 2)不需要 Root 也可以運行 等特性帶來的好處。

接者針對 MacOS, Windows 等兩種不常見的平台介紹如何運行 Podman, 對於非 Linux 工作環境的讀者如果有想要嚐鮮使用 Podman 的話，非常推薦可以參考這篇文章的方式去使用與安裝

最最最重要的是，本篇文章是繁體中文所撰寫的，請大多多給予這類型的文章一點鼓勵，大家才會更有動力去分享各類技術文章，否則都只能看國外文章了:(

https://hazel.style/2021/01/14/%E5%9C%A8Laptop%E7%92%B0%E5%A2%83%E4%BD%BF%E7%94%A8Podman%20(%E5%90%AB%20Windows%20&%20MacOS)/

#NetDevOps

今天這篇文章是一個數據調查文，主要內容是探討基於 NetDevOps 的文化下，網路維運人員使用哪些工具來協助日常的網路工作。

這份 2020 的報告總共有 333 的投票者，總共有一個月的投票時間。
整個文章總共有 49 個表格，非常的多...
這邊就列舉幾個大家可能比較有興趣的表格來幫大家預覽，當然對於整體有興趣的人還是不要忘了點選全文瀏覽！


每個項目都列舉前六名，標準基於使用正式於生產環境的票數
感興趣或是已經使用的工具
1. Ansible
2. Grafana
3. Netbox
4. ELK
5. EVE-NG
6. Promethes

感興趣或是已經整合的主題
1. Source of Truth
2. Network Health Moniroting
3. IaC
4. DevOps
5. CI
6. CI/CD

使用何種解決方案來自動化處理設定檔案
1. Ansible
2. 內部開發工具
3. NAPALM
4. Nomir
5. Terraform
6. 網路供應商的自主工具

如何控管設定檔案的改變
1. VCS
2. Rancid/Oxidized
3. 內部開發工具
4. 網路供應商的自主工具
5. FTP/SCP/TFTP
6. Solarwind NCM

管理哪些網路廠商的設備
1. Cisco IOS/IOS XE/Viptela
2. Cisco NX-OS/ACI
3. Juniper
4. Cisco IOS XR
5. Cisco ASA
6. Palo Alto

使用何種工具來模擬虛擬網路設備或是功能驗證
1. GNS3
2. VMWare
3. EVE-NG
4. 網路供應商工具
5. Docker Compose
6. Vagrant


網通業者的生態與軟體業者是截然不同的，很多軟體業習慣的操作流程與直覺並不是這容易的直接套用到網通業者的環境中。
舉例來說，使用公有雲創建 VM 並且於 VM 叢集上搭建出一個初始的工作流程並不難，Kubernetes 套上去後，就可以用容器的方式把各種應用，譬如 Prometheus, Grafana, logging, tracing, message queue 等服務都搭建到各個伺服器上。
對於網通業者來說，今天掌管的目標是 Switch 跟少部分的 Server，光 Switch 要買哪一家就是一個問題。
Switch 不太像 X86 架構一樣，想換什麼 OS 就換什麼 OS 這麼輕鬆，不走 whitebox 的架構下，一旦採購了某家廠商的解決方案，有可能就終生是對方的形狀了。這也是很多人都在提倡希望透過標準化來避免 vendor lock-in 的狀況。
上述的報告也可以看到前六名管理的機器中有四名都來自 Cisco 的機器，這種情況下很多事情都會受限於 Cisco 機器本身的設定與狀況，並不是想要做什麼就做什麼。

為了讓這一切變得簡單，如果可以透過標準化的方式去定義 switch 的架構，讓這一切變得如操作 Server 般簡單時，網通業者就會有另外一種方法來管理環境。
如果相關的軟體都有開源專案可以使用，這樣維運人員就可以用更省錢的方式來安裝與控管這一切的網通設備，聽起來真的很棒
現實生活上則是，網路產業對於 uptime 的需求非常的強，一旦出問題不是單純服務不能連，而是可能影響數千數萬甚至更多的使用者。這種情況下如果團隊全部使用開源專案而沒有 SI 公司的支援與維護，誰敢冒這個險去使用這些呢

最後要說的是，隔行如隔山，永遠不要用自己習慣的工作流程去看待別的產業，很容易被打臉。

https://dgarros.github.io/netdevops-survey/reports/2020

本篇文章來自於 CNCF 使用者雷達第四篇，探討 secret managemetn 的解決工具

如同前面三篇調查一樣，主題比較是一個大方向的探討，CNCF 會員會基於這個主題去提出用到的所有工具，所以可以觀察到結果內會有 Cert-Manager 也同時會有 KMS, Vault 等工具

結論來說: Vault & Cert-Manager 各自於自己的領域撐起一片天
詳細的可以點選下列內容觀看更多介紹與分析


https://www.hwchiu.com/cncf-tech-radar-secrets.html

本篇文章是個技術分享文，Netflix 分享內部過去四年來是如何打造一個分散式的 Tracing System。
Netflix 的串流服務想必大家都很熟悉，但是作為服務提供者來說，要如何維運這套分散式的串流服務就沒有這麼簡單。

舉例來說，當一個特定的使用者回報其服務有問題時，內部的系統要如何把下列資訊給全部串接起來組合出一個可以讓內部工程人員除錯的機制
1. Streaming Session
2. 微服務之間的流量
3. CDN 的處理

對使用者來說就是串流有問題，但是背後的網路封包實際上經過哪些 app，走過哪些節點，踏過哪些機房都是很複雜的事情，不把這些全部資訊都組合起來則非常困難除錯。

Netflix 決定要針對這個問題打造一個分散式的 Tracing 平台，而那時還沒有這麼多如 Opentracing, Zipkin, Jaeger 等相關的開源專案可以用，所以 Netflix 必須要自己去打造這套系統。
這套系統的組成跟現今常見的架構雷同，Application 本身要透過 Library 來產生出 Tracing 需要的資料，接者透過一套串流處理將資料給傳送到後端的儲存空間，最後則是由UI等相關服務來讀取資料方便使用

本篇文章基於這種架構下去探討 Netflix 的心路歷程，其中幾個比較有趣的問題這邊列出來
1. Tracing 資料的取樣該如何設計，過於頻繁會造成資料空間使用過量，過於稀少則會造成資料不夠完整，這部分 Netflix 採用基於 hybrid head-based 的取樣方式，針對特定區間採用 100% 的取樣方式，而其餘則是根據設定來隨機取樣
2. 資料儲存的部分則是有非常豐富的變化歷史，早期使用 ElasticSearch 後來對其 R/W 的效能感到不滿而輾轉到使用 Cassandra，而 Cassandra 最初使用 AWS 的 SSD 做為底層應用，後來改轉使用 EBS 並且搭配資料壓縮與一些過濾機制， 2021 決定要引入 Storage Gateway 的方式來處理

儲存方面幾乎是每年都在改善與改進，真的要遇到問題才有辦法針對問題下藥，這也是架構方面很難一口氣做到最好，隨者業務與流量擴大，很多現有的架構可能都需要打掉重來才有辦法應付

全文不算太短，但是推薦有興趣的人可以閱讀全文來看看 Netflix 是如何打造這套系統的

https://netflixtechblog.com/building-netflixs-distributed-tracing-infrastructure-bb856c319304

本篇文章標題為四個為什麼要於 Serverless 年代使用 Kubernetes 的理由，文章主要從幾個方向下手
1. 什麼是 Serverless, 為什麼 Serverless 這麼熱門
2. 使用純 Serverless 遇到的問題是什麼
3. 為什麼 Kubernetes 很棒

標題看似 Serverless & Kubernetes 是個二選一的議題，實際上文章內強調的反而是兩者設計目的不同，無法互相取代彼此，各自有適合使用的場景。

這種文章值得閱讀的地方我認為是欣賞別人如何分析 Serverless 與 Kubernetes 的好處與壞處，各自特色以及適合的應用場景，透過這些步驟來達成

1) 幫自己複習對於這些概念的理解
2) 幫助自己補充不確定與不熟悉的領域
3) 自己二次思考這些問題，也許能夠想出作者講得不夠明確的地方


這種科普文章也許沒有技術文章來得這麼硬，技術學習上也可能無法讓讀者有所成長
但是有時候這些文章的說詞與說法，可能會是團隊內導入一些新技術時可以使用的說詞與參考

https://betterprogramming.pub/4-reasons-to-use-kubernetes-in-the-serverless-era-cf77ea3b018b

本篇文章作為一個經驗談，探討於 AWS EKS 的環境中要如何避免 IP 發放完畢。
對於 Kubernetes 來說，CNI 負責的功能主要有兩個，分別是 IPAM 以及 Network Connectivity.

公有雲管理的 Kubernetes 為了讓整體操作環境可以與其雲端內的其他元件有更好的整合，通常都會開發屬於自己的 CNI 系統，譬如 Azure, AWS, Google 都有這方面的設計。
這種設計的最大好處就是可以將 Pod 使用的 IP地址透過本來 VPC 內的設計去管理，而本文要討論的就是 AWS EKS 環境中可能會遇到的 IP 地址分配問題。

EKS 預設會使用 AWS VPC CNI 來提供相關服務，其底層實作主要牽扯到底層 ENI 的配置與設定，主要會影響到底還有多少個 IP 地址可以用來分配給新的 Pod 使用。

從 Cluster 的角度來看，要先注意的 VPC 內的網段設定，如果一開始分割的子網段是/28，這情況下你整個叢集內只能有30個左右的 IP 地址可以發放，這數量根本完全不太夠使用。

從單一節點的角度來看，要注意每個節點上可以配置多少個 ENI 以及每個 ENI 能夠配置多少網卡
該 CNI 分配 IP 時會先想辦法把現有網卡上面能夠分配的 IP 填滿，一旦填滿就會創立新的網卡，接者繼續分配 IP，當運行的 Pod 數量超過節點上現時就沒有辦法繼續分配 IP。
官方針對這種情況提供了一個公式去計算
(Number of network interfaces for the instance type × (the number of IP addressess per network interface - 1)) + 2

對於一個 m5.large 的機器來說，支援三張 ENI，且每個都有 10 個 IP 可以分配，因此根據上述公式
(3*(10-1))+2 = 29, 意味 m5.large 的機器上最多只能運行29個不使用 hostnetwork:true 的 Pod。

為了解決這些問題，作者提出了兩個想法，分別是
1. Adding additional IPv4 CIDR blocks to VPC
2. Change VPC CNI to Calico CNI

對這兩個想法有興趣的可以參考原文囉
https://matiaszilli.medium.com/avoiding-ip-consumption-in-amazon-eks-32fc7320253d

Kubernetes 中最基本的運作單元是 Pod，基於 Pod 之上則有各種不同作用的高階抽象層，譬如 DaemonSet, Job, Deployment 等。
使用 Kubernetes 來部署應用程式時，遲早都要面臨資源使用的問題，到底每個 Pod 要使用多少的 CPU/Memory，同時如果是 Deployment 時到底要設定多少個 replica 來符合應用程式的需求。

Kubernetes 提供了 HPA 的方式來水平擴展 Pod 的數量，透過 HPA 的幫助， Pod 的數量可以根據當前的使用情況而自動改變。前述提到除了數量外， CPU 與 Memory 的設定也是一個煩惱的議題，因此就有一個名為 VPA (Vertical Pod Autoscaler) 的專案來處理這個情況，根據當前 Pod 的運行情況來調整 CPU/Memory 的設定(Request/Limit)。

這個專案並非 Kubernetes 的內建資源，必須要額外安裝相關的 CRD 與 Controller 來使用
今天這篇文章針對 VPA 的專案進行詳細的介紹，包括如何安裝，基本架構介紹， VPA 的概念以及使用上的限制都有詳細介紹。

特別要注意的是 VPA 與 HPA 不能同時針對一個 Pod 使用，否則會出現不可預期的行為。這部分也可以理解，畢竟兩個專案並沒有良好的整合，因此兩個 Controller 都會互相一直調整 Pod 行為時，可能會導致不預期的結果。


對於 VPA 這種調整 CPU/Memory (Request/Limut) 專案有興趣的人不仿參考下列文章
https://medium.com/infrastructure-adventures/vertical-pod-autoscaler-deep-dive-limitations-and-real-world-examples-9195f8422724

本文是一篇 2017 年的文章，雖然已經四年之久，但是我認為本篇文章值得一讀。
作者團隊於 2017 年時正在經歷如何將 VM 上的各種 Java 應用程式轉移到 Kubernetes 內的 Container，而本篇文章則是探討到底 Container 是如何透過 Linux Control Group 以及 namespace 實作的，透過對這些底層實作的瞭解，才有辦法針對 Container 效能部分去除錯與提升。

這種文章探討的都是很底層的概念，建議所有人都閱讀一遍，好好複習關於 cgroups/namespace 的概念，透過對這些概念的理解與掌握，能夠更有系統的去解釋何謂Docker Container，何謂輕量級虛擬化。

以下幫大家節錄一些重點，還是推薦自行閱讀全文

1. cgroup 用來隔離與限制 CPU,Memory,Disk,Network Bandwidth 等資源的用量
2. namespace 則是用來限制 ipc, pid, mount ,network, utc 等資訊的可視性，不同 namespace 內看到的資訊是獨立的，但是最終彼此還是屬於同一個 Kernel。
3. 任何沒有被 cgroup 規範的應用程式都會被自動包含到 root cgroup 的規範，不同發行版其位置不同，譬如 /sys/fs/cgropu.

假設今天透過 docker run 去運行一個 java 應用程式
a. Docker 會創建一個 pid namespace，接者運行 Java 前先把該應用程式給掛到新的 pid namespace 上並且賦予該 java 應用程式 PID 1
註: Host 上還是可以觀察到該 Java 應用程式，因為除了 Host 本身外，每個 pid namespace 都有自己的老爸，而老爸是可以看到小孩資訊的，這意味 docker dameon 雖然創建新的 pid namespace，但是host的pid namespace 實際是新 namespace 的老爸
b. 從老爸的視角來看，可以看到該 Java 應用程式也會有一個不同的 PID，而這個 PID 也會於 cgroup 系統中有自己的設定

4. CPU Cgroup 則是會用 share 為單位來定義每個 task 可以獲得多少相對的 CPU 時間，相對的算法是去計算 task 擁有的 share 數量佔了整個 cgroup 階層元件中的多少百分比。
舉例: 捨去其他服務單純考慮運行三個 Container 且有 4 Core CPU 的環境，三個 Container Task 分別給予 2048,1024,1024 share 的話，第一個 Container 大致是會被分配到兩個 CPU Time

5. CPU shares 沒有辦法去保證每個 task 最小用量是多少，所以需要透過 CPU Quotas 的概念來設定 CPU.cfs_quota_us(假設使用 CFS 這個排成演算法)以及 CPU.cfs_period_us(預設100ms)。
概念大概就是 cfs_period_us 定義的時間內，你最小可以使用多少時間，所以假如設定 cfs_quota_us 為 100ms，則預設情況下該 process 可以使用的量就是 100ms/100ms = 1 ~= 1 Core CPU

k8s 與上述的相關bug 可參考下列 issue
https://github.com/kubernetes/kubernetes/issues/67577


6. JVM 看到的是系統上全部的 CPU 資源，但是 Contaienr 本身當被限制 CPU 用量時，會有資訊落差，造成 GC 運行的效果不如預期，因為其認為系統有超多 CPU，而不知道自己其實被限制的CPU很少。

原文滿精彩的，推薦閱讀
https://engineering.squarespace.com/blog/2017/understanding-linux-container-scheduling