Autocruise

起因 最先看到這個問題現象是由於在 Docker EE UCP 叢集環境內，下達執行 kubectl 任何子命令操作都卡住，幾乎沒有相應動作。之前這個 UCP 叢集已經運維了好一陣子，都沒有什麼問題，情況來得很突然。 然而，在此容器叢集中，已經既有運行的容器以及服務狀態依然是好的。 過程 容器平台上原先狀態都是好的。後來從當時出問題的節點的 Docker engine 先開始著手調查， 以 CentOS / RHEL 來說，Docker engine 的日誌預設是輸出在作業系統 /var/log/message 這個文件，打開這個文件可以看到類似如下的內容：  29926 Oct  9 08:04:13 docker2 dockerd: time="2019-10-09T08:04:13.139170059+08:00" level=warning msg="failed to retrieve runc version: pipe2: too many open files"  29927 Oct  9 08:04:13 docker2 dockerd: time="2019-10-09T08:04:13.139732508+08:00" level=warning msg="failed to retrieve docker-init version: pipe2: too many open files"  30208 Oct  9 08:06:01 docker2 dockerd: time="2019-10-09T08:06:01.294335790+08:00" level=error msg="Failed to create an ipvs handle for sosbox ingress (ingress,/var/run/       docker/netns/ingress_sosbox) for lb removal: too many open files"  30209 Oct  9 08:06:02 docker2 dockerd: http: Accept error: a...

安裝 Docker EE UCP v3.x 的時候，跟之前介紹的 UCP v2.x 安裝方法類似。但需要注意 Pod IP 地址的設定。 預設情況下，在 Docker EE 平台 Kubernetes pod 的 CIDR 範圍是 192.168.0.0/16 如果節點本身 IP 地址與上述 192.168.0.0/16 範圍有重覆，則在安裝 UCP 的時候必須加上參數  --pod-cidr 來另外指定，否則無法順利安裝 。例如下面範例： $ docker run -it \     --rm --name ucp \          -v /var/run/docker.sock:/var/run/docker.sock \    docker/ucp:3.0.2 install --host-address 192.168.0.51 \    --pod-cidr 10.10.0.0/16 --interactive -D 節點本身 IP 地址是  192.168.0.51 加上參數 --pod-cidr 來另外指定  pod 的 CIDR 範圍在  10.10.0.0/16

如何在 Docker EE 環境下運用整合的 Kubernetes orchestration 做 HPA (Horizontal Pod Autoscaler) 功能? 以下操作皆在 LINUX 環境下運行. 現有一個已建立好的 Docker EE UCP 叢集, 並且已經將設定好帶有 administration 權限的 client bundle 下載在客戶主機並在一個已開啓的 terminal 操作. Docker EE 引擎版本是: # docker version Client: Version: 18.09.3 API version: 1.39 Go version: go1.10.6 Git commit: 142dfce Built: Thu Feb 28 06:08:17 2019 OS/Arch: linux/amd64 Experimental: true Server: Docker Enterprise 2.1 Engine: Version: 18.09.5 API version: 1.39 (minimum version 1.12) Go version: go1.10.8 Git commit: be4553c Built: Thu Apr 11 06:23:08 2019 OS/Arch: linux/amd64 Experimental: false Universal Control Plane: Version: 3.1.4 ApiVersion: 1.39 Arch: amd64 BuildTime: Wed Feb 27 22:26:43 UTC 2019 GitCommit: 29b16f9 GoVersion: go1.10.6 MinApiVersion: 1.20 Os: ...

Helm 是 Kubernetes 環境下的軟體包管理工具。可以這樣想像，Kubernetes 環境下的 Helm 猶如作業系統 CentOS 中的 yum. Helm使用稱為 chart 的軟體包格式，裡面包含描述 Kubernetes 應用程式資源的純文字文件，可用來部署簡單的內容例如 memcached pod，或者複雜的內容例如 HTTP server，DB，cache 等完整 Web 應用程序堆疊。Docker 容器化將單一程式封裝到單一個映像檔中，而 Helm 將整合一支應用系統所包含的多個微服務程式各自的映像檔(image)，及相關資源配置，打包到單一應用程式軟體包中封裝，且基於 chart 軟體包格式來做 Kubernetes 應用程式的分發散佈，如此更符合大型企業應用的需求。 Helm 由兩部分組成，客戶端 helm 和服務端 tiller： helm 是安裝在本地 docker host 運行的一个命令行工具； tiller 安裝運行在 Kubernetes cluster 上，管理部署在 Kubernetes cluster 的 chart 軟體包， Docker EE 2.0 cluster 支援 Kubernetes 的編配, 在 Docker EE 環境下安裝 Helm 是有可能完成的，這篇文章詳細介紹如何在 Docker EE 環境下安裝 Helm （包含以上提到的 helm 客戶端以及 tiller 服務端兩者）並進而利用 Helm 來部署 K8s 應用程式。 實驗開始前已經先建立好 Docker EE UCP cluster, (關於如何建立 Docker EE UCP cluster 請參閱其他文章), 本次所使用的 Docker EE 引擎以及 kubectl 版本如下所示： $ docker version Client: Docker Enterprise Edition (EE) 2.0 Version: 17.06.2-ee-16 API version: 1.30 Go version: go1.8.7 Git commit: 9ef4f0a Built: Thu Jul 26 16:41:28 2018 OS/Arch: linux/amd64 S...

Service Mesh 指的是在2016年由 Buoyant 公司所提出的 Linkerd 框架當中蘊含的一個核心技術概念，目的在解決微服務架構以及容器化服務所衍生出來的網路和安全問題。它在分散式系統中涵蓋了動態鏈接過程，提供安全，快速，可靠的服務間通訊。 如何設計好服務間通訊在微服務架構中是一項挑戰。分散式系統中，會有許多四處移動的跨多伺服器或主機的服務，軟體元件難免會遭遇異常情況。因為會發生部分失敗甚至導致更大範圍的中斷問題，所以設計微服務架構和服務間通訊的時候，需要將這類分散式系統的常見風險列入考量。 關於服務間通訊常見的實現方法大致會有：一個直接較容易實作的方法是以 HTTP (REST) 為基礎，但有 blocking 以及效能低的缺點；第二，採用非同步通訊協定，例如 AMQP。在應用程式代碼實作上相對比較複雜，並搭配運用 側車(sidecar)模式 以及 大使(Ambassador)模式 來處理訊息重送和熔斷訊息斷路機制；最後，運用 Service Mesh 框架。 藉由運用 Service Mesh 框架，開發人員可以專注在自己開發的應用程式碼邏輯，不需要太擔心要如何用代碼處理雲環境或是容器平台上高度複雜的服務間通訊狀況，應用程式代碼不會與通訊代碼過度耦合，而又同時能通過 Service Mesh 框架來管理雲環境或容器平台內部的服務間通訊的正確性，可靠性，以及確保一定程度的通訊效能。當前最常見的分散式系統就是微服務，簡單來說，Service Mesh 就如同是微服務的動態鏈接器（dynamic linker）。 當前常見的 Service Mesh 框架有：Google 主導的 Istio ；以及 Buoyant 公司所提出的 Linkerd ， 後來 Buoyant 公司參考 Istio 架構又另外推出一個輕量型的 Service Mesh 框架: Conduit，Conduit 後來再整合到 linnkerd, 作為 Linkerd2。Nginx 也有推出類似的方案。 這裡主要先以 linkerd 為例說明 Service Mesh 框架與 Docker EE 平台的整合。 要在 Docker EE 環境下部署 linkerd 有兩種方式: 一、以 docker run 命令運行 linkerd image, 在本...