k8s~術語解釋

文章參考:https://www.kubernetes.org.cnnode

簡介

Kubernetes是一個開源的,用於管理雲平臺中多個主機上的容器化的應用,Kubernetes的目標是讓部署容器化的應用簡單而且高效(powerful),Kubernetes提供了應用部署,規劃,更新,維護的一種機制。nginx

Kubernetes一個核心的特色就是可以自主的管理容器來保證雲平臺中的容器按照用戶的指望狀態運行着(好比用戶想讓apache一直運行,用戶不須要關心怎麼去作,Kubernetes會自動去監控,而後去重啓,新建,總之,讓apache一直提供服務),管理員能夠加載一個微型服務,讓規劃器來找到合適的位置,同時,Kubernetes也系統提高工具以及人性化方面,讓用戶可以方便的部署本身的應用(就像canary deployments)。docker

節點node

  • master > 負責調度
  • worker > 負責項目運行

Kubernetes節點有運行應用容器必備的服務,而這些都是受Master的控制。
每次個節點上固然都要運行Docker。Docker來負責全部具體的映像下載和容器運行。數據庫

Kubernetes主要由如下幾個核心組件組成:apache

  1. etcd保存了整個集羣的狀態;
  2. apiserver提供了資源操做的惟一入口,並提供認證、受權、訪問控制、API註冊和發現等機制;
  3. controller manager負責維護集羣的狀態,好比故障檢測、自動擴展、滾動更新等;
  4. scheduler負責資源的調度,按照預約的調度策略將Pod調度到相應的機器上;
  5. kubelet負責維護容器的生命週期,同時也負責Volume(CVI)和網絡(CNI)的管理;
  6. Container runtime負責鏡像管理以及Pod和容器的真正運行(CRI);
  7. kube-proxy負責爲Service提供cluster內部的服務發現和負載均衡;

除了核心組件,還有一些推薦的Add-ons:json

  1. kube-dns負責爲整個集羣提供DNS服務
  2. Ingress Controller爲服務提供外網入口
  3. Heapster提供資源監控
  4. Dashboard提供GUI
  5. Federation提供跨可用區的集羣
  6. Fluentd-elasticsearch提供集羣日誌採集、存儲與查詢

術語解釋

  • pods

在Kubernetes中,最小的管理元素不是一個個獨立的容器,而是Pod,Pod是最小的,管理,建立,計劃的最小單元.一個Pod(就像一羣鯨魚,或者一個豌豆夾)至關於一個共享context的配置組,在同一個context下,應用可能還會有獨立的cgroup隔離機制,一個Pod是一個容器環境下的「邏輯主機」,它可能包含一個或者多個緊密相連的應用,這些應用多是在同一個物理主機或虛擬機上。後端

  • 同一個Pod中的應用能夠共享磁盤
  • 因爲docker的架構,一個Pod是由多個相關的而且共享磁盤的容器組成
  • Labels

標籤其實就一對 key/value ,被關聯到對象上,好比Pod,標籤的使用咱們傾向於可以標示對象的特殊特色,而且對用戶而言是有意義的(就是一眼就看出了這個Pod是尼瑪數據庫),可是標籤對內核系統是沒有直接意義的。標籤能夠用來劃分特定組的對象(好比,全部女的),標籤能夠在建立一個對象的時候直接給與,也能夠在後期隨時修改,每個對象能夠擁有多個標籤,可是,key值必須是惟一的api

  • Namespace

Namespace是對一組資源和對象的抽象集合,好比能夠用來將系統內部的對象劃分爲不一樣的項目組或用戶組。常見的pods, services, replication controllers和deployments等都是屬於某一個namespace的(默認是default),而node, persistentVolumes等則不屬於任何namespace服務器

  • Replication Controller

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

Node是Pod真正運行的主機,能夠物理機,也能夠是虛擬機。爲了管理Pod,每一個Node節點上至少要運行container runtime(好比docker或者rkt)、kubelet和kube-proxy服務。

每一個Node都包括如下狀態信息

  1. 地址:包括hostname、外網IP和內網IP
  2. 條件(Condition):包括OutOfDisk、Ready、Me* moryPressure和DiskPressure
  3. 容量(Capacity):Node上的可用資源,包括CPU、內存和Pod總數
  4. 基本信息(Info):包括內核版本、容器引擎版本、OS類型等
  • ReplicaSets

ReplicaSet是下一代複本控制器。ReplicaSet和 Replication Controller之間的惟一區別是如今的選擇器支持。Replication Controller只支持基於等式的selector(env=dev或environment!=qa),但ReplicaSet還支持新的,基於集合的selector(version in (v1.0, v2.0)或env notin (dev, qa))。在試用時官方推薦ReplicaSet。

  • Services

Kubernetes Pod是平凡的,它門會被建立,也會死掉(生老病死),而且他們是不可復活的。 ReplicationControllers動態的建立和銷燬Pods(好比規模擴大或者縮小,或者執行動態更新)。每一個pod都由本身的ip,這些IP也隨着時間的變化也不能持續依賴。這樣就引起了一個問題:若是一些Pods(讓咱們叫它做後臺,後端)提供了一些功能供其它的Pod使用(讓咱們叫做前臺),在kubernete集羣中是如何實現讓這些前臺可以持續的追蹤到這些後臺的?答案是:Service

Kubernete Service 是一個定義了一組Pod的策略的抽象,咱們也有時候叫作宏觀服務。這些被服務標記的Pod都是(通常)經過label Selector決定的(下面咱們會講到咱們爲何須要一個沒有label selector的服務)

  • Volumes

容器中的磁盤的生命週期是短暫的,這就帶來了一系列的問題,第一,當一個容器損壞以後,kubelet 會重啓這個容器,可是文件會丟失-這個容器會是一個全新的狀態,第二,當不少容器在同一Pod中運行的時候,不少時候須要數據文件的共享。Kubernete Volume解決了這個問題.
一個Kubernetes volume,擁有明確的生命週期,與所在的Pod的生命週期相同。所以,Kubernetes volume獨立與任何容器,與Pod相關,因此數據在重啓的過程當中還會保留,固然,若是這個Pod被刪除了,那麼這些數據也會被刪除。更重要的是,Kubernetes volume 支持多種類型,任何容器均可以使用多個Kubernetes volume。

  • Deployment

Deployment爲Pod和ReplicaSet提供了一個聲明式定義(declarative)方法,用來替代之前的ReplicationController來方便的管理應用。典型的應用場景包括:

  1. 定義Deployment來建立Pod和ReplicaSet
    2.滾動升級和回滾應用
  2. 擴容和縮容
  3. 暫停和繼續Deployment
    好比一個簡單的nginx應用能夠定義爲
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

Secret解決了密碼、token、密鑰等敏感數據的配置問題,而不須要把這些敏感數據暴露到鏡像或者Pod Spec中。Secret能夠以Volume或者環境變量的方式使用。
Secret有三種類型:

  1. Service Account:用來訪問Kubernetes API,由Kubernetes自動建立,而且會自動掛載到Pod的/run/secrets/kubernetes.io/serviceaccount目錄中;
  2. Opaque:base64編碼格式的Secret,用來存儲密碼、密鑰等;
  3. kubernetes.io/dockerconfigjson:用來存儲私有docker registry的認證信息。
  • Ingress

在本篇文章中你將會看到一些在其餘地方被交叉使用的術語,爲了防止產生歧義,咱們首先來澄清下。

  1. 節點:Kubernetes集羣中的服務器;
  2. 集羣:Kubernetes管理的一組服務器集合;
  3. 邊界路由器:爲局域網和Internet路由數據包的路由器,執行防火牆保護局域網絡;
  4. 集羣網絡:遵循Kubernetes網絡模型實現羣集內的通訊的具體實現,好比flannel 和 OVS。
  5. 服務:使用標籤選擇器標識一組pod成爲的Kubernetes Service。 除非另有說明,不然服務的虛擬IP僅可在集羣內部訪問。

什麼是Ingress?
一般狀況下,service和pod的IP僅可在集羣內部訪問。集羣外部的請求須要經過負載均衡轉發到service在Node上暴露的NodePort上,而後再由kube-proxy將其轉發給相關的Pod。

Ingress能夠給service提供集羣外部訪問的URL、負載均衡、SSL終止、HTTP路由等。爲了配置這些Ingress規則,集羣管理員須要部署一個Ingress controller,它監聽Ingress和service的變化,並根據規則配置負載均衡並提供訪問入口。

  • ConfigMap

ConfigMap用於保存配置數據的鍵值對,能夠用來保存單個屬性,也能夠用來保存配置文件。ConfigMap跟secret很相似,但它能夠更方便地處理不包含敏感信息的字符串。

相關文章
相關標籤/搜索