除了在生产环境使用的Kubernetes 1.3.7集群之外，我这里还有一套1.5.1的Kubernetes测试环境，这个测试环境一来用于验证各种技术方案，二来也是为了跟踪Kubernetes的最新进展。本篇要记录的一个异常就是发生在该测试Kubernetes集群中的。

一、缘起

前两天我在Kubernetes测试环境搭建一套Ceph，为了便于ceph-deploy的安装，我通过hostnamectl命令将阿里云默认提供的复杂又冗长的主机名改为短小且更有意义的主机名：

iZ25beglnhtZ -> yypdmaster
iz2ze39jeyizepdxhwqci6z -> yypdnode

以yypdmaster为例，修改过程如下：

# hostnamectl --static set-hostname yypdmaster
# hostnamectl status
Static hostname: yypdmaster
Transient hostname: iZ25beglnhtZ
         Icon name: computer-vm
           Chassis: vm
        Machine ID: 91aa4b8f2556de49e743dc2f53e8a5c4
           Boot ID: 5d0e642ebafa460086388da4177e488e
    Virtualization: kvm
  Operating System: Ubuntu 16.04.1 LTS
            Kernel: Linux 4.4.0-58-generic
      Architecture: x86-64

# cat /etc/hostname
yypdmaster

hostnamectl并未修改/etc/hosts，我手动在/etc/hosts中将yypdmaster对应的ip配置上：

xx.xx.xx.xx yypdmaster

重新登录后，我们看到主机名状态：Transient hostname不见了，只剩下了静态主机名：

# hostnamectl status
   Static hostname: yypdmaster
         Icon name: computer-vm
           Chassis: vm
        Machine ID: 91aa4b8f2556de49e743dc2f53e8a5c4
           Boot ID: 5d0e642ebafa460086388da4177e488e
    Virtualization: kvm
  Operating System: Ubuntu 16.04.1 LTS
            Kernel: Linux 4.4.0-58-generic
      Architecture: x86-64

另外一台主机也是如此修改。主机名修改后，整个k8s集群工作一切正常，因此我最初以为hostname的修改对k8s cluster的运行没有影响。

二、集群”Crash”

昨天在做跨节点挂载Cephfs测试时，发现在yypdmaster上kubectl exec另外一个node上的pod不好用，提示：连接10250端口超时！而且从错误日志来看，yypdmaster上的k8s组件居然通过yypdnode的外网ip去访问yypdnode上的10250端口，也就是yypdnode上kubelet监听的端口。由于aliyun的安全组规则限制，这个端口是不允许外网访问的，因此timeout错误是合理的。但为什么之前集群都是好好的？突然间出现这个问题呢？为什么不用内网的ip地址访问呢？

我尝试重启了yypdnode上的kubelet服务。不过似乎没什么效果！正当我疑惑时，我发现集群似乎”Crash”了，下面是当时查看集群的pod情况的输出：

# kubectl get pod --all-namespaces -o wide

NAMESPACE                    NAME                                    READY     STATUS             RESTARTS   AGE       IP             NODE
default                      ceph-pod2                               1/1       Unknown            0          26m       172.30.192.4   iz2ze39jeyizepdxhwqci6z
default                      ceph-pod2-with-secret                   1/1       Unknown            0          38m       172.30.192.2   iz2ze39jeyizepdxhwqci6z
default                      ceph-pod2-with-secret-on-master         1/1       Unknown            0          34m       172.30.0.51    iz25beglnhtz
default                      nginx-kit-3630450072-2c0jk              0/2       Pending            0          12m       <none>
default                      nginx-kit-3630450072-3n50m              2/2       Unknown            20         35d       172.30.0.44    iz25beglnhtz
default                      nginx-kit-3630450072-90v4q              0/2       Pending            0          12m       <none>
default                      nginx-kit-3630450072-j8qrk              2/2       Unknown            20         72d       172.30.0.47    iz25beglnhtz
kube-system                  dummy-2088944543-9382n                  1/1       Running            0          12m       xx.xx.xx.xx   yypdmaster
kube-system                  dummy-2088944543-93f4c                  1/1       Unknown            16         130d      xx.xx.xx.xx   iz25beglnhtz
kube-system                  elasticsearch-logging-v1-dhl35          1/1       Running            0          12m       172.30.192.6   yypdnode
kube-system                  elasticsearch-logging-v1-s3sbj          1/1       Unknown            9          35d       172.30.0.45    iz25beglnhtz
kube-system                  elasticsearch-logging-v1-t8wg0          1/1       Unknown            29         68d       172.30.0.43    iz25beglnhtz
kube-system                  elasticsearch-logging-v1-zdp19          1/1       Running            0          12m       172.30.0.3     yypdmaster
kube-system                  etcd-iz25beglnhtz                       1/1       Unknown            17         130d      xx.xx.xx.xx   iz25beglnhtz
kube-system                  etcd-yypdmaster                         1/1       Running            17         17m       xx.xx.xx.xx   yypdmaster
kube-system                  fluentd-es-v1.22-ggvv4                  1/1       NodeLost           24         68d       172.30.0.46    iz25beglnhtz
kube-system                  fluentd-es-v1.22-rj871                  1/1       Running            0          17m       172.30.0.1     yypdmaster
kube-system                  fluentd-es-v1.22-xn77x                  1/1       NodeLost           0          6d        172.30.192.0   iz2ze39jeyizepdxhwqci6z
kube-system                  fluentd-es-v1.22-z82rz                  1/1       Running            0          18m       172.30.192.5   yypdnode
kube-system                  kibana-logging-3746979809-dplzv         1/1       Running            0          12m       172.30.0.4     yypdmaster
kube-system                  kibana-logging-3746979809-lq9m3         1/1       Unknown            9          35d       172.30.0.49    iz25beglnhtz
kube-system                  kube-apiserver-iz25beglnhtz             1/1       Unknown            19         104d      xx.xx.xx.xx   iz25beglnhtz
kube-system                  kube-apiserver-yypdmaster               1/1       Running            19         17m       xx.xx.xx.xx   yypdmaster
kube-system                  kube-controller-manager-iz25beglnhtz    1/1       Unknown            21         130d      xx.xx.xx.xx   iz25beglnhtz
kube-system                  kube-controller-manager-yypdmaster      1/1       Running            21         17m       xx.xx.xx.xx   yypdmaster
kube-system                  kube-discovery-1769846148-wh1z4         1/1       Unknown            12         73d       xx.xx.xx.xx   iz25beglnhtz
kube-system                  kube-discovery-1769846148-z2v87         0/1       Pending            0          12m       <none>
kube-system                  kube-dns-2924299975-206tg               4/4       Unknown            129        130d      172.30.0.48    iz25beglnhtz
kube-system                  kube-dns-2924299975-g1kks               4/4       Running            0          12m       172.30.0.5     yypdmaster
kube-system                  kube-proxy-3z29k                        1/1       Running            0          18m       yy.yy.yy.yy    yypdnode
kube-system                  kube-proxy-kfzxv                        1/1       Running            0          17m       xx.xx.xx.xx   yypdmaster
kube-system                  kube-proxy-n2xmf                        1/1       NodeLost           16         130d      xx.xx.xx.xx   iz25beglnhtz

观察这个输出，我们看到几点异常：

• 不常见的Pod状态：Unknown、NodeLost
• Node一列居然出现了四个Node: yypdmaster、yypdnode、 iz25beglnhtz和 iz2ze39jeyizepdxhwqci6z

等了一会儿，这种状态依然不见好转。我于是重启了master上的kubelet、重启了两个节点上的docker engine，不过启动后问题依旧！

查看Running状态的Pod情况：

# kubectl get pod --all-namespaces -o wide|grep Running
kube-system                  dummy-2088944543-9382n                  1/1       Running            0          18m       xx.xx.xx.xx   yypdmaster
kube-system                  elasticsearch-logging-v1-dhl35          1/1       Running            0          18m       172.30.192.6   yypdnode
kube-system                  elasticsearch-logging-v1-zdp19          1/1       Running            0          18m       172.30.0.3     yypdmaster
kube-system                  etcd-yypdmaster                         1/1       Running            17         23m       xx.xx.xx.xx   yypdmaster
kube-system                  fluentd-es-v1.22-rj871                  1/1       Running            0          23m       172.30.0.1     yypdmaster
kube-system                  fluentd-es-v1.22-z82rz                  1/1       Running            0          24m       172.30.192.5   yypdnode
kube-system                  kibana-logging-3746979809-dplzv         1/1       Running            0          18m       172.30.0.4     yypdmaster
kube-system                  kube-apiserver-yypdmaster               1/1       Running            19         23m       xx.xx.xx.xx   yypdmaster
kube-system                  kube-controller-manager-yypdmaster      1/1       Running            21         23m       xx.xx.xx.xx   yypdmaster
kube-system                  kube-dns-2924299975-g1kks               4/4       Running            0          18m       172.30.0.5     yypdmaster
kube-system                  kube-proxy-3z29k                        1/1       Running            0          24m       yy.yy.yy.yy    yypdnode
kube-system                  kube-proxy-kfzxv                        1/1       Running            0          23m       xx.xx.xx.xx   yypdmaster
kube-system                  kube-scheduler-yypdmaster               1/1       Running            22         23m       xx.xx.xx.xx   yypdmaster
kube-system                  kubernetes-dashboard-3109525988-cj74d   1/1       Running            0          18m       172.30.0.6     yypdmaster
mioss-namespace-s0fcvegcmw   console-sm7cg2-101699315-f3g55          1/1       Running            0          18m       172.30.0.7     yypdmaster

似乎Kubernetes集群并未真正”Crash”，但从Node列来看，正常的pod归属的node不是yypdmaster就是yypdnode， iz25beglnhtz和 iz2ze39jeyize

Kubernetes集群搭建起来后，一直跑得很稳定。之前的关注点更多集中在安装、配置、组件调试方面，一些细枝末节被忽略了。Pod中时区的设置就是其中之一。今天腾出功夫打算解决一下这个问题。

一、问题现象

在我的Kubernetes 1.3.7集群的Master Node上，我们执行：

# date
Mon Feb 20 11:49:20 CST 2017

之后，在该Node上随意找到一个Pod中的Container，通过docker exec切入到容器内执行：

# docker exec -it 1975d68de07a /bin/bash
root@1975d68de07a:/# date
Mon Feb 20 03:49:53 UTC 2017

我们发现Docker内输出的当前date与Host上输出的date是不一致的。这对于K8s集群自身的运转似乎并没有多大影响，至少运行这么长时间以来，未出现因为时间设置与Host不同而导致的问题。但是对跑在Pod中应用来说，这个时间设置的问题可能会给业务的运行带来很多烦恼。

总之，一般来说，让Pod里的时间设置与Host上的Local time设置保持一致总是没错的。这里我们就来尝试解决这个问题。

二、Pod使用Host时区设置的方案

我有两个K8s集群环境，一个是基于ubuntu 14.04 node的k8s 1.3.7 环境，一个是基于ubuntu 16.04 node以kubeadm安装的k8s 1.5.1环境。由于ubuntu 14.04和ubuntu 16.04 Host在timezone的设置上略有差异，因此我们也要分为几种情况对应(redhat系的os这里暂不涉及，但原理是相同的)：

0、ubuntu上时区设置

在Ubuntu上，/etc/localtime是系统的本地时区设置文件，直接影响到系统的当前date输出。不过在Ubuntu 14.04和Ubuntu 16.04上，这个文件的内容稍有不同：

在Ubuntu 14.04上，/etc/localtime就是一个regular file，其存储着本地时区的配置数据：

# file /etc/localtime
/etc/localtime: timezone data, version 2, 2 gmt time flags, 2 std time flags, no leap seconds, 16 transition times, 2 abbreviation chars

在我的Node上，其内容与/usr/share/zoneinfo/Asia/Shanghai指向的内容一致，好像/etc/localtime是这么得来的：

cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime

而在Ubuntu 16.04上，/etc/localtime是一个symbolic link，链接到文件：/usr/share/zoneinfo/Asia/Shanghai

# file  /etc/localtime
/etc/localtime: symbolic link to /usr/share/zoneinfo/Asia/Shanghai

/usr/share/zoneinfo下存储着真正的时区设置文件，/usr/share/zoneinfo/Asia/Shanghai也是一个符号链接，指向的是/usr/share/zoneinfo/PRC：

# file /usr/share/zoneinfo/PRC
/usr/share/zoneinfo/PRC: timezone data, version 2, 2 gmt time flags, 2 std time flags, no leap seconds, 16 transition times, 2 abbreviation chars

在14.04 Node上，/etc/localtime与/usr/share/zoneinfo/PRC文件的内容是一模一样的。但在14.04的Pod中，这两个文件内容却是不同的：

# docker exec -it fe936562b6ee /bin/bash
# diff /etc/localtime /usr/share/zoneinfo/PRC
Binary files /etc/localtime and /usr/share/zoneinfo/PRC differ

因此，如果要让Pod使用的本地时区设置与Host的一致，就必须在Pod的manifest中做些“手脚”，接下来我们来分门别类地仔细看看。

1、Host 14.04，Pod 16.04

我们在14.04的node上随意run一个16.04的容器，可以看到：

# docker run -it ubuntu:16.04 /bin/bash
root@bf7cec08df23:/# ls -l /etc/localtime
lrwxrwxrwx 1 root root 27 Jan 19 16:33 /etc/localtime -> /usr/share/zoneinfo/Etc/UTC

容器内的系统时间与host时间是不一致的。

我们来创建一个使用ubuntu 16.04的docker image:

//1604pod-image-dockerfile
FROM ubuntu:16.04

CMD ["tail", "-f", "/var/log/bootstrap.log"]

在本地构建这个image：

# docker build -f ./1604pod-image-dockerfile -t 1604podimage:latest .
Sending build context to Docker daemon 5.632 kB
Step 1 : FROM ubuntu:16.04
 ---> f49eec89601e
Step 2 : CMD tail -f /var/log/bootstrap.log
 ---> Using cache
 ---> 06ffb5c85d7c
Successfully built 06ffb5c85d7c

# docker images|grep 1604pod
1604podimage                                                  latest              06ffb5c85d7c        28 minutes ago      129.5 MB

我们来编写这个运行于16.04之上的pod的manifest文件：

//1604-pod-on-1404-host.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-testpod
spec:
  replicas: 1
  template:
    metadata:
      labels:
        run: my-testpod
    spec:
      containers:
      - name: my-testpod
        image: 1604podimage:latest
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - name: tz-config
          mountPath: /etc/localtime
      volumes:
      - name: tz-config
        hostPath:
          path: /usr/share/zoneinfo/Asia/Shanghai

我们将/usr/share/zoneinfo/Asia/Shanghai直接挂载为路径/etc/locatime了。创建该Pod并检查Pod内的系统时间：

# kubectl create -f 1604-pod-on-1404-host.yaml
deployment "my-testpod" created

# kubectl exec my-testpod-802169720-ehqlt date
Mon Feb 20 14:19:13 CST 2017

# date
Mon Feb 20 14:19:15 CST 2017

可以看出Pod内的系统时间与Host上的时间在时区上保持一致了。

2、Host 14.04， Pod 14.04

在ubuntu 14.04中，由于/etc/localtime自身就存储着时区设置，因此我们需要将其mount到Pod的对应位置中。我们的image demo如下：

//1404pod-image-dockerfile
FROM ubuntu:14.04

CMD ["tail", "-f", "/var/log/bootstrap.log"]

构建该image：

# docker build -f ./1404pod-image-dockerfile -t 1404podimage:latest .
Sending build context to Docker daemon 5.632 kB
Step 1 : FROM ubuntu:14.04
 ---> f2d8ce9fa988
Step 2 : CMD tail -f /var/log/bootstrap.log
 ---> Running in 6815ca6fe9d9
 ---> bc7f7de7690d
Removing intermediate container 6815ca6fe9d9
Successfully built bc7f7de7690d

# docker images|grep 1404pod
1404podimage                                                  latest              bc7f7de7690d        8 seconds ago       187.9 MB

Pod manifest如下：

//1404-pod-on-1404-host.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-testpod
spec:
  replicas: 1
  template:
    metadata:
      labels:
        run: my-testpod
    spec:
      containers:
      - name: my-testpod
        image: 1404podimage:latest
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - name: tz-config
          mountPath: /etc/localtime
      volumes:
      - name: tz-config
        hostPath:
          path: /etc/localtime

可以看到，我们将host的/etc/locatime挂载到Pod内的/etc/localtime。创建该Pod后，我们查看一下Pod内的系统时间：

# kubectl exec my-testpod-2443385716-g9d4n date
Mon Feb 20 14:44:57 CST 2017

# date
Mon Feb 20 14:44:59 CST 2017

可以看出：两者在时区设置上已经一致了。

3、Host 16.04，Pod 16.04

由于有了上面的铺垫，后续的这两种情况，鉴于篇幅，我将简单描述。这里我们还将利用上面创建的两个image：1404podimage:latest和1604podimage:latest。

pod的manifest文件如下：

//1604-pod-on-1604-host.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-testpod
spec:
  replicas: 1
  template:
    metadata:
      labels:
        run: my-testpod
    spec:
      containers:
      - name: my-testpod
        image: 1604podimage:latest
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - name: tz-config
          mountPath: /etc/localtime
      volumes:
      - name: tz-config
        hostPath:
          path: /usr/share/zoneinfo/Asia/Shanghai

创建该Pod后，查看系统时间：

# kubectl exec my-testpod-3193072711-7kwdl date
Mon Feb 20 14:55:00 CST 2017

# date
Mon Feb 20 14:55:31 CST 2017

主机和Pod内的系统时间在时区上一致了。

4、Host 16.04，Pod 14.04

pod的manifest文件如下：

//1404-pod-on-1604-host.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-testpod
spec:
  replicas: 1
  template:
    metadata:
      labels:
        run: my-testpod
    spec:
      containers:
      - name: my-testpod
        image: 1404podimage:latest
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - name: tz-config
          mountPath: /etc/localtime
      volumes:
      - name: tz-config
        hostPath:
          path: /usr/share/zoneinfo/Asia/Shanghai

创建该Pod，对比Pod内时间和host时间：

# kubectl exec my-testpod-3024383045-xqbcv date
Mon Feb 20 14:58:54 CST 2017

# date
Mon Feb 20 14:58:49 CST 2017

主机和Pod内的系统时间在时区上一致了。

三、小结

上面所涉及到的manifest文件和Dockerfile文件源码在这里可以下载到，你可能需要根据你自己的k8s环境做些许改动。

微博：@tonybai_cn
微信公众号：iamtonybai
github.com账号: https://github.com/bigwhite