關於 shell script operator ，我們在網路上蒐集到這些相關的討論、資訊與評價

今天這篇是一個 Operator 的介紹文，該文分成三大部分，分別是 What, Why 以及 How

如果你本身對於 Operator 的概念還不是很熟悉的，會非常推薦閱讀這篇文章，幫助你從頭瞭解到底什麼是 Operator，其背後的實作原理以及我們可以透過 Opeator 做什麼事情，對於維運團隊能夠帶來什麼好處

# What
1. Operator 這個詞是由 CoreOS 工程師於 2016 提出的，目的是希望簡化應用程式的管理，特別是 Stateful 類型的
2. Operator 背後是一個 Controller，該 Controller 會根據當前應用程式的狀態而自動地進行一系列的處理，譬如創建，刪除，管理等各式各樣資源，當然這些操作都是基於 Kubernetes API 完成
3. 根據目前官方 (kubernetes.io) 的說明，要理解 Operator 就會需要理解兩個概念，分別是 CRD (Custom Resource Definition) 以及 Control-Loop
4. CRD 提供一個方式讓開發者能夠定義屬於自己的 resource，包含了 apiversion, kind 等欄位。舉例來說，你可以自己定義一個跟 Pod 幾乎完全一樣的資源，然後擴充或是減少一些欄位

# Why
1. Kubernetes 內建的機制與資源對於是非常適合於無狀態應用程式(Stateless)的，這些資源足夠滿足無狀態應用程式的需求，譬如自動擴展數量，提供流量的負載平衡
2. 但是當 Kubernetes 的應用場景愈來愈多， Stateful 應用程式的需求就出現了，這時候原生的機制就稍嫌不足，使用起來不夠順暢。
3. 透過 Operator 的概念 (CRD + Control-Loop)，使用 CRD 來定義你的資源狀態，並且透過 Controller 來幫你維護你的運作邏輯，譬如什麼時候該產生/刪除 Pod，什麼時候該創立/刪除其他資源，這些邏輯的實現都隱藏到 Controller 之中，但是同時也透過 CRD 提供一些介面參數讓開發者與維運者有能力對其進行一些調整

# How
1. 如何撰寫一個 Operator，有一些現成的工具可以幫忙，譬如 Kudo, Operator SDK, Kubebuilder 等
2. 有興趣觀看這些工具的介紹與使用，可以看全文

# Operator 的必要性

1. 2020 北美 Kubecon 上有非常多關於 Operator 的討論，作者特別提出由 HashiCorp 所分享的議程 Stop Writing Operators ，並且針對幾點來討論
2. 如果你的自動化是一個每個月執行10分鐘這種工作，那花上數週來維護與撰寫這種自動化其實非常不值得
3. 實際上開發一個 Operator 會遇到滿多問題，即使你使用 Kubebuilder 等這類型工具也還是會有很多小問題
4. 如果能的話，作者覺得有時候寫一些醜陋的 shell script 會比客製化各式各樣的 operator 還來得好。

https://medium.com/swlh/kubernetes-operator-for-beginners-what-why-how-21b23f0cb9b1

今天這篇文章的內容比較主觀，是作者列出自己認為 DevOps/SRE 2021 需要注意的工具

1. Managing Cloud Services via Kubernetes CRDs.
三大公有雲廠商目前也都推出透過 CRD 的方式來管理 Cloud Services，譬如 AWS Controllers for Kubernetes, Azure Service Operator, GCP Config Connector。一旦這些工具逐漸成熟，管理人員可以使用管理 kubernetes 的方式一併來管理相關的雲端資源。

個人看法:目前大家習慣用 Terraform, Ansible 等 IaC 等工具來管理，如果往這個方向走去，等於就是逐漸使用一個方式去管理一切。
此外也滿好奇最初的 Kubernetes Service Catalog 搭配 Broker 的方式其實也已經可以用 Yaml 等方式來管理雲端資源了，沒有仔細看 Service Catalog 目前的發展狀況，這兩者的差異有哪些

2. Pulumi
Terraform 作為 IaC 工具的龍頭老大勢必會有挑戰者對其虎視眈眈， Pulumi 這家公司就是挑戰者之一，該公司的產品提供的 IaC 工具能夠採用常見的程式語言來撰寫，避免所有開發者都要額外學習全新的 DSL。此外 Pulumi 今年度也有推出自己的 GitOps 相關工具，不過儘管如此，目前其使用社群都還是不及 Terraform.

個人看法: 當 CDK + Terraform 整合逐漸穩定後， Pulumi 的特色就會減少一項，這場戰爭目前還是看好 Terraform

3. Terragrunt & TFSEC
Terraform 因為其開放原始碼社群的緣故，有愈來愈多的整合工具來幫忙 Terraform 去處理不同的議題，這種合作模式會讓 Terraform 的功能愈來愈強大。 Terrafrunt 則是一個用來管理大型 Terraform 專案的好工具，能夠幫助開發者更友善的管理眾多設定檔案。此外 TFSEC 則是一個針對安全性議題的整合工具，幫助開發者透過靜態分析的方式去檢查當前 Terraform 的內容是否會有潛在的安全性問題。隨者 DevSecOps 的概念慢慢出來，開發與維運者也要多注重些關於安全性的整合工具。

4. Tekton
CI/CD 市場上能夠選擇的工具實在太多，而 Tekton 則是一個基於 Kubernetes 的 CI/CD pipeline 系統，相對於大部分的系統是透過單一 Yaml 去描述 Pipelin， Tekton 則是透過 CRD 的方式於去定義每個 Stage，其帶來的好處就是相同的 stage 可以重複利用，不需要針對每個 pipeline 都去重新設計

個人看法: Tekton 的架構有好有壞，隨者所有的 stage 都變成單一小CRD，管理者想要一目瞭然整個 pipeline 變得非常繁瑣，使用上也常搭配 JenkinsX 來提供複雜的 CI/CD 功能

5. Trivy
如同前面提過，DevSecOps 的概念出來後，任何部分都要去考慮安全性，而 Container Image 本身也是個不容忽視的地方。因此也有不少的開源專案針對 Container Image 來進行掃描與偵測。有些 Contianer Image Registry 直接整合相關的掃描工具，自動掃描所有更新的 Image 並且提供報告給管理人員。 掃描工具諸如 Trivy, Falco, Clair, Anchore Engine 等都值得大家多多注意。

6. ShellCheck
儘管現在有愈來愈多的工具幫助開發者來管理整個叢集，然而 shell script 的定位還是不可動搖，太多時候我們還是需要自行撰寫相關的 shell scrtip 來完成一些任務。 ShellCheck 則是一個針對 shll script 的靜態分析工具，透過 lint 與常見錯誤等分析，讓開發者能夠寫出有更好品質且更好維護的 shell script.

7. Litmus
2011 Netflix 提出 Chaos Monkey 這類型的環境檢測工具，這方面的議題就沒有減少過，即是到了充滿 Kubernetes 的今日，還是有不少的開源專案或是商業平台在提供這方面的服務，譬如 chaoskube, kube-monkey, PowerfulSeal 以及 Gremlin.
作者這邊想要強調另外一套更容易使用且容易擴充的專案 Litmus，該專案基於 Kubernetes Operator 的概念去開發，透過 ChaosEngine, ChaosExperiment 以及 ChaosResult

原文: https://medium.com/dev-genius/technologies-tools-to-watch-in-2021-a216dfc30f25