原创 k8s將dockershim移除之後,如何繼續使用docker?

說說這個前提,就是k8s宣佈將dockershim給移除了這麼個點   爲什麼要移除   說白了,就是k8s是想建立標準的,通過的CRI,容器運行的接口,不僅僅可以支持docker,還可以支持其他的容器運行時,真正的實現插件化的   從哪

原创 如何在k8s工作節點上,查看容器對應的pod的名字?

在k8s中,所有的容器,工作負載,最終都是要運行到節點上的,以容器的方式運行   那麼,如果要在節點上,查看該節點上運行的容器的pod的名字,pod的信息,該怎麼查看?   方法非常的簡單。   1、登錄到任意的工作節點   2、查看容器

原创 如何創建service的時候使用template模板?

什麼模板   模板?什麼鬼,其實非常的簡單!   就是在創建service的時候,直接引用變量,獲取變量的值,然後將這些值變成具體的參數值。   可以設置的參數   --hostname --mount --env   可以使用的變量

原创 如何在swarm的service中使用volume或者bind 掛載?

volume和bind volume都是持久化容器數據的方案。   通過持久化容器中的數據,避免了將數據寫入到容器的可寫層,從而呢,可以最大化的容器的性能!更重要的是,提升了容器的可移植性!在service中,同樣的可以使用數據卷和綁定掛

原创 如何將swarm中的service的端口暴露出去?

將swarm中的service端口暴露出去,供集羣外的服務進行訪問的 2 種方法:   1、路由網格   也就是在docker create service時,使用下面的參數   --publish published=<publish

原创 如何爲swarm中的service設置需要cpu和內存?

想象一下這個場景,你有一個服務,想要最好的運行狀態,必須需要一定的CPU和內存的數量,這樣的場景,如何在service中進行設置?   也就是說,爲service設置一個cpu和內存的值,swarm集羣中的節點,只有滿足這個要求的才能運行

原创 爲什麼swarm節點中運行容器的鏡像,無法查看到的tag信息?

最近今天,在研究docker swarm中服務的部署,發現一個非常奇怪的現象······   通過docker service create命令創建service,比如:   docker service create \ --wi

原创 如何修改一個已經發布的service的暴露的端口號?

今天要說的這個,其實非常的簡單,就是說······   如果你現在已經在swarm集羣中,部署了一個service,這個service對外暴露的端口號是8080,怎麼將它修改爲80端口?   比如,在集羣中有個nginx的serv

原创 在swarm集羣中部署service時,如何使用私有鏡像倉庫中的鏡像?

最近在部署service到swarm集羣的時候,出現了下列的報錯:   [[email protected] ~]# docker service create \ > --name=nginx \ > --publis

原创 怎樣爲docker swarm中的節點增加標籤(label)?移除標籤?

對於swarm集羣來說,通過節點的標籤,可以對節點進行分組。   與此同時,更加重要的是,在部署service的時候,可以定向調度到具有某個標籤的node上。   沒錯,和k8s中節點增加標籤的作用是類似的。   那麼,在swarm中如何

原创 部署service到swarm集羣,指定task運行的節點?(節點自定義標籤)

如標題所示,如何將service中task,指定運行在具有某個特殊的節點上,比如,存儲特別大,有GPU的?   方法,非常的簡單。   1、節點增加標籤   首先,給特殊的主機增加label   [[email protected]

原创 如何在swarm中部署service時,指定容器運行的命令?

默認情況下,在swarm中部署一個service,會根據鏡像中啓動命令來啓動容器,如果要進行測試也好,修改、調試也好,如何指定service中容器的啓動命令?   方法非常的簡單。   1、比如先查看某個鏡像的啓動命令   以alpine

原创 當執行docker swarm join命令將一個節點加入swarm集羣時,本質上都做了哪些事情?

  當你使用 docker swarm join 命令,將一個節點加入到swarm集羣時,在這條命令的背後,實際上發生了哪些事情?   這個問題,你能夠立馬回答出來,如果你還不能100%的,立刻馬上,回答出來,繼續往下看:   在執行這

原创 3個manager節點的swarm集羣,模擬manager節點故障和故障轉移

如果一個swarm集羣中,你有多個manager節點,比如3個,你的目的是什麼?   那還用說嗎,當然是一個manager掛掉之後,進行故障的轉移了,但是你經歷過這個轉移嗎?   如果沒有,跟着下面的過程,模擬一次。   首先,在集羣中有

原创 docker swarm集羣中manager節點個數的最佳實踐

Docker官方建議:每個swarm集羣有 3個 或 5個 管理節點來實現高可用性。   因爲,集羣模式管理節點使用Raft共享數據,所以,必須有奇數個管理節點。只要有超過一半的管理節點可用,集羣就可以繼續工作。