28個SpringBoot項目中常用注解，日常開發、求職面試不再懵圈
前言在使用SpringBoot開發中或者在求職面試中都會使用到很多注解或者問到注解相關的知識。本文主要對一些常用的注解進行了總結，同時也會舉出具體例子，供大家學習和參考。注解
容器作為一種新的資源類型，已經應用于各大公司，G行也不例外。容器的輕量化特性使得它能夠在故障發生時快速進行重建，將對業務的影響降到最低，我們通常稱它為自愈。在Kubernetes中，自動重建的邏輯是什么？為什么我們經常說到Pod自愈而不是容器自愈？如何判定Pod狀態，Pod都有什么狀態？重啟策略都有什么，是什么推動重啟？對于不同的重啟資源需求，G行如何實現？下文將一一講述。
圖1 Kubernetes架構
談到容器自愈，為什么說是通過Pod自愈實現的呢？Pod是一組（一個或多個）容器，這些容器共享Pod的存儲、網絡、以及運行容器的聲明。且Pod是K8s（即Kubernetes）的最小部署管理計算單元。K8s是CNCF（Cloud Native Computing Foundation）的畢業項目之一，是目前市場使用最廣泛的自動化部署、擴展和管理成千上萬容器化應用程序的開源系統，也是G行采用的容器管理工具。Pod運行在被稱作是Node的節點中，節點既可以是物理機，也可以是虛擬機。當K8s判定Pod出現問題且需要被殺死的時候，會在運轉正常且資源充足的Node節點重建完成，從而完成自愈。
圖2 CNCF的畢業項目和孵化中的項目
應用程序可能因多種原因而變得不可靠，例如：暫時失聯、配置錯誤、應用程序錯誤、硬件故障、資源緊張等。那么如何檢測運行著應用程序的pod健康狀態是好還是壞呢，K8s是通過探針來檢查的，探針有三種：ReadinessProbe、StartupProbe及LivenessProbe。
ReadinessProbe（就緒）探針：用于判斷容器服務是否可用（即是否為ready狀態），只有Ready狀態的Pod才可以接收服務請求。
StartupProbe（啟動）探針：適用于應用程序啟動緩慢、網絡訪問延遲等場景，相應造成容器啟動緩慢的情況。
LivenessProbe（存活）探針：用于判斷容器是否存活①（即是否為running狀態），如果探針檢測到容器不健康，則Kubelet將殺死這個容器，并根據容器的重啟策略（重啟策略后面會說）做相應的處理。
G行通過同時使用ReadinessProbe（就緒）探針和LivenessProbe（存活）探針來判定Pod的狀態。
K8s提供了5個控制這些探針的選項：
圖片
而這三種探針均可以通過以下三種方式②實現：
通過容器的IP地址、端口號及路徑調用http get方法，如果相應的狀態碼大于等于200且小于400，則認定容器是健康狀態。
通過容器的IP地址和端口號執行tcp檢查，如果能夠建立tcp連接，則表明容器健康。
在容器內部運行一個命令，如果返回碼為0，則表示容器健康，否則表示不健康。
G行使用HTTPGetAction和TCPSocketAction兩種方式查看連接情況。
運維人員可以使用Kubectl命令行客戶端或Yaml部署模板來配置探針和IP地址、端口號、路徑連接方式。下面是以LivenessProbe探針、HTTPGetAction連接方式為例，編寫的Yaml文件：
圖片
知道如何檢查Pod的健康狀態了，如果不健康，該如何進行重啟呢？這里就需要說到Pod的重啟策略（restartPolicy）了。
重啟策略應用于Pod內的所有容器，由Pod所處的Node上的Kubelet進行判斷和重啟操作。當某個容器異常退出或者健康檢查失敗時，Kubelet會根據重啟策略的設置進行相應的操作。
Pod的重啟策略有Always、OnFailure、Never三種，Default為Always。
Always：當容器失效時，由Kubelet自動重啟該容器
OnFailure：當容器終止運行且退出碼不為0時，由Kubelet自動重啟該容器。
Never：不論容器運行狀態如何，Kubelet都不會重啟該容器。
圖3 示例Pod在G行Prometheus的可視化平臺Grafana上的重啟情況，紅線為閾值
重啟策略明確了，那么是靠誰來完成重啟的呢？是靠控制器來實現的。
在講述控制器之前，先考慮這樣一個場景：Pod沒有副本，如果這個Pod出現問題，上面跑的容器應用也就無法運轉了，服務也就中斷了。所以在K8s中，在創Pod之初，就是以多副本的形式創建的。這種負責Pod副本的創建、Pod重啟、調度及全生命周期自動控制的組件叫做控制器（也叫工作負載，即workload）。
控制器根據不同的功能分為Replicaset與Deployment、 DaemonSet、StatefulSet、Job和Cronjob幾種。這幾種控制器G行都有使用，并且在G行自建的容器統一管理平臺進行了部署。這個平臺融合管理了云上所有的應用相關容器資源，提高了運維效率。
圖4 G行容器統一管理平臺登錄首頁
圖片
圖5 Deployment控制器下兩種Pod滾動升級方式，分別是Recreate和Rolling update，各適用于大版本和小版本
ReplicaSet（簡稱rs）是Replication Controller的升級版，是副本集的意思，用于保證K8s集群中有指定數量的Pods副本在運行③。一般不單獨使用，而是作為Deployment理想狀態的參數使用。且擁有集合式的標簽選擇器，可以選擇多個標簽。
Deployment被稱作是副本控制集（即rs）的控制器，通過為應用程序創建一個或多個rs以管理應用程序的多個版本。通過每個副本控制集（rs）的模板和副本保持的能力來管理無狀態應用的工作負載（應用程序集群），比如web集群。
圖6 展示了DaemonSet這種類型的控制器的Pods部署
DaemonSet是特殊類型的Deployment，在集群中的全部或者部分節點上，每個節點上有且僅有一份Pod的副本資源在運行。比如系統的監控、日志的收集、分布式存儲、網絡的代理等，都需要每個成員節點上有且只有一個Pod。例如：每個Node上只需要運行一個日志采集程序Logstach，或者只運行一個性能監控程序Prometheus Node Exporter。
而且后續加入集群的新的節點也會自動創建一個相同的Pod對象。管理員也可以使用Nodeselector（節點選擇器）配合節點Label指定僅在部分具有特定特征的節點上運行指定的Pod對象。
圖7 有狀態集在一個Pod故障被殺死，并重建新Pod的情況
用來管理有狀態應用的工作負載（應用程序集群），管理Pods集合的部署和伸縮，并為這些Pods提供持久存儲和持久標識符。與Depolyment類似，Statefulset管理基于相同容器模板的一組Pods。但與Depolyment不同的是，Statefulset為每個Pod維護了一個有粘性的ID。這些Pods是基于相同的模板，但是不能相互替換，即無論怎么調度，每個Pod都有一個永久不變的ID。
圖8 Job和Cronjob在完成工作后回收算力的場景展示
Job是用來定義并啟動一個批處理任務，是單次性作業控制器。這任務通常并行或者串行啟動多個計算進程去處理一批工作項，即work item，工作項處理完成后，整個批處理任務結束。比如Hadoop的離線數據處理、視頻解碼、或者HPC業務等，都需要很多個節點提供一個集中式的大算力。與傳統算力相比，Job控制器能在保留結果的同時，快速回收算力，因為一個Job完成后，就會立即殺死使用的Pod。
Cronjob控制器用于周期性調度Job控制器。傳統環境使用的一般用到的是7*24小時不間斷的備份服務器，現在可以使用Cronjob控制器周期性的起一個Job作業，做完后，保留結果，殺死Pod，回收算力。Cronjob基本照搬了Linux操作系統的周期性任務Crontab，用minutes、hours、dayofmonth、month、dayofweek來進行定義。
需要注意，一些控制器對Pod的重啟策略要求，G行也是按如下執行的：
Replicaset或者DaemonSet：必須設置為always，需要保證該容器持續運行。
Job：onFailure或Never，確保容器執行完成后不再重啟。
Pod對Node有特定要求的場景：
Node節點的配置是多種類型的，比如有的安裝了SSD磁盤，有的沒有。有的是AMD64的，有的是AMD32的。如果想著把新建的Pod運行在AMD64的Node上，該怎么做呢。下面是Pod的Yaml配置：
圖片
Pod之間相互依存或者互斥的場景：
現在想新建這么兩個Pod，有互相依存關系，需要放到同一個Region內，該如何實現呢。像這種互為親和或者互斥關系的Pod是通過在Yaml文件中增加TopologyKey屬性，來聲明目標拓撲內的Pod是否在一起的。下面是一個親和的例子，目標Pod的標簽值是APP：”Nginx”。親和Pod的標簽值也是一樣。增加的TopologyKey值為topology.kubernetes.io/region，意味著這兩個Pod給配置到了同一個Region下。
圖片
這些相互依賴或者相互之間頻繁調用的Pod，需要盡可能的部署在同一個Zone、機房、機架、Node節點。反之，就需要讓這些Pod盡可能的互相遠離。簡而言之，就是Pod之間在同一個拓撲域中共存或互斥。拓撲域指由相同地理空間中的幾個Node節點組成。
一些常規的拓撲域有：
kubernetes.io/hostname；topology.kubernetes.io/region；topology.kubernetes.io/zone。
在企業實際在使用容器這類資源的時候，除了技術本身，要考慮的其他問題也會很多。企業管理的容器有千千萬萬，出于效率考慮，對于有特殊需求的容器如何進行批量創建和管理呢，這就需要在統一管理平臺按照相應的模板進行創建與維護。在Pod進行重建后，如何保證客戶端應用屏蔽這些Pod IP地址的變化及數量的變化呢，這就需要通過定義Pod上層的Service進行保障。不同的應用系統有自身的架構特點，在進行控制器配置的時候如何進行考量呢，需要選擇哪種控制器呢，這就需要進行交付前的資源配置梳理。等等問題?？傊?，在考慮到基本的技術特性的同時，再應用系統自身特點相結合，才能夠將技術的最大價值加以發揮。
① 容器的狀態一共有五個：created（已創建）、running（運行中）、paused（暫停）、exited（停止）、dead（死亡）、restarted（重啟中）、removing（遷移中）。
②每種探測方式，還需要額外設置initialDelaySeconds和timeoutSeconds這兩個參數。initialDelaySeconds表示容器啟動后進行首次健康檢查的等待時間，單位是秒。timeoutSeconds表示健康檢查請求發送后等待響應的超時時間，單位是秒。如果超時，則Kubelet認為容器無法提供服務，會重啟該容器。
③例如：Pod所在節點發生宕機，K8s就會第一時間觀察到這個故障，并自動創建一個新Pod對象，將其調度到其他合適的節點上，K8s會實時監控集群中目標Pod的副本數量，并盡力與Deployment中聲明的Replicas數量保持一致。
本文鏈接：http://www.www897cc.com/showinfo-26-70459-0.html我們一起聊聊容器資源自愈
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號