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