“?[LOG] ASP.NET Core on K8S Starting...”

在上一篇《單節(jié)點環(huán)境搭建》中，通過Docker for Windows在Windows開發(fā)機中搭建了一個單節(jié)點的K8S環(huán)境，接下來就是動人心弦的部署ASP.NET Core API到K8S了。但是，在部署之前，我還是把基本的一些概念快速地簡單地不求甚解地過一下。

01

—

K8S集群相關概念

?????

???? （1）集群

　　首先，K8S集群也是需要多臺服務器組成，作為容器的編排管理平臺，只有一個節(jié)點在生產(chǎn)環(huán)境是不夠的。

　　（2）Node

　　其次，Node作為K8S集群中的工作節(jié)點，一個Node可以是VM或物理機，它運行真正的應用程序。

　　K8S中的Node又分為Master和Worker，和Hadoop集群中的NameNode和DataNode類似，簡而言之就是一個是負責調(diào)度（維護集群狀態(tài)）的，一個是負責干活（運行容器）的。

　　（3）資源

　　在K8S每個組件（比如Pod，Service等）開放對外暴露的都是一組RESTful API，所以我們所有對于組件的操作都可以通過RESTful API來完成，因此我們可以將其看作是資源。

　　（4）Kubectl

　　Kubectl是一個客戶端命令行工具，使用它可以連接K8S集群和進行交互。

　　如下圖所示，我們通過kubectl輸入命令與遠程的K8S集群連接，而這些命令本質(zhì)是通過調(diào)用API訪問Master節(jié)點提供的API，通過這些API去操作所謂的集群中的“資源”，對這些資源進行創(chuàng)建（POST），修改（PUT），刪除（DELETE）等操作。

02

—

三大核心對象

???? （1）Pod

　　Pod是K8S最基本的操作單元，包含一個或多個緊密相關的容器，一個Pod可以被一個容器化的環(huán)境看作是應用層的“邏輯宿主機”；

　　換句話說，在K8S中創(chuàng)建，調(diào)度和管理的最小單位就是Pod，而非容器（Container），多個容器之間的掛載是可以共享的，Pod通過提供更高層次的抽象，提供了更加靈活的部署和管理模式；

　　（2）Service

　　Service是一個抽象概念，它定義了邏輯集合下訪問Pod組的策略。通過使用Service，我們就可以不用關心這個服務下面的Pod的增加和減少、故障重啟等，只需通過Service就能夠訪問到對應服務的容器，即通過Service來暴露Pod的資源。

　　這樣說可能還是有點難懂，舉個例子，假設我們的一個服務Service A下面有3個Pod，我們都知道Pod的IP都不是持久化的，重啟之后就會有變化。那么Service B想要訪問Service A的Pod，它只需跟綁定了這3個Pod的Service A打交道就可以了，無須關心下面的3個Pod的IP和端口等信息的變化。換句話說，就像一個Service Discovery服務發(fā)現(xiàn)的組件，你無須關心具體服務的URL，只需知道它們在服務發(fā)現(xiàn)中注冊的Key就可以通過類似Consul、Eureka之類的服務發(fā)現(xiàn)組件中獲取它們的URL一樣，還是實現(xiàn)了負載均衡效果的URL。

　　（3）Deployment

　　Deployment主要負責Pod的編排，例如我們可以使用下面的yaml文件來創(chuàng)建一個Deployment：

apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.12.2 ports: - containerPort: 80

　　熟悉Docker-Compose的朋友應該對這個yaml不陌生，可以看到Deployment定義了Pod內(nèi)容，包括Pod數(shù)量、更新方式、使用的鏡像，資源限制，容器中的映射端口等等。

03

—

Service的幾種類型

???? （1）ClusterIP

?　　ClusterIP 服務是 Kubernetes 的默認服務。它給你一個集群內(nèi)的服務，集群內(nèi)的其它應用都可以訪問該服務，但是集群外部無法訪問它。

　　因此，這種服務常被用于內(nèi)部程序互相的訪問，且不需要外部訪問，那么這個時候用ClusterIP就比較合適，如下面的yaml文件所示：

apiVersion: v1 kind: Service metadata: name: my-internal-service selector: app: my-app spec: type: ClusterIP ports: - name: http port: 80 targetPort: 80 protocol: TCP

　　那么，如果需要從外部訪問呢（比如我們在開發(fā)模式下總得調(diào)試吧）？可以啟用K8S的代理模式：

$ kubectl proxy --port=8080

　　如此一來，便可以通過K8S的API來訪問了，例如下面這個URL就可以訪問在yaml中定義的這個my-internal-service了：

http://localhost:8080/api/v1/proxy/namespaces/default/services/my-internal-service:http/

　　（2）NodePort

?　　除了只在內(nèi)部訪問的服務，我們總有很多是需要暴露出來公開訪問的服務吧。在ClusterIP基礎上為Service在每臺機器上綁定一個端口，這樣就可以通過<NodeIP>:NodePort來訪問這些服務。例如，下面這個yaml中定義了服務為NodePort類型：

apiVersion: v1 kind: Service metadata: name: my-nodeport-service selector: app: my-app spec: type: NodePort ports: - name: http port: 80 targetPort: 80 nodePort: 30036 protocol: TCP

PS：這種方式顧名思義需要一個額外的端口來進行暴露，且端口范圍只能是 30000-32767，如果節(jié)點/VM 的 IP 地址發(fā)生變化，你需要能處理這種情況。

　　（3）LoadBalancer

?　　LoadBalancer 服務是暴露服務到 internet 的標準方式，它借助Cloud Provider創(chuàng)建一個外部的負載均衡器，并將請求轉發(fā)到<NodeIP>:NodePort（向節(jié)點導流）。

　　例如下面這個yaml中，定義type為LoadBalancer：

kind: Service apiVersion: v1 metadata: name: my-service spec: selector: app: MyApp ports: - protocol: TCP port: 80 targetPort: 9376 clusterIP: 10.0.171.239 loadBalancerIP: 78.11.24.19 type: LoadBalancer status: loadBalancer: ingress: - ip: 146.148.47.155PS：每一個用 LoadBalancer 暴露的服務都會有它自己的 IP 地址，每個用到的 LoadBalancer 都需要付費，這將是比較昂貴的花費。

04

—

小結

????????本文主要快速地不完全地不求甚解地過了一下K8S中的一些重要的基本概念，目的是為下一篇部署ASP.NET Core API到K8S有一個必要的認知。

參考資料

總結

以上是生活随笔為你收集整理的ASP.NET Core on K8S学习初探（2）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。