導讀web
現在，愈來愈多的企業已經採用了Kubernetes，它讓企業可以自由選擇他們所須要的應用，而且能夠運行在任何基礎架構上。可是大多數企業尚未充分認識到的是：該如何制定一種即合規又可靠的方式的管理方式，該如何管理雲平臺中的數據？該如何平衡團隊的需求？又該如何打造一支敏捷又負責的團隊？數據庫
本文將分析當前企業在採用和部署新技術過程當中所遇到的挑戰，咱們也將提供一個藍圖，協助您發展示有的管理模式，賦能全部IT人員。安全
第一章：技術的自由：多少纔算合適？微信
在大規模業務增加及創新的背後，是數以百計的新型技術服務，這些服務多是由雲原生領域提供的。每隔幾個月，就會有新的開源項目、數據庫和開發者工具出爐，驅動着史無前例的創新。網絡
各類各樣的團隊都在挖掘新方法來利用Kubernetes ，他們正在搭建一個普遍的集羣來實現其想法。但遺憾的是，這反而會引起諸多的矛盾，管理一個獨立的Kubernetes集羣已實屬不易，而若是要在多個雲上管理多個Kubernetes集羣，更是難上加難。此外，伴隨着您所運維的企業環境中集羣的數量在不斷增長，其複雜程度極可能會使您沒法取得成功。架構
缺少可視性和管理app
組織內的各個部門都須要新的Kubernetes集羣，而且訴求也是各不相同，好比不一樣的版本，不一樣的IaaS上面。舉例來講，團隊須要搭建雲廠商A的技術棧，此外已有一個雲廠商B的技術棧，在邊緣或數據中心中還有第三個技術棧。隨着集羣和工做負載的數量不斷增長，在各個環境中也成倍增加，這對運維管理者提出了巨大的挑戰·。框架
「開發者經常一會兒引進不少新的技術棧。」D2iQ的聯合CEO Tobi Knaup說，「因此，企業很快就發現他們有10到15種不一樣的方法來配置基礎架構，而後，負責運維的團隊老是後知後覺的。」運維
運維者須要有統一的工具來管理用戶界面，並造成標準化管理流程，以得到基礎架構的洞察以及完善的問題問題響應機制。若是缺乏中央式的監控視角，沒法快速洞見全部集羣的狀態，，當出現問題時，好比某個集羣崩潰了，首先，運維人員沒法第一時間得到問題，其次，運維人員還沒法輕鬆地得到問題相關的診斷信息，這些都會形成內耗。此外，運維人員也沒法經過持續監控改善資源的利用率。若是有不少種潛在的軟件版本在使用，那組織就基本不可能管理它們。全部的這些問題最終都會致使性能的不一致、可靠性下降、安全風險增長，以及開發和維護成本上升。分佈式
運維的複雜性和行政成本
身份和訪問管理是不少應用的關鍵構件。不過，當不少團隊都開始嘗試部署普遍的集羣集時，如何進行認證證書、資源共享和安全性管理會給帶來更大的挑戰。
讓咱們以酒店爲例來理解Kubernetes的多租戶。在一個酒店中，禮賓人員須要將全部的客人和他們的活動都引導至相應的房間。一樣，管理員也須要可以將全部的用戶和他們的活動都引導到他們的集羣，這樣，他們就知道誰在作什麼，以及何時在作什麼。在資源共享方面，每一個人對於訪問資源的需求都不盡相同。在一個酒店中，客人不須要和禮賓人員、維修工擁有一樣的訪問權限。相應的，有些用戶也不須要像別人那樣訪問Kubernetes資源。一個小型公司管理這樣的場景相對容易，但若是是一家大型公司，各類項目又都在使用Kubernetes，那身份管理就變成了一個很是艱鉅的任務，尤爲是要管理多個帳戶和不一樣的訪問層級就更難。若是有愈來愈多的人加入、離開、變換團隊或項目增多，那這個問題會變得愈來愈複雜。
各個團隊都在增強他們對Kubernetes的使用，集羣也將存在於不一樣的pocket之中，使用時的策略、角色和配置也都不盡相同。這種多元化的後果使得在集羣內建立一致性就變得極具挑戰性。若是運維者失去了定義用戶角色、責任和優先權的靈活性，則沒法在環境中確保由正確的人來執行正確的任務。此外，若是管理和訪問控制不足，運維者也沒法發現角色違規、訪問管理風險，沒法執行合規檢查。若是時間都用來滅火，用於提高運維效率的時間天然就減小了。
賦能開發和運維人員
在採用Kubernetes和其它雲原生服務的時候，必定要考慮到它會對工程文化產生什麼樣的影響。Kubernetes 受到開發者的歡迎，那是由於開發者所以可以輕鬆、敏捷地創建起本身的環境。這種單獨的自治權雖然賦予開發者以很大的靈活性，但也讓運維者更難覺得組織內的集羣建立標準化。挑戰就在於：在選擇和開發新技術來加速創新的時候，開發者應該擁有多少自由？在部署策略、保證管制要求，而又不損害創新的狀況下，應該保持何種程度的穩定結構？
「我知道開發者的自治權是很是重要的，可是每次開發團隊選擇了一個新技術或新方法來配置一項現有的技術，受攻擊表面就會擴大，這是我所擔憂的。」 Forrester Research的分析師Charles Betz說，「咱們必需要保證環境是安全的，打好了補丁，並且是最新版的。相對於有幾百種不一樣的方法來配置Kubernetes，又有各類層級的變化，若是您只有一到兩種配置方法，那您的員工基本不會出錯。」
「不少企業都想打造更加集成的軟件，可是若是他們引入了不少不一致的管理模式，致使交易成本上升，那他們就沒有機會進行這樣的集成了。」
開發者想在他們本身的沙盒中創建起本身的社區集羣。想安裝本身的應用，但又不想與不一樣的團隊打交道。您如何讓他們實現這些目標，同時又執行了您想要的標準呢？如何確保這些集羣都遵循了正確的訪問控制規定？如何確保以正確的方式分發證書等敏感信息？如何保證正確的軟件版本或工做負載可用？
「我認爲，關鍵是要在靈活性和管理之間找到正確的平衡。」Knaup說，「讓開發者得到他們想要的靈活性，這樣他們才能充分利用雲原生所帶來的利益；同時讓運維者知道，爲他們提供了多種技術棧，這樣他們就能夠實施管理。」
第二章：從新構想管治模式
大多數管理模式的問題是不能持續。開發團隊採用雲原生技術，又發展出更加敏捷的方式，例如持續流和持續迭代。這與幾十年來的策略有所不一樣，過去都推定一個更老舊的模式，並且不適於長達一個月的sprint週期。雖然管理模式須要從新架構，可是若是限制性過強，就會打擊開發者，阻礙創新。組織須要採用這類敏捷而快速的加速，造成DevOps導向，融入良好、穩固的管理實踐。
本章所介紹的框架和藍圖有助於平衡團隊中每一個人的需求。
多集羣可視性及管理
隨着集羣數量不斷增多，運維者不得不花更多的時間來管理集羣，用於優化的工做時間就少了。他們須要集中式，可視化的和管理集羣，經過持續性的監控，發現差別點，以更好地優化資源、提高成本效益、排除故障，並且不會浪費寶貴的時間。
配置管理
爲了減小正在使用軟件的潛在漏洞範圍，運維者須要正確合理的配置集羣，包括軟件版本的管理。合理的控制水平將有助於組織防範風險，知足合規要求。
驗證及訪問管理
根據各自不一樣的業務類型，組織能夠定義不一樣的管理和訪問控制要求。不一樣角色，權限要求也能夠隨着員工的工做角色變化。運維者能夠採用簡單的方法來管理我的登陸和准入許可，並經過集中式的、由策略驅動的能力來知足合規性需求。
構建並維護業務線關係
最後，關鍵是要避免在IT監控和支持業務需求兩者之間發生衝突，以及避免創新戰略和提升營收的目標之間發生衝突。運維不是要限制技術，相反地，它應該設法爲開發團隊簡化管理。儘管開發者都喜歡Kubernetes的自助模式，可是顯而易見，企業都想要控制，基礎架構、廠商和應用服務相關的意見對組織也很是有意義。
第三章：D2iQ的Kommander如何在Kubernetes環境中交付管治和管理能力
平衡組織內的各類需求是一項艱鉅的任務。一個通過測試的框架和彈性解決方案能夠把各個團隊團結在一塊兒，讓全部人受益。而這正是D2iQ的Kommander所扮演的角色。
D2iQ Kommander的目的就是爲了解決由集羣擴張引起的各種問題。它賦能團隊爲組織的私有云及公有云中不一樣集羣交付可擴展性、一致性、管理和運維效率。利用Kommander，多個團隊能夠建立並維護針對域的集羣，運維也所以得到了集羣可視性。集羣所以得到了更好的標準化。
Kommander的關鍵利益：
多集羣可視性和管理
隨着團隊跨不一樣的基礎架構實施各種Kubernetes，對它們的追蹤和管理就變得愈發困難。不管是哪一個基礎架構或正在使用的分佈，Kommander都能經過惟一的管理平面，爲全部集羣交付即時可視性。一旦發現問題，就能夠在問題惡化以前及時解決，從而節約了寶貴的時間。在得到了有關集羣性能、工做負載指標和集羣活動的相關洞察以後，它還能夠幫助您的組織瞭解資源使用狀況。
配置管理
集羣的配置如何管理？哪些軟件版本能夠在項目中使用？對這些問題都要進行持續的控制，對於不少要承擔全球監管義務環境，這一點很是重要。若是沒有這個能力，基本上就沒法管理一個不可預測的服務集和組織內的版本。Kommander具備開箱即用的配置管理器，可以跨集羣運維，在簡化服務的同時交付具備一致性的配置。此外，Kommander的目錄還包含有廣泛使用的開源技術，幫助您向多個集羣快速部署服務，同時管理在項目中使用哪些軟件版本。這一能力能夠大幅下降安全隱患，並簡化服務的可支持性。
驗證和訪問管理
Kommander跨組織集羣提供一個登入的以及聯合的、基於角色的策略，經過Active Directory集成並基於開放策略訪問(OPA)的安全性、認證（密鑰）和許可，用戶能夠利用他們現有的驗證機制，高效監控環境的情況。經過基於角色的訪問控制（RBAC），管理員能夠定義用戶的角色、責任和帳戶特權，並根據用戶在組織內的角色變化靈活配置訪問權限。針對多個集羣的（RBAC）安全性將會給集羣帶來高可用性，並且能夠用更少的時間實現高效運維。
構建並維護業務線關係
若是組織要在內部建立新的集羣，那就必定要跨集羣建立分離線。Kommander的集中式驗證和受權可賦能各類角色的勞動分工，確保管理靈活性實現最大化。Kommander能夠知足定製化的需求，個體團隊還能夠按需部署關鍵服務。同時，運維團隊能夠爲最適合組織的那些基礎架構、廠商和應用服務建立標準化。當組織有能力平衡開發者的靈活性和運維管控時，團隊士氣和生產力會提高，冗餘以及資源浪費的狀況會減小。
結 論
隨着您快速地採用新的、基於Kubernetes的應用和雲原生服務，您會愈來愈須要簡化目前的運維，以及保障組織有能力控制不斷擴大的 Kubernetes集羣。
設計Kommander的目的就是爲了幫助您的組織扼制資源浪費的狀況，在組織內對集羣的使用進行管治，增強勞動分工，進一步改善控制，提高靈活性。
欲瞭解更多D2iQ的Kommander的相關信息，點擊「閱讀原文」當即註冊，觀看免費的展現。
W O R K S H O P 回 放
內容大綱
如何實現Kubernetes快速部署、擴容、升級、備份等底層運維操做；
如何進行統一的權限管理；
如何從實際的項目層面進行統一的運維管理，包括多集羣資源分配；
如何管理應用商店；
如何進行統一的中央監控。
掃二維碼｜查看回放
往期精彩文章
關於D2iQ
點擊「閱讀原文」，瞭解更多D2iQ Kubernetes Platform
本文分享自微信公衆號 - D2iQ（d2iq_apac）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。