Docker 經常使用模式

Deployment

Service

Daemonset

這種模式就是確保在每一個k8s的node節點上建立一個pod實例，有且僅有一個實例。當node被添加到集羣中，Pod也被添加上去。當node被從集羣移除，這些Pod會被垃圾回收。刪除一個DaemonSet將會清理它建立的Pod。

DaemonSet 的典型應用場景有：

• 在集羣的每一個節點上運行存儲 Daemon，好比 glusterd 或 ceph。
• 在每一個節點上運行日誌收集 Daemon，好比 flunentd 或 logstash。
• 在每一個節點上運行監控 Daemon，好比 Prometheus Node Exporter 或 collectd。

其實 Kubernetes 本身就在用 DaemonSet 運行系統組件。執行以下命令：

kubectl get daemonset --namespace=kube-system

kubectl get pods --namespace=kube-system -o wide

能夠看到flannel, kube-proxy等以daemonset形式存在的資源

Daemonset對應的屬性例如label,鏡像若是更新那麼須要更新pod. DaemonSet目前有兩種升級策略，能夠經過.spec.updateStrategy.type指定：
OnDelete: 該策略表示當更新了DaemonSet的模板後，只有手動刪除舊的DaemonSet Pod纔會建立新的DaemonSet Pod
RollingUpdate： 該策略表示當更新DaemonSet模板後會自動刪除舊的DaemonSet Pod並建立新的DaemonSetPod

sidecar 挎鬥模式

將應用程序的組件部署到單獨的進程或容器中，以提供隔離和封裝。 使用此模式還可使用異構組件和技術來構建應用程序。

此模式之因此稱做「挎鬥」(Sidecar)，是由於它相似於三輪摩托車上的挎鬥。 在此模式中，挎鬥附加到父應用程序，爲應用程序提供支持性功能。 此外，挎鬥與父應用程序具備相同的生命週期：與父應用程序一塊兒建立，一塊兒停用。 挎鬥模式有時也稱爲搭檔模式，這是一種分解模式。
挎鬥服務不必定要屬於應用程序的一部分，而只是與應用程序相鏈接。 無論它位於哪一個位置，父應用程序都會跟隨。挎鬥是連同主應用程序一塊兒部署的支持性進程或服務。 以三輪摩托車爲例，挎鬥附加在一輛三輪摩托車上，每輛三輪摩托車有自身的挎鬥。 一樣，挎鬥服務與其父應用程序具備相同的生命週期。 對於應用程序的每一個實例，都會部署一個挎鬥實例，並連同應用程序實例一塊兒託管該挎鬥實例。

使用挎鬥模式的好處包括：

• 在運行時環境和編程語言方面，挎鬥與其主應用程序相互獨立，所以，無需爲每種語言開發一個挎鬥。

• 挎鬥能夠訪問主應用程序所能訪問的資源。 例如，一個挎鬥能夠監視該挎鬥和主應用程序使用的系統資源。

• 挎鬥與主應用程序保持密切的距離，所以二者之間的通訊不存在明顯的延遲。

• 即便是對於不提供擴展性機制的應用程序，也仍可使用挎鬥來擴展功能，只需在主應用程序所用的同一主機或子容器中，將挎鬥附加爲自身的進程便可。

挎鬥模式一般與容器一塊兒使用，於是稱做挎鬥容器或搭檔容器。

問題和注意事項

• 請考慮部署服務、進程或容器時所用的部署和打包格式。 容器特別適合用於挎鬥模式。
• 在設計挎鬥服務時，請慎重決定進程間通訊機制。 除非達不到性能要求，不然請儘可能使用不區分語言或框架的技術。
• 在將功能放入挎鬥以前，請考慮該功能是做爲獨立的服務仍是更傳統的守護程序運行更有利。

• 此外，請考慮是否可以以庫的形式或使用傳統擴展機制實現功能。 特定於語言的庫可能提供更深度的集成和更少的網絡開銷。

  什麼時候使用此模式

  在如下狀況下使用此模式：
• 主應用程序使用一組異類語言和框架。 使用不一樣框架以不一樣語言編寫的應用程序可使用挎鬥服務中的某個組件。
• 某個組件由遠程團隊或不一樣的組織擁有。
• 某個組件或功能必須共置在應用程序所在的同一臺主機上
• 但願某個服務與主應用程序具備相同的總體生命週期，但同時又能獨立更新該服務。

• 須要精細控制特定資源或組件的資源限制。 例如，想要限制特定組件使用的內存量。 可將組件部署爲挎鬥，而後獨立於主應用程序管理內存用量。

  此模式可能不適用於如下狀況：

• 當進程間通訊須要優化時。 父應用程序與挎鬥服務之間的通訊會產生必定的開銷，執行調用時存在明顯的延遲。頻繁通訊的接口可能沒法接受這種弊端。
• 在某些小型應用程序中，爲每一個實例部署挎鬥服務所產生的資源開銷會抵消隔離所帶來的優點。

• 當服務須要以不一樣於或獨立於主應用程序的方式縮放時。 若是存在這種狀況，將功能部署爲獨立的服務可能更好。

  示例

  挎鬥模式適用於許多方案。 一些常見示例：

• 基礎結構 API。 基礎結構開發團隊建立了一個連同每一個應用程序一塊兒部署的服務，而不是特定於語言的客戶端庫，來訪問基礎結構。 該服務做爲挎鬥加載，爲基礎結構服務（包括日誌記錄、環境數據、配置存儲、發現、運行情況檢查和監視程序服務）提供一個公用層。 挎鬥還監視父應用程序的主機環境和進程（或容器），並將信息記錄到集中式服務。
• 管理 NGINX/HAProxy。 將 NGINX 與用於監視環境狀態的挎鬥服務一塊兒部署，而後，在須要更改狀態時更新 NGINX 配置文件並回收進程。
• 表明挎鬥。 將表明服務部署爲挎鬥。 應用程序經過表明發出調用，後者可處理日誌記錄、路由、斷路、和其餘鏈接相關功能。

• 卸載代理。 將 NGINX 代理放在 node.js 服務實例的前面，以便爲服務提供靜態文件內容