Deployment和service-04

前面我們已經瞭解到，Kubernetes 通過各種 Controller 來管理 Pod 的生命週期。爲了滿足不同業務場景，Kubernetes 開發了 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等多種 Controller。我們首先學習最常用的 Deployment。

pod
pod是k8s的最小工作單元。每個pod包含一個或者多個容器。pod中的容器會作爲一個整體被master調度到一個node上運行。
5.controller
k8s通常不會直接創建pod,而是通過controller來管理pod的。controller中定義了pod的部署特性，比如有幾個劇本，在什麼樣的node上運行等。爲了滿足不同的業務場景，k8s提供了多種controller，包括deployment、replicaset、daemonset、statefulset、job等。
deployment
是最常用的controller。deployment可以管理pod的多個副本，並確保pod按照期望的狀態運行。
replicaset
實現了pod的多副本管理。使用deployment時會自動創建replicaset，也就是說deployment是通過replicaset來管理pod的多個副本的，我們通常不需要直接使用replicaset。
daemonset
用於每個node最多隻運行一個pod副本的場景。正如其名稱所示的，daemonset通常用於運行daemon。
statefuleset
能夠保證pod的每個副本在整個生命週期中名稱是不變的，而其他controller不提供這個功能。當某個pod發生故障需要刪除並重新啓動時，pod的名稱會發生變化，同時statefulset會保證副本按照固定的順序啓動、更新或者刪除。、
job
用於運行結束就刪除的應用，而其他controller中的pod通常是長期持續運行的。
service
deployment可以部署多個副本，每個pod 都有自己的IP，外界如何訪問這些副本？
答案是service
k8s的 service定義了外界訪問一組特定pod的方式。service有自己的IP和端口，service爲pod提供了負載均衡。
k8s運行容器pod與訪問容器這兩項任務分別由controller和service執行。
namespace
可以將一個物理的cluster邏輯上劃分成多個虛擬cluster，每個cluster就是一個namespace。不同的namespace裏的資源是完全隔離的。

運行一個 Deployment

kubectl run nginx-deployment --image=nginx --replicas=2
上面的命令將部署包含兩個副本的 Deployment nginx-deployment，容器的 image 爲nginx:laster

kubectl get deployment 命令可以查看 nginx-deployment 的狀態，輸出顯示兩個副本正常運行。
接下來我們用 kubectl describe deployment 瞭解更詳細的信息。

大部分內容都是自解釋的，我們重點看最下面部分。這裏告訴我們創建了一個 ReplicaSet nginx-deployment-1260880958，Events 是 Deployment 的日誌，記錄了 ReplicaSet 的啓動過程。
通過上面的分析，也驗證了 Deployment 通過 ReplicaSet 來管理 Pod 的事實。接着我們將注意力切換到 nginx-deployment-69f748fb86，
執行 kubectl describe replicaset：

Controlled By 指明此 ReplicaSet 是由 Deployment nginx-deployment 創建。Events 記錄了兩個副本 Pod 的創建。接着我們來看 Pod，
執行 kubectl get pod：

兩個副本 Pod 都處於 Running 狀態，用 kubectl describe pod 查看更詳細的信息：

Controlled By 指明此 Pod 是由 ReplicaSet nginx-deployment-1260880958 創建。Events 記錄了 Pod 的啓動過程。如果操作失敗（比如 image 不存在），也能在這裏查看到原因。
總結一下這個過程：
用戶通過 kubectl 創建 Deployment。
Deployment 創建 ReplicaSet。
ReplicaSet 創建 Pod。

從上圖也可以看出，對象的命名方式是：子對象的名字 = 父對象名字 + 隨機字符串或數字。
本節我們是通過 kubectl run 創建的 Deployment，下一節學習另一種更常用的方法。

通過 Service 訪問 Pod

我們不應該期望 Kubernetes Pod 是健壯的，而是要假設 Pod 中的容器很可能因爲各種原因發生故障而死掉。Deployment 等 controller 會通過動態創建和銷燬 Pod 來保證應用整體的健壯性。換句話說，Pod 是脆弱的，但應用是健壯的。
每個 Pod 都有自己的 IP 地址。當 controller 用新 Pod 替代發生故障的 Pod 時，新 Pod 會分配到新的 IP 地址。這樣就產生了一個問題：
如果一組 Pod 對外提供服務（比如 HTTP），它們的 IP 很有可能發生變化，那麼客戶端如何找到並訪問這個服務呢？
Kubernetes 給出的解決方案是 Service。

創建 Service

Kubernetes Service 從邏輯上代表了一組 Pod，具體是哪些 Pod 則是由 label 來挑選。Service 有自己 IP，而且這個 IP 是不變的。客戶端只需要訪問 Service 的 IP，Kubernetes 則負責建立和維護 Service 與 Pod 的映射關係。無論後端 Pod 如何變化，對客戶端不會有任何影響，因爲 Service 沒有變。
來看個例子，創建下面的這個 Deployment：

[root@master ~]# cat httpd.yml 
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: httpd
spec:
  replicas: 3
  template:
    metadata:
      labels:
        run: httpd
    spec:
      containers:
      - name: httpd
        image: httpd
        ports:
        - containerPort: 80

我們啓動了三個 Pod，運行 httpd 鏡像，label 是 run: httpd，Service 將會用這個 label 來挑選 Pod。

Pod 分配了各自的 IP，這些 IP 只能被 Kubernetes Cluster 中的容器和節點訪問。
接下來創建 Service，其配置文件如下：

[root@master ~]# cat  http-service.yml 
apiVersion: v1
kind: Service
metadata:
  name: httpd-svc
spec:
  selector:
    run: httpd
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 80

① v1 是 Service 的 apiVersion。
② 指明當前資源的類型爲 Service。
③ Service 的名字爲 httpd-svc。
④ selector 指明挑選那些 label 爲 run: httpd 的 Pod 作爲 Service 的後端。
⑤ 將 Service 的 8080 端口映射到 Pod 的 80 端口，使用 TCP 協議。

執行 kubectl apply 創建 Service httpd-svc。

httpd-svc 分配到一個 CLUSTER-IP 10.111.219.214。可以通過該 IP 訪問後端的 httpd Pod。

根據前面的端口映射，這裏要使用 8080 端口。另外，除了我們創建的 httpd-svc，還有一個 Service kubernetes，Cluster 內部通過這個 Service 訪問 kubernetes API Server。

通過 kubectl describe 可以查看 httpd-svc 與 Pod 的對應關係。

Endpoints 羅列了三個 Pod 的 IP 和端口。我們知道 Pod 的 IP 是在容器中配置的，那麼 Service 的 Cluster IP 又是配置在哪裏的呢？CLUSTER-IP 又是如何映射到 Pod IP 的呢？
答案是 iptables

Service Cluster IP 的底層實現

Service deCluster IP 是一個虛擬 IP，是由 Kubernetes 節點上的 iptables 規則管理的。
可以通過 iptables-save 命令打印出當前節點的 iptables 規則，因爲輸出較多，這裏只截取與 httpd-svc Cluster IP 10.111.219.214 相關的信息：

這兩條規則的含義是：

如果 Cluster 內的 Pod（源地址來自 10.244.0.0/16）要訪問 httpd-svc，則允許。
2 其他源地址訪問 httpd-svc，跳轉到規則 KUBE-SVC-RL3JAE4GN7VOGDGP。

KUBE-SVC-RL3JAE4GN7VOGDGP 規則如下：

1/3 的概率跳轉到規則 KUBE-SEP-5TOGU7RW6ODB2NEU
1/3 的概率（剩下 2/3 的一半）跳轉到規則 KUBE-SEP-WCXDXF365ATAGI2F
1/3 的概率跳轉到規則KUBE-SEP-IRMT6RY5EEEBXDAY

上面三個跳轉的規則如下：

即將請求分別轉發到後端的三個 Pod。通過上面的分析，我們得到如下結論：
iptables 將訪問 Service 的流量轉發到後端 Pod，而且使用類似輪詢的負載均衡策略。
另外需要補充一點：Cluster 的每一個節點都配置了相同的 iptables 規則，這樣就確保了整個 Cluster 都能夠通過 Service 的 Cluster IP 訪問 Service。
除了直接通過 Cluster IP 訪問到 Service，DNS 是更加便捷的方式，下一節我們討論。

外網如何訪問 Service

除了 Cluster 內部可以訪問 Service，很多情況我們也希望應用的 Service 能夠暴露給 Cluster 外部。Kubernetes 提供了多種類型的 Service，默認是 ClusterIP。

ClusterIP
Service 通過 Cluster 內部的 IP 對外提供服務，只有 Cluster 內的節點和 Pod 可訪問，這是默認的 Service 類型，前面實驗中的 Service 都是 ClusterIP。
NodePort
Service 通過 Cluster 節點的靜態端口對外提供服務。Cluster 外部可以通過 <NodeIP>:<NodePort> 訪問 Service。
LoadBalancer
Service 利用 cloud provider（雲廠商）特有的 load balancer 對外提供服務，cloud provider 負責將 load balancer 的流量導向 Service。目前支持的 cloud provider 有 GCP、AWS、Azur 等。
下面我們來實踐 NodePort，Service httpd-svc 的配置文件修改如下：

添加 type: NodePort，重新創建 httpd-svc。

Kubernetes 依然會爲 httpd-svc 分配一個 ClusterIP，不同的是：
EXTERNAL-IP 爲 nodes，表示可通過 Cluster 每個節點自身的 IP 訪問 Service。
PORT(S) 爲 8080:32312。8080 是 ClusterIP 監聽的端口，32312 則是節點上監聽的端口。Kubernetes 會從 30000-32767 中分配一個可用的端口，每個節點都會監聽此端口並將請求轉發給 Service。

下面測試 NodePort 是否正常工作。

通過三個節點 IP + 32312 端口都能夠訪問 httpd-svc。

接下來我們深入探討一個問題：Kubernetes 是如何將 <NodeIP>:<NodePort> 映射到 Pod 的呢？
與 ClusterIP 一樣，也是藉助了 iptables。與 ClusterIP 相比，每個節點的 iptables 中都增加了下面兩條規則：

規則的含義是：訪問當前節點 32312 端口的請求會應用規則 KUBE-SVC-RL3JAE4GN7VOGDGP，內容爲

其作用就是負載均衡到每一個 Pod。
NodePort 默認是的隨機選擇，不過我們可以用 nodePort 指定某個特定端口

現在配置文件中就有三個 Port 了：
nodePort 是節點上監聽的端口。
port 是 ClusterIP 上監聽的端口。
targetPort 是 Pod 監聽的端口。
最終，Node 和 ClusterIP 在各自端口上接收到的請求都會通過 iptables 轉發到 Pod 的 targetPort。
應用新的 nodePort 並驗證：

Rolling Update

滾動更新是一次只更新一小部分副本，成功後，再更新更多的副本，最終完成所有副本的更新。滾動更新的最大的好處是零停機，整個更新過程始終有副本在運行，從而保證了業務的連續性。
實踐
下面我們部署三副本應用，初始鏡像爲 httpd:2.2.31，然後將其更新到 httpd:2.2.32。
httpd:2.2.31 的配置文件如下：

通過 kubectl apply 部署。

部署過程如下：

創建 Deployment httpd
創建 ReplicaSet httpd-5ddb558f47
創建三個 Pod
當前鏡像爲 httpd:2.2.31

將配置文件中 httpd:2.2.31 替換爲 httpd:2.2.32，再次執行 kubectl apply。

我們發現瞭如下變化：

Deployment httpd 的鏡像更新爲 httpd:2.2.32
新創建了 ReplicaSet httpd-8bdffc6d8，鏡像爲 httpd:2.2.32，並且管理了三個新的 Pod。
之前的 ReplicaSet httpd-5ddb558f47裏面k已經沒有任何 Pod。

結論是：ReplicaSet httpd-5ddb558f47的三個 httpd:2.2.31 Pod 已經被 ReplicaSet httpd-8bdffc6d8 的三個 httpd:2.2.32 Pod 替換了。

每次只更新替換一個 Pod：
ReplicaSet httpd-8bdffc6d8 增加一個 Pod，總數爲 1。
ReplicaSet httpd-5ddb558f47減少一個 Pod，總數爲 2。
ReplicaSet httpd-8bdffc6d8 增加一個 Pod，總數爲 2。
ReplicaSet httpd-5ddb558f47減少一個 Pod，總數爲 1。
ReplicaSet httpd-8bdffc6d8 增加一個 Pod，總數爲 3。
ReplicaSet httpd-5ddb558f47減少一個 Pod，總數爲 0。

每次替換的 Pod 數量是可以定製的。Kubernetes 提供了兩個參數 maxSurge 和 maxUnavailable 來精細控制 Pod 的替換數量，我們將在後面結合 Health Check 特性一起討論。

回滾

kubectl apply 每次更新應用時 Kubernetes 都會記錄下當前的配置，保存爲一個 revision（版次），這樣就可以回滾到某個特定 revision。
默認配置下，Kubernetes 只會保留最近的幾個 revision，可以在 Deployment 配置文件中通過 revisionHistoryLimit 屬性增加 revision 數量。
下面實踐回滾功能。應用有如下三個配置文件 httpd.v1.yml，httpd.v2.yml 和 httpd.v3.yml，分別對應不同的 httpd 鏡像 2.4.16，2.4.17 和 2.4.18：

[root@master ~]# cat  httpd.v1.yml 
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: httpd
spec:
  revisionHistoryLimit: 10
  replicas: 3
  template:
    metadata:
      labels:
        run: httpd
    spec:
      containers:
      - name: httpd
        image: httpd:2.4.16
        ports:
        - containerPort: 80
[root@master ~]# 
[root@master ~]# cat  httpd.v2.yml 
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: httpd
spec:
  revisionHistoryLimit: 10
  replicas: 3
  template:
    metadata:
      labels:
        run: httpd
    spec:
      containers:
      - name: httpd
        image: httpd:2.4.17
        ports:
        - containerPort: 80
[root@master ~]# 
[root@master ~]# cat  httpd.v3.yml 
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: httpd
spec:
  revisionHistoryLimit: 10
  replicas: 3
  template:
    metadata:
      labels:
        run: httpd
    spec:
      containers:
      - name: httpd
        image: httpd:2.4.18
        ports:
        - containerPort: 80
[root@master ~]#

通過 kubectl apply 部署並更新應用：

–record 的作用是將當前命令記錄到 revision 記錄中，這樣我們就可以知道每個 revison 對應的是哪個配置文件。通過 kubectl rollout history deployment httpd 查看 revison 歷史記錄。

CHANGE-CAUSE 就是 --record 的結果。如果要回滾到某個版本，比如 revision 1，可以執行命令 kubectl rollout undo deployment httpd --to-revision=1：

此時，revison 歷史記錄也會發生相應變化。

revison 1 變成了 revison 4。不過我們可以通過 CHANGE-CAUSE 知道每個 revison 的具體含義。所以一定要在執行 kubectl apply 時加上 --record 參數。

Deployment和service-04

運行一個 Deployment

通過 Service 訪問 Pod

創建 Service

Service Cluster IP 的底層實現

外網如何訪問 Service

Rolling Update

回滾

如何使用 JS 判斷用戶是否處於活躍狀態

Mono 支持LoongArch架構

lightdb秒級增加列和刪除列（not null帶默認值）

lightdb數據庫超時相關控制參數

通過HPA+CronHPA組合應對業務複雜彈性伸縮場景

❤️‍🔥 Solon Cloud Event 新的事務特性與應用

lightdb mysql 8.0兼容之不可見主鍵

使用 JS 實現在瀏覽器控制檯打印圖片 console.image()

基於Ubuntu-22.04安裝K8s-v1.28.2實驗（四）使用域名訪問網站應用

kubeadm部署安裝K8S集羣及核心概念-02

k8s創建pod資源對象-03

KVM遷移及優化-06

Deployment和service-04

kubernetes介紹-01

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結