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

時間  2019-11-22
標籤 kubernetes pod 詳細 解讀 第二 简体版
原文   原文鏈接

8.資源對象對pod的調度

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

（1）Deployment/RC 自動化調度

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

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

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

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

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

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

kubernetes之pod超詳細解讀--第二篇（三）
注意：若是想刪除pod，不能直接kubectl delete pod,由於這些pod歸deployment管理，若是想刪除pod，只須要將replicas設置爲0，並刪除該deployment便可。
從調度上來講，若是在集羣模式下，剛剛建立的3個pod徹底是由系統全自動的完成調度，他們最終在哪些節點運行，徹底是由master的scheduler通過一系列的複雜算法計算得出的，用戶沒法干預。python

（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打標籤linux

#定義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上運行。nginx

（3） DaemonSet

  DaemonSet是kubernetes在v1.2版本更新的時候新增的一種資源對象，用於管理在集羣彙總每個node上僅運行一份pod的副本實例。（以下圖）
kubernetes之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」：redis

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較少，可是處理的數據量比較大的場景）
kubernetes之pod超詳細解讀--第二篇（三）
   Queue with Pod Work Item模式：採用一個任務隊列存放Work Items，一個job對象做爲消費者去完成這些Work Items，這種模式下會啓動一個Job和N個Pod，每個Pod對應一個Work Item
kubernetes之pod超詳細解讀--第二篇（三）
   Queue with Varibale Pod Conut模式：這也是採用的Work Items的方式，可是不一樣的是，一個Job啓動的pod的數量是能夠改變的
kubernetes之pod超詳細解讀--第二篇（三）
   Single Job with Static Work Assignment模式：也是一個job產生多個pod完成任務，可是它採用的靜態方式分配任務，而並不是任務隊列的方式動態分配
幾種批處理任務的模式對比
kubernetes之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中的實例：docker

Job Template Expansion模式：apache

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

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

[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並處理，處理完結束進程。
kubernetes之pod超詳細解讀--第二篇（三）
Queue with Varibale Pod Conut模式：
  這種模式下worker程序須要知道隊列中是否還有等待處理的work item，若是有就取出來並處理，不然認爲全部的工做完成，job結束。此處的任務隊列一般用Redis來實現。
kubernetes之pod超詳細解讀--第二篇（三）centos

（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任務

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

[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 不會被識別，可能會報錯：
kubernetes之pod超詳細解讀--第二篇（三）
使用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

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

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

kubernetes之pod超詳細解讀--第二篇（三）
#此時咱們將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

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

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

kubernetes之pod超詳細解讀--第二篇（三）
那究竟是怎麼更新的呢？由上面的截圖咱們能夠看出：
初始建立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
kubernetes之pod超詳細解讀--第二篇（三）
這裏咱們看不見deployment建立的命令，若是在建立deployment加入--record參數，這裏就能看見deployment的建立命令
#查看某個特定版本的deployment的詳細信息
[root@zy yaml_file]# kubectl rollout history deployment/nginx-deployment --revision=1
kubernetes之pod超詳細解讀--第二篇（三）
#撤銷本次發佈並回退上一個部署版本
[root@zy yaml_file]# kubectl rollout undo deployment/nginx-deployment
kubernetes之pod超詳細解讀--第二篇（三）
#回滾到特定的版本
[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
kubernetes之pod超詳細解讀--第二篇（三）
#回滾
[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爲例：
kubernetes之pod超詳細解讀--第二篇（三）
kubernetes之pod超詳細解讀--第二篇（三）
這裏deployment管理3個pod的副本，咱們將其設置爲5個

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

kubernetes之pod超詳細解讀--第二篇（三）
#在縮容到1個

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

kubernetes之pod超詳細解讀--第二篇（三）
② 自動擴容
  從kubernetes1.1開始，新增了一個名爲Horizontal Pod Autoscaler(HPA)的控制器，用於實現CPU使用率進行自動Pod擴容和縮容。（這裏必須先安裝Heapster）
kubernetes之pod超詳細解讀--第二篇（三）
  這裏小編也是一個案例說明，咱們建立一個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的時候發現以下報錯：

kubernetes之pod超詳細解讀--第二篇（三）
緣由：根據報錯信息，pod啓動須要registry.access.redhat.com/rhel7/pod-infrastructure:latest鏡像，須要去紅帽倉庫裏下載，可是沒有證書，安裝證書以後就能夠了。
解決：
① 確認docker是否正常啓動

[root@zy ~]# systemctl status docker

kubernetes之pod超詳細解讀--第二篇（三）
② 下載相應的鏡像

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

不出意外會報錯：
kubernetes之pod超詳細解讀--第二篇（三）
這是由於：
/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發現報錯：
kubernetes之pod超詳細解讀--第二篇（三）
緣由：應用程序API組將是v1部署類型所在的位置。 apps / v1beta1版本已在1.6.0中添加，所以若是您有1.5.x客戶端或服務器，則仍應使用extensions / v1beta1版本。
查看kubernetes的版本：

[root@zy yaml_file]# kubelet –version

kubernetes之pod超詳細解讀--第二篇（三）
解決：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  #建立
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程