今天這篇文章是個基礎介紹文，跟大家介紹一下 Kubernetes 裡面的 Job，不同於 Pod 這種屬於 daemon 的運算資源， Kubernetes 提供了 Job 以及 CronJob 這種一次性的運算資源。 

Job 以及 CronJob 差異就是什麼時候該執行，Job 就如同其他資源一樣，創建到 Kubernetes 內後就會開始執行，而 CronJob 則是可以制定一個時間點，去定期反覆的執行

雖說 Job 是一次性的工作流程，但是對於 Kubernetes 來說，最小的工作資源就是 Pod，所有更高階的抽象資源都是基於 Pod 配上不同的 Controller 來完成。
Job 的設計也是如此，最終運行勢必是叫起一個 Pod 來幫忙運行，但是 Job 則會期望該 Pod 最後可以進入 Completed 的狀態。

什麼情況下我們可能會使用 Job 而非其他資源如 deployment/daemonset/statefulset ?
譬如說一個 AI 的模型訓練，一次物件的偵測 甚至是一些系統資源的檢查與清除，這類型的工作都可以考慮用 Job。而那些 Server 類型需要長時間存活的服務則應該使用其他高階類型的資源來部署。

原文算是非常清楚的介紹 Job 的使用，包含了諸如 backofflimit, parallelism, activedeadlineseconds 等參數的含義，並且也有透過實際的範例來展示怎麼使用。

如果對於 Job 這種物件不熟系的，可以參考一下原文來學習一下怎麼使用
https://levelup.gitconnected.com/understanding-jobs-in-kubernetes-541614ccd796

文章開頭借用了日文的 Poka-Yokes 來分享有哪一些準則或是技巧可以讓你打造一個具 Mistake-Proof 的 Terraform 程式。

文章內列舉了四個準則，這邊簡單列舉了一下每個準則的概念，詳細資訊可以閱讀全文

# Rule 1: Use Terraform Modules to abstract specific pieces of infrastructure into logical groupings
1. 針對需求與架構去拆分你的 Terraform Module，舉例來說，創建一個名為 ECS Service 的 Module，而該 Modules 內其實會創建如 ECS, autoscaling target, metrics 等諸多資源。也正式這些資源相互合作才真正的搭建出 ECS 的服務
2. 上層的應用接下來都會以 ECS 服務為考量去使用，本身不需要去考慮太多底層創建的資源，透過變數的方式來讓不同的呼叫者有不同的 EC 服務


# Rule 2: Use Terraform Data calls to provide information
1. 人類其實很容易犯錯，特別是一些反覆執行的工作。但是電腦非常擅長這類型的工作
2. 相對於要求使用者或是開發者維護各類資源的 ID 或是資訊，更好的做法是利用 Terraform 內的 data 功能，主動地從遠方抓取這些資訊，並且搭配 filter 來過濾不必要的資訊。


# Rule 3: Be Smart About Where Interpolation and Concatenation Happens
- 創建應用時，很容易透過 Copy/Paste 等方式來創建相關資源，這時候就要特別注意資源的名稱是否有重複，是否忘了修改
- 透過變數的方式幫資源命名，但是要注意如果你今天想要修改命名的規則，每個有用到該資源的檔案都要去修改
- 有使用 Module 的話，可以考慮於 Module 呼叫時去組合相關名稱，而不是 Module 內組合。

# Rule 4: Implement State Locking for Ease of Deployments
- Lock 非常重要，透過 lock 機制我們可以避免同時有多個更新造成狀態不一致


有興趣的可以點選連結來觀看全文
原文: https://medium.com/capital-one-tech/terraform-poka-yokes-writing-effective-scalable-dynamic-and-error-resistant-terraform-dcbd6a0ada6a

本篇文章是個入門介紹文，主要探討 Liveness 以及 Readiness 這兩個非常實用且重要的觀念。
由於這兩個元件並不是一個基本 Pod 所要的基本元素，所以如果沒有特別研究與使用時，可能也不清楚原來還有這兩種不同的探針可以幫忙我們更友善與彈性的去管理 Pod，準確來說更是 Container 的行為。

過往我們在運行一些應用程式的時候，可能都會有所謂的暖身期，應用程式起來到真正可以提供服務中間會有一些初始化的過程要跑，可能需要幾秒，甚至到一分鐘都有可能。

但是當應用程式給容器化後，對於最上層的管理平台來說，如果我今天只用 Continaer 是否叫起來 當作該應用程式的狀態，實際上遠遠不夠的，就如同上述提到的，會有一些初始化等暖身時間需要等待，而這兩個探針就是從不同角度去幫忙輔助，讓 Kubernetes 有更多方式去判別到底當前 Container 是否已經準備就緒，是否可以認定已經是運行狀態甚至可以接受網路流量

如果對這兩個概念還不熟的，可以參考原文搭配一些範例學習一下

https://devops4solutions.medium.com/kubernetes-pod-health-check-liveness-and-readiness-probe-1118a265c193

今天這篇文章是作者過去三年多來維護 kubernetes 叢集下的經驗談，作為一個每天維護 400 台以上機器，超過 20 多個 Kubernetes 叢集的管理人員，要如何有效率的去控管與查看不同叢集，不同 namespace 則是一個值得注意的議題

作為一個 kubectl 工具愛好者，作者整理了自己使用的四個小技巧來幫助自己每天有效率的去管理多個 kubernetes 叢集。

1. 善用其他 log 工具來同時監控多個 pod
如果常用 kubectl logs 的人不知道有沒有過下列經驗，(1)每次要觀看特定一個 pod 的時候都要用滑鼠去複製貼上那些充滿亂數的名稱，(2)想要同時監控多個 Pod，也許這些 Pod 也不屬於同樣的 deployment，(3) 有時候根本記不得這些 pod 有哪些 label 可以用，所以還是採用最預設的參數使用

如果有這些問題的可以考慮使用看看一些針對 log 的解決方案，不論是本篇文章提到的 kubetail, 或是其他的方案如 stern, kail 等，都可以嘗試使用看看

2. 提供一個動態方式去修改預設的 namespace 而不是每次指令都要一直不停的輸入 "-n"
當今天已經很明確接下來的指令操作都會固定於某個 namespace 內來管理時，可以直接切換預設的 namespace，這樣操作上可以很下一些時間，同時也可以避免中間有任何指令不小心忘了輸入 namespace 導致不預期的操作

3. 修改 shell 讓其顯示必要資訊
這也是我非常推崇且自己一直都有使用的方式，透過修改 shell prompt 的方式讓其告知當前使用的 context 以及 namespace 是誰

如果你本身有管理多個 Cloud Provider 帳戶的，我認為也可以透過這種方式來幫忙提醒自己

4. 將常用的指令透過 alias 的方式給縮寫
透過此方式可以減少打字的時間，同時指令愈長，不小心打錯的機會也就愈高

整體而言就是，想盡辦法讓自己工作更有效率，能省則省，同時也要尋找一些機制降低錯誤發生率。

https://medium.com/better-programming/4-simple-kubernetes-terminal-customizations-to-boost-your-productivity-deda60a19924

「I will always choose a lazy person to do a difficult job because a lazy person will find an easy way to do it. Frank B. Gilbreth Sr.」

如果可以，誰不想更輕鬆的完成工作

今天分享的這篇文章是作者從自己過去的工作經驗擷取出來一些關於自動化的思維，畢竟人本來就不擅長反覆執行工作，還容易因為粗心，恍神等造成差錯。這是電腦相反，其非常適合處理這種枯燥且反覆的工作。

作者認為作為一個開發者，我們必須要先理解與釐清，日常生活中，到底有哪些事項與流程是有機會自動化的，有機會讓電腦幫我們完成。

文章內，作者分享了四個他覺得值得自動化處理的流程，當然這些只是冰山一角，做重要的還是自己能否從中擷取有用的知識與概念，並且套用到自己的團隊與日常生活中，透過這些自動化的處理，讓自己能夠更專心的處理更重要的工作，而這些重複且瑣碎的事項就讓電腦來幫忙吧

作者列舉了四個自動化的範例，詳細內容可以參考全文
1. Code Style Checks
2. Automation on GitHub
3. Localization Integration
4. Deployment Pipeline


https://medium.com/dev-genius/4-automation-ideas-for-developers-5e0985fd83b9

本篇文章探討的是 Terraform 12.20 所推出的兩個新功能， can() 以及 try()，來聊聊這兩個新功能對於開發者來說能夠帶來什麼樣的效益

can 這個功能主要是用在變數的簡單測試，譬如幫你確認變數的數值是否符合預期，這邊也可以搭配 regex 這種正規表達式的方式來幫你驗證輸入值是否符合規範。

try 這個功能目前使用起來跟大家寫程式所習慣的 try/catch 有點類似， try 之中要傳入一系列的參數，然後 try 會回傳第一個沒有發生錯誤的參數。因此如果今天有一些資料處理比較複雜的部分，可以考慮使用 try 來幫忙驗證。
舉例來說，今天需要透過 yamldecode/jsondecode 的方式來處理一些動態資料，我們可以撰寫類似下列的程式碼

locals {
  raw_value = yamldecode(file("${path.module}/example.yaml"))
  normalized_value = {
    name   = tostring(try(local.raw_value.name, null))
    groups = try(local.raw_value.groups, [])
  }
}

來幫忙判斷到底該資料有沒有成功抓取並且解析，此外我們也可以透過 try 的方式來達到一些變數的兼容性。
譬如說我希望當某個變數是字串時，回傳一個長度是一的陣列，當變數是一個陣列時，直接回傳一個陣列。 參考用法如下

locals {
  example = try(
    [tostring(var.example)],
    tolist(var.example),
  )
}


點選下列文章或是官方文件來學習更多！

https://levelup.gitconnected.com/using-terraforms-try-can-and-input-validation-eb45037af2b2

今天這篇文章要探討的是如何透過 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