日日操夜夜添-日日操影院-日日草夜夜操-日日干干-精品一区二区三区波多野结衣-精品一区二区三区高清免费不卡

在Kube.NETes中，創建和刪除Pod是最常見的任務之一。

當你執行滾動更新、擴展部署、發布新版本、執行作業和定時作業等操作時，都會創建Pod。

但是，在Pod被驅逐后，例如將節點標記為不可調度時，Pod也會被刪除并重新創建。

如果這些Pod的性質是如此短暫，那么當一個Pod正在響應請求時，如果被告知關閉，會發生什么？在關閉之前，請求是否會完成？那么后續的請求呢？是否會被重定向到其他地方？

在討論Pod被刪除時會發生什么之前，有必要談談當Pod被創建時會發生什么。

假設你想在集群中創建以下Pod：

pod.yaml

復制

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  contAIners:
    - name: web
      image: Nginx
      ports:
        - name: web
          containerPort: 80

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.
• 11.

你可以使用以下命令將YAML定義提交到集群中：

復制

$ kubectl Apply -f pod.yaml

• 1.

一旦你輸入該命令，kubectl會將Pod定義提交給Kubernetes API。

在數據庫中保存集群的狀態

Pod的定義被API接收并進行檢查，隨后存儲在數據庫（etcd）中。

Pod也被添加到調度器的隊列中。

調度器執行以下操作：

檢查Pod的定義。

收集關于工作負載的詳細信息，例如CPU和內存請求。

通過篩選器和判定的過程決定最適合運行該Pod的節點。

在此過程結束時：

• Pod在etcd中被標記為已調度。
• Pod被分配給一個節點。
• Pod的狀態被存儲在etcd中。

然而，此時Pod仍然不存在。

1. 當你使用kubectl apply -f命令提交一個Pod的YAML文件時，該YAML文件會被發送到Kubernetes API。

圖片

2. API將Pod保存在數據庫（etcd）中。

圖片

3. 調度器為該Pod分配了最適合的節點，Pod的狀態變為Pending。此時，Pod只存在于etcd中。

圖片

在控制平面中發生了前述任務，并且狀態存儲在數據庫中。

**那么是誰在你的節點上創建Pod呢？

Kubelet-Kubernetes代理

Kubelet 的任務是輪詢控制平面以獲取更新。

你可以想象kubelet不斷地向主節點發出請求：“我負責管理工作節點1，是否有新的Pod需要我處理？”

當有一個Pod需要處理時，kubelet會創建它，在某種程度上是這樣的。

kubelet并不是直接創建Pod。相反，它將工作委托給其他三個組件：

• 容器運行時接口（CRI）：負責為Pod創建容器。
• 容器網絡接口（CNI）：負責將容器連接到集群網絡并分配IP地址。
• 容器存儲接口（CSI）：負責在容器中掛載卷。

在大多數情況下，容器運行時接口（CRI）的工作類似于：

復制

$ Docker run -d <my-container-image>

• 1.

容器網絡接口（CNI）更有趣，因為它負責以下任務：

1. 為Pod生成有效的IP地址。
2. 將容器連接到網絡的其他部分。

正如你所想象的，連接容器到網絡并分配有效的IP地址有多種方式（可以選擇IPv4或IPv6，甚至可以分配多個IP地址）。

以Docker為例，它會創建虛擬以太網對并將其附加到一個橋接器上；而AWS-CNI會直接將Pod連接到虛擬私有云（VPC）的其余部分。

當容器網絡接口完成其工作時，Pod將連接到網絡的其余部分，并被分配一個有效的IP地址。

但是存在一個問題。

kubelet知道IP地址（因為它調用了容器網絡接口），但控制平面不知道。

沒有人告訴主節點Pod已被分配了IP地址，并且準備好接收流量。在控制平面的視角中，Pod仍在創建中。

kubelet的工作是收集Pod的所有細節，例如IP地址，并將其報告給控制平面。

你可以想象，檢查etcd將不僅揭示Pod的運行位置，還會顯示其IP地址。

1. Kubelet定期向控制平面輪詢更新。

2. 當一個新的Pod被分配給它所在的節點時，kubelet會獲取該Pod的詳細信息。

3. kubelet本身不會創建Pod，它依賴于三個組件：容器運行時接口（Container Runtime Interface）、容器網絡接口（Container Network Interface）和容器存儲接口（Container Storage Interface）。

4. 一旦這三個組件都成功完成，Pod就會在你的節點上運行，并分配了一個IP地址。

5. kubelet將IP地址報告給控制平面。

如果Pod不是任何服務的一部分，這就是任務的結束。Pod已創建并準備好使用。

當Pod是服務的一部分時，還需要進行一些額外的步驟。

Pods和服務

創建服務時，通常需要注意兩個關鍵信息：

1. 選擇器（selector）：用于指定接收流量的Pod。
2. 目標端口（targetPort）：Pod用于接收流量的端口。

一個典型的服務的YAML定義如下：

service.yaml

復制

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - port: 80
    targetPort: 3000
  selector:
    name: app

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.

當你使用kubectl apply將服務提交到集群時，Kubernetes會查找所有具有與選擇器（name: app）相同標簽的Pod，并收集它們的IP地址，但前提是它們通過了就緒探針（Readiness probe）。

然后，對于每個IP地址，Kubernetes會將IP地址和端口連接起來。

如果IP地址是10.0.0.3，目標端口是3000，Kubernetes會將這兩個值連接起來，并稱其為一個端點（endpoint）。

復制

IP address + port = endpoint
---------------------------------
10.0.0.3   + 3000 = 10.0.0.3:3000

• 1.
• 2.
• 3.

這些端點將以另一個名為Endpoint的對象形式存儲在etcd中。

有點困惑嗎？

在Kubernetes中，以下術語適用：

endpoint（本文和Learnk8s材料中以小寫字母e表示）是IP地址和端口對的組合（10.0.0.3:3000）。 Endpoint（本文和Learnk8s材料中以大寫字母E表示）是一組端點的集合。 Endpoint對象是Kubernetes中的一個真實對象，對于每個服務，Kubernetes會自動創建一個Endpoint對象。

你可以使用以下命令進行驗證：

復制

$ kubectl get services,endpoints
NAME                   TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)
service/my-service-1   ClusterIP   10.105.17.65   <none>        80/TCP
service/my-service-2   ClusterIP   10.96.0.1      <none>        443/TCP


NAME                     ENDPOINTS
endpoints/my-service-1   172.17.0.6:80,172.17.0.7:80
endpoints/my-service-2   192.168.99.100:8443

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.

Endpoint會收集來自Pod的所有IP地址和端口。

但不僅如此。當發生以下情況時，Endpoint對象會使用新的端點列表進行刷新：

1. 創建一個Pod。
2. 刪除一個Pod。
3. 在Pod上修改標簽。

因此，你可以想象，每當你創建一個Pod，并且kubelet將其IP地址提交給主節點后，Kubernetes會更新所有的端點以反映這種變化：

復制

$ kubectl get services,endpoints
NAME                   TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)
service/my-service-1   ClusterIP   10.105.17.65   <none>        80/TCP
service/my-service-2   ClusterIP   10.96.0.1      <none>        443/TCP


NAME                     ENDPOINTS
endpoints/my-service-1   172.17.0.6:80,172.17.0.7:80
endpoints/my-service-2   192.168.99.100:8443

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.

很好，端點被存儲在控制平面中，并且Endpoint對象已被更新。

1. 在這張圖片中，你的集群中部署了一個單獨的Pod。該Pod屬于一個服務。如果你要檢查etcd，你會發現Pod的詳細信息以及服務的信息。

2. 當部署新的Pod時會發生什么？

3. Kubernetes需要跟蹤Pod及其IP地址。服務應該將流量路由到新的端點，因此IP地址和端口應該被傳播。

4. 當另一個Pod被部署時會發生什么？

5. 是的，完全相同的過程。在數據庫中創建了新的“行”來表示新的Pod，并將端點進行傳播。

6. 當刪除一個Pod時會發生什么？

7. 服務立即移除該端點，最終該Pod也會從數據庫中刪除。

8. Kubernetes對你的集群中的每一個小變化都做出反應。

在Kubernetes中使用端點

端點在Kubernetes中被多個組件使用。

Kube-proxy使用端點來在節點上設置iptables規則。

因此，每當端點（Endpoint對象）發生變化時，kube-proxy會獲取新的IP地址和端口列表，并編寫新的iptables規則。

1. 讓我們考慮一個由三個節點組成的集群，其中有兩個Pod，并且沒有服務。Pod的狀態被存儲在etcd中。

2. 當你創建一個服務（Service）時會發生什么？

3. Kubernetes創建了一個Endpoint對象，并收集了來自Pod的所有端點（IP地址和端口對）。

4. kube-proxy守護程序訂閱對Endpoint的更改。

5. 當Endpoint被添加、刪除或更新時，kube-proxy會獲取新的端點列表。

6. kube-proxy使用端點來在集群的每個節點上創建iptables規則。

Ingress控制器也使用相同的端點列表。

Ingress控制器是集群中將外部流量路由到集群內的組件。

當你設置一個Ingress配置文件時，通常會指定Service作為目標：

入口.yaml

復制

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - backend:
          service:
            name: my-service
            port:
              number: 80
        path: /
        pathType: Prefix

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.
• 11.
• 12.
• 13.
• 14.
• 15.

實際上，流量并不會直接路由到Service。

相反，Ingress控制器建立了一個訂閱，以便在Service的端點發生變化時收到通知。

Ingress直接將流量路由到Pods，跳過了Service。

正如你所想象的那樣，每當Endpoint（對象）發生變化時，Ingress會獲取新的IP地址和端口列表，并重新配置控制器以包括新的Pods。

1. 在這張圖片中，有一個帶有兩個副本的Ingress控制器和一個Service的部署（Deployment）。

2. 如果你想通過Ingress將外部流量路由到Pods，你應該創建一個Ingress配置文件（一個YAML文件）。

3. 一旦你運行kubectl apply -f ingress.yaml命令，Ingress控制器就會從控制平面中獲取配置文件。

4. Ingress的YAML文件中有一個serviceName屬性，用于描述應該使用哪個Service。

5. Ingress控制器從Service中檢索端點列表，并跳過該Service。流量直接流向端點（Pods）。

6. 當創建一個新的Pod時會發生什么？

7. 你已經知道Kubernetes如何創建Pod并傳播端點信息了。

8. Ingress控制器訂閱對端點的更改。由于有一個新的變化，它會獲取新的端點列表。

9. Ingress控制器將流量路由到新的Pod上。

還有其他訂閱端點更改的Kubernetes組件的示例。

集群中的DNS組件CoreDNS就是其中之一。

如果你使用Headless類型的Service，CoreDNS將需要訂閱端點的更改，并在每次添加或刪除端點時重新配置自身。

同樣，服務網格（如Istio或Linkerd）、云服務提供商用于創建類型為LoadBalancer的服務，以及無數的操作員都會使用這些端點。

你必須記住，有多個組件訂閱端點的更改，它們可能在不同的時間接收到關于端點更新的通知。

這就足夠了，或者還有在創建Pod后發生的事情嗎？

創建Pod時發生的主要步驟的簡要回顧：

1. Pod被存儲在etcd中。
2. 調度器分配一個節點，并將該節點寫入etcd。
3. kubelet收到新的已調度Pod的通知。
4. kubelet將創建容器的任務委托給容器運行時接口（CRI）。
5. kubelet將容器連接到容器網絡接口（CNI）的任務委托給它。
6. kubelet將容器中的掛載卷的任務委托給容器存儲接口（CSI）。
7. 容器網絡接口分配一個IP地址。
8. kubelet將IP地址報告給控制平面。
9. IP地址被存儲在etcd中。

如果你的Pod屬于一個Service：

1. kubelet等待成功的就緒探針（Readiness probe）。
2. 所有相關的端點（對象）都會收到變更的通知。
3. 端點將新的端點（IP地址+端口對）添加到它們的列表中。
4. Kube-proxy收到端點變更的通知。Kube-proxy在每個節點上更新iptables規則。
5. Ingress控制器收到端點變更的通知。控制器將流量路由到新的IP地址上。
6. CoreDNS收到端點變更的通知。如果Service的類型是Headless，DNS條目將被更新。
7. 云服務提供商收到端點變更的通知。如果Service的類型是LoadBalancer，新的端點將作為負載均衡池的一部分進行配置。
8. 集群中安裝的任何服務網格都會收到端點變更的通知。
9. 任何訂閱端點變更的其他操作員也會收到通知。

對于一個看似普通的任務——創建一個Pod來說，這個列表確實很長。

Pod已經運行起來了。現在是時候討論一下當你刪除Pod時會發生什么了。

刪除Pod

你可能已經猜到了，但是當刪除Pod時，你需要按照相同的步驟但是逆序進行操作。

首先，應該從Endpoint（對象）中移除端點。

這次Readiness probe會被忽略，并且端點會立即從控制平面中刪除。

這反過來會觸發kube-proxy、Ingress控制器、DNS、服務網格等所有事件。

這些組件將更新其內部狀態，并停止將流量路由到該IP地址。

由于這些組件可能正在執行其他操作，無法保證從其內部狀態中刪除IP地址需要多長時間。對于某些組件來說，可能只需要不到一秒的時間；而對于其他組件來說，可能需要更長的時間。

對一些來說，這可能只需要不到一秒鐘；對其他來說，這可能需要更多。

1. 如果你使用kubectl delete pod刪除一個Pod，該命令首先會發送到Kubernetes API。

2. 該消息會被控制平面中的特定控制器——Endpoint控制器所攔截。

3. Endpoint控制器向API發送命令，將IP地址和端口從Endpoint對象中移除。

4. 誰會監聽Endpoint的更改？kube-proxy、Ingress控制器、CoreDNS等組件會收到關于這一變更的通知。

5. 一些組件，如kube-proxy，可能需要額外的時間來進一步傳播這些更改。

與此同時，etcd中的Pod狀態被更改為Terminating（終止中）。

kubelet收到此變更的通知，并進行以下操作：

1. 將容器中的任何掛載卷從容器存儲接口（CSI）卸載。
2. 將容器從網絡中分離，并釋放IP地址給容器網絡接口（CNI）。
3. 將容器銷毀給容器運行時接口（CRI）。

換句話說，Kubernetes按照與創建Pod完全相同的步驟來進行反向操作。

1. 如果你使用kubectl delete pod刪除一個Pod，該命令首先會發送到Kubernetes API。

2. 當kubelet輪詢控制平面以獲取更新時，它會注意到Pod已被刪除。

3. kubelet將銷毀Pod的任務委托給容器運行時接口（Container Runtime Interface）、容器網絡接口（Container Network Interface）和容器存儲接口（Container Storage Interface）。

然而，這里存在一個微妙但關鍵的區別。

當你終止一個Pod時，移除端點和向kubelet發送的信號同時發出。

當你首次創建一個Pod時，Kubernetes會等待kubelet報告IP地址，然后開始端點傳播。

然而，當你刪除一個Pod時，事件會并行發生。

這可能導致多種競爭條件的出現。

如果在端點傳播之前刪除了Pod會怎樣呢？

1. 刪除端點和刪除Pod同時進行。

2. 因此，在kube-proxy更新iptables規則之前，你可能會先刪除端點。

3. 或者你可能更幸運，只有在端點完全傳播之后才刪除Pod。

優雅關閉

當一個Pod在從kube-proxy或Ingress控制器中移除端點之前被終止時，你可能會遇到停機時間。

如果仔細思考一下，這是有道理的。

Kubernetes仍然將流量路由到該IP地址，但Pod已經不存在了。

Ingress控制器、kube-proxy、CoreDNS等組件沒有足夠的時間將IP地址從其內部狀態中移除。

理想情況下，Kubernetes應該在刪除Pod之前等待集群中的所有組件都具有更新的端點列表。

但是Kubernetes并不是這樣工作的。

Kubernetes提供了強大的原始組件來分發端點（例如Endpoint對象和更高級的抽象，如Endpoint Slices）。

然而，Kubernetes并不驗證訂閱端點變更的組件是否與集群狀態保持同步。

那么，為了避免這種競爭條件并確保在端點傳播后刪除Pod，你可以做些什么呢？

你應該等待。當Pod即將被刪除時，它會收到一個SIGTERM信號。

你的應用程序可以捕獲該信號并開始關閉。

由于在Kubernetes中不太可能立即從所有組件中刪除端點，你可以：

1. 在退出之前等待更長的時間。
2. 盡管收到SIGTERM信號，仍然處理傳入的流量。
3. 最后，關閉現有的長連接（例如數據庫連接或WebSockets）。
4. 關閉進程。

你應該等待多長時間呢？默認情況下，Kubernetes會發送SIGTERM信號，并在強制終止進程之前等待30秒鐘。

因此，你可以在最初的15秒內繼續正常運行。

希望這個時間間隔足夠將端點移除的更改傳播到kube-proxy、Ingress控制器、CoreDNS等組件。

隨著時間的推移，越來越少的流量會到達你的Pod，直到最終停止。

在15秒之后，可以安全地關閉與數據庫（或任何持久連接）的連接并終止進程。

如果你認為需要更多時間，可以在20或25秒時停止進程。

但是，請記住，Kubernetes將在30秒后強制終止進程（除非你在Pod定義中更改了terminationGracePeriodSeconds）。

如果無法更改代碼以等待更長時間怎么辦？你可以調用一個腳本等待固定的時間，然后讓應用程序退出。

在調用SIGTERM之前，Kubernetes在Pod中提供了一個preStop鉤子。你可以將preStop鉤子設置為等待15秒鐘。

讓我們看一個示例：

pod.yaml

復制

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
      lifecycle:
        preStop:
          exec:
            command: ["sleep", "15"]

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.
• 11.
• 12.
• 13.
• 14.
• 15.

preStop鉤子是Pod生命周期鉤子之一。

15秒的延遲是推薦的時間嗎？這取決于情況，但這可能是開始測試的合理方式。

以下是你可以選擇的選項的總結：

1. 你已經知道，當一個Pod被刪除時，kubelet會收到這一變更的通知。

圖片

2. 如果Pod具有preStop鉤子，它會首先被調用。

3. 當preStop鉤子完成后，kubelet會向容器發送SIGTERM信號。從那時起，容器應該關閉所有長連接并準備終止。

4. 默認情況下，進程有30秒的時間退出，其中包括preStop鉤子的執行時間。如果進程在此期間未退出，kubelet將發送SIGKILL信號并強制終止進程。

5. kubelet通知控制平面成功刪除了該Pod。

優雅期限和滾動更新

優雅關閉適用于被刪除的Pod。

但如果你不刪除Pod呢？即使你不刪除Pod，Kubernetes也會定期刪除Pod。

特別是，每當你部署應用程序的新版本時，Kubernetes會創建和刪除Pod。

當你在部署中更改鏡像時，Kubernetes會逐步推出變更。

pod.yaml

復制

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  replicas: 3
  selector:
    matchLabels:
      name: app
  template:
    metadata:
      labels:
        name: app
    spec:
      containers:
      - name: app
        # image: nginx:1.18 OLD
        image: nginx:1.19
        ports:
          - containerPort: 3000

• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.
• 11.
• 12.
• 13.
• 14.
• 15.
• 16.
• 17.
• 18.
• 19.
• 20.

如果你有三個副本，并且在提交新的YAML資源給Kubernetes后，Kubernetes會：

• 創建一個包含新容器鏡像的Pod。
• 銷毀一個現有的Pod。
• 等待Pod就緒。

然后它會重復上述步驟，直到所有的Pod都遷移到新版本。

Kubernetes只有在新的Pod準備好接收流量（也就是通過了就緒性檢查）后才會重復每個周期。

Kubernetes在繼續處理下一個Pod之前是否等待Pod被刪除？

不會。

如果你有10個Pod，并且每個Pod需要2秒鐘準備就緒和20秒鐘關閉，情況如下：

1. 首先創建一個新的Pod，并終止一個之前的Pod。
2. 新的Pod需要2秒鐘準備就緒，然后Kubernetes創建一個新的Pod。
3. 與此同時，正在終止的Pod保持終止狀態20秒鐘。

在20秒鐘之后，所有新的Pod都處于活動狀態（10個Pod，在2秒鐘后準備就緒），而之前的10個Pod都處于終止狀態（第一個終止的Pod即將退出）。

總體而言，在短時間內你將擁有兩倍數量的Pod（10個運行中，10個終止中）。

與就緒探針相比，寬限期限越長，你將同時擁有更多的運行中（以及終止中）的Pod。

這是一件壞事嗎？不一定，因為你要小心地確保不丟失連接。

終止長時間運行的任務

那對于長時間運行的作業呢？

如果你正在轉碼一個大型視頻，有沒有辦法延遲停止Pod的操作？

想象一下，你有一個包含三個副本的部署。

每個副本被分配了一個視頻進行轉碼，并且這個任務可能需要幾個小時才能完成。

當你觸發滾動更新時，Pod在被終止之前有30秒的時間來完成任務。

你如何避免延遲關閉Pod的操作？你可以將terminationGracePeriodSeconds增加到幾個小時。

然而，在那個時間點上，Pod的端點是無法訪問的。

如果你將指標暴露用以監控Pod，你的監控工具將無法訪問你的Pod。

為什么會這樣？

像Prometheus這樣的工具依賴于端點來抓取集群中的Pod。

然而，一旦你刪除Pod，端點刪除的信息會在集群中傳播，甚至傳遞給Prometheus！

與其增加寬限期限，你應該考慮為每個新版本創建一個全新的部署。

當你創建一個全新的部署時，現有的部署將保持不變。

長時間運行的作業可以繼續正常處理視頻。一旦它們完成，你可以手動刪除它們。

如果你希望自動刪除它們，你可以設置一個自動縮放器，當任務用盡時，它可以將部署的副本數縮減為零。

這種 Pod 自動縮放器的一個例子是 Osiris——一個 Kubernetes 的通用、縮放到零的組件。

這種技術有時被稱為Rainbow Deployments，在需要保持先前的Pod運行時間長于寬限期限的情況下非常有用。

另一個很好的例子是WebSockets。如果你正在向用戶實時傳輸更新，你可能不希望每次發布時都終止WebSockets。

如果你在一天內頻繁發布，這可能會導致實時數據流中斷多次。

為每個發布創建一個新的部署是一個不太直觀但更好的選擇。

現有用戶可以繼續傳輸更新，而最新的部署為新用戶提供服務。

隨著用戶從舊的Pod斷開連接，你可以逐漸減少副本并淘汰過去的部署。

總結

你應該注意從集群中刪除的Pod，因為它們的IP地址可能仍然被用于路由流量。

與立即關閉Pod不同，你應該考慮在應用程序中等待更長時間，或設置一個preStop鉤子。

只有在集群中的所有端點都被傳播并從kube-proxy、Ingress控制器、CoreDNS等中刪除后，才應該刪除Pod。

如果你的Pod運行長時間的任務，例如視頻轉碼或使用WebSockets提供實時更新，請考慮使用Rainbow Deployments。在Rainbow Deployments中，你為每個發布創建一個新的部署，并在連接（或任務）耗盡時刪除先前的部署。

你可以在長時間運行的任務完成后手動刪除舊的部署。或者，你可以自動將部署的副本數縮減為零，以自動化該過程。