二十，基於K8S集羣的PaaS簡介

[TOC]

1、概述

　　一、經過以往的學習應該能夠了解到k8s 和以往提到的devops概念更容易落地了。好比咱們說的CI,CD,CD

​ CI（Continuous Integration）：持續集成

　　　 CD（）：持續交付

　　　 CD（Continuous Deployment）：持續部署

　　二、早期做爲運維手工來實現發佈和部署來說咱們一週發佈一次就很頭疼了，若是是持續部署的話一天可能要部署好幾回甚至幾十次。即當咱們應用程序的程序員寫完代碼之後從本地推送到gitlab或者github之上，然後由對應的監控工具資源監視着事件的發生，一旦發生提交了新代碼就自動的去作某些操做，好比用一些所謂的CI的工具從倉庫中拖下來後作靜態檢查，作預部署的測試，測試完後沒問題了就開始打包，打包後就發給測試，由測試部署到測試環境中，這時候就須要部署了，有些是不用部署就能測試，有些是須要部署到測試環境中來實如今線測試。因此咱們作一些部署後測試。所以就有這些步驟。

　　三、一共大概有以下步驟：首先推送代碼到倉庫。而後使用CI或CD工具把代碼拖下來作靜態分析。而後作一些部署前測試，即不用打包就能夠作的測試。好比掃描一下代碼的完整性等等。而後就開始打包發給QA，由QA手動或自動部署到QA環境中。而後作部署後測試，若是沒問題就能夠發給咱們的相關的安裝部署人員，就能夠交付給咱們的生產環境中的運維工程師開始發佈到線上去了。因此這個時候若是從開始代碼推送到後面的靜態分析，打包前測試，打包後測試都是自動就稱之爲CI，若是隨後交付給運維工程師這個過程也能經過一些工具自動實現咱們一般就稱之爲CD。運維工程師拿到後就開始發佈，好比灰度，藍綠，金絲雀等，發佈上去之後若是沒問題就能夠跑起來了。即若是連部署也能自動執行，好比他們交付完之後由咱們的發佈系統自動實現將新版本經過灰度或金絲雀或藍綠的方式發佈到線上去這種方式咱們就稱之爲CD即持續部署。這些動做到今天爲止每一步均可以使用工具來實現，好比像版本控制系統，svn，vcs,git等。另外就是一些持續集成工具，好比像jenkins等。另外其還須要構建工具去實現咱們代碼的構建，包括編譯，打包等，好比咱們的make,cmake,maven,ant等。打包後的測試咱們就須要相應的測試套件來實現，好比咱們的單元測試，系統測試，迴歸測試等等。

　　四、若是咱們要結合咱們k8s環境作一套CI CD的環境的話大概以下圖。咱們的研發人員push代碼到git，而後咱們使用jenkins用於作CI整合工具來作構建測試等，沒問題後就生成應用程序而後將應用程序打包成docker鏡像。而後推到docker registry即harbor上，而後就能夠被k8s從中拖下來進行部署了。若是咱們把這一整套流程集中起來能用一個一整套的自動化功能來完成的話那就是所謂的CD即持續部署。咱們從推送代碼到git倉庫上而後用jenkins自動把其pull下來進行構建，構建完了之後他就是一個應用程序包了，而後咱們接下來讓想辦法給其生成dockerfile，只有結合dockerfile和application 才能build成鏡像文件。第二步，咱們開發人員還要開發第二套組件，即爲咱們的應用程序寫一個配套的dockerfile，dockerfile開發完成後須要Push到另一套git倉庫上，當咱們提供完之後把應用程序構建完告終合dockerfile利用docker build把對應的dockerfile拖下來，應用程序也有了，可直接打包爲docker鏡像。打包完之後咱們給其推送到harbor上去就完了。咱們要想把應用程序部署到k8s之上k8s怎麼才能完成部署呢？所以咱們要有配置清單，若是咱們寫好了配置清單，好比寫了helm，咱們把其定義成chart，把應用程序打包成鏡像之後咱們再開發好一個chart模板放在那裏，這個chart不變，在傳遞時把chart版本換上就好了。或者把鏡像文件版本換了就行。![img]

　　五、還有一種簡單的方式，咱們程序員也能夠寫好咱們的manifests，部署時這個manifests模板用ansible或者用其它工具或Go，此處他要作的有兩重做用，第一，作模板引擎渲染，即把模板中那些代碼替換成他應該替換的對應的值，好比咱們這個manifests爲了可以作到部署多種不一樣的應用程序，好比我這裏推到一個dockerfile中鏡像標籤什麼的都換了，所以咱們把這個信息結合manifests和ansible模板引擎對manifests完成渲染然後就能夠用ansible再指揮着咱們k8s拖鏡像來更新了。這個過程一系列文件都要準備好，然後纔會觸發這些組件自動工做，而咱們ansible去渲染咱們manifests這個組件可能不會，默認他本身都作不了。若是能夠的話能夠把此段結合python 實現CI CD進行發佈。

2、生產環境部署k8s，接下來咱們描述一下在真正生產環境中咱們部署k8s應該部署成什麼樣子

　　一、咱們要部署k8s要麼是在裸機上要麼是在虛擬機或公有云私有云等都是支持的。這就是基礎架構（Core Infrastructure），在基礎架構上咱們要有網絡工程師幫咱們去部署好基礎網絡環境和存儲工程師幫咱們部署好存儲環境(Network和Storage)，通常來講這種架構不會讓咱們一我的去部署。在有了基礎環境和網絡環境之上咱們就能夠構建咱們的k8s了。有了k8s集羣以後咱們還須要一個容器化的工做流系統。即確保咱們的工做負載能運行起來。即有一個正常的容器運行環境(Containized Worload)。可是無論怎麼講這一套環境中咱們還須要用到另外的兩個服務。好比鏡像服務(images registry)。另外爲了管理咱們的集羣，咱們還須要編排服務(provisioning Configuration)。接着對整個集羣來說咱們都須要作監控，都要記錄日誌，即還須要監控系統((monitoring))和日誌系統(logging)。若是能夠的話k8s服務發佈後還要有外置的負載均衡器(Load balancer)。另外咱們還須要公建倉庫(Artifact factory)。另外咱們還須要自動化工具(Build Automation)。而且還有自動化發佈工具(Rlease Automation )等。若是這個一整套環境組合完成了叫Paas，即平臺即服務的環境。Openshit就是這一整套的解決方案。

　　　

　　二、PaaS實際生產使用時的注意事項，本k8s集羣學習博客未進行記錄的知識點，後續需進行深刻了解

​ master 節點高可用

​ kubernetes Federation (k8s集羣聯合，相似於雙機房效果，經過Federation Api進行聯合 )

​ priorityClass 優先級類別，定義哪些pod應該優先被啓動等

​ limitRange 資源限制範圍

​ PSP ：pod 安全策略

​ SecurityContext 安全上下文