這是關於即將發布的紅帽 OpenShift 平台 4.0 更新中的更改、改進和添加的系列文章中的第一篇，該更新將幫助您為過渡到新版本做好準備。
從 2014 年秋天剛起步的 Kubernetes 社群首次聚集在 Google 西雅圖辦事處的那一刻起，很明顯 Kubernetes 專案注定要徹底改變當今軟體開發和部署的方式。 同時，公有雲服務供應商繼續積極投資基礎設施和服務的開發，這使得與IT合作和創建軟體變得更加容易和容易，並且變得非常容易訪問，這是在年初很少有人能夠想像到的。十年。
當然，每一項新的雲端服務的發布都會伴隨著 Twitter 上專家們的大量討論，爭論的主題多種多樣——包括開源時代的結束、本地 IT 的衰落以及其必然性。雲端中的新軟體壟斷，以及新範式X 將如何取代所有其他範式。
不用說，所有這些爭論都是非常愚蠢的
現實是，什麼都不會消失，今天，由於我們生活中新軟體的不斷出現，我們可以看到最終產品及其開發方式呈指數級增長。 儘管事實上周圍的一切都會改變，但同時，本質上，一切都將保持不變。 軟體開發人員仍然會編寫錯誤的程式碼，營運工程師和可靠性專家仍然會拿著尋呼機四處走動並在Slack 中接收自動警報，管理人員仍然會根據營運支出和資本支出進行操作，每次發生故障時，高級開發人員都會悲傷地嘆了口氣：「我告訴過你了」...
喔真的嗎 應該討論，是我們可以使用哪些工具來創建更好的軟體產品，以及它們如何提高安全性並使開發更容易、更可靠。 隨著專案變得越來越複雜，新的風險就會出現，而今天人們的生活如此依賴軟體，開發人員必須努力把工作做得更好。
Kubernetes 就是這樣的工具之一。 目前正在努力將紅帽 OpenShift 與其他工具和服務結合到一個平台中，使軟體對使用者來說更可靠、更易於管理、更安全。
話雖如此，OpenShift 團隊提出了一個簡單的問題：
如何讓 Kubernetes 的使用變得更輕鬆、更方便？
答案出乎意料地明顯：
- 自動化雲端上或雲外部署的複雜面向；
- 注重可靠性，同時隱藏複雜性；
- 繼續不斷努力發布簡單且安全的更新；
- 實現可控性和可審計性；
- 力求最初確保高安全性，但不以犧牲可用性為代價。
OpenShift 的下一個版本應該考慮到創作者的經驗以及其他在世界上最大的公司大規模實施軟體的開發人員的經驗。 此外，它還必須考慮到構成當今現代世界基礎的開放生態系統所累積的所有經驗。 同時，有必要放棄業餘開發者的舊心態，轉向自動化未來的新概念。 它需要彌合新舊軟體部署方式之間的差距，並充分利用所有可用的基礎設施——無論是由最大的雲端供應商託管還是在邊緣的微型系統上運行。
如何達到這個結果呢？
在紅帽，為了維護已建立的社區並防止公司參與的專案被關閉，人們習慣於長期從事無聊且吃力不討好的工作。 開源社群包含大量才華橫溢的開發人員，他們創造了最非凡的事物- 娛樂性、教育性、開闢新機會和簡單美麗，但是，當然，沒有人期望每個人都朝著同一個方向前進或追求共同的目標。 有時有必要利用這種能量並將其引導到正確的方向，以開發有利於我們用戶的領域，但同時我們必須監控社群的發展並向他們學習。
2018 年初，紅帽收購了 CoreOS 項目，該項目對未來有著類似的看法——更安全、更可靠，基於開源原則創建。 公司一直致力於進一步發展這些想法並實施它們，將我們的理念付諸實踐——努力確保所有軟體安全運作。 所有這些工作都建立在 Kubernetes、Linux、公有雲、私有雲以及支撐我們現代數位生態系統的數千個其他項目的基礎上。
新版本的 OpenShift 4 將更加清晰、自動化、更自然
OpenShift 平台將與最好、最可靠的 Linux 作業系統配合使用，具有裸機硬體支援、方便的虛擬化、自動基礎設施編程，當然還有容器（本質上只是 Linux 映像）。
該平台需要從一開始就是安全的，但仍然允許開發人員輕鬆迭代——也就是說，足夠靈活和安全，同時仍允許管理員輕鬆審核和管理它。
它應該允許軟體「作為服務」運行，並且不會導致運營商無法管理的基礎設施成長。
它將允許開發人員專注於為用戶和客戶創建真正的產品。 您無需費力地穿過硬體和軟體設定的叢林，所有意外的併發症都將成為過去。
OpenShift 4：無需維護的 NoOps 平台
В 描述了那些有助於塑造公司OpenShift 4 願景的任務。該團隊的目標是盡可能簡化操作和維護軟體的日常任務，使這些流程變得簡單輕鬆——無論是對於參與實施的專家還是開發人員來說。 但怎樣才能更接近這個目標呢？ 如何創造一個需要最少干預的運作軟體的平台？ 在這種情況下，NoOps 到底意味著什麼？
如果您嘗試抽象，那麼對於開發人員來說，「無伺服器」或「NoOps」的概念意味著允許您隱藏「操作」元件或最大限度地減少開發人員負擔的工具和服務。
- 不是使用系統，而是使用應用程式介面 (API)。
- 不必費心實施軟體—讓提供者為您做。
- 不要立即開始創建一個大型框架 - 首先編寫充當“構建塊”的小塊，嘗試使該程式碼與資料和事件一起工作，而不是與磁碟和資料庫一起工作。
與以前一樣，目標是加快軟體開發的迭代速度，提供創建更好產品的機會，以便開發人員不必擔心其軟體運行的系統。 經驗豐富的開發人員都清楚，專注於使用者可以快速改變現狀，因此除非您完全確定需要它，否則您不應該在編寫軟體上投入太多精力。
對於維護和營運專業人員來說，「NoOps」這個詞聽起來可能有點可怕。 但在與現場工程師溝通時，很明顯他們使用的旨在確保可靠性和可靠性的模式和技術（站點可靠性工程，SRE）與上述模式有許多相似之處：
- 不要管理系統－自動化他們的管理流程。
- 不要實施軟體 - 創建一個管道來部署它。
- 避免將所有服務捆綁在一起，並讓其中一個服務出現故障而導致整個系統出現故障——使用自動化工具將它們分散到整個基礎設施中，並以可監控的方式將它們連接起來。
SRE 知道某些事情可能會出錯，他們必須追蹤並解決問題，因此他們會自動化日常工作並提前設定錯誤預算，以便他們準備好在問題出現時確定優先順序並做出決策。
OpenShift 中的 Kubernetes 是一個旨在解決兩個主要問題的平台：它不會強迫您了解虛擬機器或負載平衡器 API，而是與更高階的抽象（部署流程和服務）配合使用。 您可以運行容器，而不是安裝軟體代理，也不必編寫自己的監控堆疊，而是使用平台中已有的工具。 因此，OpenShift 4 的秘訣實際上並不是什麼秘密 - 只需採用 SRE 原則和無伺服器概念，並得出符合邏輯的結論，以幫助開發人員和維運工程師：
- 自動化和標準化應用程式使用的基礎設施
- 將部署和開發流程連結在一起，而不限制開發人員本身
- 確保啟動、審核和保護第 XNUMX 個服務、功能、應用程式或整個堆疊並不比第一個更困難。
但 OpenShift 4 平台與其前身以及解決此類問題的「標準」方法有何不同？ 是什麼推動了實施和營運團隊的規模化？ 因為在這種情況下，王者就是集群。 所以，
- 我們確保集群的目的明確（親愛的雲，我選擇了這個集群，因為我可以）
- 機器和作業系統的存在是為了服務集群（陛下）
- 管理叢集中主機的狀態，最大限度地減少它們的重建（漂移）。
- 對於系統的每個重要元素，都需要一個保母（機制）來監控和消除問題
- 系統的「每個」面向或元素以及相關的恢復機制故障是生活中正常的一部分
- 整個基礎設施必須透過 API 進行配置。
- 使用 Kubernetes 來執行 Kubernetes。 （是的，是的，這不是錯字）
- 更新的安裝應該是簡單、無憂。 如果需要多次點擊才能安裝更新，那麼顯然我們做錯了什麼。
- 監視和調試任何組件都不應該成為問題，因此整個基礎設施的追蹤和報告也應該簡單方便。
想要了解平台的實際功能嗎？
OpenShift 4 的預覽版已向開發人員開放。 透過易於使用的安裝程序，您可以在 Red Had CoreOS 之上的 AWS 上運行叢集。 要使用預覽版，您只需要一個 AWS 帳戶來設定基礎架構和一組帳戶來存取預覽映像。
- 要開始使用，請訪問 並點擊“開始”。
- 登入您的 Red Hat 帳戶（或建立新帳戶）並按照指示設定您的第一個叢集。
安裝成功後，請查看我們的教學課程 更深入地了解使 OpenShift 4 平台成為運行 Kubernetes 的簡單便捷方式的系統和概念。
嘗試新的 OpenShift 版本並分享您的意見。 我們致力於讓與 Kumbernetes 的合作盡可能輕鬆便捷——NoOps 的未來從今天開始。
現在註意！
在會議上 20 月 37 日，OpenShift 開發人員之一 Vadim Rutkovsky 將舉辦大師班 - 他將破壞 XNUMX 個叢集並迫使他們修復它們。 會議已付費，但使用促銷代碼 #RedHat 可享 XNUMX% 的折扣
大師班時間為17:15-18:15，展位全天開放。 T 卹、帽子、貼紙－常見的！
2號廳
“這裡整個系統需要改變：我們與經過認證的機械師一起修復損壞的 k8s 集群。”
來源： www.habr.com