Kubernetes中各元件簡介（一）
一、K8S的架構圖
1，Master(管理節點)
kubectl：是客戶端的管理工具。
API Server： 供Kubernetes API介面，主要處理Rest操作以及更新Etcd中的物件。所有資源增刪改查的唯一入口。
Scheduler： 繫結Pod到Node上，資源排程。
Etcd：所有持久化的狀態資訊儲存在Etcd中。
controller-manager：負責維護叢集狀態如故障檢測，自動更新處理叢集中常規後臺任務，一個資源對應一個控制器，而ControllerManager就是負責管理這些控制器的。
2，Node(計算節點)
Kubelet：是Master在Node節點上的Agent，管理Pods以及容器、映象、Volume等。
Kube-proxy：提供網路代理以及負載均衡，實現Service通訊。
二、Pod(資源池)
每個Pod都會存在一個Pause根容器，是每一個Pod都會去執行的，container即為應用程式，所以Pod就是根容器Pause和應用程式container所組成，在Pod當中可以執行多個小的容器的。
1，Pod組成的意義
- 使用Pause根容器可以防止由於將多個容器組成一個單元，當其中某個容器掛掉就會導致整個單元無法使用的情況發生。
- Pod可以執行過個container，這些container是共享Pause根容器的IP地址，也共享Pause的volume掛債卷，這樣既簡化了關聯業務容器之間的通訊問題，也很好的解決了容器之間共享的問題
- 在Kubernetes中的Pod之間是可以進行相互通訊的，因為他們之間是一個二層交換的網路，所以不同主機之間Pod是可以進行相互訪問的
2，Pod型別劃分
靜態Pod：不會將狀態存放到Etcd儲存資料庫中，而是放到了某個Node上的具體檔案當中，並且只有在這個Node上才能啟動執行
普通Pod：普通Pod一旦被建立成功，那麼Pod狀態資訊就會放到Etcd儲存資料庫當中，狀態就會實時進行更新，就會被Master節點繫結到某個Node節點上進行排程和資源分配，隨後Pod就放到了指定的Node上面，相當於把一個應用例項化成了一組相關Docker容器並啟動去執行
3，Pod、容器與Node之間的關係
- 在Node當中執行著Pod，而在Pod當中是包含著容器。
- 在K8s當中都是以Docker映象釋出的，每個Pod可以理解為上面執行著多個映象，在預設情況下，比如在Pod當中某個容器停止了，K8s會自動檢查這個問題並重啟這個Pod（即將Pod當中的所有容器全部重啟）
- 如果Pod所在的Node宕機了，K8s會把Pod排程到其他的Node節點上
- Pod當中是可以執行多個應用的，即支援多容器執行，每一個Pod相當於一個資源池，Pod當中的容器可以共享IP和檔案系統
三、其它資源物件
1，ReplicationController
通過定義RC來實現Pod的建立過程與自動控制，在RC當中包含著一個完整的Pod模板，通過Label標籤機制對Pod實現自動控制：通過改變RC裡面的Pod數量可以實現Pod的擴容和縮容；通過改變RC裡面模板的映象版本可以實現Pod的滾動升級功能。
2，Service
Kubernetes中一個應用服務會有一個或多個例項（Pod,Pod可以通過rs進行多複本的建立）,每個例項（Pod）的IP地址由網路外掛動態隨機分配（Pod重啟後IP地址會改變）。為遮蔽這些後端例項的動態變化和對多例項的負載均衡，引入了Service這個資源物件，如下所示:
apiVersion: v1 kind: Service metadata: name: nginx-svc labels: app: nginx spec: type: ClusterIP #clusterIP: None這種就是Headless Service ports: - port: 80 #svc埠 targetPort: 80 #目標後端埠 #nodePort: 30080 自定義nodePort埠 其中type要為NodePort型別 selector: #service通過selector和pod建立關聯 app: nginx
根據建立Service的type型別不同，可分為4中模式：
-
ClusterIp：預設型別，自動分配一個僅 Cluster 內部可以訪問的虛擬 IP。普通Service：通過為Kubernetes的Service分配一個叢集內部可訪問的
固定虛擬IP（Cluster IP）；Headless Service：DNS會將headless service的後端直接解析為podIP列表。 - NodePort：在 ClusterIP 基礎上為 Service 在每臺機器上繫結一個埠，這樣就可以通過 : NodePort 來訪問該服務。
- LoadBalancer：在 NodePort 的基礎上，藉助 cloud provider 建立一個外部負載均衡器，並將請求轉發到: NodePort 。
- ExternalName：把叢集外部的服務引入到叢集內部來，在叢集內部直接使用。沒有任何型別代理被建立，這隻有 kubernetes 1.7 或更高版本的 kube-dns 才支援
3，Deployment
Deployment是為了解決Pod編排的問題，在內部使用RS。部署表示使用者對K8s叢集的一次更新操作。可以是建立一個新的服務，更新一個新的服務，也可以是滾動升級一個服務。滾動升級一個服務，實際是建立一個新的RS，然後逐漸將新RS中副本數增加到理想狀態，將舊RS中的副本數減小到0的複合操作；這樣一個複合操作用一個RS是不太好描述的，所以用一個更通用的Deployment來描述。Deployment是RC最大的升級。
4，ReplicaSet
RS是新一代RC，提供同樣的高可用能力，區別主要在於RS後來居上，能支援更多種類的匹配模式，副本集物件一般不單獨使用，而是作為Deployment的理想狀態引數使用。
5，DaemonSet
確保全部（或者一些）Node 上執行一個 Pod 的副本。當有 Node 加入叢集時，也會為他們新增一個 Pod 。當有 Node 從叢集移除時，這些 Pod 也會被回收。刪除 DaemonSet 將會刪除它建立的所有 Pod。
使用 DaemonSet 的一些典型用法：執行叢集儲存 daemon，例如在每個 Node 上執行glusterd、ceph；日誌收集，比如fluentd，logstash等；系統監控，比如Prometheus Node Exporter，collectd，New Relic agent，Ganglia gmond等；系統程式，比如kube-proxy, kube-dns, glusterd, ceph等。
使用Fluentd收集日誌的例子：
apiVersion: extensions/v1beta1 kind: DaemonSet metadata: name: fluentd spec: template: metadata: labels: app: logging id: fluentd name: fluentd spec: containers: - name: fluentd-es image: gcr.io/google_containers/fluentd-elasticsearch:1.3 env: - name: FLUENTD_ARGS value: -qq volumeMounts: - name: containers mountPath: /var/lib/docker/containers - name: varlog mountPath: /varlog volumes: - hostPath: path: /var/lib/docker/containers name: containers - hostPath: path: /var/log name: varlog