k8s中的最小調度單位---pod

     之前的文章中，我們對k8s能夠解決的問題做了簡單介紹，簡單來說，它解決的問題是容器的編排與調度，它的核心價值在于：運行在大規模集群的任務之間，實際上存在著各種各樣的關系，這些關系的處理，才是任務編排和系統管理最困難的地方，k8s就是為了這個問題而生的。

      這句話比較難理解，我們從已有的知識入手，抽絲剝繭，慢慢理解它。我們已經知道，容器的本質是一個進程，它包含三個部分：

如果說容器是云環境的一個進程，那么你可以將k8s理解成云環境中的一個操作系統。

    在一個操作系統當中，進程并不總是孤立運行的，往往是通過一個進程組的方式運行的。實際部署應用的時候，我們的應用往往不是以孤立的形式跑在docker容器中的，應用之間存在這樣那樣的關系，有的時候，他們必須跑在同一臺機器上，并且相互訪問，類似于捆綁式的，例如：如果兩個容器之間要發生之間的文件交換、需要共享某些Linux Namespace等場景。這種關系我們稱之為"超親密關系"。

     基于上面的這個前提，k8s在設計之初，就考慮了這一點，所以它在設計的時候，并不是以容器為最小的調度單位的，而是以pod這個新的概念作為k8s的最小調度單位，而每一個pod中可以包含多個容器，這樣，就實現了部署在容器中的應用程序之間就實現了捆綁，也就是他們永遠只能被部署在一臺機器上，要么部署成功，要么失敗，不可能出現一種中間狀態。

Pod和容器的關系？

   需要注意的是，Pod是一個邏輯上的概念，它的本質是一組共享了某些資源的容器。確切的說，同一個pod里面的容器，共享了相同的network namespace，當然，還可以共享掛載卷等資源。

    所謂的共享，并不是依賴，而是對等。

    假如我們有A、B兩個容器，如果A依賴B，那么A的啟動順序一定在B之后。如果A、B的地位對等，那么A、B的啟動順序將沒有嚴格要求，這才是真正的共享。那么誰來預先創建被共享的network資源呢？

   在Pod中，如果包含了多個應用容器，是需要一個infra容器，將這些應用容器給關聯起來的。類似于下面這樣：

在K8S中，infra容器占用了極少的資源，它只運行了一個叫pause的鏡像，所以也被稱為pause容器，它占用的磁盤大小在100~200kb之間。infra的存在是為了創建network namespace，然后應用容器A和應用容器B就可以加入到這個   network namespace中了。

對于 Pod 里的容器 A 和容器 B 來說：
1、它們可以直接使用 localhost 進行通信；
2、它們看到的網絡設備跟 Infra 容器看到的完全一樣；
3、一個 Pod 只有一個 IP 地址，也就是這個 Pod 的 Network Namespace 對應的 IP 地址；
4、當然，其他的所有網絡資源，都是一個 Pod 一份，并且被該 Pod 中的所有容器共享；
5、Pod 的生命周期只跟 Infra 容器一致，而與容器 A 和 B 無關
6、對于同一個 Pod 里面的所有用戶容器來說，它們的進出流量，也可以認為都是通過 Infra 容器完成的

    在這種設計模式下，掛載相同的Volume卷就很容易了，只需要在Pod的初始化yaml文件中配置volume參數即可，具體內容后續會專門分享。

     對于容器來說，一個容器只能管理一個進程，而不是一個應用。我們在進行應用上云遷移的時候，需要將應用若干個進程，然后去考慮應用模塊之間是否具有"超親密關系"，擁有超親密關系的進程可以部署在一個Pod中，其他的進程部署在另外的Pod中，用這個思路去拆分應用，才符合容器設計的初衷。

以上就是云原生技術kubernetes調度單位pod的使用詳解的詳細內容，更多關于kubernetes調度單位pod的使用的資料請關注腳本之家其它相關文章！