摘要：對于應用，我們經常需要部署多個實例用于負載均衡，在，可以通過服務非常快速的創建一個內部負載均衡。這意味著是一個內部負載均衡器。因此，代表著流量入口和負載均衡的作用。

Docker不是虛擬機。 在很多的網絡教案中喜歡將Docker與虛擬機進行類比，這種類比用于理解Docker的優勢有著不錯的作用，因為Docker與虛擬機有著相同的優勢。但是從技術而言，虛擬機技術則是對硬件層的虛擬化，而Docker是一種進程隔離技術。簡單的說，我們可以在宿主機（Host Machine）使用 ps aux 看到使用Docker啟動的進程。這意味著Docker中的程序實際上是跑在宿主操作系統中。這是我不贊成將Docker與虛擬機進行類比的原因。

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

Namespace 是Linux中對進程之間進行隔離保護的技術。通過Namespace技術，保證了不同Docker Container中看到的內容不一樣，這也是Docker的基礎。

cgroups（Control Groups）最初叫Process Container，由Google工程師（Paul Menage和Rohit Seth）于2006年提出，后來因為Container有多重含義容易引起誤解，就在2007年更名為Control Groups，并被整合進Linux內核。顧名思義就是把進程放到一個組里面統一加以控制 。本質上，Cgroups 是一種對進程資源控制（比如可訪問內存，CPU時間使用）的技術手段。

這里我們可以更加清楚的明白，Docker只是一個基于操作系統提供的虛擬化能力的一個上層應用，其核心功能都是由內核實現。這也是與虛擬機最大的不同點。

Kubernetes 是一個由Google 主導開發的開源容器編排平臺，通過數年的發展已經成為了容器編排的事實標準。各大云平臺也都提供了完善的Kubernetes功能，我們可以在Kubernetes的源碼中看到目前適配的云平臺。

在Kubernetes的世界里，我們不在關心具體的服務器細節，我們看到的是一個一個CPU，一條一條內存，一塊一塊的磁盤擺在眼前，服務器已經被完全的抽象為計算資源。應用服務器的無狀態化帶來的最大好處是擴容的便利性，我們可以借助云平臺，在數分鐘內完成百倍的吞吐量擴展。另一方面，對于應用開發者，所有的一切都在kubectl 這一個工具中。

Master 管理著整個集群的狀態與訪問。

節點（Node）代表著一臺物理實例。所有集群中的容器都運行在節點中。一旦某一個節點發生故障，則運行在該節點的容器會自動的遷移到其他節點（注意，遷移的過程是銷毀重建。事實上為了狀態的一致性，在Kubernetes中沒有容器的停止與重啟的概念）。

在集群運行中，我們可以添加/減少節點。在節點新增之后，

在集群（Cluster）內部，Kubernetes使用虛擬網絡層進行網絡通訊。這使得每一個容器都有一個自己獨立的ip。我們可以從任何一個容器通過這個ip訪問到另一個容器內部。

對于Web應用，我們經常需要部署多個實例用于負載均衡，在Kubernetes，可以通過Service服務非常快速的創建一個內部負載均衡（ELB）。對于每一個Service,仍然會分配一個ip，使得我們可以從一個容器去訪問另外一組容器而無需任何額外的程序（例如Haproxy,Nginx）支持。

在虛擬網絡之上，Kubernetes還提供了針對虛擬網絡的DNS系統，我們只需要按照特定的規則就可以訪問不同的Service，連ip都不需要知曉。

虛擬網絡完全的避開了對于物理網絡細節（例如Ip 地址，端口號）的依賴，使得我們可以通過配置得到一個完全一致的集群環境。

除了使用虛擬IP進行訪問之外，Kubernetes還提供了基于DNS的訪問辦法。

我們永遠不應該在容器中存儲任何需要持久化存儲的數據（Mysql,Redis），因為容器會崩潰重建，故障遷移等原因造成自動重新部署，這些動作都會造成數據的丟失。如果在容器中需要使用持久化存儲，我們需要使用 Persistent Volume 服務。該服務通過將外部的持久化存儲系統掛載到容器中進行使用。對于一塊磁盤，可以掛載一個允許寫操作的卷到一個容器，以及掛載多個只讀權限給多個容器。

不建議將容器中應用程序的配置文件在構建鏡像（Docker Image）的時候打包進去，這會造成配置文件的變更需要重新構建。在Kubernetes中，提供了ConfigMap服務進行配置文件的管理。

我們通過會通過ConfigMap來構建應用程序的配置管理，然后將其掛載到容器中使用。這可以非常容器的讓我們的應用程序跑在不同的環境中。

當我們向集群新增加一個（些）容器的時候，集群會自動將容器部署到合適的節點。集群會根據不同節點（Node）的狀態（節點狀態，節點資源狀態）來進行規劃，并且自動部署。在新增容器的時候，我們還可以指定對應的Node Label將不同的服務部署到不同的物理實例中，以實現服務的物理隔離。

Pod 是一個或多個Docker容器的組合，它們之間具有共享的存儲與網絡。Pod也是Kubernetes的最小單位，Pod中的容器會保證永遠運行于同一個節點。

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

部署（Development）是一個針對如何管理Pod的工具。通過Development我們可以快速地創建多個Pod副本，并且支持滾動熱更新，從而實現了應用程序的熱更新。我們可以簡單的將部署理解為應用的多服務器管理技術手段，在物理機時代，有ansible這樣的工具來進行批量部署。

我們已經使用部署將我們的應用部署在了多臺節點中，盡管Kubernetes已經提供了虛擬IP來讓我們進行不同容器之間的通訊，但是這個IP是不穩定的，因為我們的節點會進行故障遷移，宕機，從而可能更新IP。那么我們如何訪問這些服務？ 答案就是Service。

Service將一些Pod關聯在一起，并且設定一些訪問策略（比如端口映射），并且允許設定一個固定的ip。當我們嘗試去訪問這些服務的時候，我們只需要訪問Service的ip與端口（映射之后的Service端口）就可以訪問這些服務，并且Service本身可以進行負載均衡與健康檢查。

這意味著Service是一個內部負載均衡器（ELB）。

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

a. Service是4層代理，Ingress是7層代理（Http）。
b. Service是服務的集群內部訪問方法，Ingress則是通過一組規則來控制從外部系統（internet）到多個服務的訪問方法。

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

從概念上，StatefulSet與Development是非常的相似，但是不同點是：Development是對無狀態Pod的管理（比如Http Server），而StatefulSet則是對有狀態的Pod進行管理，比如（數據庫 MySQL）,同時會遵循固定的順序進行啟動或銷毀容器。

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

Daemon Set是一種獨特的部署方式，它保證了容器會運行在所有指定的節點中，并且保證在節點生命周期內一直存活。這通常適用于一些節點監控程序或采集程序。比如fluentd 或 logstash

Job是一種一次性工作程序的部署方式。它會在所有指定的Pod運行完之后結束生命周期。比如我們可以使用Job來運行數據庫遷移程序。

從名稱可知，CronJob是計劃任務的方式來運行程序，并且使用Cron語法來描述間隔周期，但是CronJob會有一些需要注意的地方：

a. CronJob是分布式的，它不會保證運行在某一個確定的節點中，除非在YAML中指定。
b. CronJob可能因為調度的問題，造成運行多次，這需要我們保證CronJob程序的冪等性。 

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

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

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

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