Kubernetes中各組件簡介（一）

_{一、K8S的架構圖}

k8s的單主機集羣部署方案

k8s集羣的私有倉庫harbor

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，Replication Controller

　　通過定義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，Replica Set

　　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