1. 程式人生 > >kubernetes之pod狀態分析

kubernetes之pod狀態分析

k8s pod 狀態分析

pod從建立到最後的建立成功會分別處於不同的階段,在原始碼中用PodPhase來表示不同的階段:

PodPending PodPhase = "Pending"
PodRunning PodPhase = "Running"
PodSucceeded PodPhase = "Succeeded"
PodFailed PodPhase = "Failed"
PodUnknown PodPhase = "Unknown"

一個pod的完整建立,通常會伴隨著各種事件的產生,k8s種事件的種類總共只有4種:

Added    EventType = "ADDED"
Modified EventType = "MODIFIED" Deleted EventType = "DELETED" Error EventType = "ERROR"
  • Pending 建立pod的請求已經被k8s接受,但是容器並沒有啟動成功,可能處在:寫資料到etcd,排程,pull映象,啟動容器這四個階段中的任何一個階段,pending伴隨的事件通常會有:ADDED, Modified這兩個事件的產生。
  • Running pod已經繫結到node節點,並且所有的容器已經啟動成功,或者至少有一個容器在執行,或者在重啟中。
  • Succeeded pod中的所有的容器已經正常的自行退出,並且k8s永遠不會自動重啟這些容器,一般會是在部署job的時候會出現。
  • Failed pod中的所有容器已經終止,並且至少有一個容器已經終止於失敗(退出非零退出程式碼或被系統停止)。
  • Unknown 由於某種原因,無法獲得pod的狀態,通常是由於與pod的主機通訊錯誤。

以上說到的pod的狀態是粗略的狀態,還有更佳詳細的狀態資訊,在原始碼中表示如下:

PodScheduled PodConditionType = "PodScheduled"
PodReady PodConditionType = "Ready"
PodInitialized PodConditionType = "Initialized"
PodReasonUnschedulable = "Unschedulable"
type PodCondition struct {
  Type PodConditionType `json:"type" protobuf:"bytes,1,opt,name=type,casttype=PodConditionType"`
  Status ConditionStatus `json:"status" protobuf:"bytes,2,opt,name=status,casttype=ConditionStatus"`
  LastProbeTime metav1.Time `json:"lastProbeTime,omitempty" protobuf:"bytes,3,opt,name=lastProbeTime"`
  LastTransitionTime metav1.Time `json:"lastTransitionTime,omitempty" protobuf:"bytes,4,opt,name=lastTransitionTime"`
  Reason string `json:"reason,omitempty" protobuf:"bytes,5,opt,name=reason"`
  Message string `json:"message,omitempty" protobuf:"bytes,6,opt,name=message"`
}
  • PodScheduled pod正處於排程中,剛開始排程的時候,hostip還沒繫結上,持續排程之後,有合適的節點就會繫結hostip,然後更新etcd資料
  • Initialized pod中的所有初始化容器已經初啟動完畢
  • Ready pod中的容器可以提供服務了
  • Unschedulable 不能排程,沒有合適的節點

PodCondition中的ConditionStatus,它代表了當前pod是否處於某一個階段(PodScheduled,Ready,Initialized,Unschedulable),“true” 表示處於,“false”表示不處於

以下通過建立一個pod來具體的看看從pod建立到成功所觸發的事件,以及pod相關狀態的改變

kubectl apply -f busybox.yaml

第一步:寫入資料到etcd

event type: ADDED 
event object: 
{
    "phase": "Pending",
    "qosClass": "BestEffort"
}

第二步:開始被排程,但是還未排程到具體node上,請注意:PodScheduled的status=“true”

event type: MODIFIED
{
  "phase": "Pending",
  "conditions": [
    {
      "type": "PodScheduled",
      "status": "True",
      "lastProbeTime": null,
      "lastTransitionTime": "2017-06-06T07:57:06Z"
    }
  ],
  "qosClass": "BestEffort"
}

第三步:被排程到了具體的node上hostip綁定了,並且被所有初始化容器已經啟動完畢(注意我的busybox.yaml中pod沒有指定init container,所以這裡很快就被設定成true),被排程到的節點watch到並開始建立容器(此階段是在拉去映象)然後建立容器 ,而此時Ready的status是false,仔細看會發現,containerStatus的狀態未waiting

event type: MODIFIED
{
  "phase": "Pending",
  "conditions": [
    {
      "type": "Initialized",
      "status": "True",
      "lastProbeTime": null,
      "lastTransitionTime": "2017-06-06T07:57:06Z"
    },
    {
      "type": "Ready",
      "status": "False",
      "lastProbeTime": null,
      "lastTransitionTime": "2017-06-06T07:57:06Z",
      "reason": "ContainersNotReady",
      "message": "containers with unready status: [busybox]"
    },
    {
      "type": "PodScheduled",
      "status": "True",
      "lastProbeTime": null,
      "lastTransitionTime": "2017-06-06T07:57:06Z"
    }
  ],
  "hostIP": "10.39.1.35",
  "startTime": "2017-06-06T07:57:06Z",
  "containerStatuses": [
    {
      "name": "busybox",
      "state": {
        "waiting": {
          "reason": "ContainerCreating"
        }
      },
      "lastState": {},
      "ready": false,
      "restartCount": 0,
      "image": "busybox",
      "imageID": ""
    }
  ],
  "qosClass": "BestEffort"
}

第四步:容器建立成功,Ready的status=“true”,此時容器的status也為running,這個時候,對應的pod的PodPhase也應該為running

event type: MODIFIED
{
  "phase": "Running",
  "conditions": [
    {
      "type": "Initialized",
      "status": "True",
      "lastProbeTime": null,
      "lastTransitionTime": "2017-06-06T07:57:06Z"
    },
    {
      "type": "Ready",
      "status": "True",
      "lastProbeTime": null,
      "lastTransitionTime": "2017-06-06T07:57:08Z"
    },
    {
      "type": "PodScheduled",
      "status": "True",
      "lastProbeTime": null,
      "lastTransitionTime": "2017-06-06T07:57:06Z"
    }
  ],
  "hostIP": "10.39.1.35",
  "podIP": "192.168.107.204",
  "startTime": "2017-06-06T07:57:06Z",
  "containerStatuses": [
    {
      "name": "busybox",
      "state": {
        "running": {
          "startedAt": "2017-06-06T07:57:08Z"
        }
      },
      "lastState": {},
      "ready": true,
      "restartCount": 0,
      "image": "busybox:latest",
      "imageID": "docker-pullable://[email protected]:c79345819a6882c31b41bc771d9a94fc52872fa651b36771fbe0c8461d7ee558",
      "containerID": "docker://a6af9d58c7dabf55fdfe8d4222b2c16349e3b49b3d0eca4bc761fdb571f3cf44"
    }
  ],
  "qosClass": "BestEffort"
}

相關推薦

kubernetespod狀態分析

k8s pod 狀態分析 pod從建立到最後的建立成功會分別處於不同的階段,在原始碼中用PodPhase來表示不同的階段: PodPending PodPhase = "Pending" PodRunning PodPhase = "Running" P

Kubernetes叢集中,Node異常時Pod狀態分析

摘要:Kubernetes叢集中Node NotReady是經常遇到的現象,我們

KubernetesPOD

repl 共享網絡 內容 light ons cat period 之前 target 什麽是Pod Pod是可以創建和管理Kubernetes計算的最小可部署單元。一個Pod代表著集群中運行的一個進程。 Pod就像是豌豆莢一樣,它由一個或者多個容器組成(例如Docker

KubernetesPod 控制器

object 調用 get 基本 contain 名稱 argument ring efault 定義Pod的常用資源 pods.spec.containers - name <string> #containers 的名字   image &

KubernetesPod排程_Kubernetes中文社群

【編者的話】Kubernetes排程器根據特定的演算法與策略將pod排程到工作節點上。在預設情況下,Kubernetes排程器可以滿足絕大多數需求,例如排程pod到資源充足的節點上執行,或排程pod分散到不同節點使叢集節點資源均衡等。但一些特殊的場景,預設排程演算法策略並不能滿足實際需求,例如

kubernetespod中斷

系列目錄 目標讀者: 想要構建高可用應用的應用所有者,因此需要知道pod會發生哪些型別的中斷 想要執行自動化(比如升級和自動擴容)的叢集管理員. 自願和非自願的中斷 pod不會自動訊息,除非有人(可能是一個人或者一個控制器)把它銷燬了,或者出現無法避免的硬體或者系統軟體錯誤. 我們把這些稱作非自願的不

Linux系統執行狀態分析及問題排查思路

〇、一件事兒 以下分析是站在Java工程師的角度來分析的。 一、CPU分析 分析CPU的繁忙程度,兩個指標:系統負載和CPU利用率 1、系統負載分析 系統負載:在Linux系統中表示,一段時間內正在執行程序數和CPU執行佇列中就緒等待程序數,以及非常重要的休眠但不可中斷的程序數的平均值(具體load值的計算

06 . KubernetesPod控制器詳細介紹及應用

#### Pod API屬性詳解 > Pod是k8s叢集中的最小編排單位。將這個設計落實到API物件上,容器就成了Pod屬性裡一個普通的欄位。那麼到底哪些屬性屬於Pod物件,哪些屬性屬於容器的呢?先看下面的一段描述: > > > > 假如把Pod看成傳統環境裡的"機器"、那麼容器就是執行在這個"機器"

kubernetes/k8s原始碼分析】kubectl-controller-managerpod gc原始碼分析

  引數:    --controllers strings:配置需要enable的列表         這裡也包括podgc          All con

mysql狀態分析show global status

其中 正在 中一 未使用 更多 同事 排序 eat 配置文件 公司的nagios監控服務器長期對內網用MySQL數據庫發出ctritical報警,因為我將其他同事的手機短信報警也開通了,搞得整個系統組的同事都怨聲載道(呵呵)這時候就需要根據其status對其Mysql數據庫

Kubernetes對象Pod詳解(附安裝部署方法)

虛擬化技術 kubernetes docker 首先介紹一下K8S是什麽:(引用自K8S中文社區)Kubernetes是容器集群管理系統,是一個開源的平臺,可以實現容器集群的自動化部署、自動擴縮容、維護等功能。通過Kubernetes你可以:快速部署應用快速擴展應用無縫對接新的應用功能節省資源,優

mysql狀態分析show global status(轉)

http 運行 global 系統性能 數據量 -- ror 必須 request mysql> show global status;可以列出MySQL服務器運行各種狀態值,我個人較喜歡的用法是show status like ‘查詢值%‘;一、慢查詢mysql&g

kubernetesScheduler分析

1. kubernetes Scheduler 簡介 kubernetes Scheduler 執行在 master 節點,它的核心功能是監聽 apiserver 來獲取 PodSpec.NodeName 為空的 pod,然後為每個這樣的 pod 建立一個 binding 指示 pod 應該排程

kubernetes/k8s原始碼分析】kubelet原始碼分析cdvisor原始碼分析

  資料流 UnsecuredDependencies -> run   1. cadvisor.New初始化 if kubeDeps.CAdvisorInterface == nil { imageFsInfoProvider := cadv

kubernetes/k8s原始碼分析】 controller-managerreplicaset原始碼分析

ReplicaSet簡介     Kubernetes 中建議使用 ReplicaSet來取代 ReplicationController。ReplicaSet 跟 ReplicationController 沒有本質的不同, ReplicaSet 支援集合式的

kubernetes/k8s原始碼分析】 client-go包Informer原始碼分析

Informer 簡介        Informer 是 Client-go 中的一個核心工具包。如果 Kubernetes 的某個元件,需要 List/Get Kubernetes 中的 Object(包括pod,service等等),可以直接使用

21天轉型容器實戰營(十二容器進階Kubernetes 儲存管理原理分析

大綱 為何需要儲存卷? 普通儲存卷 應用中使用普通卷 持久化儲存卷(PV) 持久化儲存卷申明(PVC) 應用中使用持久化卷 為何需要儲存卷? 容器部署過程中一般有以下三種資料: - 啟動時需要的初始資料,可以是配置檔案 - 啟動過程中產生的臨時資料,該臨時資料需要多個容器間共享 - 啟動過程中產

21天轉型容器實戰營(十一容器進階Kubernetes 儲存管理原理分析

[[email protected] day11]# cat pvc.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: pvc-evs-auto-example namespace: default

kubernetes/k8s原始碼分析】kubectl-controller-managerjob原始碼分析

job介紹     Job: 批量一次性任務,並保證處理的一個或者多個Pod成功結束 非並行Job: 固定完成次數的並行Job: 帶有工作佇列的並行Job: SPEC引數 .spec.completions: 

kubernetes/k8s原始碼分析】kubectl-controller-managercronjob原始碼分析

crontab的基本格式     支援 , - * / 四個字元           *:表示匹配任意值,如果在Minutes 中使用表示每分鐘    &