Docker Swarm、Kubernetes 和 Mesos 是最受歡迎的容器編排框架。 Arun Gupta 在演講中比較了 Docker、Swarm 和 Kubernetes 的以下幾個方面：
- 地方發展。
- 部署功能。
- 多容器應用。
- 服務發現。
- 擴展服務。
- 運行一次任務。
- 與 Maven 整合。
- “滾動”更新。
- 建立 Couchbase 資料庫叢集。
因此，您將清楚地了解每個編排工具必須提供的功能，並了解如何有效地使用這些平台。
Arun Gupta 是 Amazon Web Services 開源產品的技術專家，十多年來一直致力於開發 Sun、Oracle、Red Hat 和 Couchbase 開發者社群。 在領導跨職能團隊制定和實施行銷活動和計劃策略方面擁有豐富的經驗。 他領導了 Sun 工程師團隊，是 Java EE 團隊的創始人之一，也是 Devoxx10Kids 美國分支的創建者。 Arun Gupta 在 IT 部落格上發表了 4 多篇文章，並在 2 多個國家/地區發表演講。
第 55 行包含指向此資料庫服務的 COUCHBASE_URI，該服務也是使用 Kubernetes 設定檔建立的。 如果您查看第 2 行，您可以看到 kind: Service 是我正在建立的名為 couchbase-service 的服務，並且第 4 行列出了相同的名稱。下面是一些連接埠。
關鍵行是第6 行和第7 行。在服務中，我說，“嘿，這些是我正在尋找的標籤！”，這些標籤只不過是變量對名稱，第7 行指向我的couchbase-rs- pod應用。 以下是提供對這些相同標籤的存取的連接埠。
在第 19 行，我建立了一個新類型 ReplicaSet，第 31 行包含映像的名稱，第 24-27 行指向與我的 pod 關聯的元資料。 這正是服務正在尋找的內容以及應該建立連結的內容。 在文件的末尾，第 55-56 行和第 4 行之間有某種聯繫，表示：“使用此服務！”
因此，當存在副本集時，我啟動服務，並且由於每個副本集都有自己的連接埠和相應的標籤，因此它包含在服務中。 從開發人員的角度來看，您只需呼叫該服務，然後該服務就會使用您需要的副本集。
因此，我有一個 WildFly pod，它透過 Couchbase 服務與資料庫後端進行通訊。 我可以將前端與多個 WildFly pod 一起使用，它還透過 couchbase 服務與 couchbase 後端進行通訊。
稍後我們將了解位於叢集外部的服務如何透過其 IP 位址與位於叢集內部且具有內部 IP 位址的元素進行通訊。
所以，無狀態容器很棒，但是使用有狀態容器有多好呢？ 讓我們來看看有狀態容器或持久容器的系統設定。 在 Docker 中，有 4 種不同的資料儲存佈局方法值得您注意。 第一個是隱式每容器，這意味著當使用 couchbase、MySQL 或 MyDB 飽和容器時，它們都從預設的 Sandbox 開始。 也就是說，儲存在資料庫中的所有內容都儲存在容器本身中。 如果容器消失，資料也會隨之消失。
第二個是顯式每個容器，當您使用 docker volume create 命令建立特定儲存並在其中儲存資料時。 第三種每主機方法與儲存映射相關，此時容器中儲存的所有內容都會同時複製到主機上。 如果容器發生故障，資料將保留在主機上。 後者是使用多個Multi-Host主機，這在各種解決方案的生產階段是可取的。 假設您的容器和應用程式正在主機上執行，但您希望將資料儲存在 Internet 上的某個位置，為此您可以使用分散式系統的自動對應。
這些方法中的每一種都使用特定的儲存位置。 隱式和明確每個容器將資料儲存在主機上的 /var/lib/docker/volumes 中。 使用 Per-Host 方法時，儲存安裝在容器內部，容器本身安裝在主機上。 對於多主機，可以使用Ceph、ClusterFS、NFS等解決方案。
如果持久性容器發生故障，則在前兩種情況下儲存目錄將無法訪問，但在後兩種情況下仍可保持存取。 但是，在第一種情況下，您可以透過在虛擬機器上執行的 Docker 主機存取儲存庫。 在第二種情況下，資料也不會遺失，因為您已經建立了明確儲存。
如果主機發生故障，前三種情況儲存目錄不可用；最後一種情況下與儲存的連線不會中斷。 最後，在第一種情況下，共享函數被完全排除在儲存之外，而在其餘情況下是可能的。 在第二種情況下，您可以根據您的資料庫是否支援分散式儲存來共用儲存。 在 Per-Host 的情況下，資料分發只能在給定的主機上進行，對於多主機來說，資料分發是透過叢集擴展來提供的。
建立有狀態容器時應考慮到這一點。 另一個有用的 Docker 工具是 Volume 插件，它的工作原理是「電池存在，但必須更換」。 當你啟動一個 Docker 容器時，它會說：“嘿，一旦你啟動了一個帶有資料庫的容器，你就可以將你的資料儲存在這個容器中！” 這是預設功能，但您可以更改它。 該外掛程式允許您使用網路磁碟機或類似的東西來代替容器資料庫。 它包含用於基於主機的儲存的預設驅動程序，並允許容器與外部儲存系統（例如 Amazon EBS、Azure 儲存和 GCE 持久化磁碟）整合。
下一張幻燈片展示了 Docker Volume 插件的架構。
藍色代表與藍色 Docker 主機關聯的 Docker 用戶端，該主機具有本機儲存引擎，為您提供用於儲存資料的容器。 綠色表示插件客戶端和插件守護進程，它們也連接到主機。 它們提供了將資料儲存在您所需的儲存後端類型的網路儲存中的機會。
Docker Volume 外掛程式可與 Portworx 儲存體一起使用。 PX-Dev 模組實際上是您正在運行的容器，它連接到您的 Docker 主機，並允許您輕鬆地將資料儲存在 Amazon EBS 上。
Portworx 用戶端可讓您監控連接到主機的各種儲存容器的狀態。 如果您訪問我的博客，您可以閱讀如何透過 Docker 充分利用 Portworx。
Kubernetes 中的儲存概念與 Docker 類似，由 pod 中的容器可存取的目錄表示。 它們與任何容器的生命週期無關。 最常見的可用儲存類型是 hostPath、nfs、awsElasticBlockStore 和 gsePersistentDisk。 讓我們看看這些儲存在 Kubernetes 中是如何運作的。 通常，連接它們的過程包括 3 個步驟。
第一個是網路端的某人（通常是管理員）為您提供持久性儲存。 為此有一個相應的 PersistentVolume 設定檔。 接下來，應用程式開發人員編寫一個名為PersistentVolumeClaim 的配置文件，或PVC 存儲請求，其中表示：“我配置了50GB 的分佈式存儲，但為了讓其他人也能使用其容量，我告訴這個PVC，我目前僅需要 10 GB」。 最後，第三步是將您的請求安裝為存儲，並且具有 Pod、副本集或類似內容的應用程式開始使用它。 重要的是要記住，此過程由提到的 3 個步驟組成，並且是可擴展的。
下一張投影片展示了AWS架構的Kubernetes持久化容器。
在代表 Kubernetes 叢集的棕色矩形內，有 XNUMX 個主節點和 XNUMX 個工作節點（以黃色表示）。 其中一個工作節點包含一個橘色 Pod、儲存、一個副本控制器和一個綠色 Docker Couchbase 容器。 在叢集內部，節點上方，紫色矩形表示可從外部存取的服務。 建議將此架構用於在設備本身上儲存資料。 如果有必要，我可以將資料儲存在叢集外部的 EBS 中，如下一張投影片所示。 這是典型的擴展模型，但使用它時需要考慮財務方面的問題 - 將資料儲存在網路上的某個位置可能比儲存在主機上更昂貴。 在選擇容器化解決方案時，這是重要的論點之一。
就像使用 Docker 一樣，您可以將持久性 Kubernetes 容器與 Portworx 結合使用。
這就是目前 Kubernetes 1.6 術語中所謂的「StatefulSet」——一種使用有狀態應用程式的方式，用於處理有關停止 Pod 和執行優雅關閉的事件。 在我們的例子中，此類應用程式是資料庫。 在我的部落格中，您可以閱讀如何使用 Portworx 在 Kubernetes 中建立 StatefulSet。
我們來談談發展方面。 正如我所說，Docker 有 2 個版本 - CE 和 EE，在第一種情況下，我們談論的是社群版的穩定版本，每 3 個月更新一次，而不是 EE 每月更新一次。 您可以下載適用於 Mac、Linux 或 Windows 的 Docker。 安裝後，Docker 會自動更新，上手非常簡單。
對於 Kubernetes，我更喜歡 Minikube 版本 - 這是透過在單一節點上建立叢集來開始使用該平台的好方法。 要建立多個節點的集群，版本的選擇範圍更廣：kops、kube-aws（CoreOS+AWS）、kube-up（已過時）。 如果您希望使用基於 AWS 的 Kubernetes，我建議您加入 AWS SIG，該組織每週五在線上舉行會議，並發佈各種有關使用 AWS Kubernetes 的有趣資料。
讓我們看看滾動更新在這些平台上是如何執行的。 如果存在由多個節點組成的集群，則它使用特定版本的映像，例如 WildFly:1。 滾動更新意味著鏡像版本在每個節點上依序替換為新版本。
為此，我使用 docker service update（服務名稱）命令，在該命令中我指定了 WildFly:2 映像的新版本以及更新方法 update-parallelism 2。數字 2 表示系統將更新 2 個應用程式映像同時，然後10 秒的更新延遲10 秒，之後接下來的2 個影像將在另外2 個節點上更新，依此類推。 這個簡單的滾動更新機制是作為 Docker 的一部分提供給您的。
在 Kubernetes 中，滾動更新的工作原理如下。 複製控制器 rc 建立一組相同版本的副本，而此 webapp-rc 中的每個 pod 都配有位於 etcd 中的標籤。 當我需要 pod 時，我使用應用程式服務存取 etcd 儲存庫，它為我提供使用指定標籤的 pod。
在本例中，我們在Replication 控制器中有3 個pod 運行WildFly 版本1 應用程序，在後台更新時，會創建另一個具有相同名稱和末尾索引的複製控制器- - xxxxx，其中x 是隨機數，並且具有相同的標籤。 現在，應用程式服務在新的複製控制器中擁有三個具有舊版本應用程式的 pod 和三個具有新版本應用程式的 pod。 此後，舊的 Pod 將被刪除，具有新 Pod 的複製控制器將被重新命名並投入運行。
讓我們繼續進行監控。 Docker有很多內建的監控指令。 例如，docker container stats 命令列介面可讓您每秒向控制台顯示有關容器狀態的資訊 - 處理器使用情況、磁碟使用情況、網路負載。 Docker Remote API 工具提供有關客戶端如何與伺服器通訊的資料。 它使用簡單的命令，但基於 Docker REST API。 在這種情況下，REST、Flash、Remote 等字的意思相同。 當您與主機通訊時，它是一個 REST API。 Docker Remote API 可讓您取得有關運行容器的更多資訊。 我的部落格概述了在 Windows Server 上使用此監視的詳細資訊。
在執行多主機叢集時監控docker系統事件可以取得有關主機崩潰或特定主機上的容器崩潰、擴充服務等的資料。 從 Docker 1.20 開始，它包含 Prometheus，它將端點嵌入到現有應用程式中。 這允許您透過 HTTP 接收指標並將其顯示在儀表板上。
另一個監控功能是 cAdvisor（容器顧問的縮寫）。 它分析並提供正在運行的容器的資源使用情況和效能數據，提供開箱即用的 Prometheus 指標。 該工具的特別之處在於它僅提供最後 60 秒的數據。 因此，您需要能夠收集這些數據並將其放入資料庫中，以便您可以監控長期流程。 它也可用於使用 Grafana 或 Kibana 以圖形方式顯示儀表板指標。 我的部落格詳細介紹如何使用 cAdvisor 透過 Kibana 儀表板監控容器。
下一張投影片顯示了 Prometheus 端點輸出的樣子以及可顯示的指標。
在左下角，您可以看到 HTTP 請求、回應等指標，右側是它們的圖形顯示。
Kubernetes 還包括內建的監控工具。 這張投影片顯示了一個包含一個主節點和三個工作節點的典型叢集。
每個工作節點都包含一個自動啟動的 cAdvisor。 此外，還有 Heapster，這是一個與 Kubernetes 1.0.6 及更高版本相容的效能監控和指標收集系統。 Heapster 不僅可以收集工作負載、Pod 和容器的效能指標，還可以收集整個叢集產生的事件和其他訊號。 為了收集數據，它與每個 Pod 的 Kubelet 通信，自動將資訊儲存在 InfluxDB 資料庫中，並將其作為指標輸出到 Grafana 儀表板。 但是，請記住，如果您使用 miniKube，則預設此功能不可用，因此您必須使用插件進行監控。 因此，這完全取決於您運行容器的位置以及預設可以使用哪些監控工具以及需要作為單獨的附加元件安裝。
下一張投影片顯示了 Grafana 儀表板，其中顯示了我的容器的運作狀態。 這裡有很多有趣的數據。 當然，商業化的Docker和Kubernetes進程監控工具很多，像是SysDig、DataDog、NewRelic。 其中一些有 30 年免費試用期，因此您可以嘗試找到最適合您的。 就我個人而言，我更喜歡使用 SysDig 和 NewRelic，它們與 Kubernetes 整合得很好。 有些工具可以同樣地很好地整合到 Docker 和 Kubernetes 平台中。
一些廣告🙂
感謝您與我們在一起。 你喜歡我們的文章嗎？ 想看更多有趣的內容？ 通過下訂單或推薦給朋友來支持我們， , 我們為您發明的入門級服務器的獨特模擬： （適用於 RAID1 和 RAID10，最多 24 個內核和最多 40GB DDR4）。
Dell R730xd 在阿姆斯特丹的 Equinix Tier IV 數據中心便宜 2 倍？ 只有這裡 在荷蘭！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 美元起！ 閱讀
來源： www.habr.com