本篇已加入《.NET Core on K8S學習實踐系列文章索引》，可以點擊查看更多容器化技術相關系列文章。
在上一篇《單節點環境搭建》中，通過Docker for Windows在Windows開發機中搭建了一個單節點的K8S環境，接下來就是動人心弦的部署ASP.NET Core API到K8S了。但是，在部署之前，我還是把基本的一些概念快速地簡單地不求甚解地過一下。
Section 1 - ASP.NET Core on K8S學習初探（1）K8S單節點環境搭建
Section 2 - ASP.NET Core on K8S學習初探（2）K8S基本概念快速一覽
Section 3 - ASP.NET Core on K8S學習初探（3）部署API到K8S
一、K8S集群基本概念
（1）集群
首先，K8S集群也是需要多台服務器組成，作為容器的編排管理平台，只有一個節點在生產環境是不夠的。
（2）Node
其次，Node作為K8S集群中的工作節點，一個Node可以是VM或物理機，它運行真正的應用程序。
K8S中的Node又分為Master和Worker，和Hadoop集群中的NameNode和DataNode類似，簡而言之就是一個是負責調度（維護集群狀態）的，一個是負責干活（運行容器）的。
（3）資源
在K8S每個組件（比如Pod，Service等）開放對外暴露的都是一組RESTful API，所以我們所有對於組件的操作都可以通過RESTful API來完成，因此我們可以將其看作是資源。
（4）Kubectl
Kubectl是一個客戶端命令行工具，使用它可以連接K8S集群和進行交互。
如下圖所示，我們通過kubectl輸入命令與遠程的K8S集群連接，而這些命令本質是通過調用API訪問Master節點提供的API，通過這些API去操作所謂的集群中的“資源”，對這些資源進行創建（POST），修改（PUT），刪除（DELETE）等操作。
二、三大核心對象
（1）Pod
Pod是K8S最基本的操作單元，包含一個或多個緊密相關的容器，一個Pod可以被一個容器化的環境看作是應用層的“邏輯宿主機”；
換句話說，在K8S中創建，調度和管理的最小單位就是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服務發現的組件，你無須關心具體服務的URL，只需知道它們在服務發現中注冊的Key就可以通過類似Consul、Eureka之類的服務發現組件中獲取它們的URL一樣，還是實現了負載均衡效果的URL。
（3）Deployment
Deployment主要負責Pod的編排，例如我們可以使用下面的yaml文件來創建一個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內容，包括Pod數量、更新方式、使用的鏡像，資源限制，容器中的映射端口等等。
三、Service的幾種類型
（1）ClusterIP
ClusterIP 服務是 Kubernetes 的默認服務。它給你一個集群內的服務，集群內的其它應用都可以訪問該服務，但是集群外部無法訪問它。
因此，這種服務常被用於內部程序互相的訪問，且不需要外部訪問，那么這個時候用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
那么，如果需要從外部訪問呢（比如我們在開發模式下總得調試吧）？可以啟用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
除了只在內部訪問的服務，我們總有很多是需要暴露出來公開訪問的服務吧。在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，如果節點/VM 的 IP 地址發生變化，你需要能處理這種情況。
（3）LoadBalancer
LoadBalancer 服務是暴露服務到 internet 的標准方式，它借助Cloud Provider創建一個外部的負載均衡器，並將請求轉發到<NodeIP>:NodePort（向節點導流）。
例如下面這個yaml中：
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.155
PS：每一個用 LoadBalancer 暴露的服務都會有它自己的 IP 地址，每個用到的 LoadBalancer 都需要付費，這將是比較昂貴的花費。
四、小結
本文主要快速地不完全地不求甚解地過了一下K8S中的一些重要的基本概念，目的是為下一篇部署ASP.NET Core API到K8S有一個必要的認知。
參考資料
- Jesse，http://video.jessetalk.cn/my/course/6
- 阿里雲，https://github.com/AliyunContainerService/k8s-for-docker-desktop/tree/18.09
- 阿里雲，https://yq.aliyun.com/articles/508460?spm=a2c4e.11153940.blogcont221687.18.7dd57733hFolMo
- 小黑老，https://www.jianshu.com/p/1555c9b7fccd
- 騰訊雲，http://www.sohu.com/a/227967825_212034
- 池劍鋒（譯者），http://dockone.io/article/4884