Kubernetes(k8s)容器運行時(CRI)

標籤：unp   data   健康   class   刪除   服務   remove   protoc   開發   

Kubernetes節點的底層由一個叫做“容器運行時”的軟體進行支撐，它負責比如啟停容器這樣的事情。最廣為人知的容器運行時當屬Docker，但它不是唯一的。事實上，容器運行時這個領域發展迅速。為了使Kubernetes的擴充變得更容易，我們一直在打磨支援容器運行時的K8s外掛程式API：容器運行時介面(Container Runtime Interface, CRI)。

CRI是什嗎？

每種容器運行時各有所長，許多使用者都希望Kubernetes支援更多的運行時。在Kubernetes 1.5發布版裡，我們引入了CRI–一個能讓kubelet無需編譯就可以支援多種容器運行時的外掛程式介面。CRI包含了一組protocol buffers，gRPC API，相關的庫，以及在活躍開發下的額外規範和工具。CRI目前是Alpha版本。

支援可替換的容器運行時在Kubernetes中概念中並非首次。在1.3發布版裡，我們介紹了rktnetes項目，它可以讓rkt容器引擎作為Docker容器運行時的一個備選。然而，不管是Docker還是Rkt都需要通過內部、不太穩定的介面直接整合到kubelet的源碼中。這樣的整合過程要求十分熟悉kubelet內部原理，並且還會在Kubernetes社區引發巨大的維護反響。這些因素都在為容器運行時的初期造成了巨大的困難。我們通過提供一個清晰定義的抽象層消除了這些障礙，開發人員可以專註於構建他們的容器運行時。這是很小的一步，但對於真正提供可插拔的容器運行時和構建一個更健康的生態系統卻意義非凡。

CRI總覽

Kubelet與容器運行時通訊（或者是CRI外掛程式填充了容器運行時）時，Kubelet就像是用戶端，而CRI外掛程式就像對應的伺服器。它們之間可以通過Unix 通訊端或者gRPC架構進行通訊。

 

 

protocol buffers API包含了兩個gRPC服務：ImageService和RuntimeService。ImageService提供了從鏡像倉庫拉取、查看、和移除鏡像的RPC。RuntimeSerivce包含了Pods和容器生命週期管理的RPC，以及跟容器互動的調用(exec/attach/port-forward)。一個單塊的容器運行時能夠管理鏡像和容器（例如：Docker和Rkt），並且通過同一個通訊端同時提供這兩種服務。這個通訊端可以在Kubelet裡通過標識–container-runtime-endpoint和–image-service-endpoint進行設定。

生命週期管理

對於Pod和容器的生命週期管理，CRI提供了下面的機制：

service RuntimeService {
// Sandbox operations.
rpc RunPodSandbox(RunPodSandboxRequest) returns (RunPodSandboxResponse) {}
rpc StopPodSandbox(StopPodSandboxRequest) returns (StopPodSandboxResponse) {}
rpc RemovePodSandbox(RemovePodSandboxRequest) returns (RemovePodSandboxResponse) {}
rpc PodSandboxStatus(PodSandboxStatusRequest) returns (PodSandboxStatusResponse) {}
rpc ListPodSandbox(ListPodSandboxRequest) returns (ListPodSandboxResponse) {}
// Container operations.
rpc CreateContainer(CreateContainerRequest) returns (CreateContainerResponse) {}
rpc StartContainer(StartContainerRequest) returns (StartContainerResponse) {}
rpc StopContainer(StopContainerRequest) returns (StopContainerResponse) {}
rpc RemoveContainer(RemoveContainerRequest) returns (RemoveContainerResponse) {}
rpc ListContainers(ListContainersRequest) returns (ListContainersResponse) {}
rpc ContainerStatus(ContainerStatusRequest) returns (ContainerStatusResponse) {}
…
}

在資源受限的隔離環境裡的一組應用程式容器組成一個Pod。在CRI，這個環境被稱為PodSandbox。我們故意留下一些空間，讓容器運行時根據它們內部不同的原理來產生不同的PodSandbox。對於基於hypervisor的運行時，PodSandbox可能代表的是虛擬機器。對於其他的，比如Docker，它可能是Linux命名空間。這個PodSandbox一定遵循著Pod的資源定義。在v1alpha1版API裡，kubelet將建立pod級的cgroup限制下的一組進程，並傳遞給容器運行時，由此實現。

在Pod啟動前，kubelet調用RuntimeService.RunPodSandbox來建立環境，包括為Pod設定網路（例如：分配IP）等。當PodSandbox啟動後，就可以分別建立/啟動/停止/移除獨立的容器。為了刪除Pod，kubelet會在停止和移除所有容器前先停止和移除PodSandbox。

Kubelet負責通過RPC來進行容器生命週期的管理，測試容器生命週期鉤子和健康/可讀性檢查，同時為Pod提供重啟策略。

容器為中心的介面

Kubernetes擁有對Pod資源的聲明式API。我們認為一個可能的設計是為了使CRI能夠在它的抽象裡重用這個聲明式的Pod對象，給容器運行時實現和測試達到期望狀態的邏輯的自由。這會極大地簡化API，並讓CRI可以相容更廣泛的運行時。在早期的設計階段我們討論過這個方法，但由於幾個原因否決了它。首先，Kubelet有許多Pod級的特性和特定的技術（比如crash-loop backoff邏輯），這會成為所有運行時重新實現時的巨大負擔。其次，越來越重要的是，Pod的定義更新快速。只要kubelet直接管理容器，那麼許多新特性（比如init container）不需要底層容器運行時做任何改變。CRI包含了一個必要的容器級介面，這樣運行時就可以共用這些特性，擁有更快的開發速度。當然這並不意味著我們偏離了”level triggered”哲學。kubelet負責保證實際狀態到期望狀態的變化。

互動請求

service RuntimeService {
…
// ExecSync runs a command in a container synchronously.
rpc ExecSync(ExecSyncRequest) returns (ExecSyncResponse) {} // Exec prepares a streaming endpoint to execute a command in the container.
rpc Exec(ExecRequest) returns (ExecResponse) {} // Attach prepares a streaming endpoint to attach to a running container.
rpc Attach(AttachRequest) returns (AttachResponse) {} // PortForward prepares a streaming endpoint to forward ports from a PodSandbox.
rpc PortForward(PortForwardRequest) returns (PortForwardResponse) {}
…
}

Kubernetes提供了一些使用者可以與Pod及其內部容器進行互動的特性（例如kubectl exec/attach/port-forward）。Kubelet現在通過調用容器原生的方法或使用節點上可用的工具（例如nsenter和socat）來支援這些特性。在節點上使用這些工具不是一個可移植的好辦法，因為這些工具的大部分假定Pod是通過Linux命名空間進行隔離的。在CRI，我們顯式定義了這些調用，允許特定的運行時實現。

另外一個潛在的問題是，kubelet如今的實現是kubelet處理所有的流式串連請求。所以這會給節點的網路流量帶來瓶頸。在設計CRI的時候，我們採納了這個反饋，支援運行時防範中間人。容器運行時可以啟動一個對應請求的單獨的流伺服器（甚至可能為Pod審計資源使用），並且將地址返回給Kubelet。Kubelet然後將這個資訊再返回給Kubernetes API Server，它會開啟直接與運行時提供的伺服器相連的流串連，並將它跟用戶端連通。

Kubernetes(k8s)容器運行時(CRI)