本文采用本地k8s v1.10.3版本開發,如果還沒有搭建可參照 kubernetes學習筆記 （一）：搭建本地k8s開發環境進行搭建
搭建本地Docker映象倉庫
docker pull docker.io/registry拉取registry的映象到本機docker run -d -p 5000:5000 --name=registry --restart=always --privileged=true --log-driver=none -v /home/data/registrydata:/tmp/registry registry執行剛剛拉取的registry- 在Docker for Mac中找到Docker -> Preferences -> Daemon，在insecure registries中填入自己剛剛搭建的本地倉庫 http://localhost:5000
準備一個Docker映象
- 隨意使用什麼語言寫一個http介面,例如Nodejs：
@Get('whoami')
async whoAmI() {
debug('whoAmI called with %O', {});
return { serverType: Config.SERVER_TYPE };
}
複製程式碼- 編寫對應的DockerFile
FROM node:8
WORKDIR /root
RUN mkdir -p /root/app
COPY package.json /root/app/
COPY dist /root/app/dist
WORKDIR /root/app
RUN npm config set registry https://registry.npm.taobao.org/ ;\
npm config set disturl https://npm.taobao.org/dist/ ;\
npm i --production
CMD [ "node", "/root/app/dist/main.js" ]
EXPOSE 80
複製程式碼- 編譯、打標籤，並推送到本地倉庫中
echo 'Building to dits ...'
tsc
echo 'Docker building image ...'
docker build --rm -t localhost:5000/gateapp:0.0.1 .
echo 'Pushing ...'
docker push localhost:5000/gateapp
echo 'Docker list images ...'
docker images
複製程式碼最後你會看到localhost:5000/gateapp:0.0.1的映象已經在你的機器中啦,下面會用到
Kubernetes中的重要概念
- Cluster: Cluster是計算、儲存和網路資源的集合，Kubernetes利用這些資源執行各種基於容器的應用
- Master： Master是Kubernetes的大腦，它的主要職責是排程，即決定將應用放在那裡執行。
- Node: Node的職責是執行容器應用。Node由Master管理，Node負責監控並彙報容器的狀態，同時根據Master的要求管理容器的生命週期。
- Pod： Pod是Kubernetes中最小工作單元。每個Pod包含一個或多個容器。Pod中的容器會作為一個整體被Master排程到一個Node上執行。
- Controller：Kubernetes通常不會直接建立Pod，而是通過Controller來管理Pod。Controller中定義了Pod的部署特性，比如有幾個副本、在什麼樣的Node上執行等。為了滿足不同的業務場景，Kubernetes提供了多種Controller，包括Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job等，後面會逐個學習這些Controller
- Service：Service定義外界訪問一組特定Pod的方式。
建立Deployment部署應用
- 新建一個yaml檔案,如:
apiVersion: extensions/v1beta1 # kubectl api的版本
kind: Deployment # kubernetes的資源型別
metadata:
name: gate-deployment-dev
spec:
replicas: 2 # 執行的Pod副本數量
template:
metadata:
labels:
app: gate-app-dev
spec:
containers:
- name: gateapp
image: localhost:5000/gateapp:0.0.1 # Docker映象地址（上面建立的）
env: # 映象啟動時的環境變數
- name: NODE_ENV
value: 'development'
- name: HTTP_PORT
value: '80' # 容器http的埠 需要自己程式碼中實現
複製程式碼-
通過
kubectl apply -f xxx.yaml就可以部署上面的Deployment的了，也可以開啟Kubernetes的Dashboard點選建立，輸入yaml檔案中的內容進行建立。經過一段時間後，在Dashboard皮膚中可以看到,1個部署 gate-deployment-dev,一個副本集 gate-deployment-dev-775d556ffb，兩個容器組 gate-deployment-dev-775d556ffb-2tlgn、gate-deployment-dev-775d556ffb-sfqrq，可以點選檢視每個資源的資訊，大部分內容都是自解釋的。在部署Deployment後，Kubernetes大致執行了以下幾個過程：
- 使用者建立Deployment
- Deployment建立了一個副本集(ReplicaSet)gate-deployment-dev-775d556ffb
- ReplicaSet建立了兩個Pod，與我們定義的replicas: 2 一致
建立Service
此時上面的映象提供的介面還不能供外界訪問，需要建立一個對應的Service
- 新建立一個yaml檔案或者在上一個yaml檔案中新增 --- 隔開
- 編輯以下內容：
apiVersion: v1 # kubectl api的版本
kind: Service # kubernetes的資源型別
metadata:
name: gate-svc-dev
spec:
type: NodePort # service的型別 ClusterIp型別 只有Cluster內部節點和Pod可以訪問 NodePort Cluster外部可以通過<NodeIp>:<NodePort>訪問 LoadBalancer負載均衡
selector:
app: gate-app-dev # 與上面的template中定義的label一致
ports:
- protocol: TCP # 只有TCP 或 UDP
port: 80 # clusterIp 監聽的埠
nodePort: 30000 # Node 監聽的埠取值範圍 30000-32767
targetPort: 80 # Pod 監聽的埠
複製程式碼-
kubectl apply -f xxx.yaml或者在Dashboard中建立 -
觀察Dashboard皮膚，會發現多了一個名字叫gate-svc-dev的服務,提供了監聽了30000埠
-
curl http://localhost:30000/whoami可以看到介面已經可以訪問了需要注意的是：
-
為什麼需要Service？
Deployment等其他Controller動態建立和銷燬Pod來保證應用的健壯性，也就是Pod是脆弱的，應用是健壯的，我們不該期望Pod的健壯性。每個Pod都有自己的ClusterIp地址，當Pod發生故障被新的Pod替代時，ClusterIp很有可能發生變化，所以如果直接讓外界訪問Pod就有問題了。
-
Service和Pod如何對映？
通過上面的yaml定義可以看出，Service通過 label標籤選擇器選擇對應的一堆Pod。當請求被髮送到Service上時，Service採用了某種分配策略把流量轉發到了某一個Pod上面進行處理。
-
Service有哪些型別？
- ClusterIp：Service通過Cluster內部的IP對外提供服務，只有Cluster內的節點和Pod可以訪問，這是預設的型別。
- NodePort： Service通過Cluster節點的靜態埠對外提供服務。Cluster外部可以通過
<NodeIp>:<NodePort>訪問Service - LoadBalancer: cloud provider特有的對外提供服務，後續線上部署時會講到
-
滾動更新
滾動更新是一次只更新一小部分副本，成功後再更新更多的副本，最終完成所有副本的更新。滾動更新最大的好處就是零停機，保證了業務的連續性。
- 對原生程式碼進行一點改動
- 編譯、打標籤，並推送到本地倉庫中
echo 'Building to dits ...'
tsc
echo 'Docker building image ...'
docker build --rm -t localhost:5000/gateapp:0.0.2 .
echo 'Pushing ...'
docker push localhost:5000/gateapp
echo 'Docker list images ...'
docker images
複製程式碼這時候可以看到有0.0.1 和 0.0.2兩個版本的映象
-
在Dashboard中編輯Deployment，把
image: localhost:5000/gateapp:0.0.1改成image: localhost:5000/gateapp:0.0.2,點選更新 -
等待一段時間，再觀察所有的Pod都被更新成0.0.2版本的了，是不是很方便！
反覆執行上面的步驟，不難發現更新過程中Kubernets都做了什麼：
- Deployment的映象被更新為0.0.2版本
- 新建立了一個名稱為gate-deployment-dev-594468997c的ReplicaSet副本集,映象為0.0.2
- 新的ReplicaSet增加了一個Pod
- 舊的ReplicaSet減少了一個Pod
- 逐漸的新的ReplicaSet接管了所有舊ReplicaSet的Pod，滾動更新完成
-
自定義滾動更新行為
strategy:
rollingUpdate: # 滾動更新策略
maxSurge: 10% # 數值越大 滾動更新時新建立的副本數量越多
maxUnavailble: 10% # 數值越大 滾動更新時銷燬的舊副本數量越多
replicas: 2 # 執行的Pod副本數量
複製程式碼- maxSurge：此引數控制滾動更新中副本總數超過DESIRED的數量或最大比例，數值越大 滾動更新時新建立的副本數量越多
- maxUnavailble：此引數控制滾動更新中，不可用的副本佔DESIRED的最大數量或最大利弊，數值越大 滾動更新時銷燬的舊副本數量越多
複製程式碼那如果更新過程出錯了怎麼辦？請接著往下看
健康檢查
Kubernetes有很強大的自愈能力，預設的實現方式是重啟發生故障的容器，此外使用者可以使用Liveness、 Readiness的探測機制設定更為精細的健康檢查，進而真正實現零停機部署、避免部署無效的映象、更加安全的滾動升級
- 編輯之前的Deployment.yaml，例如：
image: localhost:5000/gateapp:0.0.13
readinessProbe: # 一種健康檢查決定是否加入到service 對外服務
httpGet:
scheme: HTTP # 支援http https
path: /healthy
port: 80 # 與你的pod埠一致
initialDelaySeconds: 10 # 容器啟動多久後開始檢查
periodSecods: 5 # 幾秒檢查一次
複製程式碼-
readinessProbe即是使用Readiness健康探測機制，當檢查不通過時（例如介面返回的狀態碼不是200-400之間），Kubernetes就不會把容器新增到Service中供外界訪問，觀察Pod的狀態為Not Ready。 initialDelaySeconds是決定容器啟動多久後開始檢查，通常要比啟動時間再長一些；periodSecods是多久檢查一次，連續3次探測失敗後，Ready將變成不可用，Kubernets把這個Pod從Service中下線
-
LiveNess的配置項和Readiness的一樣，不同之處在於探測失敗後的行為。前者會重啟容器，後者會設定Pod不可用，並從Service中下線。
-
LiveNess和Readiness的探測是獨立使用的，二者沒有依賴，可以單獨使用也可以同時使用。一般情況下使用LiveNess判斷容器是否需要重啟實現自愈；Readiness判斷容器是否已經準備好對外提供服務。
- 自定義健康檢查的程式碼： 自定義/healthy get介面,比如資料庫連線等等
@Get('healthy')
async checkHealthy(@Res() res: Response) {
let isHealthy = false;
// some code to check healthy begin
isHealthy = true;
// check end
const data = {
isHealthy,
};
debug('執行健康檢查結果 %O', data);
res.status(isHealthy ? HttpStatus.OK : HttpStatus.INTERNAL_SERVER_ERROR).json(data);
}
複製程式碼一起來學習Kubernetes
相信看完以上的文章，你也會認為Kubernetes真的非常強大，是非常值得學習的。筆者也是小白一個，從0開始學習的，如果你也想一起，可以加入我們的群。
