業界docker實現的技術

時間 2019-11-09

標籤業界 docker 實現技術欄目程序員峯會简体版

原文原文鏈接

業界使用架構前端

京東
- Openstack Icehouse + docker1.3 + OVS2.1.3/2.3.2+Centos6.6 ==> K8s + Docker + Flannel +Neutron + OVS + DPDK +JFS
- 某個容器失效,自動觸發RC(保持IP丌變「遷移」)
- OVS-VLAN
知乎
- Git+Jenkins(CI/CD) + mesos + 自研framework + group(隔離) + Consul + haproxy + DNS + Graphite + cAdvisor
  - 經過group作故障隔離
  - 鏡像倉庫經過hdfs和水平擴展作高可用
  - Mesos 集羣的橫向擴展
- docker網絡
  - bridge
  - NAT is not bad
  - iptables 有些坑
- 服務發現
  - DNS Client
- 自動Scale
  - 突發響應 & 資源高效利用
  - 根據cpu指標調整容器數量
  - 快伸慢縮
  - Max & Min Hard Limit
  - 支持自定義指標
攜程
- Openstack + Mesos + Docker + Chronos + ELK
- 監控：telegraf -> Influxdb -> Grafana
- 日誌：elk
  - mesos stdout、stderr
去哪兒
- OpenStack + nova-docker + VLAN =>Mesos + Marathon + Docker(--net=host) + 隨機端口 => Mesos + Marathon + Docker + Calico
阿里電商雲
- 自研EWS, 基於compose, 參考Kubernetes的設計. 支持多region.
  - cAdvisor + InfuxDB + prometheus
  - etcd + consul + zk + docker overlay
    - 使用RDS,OSS,OCS等服務化存儲
- docker容器的正確姿式
  - 每次代碼提交從新構建鏡像
  - 禁止修改運行中的鏡像
  - 利用volume保存持久化數據
- 存儲管理
  - 利用docker volume plugin支持不一樣的存儲類型
    - 塊存儲，雲盤
    - 對象存儲，OSSFS
    - 網絡文件系統 NFS
同程
- swarm + swarm agent + etcd + zabbix + Jenkins + (Nginx+Lua) + 配置中心
- 使用現狀
  - 容器5000個,高峯擴容到8000
  - Docker應用600個, 塞入容器的還有:Mongodb, Redis,Mysql
  - cpu利用率由20%提高爲80%
- 資源隔離層面
  - 物理機利用率提高，合理的編排應用
  - 各應用間資源隔離，避免環境和資源的衝突，提示安全性
  - 爆發式流量進入：快速擴容和遷移
  - 應用遷移：減小買服務器的花費
  - 運維工做：更多的自動化，更精細化的監控和報警
- 優化
  - dockfile 優化，縮小層數從20層到5層，構建速度快1倍
  - 存儲驅動從devicemapper改到overlayfs，構建速度快1倍
  - 發佈一個較大應用，耗時只需40s
  - 自動測試系統直接調用容器系統部署環境，測試完成就可回收，供其餘測試使用
  - 實測物理機和Container之間的性能幾乎沒有損耗
    - redis性能對比： redis-benchmark -h 127.0.01 -p6379 -q -d 100
- 鏡像管理
  - 基礎鏡像池的建設
  - 基礎鏡像之上再構建應用鏡像
  - 應用鏡像每次發佈時從新構建
  - 應用鏡像多版本存儲
  - 一次構建鏡像，各處可用
  - 各應用的回滾、擴容所有基於應用的鏡像來完成
- 網絡的思考
  - 在私有云的網絡可控性自己比較高
  - 多租戶的隔離在私有云的意義很少
  - 穩定可控可擴展才是急需求
  - 總體帶寬的高保證
  - 對docker容器的網絡考慮
    - 本機網絡模式和OVS模式
      - 本機網絡模式：如web
      - OVS模式：如數據分析
網易蜂巢
- openstack + K8S + etcd + OpenFlow + iscsi + Ceph + billing + 多機房
騰訊
- Kubernetes + 網絡(Bridge + VLAN / SR-IOV / overlay) + lxcfs + Ceph + configmap\secret + 藍鯨管控平臺
- 目前，大概有15000多常駐的Docker容器, Docker平臺上已經跑了數十款端遊、頁遊和手遊
- 集羣都是同時兼容Docker應用和非Docker類型的應用的
- Gaia將網絡和CPU、內存同樣，做爲一種資源維度歸入統一管理。業務在提交應用時指定本身的網絡IO需求，咱們使用TC（Traffic Control）+ cgroups實現網絡出帶寬控制，經過修改內核，增長網絡入帶寬的控制
- 具體網絡選型
  - 集羣內 pod 與 pod 的之間的通訊，因爲不須要內網 IP（能夠用虛擬 IP）因此採用 overlay 網絡，由 flannel 組件實現。
  - 公司內網到集羣內 pod 通訊，例如 HAProxy，遊戲某些模塊，採用 SR-IOV 網絡，由本身定製的 sriov-cni 組件實現。這類 pod 具有雙重網絡， eth0 對應 overlay 網絡， eth1 對應 SR-IOV 網絡。
  - pod 到公司內網之間的通訊。在微服務場景下，遊戲的數據存儲，周邊系統等，部署在物理機或者虛擬機上，所以 pod 到這些模塊、系統的訪問，走的是 NAT 網絡。
  - (Internet) 接入，採用公司的 TGW 方案。
滴滴
- Kubernetes
- 目前瞭解的資料,滴滴使用docker化的時間不長,沒有太多參考架構設計
uber
- 待補充
蘑菇街
- Kubernetes + VLAN
七牛雲
- Mesos + 自研容器調度框架（DoraFramework) + Bridge+ NAT + Open vSwitch + Consul + Prometheus + Ansible
- 七牛目前已經達到近千臺物理機的規模, mesos支持大規模調度更合適
- 不選擇Mesos的核心框架Marathon 而選擇自研
  - Marathon有些方面不支持咱們指望的使用姿式，好比不太好無縫對接服務發現
  - Marathon採用 scala 開發，出了問題很差排查，也不方便咱們作二次開發
  - 若是選用 Marathon的話，咱們上面仍是要再作一層對 Marathon的包裝才能做爲Dora的調度服務，這樣模塊就會變多，部署運維會複雜
魅族雲
- OVS & VLAN + SR-IOV +ceph(保證鏡像存儲可靠性) + 本身現有的監控系
- 主機間Container經過大二層網絡通信，經過vlan隔離
- 異地鏡像同步
- 容器設計理念
  - 容器化的虛擬機,建立的Container須要長時間運行
  - 每一個Container擁有獨立、惟一的IP
  - 主機間Container經過大二層網絡通信,經過vlan隔離
  - Container開啓ssh服務,可經過堡壘機登錄
  - Container開啓其餘經常使用服務,如crond
- 網絡
  - Iperf test: Bridge < OVS veth pair < OVS internal port
  - Iperf test: Native > SR-IOV > OVS > Bridge
  - Docker with DPDK
    - 輪詢處理數據包,避免中斷開銷
    - 用戶態驅動,避免內存拷貝、系統調用 - CPU親和、大頁技術
  - Idea
    - virtio做後端接口
    - 用戶態socket掛載到Container
    - Container內跑DPDK applications
- Container存儲
  - Devicemapper: 成熟穩定, 裸設備, snapshot
  - IOPS: Native 基本等於 Devicemapper
  - 數據盤存儲-LVM
    - 按Container進行配額, 支持在線更改配額
- 鏡像存儲與同步
  - 鏡像存儲
    - LVS前端負載均衡,保證高可用
    - distribution管理鏡像
    - 後端ceph保證鏡像存儲可靠性
  - 異地鏡像同步
    - webhook notification機制
    - 強一致同步機制
- 容器集羣調度系統
  - 調度請求落到集羣相應節點
  - 根據IDC、資源與區、Container類型篩選宿主機
  - 根據宿主機資源狀態、請求的CPU/內存/磁盤大小動態調度
  - 機櫃感知,將同一業務Container調度到不一樣機櫃
ucloud
- kubernetes + Jenkins
  - -v 掛載到主機, Flume/Logstash/rsyslog + elasticserach (日誌)
  - vswitch overlay的"大二層"網絡SDN組網方案 + ipvlan
- 主要問題類型和解決思路
  - 模塊配置
    - 模塊上下游關係, 後端服務
    - 運行環境,機房的差別性配置等
  - 一致性和依賴
    - 開發、測試、運行環境的不一致性
    - 依賴於不一樣的基礎庫
  - 部署
    - 部署效率低下，步驟多，耗時長
    - 部署狀態缺乏檢查機制
    - 應用管理
      - 大量容器實例的管理、擴容、縮容成本高
      - 程序構建、打包、運行和運維統一管理
      - 監控、日誌分析
  - 解決方案
    - 模塊配置
      - 分離環境、IDC、資源類等差別化的配置項信息
      - 配置模板，提交到cedebase進行版本化管理
      - 對不一樣的deploys派生不一樣配置值，填充模板，啓動腳本
      - 運行在不一樣的deploys彙總，只需經過環境變量傳遞給container便可
    - 一致性和依賴
      - 開發、測試、線上運行環境均採用docker生成的鏡像，保證一致
      - 基礎系統、基本工具、框架，分層構建
      - 基礎鏡像在開發、測試、線上環境統一預部署
    - 私有鏡像倉庫
      - V2版本
      - 支持UFile驅動
      - 定時pull最新鏡像
  - 一些經驗
    - docker日誌
      - 日誌打印耗費性能
      - 最好關閉logdriver，將日誌打印在後臺
    - docker daemon
      - 退出kill container，升級docker daemon， kill可選
    - docker網絡
      - NAT模式下會啓用nf_conntrack，形成性能降低，調節內核參數
    - docker鏡像
      - 編寫dockfile規範、減小鏡像層數，基礎部分放前面
      - 分地域部署鏡像registry

主要問題mysql

單實例性能調優 + 萬兆卡的性能發揮出來。須要對OVS（Open vSwitch）作一些改進
多機房:多機房及可用域支持
容器網絡需求
- Iptables 有些坑
- 跨主機容器間網絡訪問
- 容器網絡是否須要具有IP地址漂移能力
容器網絡面臨的問題
- Docker Host 模式,混布存在端口衝突。
- Docker NAT 模式,Ip地址敏感服務改造大,沒法支持服務發現
- Overlay網絡,涉及IP地址規劃,MAC地址分配,網絡設備收斂比等問題
- Overlay網絡安全性,可維護性, 容量規劃
版本升級(docker/mesos/k8s)自己的升級
docker 對有狀態的服務進行容器化的問題
- kafka / mysql
  網絡選型(k8s和mesos)

思考 && 痛點linux

能否跨機器訪問? 跨域訪問?
- flannel能夠跨容器通訊
- 跨主機的容器互聯
- 容器與外部互聯
是否支持靜態ip , 固定ip ? 域名訪問?
- 固定ip的話,那麼就須要每次部署或者更新或重啓的時候,ip保持不變
- overlay network, Docker 1.6 能夠實現跨主機通訊
是否支持dns?
4層/7層訪問
容器庫容後的網絡
ip端口,最好不要自行手動規劃
網絡策略,防護 ,隔離 ?
- 容器集羣不一樣應用之間的網絡隔離和流量限制
docker 網絡git
- host模式: 容器都是直接共享主機網絡空間的，容器須要使用-p來進行端口映射, 沒法啓動兩個都監聽在 80 端口的容器, 而且沒有作到隔離
- container模式: 一個容器直接使用另一個已經存在容器的網絡配置：ip 信息和網絡端口等全部網絡相關的信息都共享
- Bridge模式: 從docker0子網中分配一個IP給容器使用，並設置docker0的IP地址爲容器的默認網關
  - 容器的IP在容器重啓的時候會改變
  - 不一樣主機間容器通訊須要依賴第三方方案如:pipework
    方案
方案類別
- 隧道方案, 經過隧道，或者說Overlay Networking的方式：
  - Weave，UDP廣播，本機創建新的BR，經過PCAP互通。
  - Open vSwitch（OVS），基於VxLAN和GRE協議，可是性能方面損失比較嚴重。
  - Flannel，UDP廣播，VxLan。
- 路由方案
  - Calico，基於BGP協議的路由方案，支持很細緻的ACL控制，對混合雲親和度比較高。
  - Macvlan，從邏輯和Kernel層來看隔離性和性能最優的方案，基於二層隔離，因此須要二層路由器支持，大多數雲服務商不支持，因此混合雲上比較難以實現。
  - 性能好,沒有NAT，效率比較高, 可是受限於路由表,另外每一個容器都有一個ip,那麼業務ip可能會被用光.
網絡的兩大陣營
- Docker Libnetwork Container Network Model（CNM）陣營(Docker Libnetwork的優點就是原生，並且和Docker容器生命週期結合緊密)
  - Docker Swarm overlay
  - Macvlan & IP network drivers
  - Calico
  - Contiv（from Cisco）
- Container Network Interface（CNI）陣營 (CNI的優點是兼容其餘容器技術（e.g. rkt）及上層編排系統（Kuberneres & Mesos))
  - Kubernetes
  - Weave
  - Macvlan
  - Flannel
  - Calico
  - Contiv
  - Mesos CNI
常見的解決方案有：
- flannel vxlan，overlay方式
- calico
  - 容器間網絡三層隔離，無須要擔憂arp風暴
  - 基於iptable/linux kernel包轉發效率高，損耗低
  - Calico沒有多租戶的概念，全部容器節點都要求可被路由，IP地址不能重複
- ipvlan macvlan，物理二層/三層隔離，目前須要pipework工具在單個節點上配置，僅作了vlan隔離，不解決arp廣播
- swarm native vxlan，跟flannel vxlan相似
- neutron sdn，選擇就多種了，ml2+ovsplugin，midonet，vlan or vxlan
- Weave
  - 可以建立一個虛擬網絡來鏈接部署在多臺主機上的Docker容器, 外部設備可以訪問Weave網絡上的應用程序容器所提供的服務，同時已有的內部系統也可以暴露到應用程序容器上
- contiv
  - 思科主導，sdn解決方案，能夠用純軟的ovs，也能夠用ovs+cisco硬件sdn controller
  - 基於 OpenvSwitch，以插件化的形式支持容器訪問網絡，支持 VLAN，Vxlan，多租戶，主機訪問控制策略等
  - SDN能力，可以對容器的網絡訪問作更精細的控制
  - 京東基於相同的技術棧（OVS + VLAN）已支持10w+ 容器的運行
- linux bridge+三層交換機：host上 linux bridge 設置爲三層交換機的子網網段，容器之間通訊走二層交換，容器與外部走三層交換機的網關。
業界經常使用網絡選型
- kubernetes + flannel
  - Kubernetes採用扁平化的網絡模型，要求每一個Pod擁有一個全局惟一IP，Pod直接能夠跨主機通訊。目前比較成熟的方案是利用Flannel
  - Flannel已經支持UDP、VxLAN、AWS VPC和GCE路由等數據轉發模式。
  - kubernetes 下有 flannel、openvswitch和weave能夠實現Overlay Network
  - 惟品會 contiv netplugin方案(固定外網ip) + flannel
  - 京東 Flannel + Neutron + OVS
  - Flannel性能: 官方:帶寬沒有降低,延遲明顯變大
- Mesos + Caclio
  - Mesos支持CNI標準規範
  - 一容器一ip, 網絡隔離, DNS服務發現, ip分配, L3的虛擬網絡
  - 去哪兒 Mesos + Caclio
  - 七牛 Bridge+ NAT + Open vSwitch
- 魅族雲 OVS & VLAN + SR-IOV
- ucloud: vswitch overlay的"大二層"網絡SDN組網方案 + ipvlan
  日誌監控選型(包括監控,統計)

docker因爲分層設計模式,容器裏面沒法固化數據, 容器銷燬裏面的數據就會丟失, 所以建議將日誌掛載到宿主機上, 或者使用分佈式存儲如ceph
stdout/stderr類型的日誌，可經過logspout轉發到syslog中心來收集
Docker 的LogDriver 能輸出日誌到特定的端點，例如Fluentd，Syslog，或者Journald。 Logspout能將容器日誌路由到Syslog或者第三方的諸如Redis，Kafka或者Logstash的模塊中。web

方案介紹
- 採用容器外收集。將主機磁盤掛在爲容器中的日誌目錄和文件。
- 將容器中應用的控制到日誌也重定向到日誌目錄。
- 在主機上對應用日誌目錄和docker日誌目錄作日誌收集和輪換。
監控可選方案
- cAdvisor + InfluxDB + Grafana
- cAdvisor + Prometheus + Grafana
- Graphite
- Zabbix
- Datadog
日誌可選方案
- logstash
- ELK
- Graylog
- flume
- heka
- fluentd
業界方案redis
- 阿里雲 : cAdvisor + InfuxDB + prometheus
- 協程: ELK
- 知乎: Graphite + cAdvisor
  鏡像管理
鏡像老是從Dockerfile生成
鏡像之間應該避免依賴過深，建議爲三層，這三層分別是基礎的操做系統鏡像、中間件鏡像和應用鏡像
全部鏡像都應該有對應的Git倉庫，以方便後續的更新
Registrysql
- 單點問題，對應的解決方案能夠考慮DRBD、分佈式存儲以及雲存儲
- Regitry的性能問題，目前可用的解決方案是經過HTTP反向代理緩存來加速Layer的下載, 或者提供鏡像mirror
- Registry用戶權限，Nginx LUA能夠提供一個簡單快速的實現方案
  我的理解
選型不能只看編排, 還要看存儲/網絡等方面的支持
- swarm之前有些缺陷,如不能檢測失敗節點並重啓,最新版的也實現
- k8s 只是用來調度docker
- mesos是用來管理機器集羣. 經過Marathon才能間接管理docker
對應網絡的支持
- 是否可以跨主機/跨域
- 是否可以固定ip/ dns解析?
- CNI 標準的支持?
對於存儲的支持
- 是否可以固化?
- 是否支持分佈式存儲?
對於編排/調度/升級
- 是否支持回滾? 在線升級? 滾動升級?
- 是否可以細粒度分配cpu/內存等
- 是否支持有狀態服務的容器化和調度
- 自動擴縮容能力?
服務註冊/發現機制 / 負載均衡
- 是否有合適的服務註冊機制?
- 負載均衡是否可以知足各類業務場景需求?
其餘
- 隔離, 除了cgroup和namespace, 還有其餘的隔離,好比網絡隔離