Kubernetes使用者指南（四）--應用檢查和除錯
阿新 • • 發佈：2018-12-25
一、除錯
當你的應用開始執行，那麼DEBUG是不可避免的問題。
早些時候，我們在描述的是如何通過kubectl get pods來獲得Pod的簡單狀態資訊。
但是現在，這裡有更多的方式來獲得關於你的應用的更多資訊。
1、使用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: 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”欄位告訴你發生的事件是什麼。 2、例子：除錯處於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的資訊。 你可以使用
apiVersion: v1
kind: Pod
metadata:
annotations:
'{"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
3、例子：除錯掛掉的節點 有時候，檢視節點的狀態在除錯時是非常有用的，例如你可以從這個節點獲得Pod的一些奇怪的行為資訊，或者找出為什麼Pod沒有在這個節點上被排程的原因。 和Pod的一些命令一樣，你也可以使用kubectl describe node和kubectl get node -o yaml來獲得有關節點的詳細資訊。 例如，這裡是一些在節點掛掉的時候你可以看到的資訊（網路連線斷開或者kubelet程序掛掉了而且沒有重啟等情況）。 注意，節點的事件資訊說明了節點的狀態為NotReady，並且節點上的Pods也不再是執行的狀態了（這些Pod將會節點處於NotReady狀態在5分鐘後停止）。 $ kubectl get nodes
NAME LABELS STATUS
$ kubectl describe node kubernetes-minion-861h
Name: 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:
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
二、k8s使用者介面 k8s擁有一個web介面以圖形化的形式為使用者展示叢集的狀態資訊。 1、訪問使用者介面 預設情況下，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指令碼自動進行的操作。 2、使用使用者介面 k8s的UI可以用來反饋叢集當前的資訊，例如，檢查多少資源被分配了或者檢視錯誤資訊。 但是，你不能使用UI介面來修改你的叢集配置。 3、節點資源的使用情況 在訪問UI介面之後，你將會看到一個主介面，動態列出了叢集中的所有節點，相關資訊包括：內部IP地址、CPU使用、記憶體使用和檔案系統使用情況等資訊。 4、儀表板檢視 點選右上角的“Views”按鈕可以看到其他可用的檢視，包括：Explore, Pods, Nodes, Replication Controllers, Services和Events. 5、探索檢視 “Explore”檢視允許你方便地檢視當前叢集中的Pods、RCs和SVCs。 “Group by”下拉列表允許你根據一些因素對這些資源進行分組，例如：型別、名稱和主機等等。 你也可以通過點選任一資源例項上向下的三角形來建立過濾器，選擇好你想要的過濾器型別即可。 點選任一資源例項可以看到更多詳細資訊。 6、其他檢視 其他檢視（包括Pods, Nodes, Replication Controllers, Services和Events）只是簡單地列出了每個資源的型別資訊，你可以通過點選來獲得更詳細的資訊。 7、更多UI的介紹資訊 三、日誌資訊 1、k8s元件記錄的日誌 k8s的元件，例如kubelet和apiserver都是使用glog日誌庫，開發商約定的日誌級別描述請看： 2、檢查執行中容器的日誌 執行中的容器產生的日誌資訊可以通過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']
我們執行這個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
...
3、Google雲日誌系統 4、Elasticsearch和Kibana 叢集級別的日誌只收集處於執行狀態的容器中容器的標準輸出和標準錯誤資訊。 5、已知的問題 k8s會會將k8s元件和Docker中容器的日誌輪詢記錄，kubectl logs目前只能查詢最後的日誌，並不是所有的歷史記錄。 四、監控 1、在k8s中使用資源監控 對與應用的擴充套件，並且提供一個高可靠的服務來說，在部署的時候明確地知道應用的行為是至關重要的。 在k8s叢集中，應用的效能可以按照不同級別來檢查，可分為：容器、Pods、SVCs和整個叢集。 在這些不同的級別上，我們想為使用者提供正在執行的程式詳細的資源使用情況。 這將會使使用者對他們的應用是如何執行的，並且找出應用的瓶頸會有深刻的見解。 Heapster這個專案旨在為k8s以供一個基本的監控平臺。 2、概述 Heapster是一個叢集範圍的監控和事件資訊整合者，當前原生支援k8s，並且在各種安裝方式中都可以工作。 Heapster在叢集上以一個Pod的形式執行，就像k8s上任何一個應用一樣。 Heapster這個Pod會發現叢集上的所有節點，並且向節點上的kubelet查詢使用資訊，就像k8s的機器代理一樣。 kubelet本身通過cAdvisor來獲得資料，Heapster將這些資訊按Pod有關的Label進行分組，之後這些資料將會被視覺化並推送到一個可配置的後端儲存。 服務的總體構架如下如： 現在來看看其中的元件的詳細資訊。 3、cAdvisor cAdvisor是一個開源的容器資源使用和效能分析代理，它是為容器而建造的，原生支援Docker容器。 在k8s中cAdvisor被整合在kubelet中。 cAdvisor會自動發現機器上的所有容器，並收集CPU、記憶體、檔案系統和網路使用情況的統計資料。 cAdvisor還可以通過分析“根”容器來提供整個機器的總體使用情況。 在大多數k8s叢集上，cAdvisor通過機器上的容器暴露埠號4194提供一個簡單的UI介面。 下面是一個部分cAdvisor UI介面的快照，顯示的是機器的總體使用情況： 4、Kubelet Kubelet類似於k8s主節點和從節點之間的一個橋樑。 它管理著機器上執行的Pods和容器，Kubelet將每個Pod轉換為其自己的容器，並且從cAdvisor上獲得每個容器的使用情況統計。 之後，它將會通過REST API來暴露這些整合過的Pods資源使用情況統計。 5、後端儲存 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來監控叢集： 下面是一個k8s預設的Grafana儀板檢視，顯示了整個叢集、Pod和容器的CPU和記憶體使用。 Google Cloud Monitoring Google Cloud Monitoring是一個把控監視的服務，允許你在應用中將重要的指標視覺化和警報。 Heapster可以設定為自動推送所有收集到的指標到Google Cloud Monitoring中。 這個後端儲存是最容易安裝和維護的。 監視控制檯允許你使用匯出的資料很簡單地建立和定製儀表檢視。 下面的視訊介紹瞭如何安裝和執行Google Cloud Monitoring為Heapster服務： 下面是一個Google Cloud Monitoring儀表檢視的快照，顯示了叢集層面的資源使用： 6、嘗試操作！ 現在，你已經學習了一些關於Heapster的知識，可以隨意在你的叢集上嘗試使用它。 Heapster repository可以通過Github獲得，它包含了安裝Heapster和其後端儲存的詳細說明。 Heapster在大多數k8s叢集上都是預設執行的，所以你可能已經擁有Heapster了。 五、通過exec進入容器 開發者可以通過exec進入容器中執行命令，這個指南將會演示兩個例子。 1、使用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。 2、使用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 3、使用kubectl exec在Pod中開啟一個bash終端 檢查Pod最好的方式肯定是開啟一個bash終端進去檢查，假設一個pod/storage一直是執行狀態的，執行： $ kubectl exec -ti storage -- bash
[email protected]:/data#
六、使用kubectl proxy和apiserver proxy連線到容器 現在你已經看過了關於kubectl proxy和apiserver proxy的基本資訊（basics）。 這個指南將會展示如何使用它們進入一個執行在k8s叢集上的服務（kube-ui）。 1、獲得kube-ui的apiserver proxy的url kube-ui通過外掛的形式部署，通過下面的方式可以獲得apiserver proxy的url： 如果這個命令無法找到url，請看這裡： here 2、在本地工作站連線到kube-ui service 上面說的代理url是一個連線到apiserver提供的kube-ui服務。 為了連線它，你仍然需要驗證apiserver，kubectl proxy可以進行驗證： $ kubectl proxy --port=8001
Starting to serve on localhost:8001
現在你在本地工作站可以連線到kube-ui服務： 七、kubectl port-forward連線應用 kubectl port-forward 轉發本地埠到Pod中的埠。 其主頁面可以通過這裡獲得： here 和kubectl proxy,相對比，kubectl port-forward的作用更為廣泛，因為它能夠轉發TCP流量而kubectl proxy只能轉發HTTP流量。 這個指南演示瞭如何使用kubectl port-forward來連線到一個redis資料庫，這在除錯資料庫的時候是很有用的。 1、建立一個Redis Master $ kubectl create examples/redis/redis-master.yaml pods/redis-master
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: 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”欄位告訴你發生的事件是什麼。 2、例子：除錯處於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 yamlapiVersion: v1
kind: Pod
metadata:
annotations:
'{"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
3、例子：除錯掛掉的節點 有時候，檢視節點的狀態在除錯時是非常有用的，例如你可以從這個節點獲得Pod的一些奇怪的行為資訊，或者找出為什麼Pod沒有在這個節點上被排程的原因。 和Pod的一些命令一樣，你也可以使用kubectl describe node和kubectl get node -o yaml來獲得有關節點的詳細資訊。 例如，這裡是一些在節點掛掉的時候你可以看到的資訊（網路連線斷開或者kubelet程序掛掉了而且沒有重啟等情況）。 注意，節點的事件資訊說明了節點的狀態為NotReady，並且節點上的Pods也不再是執行的狀態了（這些Pod將會節點處於NotReady狀態在5分鐘後停止）。 $ kubectl get nodes
NAME LABELS STATUS
$ kubectl describe node kubernetes-minion-861h
Name: 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:
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
二、k8s使用者介面 k8s擁有一個web介面以圖形化的形式為使用者展示叢集的狀態資訊。 1、訪問使用者介面 預設情況下，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指令碼自動進行的操作。 2、使用使用者介面 k8s的UI可以用來反饋叢集當前的資訊，例如，檢查多少資源被分配了或者檢視錯誤資訊。 但是，你不能使用UI介面來修改你的叢集配置。 3、節點資源的使用情況 在訪問UI介面之後，你將會看到一個主介面，動態列出了叢集中的所有節點，相關資訊包括：內部IP地址、CPU使用、記憶體使用和檔案系統使用情況等資訊。 4、儀表板檢視 點選右上角的“Views”按鈕可以看到其他可用的檢視，包括：Explore, Pods, Nodes, Replication Controllers, Services和Events. 5、探索檢視 “Explore”檢視允許你方便地檢視當前叢集中的Pods、RCs和SVCs。 “Group by”下拉列表允許你根據一些因素對這些資源進行分組，例如：型別、名稱和主機等等。 你也可以通過點選任一資源例項上向下的三角形來建立過濾器，選擇好你想要的過濾器型別即可。 點選任一資源例項可以看到更多詳細資訊。 6、其他檢視 其他檢視（包括Pods, Nodes, Replication Controllers, Services和Events）只是簡單地列出了每個資源的型別資訊，你可以通過點選來獲得更詳細的資訊。 7、更多UI的介紹資訊 三、日誌資訊 1、k8s元件記錄的日誌 k8s的元件，例如kubelet和apiserver都是使用glog日誌庫，開發商約定的日誌級別描述請看： 2、檢查執行中容器的日誌 執行中的容器產生的日誌資訊可以通過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']
我們執行這個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
...
3、Google雲日誌系統 4、Elasticsearch和Kibana 叢集級別的日誌只收集處於執行狀態的容器中容器的標準輸出和標準錯誤資訊。 5、已知的問題 k8s會會將k8s元件和Docker中容器的日誌輪詢記錄，kubectl logs目前只能查詢最後的日誌，並不是所有的歷史記錄。 四、監控 1、在k8s中使用資源監控 對與應用的擴充套件，並且提供一個高可靠的服務來說，在部署的時候明確地知道應用的行為是至關重要的。 在k8s叢集中，應用的效能可以按照不同級別來檢查，可分為：容器、Pods、SVCs和整個叢集。 在這些不同的級別上，我們想為使用者提供正在執行的程式詳細的資源使用情況。 這將會使使用者對他們的應用是如何執行的，並且找出應用的瓶頸會有深刻的見解。 Heapster這個專案旨在為k8s以供一個基本的監控平臺。 2、概述 Heapster是一個叢集範圍的監控和事件資訊整合者，當前原生支援k8s，並且在各種安裝方式中都可以工作。 Heapster在叢集上以一個Pod的形式執行，就像k8s上任何一個應用一樣。 Heapster這個Pod會發現叢集上的所有節點，並且向節點上的kubelet查詢使用資訊，就像k8s的機器代理一樣。 kubelet本身通過cAdvisor來獲得資料，Heapster將這些資訊按Pod有關的Label進行分組，之後這些資料將會被視覺化並推送到一個可配置的後端儲存。 服務的總體構架如下如： 現在來看看其中的元件的詳細資訊。 3、cAdvisor cAdvisor是一個開源的容器資源使用和效能分析代理，它是為容器而建造的，原生支援Docker容器。 在k8s中cAdvisor被整合在kubelet中。 cAdvisor會自動發現機器上的所有容器，並收集CPU、記憶體、檔案系統和網路使用情況的統計資料。 cAdvisor還可以通過分析“根”容器來提供整個機器的總體使用情況。 在大多數k8s叢集上，cAdvisor通過機器上的容器暴露埠號4194提供一個簡單的UI介面。 下面是一個部分cAdvisor UI介面的快照，顯示的是機器的總體使用情況： 4、Kubelet Kubelet類似於k8s主節點和從節點之間的一個橋樑。 它管理著機器上執行的Pods和容器，Kubelet將每個Pod轉換為其自己的容器，並且從cAdvisor上獲得每個容器的使用情況統計。 之後，它將會通過REST API來暴露這些整合過的Pods資源使用情況統計。 5、後端儲存 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來監控叢集： 下面是一個k8s預設的Grafana儀板檢視，顯示了整個叢集、Pod和容器的CPU和記憶體使用。 Google Cloud Monitoring Google Cloud Monitoring是一個把控監視的服務，允許你在應用中將重要的指標視覺化和警報。 Heapster可以設定為自動推送所有收集到的指標到Google Cloud Monitoring中。 這個後端儲存是最容易安裝和維護的。 監視控制檯允許你使用匯出的資料很簡單地建立和定製儀表檢視。 下面的視訊介紹瞭如何安裝和執行Google Cloud Monitoring為Heapster服務： 下面是一個Google Cloud Monitoring儀表檢視的快照，顯示了叢集層面的資源使用： 6、嘗試操作！ 現在，你已經學習了一些關於Heapster的知識，可以隨意在你的叢集上嘗試使用它。 Heapster repository可以通過Github獲得，它包含了安裝Heapster和其後端儲存的詳細說明。 Heapster在大多數k8s叢集上都是預設執行的，所以你可能已經擁有Heapster了。 五、通過exec進入容器 開發者可以通過exec進入容器中執行命令，這個指南將會演示兩個例子。 1、使用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。 2、使用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 3、使用kubectl exec在Pod中開啟一個bash終端 檢查Pod最好的方式肯定是開啟一個bash終端進去檢查，假設一個pod/storage一直是執行狀態的，執行： $ kubectl exec -ti storage -- bash
[email protected]:/data#
六、使用kubectl proxy和apiserver proxy連線到容器 現在你已經看過了關於kubectl proxy和apiserver proxy的基本資訊（basics）。 這個指南將會展示如何使用它們進入一個執行在k8s叢集上的服務（kube-ui）。 1、獲得kube-ui的apiserver proxy的url kube-ui通過外掛的形式部署，通過下面的方式可以獲得apiserver proxy的url： 如果這個命令無法找到url，請看這裡： here 2、在本地工作站連線到kube-ui service 上面說的代理url是一個連線到apiserver提供的kube-ui服務。 為了連線它，你仍然需要驗證apiserver，kubectl proxy可以進行驗證： $ kubectl proxy --port=8001
Starting to serve on localhost:8001
現在你在本地工作站可以連線到kube-ui服務： 七、kubectl port-forward連線應用 kubectl port-forward 轉發本地埠到Pod中的埠。 其主頁面可以通過這裡獲得： here 和kubectl proxy,相對比，kubectl port-forward的作用更為廣泛，因為它能夠轉發TCP流量而kubectl proxy只能轉發HTTP流量。 這個指南演示瞭如何使用kubectl port-forward來連線到一個redis資料庫，這在除錯資料庫的時候是很有用的。 1、建立一個Redis Master $ kubectl create examples/redis/redis-master.yaml pods/redis-master