在Kubernetes Pod中使用Service Account访问API Server

Kubernetes API Server是整个Kubernetes集群的核心,我们不仅有从集群外部访问API Server的需求,有时,我们还需要从Pod的内部访问API Server。

然而,在生产环境中,Kubernetes API Server都是“设防”的。在《Kubernetes集群的安全配置》一文中,我提到过:Kubernetes通过client cert、static token、basic auth等方法对客户端请求进行身份验证。对于运行于Pod中的Process而言,有些时候这些方法是适合的,但有些时候,像client cert、static token或basic auth这些信息是不便于暴露给Pod中的Process的。并且通过这些方法通过API Server验证后的请求是具有全部授权的,可以任意操作Kubernetes cluster,这显然是不能满足安全要求的。为此,Kubernetes更推荐大家使用service account这种方案的。本文就带大家详细说说如何通过service account从一个Pod中访问API Server的。

零、试验环境

本文的试验环境是Kubernetes 1.3.7 cluster,双节点,master承载负荷。cluster通过kube-up.sh搭建的,具体的搭建方法见《一篇文章带你了解Kubernetes安装》。

一、什么是service account?

什么是service account? 顾名思义,相对于user account(比如:kubectl访问APIServer时用的就是user account),service account就是Pod中的Process用于访问Kubernetes API的account,它为Pod中的Process提供了一种身份标识。相比于user account的全局性权限,service account更适合一些轻量级的task,更聚焦于授权给某些特定Pod中的Process所使用。

service account作为一种resource存在于Kubernetes cluster中,我们可以通过kubectl获取当前cluster中的service acount列表:

# kubectl get serviceaccount --all-namespaces
NAMESPACE                    NAME           SECRETS   AGE
default                      default        1         140d
kube-system                  default        1         140d

我们查看一下kube-system namespace下名为”default”的service account的详细信息:

# kubectl describe serviceaccount/default -n kube-system
Name:        default
Namespace:    kube-system
Labels:        <none>

Image pull secrets:    <none>

Mountable secrets:     default-token-hpni0

Tokens:                default-token-hpni0

我们看到service account并不复杂,只是关联了一个secret资源作为token,该token也叫service-account-token,该token才是真正在API Server验证(authentication)环节起作用的:

# kubectl get secret  -n kube-system
NAME                  TYPE                                  DATA      AGE
default-token-hpni0   kubernetes.io/service-account-token   3         140d

# kubectl get secret default-token-hpni0 -o yaml -n kube-system
apiVersion: v1
data:
  ca.crt: {base64 encoding of ca.crt data}
  namespace: a3ViZS1zeXN0ZW0=
  token: {base64 encoding of bearer token}

kind: Secret
metadata:
  annotations:
    kubernetes.io/service-account.name: default
    kubernetes.io/service-account.uid: 90ded7ff-9120-11e6-a0a6-00163e1625a9
  creationTimestamp: 2016-10-13T08:39:33Z
  name: default-token-hpni0
  namespace: kube-system
  resourceVersion: "2864"
  selfLink: /api/v1/namespaces/kube-system/secrets/default-token-hpni0
  uid: 90e71909-9120-11e6-a0a6-00163e1625a9
type: kubernetes.io/service-account-token

我们看到这个类型为service-account-token的secret资源包含的数据有三部分:ca.crt、namespace和token。

  • ca.crt
    这个是API Server的CA公钥证书,用于Pod中的Process对API Server的服务端数字证书进行校验时使用的;

  • namespace
    这个就是Secret所在namespace的值的base64编码:# echo -n “kube-system”|base64 => “a3ViZS1zeXN0ZW0=”

  • token

这是一段用API Server私钥签发(sign)的bearer tokens的base64编码,在API Server authenticating环节,它将派上用场。

二、API Server的service account authentication(身份验证)

前面说过,service account为Pod中的Process提供了一种身份标识,在Kubernetes的身份校验(authenticating)环节,以某个service account提供身份的Pod的用户名为:

system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT)

以上面那个kube-system namespace下的“default” service account为例,使用它的Pod的username全称为:

system:serviceaccount:kube-system:default

有了username,那么credentials呢?就是上面提到的service-account-token中的token。在《Kubernetes集群的安全配置》一文中我们谈到过,API Server的authenticating环节支持多种身份校验方式:client cert、bearer token、static password auth等,这些方式中有一种方式通过authenticating(Kubernetes API Server会逐个方式尝试),那么身份校验就会通过。一旦API Server发现client发起的request使用的是service account token的方式,API Server就会自动采用signed bearer token方式进行身份校验。而request就会使用携带的service account token参与验证。该token是API Server在创建service account时用API server启动参数:–service-account-key-file的值签署(sign)生成的。如果–service-account-key-file未传入任何值,那么将默认使用–tls-private-key-file的值,即API Server的私钥(server.key)。

通过authenticating后,API Server将根据Pod username所在的group:system:serviceaccounts和system:serviceaccounts:(NAMESPACE)的权限对其进行authorityadmission control两个环节的处理。在这两个环节中,cluster管理员可以对service account的权限进行细化设置。

三、默认的service account

Kubernetes会为每个cluster中的namespace自动创建一个默认的service account资源,并命名为”default”:

# kubectl get serviceaccount --all-namespaces
NAMESPACE                    NAME           SECRETS   AGE
default                      default        1         140d
kube-system                  default        1         140d

如果Pod中没有显式指定spec.serviceAccount字段值,那么Kubernetes会将该namespace下的”default” service account自动mount到在这个namespace中创建的Pod里。我们以namespace “default”为例,我们查看一下其中的一个Pod的信息:

# kubectl describe pod/index-api-2822468404-4oofr
Name:        index-api-2822468404-4oofr
Namespace:    default
... ...

Containers:
  index-api:
   ... ...
    Volume Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-40z0x (ro)
    Environment Variables:    <none>
... ...
Volumes:
... ...
  default-token-40z0x:
    Type:    Secret (a volume populated by a Secret)
    SecretName:    default-token-40z0x

QoS Class:    BestEffort
Tolerations:    <none>
No events.

可以看到,kubernetes将default namespace中的service account “default”的service account token挂载(mount)到了Pod中容器的/var/run/secrets/kubernetes.io/serviceaccount路径下。

深入容器内部,查看mount的serviceaccount路径下的结构:

# docker exec 3d11ee06e0f8 ls  /var/run/secrets/kubernetes.io/serviceaccount
ca.crt
namespace
token

这三个文件与上面提到的service account的token中的数据是一一对应的。

四、default service account doesn’t work

上面提到过,每个Pod都会被自动挂载一个其所在namespace的default service account,该service account用于该Pod中的Process访问API Server时使用。Pod中的Process该怎么用这个service account呢?Kubernetes官方提供了一个client-go项目可以为你演示如何使用service account访问API Server。这里我们就基于client-go项目中的examples/in-cluster/main.go来测试一下是否能成功访问API Server。

先下载client-go源码:

# go get k8s.io/client-go

# ls -F
CHANGELOG.md  dynamic/   Godeps/     INSTALL.md   LICENSE   OWNERS  plugin/    rest/     third_party/  transport/  vendor/
discovery/    examples/  informers/  kubernetes/  listers/  pkg/    README.md  testing/  tools/        util/

我们改造一下examples/in-cluster/main.go,考虑到panic会导致不便于观察Pod日志,我们将panic改为输出到“标准输出”,并且不return,让Pod周期性的输出相关日志,即便fail:

// k8s.io/client-go/examples/in-cluster/main.go
... ...
func main() {
    // creates the in-cluster config
    config, err := rest.InClusterConfig()
    if err != nil {
        fmt.Println(err)
    }
    // creates the clientset
    clientset, err := kubernetes.NewForConfig(config)
    if err != nil {
        fmt.Println(err)
    }
    for {
        pods, err := clientset.CoreV1().Pods("").List(metav1.ListOptions{})
        if err != nil {
            fmt.Println(err)
        } else {
            fmt.Printf("There are %d pods in the cluster\n", len(pods.Items))
        }
        time.Sleep(10 * time.Second)
    }
}

基于该main.go的go build默认输出,创建一个简单的Dockerfile:

From ubuntu:14.04
MAINTAINER Tony Bai <bigwhite.cn@gmail.com>

COPY main /root/main
RUN chmod +x /root/main
WORKDIR /root
ENTRYPOINT ["/root/main"]

构建一个测试用docker image:

# docker build -t k8s/example1:latest .
... ...

# docker images|grep k8s
k8s/example1                                                  latest              ceb3efdb2f91        14 hours ago        264.4 MB

创建一份deployment manifest:

//main.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: k8s-example1
spec:
  replicas: 1
  template:
    metadata:
      labels:
        run: k8s-example1
    spec:
      containers:
      - name: k8s-example1
        image: k8s/example1:latest
        imagePullPolicy: IfNotPresent

我们来创建该deployment(kubectl create -f main.yaml -n kube-system),观察Pod中的main程序能否成功访问到API Server:

# kubectl logs k8s-example1-1569038391-jfxhx
the server has asked for the client to provide credentials (get pods)
the server has asked for the client to provide credentials (get pods)

API Server log(/var/log/upstart/kube-apiserver.log):

E0302 15:45:40.944496   12902 handlers.go:54] Unable to authenticate the request due to an error: crypto/rsa: verification error
E0302 15:45:50.946598   12902 handlers.go:54] Unable to authenticate the request due to an error: crypto/rsa: verification error
E0302 15:46:00.948398   12902 handlers.go:54] Unable to authenticate the request due to an error: crypto/rsa: verification error

出错了!kube-system namespace下的”default” service account似乎不好用啊!(注意:这是在kubernetes 1.3.7环境)。

五、创建一个新的自用的service account

在kubernetes github issues中,有好多issue是关于”default” service account不好用的问题,给出的解决方法似乎都是创建一个新的service account。

service account的创建非常简单,我们创建一个serviceaccount.yaml:

//serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: k8s-example1

创建该service account:

# kubectl create -f serviceaccount.yaml
serviceaccount "k8s-example1" created

# kubectl get serviceaccount
NAME           SECRETS   AGE
default        1         139d
k8s-example1   1         12s

修改main.yaml,让Pod显示使用这个新的service account:

//main.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: k8s-example1
spec:
  replicas: 1
  template:
    metadata:
      labels:
        run: k8s-example1
    spec:
      serviceAccount: k8s-example1
      containers:
      - name: k8s-example1
        image: k8s/example1:latest
        imagePullPolicy: IfNotPresent

好了,我们重新创建该deployment,查看Pod日志:

# kubectl logs k8s-example1-456041623-rqj87
There are 14 pods in the cluster
There are 14 pods in the cluster
... ...

我们看到main程序使用新的service account成功通过了API Server的身份验证环节,并获得了cluster的相关信息。

六、尾声

在我的另外一个使用kubeadm安装的k8s 1.5.1环境中,我重复做了上面这个简单测试,不同的是这次我直接使用了default service account。在k8s 1.5.1下,pod的执行结果是ok的,也就是说通过default serviceaccount,我们的client-go in-cluster example程序可以顺利通过API Server的身份验证,获取到相关的Pods元信息。

七、参考资料


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

Kubernetes集群Pod使用Host的本地时区设置

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

Kubernetes Pod无法挂载ceph RBD存储卷的临时解决方法

所有涉及到存储的地方都是极易出现“坑”的地方,Kubernetes也不例外。

一、问题起因

问题始于昨天升级一个stateful service的操作。该service下的Pod挂载了使用ceph RBD提供的一个Persistent Volume。该Pod是用普通deployment部署的,并没有使用处于alpha状态的PetSet。改动仅仅是image的版本发生了变化。我执行的操作如下:

# kubectl apply -f index-api.yaml

操作是成功的。但命令执行后,再次查看index-api这个Pod的状态,该Pod的状态长期处于:“ContainerCreating”,显然Pod没能重启成功。

进一步通过describe pod 检视events,发现如下Warning:

events:
  FirstSeen    LastSeen    Count    From            SubobjectPath    Type        Reason        Message
  ---------    --------    -----    ----            -------------    --------    ------        -------
  2m        2m        1    {default-scheduler }            Normal        Scheduled    Successfully assigned index-api-3362878852-9tm9j to 10.46.181.146
  11s        11s        1    {kubelet 10.46.181.146}            Warning        FailedMount    Unable to mount volumes for pod "index-api-3362878852-9tm9j_default(ad89c829-f40b-11e6-ad11-00163e1625a9)": timeout expired waiting for volumes to attach/mount for pod "index-api-3362878852-9tm9j"/"default". list of unattached/unmounted volumes=[index-api-pv]
  11s        11s        1    {kubelet 10.46.181.146}            Warning        FailedSync    Error syncing pod, skipping: timeout expired waiting for volumes to attach/mount for pod "index-api-3362878852-9tm9j"/"default". list of unattached/unmounted volumes=[index-api-pv]

index-api这个Pod尝试挂载index-api-pv这个pv超时,并失败。

二、问题探索和临时解决

首先查看问题pod所在Node(10.46.181.146)上的kubelet日志,kubelet负责与本地的docker engine以及其他本地服务交互:

... ...
I0216 13:59:27.380007    1159 reconciler.go:294] MountVolume operation started for volume "kubernetes.io/rbd/7e6c415a-f40c-11e6-ad11-00163e1625a9-index-api-pv" (spec.Name: "index-api-pv") to pod "7e6c415a-f40c-11e6-ad11-00163e1625a9" (UID: "7e6c415a-f40c-11e6-ad11-00163e1625a9").
E0216 13:59:27.393946    1159 disk_manager.go:56] failed to attach disk
E0216 13:59:27.394013    1159 rbd.go:228] rbd: failed to setup mount /var/lib/kubelet/pods/7e6c415a-f40c-11e6-ad11-00163e1625a9/volumes/kubernetes.io~rbd/index-api-pv rbd: image index-api-image is locked by other nodes
E0216 13:59:27.394121    1159 nestedpendingoperations.go:254] Operation for "\"kubernetes.io/rbd/7e6c415a-f40c-11e6-ad11-00163e1625a9-index-api-pv\" (\"7e6c415a-f40c-11e6-ad11-00163e1625a9\")" failed. No retries permitted until 2017-02-16 14:01:27.394076217 +0800 CST (durationBeforeRetry 2m0s). Error: MountVolume.SetUp failed for volume "kubernetes.io/rbd/7e6c415a-f40c-11e6-ad11-00163e1625a9-index-api-pv" (spec.Name: "index-api-pv") pod "7e6c415a-f40c-11e6-ad11-00163e1625a9" (UID: "7e6c415a-f40c-11e6-ad11-00163e1625a9") with: rbd: image index-api-image is locked by other nodes
E0216 13:59:32.695919    1159 kubelet.go:1958] Unable to mount volumes for pod "index-api-3362878852-pzxm8_default(7e6c415a-f40c-11e6-ad11-00163e1625a9)": timeout expired waiting for volumes to attach/mount for pod "index-api-3362878852-pzxm8"/"default". list of unattached/unmounted volumes=[index-api-pv]; skipping pod
E0216 13:59:32.696223    1159 pod_workers.go:183] Error syncing pod 7e6c415a-f40c-11e6-ad11-00163e1625a9, skipping: timeout expired waiting for volumes to attach/mount for pod "index-api-3362878852-pzxm8"/"default". list of unattached/unmounted volumes=[index-api-pv]
... ...

通过kubelet的日志我们可以看出调度到10.46.181.146这个Node上的index-api pod之所以无法挂载ceph RBD volume,是因为index-api-image已经被其他node锁住。

我的这个小集群一共就只有两个Node(10.46.181.146和10.47.136.60),那锁住index-api-image的就是10.47.136.60这个node了。我们查看一下平台上pv和pvc的状态:

# kubectl get pv
NAME           CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM                   REASON    AGE
ceph-pv        1Gi        RWO           Recycle         Bound     default/ceph-claim                101d
index-api-pv   2Gi        RWO           Recycle         Bound     default/index-api-pvc             49d

# kubectl get pvc
NAME            STATUS    VOLUME         CAPACITY   ACCESSMODES   AGE
ceph-claim      Bound     ceph-pv        1Gi        RWO           101d
index-api-pvc   Bound     index-api-pv   2Gi        RWO           49d

index-api-pv和index-api-pvc的状态都是正常的,从这里看不出lock的情况。无奈我只能从ceph这个层面去查问题了!

index-api-image在mioss pool下面,我们利用ceph的rbd cli工具查看一下其状态:

# rbd ls mioss
index-api-image

# rbd info mioss/index-api-image
rbd image 'index-api-image':
    size 2048 MB in 512 objects
    order 22 (4096 kB objects)
    block_name_prefix: rb.0.5e36.1befd79f
    format: 1

# rbd disk-usage mioss/index-api-image
warning: fast-diff map is not enabled for index-api-image. operation may be slow.
NAME            PROVISIONED USED
index-api-image       2048M 168M

index-api-image状态ok。

如果你在执行rbd时,出现下面错误:

# rbd
rbd: error while loading shared libraries: /usr/lib/x86_64-linux-gnu/libicudata.so.52: invalid ELF header

可以通过重装libicu52这个包(这里演示的是基于ubuntu 14.04 amd64的版本)来解决:

# wget -c http://security.ubuntu.com/ubuntu/pool/main/i/icu/libicu52_52.1-3ubuntu0.4_amd64.deb
# dpkg -i ./libicu52_52.1-3ubuntu0.4_amd64.deb

回归正题!

经查manual发现,rbd提供了lock相关子命令可以查看image的lock list:

# rbd lock list  mioss/index-api-image
There is 1 exclusive lock on this image.
Locker       ID                       Address
client.24128 kubelet_lock_magic_node1 10.47.136.60:0/1864102866

真凶找到!我们看到位于10.47.136.60 node上有一个locker将该image锁住。我尝试重启10.47.136.60上的kubelet,发现重启后,lock依旧。

怎么取消这个锁呢?rbd不光提供了lock list命令,还提供了lock remove命令:

lock remove (lock rm)       Release a lock on an image

usage:
      lock remove image-spec lock-id locker
              Release a lock on an image. The lock id and locker are as output by lock ls.

开始解锁:

# rbd lock remove  mioss/index-api-image   kubelet_lock_magic_node1 client.24128

解锁成功后,delete掉那个处于ContainerCreating的Pod,然后index-api pod就启动成功了:

NAMESPACE                    NAME                                    READY     STATUS    RESTARTS   AGE       IP             NODE            LABELS
default                      index-api-3362878852-m6k0j              1/1       Running   0          10s       172.16.57.7    10.46.181.146   app=index-api,pod-template-hash=3362878852

三、问题简要分析

从问题现象来看,起因是由于index-api pod被从10.47.136.60这个node调度到 10.46.181.146这个node上而导致的。但是为什么image的lock没有释放的确怪异,因为我的index-api是捕捉pod退回信号,支持优雅退出的:

# kubectl delete -f index-api-deployment.yaml
deployment "index-api" deleted

2017/02/16 08:41:27 1 Received SIGTERM.
2017/02/16 08:41:27 1 [::]:30080 Listener closed.
2017/02/16 08:41:27 1 Waiting for connections to finish...
2017/02/16 08:41:27 [C] [asm_amd64.s:2086] ListenAndServe:  accept tcp [::]:30080: use of closed network connection 1
2017/02/16 08:41:27 [I] [engine.go:109] engine[mioss1(online)]: mioss1-29583fe44a637eabe4f865bc59bde44fa307e38e exit!
2017/02/16 08:41:27 [I] [engine.go:109] engine[wx81f621e486239f6b(online)]: wx81f621e486239f6b-58b5643015a5f337931aaa4a5f4db1b35ac784bb exit!
2017/02/16 08:41:27 [I] [engine.go:109] engine[wxa4d49c280cefd38c(online)]: wxa4d49c280cefd38c-f38959408617862ed69dab9ad04403cee9564353 exit!
2017/02/16 08:41:27 [D] [enginemgr.go:310] Search Engines exit ok

因此,初步猜测:这里很可能是kubernetes在监视和处理pod退出时,对于存储插件的状态处理存在一些bug,至于具体什么问题,还不得而知。

四、小结

对于像index-api service这样的stateful服务来说,使用普通deployment显然不能满足要求。Kubernetes在[1.3.0, 1.5.0)版本区间提供了处于alpha状态的PetSet controller,在1.5.0版本后,PetSet被改名为StatefulSet。与普通Pod不同,PetSet下面的每个Pet都有严格的身份属性,并根据身份属性绑定一定资源,并且不会像普通Pod那样被Kubernetes随意调度到任意Node上。

像index-api-service索引服务这样的一个实例绑定一个cephRBD pv的应用,特别适合使用PetSet或StatefulSet,不过我这里尚未测试用上PetSet后是否还会出现无法挂载rbd卷的问题。


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




这里是Tony Bai的个人Blog,欢迎访问、订阅和留言!订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:


以太币:


如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多