K8S應用於生產環境 vs. K8s應用於開發環境的4個空想
當容器和K8S的IT管理團隊把本地變更部署在生產環境的時候，往往面對很多要學習的東西。
最近我們澄清了一些大家在進行K8S實驗的時候所面對的常見的誤解。其中最大的一個誤解就是：在生產環境中執行K8S和開發測試環境並無兩樣。
答案：是不一樣的。
Avi Network公司的聯合創始人兼首席技術官Ranga Rajagopalan認為：“對於K8S，容器和微服務來說，實驗環境和生產環境有巨大的不同。簡單的執行和安全，可靠的執行是不一樣的”。
Ranga Rajagopalan的意見中有一個重要的論點：上述問題不僅僅只是存在於K8S，同樣也存在於容器和微服務。部署容器相對簡單；而在生產環境運維和縮放容器（包括容器化的微服務）是問題複雜的原因。
容器和容器的編排工具通常都是成套出現的。New Stack公司之前進行了一項調查，調查發現當組織為了解決運維所面對的挑戰，去尋找更強大的技術的時候，容器反過來推動了K8S的普及。雖然也有其他的工具，K8S還是快速成為了編排工具和選擇的代名詞。像Rajagopalan說的那樣，在沙箱裡執行K8S和在生產環境中執行K8S有巨大的不同。
通常IT專業人士和團隊運維小規模的K8S環境，當這個環境轉向生產環境部署的時候，這些人將有很多東西需要面對和學習。“你肯定想在上生產環境之前掃清這些常見的誤解,這裡有IT領導者和團隊需要了解的知識”。
空想#1:在開發測試環境執行K8S能幫你全面瞭解運維的需求
現實：在開發測試環境執行K8S能幫你走一些捷徑，你可以不必面對生產環境所帶來的運營負載。
Wei Lien Dang， StackRox的產品副總裁認為“開發測試環境和生產環境的最大不同源自於運維和安全，在運維測試環境你根本不用在乎叢集宕機。
Portworx的聯合創始人兼CEO Murli Thirumale將開發測試環境和生產環境的不同與敏捷和可靠，高效能的敏捷做了類比。
“開發團隊的目標是在開發和測試新應用和程式碼的時候實現應用的敏捷；而同時運維人員的目標是應用和資料的可靠性，可伸縮性，安全性和效能。後者需要一個強大的，企業級的，經過測試和驗證的平臺。
自動化已經成為了在生產環境中採用K8S（或者通俗所說的容器）的迫切需求。
Coda Global的架構師Ranjan Bhagitrathan認為“生產叢集必須通過自動化部署。生產叢集一定要具備可複製性，從而實現整體生產環境的一致性，同時可複製性也對災難恢復有所幫助”。
Bhagitrathan同時也認為版本控制對生產環境運維至關重要，“對所有事情進行版本控制，比如服務部署的配置檔案，策略等等，如果可能也包括實現基礎架構即程式碼的程式碼命令。這能確保你的環境是相同的。同時也要確保容器映象有版本控制，不要只是用“最新映象”這樣的名字來個映象打標籤，這樣很容易引起混亂。
空想#2：你已經得到了可靠性和安全性
現實：如果你只在非生產環境試驗過K8S。你可能沒獲得可靠性和安全性，或者目前沒有。
好訊息是你最終會做到，因為上生產環境之前，需要做規劃和架構設計。
AquaSecurity的聯合創始人兼 CTO Amir Jerbi認為“很顯然，在生產環境，效能，可伸縮性，高可用性和安全性方面所面對的挑戰更嚴峻。所以在架構階段規劃生產環境需求，並且把安全，伸縮控制，Helm charts整合在K8S部署的定義中是極為重要的”
Dang分享了一個測試開發環境如何導致過度自信的例子：
“開放所有的網路埠在測試開發環境中是非常不錯的，很可能所有的服務都能互相連線。K8S預設設定所有網路連線開放。但這不是一個成熟生產環境所應有的設定，一旦步入生產階段，停機和大規模攻擊會給業務帶來風險“。
“當工作轉移到容器和微服務的時候，構建高可靠，高可用的系統是非常有價值的工作。編排工具幫你實現這部分工作，但這並不舉手可得。安全性也是一樣。”
“我們要做很多事情來減少針對K8S的攻擊，通過加強網路策略來實施最低許可權模型，並且限制服務只和需要的服務連線是非常關鍵的。”
在生產環境中，容器映象的安全漏洞可以很快變的很嚴重，威脅可能是受限的或者根本不在本地。
（whereas the threat may be limited or non-existent locally.）
Bhagirathan說，“要注意你的容器映象採用的基礎映象是什麼，儘可能用受信任的官方映象或者自己動手製作。用未知的映象也許可以幫你很快的跑起服務，但也帶來了安全問題。比如，你肯定不想你的K8S系統給別人挖比特幣做貢獻。”
紅帽公司的安全策略師 Kirsten Newcomer 鼓勵人們通過10個層次來考慮容器安全- 包括容器堆疊層（比如容器主機和註冊），容器生命週期（API管理）。有關10層的細節資訊以及如何應用在K8S這樣的容器編排工具，請參閱Newcomer的播客或者白皮書ofollow,noindex" target="_blank">https://www.redhat.com/en/enga ... yaAAA
空想#3編排工具讓縮放變得易如反掌
事實：雖然很多軟體專業人士都認為K8S這樣的容器編排引擎對於容器擴充套件性來說是必不可少的，但是認為編排工具能立即讓縮放變得簡單是錯誤的，特別是當你第一次在生產環境中使用它。
Sumo Logic公司的高階技術產品經理 Frank Reno認為“自動縮放改變了一切，資料越來越大，你的監控系統需要根據資料量來擴充套件。在執行成產環境之前，K8S的所有元件都不能被很好的瞭解。畢竟確保K8S系統的健康執行，API伺服器和其他控制組件能根據需求縮放不是自動的。
開發和測試環境讓事情變得過於簡單，而真正的環境需要這樣，或那樣的需求，並且需要一直維護。
“在開發測試環境可以非常簡單跳過一些基礎設定，比如確保你能用到特定的資源，並且限制請求”Reno說，“如果在生產環境不這樣設定，你的好日子就算到頭了”
向上或向下擴充套件群集是一個很好的例子，當你在本地進行實驗時，它可能看起來很簡單，但在生產環境中縮放變得明顯更具挑戰性。
“生產叢集，與開發或模擬叢集相反，在擴充套件方面遇到更多的痛點，” WhiteSource的執行長Rami Sass說。 “儘管應用程式的橫向擴充套件在Kubernetes中非常簡單，但DevOps [團隊]還需要考慮其它方面，特別是保持服務線上的同時擴充套件基礎架構。 重要的是確保主要服務，負責漏洞和安全的報警系統分佈在群集的節點上，並使之有狀態，這樣在向下擴充套件時不會丟失任何資料。“
和其它挑戰一樣，這是合理規劃和利用資源的問題。
“瞭解你的縮放需求，為它們做計劃，更重要的是：做測試！” Coda Global公司的Bhagirathan提出了建議。“你的生產環境應該能承擔更高的負荷”
空想#4: K8S在哪執行都沒區別
現實：正如同在開發人員的筆記本上執行K8S和生產環境中執行K8S有區別一樣，環境會導致差別。
一個常見的誤解是（假設）Kubernetes在本地執行正常，那麼它可以在任何地方正常工作，”Bitnami的執行長兼聯合創始人Daniel Lopez說道，他用雲平臺之間的差異來應證這個假設的是錯誤的。 “雖然Kubernetes如果能夠有效地提供一致的環境，但供應商之間仍存在顯著差異 。
Lopez還指出，生產環境的部署需要那些不只作用於本地的元件，比如監控，日誌和證書管理，以及憑據。你需要考慮這些因素，這也是導致開發/測試和生產環境之間差距擴大的關鍵問題之一。
這也是綜合性問題，不僅K8S需要考慮,也包括容器和微服務，更廣泛的來說，在混合雲和多雲環境也需要考慮。
“公共 - 私有部署比紙面上看起來更棘手，因為許多必要的服務，如負載平衡和防火牆，都是專有的。 在實驗室中執行良好的容器在具有不同工具的雲環境中執行可能根本不工作 - 或者至少不安全 -，“Avi Networks的Rajagopalan說。 “這就是為什麼像Istio這樣的服務網格技術受到如此多關注的原因。 不管容器執行在哪，他們都提供相同的應用程式服務，因此你不必考慮基礎架構 - 這是容器最重要的一點“。