摘要：對(duì)于應(yīng)用，我們經(jīng)常需要部署多個(gè)實(shí)例用于負(fù)載均衡，在，可以通過(guò)服務(wù)非常快速的創(chuàng)建一個(gè)內(nèi)部負(fù)載均衡。這意味著是一個(gè)內(nèi)部負(fù)載均衡器。因此，代表著流量入口和負(fù)載均衡的作用。

Docker不是虛擬機(jī)。 在很多的網(wǎng)絡(luò)教案中喜歡將Docker與虛擬機(jī)進(jìn)行類比，這種類比用于理解Docker的優(yōu)勢(shì)有著不錯(cuò)的作用，因?yàn)镈ocker與虛擬機(jī)有著相同的優(yōu)勢(shì)。但是從技術(shù)而言，虛擬機(jī)技術(shù)則是對(duì)硬件層的虛擬化，而Docker是一種進(jìn)程隔離技術(shù)。簡(jiǎn)單的說(shuō)，我們可以在宿主機(jī)（Host Machine）使用 ps aux 看到使用Docker啟動(dòng)的進(jìn)程。這意味著Docker中的程序?qū)嶋H上是跑在宿主操作系統(tǒng)中。這是我不贊成將Docker與虛擬機(jī)進(jìn)行類比的原因。

要去理解Docker,最避不開的是Namespace 與Cgroups。

Namespace 是Linux中對(duì)進(jìn)程之間進(jìn)行隔離保護(hù)的技術(shù)。通過(guò)Namespace技術(shù)，保證了不同Docker Container中看到的內(nèi)容不一樣，這也是Docker的基礎(chǔ)。

cgroups（Control Groups）最初叫Process Container，由Google工程師（Paul Menage和Rohit Seth）于2006年提出，后來(lái)因?yàn)镃ontainer有多重含義容易引起誤解，就在2007年更名為Control Groups，并被整合進(jìn)Linux內(nèi)核。顧名思義就是把進(jìn)程放到一個(gè)組里面統(tǒng)一加以控制 。本質(zhì)上，Cgroups 是一種對(duì)進(jìn)程資源控制（比如可訪問(wèn)內(nèi)存，CPU時(shí)間使用）的技術(shù)手段。

這里我們可以更加清楚的明白，Docker只是一個(gè)基于操作系統(tǒng)提供的虛擬化能力的一個(gè)上層應(yīng)用，其核心功能都是由內(nèi)核實(shí)現(xiàn)。這也是與虛擬機(jī)最大的不同點(diǎn)。

Kubernetes 是一個(gè)由Google 主導(dǎo)開發(fā)的開源容器編排平臺(tái)，通過(guò)數(shù)年的發(fā)展已經(jīng)成為了容器編排的事實(shí)標(biāo)準(zhǔn)。各大云平臺(tái)也都提供了完善的Kubernetes功能，我們可以在Kubernetes的源碼中看到目前適配的云平臺(tái)。

在Kubernetes的世界里，我們不在關(guān)心具體的服務(wù)器細(xì)節(jié)，我們看到的是一個(gè)一個(gè)CPU，一條一條內(nèi)存，一塊一塊的磁盤擺在眼前，服務(wù)器已經(jīng)被完全的抽象為計(jì)算資源。應(yīng)用服務(wù)器的無(wú)狀態(tài)化帶來(lái)的最大好處是擴(kuò)容的便利性，我們可以借助云平臺(tái)，在數(shù)分鐘內(nèi)完成百倍的吞吐量擴(kuò)展。另一方面，對(duì)于應(yīng)用開發(fā)者，所有的一切都在kubectl 這一個(gè)工具中。

Master 管理著整個(gè)集群的狀態(tài)與訪問(wèn)。

節(jié)點(diǎn)（Node）代表著一臺(tái)物理實(shí)例。所有集群中的容器都運(yùn)行在節(jié)點(diǎn)中。一旦某一個(gè)節(jié)點(diǎn)發(fā)生故障，則運(yùn)行在該節(jié)點(diǎn)的容器會(huì)自動(dòng)的遷移到其他節(jié)點(diǎn)（注意，遷移的過(guò)程是銷毀重建。事實(shí)上為了狀態(tài)的一致性，在Kubernetes中沒(méi)有容器的停止與重啟的概念）。

在集群運(yùn)行中，我們可以添加/減少節(jié)點(diǎn)。在節(jié)點(diǎn)新增之后，

在集群（Cluster）內(nèi)部，Kubernetes使用虛擬網(wǎng)絡(luò)層進(jìn)行網(wǎng)絡(luò)通訊。這使得每一個(gè)容器都有一個(gè)自己獨(dú)立的ip。我們可以從任何一個(gè)容器通過(guò)這個(gè)ip訪問(wèn)到另一個(gè)容器內(nèi)部。

對(duì)于Web應(yīng)用，我們經(jīng)常需要部署多個(gè)實(shí)例用于負(fù)載均衡，在Kubernetes，可以通過(guò)Service服務(wù)非?？焖俚膭?chuàng)建一個(gè)內(nèi)部負(fù)載均衡（ELB）。對(duì)于每一個(gè)Service,仍然會(huì)分配一個(gè)ip，使得我們可以從一個(gè)容器去訪問(wèn)另外一組容器而無(wú)需任何額外的程序（例如Haproxy,Nginx）支持。

在虛擬網(wǎng)絡(luò)之上，Kubernetes還提供了針對(duì)虛擬網(wǎng)絡(luò)的DNS系統(tǒng)，我們只需要按照特定的規(guī)則就可以訪問(wèn)不同的Service，連ip都不需要知曉。

虛擬網(wǎng)絡(luò)完全的避開了對(duì)于物理網(wǎng)絡(luò)細(xì)節(jié)（例如Ip 地址，端口號(hào)）的依賴，使得我們可以通過(guò)配置得到一個(gè)完全一致的集群環(huán)境。

除了使用虛擬IP進(jìn)行訪問(wèn)之外，Kubernetes還提供了基于DNS的訪問(wèn)辦法。

我們永遠(yuǎn)不應(yīng)該在容器中存儲(chǔ)任何需要持久化存儲(chǔ)的數(shù)據(jù)（Mysql,Redis），因?yàn)槿萜鲿?huì)崩潰重建，故障遷移等原因造成自動(dòng)重新部署，這些動(dòng)作都會(huì)造成數(shù)據(jù)的丟失。如果在容器中需要使用持久化存儲(chǔ)，我們需要使用 Persistent Volume 服務(wù)。該服務(wù)通過(guò)將外部的持久化存儲(chǔ)系統(tǒng)掛載到容器中進(jìn)行使用。對(duì)于一塊磁盤，可以掛載一個(gè)允許寫操作的卷到一個(gè)容器，以及掛載多個(gè)只讀權(quán)限給多個(gè)容器。

不建議將容器中應(yīng)用程序的配置文件在構(gòu)建鏡像（Docker Image）的時(shí)候打包進(jìn)去，這會(huì)造成配置文件的變更需要重新構(gòu)建。在Kubernetes中，提供了ConfigMap服務(wù)進(jìn)行配置文件的管理。

我們通過(guò)會(huì)通過(guò)ConfigMap來(lái)構(gòu)建應(yīng)用程序的配置管理，然后將其掛載到容器中使用。這可以非常容器的讓我們的應(yīng)用程序跑在不同的環(huán)境中。

當(dāng)我們向集群新增加一個(gè)（些）容器的時(shí)候，集群會(huì)自動(dòng)將容器部署到合適的節(jié)點(diǎn)。集群會(huì)根據(jù)不同節(jié)點(diǎn)（Node）的狀態(tài)（節(jié)點(diǎn)狀態(tài)，節(jié)點(diǎn)資源狀態(tài)）來(lái)進(jìn)行規(guī)劃，并且自動(dòng)部署。在新增容器的時(shí)候，我們還可以指定對(duì)應(yīng)的Node Label將不同的服務(wù)部署到不同的物理實(shí)例中，以實(shí)現(xiàn)服務(wù)的物理隔離。

Pod 是一個(gè)或多個(gè)Docker容器的組合，它們之間具有共享的存儲(chǔ)與網(wǎng)絡(luò)。Pod也是Kubernetes的最小單位，Pod中的容器會(huì)保證永遠(yuǎn)運(yùn)行于同一個(gè)節(jié)點(diǎn)。

比如對(duì)于PHP-FPM應(yīng)用而言，需要PHP-FPM進(jìn)程與對(duì)應(yīng)的Web Server（Nginx,Apache）?；贒ocker最小部署原則，我們會(huì)將PHP-FPM與Web Server分為兩個(gè)鏡像。我們可以在一個(gè)Pod中同時(shí)部署PHP-FPM鏡像與Web Server進(jìn)程，并且它們之間仍然可以通過(guò)fastcgi的方式進(jìn)行通訊。而Kubernetes又保證了這些容器具備相同的生命周期。我們將整體理解為一個(gè)應(yīng)用程序即可。

部署（Development）是一個(gè)針對(duì)如何管理Pod的工具。通過(guò)Development我們可以快速地創(chuàng)建多個(gè)Pod副本，并且支持滾動(dòng)熱更新，從而實(shí)現(xiàn)了應(yīng)用程序的熱更新。我們可以簡(jiǎn)單的將部署理解為應(yīng)用的多服務(wù)器管理技術(shù)手段，在物理機(jī)時(shí)代，有ansible這樣的工具來(lái)進(jìn)行批量部署。

我們已經(jīng)使用部署將我們的應(yīng)用部署在了多臺(tái)節(jié)點(diǎn)中，盡管Kubernetes已經(jīng)提供了虛擬IP來(lái)讓我們進(jìn)行不同容器之間的通訊，但是這個(gè)IP是不穩(wěn)定的，因?yàn)槲覀兊墓?jié)點(diǎn)會(huì)進(jìn)行故障遷移，宕機(jī)，從而可能更新IP。那么我們?nèi)绾卧L問(wèn)這些服務(wù)？ 答案就是Service。

Service將一些Pod關(guān)聯(lián)在一起，并且設(shè)定一些訪問(wèn)策略（比如端口映射），并且允許設(shè)定一個(gè)固定的ip。當(dāng)我們嘗試去訪問(wèn)這些服務(wù)的時(shí)候，我們只需要訪問(wèn)Service的ip與端口（映射之后的Service端口）就可以訪問(wèn)這些服務(wù)，并且Service本身可以進(jìn)行負(fù)載均衡與健康檢查。

這意味著Service是一個(gè)內(nèi)部負(fù)載均衡器（ELB）。

Ingress本質(zhì)上和Service一樣，也是一種流量代理的概念，但是與Service不一樣的是：

a. Service是4層代理，Ingress是7層代理（Http）。
b. Service是服務(wù)的集群內(nèi)部訪問(wèn)方法，Ingress則是通過(guò)一組規(guī)則來(lái)控制從外部系統(tǒng)（internet）到多個(gè)服務(wù)的訪問(wèn)方法。

我們可以設(shè)定不同的域名，不同的Http url path 路由到不同的后端服務(wù)（Backend Service）。 因此，Ingress代表著流量入口和負(fù)載均衡（LB）的作用。

從概念上，StatefulSet與Development是非常的相似，但是不同點(diǎn)是：Development是對(duì)無(wú)狀態(tài)Pod的管理（比如Http Server），而StatefulSet則是對(duì)有狀態(tài)的Pod進(jìn)行管理，比如（數(shù)據(jù)庫(kù) MySQL）,同時(shí)會(huì)遵循固定的順序進(jìn)行啟動(dòng)或銷毀容器。

通常地，StatefulSet服務(wù)都會(huì)搭配持久化存儲(chǔ)服務(wù)一起工作，我們會(huì)將數(shù)據(jù)庫(kù)的數(shù)據(jù)目錄指向持久化存儲(chǔ)中，這保證了容器在銷毀、重建之后數(shù)據(jù)仍然不會(huì)丟失。

Daemon Set是一種獨(dú)特的部署方式，它保證了容器會(huì)運(yùn)行在所有指定的節(jié)點(diǎn)中，并且保證在節(jié)點(diǎn)生命周期內(nèi)一直存活。這通常適用于一些節(jié)點(diǎn)監(jiān)控程序或采集程序。比如fluentd 或 logstash

Job是一種一次性工作程序的部署方式。它會(huì)在所有指定的Pod運(yùn)行完之后結(jié)束生命周期。比如我們可以使用Job來(lái)運(yùn)行數(shù)據(jù)庫(kù)遷移程序。

從名稱可知，CronJob是計(jì)劃任務(wù)的方式來(lái)運(yùn)行程序，并且使用Cron語(yǔ)法來(lái)描述間隔周期，但是CronJob會(huì)有一些需要注意的地方：

a. CronJob是分布式的，它不會(huì)保證運(yùn)行在某一個(gè)確定的節(jié)點(diǎn)中，除非在YAML中指定。
b. CronJob可能因?yàn)檎{(diào)度的問(wèn)題，造成運(yùn)行多次，這需要我們保證CronJob程序的冪等性。 

apiVersion: apps/v1 #當(dāng)前服務(wù)的API版本，對(duì)于Beta中的服務(wù)，需要在部署Kubenetes集群中進(jìn)行開啟允許使用beta服務(wù)。
kind: Deployment #不同的服務(wù)類型使用Kind進(jìn)行標(biāo)記，比如Service,Ingress
metadata:
  name: nginx-deployment  #name是一個(gè)非常有用的屬性，它會(huì)在DNS系統(tǒng)中會(huì)使用
  labels:
    app: nginx  #當(dāng)前服務(wù)的標(biāo)簽設(shè)定
spec:
  replicas: 3  #Pod的副本數(shù)量
  selector:
    matchLabels:
      app: nginx
  template:  #Pod的模板
    metadata:
      labels:
        app: nginx 
    spec:
      imagePullSecrets:    #如果鏡像使用的私有鏡像倉(cāng)庫(kù)，則需要指定docker倉(cāng)庫(kù)的key才可以pull docker鏡像
      - name: DOCKER_PULL_KEY_NAME
      containers:
      - name: nginx    #容器名稱
        env:     #附加到容器中的環(huán)境變了
        - name: ENV_NAME
          value: ENV_VALUE
        image: nginx:1.7.9 #鏡像
        ports:
        - containerPort: 80 #容器內(nèi)部的需要導(dǎo)出的端口

Kubernetes 憑借著Google多年的大規(guī)模服務(wù)器管理經(jīng)驗(yàn)，將后端架構(gòu)完整的抽象出了一些更高級(jí)別的概念，在這些概念中我們完全脫離了服務(wù)器本身的限制，不在操心具體的服務(wù)器配置。我們可以將更多的精力關(guān)注自己的應(yīng)用。

http://man7.org/linux/man-pag...

https://www.kernel.org/doc/Do...