kubernetes之pod超詳細解讀--第二篇（三）

8.資源對象對pod的調度

  在kubernetes集羣中，pod基本上都是容器的載體，通常需要通過相應的資源對象來完成一組pod的調度和自動控制功能，比如：deployment、daemonSet、RC、Job等等。接下來小編將一一介紹這些資源對象如何調度pod。

（1）Deployment/RC 自動化調度

  Deployment/RC的主要功能之一就是自動部署一個容器應用的多個副本，以及持續監控副本數量，在集羣內始終維持用戶指定的副本數量。
舉例：（這裏以deployment爲例）

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: docker.io/nginx
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80

[root@zy yaml_file]# kubectl create -f nginx-deployment.yaml #創建deployment
[root@zy yaml_file]# kubectl get pod  #查看創建的pod

[root@zy yaml_file]# kubectl get deploy  #查看deploy  狀態

[root@zy yaml_file]# kubectl get rs  #查看RS狀態

注意：如果想刪除pod，不能直接kubectl delete pod,因爲這些pod歸deployment管理，如果想刪除pod，只需要將replicas設置爲0，並刪除該deployment即可。
從調度上來說，如果在集羣模式下，剛剛創建的3個pod完全是由系統全自動的完成調度，他們最終在哪些節點運行，完全是由master的scheduler經過一系列的複雜算法計算得出的，用戶無法干預。

（2）NodeSelector定向調度

  Deployment/RC對pod的調度用戶是無法干預的，如果我們想將一個pod定向的在某個特定的節點上運行，那該怎麼做呢？還記得之前說過的標籤嗎，如此強大的功能不用就浪費了，這裏我們可以使用node的標籤，和pod的nodeSelector屬性相匹配，來達到上述的目的。
舉例：
#爲node創建標籤：
[root@zy yaml_file]# kubectl get node #查看集羣node
[root@zy yaml_file]# kubectl label nodes 127.0.0.1 zone=north #給node打標籤

#定義pod：redis-master-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: node-pod
  labels:
    name: node-pod
spec:
  containers:
  - name:  node-pod
    image: docker.io/kubeguide/redis-master
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 6379
  nodeSelector:
    zone: north

[root@zy yaml_file]# kubectl create -f redis-master-pod.yaml

這樣，pod就會被定向到有zone: north 標籤的node上去運行，當然這裏如果定義的deployment/RC的話，會根據副本數，在相應的具有標籤的node上運行。

（3） DaemonSet

  DaemonSet是kubernetes在v1.2版本更新的時候新增的一種資源對象，用於管理在集羣彙總每一個node上僅運行一份pod的副本實例。（如下圖）

DaemonSet的應用場景有：
  在每一個node上運行一個GlusterFS存儲或者Ceph存儲的Daeson進程
  在每個node上運行一個日誌採集程序，例如：Fluentd或者Logstach
  在每臺node上運行一個性能監控程序，採集node的運行性能數據，如：Prometheus、collectd、New Relic agent
 接下來小編就給出一個例子定義爲在每臺node上啓動一個fluentd容器，配置文件fluentd-ds.yaml的內容如下，其掛載了物理機的兩個目錄“/var/log”和“/var/lib/docker/containers”：

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: fluentd-cloud-logging
  namespace: kube-system
  labels:
    k8s-app: fluentd-cloud-logging
spec:
  template:
    metadata:
      namespace: kube-system
      labels:
        k8s-app: fluentd-cloud-logging
    spec:
      containers:
      - name: fluentd-cloud-logging
        image: docker.io/forkdelta/fluentd-elasticsearch
        resrouces:
          limits:
            cpu: 100m
            memory: 200Mi
        env:
        - name: FLUENTD_ARGS
          value: -q
        volumeMounts:
        - name: varlog
          mountPath: /var/log
          readOnly: false
        - name: containers
          mountPath: /var/lib/dpcker/containers
          readOnly: false
    volumes:
    - name: containers
      hostPath:
        path: /var/lib/dpcker/containers
    - name: varlog
      hostPath:
        path: /var/log

（4） job：批處理調度

  Kubernetes在v1.2版本開始支持批處理類型的應用，可以通過kubernetes Job資源對象來定義並啓動一個批處理任務。批處理任務提高通常並行（或者串行）啓動多個計算進程去處理一批工作項（work items），處理完成之後，整個批處理任務結束。
 批處理任務可以分爲以下幾種模式：
   Job Template Expansion模式：一個Job對象對應一個待處理的work item，有幾個work items就會產生幾個獨立的job（通常適合work items較少，但是處理的數據量比較大的場景）

   Queue with Pod Work Item模式：採用一個任務隊列存放Work Items，一個job對象作爲消費者去完成這些Work Items，這種模式下會啓動一個Job和N個Pod，每一個Pod對應一個Work Item

   Queue with Varibale Pod Conut模式：這也是採用的Work Items的方式，但是不同的是，一個Job啓動的pod的數量是可以改變的

   Single Job with Static Work Assignment模式：也是一個job產生多個pod完成任務，但是它採用的靜態方式分配任務，而並非任務隊列的方式動態分配
幾種批處理任務的模式對比

考慮到批處理的並行問題，kubernetes將job分爲以下三種類型：
  Non-parallel Jobs：通常一個job只啓動一個pod，只有pod異常纔會重啓pod，pod正常結束，Job也結束
  Parallel Jobs with a fixed completion count：並行Job會啓動多個pod，正常的pod結束的數量達到設定的值後，Job結束。其中有兩個參數
   Spec.completions：預期的pod正常退出的個數
  Spec.parallelism：啓動的Job數
  Parallel Jobs with a work queue：所有的work item都在一個queue中，Job啓動的pod能判斷是否queue中還有任務需要處理，如果某個pod正常結束，job不會啓動新的pod，如果有一個pod結束，那麼job下其他pod將不存在幹活的情況，至少有一個pod正常結束時，job算成功結束。

---

接下來小編介紹一下上面三種常見的批處理模型在kubernetes中的實例：

Job Template Expansion模式：

apiVersion: batch/v1
kind: Job
medata:
  name: process-item-$ITEM
  labels:
    jobgroup: jobexample
spec:
  template:
    metadata:
      name: jobexample
      labels:
        jobgroup: jobexample
    spec:
      containers:
      - name: c
        image: docker.io/busybox
        imagePullPolicy: IfNotPresent
        command: ["sh","-c","echo Processing item $ITEM && sleep 5"]
      restartPolicy: Never

#以上面的yaml內容爲模板，創建三個job的定義文件：
[root@zy yaml_file]# for i in apple banana cherry ;do cat job.yaml |sed "s/\$ITEM/$i/" > job-$i.yaml ;done
[root@zy yaml_file]#mkdir jobs && mv job-* jobs  #將job的定義文件統一放入jobs目錄下
[root@zy yaml_file]# kubectl create -f jobs  #創建job
[root@zy yaml_file]# kubectl get jobs 查看job

[root@zy yaml_file]# docker ps -a  #通過查看創建container，查看任務打印的內容
[root@zy yaml_file]# kubectl get pod --show-all  #查看pod 

Queue with Pod Work Item模式：
  在這種模式下需要一個任務隊列存放work items，比如kafka、RabbitMQ,客戶端將需要處理的任務放入隊列中，然後編寫worker程序並打包成爲鏡像並定義成爲Job中的work Pod，worker程序的實現邏輯就是從任務隊列中拉取一個work item並處理，處理完結束進程。

Queue with Varibale Pod Conut模式：
  這種模式下worker程序需要知道隊列中是否還有等待處理的work item，如果有就取出來並處理，否則認爲所有的工作完成，job結束。此處的任務隊列通常用Redis來實現。

（5） Cronjob 定時任務

  Kubernetes從v1.5版本開始增加了一個新類型的Job，類似於Linux crond的定時任務，Crond Job,下面，小編向大家介紹一下這個類型的Job如何使用。
  先想使用這個類型的Job，必須是kubernetes1.5版本以上，並且在啓動API server是加入參數：--runtime-config=batch/v2alpha1=true（在apiserver 的配置文件中加入/etc/kubernetes/apiserver）

然後重啓：[root@zy yaml_file]# systemctl restart kube-apiserver

#編寫crond Job的定義：
apiVersion: batch/v2alpha1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: docker.io/busybox
            imagePullPolicy: IfNotPresent
            args:
            - /bin/sh
            - -c 
            - date; echo Hell from the Kubernetes cluster
          restartPolicy: OnFailure

[root@zy yaml_file]# kubectl create -f cron.yaml #創建CronJob
[root@zy yaml_file]# kubectl get cronjob  #查看CronJob任務

[root@zy yaml_file]# kubectl get jobs --watch  #查看job，可以發現有每分鐘都會有一個job執行

注意：這裏的任務執行的週期與linux crond相同（分 時 日 月 周）

9.Init Container 初始化容器

  在很多場景下，我們在啓動應用之前需要進行一些列的初始化，在kubernetes1.5版本之後，init Container被應用於啓動應用容器之前啓動一個或者多個“初始化”容器，完成應用容器所需要的預置條件。它們僅僅運行一次就結束，當所有定義的init Container都正常啓動之後，纔會啓動應用容器。
下面小編演示一個案例：在啓動nginx服務之前，通過初始化buxybox爲nginx創建一個index.html主頁：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  initContainers:
  - name: install
    image: docker.io/busybox
    imagePullPolicy: IfNotPresent
    command:
    - wget
    - "-O"
    - "/work-dir/index.html"
    - http://kubernetes.io
    volumeMounts:
    - name: workdir
      mountPath: "/work-dir"
  containers:
  - name: ngxin
    image: docker.io/nginx
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 80
    volumeMounts:
    - name: workdir
      mountPath: /usr/share/nginx/html
  dnsPolicy: Default
  volumes:
  - name: workdir
    emptyDir: {}

這裏注意如果是k8s的版本比較低的話，這裏的initContainers 不會被識別，可能會報錯：

使用init container的注意事項：
   如果定義多個init container，必須上一個運行完成才能運行下一個
   多個init container定義資源請求，取最大的那個爲有效請求
   Pod重啓時，init container會跟着重啓

10.pod的升級和回滾

(1)pod的升級

  當我們新應用部署的時候，需要將pod中image換成新打包的image，但是由於在生產環境，又不能讓服務較長時間的不可用，這時kubernetes提供了滾動升級功能來解決這個難題。
小編這裏以deployment爲例，用三個nginx的服務，進行image的替換，查看究竟kubernetes如何實現滾動升級的：

#nginx-deplyment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: docker.io/nginx
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80

[root@zy yaml_file]# kubectl  create -f nginx-deployment.yaml 
[root@zy yaml_file]# kubectl get pod  #查看pod

[root@zy yaml_file]# kubectl get rs  #查看由deployment創建的RS

#此時我們將pod中的image設置爲docker.io/linuxserver/nginx
[root@zy yaml_file]# kubectl set image deployment/nginx-deployment nginx=docker.io/linuxserver/nginx
或者：

[root@zy yaml_file]# kubectl edit deployment/nginx-deployment
[root@zy yaml_file]# kubectl rollout status deployment/nginx-deployment #可以查看滾動升級的過程
#我們查看具體的更新細節
[root@zy yaml_file]# kubectl describe deployment/nginx-deployment

[root@zy yaml_file]# kubectl get rs  #查看RS

那到底是怎麼更新的呢？由上面的截圖我們可以看出：
初始創建deployment時，系統創建了一個RS並按照配置的replicas創建了3個Pod，當deployment更新時，系統又創建了一個新的RS，逐漸的將舊的RS的副本數從3縮小到0，而將新的RS的副本數從0逐漸增加到3，最後就是以這樣的方式，在服務不停止的情況下巧妙的完成了更新。
更新策略：
  Recereate（重構）：設置：spec.strategy.type=Recreate,表示deployment更新過程中會先殺死所有正在運行的pod，然後在重新創建。（會造成服務中斷）
  RollingUpdate（滾動更新）：設置：spec.strategy.type=RollingUpdate,表示deployment以滾動更新的方式來逐漸更新pod，滾動更新有兩個重要的參數
  spec.strategy.type.rollingUpdate.maxUnavailabe：用於指定deployment在更新過程中不可用pod的數量的上限（v1.6之後默認將1改爲25%）：也就是說，當這個值設置爲2的時候，並且replicas是5的話，在更新時至少要有3個pod能正常提供對外服務。
  spec.strategy.type.rollingUpdate.maxSurge：表示指定deployment更新Pod過程中Pod總數不能超過Pod期望副本數部分的最大值（v1.6之後默認將1改爲25%），也就是說，當這個值設置爲2的時候，並且replicas是5的話，正在運行的Pod不能超過7個。
更新的注意點：
  deployment會爲每一次更新都創建一個RS，如果當deployment本次更新未完成，用戶又發起了下一次更新，此時deployment不會等本次更新完成之後再進行下一次更新，它會將本次更新的所有的Pod全部殺死，直接進入下一次更新
  關於更新label和label selector的問題
   更新時deployment的標籤選擇器時，必須同時更新deployment中定義的pod的label，否則deployment更新會報錯
   添加或者修改deployment的標籤選擇器時會導致新的標籤選擇器不會匹配就選擇器創建的RS和Pod，則這些RS和Pod處於孤立狀態，不會被系統自動刪除
   在deployment的selector中刪除一個或者多個標籤，deployment的RS和Pod不會受到影響，但是被刪除的label仍然會留在已有的RS和Pod中

(2)pod的回滾

  有時，因爲新版本不穩定時，我們可能將deployment回滾到舊的版本，默認情況下deployment發佈的所有歷史記錄都會留在系統中，這裏小編向大家展示如何回退版本：
#查看deployment歷史
[root@zy yaml_file]# kubectl rollout history deployment/nginx-deployment

這裏我們看不見deployment創建的命令，如果在創建deployment加入--record參數，這裏就能看見deployment的創建命令
#查看某個特定版本的deployment的詳細信息
[root@zy yaml_file]# kubectl rollout history deployment/nginx-deployment --revision=1

#撤銷本次發佈並回退上一個部署版本
[root@zy yaml_file]# kubectl rollout undo deployment/nginx-deployment

#回滾到特定的版本
[root@zy yaml_file]# kubectl rollout undo deployment/nginx-deployment --to-revision=2

(3)pod的更新和回滾的補充說明

① 暫停或恢復deployment的部署操作
  對於一次複雜的deployment的配置修改，爲了避免頻繁的更新deployment，我們可以先暫停deployment的更新操作，然後進行配置，再恢復更新，一次性觸發完整的更新操作。
#暫停deployment的更新
[root@zy yaml_file]# kubectl rollout pause deployment/nginx-deployment
之後我們可以做一系列的操作，更新image，設置資源。（這裏修改之後不會觸發更新）
#恢復更新
[root@zy yaml_file]# kubectl rollout resume deployment/nginx-deployment
恢復之後，該deployment會一次性更新所有操作。

② 使用kubeclt rolling-update命令完成RC的更新
  對於RC的更新我們可以通過命令kubeclt rolling-update實現。但是該命令會創建一個新的RC，並將舊的RC的pod逐漸降低到0，新的RC的pod逐漸增加到replicas設置的值，並且新的RC必須和舊的RC在同一namespace下。
這裏小編以一個例子演示：

#redis-mater-controller-v2.yaml
apiVersion: v1
kind: ReplicationController
metadata:
  name: redis-master-v2
  labels:
    name: redis-master-v3
    new-version: v3
spec:
  replicas: 1
  selector:
    name: redis-master-v3
    new-version: v3
  template:
    metadata:
      labels:
        name: redis-master-v3
        new-version: v3
    spec:
      containers:
      - name: master
        image: docker.io/kubeguide/redis-master:v3.0
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 6379

[root@zy yaml_file]# kubectl create -f redis-mater-controller-v2.yaml #創建這個RC

此時我們想將image替換成v3.0，這是就需要對RC滾動升級，這裏注意兩點：
  RC的名字不能與舊的RC的名字相同
  在selector中應至少有一個Label與舊的RC的label不同
#更新
[root@zy yaml_file]# kubectl rolling-update redis-master-v2 -f redis-mater-controller-v3.yaml

#回滾
[root@zy yaml_file]# kubectl rolling-update redis-master-v3 --image=docker.io/kubeguide/redis-master --rollback
注意：RC的滾動升級不具有deployment在應用版本升級過程中的歷史記錄、新舊版本數量的精細控制。

③ 其他管理對象的更新策略
  DaemonSet的更新：OnDelete 和 RollingUpdate兩種方式
  StatefulSet的更新：kubernetes1.6之後，開始逐漸對StatefulSet的更新向deployment看齊，目前瞭解較少

11.pod的擴容和縮容

  在實際的生產中，我們經常會遇到某個服務因爲壓力過大，需要擴容，有可能遇到當集羣資源過度緊張的時候，減少一部分服務的副本。在kubernetes中我們可以利用deployment的Scale實現。
  Kubernetes對pod的擴容和縮容提供了手動和自動的兩種方式。手動則是執行命令，而自動測試更具某個性能指標，並指定pod的副本數量範圍，由系統自動的在這個範圍內根據性能指標進行調整。
① 手動擴容
#這裏以一個簡單的nginx爲例：


這裏deployment管理3個pod的副本，我們將其設置爲5個

[root@zy yaml_file]# kubectl scale deployment nginx-deployment --replicas=5

#在縮容到1個

[root@zy yaml_file]# kubectl scale deployment nginx-deployment --replicas=1

② 自動擴容
  從kubernetes1.1開始，新增了一個名爲Horizontal Pod Autoscaler(HPA)的控制器，用於實現CPU使用率進行自動Pod擴容和縮容。（這裏必須先安裝Heapster）

  這裏小編也是一個案例說明，我們創建一個Tomcat的pod由deployment管理，並且提供一個service供外部訪問，同時設置HPA實時監控deploy的CPU使用率，自動pod擴容，最後使用一個循環壓力測試這個服務（不斷地訪問Tomcat），查看deploy的擴容與縮容情況：

#tomcat-apache-deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: tocamt-apache
spec:
  replicas: 1
  template:
    metadata:
      name: tocamt-apache
      labels:
        app: tocamt-apache
    spec:
      containers:
      - name: tocamt-apache
        image: tomcat
        imagePullPolicy: IfNotPresent
        resources:
          requests:
            cpu: 20m  #注意這裏一定要設置cpu的請求，不然Heapster無法採集
        ports:
        - containerPort: 80

#tomcat-apache-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: tomcat-apache
spec:
  ports:
  - port: 80
  selector:
    app: tocamt-apache

#定義或者創建HPA：

[root@zy yaml_file]# kubectl autoscale deployment tomcat-apache  --min=1 --max=10 --cpu-percent=50 

命令解釋：表示pod的數量在1~10之間，以使得平均podCPU使用率維持在50%
或者yaml文件：

#hpa-tomcat-apache.yaml
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: tomcat-apache
spec:
  scaleTargetRef:
    apiVersion: extensions/v1beta1
    kind: Deployment
    name: tocamt-apache
  minReplicas: 1
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50

最後我們在創建一個busybox 的pod，然後進入容器，執行

while true;do wget -q -O- http:ClusterIP >dev/null ;done

對這個deployment進行壓力測試，最後可以看到deploy管理的這個pod的數量數變化的，但始終保持pod平均的CPU使用率在50%左右，當將這個壓力測試的容器關閉時，pod的數量又會變成原先定義的1個。

問題解答

1. 創建pod時一直處於ContainerCreating的狀態，用[root@zy yaml_file]# kubectl describe pod frontend的時候發現如下報錯：

原因：根據報錯信息，pod啓動需要registry.access.redhat.com/rhel7/pod-infrastructure:latest鏡像，需要去紅帽倉庫裏下載，但是沒有證書，安裝證書之後就可以了。
解決：
① 確認docker是否正常啓動

[root@zy ~]# systemctl status docker

② 下載相應的鏡像

[root@zy ~]# docker pull registry.access.redhat.com/rhel7/pod-infrastructure:latest

不出意外會報錯：

這是因爲：
/etc/docker/certs.d/registry.access.redhat.com/redhat-ca.crt: no such file or directory
此時我們下載相應的rpm包：

[root@zy ~]#wget http://mirror.centos.org/centos/7/os/x86_64/Packages/python-rhsm-certificates-1.19.10-1.el7_4.x86_64.rpm
[root@zy ~]#rpm -ivh python-rhsm-certificates-1.19.10-1.el7_4.x86_64.rpm

然後執行以下命令：

[root@zy ~]#rpm2cpio python-rhsm-certificates-1.19.10-1.el7_4.x86_64.rpm | cpio -iv --to-stdout ./etc/rhsm/ca/redhat-uep.pem | tee /etc/rhsm/ca/redhat-uep.pem

此時/etc/docker/certs.d/registry.access.redhat.com/redhat-ca.crt文件中就會有內容，再次下載鏡像即可。

2. 版本問題

當在創建deployment時，用的apiVersion時：使用的是apps / v1beta1發現報錯：

原因：應用程序API組將是v1部署類型所在的位置。 apps / v1beta1版本已在1.6.0中添加，因此如果您有1.5.x客戶端或服務器，則仍應使用extensions / v1beta1版本。
查看kubernetes的版本：

[root@zy yaml_file]# kubelet –version

解決：apiVersion：extensions / v1beta1 即可

3. Kubernetes安裝heapster插件

#下載相應的鏡像：
[root@zy yaml_file]# docker pull docker.io/forestgun007/heapster_grafana:v3.1.1
[root@zy yaml_file]# docker pull docker.io/sailsxu/heapster_influxdb:v0.6
[root@zy yaml_file]# docker pull docker.io/mxpan/heapster:canary

編寫相應的yaml文件：

#grafana-deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: monitoring-grafana
  namespace: kube-system
spec:
  replicas: 1
  template:
    metadata:
      labels:
        task: monitoring
        k8s-app: grafana
    spec:
      volumes:
      - name: grafana-storage
        emptyDir: {}
      containers:
      - name: grafana
        image: docker.io/forestgun007/heapster_grafana:v3.1.1
        imagePullPolicy: IfNotPresent
        ports:
          - containerPort: 3000
            protocol: TCP
        volumeMounts:
        - mountPath: /var
          name: grafana-storage
        env:
        - name: INFLUXDB_HOST
          value: monitoring-influxdb
        - name: GRAFANA_PORT
          value: "3000"
        - name: GF_AUTH_BASIC_ENABLED
          value: "false"
        - name: GF_AUTH_ANONYMOUS_ENABLED
          value: "true"
        - name: GF_AUTH_ANONYMOUS_ORG_ROLE
          value: Admin
        - name: GF_SERVER_ROOT_URL
          value: /

#grafana-service.yaml
apiVersion: v1
kind: Service
metadata:
  labels:
    kubernetes.io/cluster-service: 'true'
    kubernetes.io/name: monitoring-grafana
  name: monitoring-grafana
  namespace: kube-system
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 3000
  selector:
    k8s-app: grafana

#influxdb-deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: monitoring-influxdb
  namespace: kube-system
spec:
  replicas: 1
  template:
    metadata:
      labels:
        task: monitoring
        k8s-app: influxdb
    spec:
      volumes:
      - name: influxdb-storage
        emptyDir: {}
      containers:
      - name: influxdb
        image: docker.io/sailsxu/heapster_influxdb:v0.6
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - mountPath: /data
          name: influxdb-storage

#influxdb-service.yaml
apiVersion: v1
kind: Service
metadata:
  labels:
    task: monitoring
    kubernetes.io/cluster-service: 'true'
    kubernetes.io/name: monitoring-influxdb
  name: monitoring-influxdb
  namespace: kube-system
spec:
  # type: NodePort
  ports:
  - name: api
    port: 8086
    targetPort: 8086
  selector:
    k8s-app: influxdb

#heapster-deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: heapster
  namespace: kube-system
spec:
  replicas: 1
  template:
    metadata:
      labels:
        task: monitoring
        k8s-app: heapster
        version: v6
    spec:
      containers:
      - name: heapster
        image: docker.io/mxpan/heapster:canary
        imagePullPolicy: IfNotPresent
        command:
        - /heapster
        - --source=kubernetes:https://kubernetes.default
        - --sink=influxdb:influxdb:http://monitoring-influxdb.kube-system.svc:8086

#heapster-service.yaml
apiVersion: v1
kind: Service
metadata:
  labels:
    task: monitoring
    kubernetes.io/cluster-service: 'true'
    kubernetes.io/name: Heapster
  name: heapster
  namespace: kube-system
spec:
  ports:
  - port: 80
    targetPort: 8082
  selector:
    k8s-app: heapster

最後將這六個文件移動到一個目錄下，比如：heapster

[root@zy ~]# kubectl create -f  heapster  #創建