新特性初探：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了。