k8s - Tony Bai

当Docker遇到systemd

十二月 27, 2016

近期在做Kubernetes集群的升级的相关试验，即从原先的K8s 1.3.7版本升级到最新的K8s 1.5.1版本。k8s自1.4版本开始引入kubeadm，试图简化K8s的安装和使用门槛，提升开发者体验。但kubeadm仅支持16.04及以上的Ubuntu版本，于是我们在升级K8s集群前会遇到另外一个问题：Ubuntu 16.04已经由Upstart初始化系统换成了systemd初始化系统，Ubuntu 16.04上的Docker engine的使用和配置方法与以前在Ubuntu 14.04上将有所不同。Docker是K8s支持的容器引擎之一，也是目前最主流的容器引擎，弄清楚Docker的配置和使用也是后续用好K8s的前提之一。于是这里打算记录一下Docker与Systemd是如何相生共存的^0^。

一、Ubuntu 16.04安装Docker

Aliyun目前上没有提供官方Ubuntu 16.04 ECS，最高仅支持到Ubuntu 14.04.4。因此在Aliyun ECS上用16.04需要手工upgrade到16.04（不过建议在upgrade前做个snapshot，一旦upgrade失败，好恢复）。升级后的Ubuntu环境信息如下：

Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-58-generic x86_64)

kubeadm文档中认为Docker 1.11.2版本与之更配哟，不过对于更新的版本似乎配合起来也没有什么大问题。我们这里安装目前可以找到的最新stable release: docker 1.12.5：

# docker version
Client:
 Version:      1.12.5
 API version:  1.24
 Go version:   go1.6.4
 Git commit:   7392c3b
 Built:        Fri Dec 16 02:42:17 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.5
 API version:  1.24
 Go version:   go1.6.4
 Git commit:   7392c3b
 Built:        Fri Dec 16 02:42:17 2016
 OS/Arch:      linux/amd64

上面是你安装docker成功后，才能输出的version信息哦^0^。

安装Docker的方法随着docker的快速演进也在变化中，随着Docker的成熟，其方法趋于稳定。官方提供的在Ubuntu安装Docker的方法成为主流，我们这里也不例外的参考这一方法。不过这一方法有一前提，那就是你最好配备的“加(fan)速(qiang)器(qi)”，否则好慢，甚至是不成功。

详细步骤如下：（熟悉之的观众可略过之^_^）

1、从keyserver获取key

# apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys  58118E89F3A912897C070ADBF76221572C52609D

Executing: /tmp/tmp.OoFaQ0V0gx/gpg.1.sh --keyserver
hkp://p80.pool.sks-keyservers.net:80
--recv-keys
58118E89F3A912897C070ADBF76221572C52609D
gpg: requesting key 2C52609D from hkp server p80.pool.sks-keyservers.net
gpg: key 2C52609D: public key "Docker Release Tool (releasedocker) <docker@docker.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)

2、添加Docker源

创建/etc/apt/sources.list.d/docker.list文件，写入：

deb https://apt.dockerproject.org/repo ubuntu-xenial main

执行apt-get update更新包信息：

... ...
Get:11 https://apt.dockerproject.org/repo ubuntu-xenial InRelease [30.2 kB]
Fetched 30.2 kB in 2s (14.1 kB/s)
Reading package lists... Done

3、安装Docker engine

执行安装命令，安装Docker engine：

# apt install docker-engine
... ...
Setting up docker-engine (1.12.5-0~ubuntu-xenial) ...
Setting up liberror-perl (0.17-1.2) ...
Setting up git-man (1:2.7.4-0ubuntu1) ...
Setting up git (1:2.7.4-0ubuntu1) ...
Processing triggers for libc-bin (2.23-0ubuntu5) ...
Processing triggers for systemd (229-4ubuntu13) ...
Processing triggers for ureadahead (0.100.0-19) ...

验证安装结果：

# which docker
/usr/bin/docker

# docker version
... ... //输出和上一节相同的结果

# ps -ef|grep docker
root     22132     1  0 11:18 ?        00:00:00 /usr/bin/dockerd -H fd://
root     22162 22132  0 11:18 ?        00:00:00 docker-containerd -l unix:///var/run/docker/libcontainerd/docker-containerd.sock --shim docker-containerd-shim --metrics-interval=0 --start-timeout 2m --state-dir /var/run/docker/libcontainerd/containerd --runtime docker-runc

安装后，Docker引擎自动启动了。

二、Docker服务的使能与启停

控制Docker服务开机自启以及启停操作的脚本已经由upstart初始化系统的/etc/init.d/docker变为了systemd初始化系统的/lib/systemd/system/docker.service。

在systemd下，docker service的脚本路径通过下面命令可以找到：

# systemctl show --property=FragmentPath docker
FragmentPath=/lib/systemd/system/docker.service

通过下面命令可以查看docker service的是否是开机自启：

# systemctl is-enabled docker
enabled

通过systemctl enable和disable命令可以使能开机自启或取消开机自启。

传统Ubuntu通过service docker start/stop/restart启动、停止或重启服务，换到systemd后，我们需要用systemctl start/stop/restart docker来启动、停止或重启服务。

三、Docker的EnvironmentFile

以前我们给Docker engine设置一个http_proxy、设置–insecure-registry或–registry-mirror、配置一个dns啥的，都可以通过/etc/default/docker中的DOCKER_OPTS以及相关export的环境变量实现。但在Ubuntu 16.04下这个配置文件变成了这样：

# Docker Upstart and SysVinit configuration file

#
# THIS FILE DOES NOT APPLY TO SYSTEMD
#
#   Please see the documentation for "systemd drop-ins":
#   https://docs.docker.com/engine/articles/systemd/
... ...

问题来了！我们怎么配置Docker engine呢？Docker官方推荐在如下路径下面创建配置文件（比如http-proxy.conf），以override默认的docker.service文件中的配置：

/etc/systemd/system/docker.service.d

不过经测试后（after systemctl daemon-reload; systemctl restart docker），发现并不生效。

我们来使用EnvironmentFile对Docker Engine进行配置。编辑/lib/systemd/system/docker.service文件，添加如下内容：

ExecStart=/usr/bin/dockerd -H fd:// $DOCKER_OPTS
EnvironmentFile=-/etc/default/docker

习惯了使用/etc/default/docker配置DOCKER_OPTS等配置，于是在EnvironmentFile中直接使用了该文件。

///etc/default/docker
DOCKER_OPTS="--dns 8.8.8.8 --dns 8.8.4.4"

# If you need Docker to use an HTTP proxy, it can also be specified here.
#export http_proxy="http://127.0.0.1:3128/"
http_proxy="http://xxxxx"
https_proxy="xxxx"
no_proxy="127.0.0.1,localhost"

保存后，执行：

systemctl daemon-reload
systemctl restart docker

你会发现配置生效了。

经常接触/etc/default/docker的人会发现，上述文件中的http_proxy等变量前面的export关键字没有了。没错，在systemd环境下，不再需要export了，如果加上export，反倒会导致配置不生效。

四、Docker引擎的日志

最后，Docker引擎的日志哪里去了？以前不是在/var/log/upstart/下面么？Ubuntu 16.04中，这个目录下连docker字样的影儿都没看到。

在systemd下面，我们需要搬出journalctl工具。想看docker service的实时日志，请执行：

# journalctl -u docker -f

看历史日志：

# journalctl --since "1 hour ago" -u docker

更多journalctl用法，可以参考其man pages。

为Kubernetes集群中服务部署Nginx入口服务

十一月 22, 2016

0 条评论

这段日子，一直在搞与Kubernetes有关的东东：像什么Kubernetes集群搭建、DNS插件安装和配置、集成Ceph RBD持久卷、Private Registry镜像库访问等，这些都缘于正在开发的一个类PaaS小平台的需要：“平台虽小，五脏俱全”。整个平台由Kubernetes集群承载，对于K8s集群内部的Service来说，目前还欠缺一个服务入口。之前的《Kubernetes集群中的Nginx配置热更新方案》一文实际上就是入口方案设计的一个前奏，而本文则是说明一下Nginx入口服务部署设计和实施过程中遇到的一些坑。

一、Nginx入口方案简述

Nginx作为集群入口服务，从功能上说，一般都是充当反向代理和负载均衡的角色。在我们这里它更多是用于反向代理，因为负载均衡的事情“移交”给了K8s去实现了。k8s通过ClusterIP- 一种VIP机制，默认基于iptables的负载分担实现服务请求的负载均衡（如iptable nat table的规则：-m statistic –mode random –probability 0.33332999982），查看iptables nat链的rules，可以看到如下样例：

# iptables -t nat -nL
... ...
Chain KUBE-SVC-UQG6736T32JE3S7H (2 references)
target     prot opt source               destination
KUBE-SEP-Z7UQLD332S673VAF  all  --  0.0.0.0/0            0.0.0.0/0            /* default/nginx-kit: */ statistic mode random probability 0.50000000000
KUBE-SEP-TWOIACCAJCPK3HWO  all  --  0.0.0.0/0            0.0.0.0/0            /* default/nginx-kit: */
... ..

接下来，我们简单说说我们的Nginx入口方案。事先声明：这绝对不是一个理想的方案，因为它还有诸多缺陷，只是在目前平台需求上下文和资源的约束前提下，它可以作为我们的一个可用的过渡方案，方案示意图如下：

img{512x368}

Nginx以Kubernetes service的形式运行于K8s cluster内部，并限制只能被K8s调度到带有label: role=entry的Node上；
最外层，通过DNS域名的轮询机制，实现用户请求在Node这一层上的“负载均衡”；
访问某个NodeIP:NodePort的请求，被转发到Nginx ClusterIP: Port，并通过iptables nat的负载机制，分发到Nginx service的多个real endpoints上；
位于real endpoint上的Nginx程序处理用户请求，并根据配置，将请求proxy_pass到后端服务的ClusterIP:Port上，并最终由k8s实现将请求均衡分发到后端服务的endpoint。

二、Nginx入口服务部署

部署前，我们先来给运行Nginx Pod的Node打label：

# kubectl label node/10.47.136.60 role=entry
node "10.47.136.60" labeled

# kubectl label node/10.47.136.60 role=entry
node "10.47.136.60" labeled

# kubectl get nodes --show-labels
NAME            STATUS    AGE       LABELS
10.46.181.146   Ready     39d       beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=10.46.181.146,role=entry,zone=ceph
10.47.136.60    Ready     39d       beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=10.47.136.60,role=entry,zone=ceph

在Nginx配置热加载方案一文中，我们提到一个nginx pod中包含三个Container：nginx、nginx-conf-generator和init container，Nginx service的yaml示例如下：

//nginx-kit.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-kit
spec:
  replicas: 2
  template:
    metadata:
      labels:
        run: nginx-kit
      annotations:
        pod.beta.kubernetes.io/init-containers: '[
          {
               "name": "nginx-kit-init-container",
               "image": "registry.cn-beijing.aliyuncs.com/xxxx/nginx-conf-generator",
               "imagePullPolicy": "IfNotPresent",
               "command": ["/root/conf-generator/nginx-conf-gen", "-mode", "gen-once"],
               "volumeMounts": [
                   {
                      "name": "conf-volume",
                      "mountPath": "/etc/nginx/conf.d"
                   }
               ]
          }
        ]'
    spec:
      containers:
      - name: nginx-conf-generator
        volumeMounts:
        - mountPath: /etc/nginx/conf.d
          name: conf-volume
        image: registry.cn-beijing.aliyuncs.com/xxxx/nginx-conf-generator:latest
        imagePullPolicy: IfNotPresent
      - name: xxxx-nginx
        volumeMounts:
        - mountPath: /etc/nginx/conf.d
          name: conf-volume
        image: registry.cn-hangzhou.aliyuncs.com/xxxx/nginx:latest
        imagePullPolicy: IfNotPresent
        command: ["/home/auto-reload-nginx.sh"]
        ports:
        - containerPort: 80
      volumes:
      - name: conf-volume
        emptyDir: {}
      nodeSelector:
        role: entry
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-kit
  labels:
    run: nginx-kit
spec:
  type: NodePort
  ports:
  - port: 80
    nodePort: 28888
    protocol: TCP
  selector:
    run: nginx-kit

关于这个yaml，有几点我们是必须要说说的：

1、关于init container

通过上述yaml文件内容，我们可以看到init container和nginx-conf-generator container都是基于同一镜像创建的，只是工作mode不同罢了。在deployment描述文件中，init container的描述需要放在deployment.spec.template.metadata下面，而不是deployment的metadata下面。如果按照后者编写，那么init container将不会被创建和启动，nginx container启动后也就会提示：找不到”default.conf”。

另外，虽然源自同一个image，但init container启动时却提示在$PATH里找不到名为”-mode”的可执行程序，显然init container中的ENTRYPOINT并不起作用，nginx-conf-generator的Dockerfile节选如下：

//Dockerfile
From ubuntu:14.04
... ...
ENTRYPOINT ["/root/conf-generator/nginx-conf-gen"]

为此我们在init container的”command”命令参数中增加了可执行程序全路径以供container执行：

 "command" : ["/root/conf-generator/nginx-conf-gen", "-mode", "gen-once"],

最后，通过上面yaml文件创建nginx-kit服务依旧要用kubectl apply，而不是kubectl create，否则init container不会被理会。

2、关于nginx conf模板

由于种种原因，当前我们是通过server host的location path来映射后端cluster中的不同Service的，nginx default.conf模板如下：

server {
    listen 80;
    #server_name opp.neusoft.com;

    {{range .}}
    location {{.Path}} {
        proxy_pass http://{{.ClusterIP}}:{{.Port}}/;
        proxy_redirect off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
    {{end}}

    #error_page  404              /404.html;

    # redirect server error pages to the static page /50x.html
    #
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }
}

这里要注意的是proxy_pass directive后面值的写法，如果你选择这样写：

proxy_pass http://{{.ClusterIP}}:{{.Port}};

那么当访问某个路径时，比如：localhost/volume/api/v1/pools时，nginx后端的Service收到的url访问路径将是：/volume/api/v1/pools，volume这个location path并不能被去除，后端的Service在做路由匹配时基本都是会出错的。fix的方法是赋予proxy_pass directive下面这样的值：

proxy_pass http://{{.ClusterIP}}:{{.Port}}/;

没错，在最后加上一个”/”，这样nginx所反向代理的Service将会收到/api/v1/pools这样的访问URl路径。

标签 k8s 下的文章