使用Kubernetes啟動項目所需的一切

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

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

在開始之前，我想提一提，使用容器有很多好處，從提高部署速度到在更大的水平范圍內交付的一致性。 即使這樣，您也不應該對所有內容都使用容器，因為僅將應用程序的任何部分放入容器中都會帶來諸如維護容器編排層的開銷。 因此，不要一味得出結論，相反，在項目開始時，請創建成本/收益分析。

現在開始在Kubernetes的世界中開始我們的旅程!

硬件

節點 Node

節點是Kubernetes中最小的工作單元，可以是任何具有CPU和RAM內存的設備。 例如，節點可以是任何東西，從智能手表，智能手機，筆記本電腦甚至是RaspberryPi。 當我們與云提供商合作時，節點就是虛擬機。 因此，節點是單個設備上的抽象。

正如您將在下一篇文章中看到的那樣，這種抽象的優點在于我們不需要了解底層的硬件結構，我們只需要使用節點，這樣我們的基礎架構將獨立于平臺。

> Node

集群 Cluster

集群是一組節點。 將程序部署到群集時，它會自動處理將工作分配到各個節點的情況。 如果需要更多資源(例如，我們需要更多內存)，則可以將新節點添加到群集中，并且工作將自動重新分配。

我們在集群上運行代碼，而不必在意哪個節點上，工作的分配將自動進行。

> Cluster

持久卷 Persistent Volumn

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

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

所以問題是，什么時候應該使用持久卷? 要回答這個問題，首先我們應該了解不同類型的數據庫應用程序。

我們可以將數據管理解決方案分為兩類：

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

垂直可伸縮解決方案(如MySQL，Postgres，Microsoft SQL等)不應放入容器中。 這些數據庫平臺需要高I / O，共享磁盤，塊存儲等，并且并未設計為優雅地處理群集中節點丟失的情況，這種情況通常發生在基于容器的生態系統中。

對于水平可伸縮應用程序(Elastic，Cassandra，Kafka等)，應使用容器，因為它們可以承受數據庫集群中節點丟失的損失，并且數據庫應用程序可以獨立地重新平衡。

通常，您可以并且應該對使用冗余存儲技術的分布式數據庫進行容器化，并且可以承受數據庫集群中節點的丟失(ElasticSearch是一個很好的例子)。

軟件

容器 Container

現代軟件開發的目標之一是使同一主機或群集上的應用程序彼此隔離。 虛擬機是解決此問題的一種方法。 但是虛擬機需要自己的操作系統，因此通常大小為千兆字節。

相比之下，容器將應用程序的執行環境彼此隔離，但共享底層操作系統內核。 因此，容器就像一個盒子，我們在其中存儲運行應用程序所需的所有內容，例如代碼，運行時，系統工具，系統庫和設置等。它們通常以兆字節為單位進行度量，它們使用的資源比VM少得多， 并幾乎立即啟動。

吊艙 Pod

吊艙是一組容器。 在Kubernetes中，最小的工作單元是吊艙。 一個Pod可以包含多個容器，但是通常每個Pod使用一個容器，因為Kubernets中的復制單元是Pod。 因此，如果要獨立縮放每個容器，則可以在容器中添加一個容器。

部署 Deployment

部署的主要作用是為Pod和副本集(同一Pod多次復制的集合)提供聲明性更新。 使用部署，我們可以指定同一時間可以運行多少個相同pod的副本。 部署就像是Pod的管理器一樣，它將自動增加請求的Pod的數量，它將監視Pod，并在出現故障的情況下重新創建Pod。 部署確實有幫助，因為您不必分別創建和管理每個Pod。

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

有狀態集 StatefulSet

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

守護程序集 DeamonSet

DaemonSet確保Pod在群集的所有節點上運行。 如果從集群添加/刪除節點，DaemonSet會自動添加/刪除容器。 這對于監視和日志記錄很有用，因為這樣可以確保您一直在監視每個節點，而不必手動管理群集的監視。

服務 Service

部署負責使一組Pod保持運行，而服務負責啟用對一組Pod的網絡訪問。 服務提供了跨集群標準化的重要功能：負載平衡，應用程序之間的服務發現以及支持零停機應用程序部署的功能。 每個服務都有一個唯一的IP地址和一個DNS主機名。 可以將使用服務的應用程序手動配置為使用IP地址或主機名，并且流量將負載平衡到正確的Pod。 在"外部流量"部分，我們將詳細了解服務類型以及如何使用它們在內部服務之間以及與外部世界進行通信。

ConfigMaps

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

外部流量

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

集群IP

這是Kubernetes中的默認服務類型，它使您可以與集群內的其他服務進行通信。 這不是為了外部訪問，而是通過使用代理的一點技巧，外部流量會影響我們的服務。 不要在生產中使用此解決方案，而只能用于調試。 聲明為ClusterIP的服務不應在外部直接可見。

節點端口

正如我們在本文的第一部分中看到的那樣，pod在節點上運行。 節點可以是不同的設備，例如筆記本電腦，也可以是虛擬機(在云中工作時)。 每個節點都有一個固定的IP地址。 通過將服務聲明為NodePort，該服務將公開該節點的IP地址，因此您可以從外部訪問它。 可以在生產中使用它，但是對于大型應用程序(其中有許多服務)，手動管理所有不同的IP地址可能很麻煩。

負載均衡器

聲明類型為LoadBalancer的服務會使用云提供商的負載均衡器在外部公開它。 來自該外部負載平衡器的流量如何路由到服務窗格，取決于群集提供程序。 這是一個非常好的解決方案，您不必管理群集中每個節點的所有IP地址，但是每個服務只有一個負載均衡器。 缺點是，每個服務都將有一個單獨的負載平衡器，并且將按每個負載平衡器實例向您收費。

該解決方案確實非常適合生產，但是可能會有點貴。 因此，讓我們看一個更便宜的解決方案。

入口 Ingress

入口不是服務，而是管理群集中對服務的外部訪問的API對象。 它充當集群的反向代理和單個入口點，該集群將請求路由到其他服務。 我通常使用NGINX Ingress Controller，該控制器承擔反向代理的角色，同時還充當SSL。 要暴露入口，最好的生產就緒解決方案是使用負載平衡器。

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

下一步

在本文中，我們了解了Kubernetes中使用的基本概念，了解了其硬件結構，了解了Pod，Deployments，StatefulSets，Services等不同的軟件組件，并了解了如何在服務之間以及與外界進行通信。

在下一篇文章中，我們將在Azure上設置群集，并創建一個帶有LoadBalancer，一個Ingress Controller，兩個服務的基礎結構，并使用兩個Deployment來為每個服務啟動三個Pod。

如果您需要更多"愚蠢簡單"的解釋，請在"中等"上關注我!

還有另一個正在進行的"愚蠢的簡單AI"系列。 可以在此處找到前兩篇文章：Python中的SVM和內核SVM和KNN。

感謝您閱讀本文!