前言
好的，所以我知道這不是新技術，但是它似乎在K8s領域正在積聚很多動力，環顧四周，當我剛開始工作時，並沒有很多"基本"文檔。
經過大量的抓耳撓腮，閱讀，更多的抓耳撓腮，YouTube視頻，甚至更多的抓耳撓腮……我終於有了頓悟的時刻，這一切對我來說都變得很有意義。 因此，我想寫這篇博客文章是為了減輕人們的痛苦。
什麼是運算符？
好了，讓我們從頭開始，我想您到閱讀本文的原因是：
- 您正在從事一個涉及Kubernetes的項目
- 有人提到過許多Kubernetes流行語之一（controller控制器，operator操作員，CRD，group組或種類）
- 有人隨機說："如果Kubernetes可以為我自動化這件事，那不是很好嗎？"
- 您已經閱讀了有關Operator的資料，並坐在那裡像" WTF？！？！？！"
it's enough to make you cry
好吧，不用擔心，隨時可以獲得幫助！
我們可以將運算符視為邏輯的捆綁單元，它在Kubernetes中執行一些複雜的業務邏輯。
好的，很好，但這是非常抽象的。
事實是，我們可能已經與Kubernetes運營商打過交道，我們只是不知道：
<code>kubectl get pods/<code>
在非常抽象的級別上，上面的命令使用默認的K8s運算符之一，"Pod"運算符，而我們正在執行的操作數是"get" 操作。
而且，如果我們要創建或刪除新的Pod，我們也可以為這些任務提供運算符Operator。 我們只需要知道如何使用它們，以及何時使用它們。 我們不需要知道Kubernetes是如何創建Pod的，也不需要知道如何獲取Pod的信息，這就是我們不在乎的K8s級別的業務邏輯。 但是我們關心的是，一旦我們有一個Pod和在該Pod上運行的服務，Kubernetes將對其進行監視，並在它出現問題並終止時重新創建它。
但是Kubernetes已經為我做了所有這一切嗎？
好的，所以我們有我們的定義，但是現在您坐在那裡，對自己進行思考："無論如何，Kubernetes已經為我做了所有這些事情……當Pod掛了而我沒有做任何事情時，它會自動縮放並啟動新資源？ 我為什麼要在乎？"
您是正確的，它確實做到了這些事情，即使您不必考慮使用運算符，也可以實現9/10倍的工作。 但是事情變得有趣的地方是，您必須開始考慮狀態！
無狀態很容易； 有狀態很難
讓我們舉一個非常非常簡單的非技術示例：
您坐在餐廳裡，服務員走過來，接您的訂單，並以他無窮的智慧決定不寫下您的訂單，而是將其記入內存，然後再下令將訂單交給廚房。
問：如果那個服務員在去廚房的途中突然摔死，會發生什麼？？？
A.在Kubernetes供電的餐廳裡，我們不必擔心，因為控制器只會製造另一個看上去和最後一個完全一樣的服務員……但是，哦，等等……我們有一個新的服務員，但是我們發生了什麼事，訂單？ 它和第一個服務員一起死了！
現在，這是一個非常人為的示例，但是…這是我的頓悟時刻：
Operator實質上是一種使我們能夠為Kubernetes提供更多特定於域的方式來執行復雜任務的方式，而不僅僅是其默認的"替代已死的事物"方法。
DevOps就是DevOps
容器向我們承諾了一種更好的滾動部署和運行應用程序的簡便方法。 並在很大程度上實現了這一目標。 我們可以使用Web應用程序創建一個容器，使用NGINX創建一個容器，並使用Redis實例創建一個容器，將它們全部放到K8s服務中，通過一個不錯的YAML進行部署，並且可以立即啟動並運行它們。 如果我們丟失了緩存，NGINX或我們的應用程序，我們就可以放心，因為它很快就會回來，並會根據需要擴展等。
但是，我們的應用程序中更復雜的部分呢？ 那我們的數據庫呢？
好吧……我們當然可以創建一個帶有我們數據庫鏡像的容器，準備將其部署到Kubernetes中，但是我們如何：
- 將多個數據庫實例配置為主從配置？
- 設置我們的複製作業？
- 安排我們的備份？
好的，這可能有點麻煩，但是讓我們採用另一種方法。 如果我們想擴展一些雲基礎架構作為服務的一部分怎麼辦？ 像Azure ServiceBus一樣？
- 我們甚至怎麼可能將服務總線集裝箱化？
- 我們如何配置和擴展ServiceBus？
這就是容器解決我們所有DevOps問題的承諾真正開始出現問題的地方。
要Operator還是不要……這是個問題
現在，我想退後一步，承認我個人對Operator仍然有不同的感覺，還有一個問題似乎仍在我腦海中浮現：
僅僅因為我可以寫一個Operator來自動化和管理某些東西。 這意味著我應該嗎？
免責聲明時間：我是Terraform的忠實擁護者，說實話，我認為在很長的一段時間內，對於DevOps來說這可能是最好的事情。 對我來說，架構是可以生存和發展的代碼，可以進行協作和審查。
我只需運行腳本即可啟動，修改和拆除複雜的基礎架構項目。
現在，我還可以將所有這些轉換為運算符； 說我寫了一個CosmosDB的Operator和ServiceBus等Operator，這在維護方面有很多開銷。 Terraform擁有一個蓬勃發展的社區，它使我能夠利用經驗豐富的，經驗豐富的提供商為我服務。
但是，另一方面，想象一下一個世界，每個Operator都已經被編寫並且可以完美地工作，並且具有與Terraform相同的支持和配置可能性……一個.yaml文件，一個kubectl命令，然後有了它，我們非常複雜的應用程序體系結構可以自動部署。 我們的告警電話永遠不會響，永遠不會有任何有關規模或容量的警報，因為我們知道Kubernetes正在為我們完成所有艱苦的工作，因此感到安全：
……現在，這將不是一個可愛的DevOps世界嗎？
(本文翻譯自C:\\Dave\\Storey的文章《Kubernetes Operators for beginners》，參考：https://medium.com/@stoz_das/kubernetes-operators-for-beginners-8f53ead07097)
閱讀更多 聞數起舞 的文章
