最近完成了基於k8s的springcloud搭建，記錄下過程。
K8S的組件介紹
Pod
一個Pod是一組容器的集合,它們共享網絡,我們的微服務注冊中心是Consul,微服務的容器和Consul客戶端的容器組成了一個Pod.這樣微服務訪問Consul客戶端就像訪問本地一樣了.使用localhost就可以訪問到Consul.然后Consul客戶端再和服務端通信.
Service
Service是Pod提供的服務的抽象,因為K8S的Pod的容器是不穩定的,可能會掛掉,這種情況下，K8S就會為我們重新啟動POD，維持着指定的狀態。Pod里的容器分配的IP是不同的，這就需要通過Service給不同的服務的IP綁定到一個Service名字上，以后通過Servie就能解析出對應的Pod的IP。在同一個K8S集群中，Service的name還充當着DNS-Name，需要在Pod-A里訪問另一個Service里的Pod-B時（比如應用需要訪問另一個Service提供的Redis的服務），使用Servie name就可以解析出名字。
Deployment
Deployment控制RS，RS控制Pod，這一整套，向外提供穩定可靠的Service。至於什么是RS，筆者目前還沒有深入了解，項目中這個概念也比較淡化，先擱置了。
ConfigMap
ConfigMap可以把配置或者配置文件掛載到容器中，生命周期和Pod獨立
PersistVolume（PV）和PersisteVolumeClaim(PVC)
k8s中的存儲系統，生命周期和容器獨立的存儲。可以聲明把pvc掛載到容器的某一個目錄。pv是由集群管理員管理的，我們不用管。
Ingress
Ingress主要負責路由。項目由於是前后端分離，所有的請求都要先經過nginx，所以Ingress這一層需要先把所有請求都轉發到nginx。有沒有更好的路由方式筆者還不知道，需要繼續學習。
Nginx
請求轉發到Nginx之后，Nginx繼續對請求進行轉發：如果請求的是頁面，css，html這些靜態資源，就直接在nginx服務器中訪問；如果要訪問RestApi，就對請求進行轉發，轉發到Spring cloud gateway里。
這里要注意的地方是localtion的配置，請求api需要在location那里加上proxy_pass ，server_name配置的是nginx的service的name。
這里我們對proxy_pass的location設計是使用了/webapi這個來進行動靜分離。
Spring cloud gateway
微服務的網關接到來自nginx的請求，會根據網關的application.yml中配置的轉發規則進行轉發。對/webapi開頭的，會使用 -StripPrefix=1的fitler，這樣網關轉發到微服務的時候就會把/webapi去掉