Kubernetes是Google開(kāi)源的Docker容器集群編排管理系統，為容器化的應用提供自動(dòng)部署，彈性伸縮，資源調度，負載均衡和服務(wù)發(fā)現等應用云平臺所需的管理功能體系。Kubernetes 的靈感源于谷歌過(guò)去15年在生產(chǎn)環(huán)境中運行容器的管理經(jīng)驗，集合了社區中先進(jìn)的理念和實(shí)戰技術(shù)。

　　Kubernetes對計算資源進(jìn)行了更高層次的抽象，通過(guò)將容器進(jìn)行細致的組合，將最終的應用服務(wù)交給用戶(hù)。Kubernetes在模型建立之初就考慮了容器跨機連接的要求，支持多種網(wǎng)絡(luò )解決方案，同時(shí)在Service層次構建集群范圍的SDN網(wǎng)絡(luò )。其目的是將服務(wù)發(fā)現和負載均衡放置到容器可達的范圍，這種透明的方式便利了各個(gè)服務(wù)間的通信，并為微服務(wù)架構的實(shí)踐提供了平臺基礎。而在Pod層次上，作為Kubernetes可操作的最小對象，其特征更是對微服務(wù)架構的原生支持。

　　架構及部署

　　Architecture

　　Kubernetes是2014年6月開(kāi)源的，采用Golang的語(yǔ)言開(kāi)發(fā)，每一個(gè)組件互相之間使用的是Master API的方式，Kubernetes的架構模式是用Master-slave模式，并且支持多種聯(lián)機網(wǎng)絡(luò )，支持多種分布式存儲架構。

　　Master的核心組件是API server，對外提供REST API服務(wù)接口。kubernetes所有的信息都存儲在分布式系統ETCD中. Scheduler是kubernetes的調度器，用于調度集群的主機資源。Controller用于管理節點(diǎn)注冊以及容器的副本個(gè)數等控制功能。

　　在Node上的核心組件是kubelet，它是任務(wù)執行者，會(huì )跟apiserver進(jìn)行交互，獲取資源調度信息。 kubelet會(huì )根據資源和任務(wù)的信息和調度狀態(tài)與Docker去交互，調用Docker的API, 創(chuàng )建、刪除與管理容器，而kube-Proxy可以根據從API里獲取的信息以及整體的Pod架構狀態(tài)組成虛擬NAT網(wǎng)絡(luò )。

　　快速部署過(guò)程

　　在最新更新的kubernetes 1.4版本中，社區開(kāi)發(fā)了專(zhuān)用的部署組件kubeadm, 用來(lái)完成kubernetes集群整體的部署過(guò)程。Kubeadm是對以往手動(dòng)或腳本部署的簡(jiǎn)化，集成了manifest配置、參數設置、認證設置、集群網(wǎng)絡(luò )部署以及安全證書(shū)的獲取。需要注意的是kubeadm目前默認從gcr.io的鏡像中心獲取鏡像，若需使用其他鏡像源，需要更改源碼編譯出定制版本。

　　Ubuntu 16.04環(huán)境的使用過(guò)程如下： ?設定部署主機資源

　　1)在所有節點(diǎn)上(包括master和node)部署基礎運行環(huán)境

部署內容包括docker, kubelet, kubeadm, kubectl kubernetes-cni ?運行如下命令：
# curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
# cat < /etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial main
EOF
# apt-get update
# apt-get install -y docker.io kubelet kubeadm kubectl kubernetes-cni

　　2)部署Master

　　在Master上運行 kubeadm init, 運行結束后，可獲得集群的token,以及提示在node上運行的命令：

　　3)添加節點(diǎn)

　　在master上的kubeadm init的輸出中獲取相應的參數并在Node上運行：

　　4)部署網(wǎng)絡(luò )

　　kubernete集群需要可以跨主機的網(wǎng)絡(luò )解決方案，使得位于不同主機的pod可以相互通信。目前有多種類(lèi)似的解決方案，例如weave network, calico 或者 Canal。當前使用的是weave net

　　關(guān)于網(wǎng)絡(luò )，對于隔離要求較高的場(chǎng)景需求，采用calico是比較合適的選擇。calico會(huì )幫助容器在主機間搭建純二層的網(wǎng)絡(luò )，在每個(gè)主機上維護一個(gè)路由表，用來(lái)獲取目標容器所在主機的可達路徑，以及本機容器的路有項。利用iptables的防火墻機制去做隔離。容器之間跨主機進(jìn)行交互時(shí)，IP包從容器出發(fā)，經(jīng)過(guò)本地路有表選路，通過(guò)目標網(wǎng)段所在主機的路有項，到達目標主機，然后在目標主機內，進(jìn)入路有選路前，先經(jīng)由iptables隔離規則（可設置）進(jìn)行判斷決定是否丟棄或返回，然后再經(jīng)路有選路到目標容器，最終到達目標容器。整個(gè)過(guò)程沒(méi)有任何封包解包的過(guò)程，傳輸效率較高。

　　隔離規則可以設定在同一用戶(hù)名下的哪些容器可以被隔離成一組，被隔離的容器間可通信，而與其它容器不可通信?；蛘咴O置規則來(lái)組成更加豐富的隔離效果。

　　部署組件詳解

　　在kubernetes 1.4版本利用kubeadm部署過(guò)程中，安裝的插件包括kube-discovery，kube-proxy和kube-dns,分別負責部署階段配置的分發(fā), NAT網(wǎng)絡(luò )和集群系統的dns服務(wù)。值得注意的是kube-proxy不再通過(guò)manifest來(lái)運行，是通過(guò)插件用demonset的方式來(lái)部署。

　　1)kubeadm

　　在kubeadm init運行階段，首先創(chuàng )建驗證token以及靜態(tài)pod文件（manifest的文件），以及運行所需的證書(shū)和kubeconfig。完成這些工作后，kubeadm會(huì )等待apiserver的啟動(dòng)并正常運行，以及等待首個(gè)節點(diǎn)的接入。

　　由于master節點(diǎn)啟動(dòng)kubelet來(lái)運行manifest文件，并且在kubelet.conf中設置了需要連接當前主機為master，因此此master 也會(huì )作為node節點(diǎn)接入，并且master作為節點(diǎn)運行也為kube-discovery提供運行的必須環(huán)境。

　　當節點(diǎn)加入并且apiserver運行正常后，將標示master的角色，kubeadm.alpha.kubernetes.io/role=master。

　　2)Kube-discovery

　　隨后在部署運行kube-discovery時(shí)，在kube-discovery所運行的pod上設置node的親和性，并將它限制成為必須在master上運行的pod。由于kube-discovery的主要功能是證書(shū)及token等配置的管理與分發(fā)，并且后續的節點(diǎn)加入時(shí)只需要一個(gè)簡(jiǎn)單的master ip信息，因此將kube-discovery限制到了master節點(diǎn)運行，以此統一服務(wù)的入口。 ?這些通過(guò)在pod的annotations來(lái)實(shí)現 ?requiredDuringSchedulingIgnoredDuringExecution表示在調度過(guò)程中需要滿(mǎn)足的條件，和后面的nodeSelectorTerms在一起類(lèi)似于nodeselector。這樣設置即可將pod限制到master主機中。

　　3)Kube-dns

　　從kubernetes 1.3開(kāi)始，kube-dns已經(jīng)不再使用etcd+skydns+kube2sky的方式。而是使用了dns緩存及轉發(fā)工具dnsmasq，以及利用skydns庫和本地內存緩存組合而成的kube-dns。

　　Kube-dns將從kubernetes master中監聽(tīng)變動(dòng)的service和endpoint信息，并建立從service ip 到service name的域名映射(對于無(wú)service的，將會(huì )建立pod ip和相應域名的映射)。Kube-dns將這些信息存放在本地的內存緩沖中，并監聽(tīng)127.0.0.1:10053提供服務(wù)。

　　Dnsmasq是簡(jiǎn)單的域名服務(wù)、緩存和轉發(fā)工具，這里利用它的轉發(fā)功能將kube-dns的dns服務(wù)轉接到外部，參數–server=127.0.0.1:10053。

　　二.運維管理

　　租戶(hù)資源管理Namespace(命名空間)

　　namespace 是kubernete用來(lái)做租戶(hù)管理的對象。每個(gè)租戶(hù)獨享自己的邏輯空間，包括replication controller、 pod、 service、 deployment、configmap等。 ?常用的查看方式：

　　kubectl get --namespace=

　　或查看所有namespace的某類(lèi)資源

　　kubectl get --all-namespaces

　　例如：查看所有的pod，并希望看到所部署的節點(diǎn)位置

　　kubectl get pod –all-namespaces –o wide

　　查看namespace為 test的replication controller，以及l(fā)abet

　　kubectl get rc –namespace=test –show-labels

　　配置管理ConfigMap

　　當服務(wù)運行在容器中時(shí)，需要訪(fǎng)問(wèn)外部的變量，或者需要根據環(huán)境的不同更改配置文件，比如，DB以傳統的方式運行在容器云之外，當服務(wù)啟動(dòng)時(shí)，需要初始化包含DB信息的配置文件。當需要切換db時(shí)，就需要更改配置文件， 當容器中有服務(wù)在運行時(shí)， 并不推薦登陸到容器內進(jìn)行文件配置更改。

　　合理的方式是利用kubernetes的配置管理，將配置信息寫(xiě)入到ConfigMap, 并掛載到對應的pod中。 

　　例如golang程序golang-sample需要訪(fǎng)問(wèn)配置文件db.json,內容如下：

    {
        "dbType": "mysql",
        "host": "192.168.1.22",
        "user": "tenxcloud",
        "password": "password",
        "port": "3306",
        "connectionLimit": 200,
        "connectTimeout": 20000,
        "database": "sample"
    }
將db.json寫(xiě)入config.yaml中：
apiVersion: v1
data:
  db.json: |-
    {
        "dbType": "mysql",
        "host": "192.168.1.22",
        "user": "tenxcloud",
        "password": "password",
        "port": "3306",
        "connectionLimit": 200,
        "connectTimeout": 20000,
        "database": "sample"
    }
kind: ConfigMap
metadata:
  name: config-sample
  namespace: sample
創(chuàng )建configmap對象：
kubectl create –f config.yaml
在 pod中添加對應的volume
apiVersion: v1
kind: Pod
metadata:
  labels:
    name: golang-sample
  name: golang-sample
  namespace: sample
spec:
  containers:
  - image: inde.tenxcloud.com/sample/golang-sample:latest
    volumeMounts:
    - mountPath: /usr/src/app/config/db/
      name: configmap-1
  volumes:
  - configMap:
      items:
      - key: db.json
        path: db.json
      name: config-sample
    name: configmap-1

　　當pod創(chuàng )建運行后，服務(wù)在pod容器內只需要讀取固定位置的配置文件， 當配置需要改變時(shí)， 更新ConfigMap并重新分發(fā)到pod內，這樣重啟容器后，容器內所掛載的配置也會(huì )相應更新。當需要pod容器同時(shí)使用一個(gè)ConfigMap 時(shí)，更新ConfigMap內容的同時(shí)，可以批量更新容器的配置。

　　主機運維管理

　　對于運維操作來(lái)說(shuō)，kubectl是一個(gè)很便利的命令行工具，首先可以對各種資源進(jìn)行操作，比如添加、獲取、刪除，通過(guò)更多命令參數得到指定的信息。

　　獲取資源列表及詳細信息的方式可通過(guò)kubectl get 來(lái)進(jìn)行，具體的操作運行kubectl get –help即可。

　　實(shí)踐使用過(guò)程中，對節點(diǎn)的運維操作會(huì )影響到應用的使用和資源的調度，比如由于配置升級需要對節點(diǎn)主機進(jìn)行重啟，需要考慮已經(jīng)運行在其上的容器的狀況，用戶(hù)的希望是對資源池的操作盡量少的影響容器應用，同時(shí)資源池的變動(dòng)和上層的容器服務(wù)解藕。

　　當需要對主機進(jìn)行維護升級時(shí)，首先將節點(diǎn)主機設置成不可調度模式：

　　kubectl cordon［nodeid］
　　然后需要將主機上正在運行的容器驅趕到其它可用節點(diǎn)：
　　kubectl drain ［nodeid］
　　當容器遷移完畢后，運維人員可以對該主機進(jìn)行操作，配置升級性能參數調優(yōu)等等。當對主機的維護操作完畢后， 再將主機設置成可調度模式：
　　kubectl uncordon [nodeid]

　　這樣新創(chuàng )建的容器即可以分配到該主機，可以通過(guò)kubectl patch 對資源對象進(jìn)行實(shí)時(shí)修改，比如為service增加端口，為pod修改容器鏡像版本。Annotation 可以幫助用戶(hù)更好的設置kubernete自定義插件。用戶(hù)可以在自建組件中獲取資源中對應的annotation以此進(jìn)行操作。通過(guò)kubectl label可以方便的對資源打標簽，比如對node打標簽，然后容器調度時(shí)可指定分配到對應標簽的主機。

　　Kubernetes作為容器集群管理工具,為應用平臺提供了基于云原生的微服務(wù)支持，其活躍的社區吸引了廣大開(kāi)發(fā)者的熱情關(guān)注，刺激了容器周邊生態(tài)的快速發(fā)展，同時(shí)為眾多互聯(lián)網(wǎng)企業(yè)采用容器集群架構升級內部IT平臺設施，構建高效大規模計算體系提供了技術(shù)基礎。

　?。ㄔ膩?lái)自CSDN）