作為一名長期從事運維的工程師來說，我會時常審視維護伺服器工作的簡單性與可重現性；而我的一個最重要的工作原則便是“永遠不要手動操作伺服器”。所有伺服器都必須由工具進行啟動（provisioned）與配置以執行，同時通過工具來監控、維護伺服器的狀態——而我的選擇是Chef；當然你也可以有很多其他選擇如：Ansible、Salt與Puppet。

在Collective Idea中，Chef確實執行得非常好，它管理著公司內部與外部客戶的很多伺服器。但是，漸漸的我也意識到了Chef的一個缺陷：對變化的處理不好。生產環境的應用與基礎設施都是有很多複雜的構件（creatures）組成，這些構件都由很多變化的元件（moving parts）組成，元件之間又有大量的顯式或者隱式的依賴——它們隨時都會由於不可預知的原因發生變化。其中，有些變化容易處理，如配置檔案更改或者對系統進行微調；但是其他一些就比較複雜，如，不停機升級一個應用依賴的Ruby執行時版本。而且，還有一些對伺服器的調整需要人工操作，如，升級作業系統核心後的重啟等。

不可變基礎設施

Docker

• 容器與容器之間如何發現與通訊？
• 如何決定在哪執行以及執行多少個容器？
• 如何獲取容器執行的日誌與執行狀態資訊？
• 如何部署新的映象？
• 容器崩潰時都發生了什麼？
• 如何只將特定的一部分容器暴露在公網或者內網環境下？

直至當下，相比現在服役的Chef工具來說，回答這些問題以及大規模在Collective Idea部署Docker應用都還不太成熟。但是，現在還是湧現出了很多解決我提出的問題的工具，而且還提供了可用於生產環境的容器化部署方案，如：Docker公司自己的Docker Compose；但是我們還是選擇了Google的方案——Kubernetes ，它號稱融合了Google在十幾年來在其超大規模資料中心運行了數十億個容器的經驗。

在本系列文章的第一篇中我闡述了從基礎設施的容器化角度闡述了什麼是容器，什麼是Docker以及它們是怎麼來重新定義運維工作以及對基礎設施產生的影響。但是，僅僅瞭解了容器與Docker還不足以將它們運用到我們實際的技術棧中去；所以在本篇文章中我會介紹Kubernetes——一個容器的編排（orchestration）工具——我選擇用它來為基礎設施容器化部署提供支援。

資源（Resources）

Node

Pod

Deployment

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        role: web
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80  

Service

##
# nginx
# Listen to the world on port 80 and 443
##
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    role: web
spec:
  type: LoadBalancer
  ports:
  - name: http
    port: 80
    targetPort: 80
  - name: https
    port: 443
    targetPort: 443
  selector:
    # Find all Resources that are tagged with the "role: web" label
    # In our case, it will find the nginx Deployment mentioned above
    role: web
---
##
# Rails
# Listen for traffic on 8080 so we don't have to run as root.
##
apiVersion: v1
kind: Service
metadata:
  name: rails
  labels:
    role: rails
spec:
  type: NodePort
  ports:
  - port: 8080
    targetPort: 8080
  selector:
    role: rails
---
##
# Redis
##
apiVersion: v1
kind: Service
metadata:
  name: redis
  labels:
    role: redis
spec:
  type: NodePort
  ports:
  - port: 6379
    targetPort: 6379
  selector:
    role: redis   

Namespace

apiVersion: v1
kind: Namespace
metadata:
  name: my-app

Labels

• 任何應用都有敏感資訊需要保持安全（資料庫密碼等），Kubernetes中的secrets資源就是用來在Pod與容器中保護你的敏感資訊的；
• DaemonSet資源型別用於定義在部分或者所有Nodes中都冗餘的執行一個Pod。
• Job資源用於建立一次性的任務，例如當你需要遷移一個數據庫時可以使用。