文章參考:https://www.kubernetes.org.cnnode
Kubernetes是一個開源的,用於管理雲平臺中多個主機上的容器化的應用,Kubernetes的目標是讓部署容器化的應用簡單而且高效(powerful),Kubernetes提供了應用部署,規劃,更新,維護的一種機制。nginx
Kubernetes一個核心的特色就是可以自主的管理容器來保證雲平臺中的容器按照用戶的指望狀態運行着(好比用戶想讓apache一直運行,用戶不須要關心怎麼去作,Kubernetes會自動去監控,而後去重啓,新建,總之,讓apache一直提供服務),管理員能夠加載一個微型服務,讓規劃器來找到合適的位置,同時,Kubernetes也系統提高工具以及人性化方面,讓用戶可以方便的部署本身的應用(就像canary deployments)。docker
Kubernetes節點有運行應用容器必備的服務,而這些都是受Master的控制。
每次個節點上固然都要運行Docker。Docker來負責全部具體的映像下載和容器運行。數據庫
Kubernetes主要由如下幾個核心組件組成:apache
除了核心組件,還有一些推薦的Add-ons:json
在Kubernetes中,最小的管理元素不是一個個獨立的容器,而是Pod,Pod是最小的,管理,建立,計劃的最小單元.一個Pod(就像一羣鯨魚,或者一個豌豆夾)至關於一個共享context的配置組,在同一個context下,應用可能還會有獨立的cgroup隔離機制,一個Pod是一個容器環境下的「邏輯主機」,它可能包含一個或者多個緊密相連的應用,這些應用多是在同一個物理主機或虛擬機上。後端
- 同一個Pod中的應用能夠共享磁盤
- 因爲docker的架構,一個Pod是由多個相關的而且共享磁盤的容器組成
標籤其實就一對 key/value ,被關聯到對象上,好比Pod,標籤的使用咱們傾向於可以標示對象的特殊特色,而且對用戶而言是有意義的(就是一眼就看出了這個Pod是尼瑪數據庫),可是標籤對內核系統是沒有直接意義的。標籤能夠用來劃分特定組的對象(好比,全部女的),標籤能夠在建立一個對象的時候直接給與,也能夠在後期隨時修改,每個對象能夠擁有多個標籤,可是,key值必須是惟一的api
Namespace是對一組資源和對象的抽象集合,好比能夠用來將系統內部的對象劃分爲不一樣的項目組或用戶組。常見的pods, services, replication controllers和deployments等都是屬於某一個namespace的(默認是default),而node, persistentVolumes等則不屬於任何namespace服務器
Replication Controller 保證了在全部時間內,都有特定數量的Pod副本正在運行,若是太多了,Replication Controller就殺死幾個,若是太少了,Replication Controller會新建幾個,和直接建立的pod不一樣的是,Replication Controller會替換掉那些刪除的或者被終止的pod,無論刪除的緣由是什麼(維護阿,更新啊,Replication Controller都不關心)。基於這個理由,咱們建議即便是隻建立一個pod,咱們也要使用Replication Controller。Replication Controller 就像一個進程管理器,監管着不一樣node上的多個pod,而不是單單監控一個node上的pod,Replication Controller 會委派本地容器來啓動一些節點上服務(Kubelet ,Docker)。網絡
Node是Pod真正運行的主機,能夠物理機,也能夠是虛擬機。爲了管理Pod,每一個Node節點上至少要運行container runtime(好比docker或者rkt)、kubelet和kube-proxy服務。
每一個Node都包括如下狀態信息
ReplicaSet是下一代複本控制器。ReplicaSet和 Replication Controller之間的惟一區別是如今的選擇器支持。Replication Controller只支持基於等式的selector(env=dev或environment!=qa),但ReplicaSet還支持新的,基於集合的selector(version in (v1.0, v2.0)或env notin (dev, qa))。在試用時官方推薦ReplicaSet。
Kubernetes Pod是平凡的,它門會被建立,也會死掉(生老病死),而且他們是不可復活的。 ReplicationControllers動態的建立和銷燬Pods(好比規模擴大或者縮小,或者執行動態更新)。每一個pod都由本身的ip,這些IP也隨着時間的變化也不能持續依賴。這樣就引起了一個問題:若是一些Pods(讓咱們叫它做後臺,後端)提供了一些功能供其它的Pod使用(讓咱們叫做前臺),在kubernete集羣中是如何實現讓這些前臺可以持續的追蹤到這些後臺的?答案是:Service
Kubernete Service 是一個定義了一組Pod的策略的抽象,咱們也有時候叫作宏觀服務。這些被服務標記的Pod都是(通常)經過label Selector決定的(下面咱們會講到咱們爲何須要一個沒有label selector的服務)
容器中的磁盤的生命週期是短暫的,這就帶來了一系列的問題,第一,當一個容器損壞以後,kubelet 會重啓這個容器,可是文件會丟失-這個容器會是一個全新的狀態,第二,當不少容器在同一Pod中運行的時候,不少時候須要數據文件的共享。Kubernete Volume解決了這個問題.
一個Kubernetes volume,擁有明確的生命週期,與所在的Pod的生命週期相同。所以,Kubernetes volume獨立與任何容器,與Pod相關,因此數據在重啓的過程當中還會保留,固然,若是這個Pod被刪除了,那麼這些數據也會被刪除。更重要的是,Kubernetes volume 支持多種類型,任何容器均可以使用多個Kubernetes volume。
Deployment爲Pod和ReplicaSet提供了一個聲明式定義(declarative)方法,用來替代之前的ReplicationController來方便的管理應用。典型的應用場景包括:
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80
Secret解決了密碼、token、密鑰等敏感數據的配置問題,而不須要把這些敏感數據暴露到鏡像或者Pod Spec中。Secret能夠以Volume或者環境變量的方式使用。
Secret有三種類型:
在本篇文章中你將會看到一些在其餘地方被交叉使用的術語,爲了防止產生歧義,咱們首先來澄清下。
什麼是Ingress?
一般狀況下,service和pod的IP僅可在集羣內部訪問。集羣外部的請求須要經過負載均衡轉發到service在Node上暴露的NodePort上,而後再由kube-proxy將其轉發給相關的Pod。
Ingress能夠給service提供集羣外部訪問的URL、負載均衡、SSL終止、HTTP路由等。爲了配置這些Ingress規則,集羣管理員須要部署一個Ingress controller,它監聽Ingress和service的變化,並根據規則配置負載均衡並提供訪問入口。
ConfigMap用於保存配置數據的鍵值對,能夠用來保存單個屬性,也能夠用來保存配置文件。ConfigMap跟secret很相似,但它能夠更方便地處理不包含敏感信息的字符串。