Kubernetes用戶指南（四）--應用檢查和調試

1、調試

當你的應用開始運行，那麼DEBUG是不可避免的問題。

早些時候，咱們在描述的是如何經過kubectl get pods來得到Pod的簡單狀態信息。

可是如今，這裏有更多的方式來得到關於你的應用的更多信息。

一、使用kubectl describe pod來得到Pod的詳細信息

在這個例子中，咱們將會像以前的例子同樣使用RC來建立兩個Pod：

apiVersion: v1

kind: ReplicationController

metadata:

  name: my-nginx

spec:

  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        resources:
          limits:
            memory: "128Mi"
            cpu: "500m"
        ports:
        - containerPort: 80

$  kubectl create -f ./my-nginx-rc.yaml

replicationcontrollers/my-nginx

$  kubectl get pods

NAME             READY     REASON    RESTARTS   AGE

my-nginx-gy1ij   1/1       Running   0          1 m

my-nginx-yv5cn   1/1       Running   0          1m

咱們能夠經過kubectl describe pod來得到每一個Pod的詳細信息，例如：

$  kubectl describe pod my-nginx-gy1ij
Name:               my-nginx-gy1ij
Image(s):           nginx
Node:               kubernetes-minion-y3vk/10.240.154.168
Labels:             app=nginx
Status:             Running
Reason:             
Message:           
IP:             10.244.1.4
Replication Controllers:    my-nginx (2/2 replicas created)
Containers:
  nginx:
    Image:  nginx
    Limits:
      cpu:      500m
      memory:       128Mi
    State:      Running
      Started:      Thu, 09 Jul 2015 15:33:07 -0700
    Ready:      True
    Restart Count:  0
Conditions:
  Type      Status
  Ready     True 
Events:
  FirstSeen             LastSeen            Count   From                    SubobjectPath               Reason      Message
  Thu, 09 Jul 2015 15:32:58 -0700   Thu, 09 Jul 2015 15:32:58 -0700 1   {scheduler }                                    scheduled   Successfully assigned my-nginx-gy1ij to kubernetes-minion-y3vk
  Thu, 09 Jul 2015 15:32:58 -0700   Thu, 09 Jul 2015 15:32:58 -0700 1   {kubelet kubernetes-minion-y3vk}    implicitly required container POD   pulled      Pod container image "gcr.io/google_containers/pause:0.8.0" already present on machine
  Thu, 09 Jul 2015 15:32:58 -0700   Thu, 09 Jul 2015 15:32:58 -0700 1   {kubelet kubernetes-minion-y3vk}    implicitly required container POD   created     Created with docker id cd1644065066
  Thu, 09 Jul 2015 15:32:58 -0700   Thu, 09 Jul 2015 15:32:58 -0700 1   {kubelet kubernetes-minion-y3vk}    implicitly required container POD   started     Started with docker id cd1644065066
  Thu, 09 Jul 2015 15:33:06 -0700   Thu, 09 Jul 2015 15:33:06 -0700 1   {kubelet kubernetes-minion-y3vk}    spec.containers{nginx}          pulled      Successfully pulled image "nginx"
  Thu, 09 Jul 2015 15:33:06 -0700   Thu, 09 Jul 2015 15:33:06 -0700 1   {kubelet kubernetes-minion-y3vk}    spec.containers{nginx}          created     Created with docker id 56d7a7b14dac
  Thu, 09 Jul 2015 15:33:07 -0700   Thu, 09 Jul 2015 15:33:07 -0700 1   {kubelet kubernetes-minion-y3vk}    spec.containers{nginx}          started     Started with docker id 56d7a7b14dac

你能夠看到容器和Pod（標籤和資源需求量等等）的配置信息，也能夠看到他們的狀態信息（包括聲明、是否準備就緒、重啓次數和發生的事件等等）。

容器的state是Waiting、Running或者Terminated其中一個，根據這個狀態信息，系統會告訴你正在運行的容器是何時啓動的。

Ready說明了容器是否經過了它的最後一個就緒檢查。（假如，容器沒有準備就緒狀態檢查的探針，那麼這個容器將會被認爲是處於Ready狀態的。）

Restart Count說明了容器重啓了多少次，在檢查容器中由於配置重啓的政策爲「老是」的循環崩潰時這是很是有用的信息。

當前有關Pod的惟一信息是Pod的Ready狀態，代表了當前Pod有能力爲請求服務，而且加入到負載均衡池中提供給全部匹配到的SVC。

最後，你能夠看到一大堆有關你的Pod最近發生的事件，系統經過指明該事件第一次、最後一次發送的時間和發送的次數來壓縮處理相同的事件。

「From」字段指明瞭哪一個組件發生了這些事件，「SubobjectPath」字段告訴你哪一個Object（例如，Pod中的容器）是被引用的，「Reason」和「Message」字段告訴你發生的事件是什麼。

二、例子：調試處於Pending狀態的Pods

經過觀察事件信息來發現異常的一個常見的場景是：當你建立了一個Pod，可是它在任何節點上都不正常運行。

例如，這個Pod可能請求的資源量超出了節點上的空閒資源數，或者它可能指定了一個不可以匹配全部節點的Label Selector。

假設咱們在一個擁有4個節點、每一個節點都有1個CPU核心的集羣上，經過5個replicas建立了以前的RC（以前是2個replicas），而且請求了600millicores代替以前的500。

假設其中的一個Pod將不會被調度。（注意，這是由於集羣上裝了例如，fluentd、skydns等等的插件，若是咱們請求超過1000millicores那麼全部Pod都將不會被調度。）

$  kubectl get pods
NAME             READY     REASON    RESTARTS   AGE
my-nginx-9unp9   0/1       Pending   0          8s
my-nginx-b7zs9   0/1       Running   0          8s
my-nginx-i595c   0/1       Running   0          8s
my-nginx-iichp   0/1       Running   0          8s
my-nginx-tc2j9   0/1       Running   0          8s

爲了找出第一個Pod爲何沒有處於running狀態，咱們可使用kubectl describe pod查看處於pending狀態的Pod的事件：

$  kubectl describe pod my-nginx-9unp9 
Name:               my-nginx-9unp9
Image(s):           nginx
Node:               /
Labels:             app=nginx
Status:             Pending
Reason:             
Message:           
IP:             
Replication Controllers:    my-nginx (5/5 replicas created)
Containers:
  nginx:
    Image:  nginx
    Limits:
      cpu:      600m
      memory:       128Mi
    State:      Waiting
    Ready:      False
    Restart Count:  0
Events:
  FirstSeen             LastSeen            Count   From        SubobjectPath   Reason          Message
  Thu, 09 Jul 2015 23:56:21 -0700   Fri, 10 Jul 2015 00:01:30 -0700 21  {scheduler }            failedScheduling    Failed for reason PodFitsResources and possibly others

在這裏你能夠看到，由Scheduler產生的事件說明了這個Pod調度失敗是由於PodFitsResources（也有多是其餘）。

PodFitsResources說明了在任何節點上都沒有足夠的資源給這個Pod。

根據事件產生的形式，也有多是其餘的緣由致使調度失敗。

爲了糾正這種狀況，你可使用kubectl scale來更新RC來定義使用4個或者更少的replicas。（或者你能夠直接放棄這個Pod，這是沒有影響的。）

例如你使用kubectl describe pod看到的事件都將持久化到etcd中，而且在集羣發生什麼事情的時候提供一個high-level的信息。

你可使用

kubectl get events

來列出全部事件。

可是你必須記住，事件也是有命名空間的。

這意味着若是你對一些命名空間下的Object（例如，在my-namespace中Pod發生的事情）的事件感興趣，你須要在命令行中明確地指定這個命名空間：

kubectl get events --namespace=my-namespace

可使用--all-namespace參數看全部命名空間的事件。

除了kubectl describe pod以外，另一種得到有關Pod的額外信息（超出kubectl get pod所提供的信息）的方式能夠是，爲kubectl get pod指定格式化輸出標識，-o yaml。

這將會經過yaml格式給你提供比kubectl describe pod更多的信息，這基本上是系統中有關Pod的全部信息了。

在這裏你將會看到相似註解的東西（一種k8s系統內部使用的，沒有Label限制的鍵值對元數據）、重啓政策、端口和卷。

$ kubectl get pod my -nginx-i595c -o yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubernetes.io/created-by: '{"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicationController","namespace":"default","name":"my-nginx","uid":"c555c14f-26d0-11e5-99cb-42010af00e4b","apiVersion":"v1","resourceVersion":"26174"}}'
  creationTimestamp: 2015-07-10T06:56:21Z
  generateName: my-nginx-
  labels:
    app: nginx
  name: my-nginx-i595c
  namespace: default
  resourceVersion: "26243"
  selfLink: /api/v1/namespaces/default/pods/my-nginx-i595c
  uid: c558e44b-26d0-11e5-99cb-42010af00e4b
spec:
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: nginx
    ports:
    - containerPort: 80
      protocol: TCP
    resources:
      limits:
        cpu: 600m
        memory: 128Mi
    terminationMessagePath: /dev/termination-log
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: default-token-zkhkk
      readOnly: true
  dnsPolicy: ClusterFirst
  nodeName: kubernetes-minion-u619
  restartPolicy: Always
  serviceAccountName: default
  volumes:
  - name: default-token-zkhkk
    secret:
      secretName: default-token-zkhkk
status:
  conditions:
  - status: "True"
    type: Ready
  containerStatuses:
  - containerID: docker://9506ace0eb91fbc31aef1d249e0d1d6d6ef5ebafc60424319aad5b12e3a4e6a9
    image: nginx
    imageID: docker://319d2015d149943ff4d2a20ddea7d7e5ce06a64bbab1792334c0d3273bbbff1e
    lastState: {}
    name: nginx
    ready: true
    restartCount: 0
    state:
      running:
        startedAt: 2015-07-10T06:56:28Z
  hostIP: 10.240.112.234
  phase: Running
  podIP: 10.244.3.4
  startTime: 2015-07-10T06:56:21Z

三、例子：調試掛掉的節點

有時候，查看節點的狀態在調試時是很是有用的，例如你能夠從這個節點得到Pod的一些奇怪的行爲信息，或者找出爲何Pod沒有在這個節點上被調度的緣由。

和Pod的一些命令同樣，你也可使用kubectl describe node和kubectl get node -o yaml來得到有關節點的詳細信息。

例如，這裏是一些在節點掛掉的時候你能夠看到的信息（網絡鏈接斷開或者kubelet進程掛掉了並且沒有重啓等狀況）。

注意，節點的事件信息說明了節點的狀態爲NotReady，而且節點上的Pods也再也不是運行的狀態了（這些Pod將會節點處於NotReady狀態在5分鐘後中止）。

$  kubectl get nodes
NAME                     LABELS                                          STATUS
kubernetes-minion-861h   kubernetes.io/hostname=kubernetes-minion-861h   NotReady
kubernetes-minion-bols   kubernetes.io/hostname=kubernetes-minion-bols   Ready
kubernetes-minion-st6x   kubernetes.io/hostname=kubernetes-minion-st6x   Ready
kubernetes-minion-unaj   kubernetes.io/hostname=kubernetes-minion-unaj   Ready

$  kubectl describe node kubernetes-minion-861h
Name:           kubernetes-minion-861h
Labels:         kubernetes.io/hostname=kubernetes-minion-861h
CreationTimestamp:  Fri, 10 Jul 2015 14:32:29 -0700
Conditions:
  Type      Status      LastHeartbeatTime           LastTransitionTime          Reason                  Message
  Ready     Unknown     Fri, 10 Jul 2015 14:34:32 -0700     Fri, 10 Jul 2015 14:35:15 -0700     Kubelet stopped posting node status.   
Addresses:  10.240.115.55,104.197.0.26
Capacity:
 cpu:       1
 memory:    3800808Ki
 pods:      100
Version:
 Kernel Version:        3.16.0-0.bpo.4-amd64
 OS Image:          Debian GNU/Linux 7 (wheezy)
 Container Runtime Version: docker://Unknown
 Kubelet Version:       v0.21.1-185-gffc5a86098dc01
 Kube-Proxy Version:        v0.21.1-185-gffc5a86098dc01
PodCIDR:            10.244.0.0/24
ExternalID:         15233045891481496305
Pods:               (0 in total)
  Namespace         Name
Events:
  FirstSeen             LastSeen            Count   From                    SubobjectPath   Reason      Message
  Fri, 10 Jul 2015 14:32:28 -0700   Fri, 10 Jul 2015 14:32:28 -0700 1   {kubelet kubernetes-minion-861h}            NodeNotReady    Node kubernetes-minion-861h status is now: NodeNotReady
  Fri, 10 Jul 2015 14:32:30 -0700   Fri, 10 Jul 2015 14:32:30 -0700 1   {kubelet kubernetes-minion-861h}            NodeNotReady    Node kubernetes-minion-861h status is now: NodeNotReady
  Fri, 10 Jul 2015 14:33:00 -0700   Fri, 10 Jul 2015 14:33:00 -0700 1   {kubelet kubernetes-minion-861h}            starting    Starting kubelet.
  Fri, 10 Jul 2015 14:33:02 -0700   Fri, 10 Jul 2015 14:33:02 -0700 1   {kubelet kubernetes-minion-861h}            NodeReady   Node kubernetes-minion-861h status is now: NodeReady
  Fri, 10 Jul 2015 14:35:15 -0700   Fri, 10 Jul 2015 14:35:15 -0700 1   {controllermanager }                    NodeNotReady    Node kubernetes-minion-861h status is now: NodeNotReady


$  kubectl get node kubernetes-minion-861h -o yaml
apiVersion: v1
kind: Node
metadata:
  creationTimestamp: 2015-07-10T21:32:29Z
  labels:
    kubernetes.io/hostname: kubernetes-minion-861h
  name: kubernetes-minion-861h
  resourceVersion: "757"
  selfLink: /api/v1/nodes/kubernetes-minion-861h
  uid: 2a69374e-274b-11e5-a234-42010af0d969
spec:
  externalID: "15233045891481496305"
  podCIDR: 10.244.0.0/24
  providerID: gce://striped-torus-760/us-central1-b/kubernetes-minion-861h
status:
  addresses:
  - address: 10.240.115.55
    type: InternalIP
  - address: 104.197.0.26
    type: ExternalIP
  capacity:
    cpu: "1"
    memory: 3800808Ki
    pods: "100"
  conditions:
  - lastHeartbeatTime: 2015-07-10T21:34:32Z
    lastTransitionTime: 2015-07-10T21:35:15Z
    reason: Kubelet stopped posting node status.
    status: Unknown
    type: Ready
  nodeInfo:
    bootID: 4e316776-b40d-4f78-a4ea-ab0d73390897
    containerRuntimeVersion: docker://Unknown
    kernelVersion: 3.16.0-0.bpo.4-amd64
    kubeProxyVersion: v0.21.1-185-gffc5a86098dc01
    kubeletVersion: v0.21.1-185-gffc5a86098dc01
    machineID: ""
    osImage: Debian GNU/Linux 7 (wheezy)
    systemUUID: ABE5F6B4-D44B-108B-C46A-24CCE16C8B6E

2、k8s用戶界面

k8s擁有一個web界面以圖形化的形式爲用戶展現集羣的狀態信息。

一、訪問用戶界面

默認狀況下，UI是以集羣插件的形式部署的。

訪問

https://<kubernetes-master>/ui

將會重定向到

https://<kubernetes-master>/api/v1/proxy/namespaces/kube-system/services/kube-ui/#/dashboard/

若是你沒法訪問集羣的UI界面，多是由於kube-ui進程並無在你的集羣中啓動，這樣的話，你能夠經過手動來啓動：

kubectl create -f cluster/addons/kube-ui/kube-ui-rc.yaml --namespace=kube-system
kubectl create -f cluster/addons/kube-ui/kube-ui-svc.yaml --namespace=kube-system

通常狀況下，這應該是運行在Master節點上的kube-addons.sh腳本自動進行的操做。

二、使用用戶界面

k8s的UI能夠用來反饋集羣當前的信息，例如，檢查多少資源被分配了或者查看錯誤信息。

可是，你不能使用UI界面來修改你的集羣配置。

三、節點資源的使用狀況

在訪問UI界面以後，你將會看到一個主界面，動態列出了集羣中的全部節點，相關信息包括：內部IP地址、CPU使用、內存使用和文件系統使用狀況等信息。

四、儀表板視圖

點擊右上角的「Views」按鈕能夠看到其餘可用的視圖，包括：Explore, Pods, Nodes, Replication Controllers, Services和Events.

五、探索視圖

「Explore」視圖容許你方便地查看當前集羣中的Pods、RCs和SVCs。

「Group by」下拉列表容許你根據一些因素對這些資源進行分組，例如：類型、名稱和主機等等。

你也能夠經過點擊任一資源實例上向下的三角形來建立過濾器，選擇好你想要的過濾器類型便可。

點擊任一資源實例能夠看到更多詳細信息。

六、其餘視圖

其餘視圖（包括Pods, Nodes, Replication Controllers, Services和Events）只是簡單地列出了每一個資源的類型信息，你能夠經過點擊來得到更詳細的信息。

七、更多UI的介紹信息

請看 Kubernetes UI development document

3、日誌信息

一、k8s組件記錄的日誌

k8s的組件，例如kubelet和apiserver都是使用 glog日誌庫，開發商約定的日誌級別描述請看：

docs/devel/logging.md

二、檢查運行中容器的日誌

運行中的容器產生的日誌信息能夠經過kubectl logs來得到。

例如，如今有一個根據這個配置文件   counter-pod.yaml來生成的Pod，其中有一個容器每秒會輸出一些文本信息（你能夠在這裏 here找到不一樣的Pod聲明）。

apiVersion: v1
kind: Pod
metadata:
  name: counter
spec:
  containers:
  - name: count
    image: ubuntu:14.04
    args: [bash, -c, 
            'for ((i = 0; ; i++)); do echo "$i: $(date)"; sleep 1; done']

Download example

咱們運行這個Pod：

$  kubectl create -f ./counter-pod.yaml
pods/counter

而後獲取它的日誌信息：

$  kubectl logs counter
0: Tue Jun  2 21:37:31 UTC 2015
1: Tue Jun  2 21:37:32 UTC 2015
2: Tue Jun  2 21:37:33 UTC 2015
3: Tue Jun  2 21:37:34 UTC 2015
4: Tue Jun  2 21:37:35 UTC 2015
5: Tue Jun  2 21:37:36 UTC 2015
...

若是Pod中不止只有一個容器，那麼你須要指明哪一個容器的日誌文件是你想要獲取的。

$  kubectl logs kube-dns-v3-7r1l9 etcd
2015/06/23 00:43:10 etcdserver: start to snapshot (applied: 30003, lastsnap: 20002)
2015/06/23 00:43:10 etcdserver: compacted log at index 30003
2015/06/23 00:43:10 etcdserver: saved snapshot at index 30003
2015/06/23 02:05:42 etcdserver: start to snapshot (applied: 40004, lastsnap: 30003)
2015/06/23 02:05:42 etcdserver: compacted log at index 40004
2015/06/23 02:05:42 etcdserver: saved snapshot at index 40004
2015/06/23 03:28:31 etcdserver: start to snapshot (applied: 50005, lastsnap: 40004)
2015/06/23 03:28:31 etcdserver: compacted log at index 50005
2015/06/23 03:28:31 etcdserver: saved snapshot at index 50005
2015/06/23 03:28:56 filePurge: successfully removed file default.etcd/member/wal/0000000000000000-0000000000000000.wal
2015/06/23 04:51:03 etcdserver: start to snapshot (applied: 60006, lastsnap: 50005)
2015/06/23 04:51:03 etcdserver: compacted log at index 60006
2015/06/23 04:51:03 etcdserver: saved snapshot at index 60006
...

三、Google雲日誌系統

Cluster Level Logging to Google Cloud Logging這個入門指南展現了容器的日誌是如何被記錄到 Google Cloud Logging中的，而且會說明如何查詢這些日誌。

四、Elasticsearch和Kibana

Cluster Level Logging with Elasticsearch and Kibana  入門指南描述瞭如何將集羣日誌記錄到Elasticsearch中，而後使用Kibana來查看。

集羣級別的日誌只收集處於運行狀態的容器中容器的標準輸出和標準錯誤信息。

Collecting log files within containers with Fluentd這個指南闡述瞭如何將容器的日誌信息也記錄到Google雲日誌系統中。

五、已知的問題

k8s會會將k8s組件和Docker中容器的日誌輪詢記錄，kubectl logs目前只能查詢最後的日誌，並非全部的歷史記錄。

4、監控

一、在k8s中使用資源監控

對與應用的擴展，而且提供一個高可靠的服務來講，在部署的時候明確地知道應用的行爲是相當重要的。

在k8s集羣中，應用的性能能夠按照不一樣級別來檢查，可分爲：容器、Pods、SVCs和整個集羣。

在這些不一樣的級別上，咱們想爲用戶提供正在運行的程序詳細的資源使用狀況。

這將會使用戶對他們的應用是如何運行的，而且找出應用的瓶頸會有深入的看法。

Heapster這個項目旨在爲k8s以供一個基本的監控平臺。

二、概述

Heapster是一個集羣範圍的監控和事件信息整合者，當前原生支持k8s，而且在各類安裝方式中均可以工做。

Heapster在集羣上以一個Pod的形式運行，就像k8s上任何一個應用同樣。

Heapster這個Pod會發現集羣上的全部節點，而且向節點上的kubelet查詢使用信息，就像k8s的機器代理同樣。

kubelet自己經過 cAdvisor來得到數據，Heapster將這些信息按Pod有關的Label進行分組，以後這些數據將會被可視化並推送到一個可配置的後端存儲。

目前支持的後端包括： InfluxDB（使用 Grafana進行可視化）和 Google Cloud Monitoring。

服務的整體構架以下如：

如今來看看其中的組件的詳細信息。

三、cAdvisor

cAdvisor是一個開源的容器資源使用和性能分析代理，它是爲容器而建造的，原生支持Docker容器。

在k8s中cAdvisor被集成在kubelet中。

cAdvisor會自動發現機器上的全部容器，並收集CPU、內存、文件系統和網絡使用狀況的統計數據。

cAdvisor還能夠經過分析「根」容器來提供整個機器的整體使用狀況。

在大多數k8s集羣上，cAdvisor經過機器上的容器暴露端口號4194提供一個簡單的UI界面。

下面是一個部分cAdvisor UI界面的快照，顯示的是機器的整體使用狀況：

四、Kubelet

Kubelet相似於k8s主節點和從節點之間的一個橋樑。

它管理着機器上運行的Pods和容器，Kubelet將每一個Pod轉換爲其本身的容器，而且從cAdvisor上得到每一個容器的使用狀況統計。

以後，它將會經過REST API來暴露這些整合過的Pods資源使用狀況統計。

五、後端存儲

InfluxDB和Grafana

在開源世界，使用InfluxDB和Grafana進行監控是一個十分受歡迎的組合。

InfluxDB經過暴露一個使用起來很簡單的API來輸出和獲取時間序列的數據。

在大多數k8s集羣上Heapster默認設置使用InfluxDB做爲後端存儲工具。

一個詳細的設置指南能夠看這裏：

here

InfluxDB和Grafana都在Pod中運行，這些Pod將會以SVC的形式暴露出來，這樣Heapster就可以找到它。

Grafana容器提供了一個配置界面叫作：GrafanaUI。

k8s默認的可視化儀表形式的界面包含一個 集羣上的監視器和其中的Pods的資源使用示例視圖。

這個視圖能夠根據須要進行擴展和定製。

點擊這裏查看InfluxDB的存儲模式：

here

下面的視頻展現瞭如何使用heapster, InfluxDB和Grafana來監控集羣：

http://www.youtube.com/watch?v=SZgqjMrxo3g

下面是一個k8s默認的Grafana儀板視圖，顯示了整個集羣、Pod和容器的CPU和內存使用。

Google Cloud Monitoring

Google Cloud Monitoring是一個把控監視的服務，容許你在應用中將重要的指標可視化和警報。

Heapster能夠設置爲自動推送全部收集到的指標到Google Cloud Monitoring中。

以後這些指標能夠在 Cloud Monitoring Console中得到。

這個後端存儲是最容易安裝和維護的。

監視控制檯容許你使用導出的數據很簡單地建立和定製儀表視圖。

下面的視頻介紹瞭如何安裝和運行Google Cloud Monitoring爲Heapster服務：

https://www.youtube.com/watch?v=xSMNR2fcoLs

下面是一個Google Cloud Monitoring儀表視圖的快照，顯示了集羣層面的資源使用：

六、嘗試操做！

如今，你已經學習了一些關於Heapster的知識，能夠隨意在你的集羣上嘗試使用它。

Heapster repository能夠經過Github得到，它包含了安裝Heapster和其後端存儲的詳細說明。

Heapster在大多數k8s集羣上都是默認運行的，因此你可能已經擁有Heapster了。

5、經過exec進入容器

開發者能夠經過exec進入容器中運行命令，這個指南將會演示兩個例子。

一、使用kubectl exec來檢查容器的環境變量

k8s經過環境變量暴露 services。

可使用kubectl exec方便地檢查這些環境變量。

首先咱們建立一個Pod和一個SVC：

$  kubectl create -f examples/guestbook/redis-master-controller.yaml

$  kubectl create -f examples/guestbook/redis-master-service.yaml

等待Pod處於運行和準備狀態：

$  kubectl get pod
NAME                 READY     REASON       RESTARTS   AGE
redis-master-ft9ex   1/1       Running      0          12s

以後咱們能夠檢查Pod的環境變量：

$  kubectl exec redis-master-ft9ex env
...
REDIS_MASTER_SERVICE_PORT=6379
REDIS_MASTER_SERVICE_HOST=10.0.0.219
...

咱們能夠在應用中使用這些環境變量來發現SVC。

二、使用kubectl exec檢查掛載的卷

若是卷像預期的同樣被成功掛載，那麼可使用kubectl exec方便地進行檢查，首先咱們建立一個Pod，其有一個卷被掛載在/data/redis目錄下：

kubectl create -f docs/user-guide/walkthrough/pod-redis.yaml

等待Pod處於運行和準備狀態：

$  kubectl get pods
NAME      READY     REASON    RESTARTS   AGE
storage   1/1       Running   0          1m

使用kubectl exec驗證卷是否有成功掛載：

$  kubectl exec storage ls /data

redis

三、使用kubectl exec在Pod中打開一個bash終端

檢查Pod最好的方式確定是打開一個bash終端進去檢查，假設一個pod/storage一直是運行狀態的，執行：

$  kubectl exec -ti storage -- bash
root@storage:/data#

6、使用kubectl proxy和apiserver proxy鏈接到容器

如今你已經看過了關於kubectl proxy和apiserver proxy的基本信息（ basics）。

這個指南將會展現如何使用它們進入一個運行在k8s集羣上的服務（ kube-ui）。

一、得到kube-ui的apiserver proxy的url

kube-ui經過插件的形式部署，經過下面的方式能夠得到apiserver proxy的url：

$  kubectl cluster-info | grep "KubeUI"
KubeUI is running at https://173.255.119.104/api/v1/proxy/namespaces/kube-system/services/kube-ui

若是這個命令沒法找到url，請看這裏：

here

二、在本地工做站鏈接到kube-ui service

上面說的代理url是一個鏈接到apiserver提供的kube-ui服務。

爲了鏈接它，你仍然須要驗證apiserver，kubectl proxy能夠進行驗證：

$  kubectl proxy --port=8001
Starting to serve on localhost:8001

如今你在本地工做站能夠鏈接到kube-ui服務：

http://localhost:8001/api/v1/proxy/namespaces/kube-system/services/kube-ui

7、kubectl port-forward鏈接應用

kubectl port-forward 轉發本地端口到Pod中的端口。

其主頁面能夠經過這裏得到：

here

和 kubectl proxy ,相對比，kubectl port-forward的做用更爲普遍，由於它可以轉發TCP流量而kubectl proxy只能轉發HTTP流量。

這個指南演示瞭如何使用kubectl port-forward來鏈接到一個redis數據庫，這在調試數據庫的時候是頗有用的。

一、建立一個Redis Master

$  kubectl create examples/redis/redis-master.yaml

pods/redis-master

等待Redis Master處於運行和就緒狀態：

$  kubectl get pods
NAME           READY     STATUS    RESTARTS   AGE
redis-master   2/2       Running   0          41s

二、鏈接到Redis Master

驗證Redis Master監聽6397端口：

$  kubectl get pods redis-master -t='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
6379

以後，將本地6379端口轉發到Pod中的6379端口：

$  kubectl port-forward redis-master 6379:6379
I0710 14:43:38.274550    3655 portforward.go:225] Forwarding from 127.0.0.1:6379 -> 6379
I0710 14:43:38.274797    3655 portforward.go:225] Forwarding from [::1]:6379 -> 6379

在本地執行redis-cli來驗證鏈接是否成功：

$  redis-cli
127.0.0.1:6379>  ping

PONG

如今就能夠從本地來調試這個數據庫了