K8S環境中實踐高可靠的配置和技巧都有哪些？
磁盤類型及大小
磁盤類型：
- 推薦使用ssd 磁盤
- 對於worker節點，創建集群時推薦使用掛載數據盤。這個盤是專門給/var/lib/docker 存放本地鏡像。可以避免后續因鏡像太多而造成磁盤根目錄容量不夠的情況。在運行一段時間后，本地會存在很多無用的鏡像。比較快捷的方式就是，先下線這台機器，重新構建這個磁盤，然后再上線。
磁盤大小：
kubernetes節點需要的磁盤空間也不小，Docker鏡像、系統日志、應用日志都保存在磁盤上。創建kubernetes集群的時候，要考慮每個節點上要部署的pod數量，每個pod的日志大小、鏡像大小、臨時數據，再加上系統預留的值。
kubernetes集群中操作系統占用3G左右的磁盤空間，建議預留8G左右的磁盤空間。剩余空間考慮到給kubernetes資源對象使用。
是否立即構建worker節點
- 構建節點考慮初始節點數量和后續增加的節點和證書問題。
網絡選擇
- 如果需要連接外部的一些服務，如rds等，則需要考慮復用原有的VPC，而不是創建一個新的VPC。因為VPC間是隔離的，您可以創建一個新的交換機，把kubernetes的機器都放在這個交換機網絡下，從而便於管理。
- 在kubernetes集群創建時，需要選定好網絡插件，后續如果需要更新網絡插件，或多或少都會對生產業務造成一定影響。當前主流的網絡插件有：calico、flannel和terway(阿里雲)
- pod網絡cidr不能設置太小，如果太小，可以支持的節點數量就會受限。這個值的設置需要和pod節點數量綜合考慮。例如：pod網絡cidr的網段是/16，那么就會256*256個地址，如果每個節點數量是128，則最多可以支持512個節點。
使用多可用區
- 阿里雲支持多地域，每個地域下面又有不同的可用區。可用區是指在同一個地域內，店里和網絡互相地理的物理區域。多可用區能夠實現跨區域的容災能力。同時也會帶來額外的網絡時延。創建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。
日志和監控方向
- 需要提前測試好是否配置elkF集群來實現日志的監控，實現之后對於每個pod的日志的存儲和采集，需要提前配置(包括動態新增pod和動態新增節點時是否能夠自動采集日志和存儲日志)。
- 需要提前測試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以上。