K8S生產環境中實踐高可靠的配置和技巧都有哪些？

K8S環境中實踐高可靠的配置和技巧都有哪些？

磁盤類型及大小

磁盤類型：

• 推薦使用ssd 磁盤
• 對於worker節點，建立集羣時推薦使用掛載數據盤。這個盤是專門給/var/lib/docker 存放本地鏡像。能夠避免後續因鏡像太多而形成磁盤根目錄容量不夠的狀況。在運行一段時間後，本地會存在不少無用的鏡像。比較快捷的方式就是，先下線這臺機器，從新構建這個磁盤，而後再上線。

磁盤大小：
kubernetes節點須要的磁盤空間也不小，Docker鏡像、系統日誌、應用日誌都保存在磁盤上。建立kubernetes集羣的時候，要考慮每一個節點上要部署的pod數量，每一個pod的日誌大小、鏡像大小、臨時數據，再加上系統預留的值。
kubernetes集羣中操做系統佔用3G左右的磁盤空間，建議預留8G左右的磁盤空間。剩餘空間考慮到給kubernetes資源對象使用。

是否當即構建worker節點

1. 構建節點考慮初始節點數量和後續增長的節點和證書問題。

網絡選擇

1. 若是須要鏈接外部的一些服務，如rds等，則須要考慮複用原有的VPC，而不是建立一個新的VPC。由於VPC間是隔離的，您能夠建立一個新的交換機，把kubernetes的機器都放在這個交換機網絡下，從而便於管理。
2. 在kubernetes集羣建立時，須要選定好網絡插件，後續若是須要更新網絡插件，或多或少都會對生產業務形成必定影響。當前主流的網絡插件有：calico、flannel和terway(阿里雲)
3. pod網絡cidr不能設置過小，若是過小，能夠支持的節點數量就會受限。這個值的設置須要和pod節點數量綜合考慮。例如：pod網絡cidr的網段是/16，那麼就會256*256個地址，若是每一個節點數量是128，則最多能夠支持512個節點。

使用多可用區

1. 阿里雲支持多地域，每一個地域下面又有不一樣的可用區。可用區是指在同一個地域內，店裏和網絡互相地理的物理區域。多可用區可以實現跨區域的容災能力。同時也會帶來額外的網絡時延。建立kubernetes集羣時，您能夠選擇建立多可用區kubernetes集羣。其實對於裸機部署來說，跨機房網絡只要3層可達既能夠。

聲明每一個pod的resource

在使用kubernetes集羣時，常常會遇到：在一個節點上調度了太多的pod，致使節點負載過高，無法正常對外提供服務的問題。
爲避免上述問題，在kubernetes中部署pod時，您能夠指定pod須要的request及limit的資源，kubernetes在部署這個pod時，就會根據pod的需求找到一個具備充足空閒資源的節點部署這個pod。下面例子中就聲明瞭nginx這個pod須要1核CPU，1024M內存，運行實際應用不能超過2核CPU和4096MB內存。
apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: nginx resources: # 資源聲明 requests: memory: "1024Mi" cpu: "1000m" limits: memory: "4096Mi" cpu: "2000m"
kubernetes採用靜態資源調度方式，對於每一個節點上的剩餘資源，是這樣計算的：節點剩餘資源=節點總資源-已經分配出去的資源，並非實際使用的資源。若是您本身手動裕興一個很耗資源的程序，kubernetes並不能感知到。
另外全部的pod上都要聲明resource。對於沒有聲明resource的pod，它被調度到某個節點後，kubernetes也不會在對應的節點上扣掉這個pod使用的資源。可能會致使節點上調度過去的太多的pod。

日誌和監控方向

1. 須要提早測試好是否配置elkF集羣來實現日誌的監控，實現以後對於每一個pod的日誌的存儲和採集，須要提早配置(包括動態新增pod和動態新增節點時是否可以自動採集日誌和存儲日誌)。
2. 須要提早測試prometheus監控和grafana圖形展現(動態新增pod節點監控和node監控)。

啓動時等待下游服務，不要直接退出

遊戲應用可能會有一些外部依賴，例如須要從數據庫(DB)讀取數據或者依賴另外一個服務的接口。應用啓動的時候，外部依賴尾部都能知足。手工運維的時候，一般採用依賴不知足當即退出的方式，也就是所謂的failfast，可是在kubernetes中，這種策略再也不適用。緣由在於kubernetes中多數運維操做是自動的，不須要人工接入，例如部署應用，您不用本身選擇節點，再到節點上啓動應用，應用fail，不用手動重啓，kubernetes會自動重啓應用。負載增高，還能夠經過HPA自動擴容。
針對啓動時依賴不知足這個場景，假設有兩個應用A和B，A依賴B，對A來講就是依賴不知足。若是A仍是按照傳統的方式直接退出，當B啓動以後，A也不會再啓動，必須人工介入處理才行。
kubernetes的最好的方式就是啓動時檢查依賴，若是不知足，輪訓等待，而不是直接退出。能夠經過Init Container(https://kubernetes.io/docs/concepts/workloads/pods/init-containers/?spm=a2c63.p38356.879954.9.79896be3WGvb05#what-can-init-containers-be-used-for)完成這個功能。

配置restart policy

pod運行過程當中進程退出是個很常見的問題，不管是代碼裏面的一個BUG，仍是佔用內存還多，都會致使應用進程退出，pod退出。您能夠在pod上配置restart Policy，都能實現pod掛掉以後在自動重啓。
apiVersion: v1 kind: Pod metadata: name: tomcat spec: containers: - name: tomcat image: tomcat restartPolicy: OnFailure #
restart Policy有三個可選值

• Always：老是自動重啓
• OnFailure：異常退出才自動重啓(進程退出狀態非0)
• Never：從不重啓

配置Liveness Probe和Readiness Probe

Pod處於running狀態和pod能正常提供服務是徹底不一樣的概念，一個running狀態的pod，裏面的進程可能發生了死鎖而沒法提供服務。可是由於pod仍是running的，kubernetes也不會自動重啓這個pod。全部咱們要在全部pod上配置liveness probe，探測pod是否真的存活，是否還能提供服務。若是liveness probe發現了問題，kubernetes會自動重啓pod。
readiness probe 用於探測pod是否是能夠對外提供服務。應用啓動過程當中須要一些時間完成初始化，在這個過程當中是無法對外提供服務的，經過readiness probe，能夠告訴ingress 或者service能不能把流量繼續轉發到這個pod上，當pod出現問題的時候，readiness probe可以避免新流量繼續轉發給這個pod。
apiVersion: v1 kind: Pod metadata: name: tomcat spec: containers: - name: tomcat image: tomcat livenessProbe: httpGet: path: /index.jsp port: 8080 initialDelaySeconds: 3 periodSeconds: 3 readinessProbe: httpGet: path: /index.jsp port: 8080

每一個進程一個容器

不少剛剛接觸容器的人按照舊習慣把容器當作虛擬機(VM)使用，在一個容器裏面放置多個進程：監控進程、日誌進程、sshd進程、甚至整個systemd。這樣操做存在兩個問題：
- 判斷pod總體的資源佔用會變複雜，不方便實施前面提到resource limit。
- 容器內只有一個進程的狀況，進程掛了，外面的容器引擎能夠清楚的感知到，而後重啓容器。若是容器內有多個進程，某個進程掛了，容器未必受影響，外部的容器引擎感知不到容器內有進程退出，也不會對容器作任何的操做，可是實際上容器已經不能正常工做了。
若是有好幾個進程須要進行協同工做，在kubernetes裏也能夠實現，例如nginx和php-fpm，經過unix domain socket通訊，咱們能夠用一個包含兩個容器的pod，unix socker放在兩個容器的共享volume中。

確保不存在SPOF(Single Point of Failure)

若是應用只有一個示例，當實例失敗的時候，雖然kubernetes可以重啓實例，可是中間不可避免的存在一段時間的不可用。甚至更新應用，發佈一個新版本的時候，也會出現這種狀況。在kubernetes裏，儘可能避免直接使用pod，儘量的使用deployment/Statefulset,而且讓應用至少有兩個pod以上。