新特性初探：Docker for Mac喜迎Kuberntes支援能力

很高興內建支援Docker Swarm和Kubernetes的Mac版Docker[1]釋出了，本文將會回顧一下此工具簡史，然後看看新功能的第一印象。

為什麼對開發者很重要？

Docker CE（簡稱Docker）是一款易用簡便的容器工具，是給使用者帶來自主和硬體無關性體驗的軟體。Mac版Docker並不是從一開始就支援Kubernetes，我們看看它的簡史：

Docker髮端於DotCloud公司，一開始並不支援Windows和Mac，只能執行在Linux上。

Docker簡史

虛機

最開始，如果Mac或者Linux使用者想使用容器技術，就需要在Linux主機中安裝如VirtualBox或者VMWare Workstation/Player之類的虛擬機器工具，並設定共享目錄。為了使用統一CLI工具，使用者不得不採用Hashicorp公司的Vagrant[2]。

使用場景：這種方式都是過時的技術，並不建議採用。

Docker Machine

Docker Machine是進化的第二步，採用boot2docker映象在本地或者遠端環境部署虛機，並提供可寫磁碟空間，也是朝易用性邁出的一大步。一旦基於SSL認證的VM生成，Docker客戶端就可以透過TCP/IP工具訪問它，可以同時支援多個Docker版本構成的叢集。

優點：

• 同一主機支援多個容器後端

• 只支援Linux

• 使用boot2docker映象

• 模組化支援各家雲提供商外掛

缺點：

• 命令列方式操作

• 不支援Windows和Mac

使用場景：使用Windows 7或者Windows 10 Home，需要在本地執行一套叢集，或者需要在雲端運維一套叢集。

Docker for Mac/Windows

Docker Machine需要太多手工操作（透過docker-machine env），為了採用TLS，有時還需要重建。Docker for Mac/Windows（簡稱DfM）本著造福廣大使用者的初衷，內建UI和選單支援，推出了功能有限的beta版本，剛開始主要是Twitter使用它。

優點：

• 安裝簡便

• 自動配置命令列

• 圖形化介面配置

• 一鍵啟停作業

缺點：

• 共享捲時效能很差

• 高耗能降低電池使用時間

• 支援Windows 10 pro或者enterprise

使用場景：可用，但是需要本地安裝Docker Swarm或者Kubernetes。

Minikube

Minikube跟docker-machine非常類似，也依靠boot2docker，初衷是建立內含可用於開發的Docker主機的單節點Kubernetes叢集。

Mac上的minikube輸出案例如下：

$ minikube start
Starting local Kubernetes v1.8.0 cluster...  
Starting VM...  
Getting VM IP address...  
Moving files into cluster...  
Setting up certs...  
Connecting to cluster...  
Setting up kubeconfig...  
Starting cluster components...  
Kubectl is now configured to use the cluster.  
Loading cached images from config file.

優點：

• 本地環境易於訪問

• Kubernetes可用

缺點：

• Kubernetes在空閑時耗費大量電力

• 感覺還是跟docker-machine很類似

• 內建Docker版本嚴重滯後

• 有些功能尚不支援，例如RBAC（role-based authentication control）

• 需要使用minikube start/stop

使用場景：需要本地Kubernetes場景但是不必關註Docker版本。

以上總結了各階段優缺點，下麵看看最新內建Kubernetes功能的DfM第一印象。

第一印象

以下是我更新DfM後，使用它得到的第一印象。

開始

需要Docker 17.12或者更高版本以獲得Kubernetes支援，然後就是透過UI介面花幾分鐘下載新版本。

背景關係和名稱空間

如果以前安裝了minikube，需要轉換到DfM背景關係，否則kubectl會掛起。

kubectl config use-context docker-for-desktop

如果發現有太多輸出內容，Kubernetes社群有一個叫kubectx[3]的工具可以改善輸出狀況。

Docker Swarm和Kubernetes之間一個不同是名稱空間的支援。預設地，Kubernetes生態容器執行在稱為system的隱藏名稱空間，可以透過以下命令檢視kubectl get all –all-namespaces：

輸出有很多預設執行的服務，和Docker Swarm一樣，區別是對使用者隱藏，執行在幾個固定二進位制程式碼中，而不是分散執行的服務。

以下命令可以檢視Kubernetes版本：

$kubectl version
Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.2", GitCommit:"bdaeafa71f6c7c04636251031f93464384d54963", GitTreeState:"clean", BuildDate:"2017-10-24T19:48:57Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"darwin/amd64"}  
Server Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.2", GitCommit:"bdaeafa71f6c7c04636251031f93464384d54963", GitTreeState:"clean", BuildDate:"2017-10-24T19:38:10Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}

看起來是1.8.2版本，儘管不是最新版本但也包含了所有重要功能。

整合Docker

Docker希望Kubernetes更加易用，因此整合了Docker stacks和Kubernetes原生部署服務。

Kubernetes是很容易擴充套件的，Docker使用Custom Resource Definitions （CRDs）引入了對“棧（stack）”概念的支援。可以驗證如下：

$kubectl get stacks
No resources found.
$ kubectl get crd
NAME                        AGE  
stacks.compose.docker.com   24d

看看對compose檔案的效果：

$ docker stack deploy prometheus -c ./docker-compose.yml 
Stack prometheus was created  
Waiting for the stack to be stable and running...  
 - Service exporter has one container running
 - Service grafana has one container running
 - Service prom has one container running
Stack prometheus is stable and running

CRD驗證：

$ kubectl get stacks
NAME         AGE  
prometheus   1m

建立了幾個Pods：

$kubectl get pods  
NAME                        READY     STATUS             RESTARTS   AGE  
exporter-66c7bbfcc6-r5sq4   1/1       Running            0          2m  
grafana-7c5f5f6b75-rfgzp    1/1       Running            0          2m  
prom-76b4f584f7-qckc9       0/1       CrashLoopBackOff   4          2m

Prometheus有一個bug，可以用這個命令debug：$kubectl logs pod/prom-76b4f584f7-qckc9。

如果仍然使用docker-compose開發和生產，現在可以直接轉向Kubernetes了。

內建工作流

我們期望內建工作流能夠實現：

• kubectl apply 支援YAML

• helm

• RBAC啟用

下麵部署OpenFaaS-Serverless功能（採用Docker和Kubernetes實現起來很簡單）。

$ mkdir -p go/src/github.com/openfaas/ && \
 cd go/src/github.com/openfaas/ && \
 git clone https://github.com/openfaas/faas-netes && \
 cd faas-netes && \
 kubectl apply -f ./yaml

如果碰到名稱空間錯誤，可以在faas-netes目錄下執行kubectl apply -f ./namespaces.yml ，然後再嘗試一遍。

OpenFaaS會在localhost:31112啟動圖形介面，並啟用了RBAC和兩個名稱空間（openfaas / openfaas-fn），輸出如下：

service "alertmanager" created  
deployment "alertmanager" created  
configmap "alertmanager-config" configured  
service "faas-netesd" created  
deployment "faas-netesd" created  
deployment "gateway" created  
service "gateway" created  
service "nats" created  
deployment "nats" created  
service "prometheus" created  
deployment "prometheus" created  
configmap "prometheus-config" configured  
deployment "queue-worker" created  
serviceaccount "faas-controller" configured  
role "faas-controller" configured  
rolebinding "faas-controller-fn" configured

服務也建立完畢。驗證如下：

$ kubectl get all --namespace openfaas

然後開啟UI，部署一個應用功能：

http://localhost:31112 

然後選擇Figlet – figlet是Linux下二進位制檔案可以產生ASCII 文字logos。

檢視產生的Function/Pod：

$ kubectl get all --namespace openfaas-fn
NAME            DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE  
deploy/figlet   1         1         1            1           8m
NAME                   DESIRED   CURRENT   READY     AGE  
rs/figlet-676c995d66   1         1         1         8m
NAME            DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE  
deploy/figlet   1         1         1            1           8m
NAME                   DESIRED   CURRENT   READY     AGE  
rs/figlet-676c995d66   1         1         1         8m
NAME                         READY     STATUS    RESTARTS   AGE  
po/figlet-676c995d66-rqjpn   1/1       Running   0          8m
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE  
svc/figlet   ClusterIP   10.101.45.157           8080/TCP   8m

相對於Docker Swarm，Kubernetes使用更多物件形成服務。

啟用服務檢視結果:

作業執行很順暢，而且簡單易用。對於社群維護和內建OpenFaaS整合很有幫助。

之前提過需要helm（一個類似OpenFaaS的分散式軟體管理器），在Docker Swarm中沒有類似的概念。

寫這篇部落格之前，我在Twitter上看有訊息說helm也已經被支援了。

總結

其實不僅是簡單的DfM整合了“棧”，應該說在現有工具外層實現了簡單化，提高了速度，更加易用。相信Docker Swarm使用者都會使用這種整合，而且遷移到Kubernetes。

Docker Swarm 已死？作為Docker Captains使用者組成員，我並沒有更多內部訊息，但是因為Docker Swarm仍然有很多使用者，因此仍然會被支援。例如：最原始可以執行在容器內的Swarm仍然被Docker’s UCP product[4]支援。

如果讀了developer reactions on Hacker News[5]，可以看到Swarm仍然有很多粉絲，如果Kubernetes想吸引他們，那麼on-prem安裝維護過程需要提高。

因此我的第一印象總結如下：很多新功能令人振奮，尤其是對DfM的更新以及內部新元素使得它看起來更像一個LinuxKit了。

相關連結：

1. https://www.docker.com/docker-mac

2. https://www.vagrantup.com/

3. https://github.com/ahmetb/kubectx

4. https://docs.docker.com/datacenter/ucp/2.2/guides/

5. https://news.ycombinator.com/item?id=16084243

原文連結：https://blog.alexellis.io/docker-for-mac-with-kubernetes/

基於Kubernetes的DevOps實踐培訓

本次培訓包含：Kubernetes核心概念；Kubernetes叢集的安裝配置、運維管理、架構規劃；Kubernetes元件、監控、網路；針對於Kubernetes API介面的二次開發；DevOps基本理念；微服務架構；微服務的容器化等，點選識別下方二維碼加微信好友瞭解具體培訓內容。

點選閱讀原文連結即可報名。