Kubernetes系列——Kubernetes 組件、對象（二）

1、Kubernetes 組件

介紹了Kubernetes集羣所需的各類二進制組件。

Master 組件

Master組件提供集羣的管理控制中心。

Master組件能夠在集羣中任何節點上運行。可是爲了簡單起見，一般在一臺VM/機器上啓動全部Master組件，而且不會在此VM/機器上運行用戶容器。請參考 構建高可用羣集以來構建multi-master-VM。

kube-apiserver

kube-apiserver用於暴露Kubernetes API。任何的資源請求/調用操做都是經過kube-apiserver提供的接口進行。請參閱構建高可用羣集。

ETCD

etcd是Kubernetes提供默認的存儲系統，保存全部集羣數據，使用時須要爲etcd數據提供備份計劃。

kube-controller-manager

kube-controller-manager運行管理控制器，它們是集羣中處理常規任務的後臺線程。

邏輯上，每一個控制器是一個單獨的進程，但爲了下降複雜性，它們都被編譯成單個二進制文件，並在單個進程中運行。

這些控制器包括：

一、節點（Node）控制器。

二、副本（Replication）控制器：負責維護系統中每一個副本中的pod。

三、端點（Endpoints）控制器：填充Endpoints對象（即鏈接Services＆Pods）。

四、Service Account和Token控制器：爲新的Namespace 建立默認賬戶訪問API Token。

cloud-controller-manager

雲控制器管理器負責與底層雲提供商的平臺交互。雲控制器管理器是Kubernetes版本1.6中引入的，目前仍是Alpha的功能。

雲控制器管理器僅運行雲提供商特定的（controller loops）控制器循環。能夠經過將 flag設置爲external啓動kube-controller-manager ，來禁用控制器循環。

cloud-controller-manager 具體功能：--cloud-provider

    節點（Node）控制器

    路由（Route）控制器

    Service控制器

    卷（Volume）控制器

kube-scheduler

kube-scheduler 監視新建立沒有分配到Node的Pod，爲Pod選擇一個Node。

插件 addons

插件（addon）是實現集羣pod和Services功能的 。Pod由Deployments，ReplicationController等進行管理。Namespace 插件對象是在kube-system Namespace中建立。

DNS

雖然不嚴格要求使用插件，但Kubernetes集羣都應該具備集羣 DNS。

羣集 DNS是一個DNS服務器，可以爲 Kubernetes services提供 DNS記錄。

由Kubernetes啓動的容器自動將這個DNS服務器包含在他們的DNS searches中。

瞭解更多詳情

用戶界面

kube-ui提供集羣狀態基礎信息查看。更多詳細信息，請參閱使用HTTP代理訪問Kubernetes API

容器資源監測

容器資源監控提供一個UI瀏覽監控數據。

Cluster-level Logging

Cluster-level logging，負責保存容器日誌，搜索/查看日誌。

節點（Node）組件

節點組件運行在Node，提供Kubernetes運行時環境，以及維護Pod。

kubelet

kubelet是主要的節點代理，它會監視已分配給節點的pod，
具體功能：

    安裝Pod所需的volume。

    下載Pod的Secrets。

    Pod中運行的 docker（或experimentally，rkt）容器。

    按期執行容器健康檢查。

    Reports the status of the pod back to the rest of the system, by creating a mirror pod if necessary.

    Reports the status of the node back to the rest of the system.

kube-proxy

kube-proxy經過在主機上維護網絡規則並執行鏈接轉發來實現Kubernetes服務抽象。

docker

docker用於運行容器。

RKT

rkt運行容器，做爲docker工具的替代方案。

supervisord

supervisord是一個輕量級的監控系統，用於保障kubelet和docker運行。

fluentd

fluentd是一個守護進程，可提供cluster-level logging.。

 

2、Kubernetes對象

瞭解Kubernetes對象

Kubernetes對象是Kubernetes系統中的持久實體。Kubernetes使用這些實體來表示集羣的狀態。
具體來講，他們能夠描述：

    容器化應用正在運行(以及在哪些節點上)

    這些應用可用的資源

    關於這些應用如何運行的策略，如從新策略，升級和容錯

Kubernetes對象是「record of intent」，一旦建立了對象，Kubernetes系統會確保對象存在。經過建立對象，能夠有效地告訴Kubernetes系統你但願集羣的工做負載是什麼樣的。

要使用Kubernetes對象（不管是建立，修改仍是刪除），都須要使用Kubernetes API。例如，當使用kubectl命令管理工具時，CLI會爲提供Kubernetes API調用。你也能夠直接在本身的程序中使用Kubernetes API，Kubernetes提供一個golang客戶端庫 （其餘語言庫正在開發中-如Python）。

對象（Object）規範和狀態

每一個Kubernetes對象都包含兩個嵌套對象字段，用於管理Object的配置：Object Spec和Object Status。Spec描述了對象所需的狀態 - 但願Object具備的特性，Status描述了對象的實際狀態，並由Kubernetes系統提供和更新。

例如，經過Kubernetes Deployment 來表示在集羣上運行的應用的對象。建立Deployment時，能夠設置Deployment Spec，來指定要運行應用的三個副本。Kubernetes系統將讀取Deployment Spec，並啓動你想要的三個應用實例 - 來更新狀態以符合以前設置的Spec。
若是這些實例中有任何一個失敗（狀態更改），Kuberentes系統將響應Spec和當前狀態之間差別來調整，這種狀況下，將會開始替代實例。

有關object spec、status和metadata更多信息，請參考「Kubernetes API Conventions」。

描述Kubernetes對象

在Kubernetes中建立對象時，必須提供描述其所需Status的對象Spec，以及關於對象（如name）的一些基本信息。
當使用Kubernetes API建立對象（直接或經過kubectl）時，該API請求必須將該信息做爲JSON包含在請求body中。
一般，能夠將信息提供給kubectl .yaml文件，在進行API請求時，kubectl將信息轉換爲JSON。

如下示例是一個.yaml文件，顯示Kubernetes Deployment所需的字段和對象Spec：

nginx-deployment.yaml
apiVersion: apps/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

使用上述.yaml文件建立Deployment，是經過在kubectl中使用kubectl create命令來實現。將該.yaml文件做爲參數傳遞。以下例子：

$ kubectl create -f docs/user-guide/nginx-deployment.yaml --record

其輸出與此相似:

deployment "nginx-deployment" created

必填字段

對於要建立的Kubernetes對象的yaml文件，須要爲如下字段設置值：

    apiVersion - 建立對象的Kubernetes API 版本

    kind - 要建立什麼樣的對象？

    metadata- 具備惟一標示對象的數據，包括 name（字符串）、UID和Namespace（可選項）

還須要提供對象Spec字段，對象Spec的精確格式（對於每一個Kubernetes 對象都是不一樣的），以及容器內嵌套的特定於該對象的字段。Kubernetes API reference能夠查找全部可建立Kubernetes對象的Spec格式。

下一步？

• 瞭解最重要的Kubernetes對象，如Pod