作者 ｜ 中國移動云能力中心PaaS產品部 仇明

?近些年來，容器技術迅速席卷全球，顛覆了應用的開發、交付和運行模式。容器技術作為云原生技術領域的技術基石，也是現今最熱門的一種服務器端技術。容器以及容器編排技術成為基礎設施領域最炙手可熱的關鍵詞，隨著容器及周邊生態技術的蓬勃發展，容器社區當仁不讓成為開源社區最活躍的生態圈之一。同時，以容器技術為核心的容器生態圈在云計算、互聯網等領域得到了廣泛應用。

01容器的概念

早在2000年，容器技術的概念就已經出現，當初是用在chroot環境中做進程隔離。2013年，Docker項目正式發布，讓Linux容器技術逐步席卷天下。2014 年，Kubernetes項目正式發布，容器技術開始和編排系統齊頭并進。

容器的本質，是一個試圖被隔離，資源受限制的進程。所使用的隔離技術都是基于Linux內核提供，其中namespace用來做資源隔離，cgroups用來做資源限制（CPU、內存、存儲、網絡的使用限制）。隔離技術中不得不提的是虛擬機。通過如下的虛擬機和容器的對比圖，可以看出，虛擬機工作原理中最重要的是Hypervisor層——進行硬件虛擬化功能，模擬出運行操作系統需要的各種硬件（如 CPU、內存、I/O 設備等），然后，在這些虛擬硬件上安裝操作系統Guest OS。而容器沒有自己的OS，通過Container Daemon直接共享宿主機內核，所有對容器進程的限制都是基于宿主機操作系統本身能力進行。故而，容器也顯得很輕量化。

02Pod概念

2.1 操作系統中的例子

首先，在虛擬機中運行一個簡單的java程序，然后通過pstree指令，將會看到這個java程序實際上是由一組（linux中）線程組成，共享資源，共同協作完成java程序的業務工作。

2.2 Pod實現原理

在被譽為云時代的操作系統Kubernetes 中，容器被類比為了進程，那么Pod呢？其實 Pod 只是一個抽象的邏輯概念，它可以類比為前面例子中的java程序一樣，是一組（一個或者多個）容器的集合，這些容器之間共享同一份網絡（Network Namespace）和存儲（Volume）等資源。

2.2.1 網絡共享

Pod中首先會創建一個基礎容器（Infra container），然后以join network namespace的方式，將其它容器都與基礎容器的網絡關聯起來，這樣就實現了pod內容器間共享網絡資源的功能。所以基礎容器永遠都是Pod 里面第一個被創建的容器，等待其他容器的加入。Pod的生命周期只跟基礎容器一致。基礎容器是一個非常小的鏡像，叫做 k8s.gcr.io/pause，大概 100~200KB 左右，是一個匯編語言寫的、永遠處于“暫停”狀態的容器。

2.2.2 存儲共享

Pod是通過Volume實現共享存儲的。Pod先綁定好Volume，然后Pod里的容器只要聲明掛載這個Volume，就可以共享這個Volume對應的宿主機目錄，所有容器看到的這個Volume目錄內容都是一樣的。以下yaml提供了單Pod內啟兩個容器的示例。

apiVersion: v1
kind: Pod
metadata:
  name: one-pod-two-container-demo
spec:
  volumes:                  #Pod先綁定好Volume
    - name: shared-logs
      emptyDir: {}
  containers:
    - name: web-nginx
      image: nginx
      volumeMounts:          #容器再掛載這個volume
        - name: shared-logs
          mountPath: /var/log/nginx
    - name: sidecar-container
      image: busybox
      command: ["sh","-c","while true; do cat /var/log/nginx/access.log /var/log/nginx/error.log; sleep 30; done"]
      volumeMounts:          #容器再掛載這個volume
        - name: shared-logs
          mountPath: /var/log/nginx

03容器設計模式

Kubernetes 社區結合了Kubernetes 集群的微服務模型提出了一系列解決典型分布式系統問題的容器設計模式，主要可以分三大類：

• 單容器管理模式；
• 單節點多容器模式；
• 多節點多容器模式。

3.1 單容器管理模式

Kubernetes 容器設計模式中，單容器管理模式是最簡單的，單單啟動一個單容器微服務實例命令與Docker原生命令類似。

$ kubectl run nginx --image=nginx:latest -n qiuqiu
pod/nginx created

$ kubectl get all -n qiuqiu
NAME        READY   STATUS    RESTARTS   AGE
pod/nginx   1/1     Running   0          9s

3.2 單節點多容器模式

在秉持關注點分離原則（SOC)下，容器化應用程序是容器之間的職責分離，每個容器都應該只承擔它最擅長業務，其他額外的任務，應該交給其他容器（Sidecar 容器），單節點多容器模式便是利用了Kubernetes 中Pod內所有容器可以共享同一個存儲空間（Volume）和網絡地址空間（Network Namespace）特性，來充分體現SOC原則。

3.2.1 挎斗模式（Sidecar Pattern）

挎斗模式主要是利用在同一個Pod中的容器可以共享存儲的能力。如下圖應用日志收集服務場景：對于應用服務A（如：Nginx）來說，重心并非日志的持久化存儲與管理（access.log等)，而運維人員有時會需要通過日志排查服務異常問題。因此，日志收集器服務是一個很有必要的輔助工具。秉持關注點分離原則（SOC)，可以為應用服務的Pod中加入一個日志收集器服務的Sidecar 容器，應用服務容器作為主容器只需關注業務，日志信息由Sidecar 容器進行收集處理。生產環境中可以使用Filebeat 或者 Logstash 等工具收集日志并分發給ElasticSearch集群。挎斗模式下，通常作為輔助工具的Sidecar 容器鏡像是標準化可重用的，應用服務不需要每次都帶著輔助工具的執行文件一起打包迭代升級。

以下yaml文件定義了一個Pod內，啟動2個容器（不包含基礎容器），并使用emptyDir卷作為共享存儲。Sidecar 容器通常在定義中排在第二位，因此在執行 kubectl 命令時，默認目標是主容器。Nginx 服務作為主容器，產生的日志寫入共享存儲卷掛載的/var/log/nginx目錄。這樣可以阻止原本將Nginx 服務日志以容器標準化輸出形式輸出（即阻止被軟連接到/dev/stdout和/dev/stderr，輸出到了容器的前臺日志），并寫入access.log 與 error.log 文件。最后由Sidecar容器（busybox）進行相關日志處理。

apiVersion: v1
kind: Pod
metadata:
  name: app-log-aggregation-server
spec:
  volumes:
    - name: shared-logs
      emptyDir: {}
  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/nginx
    - name: sidecar-container
      image: busybox
      command: ["sh","-c","while true; do cat /var/log/nginx/access.log /var/log/nginx/error.log; sleep 30; done"]
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/nginx

3.2.2 外交官模式(Ambassador Pattern)

外交官模式主要是利用同一個Pod中的容器可以共享網絡地址空間的特性。外交官模式中存在一個負責代理從應用程序容器到其他服務的連接的邊車容器（SideCar container ），也稱為外交官容器。例如，幾乎所有應用程序在某個階段都需要數據庫連接。針對應用開發迭代中會存在多種環境數據庫——一個開發數據庫、一個測試數據庫和一個生產數據庫。在編寫應用程序的 Pod 時，開發/實施人員需要可以通過環境變量或 configMap 更改數據庫連接配置項達到數據庫的切換。而這種情況下還可以通過外交官模式，根據運行的環境將數據庫連接代理到相應的數據庫。開發/實施人員無需修改配置項（和使用開發環境數據庫配置項一樣)，當部署到測試或生產環境時，外交官容器會檢測它在哪個環境上運行（例如反射方式），并連接到正確的數據庫上。

以下yaml給出一個Redis客戶端訪問不同環境Redis庫樣例。主容器是由redis客戶端服務，外交官容器是基于malexer/twemproxy 鏡像啟動的容器，提供中繼鏈接Redis數據服務。需要說明的malexer/twemproxy 鏡像需要將Redis 實例以環境變量傳遞（13-15行），格式為address:port:weight。默認情況下，該容器偵聽端口 6380（其他高級配置可查閱github：https://github.com/malexer/docker-twemproxy）。 

# Redis client yaml
apiVersion: v1
kind: Pod
metadata:
  namespace: qiuqiu
  name: ambassador-example
spec:
  containers:
  - name: redis-client
    image: redis
  - name: ambassador
    image: malexer/twemproxy
    env:
    - name: REDIS_SERVERS
      value: redis-st-0.redis-svc.qiuqiu.svc.cluster.local:6379:1
    ports:
    - containerPort: 6380

以下圖，演示了應用程序（由 Redis 客戶端模擬）向 localhost:6380 發起請求，外交官容器接收請求并將其中轉到其配置中定義的 Redis 服務器。

3.2.3 適配器模式（Adapter Pattern）

適配器模式主要是以標準化和規范化應用對外暴露服務接口。每個應用程序可能會以各種形式（如JSON、XML、StatsD等），對外輸出監控指標數據。然而，監控系統卻希望收到的是統一數據模型的數據。這時就可以通過使用適配器模式，將應用程序容器，同相應的監控指標數據轉換的適配器容器創建在同一個Pod內，就可做到將不同應用的異構監控指標數據轉換為單個統一模型數據。

以下yaml是以Prometheus 監控Nginx 服務狀態指標為例。Nginx 有一個用于查詢 Web 服務器狀態的接口，只要更改 default.conf 文件配置項即可啟用。接著添加一個適配器容器將此接口的輸出轉換為 Prometheus 所需的數據格式即可。通過configMap 配置 default.conf 文件內容，其中（20-24行）定義了一個接口（/nginx_status），它利用 stub_status 模塊來顯示 Nginx 狀態信息；接著是創建包含Nginx 容器和適配器容器的Pod。適配器容器使用 nginx/nginx-prometheus-exporter鏡像創建，它可以按照 Prometheus 格式轉換 Nginx 在 /nginx_status 接口暴露的指標數據格式。

# Nginx config
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: qiuqiu
  name: nginx-conf
data:
  default.conf: |
    server {
      listen       80;
      server_name  localhost;
      location / {
          root   /usr/share/nginx/html;
          index  index.html index.htm;
      }
      error_page   500 502 503 504  /50x.html;
      location = /50x.html {
          root   /usr/share/nginx/html;
      }
      location /nginx_status {
        stub_status;
        allow 127.0.0.1;  #only allow requests from localhost
        deny all;   #deny all other hosts 
      }
    }




# Nginx Pod and the adapter container
apiVersion: v1
kind: Pod
metadata: 
  namespace: qiuqiu
  name: webserver
spec:
  volumes:
  - name: nginx-conf
    configMap:
      name: nginx-conf
      items:
      - key: default.conf
        path: default.conf
  containers:
  - name: webserver
    image: nginx
    ports:
    - containerPort: 80
    volumeMounts:
    - mountPath: /etc/nginx/conf.d
      name: nginx-conf
      readOnly: true
  - name: adapter
    image: nginx/nginx-prometheus-exporter:0.4.2
    args: ["-nginx.scrape-uri","http://localhost/nginx_status"]
    ports:
    - containerPort: 9113

以下圖是驗證操作：執行yaml創建服務后，首先登錄到 webserver Pod，安裝 curl 指令（便于發起 HTTP 請求），接著，檢查 /nginx_status 接口和適配器容器的轉換接口（9113/metrics ）。

3.3 多節點多容器模式

3.3.1 選舉模式（Election Pattern）

選舉模式是一種多節點多容器組合模式，在分布式系統中尤為重要。在分布式系統中，有狀態應用服務來要解決高可用和水平伸縮問題時，需要依賴外部系統存儲每個實例與狀態分片數據的對應關系（全局信息）。而引入選舉主控節點機制，就不需要依賴外部的系統來維護自己的狀態了，由主控節點完成保存和分發全局信息任務——將應用服務容器與可復用的選舉器容器組合起來使用——即選舉模式。

以下yaml提供了一個用來作為應用容器檢測選舉結果的nodejs服務（具體參考Kubernetes社區contrib項目election（https://github.com/kubernetes/contrib/tree/master/election））

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-elector-nodejs
  namespace: qiuqiu
spec:
  replicas: 3
  selector:
    matchLabels:
      name: leader-elector
  template:
    metadata:
      labels:
        name: leader-elector
    spec:
      containers:
      - image: k8s.gcr.io/nodejs-election-client:0.1
        imagePullPolicy: IfNotPresent
        name: nodejs
        ports:
        - containerPort: 8080
          protocol: TCP
        resources:
          requests:
            cpu: 100m
      - image: k8s.gcr.io/leader-elector:0.5
        imagePullPolicy: Always
        name: elector
        args:
          - --election=elect-master
          - --http=localhost:4040
        ports:
        - containerPort: 4040
          protocol: TCP
        resources:
          requests:
            cpu: 100m

04綜述

以上簡單介紹了容器和Pod的概念，并基于容器和Pod的關系，引入容器設計模式。并結合實例介紹了跨斗模式、外交官模式、適配器模式、選舉模式。以下列表是對以上介紹模式的一個簡單綜述。

鑒于篇幅限制，諸如工作隊列模式（Work queue pattern）、分散收集模式（Scatter/gather pattern）等其他優秀的設計模式，讀者可以按需查詢社區文檔（https://kubernetes.io/blog）。