k8s本地部署

k8s是什麼

Kubernetes是容器集羣管理系統,是一個開源的平臺,能夠實現容器集羣的自動化部署、自動擴縮容、維護等功能。node

Kubernetes 具備以下特色:

便攜性: 不管公有云、私有云、混合雲仍是多雲架構都全面支持
可擴展: 它是模塊化、可插拔、可掛載、可組合的,支持各類形式的擴展
自修復: 它能夠自保持應用狀態、可自重啓、自複製、自縮放的,經過聲明式語法提供了強大的自修復能力nginx

Kubernetes 是什麼意思? K8s?

名稱 Kubernetes 源於希臘語,意爲 「舵手」 或 「飛行員」, 且是英文 「governor」 和 「cybernetic」的詞根。 K8s 是經過將 8 個字母 「ubernete」 替換爲 8 而導出的縮寫。另外,在中文裏,k8s 的發音與 Kubernetes 的發音比較接近。docker

架構

每個 Kubernetes 就集羣都由一組 Master 節點和一系列的 Worker 節點組成,其中 Master 節點主要負責存儲集羣的狀態併爲 Kubernetes 對象分配和調度資源。
api

Master

  • API Server 負責處理來自用戶的請求,其主要做用就是對外提供 RESTful 的接口,包括用於查看集羣狀態的讀請求以及改變集羣狀態的寫請求,也是惟一一個與 etcd 集羣通訊的組件。
  • Controller 管理器運行了一系列的控制器進程,這些進程會按照用戶的指望狀態在後臺不斷地調節整個集羣中的對象,當服務的狀態發生了改變,控制器就會發現這個改變而且開始向目標狀態遷移。 集羣故障檢測和恢復的自動化工做好比Replication Controller
  • Scheduler 調度器其實爲 Kubernetes 中運行的 Pod 選擇部署的 Worker 節點,它會根據用戶的須要選擇最能知足請求的節點來運行 Pod,它會在每次須要調度 Pod 時執行。
    主要用於收集和分析當前 Kubernetes 集羣中全部 Minion / Node 節點的資源 (包括內存、CPU 等) 負載狀況,而後依據資源佔用狀況分發新建的 Pod 到 Kubernetes 集羣中可用的節點。
    實時監測 Kubernetes 集羣中未分發和已分發的全部運行的 Pod

Worker

  • kubelet 負責 Node 節點上 Pod 的建立、修改、監控、刪除等全生命週期的管理,對pod進行各類操做和日誌上報
  • kube-proxy 負責宿主機的子網管理,同時也能將服務暴露給外部,其原理就是在多個隔離的網絡中把請求轉發給正確的 Pod 或者容器。

名詞解釋

  • Pod 是 Kubernetes 中可部署的最小、最基本對象。一個 Pod 表明集羣中正在運行的單個進程實例。 它們共享 PID、IPC、Network 和 UTS namespace
  • Container docker容器
  • Node 是 Pod 真正運行的主機,能夠是物理機,也能夠是虛擬機。
  • Service 是應用服務的抽象,經過 labels 爲應用提供負載均衡和服務發現。
  • Label 是識別 Kubernetes 對象的標籤,以 key/value 的方式附加到對象上。Label 定義好後其餘對象可使用 Label Selector 來選擇一組相同 label 的對象。
    如: app=nginx
  • Deployment 指不具備惟一標識的一組多個相同的 Pod。Deployment 運行應用的多個副本,並自動替換任何失敗或無響應的實例

部署

server.js網絡

var http = require('http');

var handleRequest = function(request, response) {
  console.log('Received request for URL: ' + request.url);
  response.writeHead(200);
  response.end('Hello World!');
};
var www = http.createServer(handleRequest);
www.listen(8080);
FROM node:6.9.2
EXPOSE 8080
COPY server.js .
CMD node server.js
eval $(minikube docker-env)
docker build -t hello-node:v1 .

建立 Deployment架構

kubectl run hello-node --image=hello-node:v1 --port=8080

查看 Deployment:app

kubectl get deployments

查看pod負載均衡

kubectl get pods

查看集羣事件:模塊化

kubectl get events

查看 kubectl 配置:post

kubectl config view

建立service
暴露到公網

kubectl expose deployment hello-node --type=LoadBalancer
kubectl get services

服務訪問

minikube service hello-node --url

查看log

kubectl logs <POD-NAME>

更新應用:

response.end('Hello World Again!');

構建v2鏡像

docker build -t hello-node:v2 .

修改鏡像

kubectl set image deployment/hello-node hello-node=hello-node:v2

再次訪問

清理

如今能夠清理您在集羣中建立的資源:

kubectl delete service hello-node
kubectl delete deployment hello-node

能夠中止 Minikube VM:

minikube stop
eval $(minikube docker-env -u)

或者,刪除 Minikube VM:

minikube delete

經過yaml描述文件建立deployment
deployment.yaml

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2 # tells deployment to run 2 pods matching the template
  template: # create pods using pod definition in this template
    metadata:
      # unlike pod-nginx.yaml, the name is not included in the meta data as a unique name is
      # generated from the deployment name
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

將 kubectl 的 —record 的 flag 設置爲 true 能夠在 annotation 中記錄當前命令建立或者升級了該資源。這在將來會頗有用,例如,查看在每一個 Deployment revision 中執行了哪些命令。

kubectl create -f deployment.yaml --record
kubectl describe deployment nginx-deployment
kubectl get deployments

給這個nginx換個版本

kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
或手動改配置
kubectl edit deployment/nginx-deployment

查看狀態:

kubectl rollout status deployment/nginx-deployment
- deployment "nginx-deployment" successfully rolled out

經過record能夠記錄命令

kubectl rollout history deployment/nginx-deployment
deployment.extensions/nginx-deployment
REVISION  CHANGE-CAUSE
1         kubectl create --filename=deployment.yaml --record=true
2         kubectl create --filename=deployment.yaml --record=true

擴容/縮容

kubectl  scale deployment nginx-deployment --replicas=4

查看歷史操做

kubectl rollout history deployment/nginx-deployment

回滾

kubectl rollout history deployment/nginx-deployment --revision=2

回滾到歷史版本

kubectl rollout undo deployment/nginx-deployment --to-revision=2

暫停/恢復

kubectl rollout pause deployment/nginx-deploymen
kubectl rollout resume deploy nginx-deployment

關於rollout/pasuse/回滾

rollout

.spec.strategy.rollingUpdate.maxSurge 能夠爲整數或者百分比,默認爲desired Pods數的25%
.spec.strategy.rollingUpdate.maxUnavailable 能夠爲整數或者百分比,默認爲desired Pods數的25%
在Deployment rollout時,須要保證Available(Ready) Pods數不低於 desired pods number - maxUnavailable; 保證全部的Pods數很少於 desired pods number + maxSurge。

rollout時,先建立maxSurge個Pods,這時達到pods數的上限值desired replicas + maxSurge,而後delete OldRS maxUnavailable個Pods,這時Ready的Pods number最差也能保證desired replicas - maxUnavailable個。直到刪除全部的pods。升級結束。

pasuse

kubectl rollout pause只會用來中止觸發下一次rollout。因此正在執行的滾動不會中止。可是下次滾動就會被暫停,直到用戶執行kubectl rollout resume

回滾

回滾的時候也是按照滾動的機制進行的,一樣要遵照maxSurge和maxUnavailable的約束。並非一次性將全部的Pods刪除,而後再一次性建立新的Pods。

和docker swarm選型

docker swarm優勢

  1. 跑的快,幾個命令部署應用
  2. 應用環境孤立,單獨運行。
  3. 版本控制和組件重用。
    缺點:
  4. 不提供存儲選項。 Docker Swarm不提供將容器鏈接到存儲的無障礙方式
  5. 監控不良 只能用Stats命令簡單的監控

Kubernetes優勢:

  1. 維護容器的穩定
  2. 大規模部署和更新軟件: 水平基礎架構縮放,自動擴展,手動縮放,複製控制器。
  3. 自我修復
  4. 存儲問題。pod間數據共享,能夠經過volume遠程存儲
    缺點
  5. 安裝繁瑣
  6. 初始過程須要時間,建立新進程須要等很長時間

Kubernetes:
須要成熟的部署和監控選項
須要快速可靠的響應時間
須要開發複雜的應用程序,而且須要高資源計算而不受限制
有一個很是大的集羣

Docker,
但願快速,方便的部署集羣
啓動速度快

參考

http://www.javashuo.com/article/p-cviahawv-dz.html
http://www.javashuo.com/article/p-nndfwuug-nb.html
k8s service詳解:https://zhuanlan.zhihu.com/p/39909011

相關文章
相關標籤/搜索