今天這篇文章要探討的是如何透過 helmfile 這個專案來管理你的 helm charts，你如果目前是採用 helm charts 來管理 kubernetes 內的應用程式，同時單純使用 helm charts 覺得卡卡的，想要探索更多不同的管理工具，那非常推薦來研究看看 helmfile

# 可能問題
過往使用 Helm 來管理應用程式時，你會需要使用 helm 這個指令來進行管理，不論是安裝，解除，升版，降版，甚至是傳遞不同的參數，這一系列的操作都需要透過 helm 的指令來安裝。
當今天目標叢集內有多個應用程式都需要透過 helm 來處理時，你會怎麼做？

一種可能的做法就是撰寫相關的 script，把所有會用到的 helm 指令都包進來，接下來於 CI/CD 的過程中去呼叫這個 script 來處理

那有沒有一個現成的工具，可以更優雅的幫忙處理這個問題，甚至透過這個方式讓我們也可以採用 Infrastructure as Code 的方式來部署與管理 Helm Charts.

如果你對於這個議題有興趣，可以快速的看看下列原文，原文中用一個簡單的範例去示範如何使用 helmfile 來安裝與管理多個 helm charts.

https://medium.com/swlh/how-to-declaratively-run-helm-charts-using-helmfile-ac78572e6088

今天這篇文章探討的是 Git 的 pre-commit hook 系統，透過這種 pre-commit 的系統，能夠幫助開發者與本地開發時，先行進行一些處理，避免什麼問題都要丟到遠方的 CI/CD pipeline 去檢查。畢竟程式碼更新，觸發 CI/CD 流程，等待結果告知，這部分有時候都要花上數分鐘，往往就是檢查到一個格式錯誤，譬如拼字錯誤，多一個空白，格式錯誤等。

如果今天可以將一些常用的檢查給複製一份到本地端去執行，這樣開發者可以更快地找出錯誤，同時也可以節省很多等待的時間，因此本篇文章就要針對 git pre-commit hook 來介紹。

本篇文章要介紹的並不是直接使用 git 的 pre-commit hook，而是要使用 python 的套件 git pre-commit hook，其龐大的生態系可以幫助使用者輕鬆的使用常見的 yaml 格式來管理 git 本身的 pre-commit hook。舉例來說，可以於專案底下放置一個有下列內容的檔案

repos:
-   repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v3.2.0
    hooks:
    -   id: trailing-whitespace
    -   id: end-of-file-fixer
    -   id: check-yaml
    -   id: check-added-large-files

透過 python 的 pre-commit hook 系統，會將其中描述的四個功能 (trailing-whitespace....check-added-large-files)實際的程式碼給轉換並且安裝到 .git/hooks/pre-commit 底下。

同時透過這種框架，開發者也可以自行開發屬於自己的 pre-commit hook並整合到該 yaml 檔案之中。整個使用的方式非常簡單

1. 透過 python 的方式安裝 git pre-commit 
2. 準備一個名為 .pre-commit-config.yaml 的檔案，並且描述你希望使用的 hook
3. 透過 pre-commit install 的方式將該 yaml 的內容轉換為真正 git 所使用的內容
4. 可以開始透過 git commit 來幫助你進行本地檢查囉

如果對於提升本地開發效率有興趣的人，不要錯過研究看看 git pre-commit 這種機制，不論是直接撰寫 git 或是透過這種 python 的 git pre-commit 框架，只要能夠幫忙解決相關問題，提升效率就會是一個值得研究的方法。
更多的 hook 參考以及該框架介紹，請點選下列全文來觀賞囉
https://towardsdatascience.com/pre-commit-hooks-you-must-know-ff247f5feb7e

今天這篇文章是一個 Jenkins Container 的特殊玩法，作者使用五個連續的 Jenkins Job 來打造一個測試應用程式的環境，期望透過這種機制來打造出一個符合不同程式語言的流水線。

第一個 Job 會先嘗試抓取遠方的程式碼，譬如 GitHub Repo 遠方的 code.
第二個 Job 會根據該專案的程式語言呼叫起不同的 Container 來運行測試環境
第三個 Job 則會根據前述的環境來進行測試，根據結果來判別本次的修改是否正確
後面兩個 Job 主要偏向監控以及通知用的，如果本次修改導致測試失敗，會將 log 訊息以及相關資訊傳送給 admin 告知有工作失敗

註:我個人是覺得與其這樣弄，不然專心讓每個 job 對應一個程式語言，然後使用 Jenkins Job Builder (JJB)來管理這些 Job，這樣每個 Job 的工作也明確也專一，維護起來也方便。
不過文章就是多看也不錯，也許用不到，不過至少可以知道會有人這樣弄，也可以從中反思這樣的優缺點。

https://medium.com/@fmirikar5119/deploying-applications-with-jenkins-container-34fd0348282f

今天這篇文章是一個入門介紹文，跟大家介紹一下 Secret 這個物件。與 ConfigMap 一樣， Secret 也是 Kubernetes 內建的一個特別儲存單元，用法完全與 ConfigMap 類似，但是最大的差異在於其本身的內容必須要透過 base64 進行編碼以及該物件本身會放在 tmpfs 而非真正的檔案系統下。
但是也就是這個編碼以及 Secret 這個名詞很容易讓人搞混，以為把所有的東西都放到 Secret 就安全無誤，實際使用上才會發現這並沒有很安全。
因此本篇介紹完會探討 Secret 的使用方式，以及實務上可以怎麼使用

1. 透過 yaml 這種 declarative 的方式來描述 secret 的內容，這種格式下也有多種用法
a. [removed] tls, docker-registry。
如果你有使用過 imagePullSecrets 這種類型來存取非公開的 contaienr registry 的話，就會需要使用 docker-registry 這種類型來存放相關的存取資訊。

由於上面提到的 base64 都是編碼，並非加密，因此如果有任何加密的需求，請一定要考慮使用不同的解決方案，譬如 Vault, Sealed Secrets, Helm Secrets 等不同的解決方案，千萬不要把 secrets 的內容直接編碼就放到公開的 git repo 上，這樣是完全沒有安全性可言的。


如果對於 secrets 這個物件還不太熟的，可以參考這篇文章看看各種基本用法

https://medium.com/better-programming/how-to-use-kubernetes-secrets-for-storing-sensitive-config-data-f3c5e7d11c15

容器的蓬勃發展使得現在大部分的開發者都一定聽過 docker 甚至是 container 這類型的名詞，但是對於維運人員來說這完全不夠，他們更在意的是如果要將這些容器化的應用程式給部署到生產環境上，要如何面對千變萬化的環境並且能夠處理得妥妥穩穩的。

為了解決這個問題，勢必要有一套容器協同合作方案，能夠處理至少下列四個功能
1. Scheduling: 決定哪些 container 要運行到哪個節點
2. Management: 容器的生命週期該怎麼管理
3. Service Discovery: 不同的容器服務要如何存取彼此
4. Load Balancing: 透過負載平衡的方式來轉發各式各樣的流量

過去百家爭鳴的時代已經慢慢消退，2021 的這天，我想 Kubernetes 是所有人想到這個問題的第一直覺反應。

本篇文章是 2018 年底的文章，作者想要描述到底一個容器協同方案應該長什麼樣子，要提供什麼樣的功能，也許最後其實作與使用方式與 Kubernetes 不盡相同，但是其背後的目的都是一致，希望能夠提供的解決方案讓大家開心的使用容器化的應用程式來面對各式各樣的部署環境。

本篇文章中，作者採用了 Nomad 以及 Consul 來描述這兩個開源解決方案如何組合出一個容器協同平臺，同時簡介了一下這個架構的樣貌以及特色。
透過這兩個解決方案至少達成了 scheduling, service discovery, load balancing 等基本需求

也許現在的你都在使用 Kubernetes 來完成每日所需，但是看看這些不同解決方案的設計與樣貌，也可以幫自己補充一些廣度的知識，讓你可以理解到底這些開源軟體之間的差異

https://medium.com/@obenaus.thomas/how-a-production-ready-container-orchestration-system-could-look-like-6f92b81a3319

Rancher 於 2020 十二月份推出了一個全新的開源專案， Harvester，這個專案主打的目標不同於以往，是個非常特別的領域，所謂的超融合架構 (Hyperconverged Infrastrucuture)。

Harvester 是一個基於 Kubernetes 架構的解決方案，其本身也整合其他開源軟體來提供虛擬化以及儲存這些 HCI(超融合架構) 的基本需求，同時透過其抽象化的介面，讓使用者不太需要理解 kubernetes 也能夠使用這套 Harvester 。

Harvester 底層技術包含了 Kubernetes, KubeVirt 以及 Longhorn, 透過這些的整合來達到上述的虛擬化 (VM+容器)，儲存系統管理。

# 特色
1. Harvester 透過 Multus 這套 CNI 來達成多個 CNI 組合，藉此讓 K8s 裡面的 Pod 都有可以多個網路介面
2. 透過 Longhorn 來達到 scale out 的儲存需求
3. 透過 Kubevirt 來達到 VM 的生命週期管理
4. 透過 MinIO 來管理 VM Image

整套解決方案最後也整合 Rancher 本身的介面，讓你可以透過 K8s 這技術同時管理容器＋虛擬機，如果你過往有玩過 HCI 這個議題的，我認為你可以參考一下，看一下這套解決方案到底怎麼玩，跟過去的經驗有什麼不同

https://rancher.com/blog/2020/announcing-harvester-open-source-hyperconverged-infrastructure-software

#SDN閒談

今天來簡單跟大家科普聊聊所謂的 SDN(Software-Defined Networks) 軟體定義網路的簡單概念，到底其代表什麼，以及在什麼情況下我們需要去理或使用它

SDN 一詞的發展最早可以追朔到 2008 年由 Nick 教授所發表的論文，該論文中設計了一種嶄新的網路協定，稱為 Openflow, 期望透過 Openflow 這種協定來定義該如何傳輸風封包，簡單的說就是「看到什麼樣的內容/標頭，就做什麼事情」。

SDN 的重大核心概念就是透過「軟體」去「定義」你的「網路行為」，系統中會有一個控制器，該控制器透過一種集中化的方式以上帝視角去窺視整個網路拓墣，並基於此架構下去進行網路封包傳輸的設計，譬如「我想要讓符合特定規則的封包可以通過，請幫我設定網路裝置A,B,C,D 來符合我需求」

發展了多個年頭後， Openflow 實際使用上遇到瓶頸，對於純軟體概念來說， OpenFlow 可以使用，但是要將這個精神給套用到硬體交換機上來達到又快速，又彈性的功能時就會遇到挑戰，因此後續又有新的技術誕生，P4(Programming Protocol-Independent Packet Processors)，透過這套技術漂亮的解決過往 Openflow 太過制式化的問題。

SDN 的領域中，也有很多的相關開源專案，從常見的 OpenVswitch, ONOS, OpenDaylight 到 Stratum, SONIC 等都從不同面向來搭建出這樣的網路架構

但是，我自己認為 SDN 就是一個精神，你可以談廣義的 SDN，也可以談狹義的 SDN，有些人會認為 2008 以後所談的概念與技術才有資格稱為 SDN，也有人認為只要我能夠用軟體去控制這些封包傳輸，我就是 SDN，譬如我自己寫一套軟體去大量控管多節點的 iptables 來實現多節點的防火牆設計。
這種情況下，說是「軟體定義網路」也通，只是要如何解讀就是每個人信仰的不同罷了，其實沒有必要爭論誰才是正統，
SDN 就如同 DevOps, CI/CD 等概念一樣，都有一個參考的文化與概念，但是並沒有一定的實作方式，結果論來說就是，整個網路架構如何打造，對於開發者，對於維運者如何使用而已。

從我自己的角度出發，去看待這個產業反而最大的一個議題是，要同時找到會寫程式也有網路概念的人真的很難。
過往仰賴廠商解決方案的人，可能非常熟稔各自的操作模式，譬如各式各樣的 CLI 操作介面。
然而當這一切生態系被打破時，任何人都能夠透過撰寫程式來控管，用你習慣的程式語言來控制整個網路功能，譬如決定什麼樣的封包從哪個網孔出去，修改什麼樣標頭內容，又或是要如何解讀這些封包。要同時擁有寫程式以及網路概念就變得非常困難。

這邊的網路並不是單純大家熟悉的 TCP/IP 而已，實際上有非常多的概念與面向，譬如 Segment Routing, BGP/OSPF, VXLAN/GRE/GTP, VLAN/QINQ, MLAG/Bonding，甚至更複雜的 Broadband (OLT, ONU..), Mobile Core (LTE/5G)... 等 

如果你對於 SDN 這個概念有興趣，非常推薦由 Open Networking Foundation (開放網路基金會) CTO 與他人一同撰寫的電子書，從系統化的角度帶你認識 SDN 的發展，從過去到未來

https://sdn.systemsapproach.org/index.html

今天不聊科技，來聊聊日常工作中的優先度選擇。
作者認為每當你對一件事情說 Yes，其實你就是對其他的事情說 No，因為我們時間有限，不可能每件事情都想要盡善盡美，而那些被你自動說 NO 的事情，其實有些可能反而能夠為你帶來更大的效益。

整篇文章都圍繞於機會成本的概念，探討到底什麼是機會成本，其中顯性機會成本以及隱性機會成本的差異是什麼。

就我個人來看，其實日常工作中也是充滿各種選擇，舉例來說，今天要有一個新的專案要開發，你要負責對其處理 CI/CD 等相關工作，你會怎麼安排自己的 Task ? 這些彼此間的優先順序會怎麼選擇？

也許你腦中會想到有下列的事情要完成

1. 打通 CI/CD 流水線
2. 完善 CI 系統，增加各種檢查，譬如 unit test, linter 或是其他種類
3. 完善 CD 系統，自動上版本，自動更新

但是仔細看會發現，其實(3)這點真的一開始就可以辦到嗎? 需不需要一個手動部署的版本先撐住? 然後根據這些結果再跟(2)去比較，到底開發團隊一開始需要什麼?

其實時間有限的情況下，我們往往都需要進行選擇，困難的是這些選擇永遠都沒有一個標準答案，不同團隊不同環境下，相同選項都會有不同答案。

我個人也滿認同作者提到的概念，時間有限，將精力與時間放到更具有價值的開發與工作上，那些可以展現你個人價值與光芒的工作，未來可能都會是你職涯的推手。
更多的工作團隊中，你的價值是自己帶出來的，而不是別人指派給你的，因此我認為如果你有機會獨當一面去處理一系列的工作，如何展現出你的價值就是一個值得訓練也值得培養的能力與議題

原文：
https://dariusforoux.medium.com/say-no-anything-thats-not-a-priority-9ed70064d0b6

今天這篇文章也是一個入門介紹文，雖說是一個入門介紹文，但是我覺得期主題滿好的，主要是針對 Ingress 這個架構來探討。我個人認為 Kubernetes 的架構加上 Yaml 安裝一切的結果很容易導致大家其實不知道 Kubernetes 做了什麼，也不知道架構到底是什麼，總之 Yaml 寫寫功能就通了。因此如果本來對於 Ingress 背後含義與架構的讀者是可以參考這篇文章重新複習一下對於 Ingress/Ingress Controller 的差異與概念。

Ingress: 其實從抽象層面來看， Ingress 就如同過往使用的 reverse proxy 一樣，根據不同的方式來轉發不同的請求封包到不同的後端服務。然而這個抽象概念於 Kubernetes 被拆分為二，分別為資訊定義端以及真正實作端。

舉例來說，假如我們採用 Nginx 作為 Ingress 的解決方案

資訊定義端(Ingress Yaml Definition): Ingress 的物件描述，也就是大家最常看到的 Ingress Yaml 資源格式，這個格式是由 kubernetes 所定義，本身沒有任何實作功能，完全是一群規則的描述。

真正實作端(Ingress Controller): 負責將 Ingress 物件轉換成 Nginx.conf，並且動態的告知 Nginx 伺服器去載入最新的設定檔案

這也是我們為什麼都要先安裝一個 deployment之類的服務到 k8s 之中，該 deployment 會扮演 Ingress Controller 的角色
接者我們根據需求部署各種 Ingress 規則到系統中，然後先前部署的 Ingress Controller 就會去抓取這些資源，並且轉換成真正可行的 nginx.conf 這種資源

本文使用的是 Kong 這套解決方案，但是整體運作邏輯跟上述提到用 Nginx 的邏輯一樣，因為這邊遵循的都是 k8s Ingress 的運作模式，因此只要搞懂其背後邏輯，未來學習任何一套解決方案的時候，都會有相同的脈絡跟模式可以參考，比較不會瞎子摸象的感覺


原文： https://medium.com/swlh/kubernetes-ingress-simplified-e0b9dc32f9fd

今天這篇文章探討的是 2020 十一月份於美國舉行的線上 Kubeconf & CloudNatvieConf 的一些內容整理，作者整理了五個有趣的議題，分別如下

# Platforms as Product: Self-service is essential
Platforms as Product 這個概念幾乎貫穿了整場 Kubeconf， 其中由 Dave Sudia's 帶來的 keynote 介紹了到底打造一個屬於自己的 k8s 平台會有哪些好處以及有哪些挑戰。
此外，如何打造一個給內部開發人員自治的 k8s 叢集也是一個有趣的議題，當愈來愈多的服務往 k8s 轉移時，對於開發人員來說，需不需要一個 k8s 來使用，這部分到底是由來負責維護與管理等都是一個有趣的問題。
另外最重要還是 Apple 的公開聲明，Kubernetes 的導入是一個進行式，其牽扯的範圍從軟硬開發人員，維運人員到其他如財政相關部門，所有的服務都即將採用 k8s 做為底層架構

video: https://www.youtube.com/watch?v=z3nFTi5-b3A&feature=youtu.be

# Safety and Speed: Move fast and don’t break things
這個類型的議題有非常多，譬如關於部署方面，就有非常多的討論都在探討要如何透過 GitOps 的架構來達到安全且快速的軟體更新。
此外，如何幫 k8s 叢集打造一個強韌且穩固的可觀測性平台也是一個議題，其中由 OpenTelemetry 這個組織所提倡的統一介面也是有諸多的聲浪，雖然該專案還在萌芽發展，但是有興趣的人還是要多關注一下這個專案


另外一個有趣的專案新專案 Troubleshoot.sh 其基於 kubectl plugin 的框架，提供一系列的工具幫助管理人員除錯與管理，最後提到的則是 Telepresence 這套除錯工具。

對於這系列工具有興趣的都可以玩看看

GitOps: https://kccncna20.sched.com/event/ekBA/gitops-is-likely-more-than-you-think-it-is-cornelia-davis-weaveworks

Troubleshoot.sh: https://troubleshoot.sh/
Telepresence: https://www.telepresence.io/


# DevSecOps: Security is a day 0 concern

Security 這個議題一直沒有停燒過，過去的 Kubeconf 就有非常多的討論關於如何強化 kubernetes 相關的安全性，從應用程式，資源管理，叢集本身到整個架構，處處都有安全性的問題需要考慮。

Open Policy Agent (OPA) 是一個非常頻繁出現的專案，透過 OPA 的框架其實可以做到非常多的事情，譬如 network policy 的檢查，相關 YAML 語意的比對，這些功能甚至都可以整合到 CI 的階段中，去幫忙檢查所有 Yaml 的設定是否符合公司的安全準則。

# Multi Cluster: The K8s future is connected

隨者基於 k8s 架設的平台數量愈來愈多，考量到跨國跨區服務等架構時，如何搭建出一個 Multi-Cluster 的 k8s 叢集也是一個炙手可熱的問題。

作者於演講中使用 K8s Initializer 這個工具來搭建一組由 GKE + Docker for Mac 所組合的 multi-cluster 叢集，對這方面有興趣的可以看看下列演講與這個工具。



K8s Initializer: https://app.getambassador.io/initializer/

video: https://kccncna20.sched.com/event/ekD9/multi-cluster-is-easier-than-you-think-with-linkerd-and-ambassador-thomas-rampelberg-buoyant-daniel-bryant-datawire?iframe=no

# End user focus: Learning and telling stories is important

整個 Kubeconf & CloudNativeConf 最大的訴求有兩個
1) 分享使用者的使用經歷
2) 幫助所有剛剛踏入 Cloud Native 的夥伴，讓他們在這條道路上能夠少走冤望路

我自己的觀察也符合這類型的需求，對於一個大型開源專案，很多時候火力展示反而不是最重要的，反而是如何茁壯這個開源社群。針對不熟悉的使用者提供一些方便的學習管道，讓他們更有辦法踏入這個社群，並且享受這些工具帶來的成果。同時透過分享已知的成功案例，讓那些還在思考與猶豫的群體能夠有一個定心丸，願意踏出第一步來嘗試看看 Cloud Natvie。

這場

今天這篇文章是一個教學文章，示範如何透過 Terraform 這套 IaC 知名開源解決方案來操作 AWS 雲端資源，並且透過 Terraform 來創建 Network Load Balancer (NLB)。

如果你本身有在使用 AWS 等雲端服務的話，非常推薦一定要學習 Terraform 這種 IaC 的工具，透過 IaC 這種工具可以帶來非常多的好處，譬如
1. 用程式碼的方式去定義想要的雲端資源
2. 透過版本控制的方式去監管，可以知道誰於什麼時間點進行什麼修改
3. 因為是程式碼定義，可以快速複製與修改

因此這篇文章算是一個入門文章，跟你複習一下如何透過網頁去操作 AWS 來創建 NLB
這種資源，同時將這些概念轉換成 Terraform 的語法，一步一步的帶你去理解與使用 Terraform，因此對於 Terraform 不熟的人可以參考看看


https://medium.com/@sahityamaruvada/setting-up-aws-network-load-balancer-with-terraform-0-12-b87e75992949

今天這篇文章是作者工作多年來，對於 Dockerfile 的一些想法與學習到的經驗，主要內容是講述到底如何最佳化 Dockerfile 的內容，實作上有哪些底可以參考與注意

1. 利用 Cache 的概念來加速建置的時間，最明顯的範例就是 RUN 這個指令，很常看到大家會透過一次 RUN 指令來安裝全部使用的套件，而非每個指令單獨一個 RUN，後者會產生眾多的的 Layer 數量

2. 沒有使用到的套件就不需要安裝，盡量保持精準原則，只安裝必要的相依性套件。這過這些階段可以節省一些 Image 大小，對於未來下載與部署都能夠有一些速度上的提升

3. 採用官方的 image 作為 base image，這部分的安全性會更佳保證，同時內容也會有專門團隊維護。此外 tag 部份也要注意不要使用 latest，最好能夠針對需求去固定版本，以免上游更新後，重新建置的 image 產生出不同的執行結果，這時候除錯也很麻煩

4. 採用 Multi-stage 的方式來建置你的環境，最常見的範例就是將編譯環境與執行環境分開。第一個 Stage 先準備建置環境，安裝相關的工具最後編譯出執行檔案，接者把該檔案複製到第二個 Stage 去單純執行即可

除了這些外，也有些滿常見的概念譬如，能的話盡量透過 USER 去指定使用者，而不是採用 root 的方式直接碾壓過去。

至於要不要使用 Alpine ，這部分見仁見智，畢竟 Alpine 某些版本會有些問題，特別是 Kubernetes 內可能會有 DNS 查詢的問題

我個人是非常討厭精簡化的容器，因為當發生問題想要進去看的時候，連一些工具都沒有，有的連 shell 都沒有，完全不給人除錯用

https://blog.bitsrc.io/best-practices-for-writing-a-dockerfile-68893706c3

今天這篇文章用來介紹 docker 20.10 所帶來的改變，就算 kuberetes 未來不再預設使用 docker 作為其 CRI，但是對於本地開發者來說， docker 還是個短期不太可能淘汰的工具，所以適時的理解最新的一些變化也是不可或缺的一部分

1. Rootless 從過去的實驗性質到全面支援

自從 runc 這個 container runtime 支援 cgroupv2 之後，已經可以透過 rootless 來創造符合 OCI 標準的容器，因此 docker 也可以順便藉由這個過程一併支持 rootless 的環境


2. Logging drivers

過往大家可能比較少會去關注或是修改 docker logging 的輸出方式，比較常見的是直接基於預設的情況去使用，而有部分的解決方案可能會特別修改成 syslog 等不同方式

而 20.10 所做的事情就是強化整體的使用習慣，讓你不管底層是使用何種 logging driver，你都可以透過 docker logs 的方式去閱讀這些資訊

3. OS support
20.10 開始支援 Ubuntu 20.10, Fedora 33 以及 CentOS8

4. CLI improvements

docker CLI 一直持續改進與強化，移除沒用的功能同時也針對一些常見功能加入一些參數，譬如
1. docker push 與 docker pull 的概念一致，預設情況下，如果不給 tag 就會幫忙帶入 latest 進去
2. docker exec 可以透過事先撰寫檔案來一口氣傳入大量的環境變數


https://towardsdatascience.com/whats-new-in-docker-20-10-fd1de1216c0

今天這篇也是一個 Terraform 的入門文章，上次有一篇 Terraform 探討創建 NLB 這樣的 Load Balancer 資源，而這次的入門文章則是更為深入，用一個 wordpress 為一個範例去探討中間要用到的所有元件，包含了

1. 於 AWS 端使用 RDS 服務創建資料庫
2. 於本地透過 minikube 創建一個測試用 kubernetes
3. 於測試用的 kubernetes 部署 deployment/serivce
4. 本地的 kubernetes deployment (wordpress) 會使用 AWS RDS 當作後端資料庫

上述的這一切操作都會全部都過 Terraform 來完成，所以該 Terraform 會一口氣使用兩個 Provider，分別是 AWS 以及 kubernetes
就我個人經驗來看，透過 Terraform 來管理 Kubernetes 的經驗看到的真的不多，大部分還是會用其他的工具如 Helm/Kustomize 來控管部署 Kubernetes。

稍微看了一下 Kubernetes Provider 裡面的內容，發現支援的 resource 類型也不是很多，這樣起來最後很容易就綁手綁腳。所以我個人的經驗還是告訴我，不要用 Terraform 來完全控管 kubernetes 的資源，不然有一天遲早會感受到痛苦

https://apeksh742.medium.com/terraform-to-launch-wordpress-on-k8s-with-aws-rds-database-62fa66cd50ec

今天這篇文章我個人滿喜歡的，整個文章內容就是為了一個主題去探討，到底 Pod 是如何獲得 IP 地址的。

作者開頭闡述了一個常見的情況，就是 Kubernetes 架構龐大，元件複雜，每次談到所謂的網路模型的時候，大家都攘攘上口 CNI, CNI, CNI，但是又有多少人能夠清楚地描述整個 CNI 的運作過程，到底什麼時間點被呼叫，每次的呼叫做了什麼事情。

因此作者特別撰寫了這篇文章，打算從 CRI,CNI 兩個元件去按討，到底一個 Pod 起來到取得 IP 的過程中這些元件會如何互動

為了解釋這個過程，作者分別使用 Containerd 以及 Flannel 作為其 CRI/CNI 的解決方案，從過程中一步一步去解釋到底 Flannel 大概怎麼運作，IP 怎麼取得。

這邊要提醒的是，CNI 玩法百百種，Flannel 的做法是其中一種選擇，其他的 CNI 會有別的方式來設定 IP 地址，但是其源頭如何與 CRI 互動這部分是不會改變的。我認為大家有時間都要好好的看這篇文章，去學習一下到底底層元件的運作原理與流程，都能夠幫助自己更佳理解 Kubernetes 這龐大的怪獸

https://medium.com/cloud-belivers/how-kubernetes-pod-obtains-ip-address-3982ac9697b1

這篇文章探討的是 kubectl 於 1.18 對於 kubectl run/kubectl create 改動所造成的影響，這個影響我認為層面不會太大，但是對於習慣用 kubectl run 的人來是一個滿大的困擾，簡單來說就是移除了一些用法，但是卻沒有任何替代解決方案可以取代。

kubectl v1.18 以前，你有至少三種方法可以部署一個 Deployment 到 Kubernetes 中
1. 撰寫程式並且透過相關函式庫直接戳 kubernetes API server 來創建資源
2. 手動撰寫 YAML 檔案，透過 kubectl apply -f 等類似方式創建
3. 透過 kubectl run (e.g kubectl run nginx-1 --image=nginx --port=80 --restart=Always) 此方式來動態創建一個 deployment.

基於各種維護與管理考量，任何的生產環境都會基於 (1)/(2) 這類型可以控管的方式來部署應用程式，基本上不會使用 (3) 這種方式來創建，但是 (3) 某些情況下滿好用的，譬如

1. 新手測試，想要快速起一個 deployment 測試，但是卻不知道去哪邊找一個 deployment Yaml 的範例(Deployment YAML 本身結構多層，人腦難以記住全貌)
2. 一些 OSS 專案想要提供使用者一些範例去操作，會提供 kubectl run 的指令來創建資源

作者還表示可以將 (2) + (3) 給結合，譬如透過下列方式可以產生一個 YAML 內容
kubectl run nginx-1 --image=nginx:1.14.2 --port=80 \
    --restart=Always -o yaml --dry-run
    
接者透過這個範例去創建與修改來達到 (2) 的做法

不過這一切都隨者 kubectl v1.18 的改變而壞光了，因為 v1.18 後 kubectl run 不再支援 deployment 的創建，退而求其次要求使用者透過 kubectl create 去創建資源，但是其支援的參數比過往還要少，所以沒有辦法透過 kubectl create 取代 kubectl run 的所有用法。

詳細的一些內容與比較可以參閱全文


https://alexellisuk.medium.com/kubernetes-1-18-broke-kubectl-run-heres-what-to-do-about-it-2a88e5fb389a

PR: https://github.com/kubernetes/kubernetes/pull/87077
PR: https://github.com/kubernetes/kubectl/issues/898

今天的文章不是一個技術文，反而是探討身為一個軟體工程師，該怎麼撰寫相關的技術文件

鑑於 WFH (Work From Hoem) 習慣的興起，人與人面對面的溝通減少，這意味即時的訊息傳遞變少了，取而代之的是非同步的訊息傳遞，簡單來說就是技術文件。

好的技術文件能夠讓需要的人快速找到問題，解決疑惑，但是一個好的技術文件到底該怎麼寫，這部分其實非常困難，並不是向程式碼一樣可以 copy&paste 馬上看到成果的，反而是需要時間練習，將整個過程與思路消化起來，用自己習慣的語言與形式將其撰寫出來。

首先，作者非常推崇由 Google 撰寫的系列文章，Tech Writing Course，整個課程內容不到兩小時，從不同章節來跟大家分享如何撰寫技術文章

接者撰寫技術文章時，作者個人是喜歡 divio 這個平台，不過更重要的則是其推薦的分類模式，根據內容分類成四大項

1. Tutorials - 學習導向
2. How-To Guides - 問題解決導向
3. Explanation - 深度理解導向
4. Reference - 資運分享導向

Google: https://developers.google.com/tech-writing
Divio: https://www.divio.com/

最後寫作語法方面，作者認為寫出一個能夠被有效搜尋的文章是非常重要的，譬如透過 word 等方式上傳檔案到系統中反而是一個不利於搜尋的方式。
取而代之的是，作者認為可以採用 Markdown 類似的語法作為基礎去撰寫文章，這種方式對於維護與撰寫都相對容易

今天有任何 Diagrams 的畫圖需求，可以考慮使用 Mermaid 這套解決方案，對於 GitLab/Azure 的使用者來說，已經內建其中。 GitHub/Atlassian Confluence 則有相關的 Plugin 可以安裝使用

最後則是文章的樣版內容，針對特定的文章格式，已經有不少的範本可以參考，透過這些範本可以更清楚的去描述你的內容，讓整體文章看起來更佳簡潔與流暢

1. Software Architecture Review Template
2. Architecture Decision Record Template
3. Incident Postmortem Template
4. DevOps Runbook
5. Decision Template
6. Writing Guidelines
7. OKR Template
8. Etc.

有興趣的點選原文學習更多
https://medium.com/better-programming/best-practices-when-documenting-your-code-for-software-engineers-941f0897aa0

本篇不是一個技術文章，而是一個 DevOps 招募主管的經驗談，隨者 DevOps 需求提升，愈來愈多人開始轉往這個方向。對於作者來說，要如何從茫茫大海中挑到正確的人選其實並不容易。
作者的公司會對所有的招募人員有個第一次的技術訪談，該技術訪談著重的都是一些基本技能，是一些第一天上工可能會用到的知識與能力，譬如 TCP/IP 網路概念， Linux 工具使用，儲存相關概念等。然而另作者感到灰心的是，很多人的履歷寫得洋洋灑灑非常厲害，什麼東西都有碰過都會，但是實際上去問對方該技術是什麼該技術什麼怎麼做，都沒有辦法準確有信心的回答，這樣反而會讓面試官覺得該履歷是個打腫臉充胖子的行為。

因此本文後續作者就整理了一些關於 DevOps 面試的心得與經驗，譬如說

1. 不要造假履歷，履歷上面寫的東西都要能夠精準回答到基本等級，不論是程式語言或是 docker/kubernetes，只要敢寫上去，就要有信心去回答這些問題。
2. 對於所面試職位所需要的技能要真的會，舉例來說面試一個要使用 PostgresQL 的職位，結果連該技術都沒有用過，這樣其實真的會浪費彼此時間
3. 誠實面對所有問題，不知道的問題就勇敢的說不知道，瞎扯淡什麼太多的其實面試官都知道。

原文中還有不少段落，這邊就不一一列出，但是我認為本文真的算滿忠肯的，畢竟現在 CNCF 生態系這麼龐大，很多時候沒有一個扎實的基本功是很難快速地去學習不同領域的技術並且將其整合再一起，更不用說當遇到問題時，該如何除錯了。


https://lukeshaughnessy.medium.com/im-a-devops-hiring-manager-here-s-how-to-crack-my-technical-interviews-part-1-b53885e08655

談到如何包裝與客製化 Kubernetes 應用程式，Helm/Kustomize 我認為是當前最容易被拿來比較的兩大開源專案。
我個人認為這兩者的走向截然不同，光如何客製化就是採取不同的方式，一個主打 Template，一個則是 Template-free，此外 Helm 本身需要額外安裝 CLI 才可以使用，而 Kustomize 目前則是 Kubectl 該指令已經內建，因此使用上也不需要額外安裝任何指令即可

這篇文章是一個 Kustomize 的教學文，主要是用來介紹到底 Kustomize 是如何透過 template-free 的方式讓維運人員可以客製化其部署應用程式，如果本身對於 Kustomize 還不是很熟悉但是又想要理解的，推薦可以快速地看下這篇文章，會對 Kustomize 有個初步理解。


https://pavan1999-kumar.medium.com/introduction-to-kustomize-97f990dc2f44

不知道有多少人曾經想要挖掘過 Kubernetes 的原始碼？
本篇作者跟大家分享其閱讀 Kubernetes source code 的經驗，Kubernetes 基本上大部分的程式碼都是基於 golang 去撰寫的，能夠參透其中其實對於 golang 的一些用法與寫法會有很大的增廣見聞。
無法保證 Kubernetes 的寫法一定是最棒最好，但是我認為多看不同的原始碼，其實對於自己寫程式的能力與想法都是會有所長進。
此外如果已經有一些語言與框架的基礎，對於閱讀這些大型專案的程式碼都會有所幫助，譬如假如你熟悉 COBRA 這個 CLI 的框架，那你看 kubernetes 各種 CMD 都會覺得輕切，覺得閱讀起來輕鬆順手。

總之本篇文章就是作者簡介自己閱讀原始碼過程的經過，比較偏向給初學者探索的，讓初學者有方向可以去探索，一免一開始看到太龐大的專案然後無所適從，或是選擇了一個不會收斂的方向導致閱讀起來很沒有成就感。


https://medium.com/cloudlego/want-to-understand-kubernetes-source-code-this-is-how-you-can-start-exploring-6eea25e50a69

今天這篇是一個關於 Prometheus 的教學文，隨者 Kubernetes 架設與維運的要求日漸提升，可觀測性的重要程度也一直不斷上升，其包含三大面向
Monitoring,Logging 以及 Tracing。
而 Monitoring 中最知名的開源專案組合包就是 Prometheus 以及 Grafana。因此本文作者基於 GitLab Managemend Kubernetes 的前提下，跟大家分享如何創建 Prometheus 相關服務，並且如何把系統上運行的資訊與其整合。

如果本身對於 Prometheus 只有聽過但是還沒有實際玩過的人，不仿可以參考本文學習一下 Prometheus 的概念與想法。

https://medium.com/@thisiskj/lets-explore-prometheus-5f7d790338ac