使用Kubernetes啟動(dòng)項(xiàng)目所需的一切

在微服務(wù)，云計(jì)算和無服務(wù)器架構(gòu)時(shí)代，了解Kubernetes并學(xué)習(xí)如何使用它非常有用。 但是，特別是對(duì)于新手來說，Kubernetes的官方文檔可能很難解讀。 在以下系列文章中，我將嘗試提供Kubernetes的簡(jiǎn)化視圖，并提供示例，說明如何使用它通過不同的云提供商(例如Azure，Amazon，Google Cloud甚至IBM)來部署微服務(wù)。

在本系列的第一篇文章中，我們將討論Kubernetes中使用的最重要的概念。 在以下文章中，我們將學(xué)習(xí)如何編寫配置文件，如何將Helm用作程序包管理器，如何創(chuàng)建云基礎(chǔ)架構(gòu)以及如何使用Kubernetes輕松編排我們的服務(wù)。 在上一篇文章中，我們將創(chuàng)建一個(gè)CI / CD管道來自動(dòng)化整個(gè)工作流程。 利用這些信息，您將能夠啟動(dòng)任何類型的項(xiàng)目并創(chuàng)建可靠的基礎(chǔ)架構(gòu)/體系結(jié)構(gòu)。

在開始之前，我想提一提，使用容器有很多好處，從提高部署速度到在更大的水平范圍內(nèi)交付的一致性。 即使這樣，您也不應(yīng)該對(duì)所有內(nèi)容都使用容器，因?yàn)閮H將應(yīng)用程序的任何部分放入容器中都會(huì)帶來諸如維護(hù)容器編排層的開銷。 因此，不要一味得出結(jié)論，相反，在項(xiàng)目開始時(shí)，請(qǐng)創(chuàng)建成本/收益分析。

現(xiàn)在開始在Kubernetes的世界中開始我們的旅程!

硬件

節(jié)點(diǎn) Node

節(jié)點(diǎn)是Kubernetes中最小的工作單元，可以是任何具有CPU和RAM內(nèi)存的設(shè)備。 例如，節(jié)點(diǎn)可以是任何東西，從智能手表，智能手機(jī)，筆記本電腦甚至是RaspberryPi。 當(dāng)我們與云提供商合作時(shí)，節(jié)點(diǎn)就是虛擬機(jī)。 因此，節(jié)點(diǎn)是單個(gè)設(shè)備上的抽象。

正如您將在下一篇文章中看到的那樣，這種抽象的優(yōu)點(diǎn)在于我們不需要了解底層的硬件結(jié)構(gòu)，我們只需要使用節(jié)點(diǎn)，這樣我們的基礎(chǔ)架構(gòu)將獨(dú)立于平臺(tái)。

> Node

集群 Cluster

集群是一組節(jié)點(diǎn)。 將程序部署到群集時(shí)，它會(huì)自動(dòng)處理將工作分配到各個(gè)節(jié)點(diǎn)的情況。 如果需要更多資源(例如，我們需要更多內(nèi)存)，則可以將新節(jié)點(diǎn)添加到群集中，并且工作將自動(dòng)重新分配。

我們?cè)诩荷线\(yùn)行代碼，而不必在意哪個(gè)節(jié)點(diǎn)上，工作的分配將自動(dòng)進(jìn)行。

> Cluster

持久卷 Persistent Volumn

由于我們的代碼可以從一個(gè)節(jié)點(diǎn)重定位到另一個(gè)節(jié)點(diǎn)(例如，一個(gè)節(jié)點(diǎn)沒有足夠的內(nèi)存，因此工作將重新安排在另一個(gè)具有足夠內(nèi)存的節(jié)點(diǎn)上)，因此保存在節(jié)點(diǎn)上的數(shù)據(jù)是易失的。 但是在某些情況下，我們想要永久保存數(shù)據(jù)。 在這種情況下，我們應(yīng)該使用持久卷。 永久卷就像一個(gè)外部硬盤驅(qū)動(dòng)器，您可以將其插入并在其中保存數(shù)據(jù)。

Kubernetes最初是作為無狀態(tài)應(yīng)用程序平臺(tái)開發(fā)的，其中持久性數(shù)據(jù)存儲(chǔ)在其他位置。 隨著項(xiàng)目的成熟，許多組織也希望開始將其用于有狀態(tài)應(yīng)用程序，因此添加了持久的卷管理。 與虛擬化的早期階段非常相似，數(shù)據(jù)庫(kù)服務(wù)器通常不是遷移到這種新架構(gòu)中的第一批服務(wù)器。 原因是數(shù)據(jù)庫(kù)是許多應(yīng)用程序的核心，并且可能包含有價(jià)值的信息，因此本地?cái)?shù)據(jù)庫(kù)系統(tǒng)仍主要在VM或物理服務(wù)器中運(yùn)行。

所以問題是，什么時(shí)候應(yīng)該使用持久卷? 要回答這個(gè)問題，首先我們應(yīng)該了解不同類型的數(shù)據(jù)庫(kù)應(yīng)用程序。

我們可以將數(shù)據(jù)管理解決方案分為兩類：

• 垂直可擴(kuò)展—包括傳統(tǒng)的RDMS解決方案，例如MySQL，PostgreSQL和SQL Server
• 水平可擴(kuò)展—包括" NoSQL"解決方案，例如ElasticSearch或基于Hadoop的解決方案

垂直可伸縮解決方案(如MySQL，Postgres，Microsoft SQL等)不應(yīng)放入容器中。 這些數(shù)據(jù)庫(kù)平臺(tái)需要高I / O，共享磁盤，塊存儲(chǔ)等，并且并未設(shè)計(jì)為優(yōu)雅地處理群集中節(jié)點(diǎn)丟失的情況，這種情況通常發(fā)生在基于容器的生態(tài)系統(tǒng)中。

對(duì)于水平可伸縮應(yīng)用程序(Elastic，Cassandra，Kafka等)，應(yīng)使用容器，因?yàn)樗鼈兛梢猿惺軘?shù)據(jù)庫(kù)集群中節(jié)點(diǎn)丟失的損失，并且數(shù)據(jù)庫(kù)應(yīng)用程序可以獨(dú)立地重新平衡。

通常，您可以并且應(yīng)該對(duì)使用冗余存儲(chǔ)技術(shù)的分布式數(shù)據(jù)庫(kù)進(jìn)行容器化，并且可以承受數(shù)據(jù)庫(kù)集群中節(jié)點(diǎn)的丟失(ElasticSearch是一個(gè)很好的例子)。

軟件

容器 Container

現(xiàn)代軟件開發(fā)的目標(biāo)之一是使同一主機(jī)或群集上的應(yīng)用程序彼此隔離。 虛擬機(jī)是解決此問題的一種方法。 但是虛擬機(jī)需要自己的操作系統(tǒng)，因此通常大小為千兆字節(jié)。

相比之下，容器將應(yīng)用程序的執(zhí)行環(huán)境彼此隔離，但共享底層操作系統(tǒng)內(nèi)核。 因此，容器就像一個(gè)盒子，我們?cè)谄渲写鎯?chǔ)運(yùn)行應(yīng)用程序所需的所有內(nèi)容，例如代碼，運(yùn)行時(shí)，系統(tǒng)工具，系統(tǒng)庫(kù)和設(shè)置等。它們通常以兆字節(jié)為單位進(jìn)行度量，它們使用的資源比VM少得多， 并幾乎立即啟動(dòng)。

吊艙 Pod

吊艙是一組容器。 在Kubernetes中，最小的工作單元是吊艙。 一個(gè)Pod可以包含多個(gè)容器，但是通常每個(gè)Pod使用一個(gè)容器，因?yàn)镵ubernets中的復(fù)制單元是Pod。 因此，如果要獨(dú)立縮放每個(gè)容器，則可以在容器中添加一個(gè)容器。

部署 Deployment

部署的主要作用是為Pod和副本集(同一Pod多次復(fù)制的集合)提供聲明性更新。 使用部署，我們可以指定同一時(shí)間可以運(yùn)行多少個(gè)相同pod的副本。 部署就像是Pod的管理器一樣，它將自動(dòng)增加請(qǐng)求的Pod的數(shù)量，它將監(jiān)視Pod，并在出現(xiàn)故障的情況下重新創(chuàng)建Pod。 部署確實(shí)有幫助，因?yàn)槟槐胤謩e創(chuàng)建和管理每個(gè)Pod。

部署通常用于無狀態(tài)應(yīng)用程序。 但是，您可以通過將持久卷附加到部署卷并使其成為有狀態(tài)來保存部署狀態(tài)。

有狀態(tài)集 StatefulSet

StatefulSet是Kubernetes中的一個(gè)新概念，它是用于管理有狀態(tài)應(yīng)用程序的資源。 它管理一組Pod的部署和擴(kuò)展，并提供有關(guān)這些Pod的順序和唯一性的保證。 它與Deployment類似，唯一的區(qū)別是Deployment會(huì)創(chuàng)建具有隨機(jī)Pod名稱的Pod集，并且Pod的順序并不重要，而StatefulSet創(chuàng)建具有唯一命名約定和順序的Pod。 因此，如果要?jiǎng)?chuàng)建名為example的Pod的三個(gè)副本，StatefulSet將創(chuàng)建具有以下名稱的Pod：example-0，example-1，example-2。 在這種情況下，最重要的好處是您可以依靠窗格的名稱。

守護(hù)程序集 DeamonSet

DaemonSet確保Pod在群集的所有節(jié)點(diǎn)上運(yùn)行。 如果從集群添加/刪除節(jié)點(diǎn)，DaemonSet會(huì)自動(dòng)添加/刪除容器。 這對(duì)于監(jiān)視和日志記錄很有用，因?yàn)檫@樣可以確保您一直在監(jiān)視每個(gè)節(jié)點(diǎn)，而不必手動(dòng)管理群集的監(jiān)視。

服務(wù) Service

部署負(fù)責(zé)使一組Pod保持運(yùn)行，而服務(wù)負(fù)責(zé)啟用對(duì)一組Pod的網(wǎng)絡(luò)訪問。 服務(wù)提供了跨集群標(biāo)準(zhǔn)化的重要功能：負(fù)載平衡，應(yīng)用程序之間的服務(wù)發(fā)現(xiàn)以及支持零停機(jī)應(yīng)用程序部署的功能。 每個(gè)服務(wù)都有一個(gè)唯一的IP地址和一個(gè)DNS主機(jī)名。 可以將使用服務(wù)的應(yīng)用程序手動(dòng)配置為使用IP地址或主機(jī)名，并且流量將負(fù)載平衡到正確的Pod。 在"外部流量"部分，我們將詳細(xì)了解服務(wù)類型以及如何使用它們?cè)趦?nèi)部服務(wù)之間以及與外部世界進(jìn)行通信。

ConfigMaps

如果您想部署到舞臺(tái)，開發(fā)人員和產(chǎn)品等多個(gè)環(huán)境，由于環(huán)境差異，將配置烘焙到應(yīng)用程序中是一個(gè)不好的做法。 理想情況下，您需要分離配置以匹配部署環(huán)境。 這就是ConfigMap發(fā)揮作用的地方。 ConfigMap允許您將配置工件與圖像內(nèi)容分離，以使容器化的應(yīng)用程序具有可移植性。

外部流量

因此，您已經(jīng)在集群中運(yùn)行了所有服務(wù)，但是現(xiàn)在的問題是如何使外部流量進(jìn)入集群? 共有三種不同的服務(wù)類型，可用于處理外部流量：ClusterIP，NodePort和LoadBalancer。 第四個(gè)解決方案是添加另一個(gè)抽象層，稱為入口控制器。

集群IP

這是Kubernetes中的默認(rèn)服務(wù)類型，它使您可以與集群內(nèi)的其他服務(wù)進(jìn)行通信。 這不是為了外部訪問，而是通過使用代理的一點(diǎn)技巧，外部流量會(huì)影響我們的服務(wù)。 不要在生產(chǎn)中使用此解決方案，而只能用于調(diào)試。 聲明為ClusterIP的服務(wù)不應(yīng)在外部直接可見。

節(jié)點(diǎn)端口

正如我們?cè)诒疚牡牡谝徊糠种锌吹降哪菢?，pod在節(jié)點(diǎn)上運(yùn)行。 節(jié)點(diǎn)可以是不同的設(shè)備，例如筆記本電腦，也可以是虛擬機(jī)(在云中工作時(shí))。 每個(gè)節(jié)點(diǎn)都有一個(gè)固定的IP地址。 通過將服務(wù)聲明為NodePort，該服務(wù)將公開該節(jié)點(diǎn)的IP地址，因此您可以從外部訪問它。 可以在生產(chǎn)中使用它，但是對(duì)于大型應(yīng)用程序(其中有許多服務(wù))，手動(dòng)管理所有不同的IP地址可能很麻煩。

負(fù)載均衡器

聲明類型為L(zhǎng)oadBalancer的服務(wù)會(huì)使用云提供商的負(fù)載均衡器在外部公開它。 來自該外部負(fù)載平衡器的流量如何路由到服務(wù)窗格，取決于群集提供程序。 這是一個(gè)非常好的解決方案，您不必管理群集中每個(gè)節(jié)點(diǎn)的所有IP地址，但是每個(gè)服務(wù)只有一個(gè)負(fù)載均衡器。 缺點(diǎn)是，每個(gè)服務(wù)都將有一個(gè)單獨(dú)的負(fù)載平衡器，并且將按每個(gè)負(fù)載平衡器實(shí)例向您收費(fèi)。

該解決方案確實(shí)非常適合生產(chǎn)，但是可能會(huì)有點(diǎn)貴。 因此，讓我們看一個(gè)更便宜的解決方案。

入口 Ingress

入口不是服務(wù)，而是管理群集中對(duì)服務(wù)的外部訪問的API對(duì)象。 它充當(dāng)集群的反向代理和單個(gè)入口點(diǎn)，該集群將請(qǐng)求路由到其他服務(wù)。 我通常使用NGINX Ingress Controller，該控制器承擔(dān)反向代理的角色，同時(shí)還充當(dāng)SSL。 要暴露入口，最好的生產(chǎn)就緒解決方案是使用負(fù)載平衡器。

使用此解決方案，您可以使用單個(gè)負(fù)載均衡器公開任何數(shù)量的服務(wù)，從而可以使您的賬單盡可能低。

下一步

在本文中，我們了解了Kubernetes中使用的基本概念，了解了其硬件結(jié)構(gòu)，了解了Pod，Deployments，StatefulSets，Services等不同的軟件組件，并了解了如何在服務(wù)之間以及與外界進(jìn)行通信。

在下一篇文章中，我們將在Azure上設(shè)置群集，并創(chuàng)建一個(gè)帶有LoadBalancer，一個(gè)Ingress Controller，兩個(gè)服務(wù)的基礎(chǔ)結(jié)構(gòu)，并使用兩個(gè)Deployment來為每個(gè)服務(wù)啟動(dòng)三個(gè)Pod。

如果您需要更多"愚蠢簡(jiǎn)單"的解釋，請(qǐng)?jiān)?quot;中等"上關(guān)注我!

還有另一個(gè)正在進(jìn)行的"愚蠢的簡(jiǎn)單AI"系列。 可以在此處找到前兩篇文章：Python中的SVM和內(nèi)核SVM和KNN。

感謝您閱讀本文!