前一篇文章，概念性地介紹了K8s的一些基礎元件，如Pod、部署和服務。這篇文章，我打算寫寫如何使用YAML清單定義和配置這些資源。
實際上，在K8s叢集中建立物件有幾種方式 - 命令，或宣告。兩種方式區別不大。
不過實際應用中，一旦開始真正部署應用，最終都會走到YAML配置檔案方式。這種方式也叫配置清單。每個資源型別的清單，例如部署、服務、入口，他們的格式會略有不同，儘管他們之間存在著共性。
這篇文章，我就著重寫寫如何使用YAML清單定義和配置這些資源。當然，涉及內容太多，我們還是面向實際應用，寫寫通用的，和最有針對性的配置格式，而不詳細解釋所有的配置選項和排列。
為防止非授權轉發，這兒給出本文的原文連結：https://www.cnblogs.com/tiger-wang/p/13996662.html
Pod和部署的配置清單
前文我們說過，Pod是K8s最小的可部署單元。我們部署Pod，不是部署單個容器，而是部署包含一個或多個容器的Pod。這個概念一定要清楚。
K8s中部署獨立的Pod是可以的。但在實際應用中，最常見的做法是將Pod部署成為“部署資源”的一部分。
所以，通常我們的做法，是在部署清單中定義Pod資源，而不是建立一個Pod，然後建立一個部署來管理他們。換句話說，我們是建立了一個知道如何為我們建立Pod的部署。
我們先來看一個相對基礎的部署清單：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 1
maxUnavailable: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.19.3
ports:
- containerPort: 80
YAML對空格敏感，所以寫的時候一定要注意縮排。
1. apiVersion、kind、metadata
這是K8s配置清單的開頭，每個清單都會有這三個項。
apiVersion: apps/v1
apiVersion用來指示K8s API的版本。K8s有很多個API版本。以下命令可以查詢已經安裝的全部版本。
% kubectl api-versions
K8s的每個版本都包含了不同的API資源版本。
大多數情況下，配置應用時不需要太多關注這個版本號，對應好就成。
kind: Deployment
定義清單的型別。前面說了，各種資源都有不同的配置清單。本例中是部署。
metadata:
name: nginx-deployment
labels:
app: nginx
後設資料提供了諸如資源名稱以及附加到資源上的標籤等細節。
需要注意一下：標籤是與資源相關的鍵值對，後面我們會用到。本例中，我們只有一個標籤app，值是nginx。
2. spec
這是K8s清單中的規範資源部分，這部分才是實際指定型別的資源定義，在本例中，是部署（kind: Deployment）的配置。
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 1
maxUnavailable: 1
副本和策略，定義了部署應該建立多少個Pod例項，以及建立他們應該使用的方法。本例中，我們希望K8s同時執行三個Pod，並且部署新版本時使用滾動更新。
在策略中，我們設定maxUnavilable為1，這是更新策略的一個額外設定，表示我們希望在釋出部署新版本時，在需要用新版本替換舊版本的Pod過程中，或者開始新Pod之前，每次只刪除一箇舊Pod。
maxSurge和maxUnavailable也是額外設定。maxSurge控制滾動更新時一次應該新增多少額外的容器，而maxUnavilable則定義了一個容器要執行多少秒後才可被認為是可用的。
selector:
matchLabels:
app: nginx
selector部分定義這個部署管理哪些Pod。這裡面涉及到後設資料和選擇器的相互配合，我們後面會說到。
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.19.3
ports:
- containerPort: 80
部署的spec節的最後一個部分是模板。這是一個清單內的清單，裡面也同樣有metadata和spec。這裡的內容實際是一個Pod的定義配置清單。
因此，這整個部署清單定義了兩種型別的資源：Pod，和用於管理Pod擴充套件和生命週期的部署。
上面這個Pod模板，定義了一個叫nginx的容器，是由nginx 1.19.3映象構建的。這裡containerPort定義了容器內公開的埠。預設80，可不寫。不過我自己覺得，寫出來是一個好習慣。
如果我們想在Pod中部署兩個容器，則需要在containers下新增另一個：
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.19.3
ports:
- containerPort: 80
- name: nginx1
image: nginx:1.19.3
ports:
- containerPort: 8080
例子中，我們新增的第二個容器，名稱叫nginx1，也是nginx 1.19.3映象，埠在8080。
上面就是部署清單的基本內容。這部分內容很多，需要了可以查K8s相關的部分。
前面說了，K8s清單不同型別的規範會稍有不同，但他們的共同之處也很多，比如後設資料和選擇器。所以學通了一個，其它基本上也就通了。
標籤和選擇器的配合
標籤是K8s中最廣泛使用的一個概念，是與物件關聯的一個鍵值對。每個物件都可以有幾個不同的標籤，但每個鍵只能定義一次。
看前邊的例子：
metadata:
name: nginx-deployment
labels:
app: nginx
有一個鍵名叫app，值是nginx。
同樣，在spec的template中：
spec:
template:
metadata:
labels:
app: nginx
這裡，我們向Pod新增了同樣的鍵值對。
在需要的情況下，我們還可以新增其它的標籤，例如：
metadata:
labels:
app: nginx
environment: staging
system: frontend
這兩個標籤的用處，可以自己去查。
標籤在命令列管理的時候非常有用。例如下面的命令：
kubectl get pods -l environment=staging,system=frontend
可以查出所有具有staging和frontend標籤的Pod。
標籤在這裡，主要是提供附加資訊。所以，實際中可以加上各種全適的標籤。同樣，在選擇器定義時，也可以通過這些標籤來區分不同的資源。例如：
selector:
matchLabels:
app: nginx
這裡面，選擇器定義了所選資源的條件。滿足條件的資源，才會被匹配。例如，上面這個選擇器將匹配所有具有app標籤且值為nginx的Pod。
同樣，對應上面的命令列，選擇器可以寫為：
selector:
matchLabels:
environment: staging
system: frontend
這兒要注意：這個匹配的全條件的，條件之間是與的關係。當然，還有一些資源可以支援更多的匹配表示式，例如：In、NotIn、Exists或DoesNotExist。
除了部署外，服務也使用相同的機制來定義它將資料傳遞給哪個Pod。
服務的配置清單
在前文中說過，服務可以看作叢集內的負載均衡，負責隔離並轉發向Pod發出的請求。
我們來看一個清單的例子：
apiVersion: v1
kind: Service
metadata:
name: my-shop-backend
labels:
app: my-shop
system: backend
spec:
type: ClusterIP
selector:
app: my-shop
system: backend
ports:
- port: 80
targetPort: 8080
protocol: TCP
1. apiVersion、kind、metadata
跟前邊一樣，先定義清單的資源型別，這回是服務，以及所需的API版本。後設資料為服務指定了一個名稱，並加了兩個標籤用來記錄和提供資訊。
2. spec
首先，需要定義服務型別。根據K8s的版本，這兒有4種選擇：
- ClusterIP，預設值，定義服務只能從內部訪問；
- NodePort，在每個節點自動生成的埠上公開服務；
- loadbalance，在連線AWS、Azure等雲服務時，提供負載均衡；
- ExternalName，這個有點特殊，它不做代理或轉發，而只提供內部的DNS服務。
實際應用中，通常就用預設的ClusterIP，把服務作為內部負載均衡器，並使用入口將外部請求轉發到服務的結構就OK了。
下一個是選擇器，這個配置具體控制負載均衡的實現配置。如前一節所寫的，選擇器將選擇所有具有所需標籤的Pod，在本例中是app:my-shop和system:backend。服務將把所有傳入的請求路由到這些服務。看下面的部分：
spec:
selector:
app: my-shop
system: backend
最後，是清單中的埠配置。例子中定義了服務將被公開的埠80以及要使用的協議，本例中是TCP。targetPort是Pod上的埠，表示請求將會被傳發到8080。這一段單摘出來如下：
spec:
ports:
- port: 80
targetPort: 8080
protocol: TCP
這個部分因為涉及到網路，所以配置可以很複雜。必要時，可以參考K8s的文件。
在應用中，通常需要向外部公開某種HTTP服務。部署部分處理應用程式Pod的管理，服務提供多個Pod內部的負載均衡，而入口將應用暴露給外部。
入口的配置清單
前文中說過，入口充當內部K8s服務的外部負載均衡或反向代理。下面的例子展示瞭如何公開內部服務到外網：
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: my-shop-backend-ingress
labels:
app: my-shop
system: backend
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- http:
host: api.my-shop.com
paths:
- path: /my-shop
backend:
serviceName: my-shop-backend
servicePort: 80
1. apiVersion、kind、metadata
同樣，入口清單也包含API版本、型別和後設資料。不同的是，入口的後設資料還包含入口的名稱以及關聯物件的標籤。
此外，還多了一個註釋標籤annotations。註釋標籤的工作原理與前面提到的標籤很相似，也都是鍵值對。不同的是註釋標籤不能用來選擇物件。
本例中，我們新增了註釋nginx.ingress.kubernetes.io/rewrite-target，值為/。這個註釋用到了Nginx入口控制器的一個特殊鍵值，用來告訴控制器重寫傳入請求的匹配路徑為“/”。
例如，在以下路徑收到一個請求：
/my-shop/orders/123
入口控制器將重寫到：
/orders/123
另外，為了使用入口，叢集中需要部署一個入口控制器。每個入口控制器會有不同的特性，都需要不同的註釋來配置。因此，入口配置清單可能會根據不同的作用而有所不同。
2. spec
入口清單的spec部分包含配置由叢集的入口控制器管理的反向代理所需要的全部規則。如果你用過Nginx、IIS或其它類似的反代，那應該會容易理解，規則很相似，都是定義了一組傳入請求的規則，以決定將他們路由到什麼路徑。
入口清單可以定義多種規則，但一定要記著可部署單元的概念。我們應該為部署到K8s的每個應用配置單一入口，而不是跨應用去配置入口，儘管這樣做技術上支援。
看上面例子的spec段：
spec:
rules:
- http:
host: api.my-shop.com
paths:
- path: /my-shop
backend:
serviceName: my-shop-backend
servicePort: 80
通常我會習慣用主機來區分不同的應用，像例子中的api.my-shop.com。當然，您也可以通過匹配路徑來定義，例如/my-shop。而這個會根據後設資料中的重寫定義註釋被重寫。
除了匹配傳入的路徑和主機外，清單中還需要定義請求轉發的內部服務和埠。本例中，我們用了同樣的80埠去路由到上一節中定義的後端服務中。
上面這個例子是最常見的一個入口清單定義，只將傳入的請求與單個服務匹配。
有時候，可能會幾種不同型別的Pod組成一個服務“微單元”。這種情況下，也可能會有幾個K8s服務，並且基於路徑將幾個服務路由到單一入口內，這時候可以這樣配置：
spec:
rules:
- http:
paths:
- path: /orders
backend:
serviceName: my-shop-orders-service
servicePort: 80
- http:
paths:
- path: /history
backend:
serviceName: my-shop-order-history-backend
servicePort: 80
在K8s配置時，入口中可以加入很多配置。這部分如果有問題，可以去翻K8s文件。
如果只是需要將應用部署到K8s，那上邊的內容基本夠用了。唯一要注意的是叢集中用了哪個入口控制器。
總結一下
這篇文章是這個系列的第二篇。
這篇文章介紹了我們必須要知道的K8s的主要資源：Pod、部署、服務、入口的YAML基本配置，並列出了一些最重要的配置值。
K8s這個東西，做為一個大的分散式架構，肯定是比較複雜的。但實際應用中，不是每個內容都需要理解和應用。
做多了，就是套路。
蹚過了，就是經驗。
（未完待續）
 |
微信公眾號：老王Plus 掃描二維碼，關注個人公眾號，可以第一時間得到最新的個人文章和內容推送 本文版權歸作者所有，轉載請保留此宣告和原文連結 |