摘要：舉個(gè)例子，我們在這種狀態(tài)下創(chuàng)建一個(gè)，然后執(zhí)行在中會(huì)發(fā)現(xiàn)有了字段，并且裝載了一個(gè)是的，這個(gè)就是我們這個(gè)下的。

注：本案例在我的部署環(huán)境下是可行的，但不保證在所有環(huán)境下都可行。我盡可能講得直白而詳細(xì)，因?yàn)槲易约阂膊艅傞_始接觸，已經(jīng)做過深入研究的可以瀏覽，若有什么錯(cuò)誤，煩請(qǐng)指正，感激不盡！

我的環(huán)境： K8S1.0.0+flannel+docker1.6的分布式集群。

這里先不贅述flannel的部署了，以后有時(shí)間再寫相關(guān)的文檔。

先講講kubernetes的serviceaccount，我們的服務(wù)有時(shí)候需要一些帶有隱私信息的東西，token，certification file等等，這些東西我們可以在master上創(chuàng)建，然后在創(chuàng)建pod的時(shí)候?qū)脒M(jìn)去。具體可以去看github上的secret.md，那里有具體的例子。

我們執(zhí)行：

kubectl get serviceaccount

如果如下：

NAME      SECRETS
default   1

那么是正常的（用腳本啟動(dòng)的kubernetes一般會(huì)是這樣的情況） 而如果是：

NAME      SECRETS
default   0

這就麻煩了，用腳本啟動(dòng)k8s，啟動(dòng)的時(shí)候是會(huì)自動(dòng)創(chuàng)建一個(gè)serviceaccount的，而serviceaccount創(chuàng)建出來的時(shí)候又會(huì)自動(dòng)創(chuàng)建一個(gè)secret作為這個(gè)serviceaccount的token。

我們在apiserver的啟動(dòng)參數(shù)中添加：

--admission_control=ServiceAccount

apiserver在啟動(dòng)的時(shí)候會(huì)自己創(chuàng)建一個(gè)key和crt（見/var/run/kubernetes/apiserver.crt和apiserver.key）

然后在啟動(dòng)./kube-controller-manager 時(shí)添加flag：

--service_account_private_key_file=/var/run/kubernetes/apiserver.key

這樣啟動(dòng)k8smaster后，我們就會(huì)發(fā)現(xiàn)

kubectl get serviceaccount

結(jié)果如下：

NAME      SECRETS
default   1

注意，這里可能會(huì)啟動(dòng)apiserver失敗，或者啟動(dòng)后沒有效果，因?yàn)闆]有secrets的serviceaccount會(huì)保存在etcd中，所以我們在正常啟動(dòng)前最好刪掉etcd中的舊數(shù)據(jù)（$etcdctl rm --recursive registry）。

正常啟動(dòng)后我們在這種狀態(tài)下創(chuàng)建pod，pod中會(huì)加入serviceaccount這個(gè)字段，即便我們在創(chuàng)建的json或yaml中不指定，那么它的默認(rèn)值也會(huì)是默認(rèn)的serviceaccount：default。 而這個(gè)serviceaccount的secret就會(huì)被導(dǎo)入到pod啟動(dòng)的containers中。 舉個(gè)例子，我們在這種狀態(tài)下創(chuàng)建一個(gè)pod，然后執(zhí)行：

[root@vm-56-65 bin]# kubectl  get pods/imgpod -o yaml

在yaml中會(huì)發(fā)現(xiàn)：

spec:
  containers:
  - image: registry.hub.gome.com.cn/img_server:1.1
    imagePullPolicy: IfNotPresent
    name: imgpod
    resources:
      limits:
        cpu: 600m
        memory: 1181116006400m
    terminationMessagePath: /dev/termination-log
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: default-token-n0i1i
      readOnly: true
  dnsPolicy: ClusterFirst
  nodeName: 10.58.56.62
  restartPolicy: Always
  serviceAccountName: default
  volumes:
  - name: default-token-n0i1i
    secret:
      secretName: default-token-n0i1i

有了serviceaccountName字段，并且volumn裝載了一個(gè)secret.是的，這個(gè)secret：default-token-n0i1i就是我們default這個(gè)serviceaccount下的secret。它被裝載到mountPath: /var/run/secrets/kubernetes.io/serviceaccount目錄中，我們?nèi)绻趕laver上進(jìn)入相關(guān)容器，便可以找到這個(gè)目錄和相應(yīng)的token（注：創(chuàng)建這個(gè)pod的json中不用指定serviceaccount，也不用寫volumn字段去掛載secret，這些都會(huì)自動(dòng)完成的，是否可以手動(dòng)指定呢？期待大神們的指點(diǎn)）。

為什么要先說這些呢？ 因?yàn)槲覀兊膆eapster啟動(dòng)的時(shí)候會(huì)有這種情況： pod狀態(tài)為running，但是反復(fù)地restart；我們用webapi查看該pod的日志，發(fā)現(xiàn)：

/var/run/secret/kubernetes.io/serviceaccount/token no such file or directory

我認(rèn)為這是因?yàn)閔eapster在運(yùn)行時(shí)需要向k8smaster做https的連接，但是沒有token和證書是不能連接的，heapster的程序找不到token就error并exit了，k8s會(huì)再啟動(dòng)之，于是就反復(fù)restart。

如下是我heapster啟動(dòng)的json（一個(gè)replicationcontroller）

heaprep.json:
{
    "apiVersion": "v1",
    "kind": "ReplicationController",
    "metadata": {
        "labels": {
            "name": "heapster"
        },
        "name": "monitoring-heapster-controller"
    },
    "spec": {
        "replicas": 1,
        "selector": {
            "name": "heapster"
        },
        "template": {
            "metadata": {
                "labels": {
                    "name": "heapster"
                }
            },
            "spec": {
                "containers": [
                    {
                        "image": "registry.hub.gome.com.cn/kubernetes/heapster:v0.16.0",
                        "name": "heapster",
            "command":[
                "/heapster",
                "--source=kubernetes:"https://kubernetes:443?auth="",
                "--sink=influxdb:http://10.126.53.10:8086"
            ],
            "resources": {
                        "limits":{
                            "cpu":"0.5",
                            "memory":"1.1Gi"
                        }
                },
             "env": [
              {
                "name": "KUBERNETES_SERVICE_HOST",
                "value": "vm-56-65"
              }
            ]
                    }
                ]
            }
        }
    }
}

這里"env"中的環(huán)境變量是必須要加的，否則heapster會(huì)報(bào)錯(cuò)，具體什么錯(cuò)不大記得了，應(yīng)該是有關(guān)10.0.0.1 這個(gè)域名的（heapster中的KUBERNETES_SERVICE_HOST變量默認(rèn)是10.0.0.1）。 *10.0.0.1是k8s集群中master服務(wù)的ClusterIP（kubectl get svc 就可以看到）,其他slaver是可以通過這個(gè)ip：port訪問到master服務(wù)的。但是因?yàn)閔eapster做的是https的請(qǐng)求，需要crt證書和token。而10.0.0.1不是一個(gè)hostname并且沒有相關(guān)的證書（感覺這是heapster最大的一個(gè)坑），所以我干脆自己做證書，自己做hosts引導(dǎo)，自己做環(huán)境變量。

現(xiàn)在我們需要一個(gè)hostname為vm-56-65的證書，執(zhí)行這些命令：

openssl genrsa -out ca.key 2048

openssl req -x509 -new -nodes -key ca.key -subj "/CN=abc.com" -days 5000 -out ca.crt

openssl genrsa -out server.key 2048

openssl req -new -key server.key -subj "/CN=vm-56-65" -out server.csr

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 5000

注意，這里兩個(gè) -subj "***"中第二個(gè)要寫hostname，且強(qiáng)烈建議第一個(gè)subj和第二個(gè)不要相同(設(shè)為相同可能會(huì)導(dǎo)致普通的curl https命令認(rèn)證失敗)。具體關(guān)于證書的生成，可以參考： http://wangzhezhe.github.io/blog/2015/08/05/httpsandgolang/ 執(zhí)行這些命令后，會(huì)生成一系列文件，將它們一并copy到master的/var/run/kubernetes/中，我們的master啟動(dòng)要用這些證書文件：

./kube-apiserver --logtostderr=true --log-dir=/var/log/ --v=0 --admission_control=ServiceAccount --etcd_servers=http://127.0.0.1:4001 --insecure_bind_address=0.0.0.0 --insecure_port=8080 --kubelet_port=10250 --service-cluster-ip-range=10.0.0.1/24 --allow_privileged=false   --service-node-port-range="30000-35535"   --secure-port=443    --client_ca_file=/var/run/kubernetes/ca.crt  --tls-private-key-file=/var/run/kubernetes/server.key --tls-cert-file=/var/run/kubernetes/server.crt 

這里--secure-port=443 是因?yàn)槲以趆eapster訪問master時(shí)，沒有采用內(nèi)部ClusterIP，而是直接訪問物理IP，而端口沒有變，所以將master上apiserver的https監(jiān)聽端口修改了以便訪問。

這樣啟動(dòng)了apiserver后，我們再重新create pod。 容器啟動(dòng)，我們進(jìn)入pod的日志，看到非常多的：

dial tcp: lookup vm-56-65: no such host

進(jìn)入容器中修改容器里的/etc/hosts，添加一個(gè)：

10.58.56.65 vm-56-65

如前文所說，我這里用了物理ip，當(dāng)然，如果我們這里配10.0.0.1 也是可以的（如果使用10.0.0.1，api-server啟動(dòng)的時(shí)候就不用再添加--secure-port=443了）。 具體怎么進(jìn)容器、改hosts這里我就不細(xì)講了，大家都懂的~

修改完畢后，再刷新幾次pod的日志，會(huì)發(fā)現(xiàn)，日志慢慢就不更新了（或者該說，不報(bào)錯(cuò)了），恭喜你，heapster已經(jīng)在正常跑了。

不止如此，只要再添加一個(gè)token的配置，就可以在任何一臺(tái)能與10.58.56.65直連的機(jī)器上，向apiserver做帶認(rèn)證的https請(qǐng)求。

heapster最大的好處是其抓取的監(jiān)控?cái)?shù)據(jù)可以按pod，container，namespace等方式group，這樣就能進(jìn)行監(jiān)控信息的隱私化，即每個(gè)k8s的用戶只能看到自己的應(yīng)用的資源使用情況，而后臺(tái)管理者又能看到每臺(tái)機(jī)器的資源使用情況，類似自動(dòng)擴(kuò)容之類的功能就有了一個(gè)可靠的信息來源。

以上只是我個(gè)人在部署過程中遇到的問題，不能保證這個(gè)方案100%可行，我也仍在做進(jìn)一步的研究，相信heapster還有很多的坑，大家多多交流吧~^_^