作為一名軟件工程師，為什么你只需要掌握 Kubernetes ？

翻譯自 Saying Goodbye to PaaS and IaaS 。

Kubernetes 正在接管，不是嗎？

幾乎每個人現(xiàn)在都聽說過 Kubernetes ，許多各種規(guī)模的組織正在使用它或至少在考慮在生產(chǎn)中使用它。然而，Kubernetes 不僅僅是用于運行容器化工作負(fù)載的技術(shù)。它可以改變您的 DevOps 文化。通過設(shè)計，它抽象了底層基礎(chǔ)設(shè)施，同時允許我們在需要時創(chuàng)建或修改它。

軟件工程師將不再需要使用 PaaS 或 IaaS 。

太過激進(jìn)了嗎？

也許是的，但這不是把 Kubernetes 置于至高無上的地位，讓它成為我們所有問題的唯一解決方案。我完全意識到 Kubernetes 、容器和微服務(wù)可能并不是每個問題和每個組織的解決方案。然而，根據(jù)我在過去幾年幫助組織成為云原生的經(jīng)驗，許多人在實施 DevOps 文化時遇到了很多困難。

我堅信 Kubernetes 可以幫助解決這個問題。

Kubernetes 將長久存在

毫無疑問，Kubernetes 不僅僅是一個會消失的炒作技術(shù)。

我還記得 2014 年 Kubernetes 剛剛被捐贈給 CNCF 時我開始使用它。當(dāng)時幾乎它是唯一的用于運行容器化工作負(fù)載的開源技術(shù)。如今，使用容器的組織中約有一半正在使用 Kubernetes 在生產(chǎn)環(huán)境中運行它們。

但Kubernetes的意義不僅僅在于操作容器化工作負(fù)載。

起源

我喜歡講述這個故事，我最初是在 Nigel Poulton 的課程中聽到的。然而，這是 Kubernetes 的簡短故事。

IT 基礎(chǔ)設(shè)施虛擬化（即基礎(chǔ)設(shè)施即服務(wù)，簡稱 IaaS ）的興起始于大約20年前，由亞馬遜開創(chuàng)，隨后有微軟、IBM、Digital Ocean 等等。

當(dāng)時，亞馬遜的優(yōu)勢是巨大的。雖然如今谷歌也提供按需基礎(chǔ)設(shè)施服務(wù)，但在當(dāng)時，谷歌正在思考如何利用自己的專業(yè)知識在這個領(lǐng)域中勝過競爭對手。

谷歌還試圖往前看，自問：

我們?nèi)绾螌⑺性苹A(chǔ)設(shè)施，包括裸金屬服務(wù)器，統(tǒng)一到一個合適的抽象層中？

這是一個聰明的問題，因為當(dāng)時已經(jīng)清楚，每個基礎(chǔ)設(shè)施提供商在其提供的細(xì)節(jié)上會略有不同（函數(shù)即為一個很好的例子）。

答案就是 Kubernetes 。

為什么？因為 Kubernetes 可以在每個云提供商上運行，甚至可以在裸金屬服務(wù)器上運行。使用 Kubernetes 的開發(fā)人員無需擔(dān)心或甚至了解它實際在哪個基礎(chǔ)設(shè)施上運行。

崛起

當(dāng)我和人們談?wù)?Kubernetes 時，我喜歡告訴他們我認(rèn)為它是運行軟件的頭號平臺。當(dāng)然，你可以看出我是一個鐵桿粉絲——部分原因是因為我參與了這個令人驚嘆的社區(qū)，并喜歡在這里做貢獻(xiàn)——但我們來快速看看為什么 Kubernetes 真的是解決許多問題的瑞士軍刀。

一切都始于容器。沒有容器，就不需要 Kubernetes ，對吧？

根據(jù) CNCF 的 2022 年調(diào)查，容器現(xiàn)在被視為主流，有 44％ 的受訪者表示他們在大多數(shù)或所有生產(chǎn)應(yīng)用中使用容器。其中一半使用容器的組織在生產(chǎn)中使用 Kubernetes 來部署其中至少一部分容器（ 64％ 的最終用戶和 49％ 的非最終用戶）。

你可能會說這只是數(shù)字，只代表世界各地正在發(fā)生的特定領(lǐng)域的軟件工程。你可能還會說，對很多人來說，Kubernetes 并不是合適的工具。在這些陳述中，你可能是對的。

但是我們來考慮一下。

對于許多組織、用例和環(huán)境來說，Kubernetes 是合適的工具。即使對于你正在處理的特定產(chǎn)品或所在的團(tuán)隊/部門來說，學(xué)習(xí)如何使用 Kubernetes 也是非常有價值的。

而且，我想用上述 CNCF 調(diào)查中的一個有趣事實來強(qiáng)調(diào)這一點。

Kubernetes 的使用逐漸不僅局限于運行應(yīng)用負(fù)載，還用于輔助負(fù)載。這意味著安全控制、服務(wù)網(wǎng)格、消息系統(tǒng)、可觀察性和持續(xù)集成/持續(xù)交付工具。令人驚訝的是，從 2021 年到 2022 年，輔助負(fù)載的數(shù)量將超過應(yīng)用負(fù)載。然而，輔助負(fù)載的數(shù)量同比增長了 211％ 。

https://www.cncf.io/reports/cncf-annual-survey-2022/

Kubernetes 不僅僅是用于編排容器化應(yīng)用負(fù)載的旗艦工具。

它正在成為云的操作系統(tǒng)

如何實現(xiàn)DevOps？

也許你已經(jīng)看到了未來發(fā)展的方向。自從誕生以來，DevOps 運動一直在試圖彌合開發(fā)人員和運維人員之間的鴻溝。而且有很多不同的方式來做到這一點。

我見過開發(fā)人員變成運維人員，反之亦然，還有 DevOps 職位和整個團(tuán)隊，最新的變化是平臺工程師或團(tuán)隊。不管你采取什么解決方案，根本動機(jī)始終是賦予開發(fā)人員建立和運行他們自己的軟件的能力。

你構(gòu)建它，你運行它。

這就是 DevOps 的口號。盡管我個人不喜歡 DevOps 的職位或整個團(tuán)隊，但我喜歡平臺工程的理念。當(dāng)我在一家專注于 DevOps 的公司為 Cloud Foundry 構(gòu)建數(shù)據(jù)服務(wù)時，我在技術(shù)層面上對 DevOps 的理念是建立一個平臺。就像一個內(nèi)部PaaS（如 Heroku、Cloud Foundry 等）。

這并不是什么新鮮事。我們?yōu)樵S多大型領(lǐng)先行業(yè)的客戶運行了多個 Cloud Foundry 實例，使他們的開發(fā)人員能夠構(gòu)建和運行他們的軟件。棘手的問題在于平衡類似 Cloud Foundry 的平臺的限制和團(tuán)隊開發(fā)人員可能需要的靈活性。

如果他們需要新的數(shù)據(jù)庫、網(wǎng)絡(luò)或子網(wǎng)、Blob 存儲等，他們?nèi)匀恍枰蕾囘\維團(tuán)隊。那么支持性的工作負(fù)載呢？比如安全控制、持續(xù)集成/持續(xù)交付或可觀測性工具？這些也可能需要由運維部署和維護(hù)。

選項的擴(kuò)展

讓我們總結(jié)一下目前的情況。容器無處不在，我們有這個強(qiáng)大的工具可以在規(guī)模上對它們進(jìn)行編排。然后，我們有開發(fā)人員和運維人員，我們?nèi)匀幌Ｍ麥p少摩擦，以便快速交付價值。但是有許多不同的方法可以做到這一點，每種方法都有其優(yōu)缺點。似乎沒有一種方法是萬能的。

這本身不一定是一個問題，但是讓我們花一分鐘來看看不同選項的影響。

• 運維人員可以給開發(fā)人員訪問 IaaS 層。這將給開發(fā)人員很多自由和靈活性。但這也意味著他們需要很多運維知識。而且我們不能忘記 IaaS 提供商之間的微妙差異。開發(fā)人員需要了解不止一個 IaaS 提供商。但公平地說，在這種情況下，開發(fā)人員和運維之間的差距將非常小，因為開發(fā)人員可以自己提供所需的一切。但開發(fā)人員想要擁有這種深入的運維知識嗎？他們是否有能力？他們是否被允許？考慮所有治理和安全約束。

• 運維人員可以為開發(fā)人員引入一個通用的平臺即服務(wù)（PaaS）。比如說 Cloud Foundry 。它會為開發(fā)人員抽象出底層基礎(chǔ)設(shè)施，并為他們提供一些接口來運行他們的應(yīng)用程序（部署、擴(kuò)展、查看日志等）。開發(fā)人員幾乎不需要運維知識，但他們的靈活性也會受到限制。但如果他們需要數(shù)據(jù)庫、消息服務(wù)、持續(xù)集成/持續(xù)交付或其他什么東西，仍然會有一個小的差距。

當(dāng)然，這些不是唯一的可能性。我在可能性范圍上指出了一些點。在這個范圍內(nèi)還有完全不同的選項，類似于我指出的選項，但細(xì)節(jié)上有所不同。一如既往，真相位于中間。

然而，我希望至少從開發(fā)人員的角度來看，能有一種統(tǒng)一的方式。我認(rèn)為 Kubernetes 可以成為這種統(tǒng)一。它可以成為以統(tǒng)一方式提供開發(fā)人員所需一切的平臺。

但等等，Kubernetes 是用于運行容器化工作負(fù)載的，對嗎？那么我們?nèi)绾问褂?Kubernetes 在基礎(chǔ)設(shè)施層面部署應(yīng)用？

一戒統(tǒng)領(lǐng)天下

在過去幾年中，我們看到了在 Kubernetes 領(lǐng)域成立的新公司，它們專注于為開發(fā)人員部署和管理（多/云）平臺。Upbound 就是這樣一家公司，他們創(chuàng)建了 Crossplane ，這是一個開源項目，可以用來創(chuàng)建他們所稱的控制面。

控制面就是你登錄到云服務(wù)提供商帳戶時看到的東西。它允許我們將 Kubernetes 用作我們之前討論的平臺。一個地方，可以控制一切，包括應(yīng)用程序和基礎(chǔ)設(shè)施、配置、策略和權(quán)限。它允許開發(fā)人員進(jìn)行自助服務(wù)，最酷的是，通過單個 Crossplane 安裝，您甚至可以從不同的云提供商中提供基礎(chǔ)設(shè)施資源，實現(xiàn)真正的多云體驗。

我是 Crossplane 的鐵桿粉絲，因為它運行在 Kubernetes 上，因此利用了 Kubernetes 的能力，比如自我修復(fù)和（自動）擴(kuò)展。猜猜怎么著，通過 Crossplane 部署的基礎(chǔ)設(shè)施組件也是如此。Kubernetes 將使用其協(xié)調(diào)機(jī)制，確保一切始終處于所期望的狀態(tài)。

這不是很棒嗎？

這里有一個小倉庫，其中包含了使用 Crossplane 提供 Azure 資源的入門指南。我保證將來會發(fā)表一篇后續(xù)文章，更深入地介紹 Crossplane 。

• iamNoah1/crossplane-jump

結(jié)論

大約兩年前，我說過 Kubernetes 會接管，而且事實證明我沒錯。相反，每個人都知道 Kubernetes ，許多組織都在使用它。然而，Kubernetes 并不是在軟件工程中所有問題或難題的解決方案。

但是通過 Kubernetes 和類似 Crossplane 的工具的幫助，我們可以彌合開發(fā)人員和運維之間的鴻溝。云原生的所有動力一直都是為了提高上市時間。但我必須說，通過 DevOps 、平臺人員或團(tuán)隊引入更多的隔閡似乎不是正確的方法。

通過強(qiáng)大的平臺來抽象基礎(chǔ)設(shè)施，讓開發(fā)人員可以全力構(gòu)建和運行他們的軟件，這對我來說更自然。

希望你喜歡這篇文章，并且我非常樂意聽取任何反饋或了解你對這個主題的看法。

本文使用 文章同步助手 同步