開發者應該瞭解Kubernetes對於程序的影響點

摘要： 主要介紹開發者對於程序上kubernetes須要注意的點

開發者是否要了解Kuberntes呢？

如今Kubernters愈來愈熱了，不少公司都在開發、測試以及生產上逐步使用上了Kubernetes做爲容器集羣管理平臺。最新調查顯示，在5000+的大型企業中，有超過40%的生產環境已經使用上Kubernetes(*)。可是通常的理解，Kubernetes是更偏運維類的系統，開發彷佛不用太關注，是不是這樣？答案是否認的！

雖說，多數開發者能夠不用改動原有應用就能夠把這些應用遷移/搬移到容器平臺裏（這裏用「搬移」意思是，更多的是使用者把容器直接做爲虛機對待），可是若是須要更好的使用Kubernetes，則開發者須要理解kubernetes的一些架構以及原理，並對程序架構以及一些實現細節做出調整。本文從一些細節上解釋一下程序須要作出的適配點，以更好的把程序運行到Kuberentes上。

處理好IP無關性/動態性

在程序中，要作到把程序間的相互調用作到不寫死IP，並且要能適配容器的IP的漂移。要作到IP無關性，能夠經過如下幾個方式：

1. 經過微服務的服務註冊與發現的方式來獲取對端IP。注意這個是容器IP，通常在集羣外是不可見的。若是還有Kubernetes集羣外的應用，要直接訪問POD(特別是Springcloud類應用混布)，則須要考慮網絡模型的問題。在阿里雲裏，提供了Terway的網絡模式，利用了彈性網卡技術(ENI)能夠直接支持ECS與POD的互通，很好的支持程序往容器化演進。

(terway已經開源https://github.com/AliyunCont...，求star)

1. 經過Kubernetes的SLB Service或者Ingress的方式訪問POD。特別是對於傳統非改造的的應用直接搬遷，須要使用這個模式。由於SLB/Ingress的對外IP是固定。若是是集羣中訪問，則使用service的域名方式訪問更好。

處理好程序的外部配置

一般，原有的程序都是將相關配置寫到本地配置文件的。到了容器特別是Kubernetes後，這個方式務必改變，由於程序的啓動過程已經沒法人爲干預，同時須要能適配支持程序實例的伸縮，而不是固定將程序設計成固定的實例數。

充分利用Kubernetes的configmap/secret

對於啓動時的配置以及環境變量配置，儘量配置到configmap以及secret中。這裏須要注意的是，configmap/secret的改動是沒法改變已經運行的容器的環境變量。若是是經過volume方式使用，則對應的文件在不肯定時間時在已有的程序中生效。因此對於configmap/secret的使用，後續的變動都要經過rolling upgrade的方式使其新配置生效

利用配置中心

對於運行態的配置變動，須要利用微服務體系中的配置中心的概念來處理，須要其更好支持如下核心特性：

• 必須支持動態推送

• 必須支持版本管理

• 必須支持容錯和恢復

• 支持安全通訊

在阿里雲上能夠無償使用配置中心：ACM，其已經很好的提供了以上特性。而且其已經開源出來，叫NACOS(https://nacos.io)

理解好程序的啓動過程和啓動時間

雖然不少時候咱們聽到容器的宣傳是「秒級」啓動，可是對於程序如何在容器/Kubernetes裏啓動，是須要程序有明確的認識的。

這裏須要特別注意的是：「秒級啓動」不能等同於「秒級可用」。由於程序在容器的啓動過程大致以下：

這裏標示的時間級別以一個普通tomcat業務程序爲例（例如其須要鏈接mysql等）

因此開發者須要考慮這個過程對於程序的影響

利用好Kubernetes的健康檢查雙保險

以往健康檢查的概念是作health check，可是到Kubernetes則變爲了兩重的檢查，分別爲：liveness和readiness，爲何呢？從上面的程序啓動過程能夠看見，容器啓動並不表明程序已經能夠被訪問，特別是對於java類程序，還有springboot/tomcat等的啓動過程，這個過程也是比較費時的。若是在這個時候去訪問程序則是很容易timeout的。

• Liveness: 確保應用還存活，否則Kubernetes就會重啓這個POD

• Liveness prob合理設置initialDelaySeconds值，避免不斷重啓POD(考慮使用99%的最大延遲最爲配置值比較合適)

• Readiness: 確保應用已經能夠接收流量了，否則不會分發流量給他，常見問題如：首次訪問超時

• 用於檢查的三種類型探針：http, cmd, tcp，能夠根據程序狀況使用

基於這個設計原則，程序須要考慮提供兩個被檢查的接口。一個即刻歐用於判斷程序是否存活，例如直接返回http 200。一個接口用於判斷程序是否能正常處理請求，特別是對於程序依賴鏈接數據庫、redis等外資源才能提供服務，則這個接口須要去檢查這些外部資源是否可使用。這兩個接口是明確的含義，千萬別用反了。

小結

對於IT系統架構愈來愈複雜的愈來愈智能的今天，開發者已經能夠把更多的精力放在了業務開發上，可是從架構設計上，仍是須要對Kubernetes有個深入的認識，以避免違背Kubernetes的設計原則。

本文做者：了哥-duff

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。