面经 - OpenStack（Docker、Django、K8S、SDN）知识点
文章目錄
- 概述
- OpenStack
- 虛擬化
- kvm
- 網(wǎng)絡(luò)虛擬化
- 基本技術(shù)
- Memcached
- Etcd
- 消息隊(duì)列
- 概念
- 交換機(jī)類型
- 缺點(diǎn)
- 重復(fù)投遞問(wèn)題
- 順序投遞問(wèn)題
- restful api
- Horizon
- Nova
- nova-api
- nova-scheduler
- 過(guò)濾器類型
- nova-compute
- 基本操作
- Keystone
- Glance
- Neutron
- 一些虛擬的網(wǎng)絡(luò)設(shè)備
- 架構(gòu)
- Neutron Server
- ML2 Plugin
- Linux Bridge實(shí)現(xiàn)
- local network
- flat network
- vlan network
- vxlan
- DHCP服務(wù)
- NameSpace
- Routing
- 底層實(shí)現(xiàn)
- router連接外網(wǎng)
- floating IP
- Fwaas
- OpenvSwitch
- local network
- flat network
- VLAN 網(wǎng)絡(luò)
- Roting
- VxLAN
- Cinder
- Swift
- Zun
- Kuryr-libnetwork
- SDN
- OpenFlow
- OF 1.0
- OF 1.3
- Django
- 概述
- MVC和MTV
- 和Flask Tornado的區(qū)別
- Django請(qǐng)求生命周期
- 常見的web應(yīng)用程序
- 框架組件
- RestFramework
- 緩存機(jī)制
- WSGI,uwsgi,uWSGI
- 請(qǐng)求的生命周期
- 中間件的作用和應(yīng)用場(chǎng)景
- 默認(rèn)的中間件
- django中的csrf實(shí)現(xiàn)機(jī)制
- 基于django的ajax發(fā)送請(qǐng)求給后端如何攜帶token
- ajax請(qǐng)求的csrf解決方法
- 為什么不使用django的runserver部署（runserver和uWSGI的區(qū)別）
- Kubernetes
- Pod
- Pod控制器
- Docker
- NameSpace
- Cgroups
- 驅(qū)動(dòng)
- 啟動(dòng)一個(gè)容器的步驟
- 基礎(chǔ)
- 什么是Docker
- Docker與虛擬機(jī)的不同
- Docker和普通進(jìn)程的區(qū)別
- 鏡像
- 什么是Docker鏡像和Docker容器
- Docker鏡像分層
- bootfs
- 容器分層、寫時(shí)復(fù)制（copy-on-write）
- DockerFile常見指令
- build
- Dockerfile的COPY和ADD
- Docker容器的狀態(tài)
- 網(wǎng)絡(luò)
- Docker的網(wǎng)絡(luò)類型
- docker常用命令
- 面經(jīng)
- OpenStack
- 一些命令行
- OpenStack中計(jì)算節(jié)點(diǎn)上虛擬機(jī)默認(rèn)保存路徑在哪？
- OpenStack中Glance鏡像的默認(rèn)保存路徑在哪？
- OpenStack中計(jì)算節(jié)點(diǎn)的集成橋（br-int）的作用是什么？
- OpenStack中計(jì)算節(jié)點(diǎn)的隧道橋（br-tun）的作用是什么？
- OpenStack中外部OVS橋（br-ex）的作用是什么？
- OpenStack和Docker區(qū)別
- OpenStack和kvm的區(qū)別
- kvm和xen區(qū)別
- Neutron
- vlan和vxlan的區(qū)別
- Docker
- 命名空間
概述
云計(jì)算是一種采用按量付費(fèi)的模式，基于虛擬化技術(shù)，將相應(yīng)計(jì)算資源（如網(wǎng)絡(luò)、存儲(chǔ)等）池化后，提供便捷的、高可用的、高擴(kuò)展性的、按需的服務(wù)（如計(jì)算、存儲(chǔ)、應(yīng)用程序和其他 IT 資源）。
云計(jì)算基本特征：
- 自主服務(wù)：可按需的獲取云端的相應(yīng)資源（主要指公有云）；
- 網(wǎng)路訪問(wèn)：可隨時(shí)隨地使用任何聯(lián)網(wǎng)終端設(shè)備接入云端從而使用相應(yīng)資源。
- 資源池化：
- 快速?gòu)椥?#xff1a;可方便、快捷地按需獲取和釋放計(jì)算資源。
- 按量計(jì)費(fèi)：
常見的部署模式
- 公有云
- 私有云
- 社區(qū)云
- 混合云
三種服務(wù)模式
- IaaS：云服務(wù)商將IT系統(tǒng)的基礎(chǔ)設(shè)施（如計(jì)算資源、存儲(chǔ)資源、網(wǎng)絡(luò)資源）池化后作為服務(wù)進(jìn)行售賣；
- PaaS：云服務(wù)商將IT系統(tǒng)的平臺(tái)軟件層（數(shù)據(jù)庫(kù)、OS、中間件、運(yùn)行庫(kù)）作為服務(wù)進(jìn)行售賣；
- SaaS：云服務(wù)商將IT系統(tǒng)的應(yīng)用軟件層作為服務(wù)進(jìn)行售賣。
云計(jì)算和虛擬化
云計(jì)算：IT能力服務(wù)化，按需使用，按量計(jì)費(fèi)，多租戶隔離，是一個(gè)系統(tǒng)的輕量級(jí)管理控制面。
虛擬化：環(huán)境隔離，資源復(fù)用，降低隔離損耗，提升運(yùn)行性能，提供高級(jí)虛擬化特性。
虛擬化是實(shí)現(xiàn)云計(jì)算的技術(shù)支撐之一，但并非云計(jì)算的核心關(guān)注點(diǎn)。
IT架構(gòu)的三個(gè)發(fā)展階段
OpenStack
一個(gè)開源云操作系統(tǒng)內(nèi)核，用于構(gòu)建云平臺(tái)，主要實(shí)現(xiàn)以下五個(gè)主要特點(diǎn)：
- 資源抽象：OpenStack將各類硬件資源，通過(guò)虛擬化與軟件定義的形式，抽象成虛擬的資源池；
- 資源調(diào)度：OpenStack根據(jù)管理員/用戶的需求，將資源池中的資源分配給不同的用戶，承載不同的應(yīng)用；
- 應(yīng)用生命周期管理：OpenStack可以提供初步的應(yīng)用部署/撤銷、自動(dòng)規(guī)模調(diào)整等功能；
- 系統(tǒng)運(yùn)維：OpenStack可以提供一定的系統(tǒng)監(jiān)控能力；
- 人機(jī)交互：OpenStack提供人機(jī)接口，外界可通過(guò)API、CLI或圖形界面的方式與OpenStack進(jìn)行交互。
組件間交互是消息隊(duì)列，組件內(nèi)部交互是restful api。
虛擬化
Ⅰ型虛擬化是：hypervisor直接安裝在物理機(jī)，就像是vmware的EXSi，底下是基于硬件層的
Ⅱ型虛擬化是：在物理機(jī)的正常操作系統(tǒng)，hypersivor作為一個(gè)程序模塊運(yùn)行管理虛擬機(jī)，如kvm，virtual box，vmware woerkstation。對(duì)硬件虛擬化特別優(yōu)化，性能好，靈活性高。
kvm
基于linux內(nèi)核實(shí)現(xiàn)的。有一個(gè)kvm.so，只需好管理虛擬cpu和內(nèi)存等；IO外設(shè)交給linux內(nèi)核和Qemu。
Libvirt是一個(gè)kvm管理工具，除了能管理kvm還可以xen，virtualBox，openstack底層也是libvirt。
libvirt：
- libvirtd：守護(hù)進(jìn)程：接受處理API請(qǐng)求
- API庫(kù)：提供API調(diào)用，然后開發(fā)一些高級(jí)工具，比如virt-manager，可視化管理工具
- virsh：命令行工具
kvm虛擬機(jī)是需要CPU硬件支持的，一個(gè)kvm虛擬機(jī)實(shí)質(zhì)上就是一個(gè)qemu-kvm進(jìn)程，一個(gè)vcpu對(duì)應(yīng)一個(gè)進(jìn)程里的一個(gè)線程。一個(gè)cpu可以調(diào)度進(jìn)程里的多個(gè)線程，也就是cvpu數(shù)量實(shí)際上可以超過(guò)cpu，叫CPU超配。可以充分利用宿主機(jī)的資源。
通過(guò)內(nèi)存虛擬化共享物理系統(tǒng)內(nèi)存，動(dòng)態(tài)分配給虛擬機(jī)。實(shí)現(xiàn)虛擬內(nèi)存->物理內(nèi)存->機(jī)器內(nèi)存的映射。虛擬機(jī)系統(tǒng)只能實(shí)現(xiàn)虛擬內(nèi)存到物理內(nèi)存，最后一步無(wú)法真正訪問(wèn)機(jī)器內(nèi)存，因此需要kvm進(jìn)行一個(gè)映射。
存儲(chǔ)虛擬化通過(guò)存儲(chǔ)池和卷實(shí)現(xiàn)的，卷在虛擬機(jī)里就是一塊硬盤。
網(wǎng)絡(luò)虛擬化
Linex Bridge是Linux上的TCP/IP二層協(xié)議交換設(shè)備，二層交換機(jī)，多個(gè)網(wǎng)絡(luò)設(shè)備連接到同一個(gè)bridge時(shí)，有數(shù)據(jù)包傳來(lái)beidge會(huì)轉(zhuǎn)發(fā)給其他設(shè)備。
br-ctl show查看當(dāng)前網(wǎng)橋配置。
比如在eth0網(wǎng)卡上配置一個(gè)網(wǎng)橋br0，然后虛擬機(jī)的網(wǎng)卡可以選擇br0，啟動(dòng)以后，br0底下會(huì)掛載一個(gè)inet0的設(shè)備，這就是虛擬機(jī)的虛擬網(wǎng)卡，但是在虛擬機(jī)內(nèi)部來(lái)說(shuō)虛擬網(wǎng)卡時(shí)eth0，inet0是在宿主機(jī)的時(shí)候標(biāo)識(shí)的名稱。
virbr0是kvm默認(rèn)創(chuàng)建的一個(gè)Bridge，作用是給連接的虛擬網(wǎng)卡提供NAT訪問(wèn)外網(wǎng)的功能，默認(rèn)192.168.122.1，如果網(wǎng)絡(luò)選擇默認(rèn)，就會(huì)掛載在這個(gè)上面。
virbr和br的區(qū)別：
- virbr會(huì)NAT，發(fā)出去的數(shù)據(jù)包的源IP會(huì)被替換為宿主機(jī)的IP，只能發(fā)不能收
- br直接使用自己的IP通信，可收可發(fā)，不用NAT
VLAN
LAN是本地局域網(wǎng)，通產(chǎn)使用hub或者switch連接其中的主機(jī)。一個(gè)LAN是一個(gè)廣播域，所有成員都能收到其他成員的廣播包。
VLAN是Virtual LAN，一個(gè)帶有VLAN功能的switch可以將端口劃分出很多個(gè)LAN。可以將一個(gè)交換機(jī)劃分為多個(gè)交換機(jī)，在二層進(jìn)行隔離，隔離到不同VLAN中。
一般交換機(jī)端口有兩種配置方式
- Access：端口被打上VLAN標(biāo)簽，表明該端口是屬于哪個(gè)VLAN的，不同VLAN通過(guò)VLANID區(qū)分，范圍是1~4096.Access口是直接和網(wǎng)卡相連接的。Access口只能屬于一個(gè)VLAN，網(wǎng)卡流出的數(shù)據(jù)包經(jīng)過(guò)這個(gè)端口后直接打上一個(gè)VLAN標(biāo)簽
- Trunk：一個(gè)端口可以同時(shí)傳輸轉(zhuǎn)發(fā)多個(gè)VLAN標(biāo)簽的數(shù)據(jù)包，在傳輸?shù)倪^(guò)程中數(shù)據(jù)包始終攜帶VLAN ID
總結(jié)：
基本技術(shù)
Memcached
是一個(gè)高性能分布式內(nèi)存對(duì)象緩存系統(tǒng)，在OpenStack中用于緩存認(rèn)證系統(tǒng)的令牌，減少高并發(fā)下對(duì)于數(shù)據(jù)庫(kù)的訪問(wèn)壓力，提高訪問(wèn)速度。
將需要存取的數(shù)據(jù)或?qū)ο缶彺嬖趦?nèi)存中，內(nèi)存中緩存數(shù)據(jù)可以通過(guò)API進(jìn)行操作，數(shù)據(jù)經(jīng)過(guò)Hash操作以后存在一個(gè)Hash表中，是K-V形式存儲(chǔ)。
memcached沒(méi)有訪問(wèn)控制和安全管理，因此需要使用防火墻等安全功能進(jìn)行相應(yīng)防護(hù)
使用最近最少使用算法LRU對(duì)最近不活躍的數(shù)據(jù)進(jìn)行清理，從而得到新的內(nèi)存空間。
對(duì)于大規(guī)模數(shù)據(jù)緩存有著較為明顯的優(yōu)勢(shì)而且通過(guò)開放API多種語(yǔ)言可以直接操作memcached。OpenStack的keystone就是用memcached緩存租戶的身份等信息、從而在租戶登錄驗(yàn)證的時(shí)候無(wú)需重復(fù)訪問(wèn)數(shù)據(jù)庫(kù)即可查詢得到相應(yīng)數(shù)據(jù)。Horizon和Swift也用到了這個(gè)來(lái)進(jìn)行數(shù)據(jù)的緩存以提高客戶端的訪問(wèn)請(qǐng)求速率。
操作的過(guò)程
- 檢查數(shù)據(jù)是否存在memcached，如果有直接返回
- 如果數(shù)據(jù)不存在memcached，去數(shù)據(jù)庫(kù)查詢，同時(shí)將數(shù)據(jù)庫(kù)緩存到memcached
- 每次更新數(shù)據(jù)庫(kù)的時(shí)候同步更新memcached的數(shù)據(jù)保證一致性
- 如果分配的內(nèi)存空間滿了，使用LRU算法對(duì)失效的數(shù)據(jù)進(jìn)行處理
功能特點(diǎn)
- 協(xié)議簡(jiǎn)單：基于文本行進(jìn)行操作
- 基于libevent事件處理：將epoll等事件處理封裝成一個(gè)接口，保證服務(wù)器端的連接數(shù)，使用這個(gè)庫(kù)進(jìn)行異步事件處理
- 內(nèi)置的內(nèi)存管理方式：有自己特有的一套內(nèi)存管理方式，很高效；但是不考慮容災(zāi)，重啟數(shù)據(jù)丟失
- 節(jié)點(diǎn)之間相互獨(dú)立：各個(gè)服務(wù)器之間互不通信，獨(dú)立存取數(shù)據(jù)不共享，通過(guò)客戶端實(shí)現(xiàn)其分布式，支持海量緩存和大規(guī)模應(yīng)用
缺點(diǎn)
- 單點(diǎn)故障：因?yàn)槊總€(gè)節(jié)點(diǎn)是獨(dú)立存取數(shù)據(jù)的，服務(wù)器之間沒(méi)有通信，即不會(huì)進(jìn)行數(shù)據(jù)的同步和備份，如果一個(gè)節(jié)點(diǎn)down了，節(jié)點(diǎn)的數(shù)據(jù)全部丟失且無(wú)法恢復(fù)
- 存儲(chǔ)空間限制：會(huì)受到尋址空間大小限制，32位系統(tǒng)可緩存2G，64位可緩存無(wú)限，只要物理內(nèi)存足夠大
- 存儲(chǔ)單元限制：K-V的key最大250字節(jié)，value最大1MB
- 數(shù)據(jù)碎片：內(nèi)存存儲(chǔ)單元按照Chunk分配的，會(huì)造成內(nèi)存碎片，因?yàn)椴豢赡芩写鎯?chǔ)的value大小都是一個(gè)Chunk大小
- 不安全
Etcd
是一個(gè)go語(yǔ)言開發(fā)的開源的高可用的K-V存儲(chǔ)系統(tǒng)，用于配置共享和服務(wù)的注冊(cè)和發(fā)現(xiàn)。
集群部署一般使用奇數(shù)個(gè)服務(wù)器配置，因?yàn)镽aft決策時(shí)候需要多節(jié)點(diǎn)投票。
有幾個(gè)特點(diǎn)：
- 高可用：避免因?yàn)閱吸c(diǎn)故障或者網(wǎng)絡(luò)故障造成服務(wù)down
- 一致性：每次讀取都會(huì)返回跨多個(gè)主機(jī)的最新寫入
- 完全復(fù)制：每個(gè)節(jié)點(diǎn)都可以使用完整數(shù)據(jù)歸檔
- 安全：提供一個(gè)帶有可選的客戶端證書身份驗(yàn)證的自動(dòng)化TLS
- 快速：每秒一萬(wàn)次寫入的基準(zhǔn)速度
- 可靠：使用Raft算法實(shí)現(xiàn)強(qiáng)一致、高可用的服務(wù)存儲(chǔ)目錄
應(yīng)用場(chǎng)景
- 服務(wù)發(fā)現(xiàn)：同一個(gè)分布式集群中找到是否有進(jìn)程在監(jiān)聽端口
- 配置中心：講一些數(shù)據(jù)放在Etcd集中管理，比如在啟動(dòng)的時(shí)候主動(dòng)從etcd獲取配置信息，并且設(shè)置一個(gè)Watcher，有更新的時(shí)候etcd會(huì)主動(dòng)通知訂閱者獲取最新配置信息
- 分布式鎖：使用Raft實(shí)現(xiàn)數(shù)據(jù)的強(qiáng)一致性，某次操作存儲(chǔ)必須是全局一致性的。有兩種：保持獨(dú)占（始終只有一個(gè)用戶可以獲得，實(shí)現(xiàn)了一套分布式原子操作CAS的API）、控制時(shí)序（所有想獲得鎖的用戶都會(huì)被安排執(zhí)行，獲得鎖的順序也是全局唯一，決定了執(zhí)行的順序）
相比榮譽(yù)zookeeper和doozer，有如下特點(diǎn)：
- 簡(jiǎn)單：基于HTTP+JSON，提供API便于調(diào)用
- 安全：使用SSL客戶認(rèn)證機(jī)制
- 快速：實(shí)例每秒支持一萬(wàn)次寫操作
- 可信：Raft算法實(shí)現(xiàn)分部署
消息隊(duì)列
rabbitmq屬于AMQP（高級(jí)消息隊(duì)列協(xié)議）的一種實(shí)現(xiàn)，應(yīng)用層的一個(gè)開放標(biāo)準(zhǔn)。
特點(diǎn)：
- 較高的靈活性
- 高可擴(kuò)展性，多個(gè)rabbitmq可以組成集群
- 支持常見的編程語(yǔ)言
- 提供可視化界面便于管理
- 支持多種協(xié)議，不只是AMQP
- 提供了多種插件
AMQP的三大組件：
- Exchange交換機(jī)：把消息路由到隊(duì)列
- Queue隊(duì)列：存儲(chǔ)消息等待消費(fèi)，多個(gè)消費(fèi)者可以訂閱同一個(gè)隊(duì)列
- Binding綁定：將交換機(jī)和隊(duì)列進(jìn)行綁定，告知交換機(jī)應(yīng)該投遞到哪個(gè)隊(duì)列
優(yōu)點(diǎn)：
- 異步：如果阻塞式的話，A給B發(fā)請(qǐng)求，B如果處理需要很長(zhǎng)時(shí)間，那么A也需要等待很久，顯然是不合理的，還會(huì)資源浪費(fèi)，可以通過(guò)消息隊(duì)列先發(fā)送一個(gè)請(qǐng)求命令給B ，然后A直接進(jìn)行下一步，當(dāng)B有結(jié)果時(shí)會(huì)通知A
- 解耦：如果每一個(gè)組件之間通過(guò)直接通信的話，都需要維護(hù)一套比如接口代碼，會(huì)有很多重復(fù)冗余的代碼，，而且還需要考慮比如對(duì)方是否接到消息，消息是否丟失之類的。使用消息隊(duì)列就不需要考慮這些了，把消息投遞進(jìn)入就好了，剩下的消息隊(duì)列做
- 削鋒：如果短時(shí)間內(nèi)有大量請(qǐng)求直接到服務(wù)器，可能會(huì)造成擁塞甚至崩潰。放入消息隊(duì)列里，消費(fèi)者可以依次取出消息進(jìn)行消費(fèi)，相當(dāng)于一個(gè)緩沖，雖然會(huì)慢一點(diǎn)，但是會(huì)很高效穩(wěn)定
概念
有幾個(gè)概念關(guān)鍵詞
- Exchange：消息交換機(jī)，它指定消息按什么規(guī)則，路由到哪個(gè)隊(duì)列
- Queue：消息隊(duì)列載體，每個(gè)消息都會(huì)被投入到一個(gè)或多個(gè)隊(duì)列，多個(gè)消費(fèi)者可以訂閱同一個(gè)隊(duì)列
- Binding：綁定，它的作用就是把exchange和queue按照路由規(guī)則綁定起來(lái)
- Routing Key：路由關(guān)鍵字， exchange根據(jù)這個(gè)關(guān)鍵字進(jìn)行消息投遞
- producer：消息生產(chǎn)者，就是投遞消息的程序
- consumer：消息消費(fèi)者，就是接受消息的程序
- channel：消息通道，在客戶端的每個(gè)連接里，可建立多個(gè)channel，每個(gè)channel代表一個(gè)會(huì)話任務(wù)。
交換機(jī)類型
- Direct Exchange（直連交換機(jī)）：交換機(jī)和隊(duì)列一對(duì)一匹配
- Fanout Exchange（扇型交換機(jī)）：消息會(huì)被發(fā)送至所有與該交換機(jī)綁定的隊(duì)列，不會(huì)按照指定的路由鍵進(jìn)行投遞，類似廣播
- Topic Exchange（主題交換機(jī)）：交換機(jī)會(huì)將消息的路由鍵和綁定到自身的隊(duì)列進(jìn)行匹配，將消息投遞到匹配上的隊(duì)列中去。比如如果寫成這樣log.#，那么可以匹配log.開頭的routingkey
- Headers Exchange：類似主題交換機(jī)，但是是使用消息頭部的屬性進(jìn)行分發(fā)，而不是routingkey
缺點(diǎn)
系統(tǒng)可用性降低，rabbitmq掛了以后系統(tǒng)就崩了。
如何解決消息重復(fù)投遞或者丟失的問(wèn)題
如何解決消息按順序發(fā)送的問(wèn)題
重復(fù)投遞問(wèn)題
給每一個(gè)消息設(shè)置一個(gè)類似唯一標(biāo)識(shí)的一個(gè)ID，接收者去除消息以后先在數(shù)據(jù)庫(kù)中對(duì)比一下是否存在，如果不存在，就正常消費(fèi)。
順序投遞問(wèn)題
還是使用一個(gè)ID，一般這個(gè)會(huì)出現(xiàn)在比如說(shuō)訂單的場(chǎng)景，生成訂單，制作訂單，訂單號(hào)都是一樣的，把這些消息投遞到一個(gè)訂單隊(duì)列里面，取出的時(shí)候就是順序的了。
restful api
restful api是一種軟件架構(gòu)設(shè)計(jì)的風(fēng)格，不是標(biāo)準(zhǔn)，提供了一組設(shè)計(jì)的原則和約束條件，是一套編寫接口的協(xié)議，協(xié)議規(guī)定如何編寫，返回值和狀態(tài)碼等，主要用于客戶端和服務(wù)器端的交互。
最顯著的特點(diǎn)就是一個(gè)url可以通過(guò)不同的HTTP方法實(shí)現(xiàn)不同的功能，而no rest則需要使用多個(gè)url分別實(shí)現(xiàn)多個(gè)功能。
- 還可以使用https
- 不同版本可以有不同接口
- 可以根據(jù)不同http方法執(zhí)行不同操作
- 返回格式應(yīng)該統(tǒng)一為json，還有狀態(tài)碼
django中的erest框架叫django rest framework
能夠生成符合restful規(guī)范的api
- 在開發(fā)restful api的時(shí)候，雖然具體業(yè)務(wù)流程不一樣，但是基本增刪改查操作差不多，這部分代碼可以簡(jiǎn)寫復(fù)用
- 序列化和反序列化的時(shí)候代碼流程也差不多，，也可以簡(jiǎn)寫
傳統(tǒng)的URL需要在鏈接里加上操作的動(dòng)作等；
而restful api則用URI統(tǒng)一資源標(biāo)識(shí)符唯一標(biāo)識(shí)服務(wù)器的一個(gè)資源，并且使用HTTP方法對(duì)其進(jìn)行操作
Horizon
提供一個(gè)Web前端控制臺(tái),從而實(shí)現(xiàn)通過(guò)web管理云平臺(tái)，建云主機(jī)，分配網(wǎng)絡(luò)，配安全組等。
Region（區(qū)域）：地理上的概念可以理解為是兩個(gè)不同區(qū)域的數(shù)據(jù)中心，是完全隔離的，但是可以共享同一套keystone和horizon了用戶可以選擇距離自己更近的域使用服務(wù)
Nova
端口
- nova-api：通過(guò)接口對(duì)外提供服務(wù)，接受請(qǐng)求處理操作調(diào)度資源等。接收傳來(lái)的HTTP請(qǐng)求校驗(yàn)參數(shù)，然后調(diào)用其他子服務(wù)實(shí)現(xiàn)請(qǐng)求操作，之后處理結(jié)果返回
- nova-compute：Nova的核心服務(wù)，，負(fù)責(zé)管理虛擬機(jī)的整個(gè)生命周期如創(chuàng)建相應(yīng)銷毀等，通過(guò)調(diào)用Hypervisor API
- nova-scheduler：虛擬機(jī)調(diào)度服務(wù)，決定虛擬機(jī)應(yīng)該創(chuàng)建在哪個(gè)節(jié)點(diǎn)。通過(guò)過(guò)濾器選擇合適的計(jì)算節(jié)點(diǎn)，然后計(jì)算節(jié)點(diǎn)權(quán)重，選擇最優(yōu)的節(jié)點(diǎn)（默認(rèn)權(quán)值是計(jì)算空閑內(nèi)存量，內(nèi)存越大權(quán)值越大）
- nova-conductor：負(fù)責(zé)數(shù)據(jù)庫(kù)的訪問(wèn)控制，避免compute直接訪問(wèn)數(shù)據(jù)庫(kù)。避免計(jì)算節(jié)點(diǎn)出現(xiàn)故障導(dǎo)致數(shù)據(jù)庫(kù)出現(xiàn)問(wèn)題，可以擴(kuò)展配置多個(gè)conductor更好的應(yīng)對(duì)更多計(jì)算節(jié)點(diǎn)對(duì)于數(shù)據(jù)庫(kù)的訪問(wèn)
創(chuàng)建一個(gè)虛擬機(jī)大概的流程：
這里的消息發(fā)送全部都是通過(guò)消息隊(duì)列實(shí)現(xiàn)的，進(jìn)行異步調(diào)用，不會(huì)阻塞服務(wù)；解耦各個(gè)子模塊功能；提高可擴(kuò)展性；提高性能，可以處理多個(gè)請(qǐng)求，提高吞吐量
使用API的好處：
- 對(duì)外提供了一個(gè)統(tǒng)一的調(diào)用方法，隱藏實(shí)現(xiàn)細(xì)節(jié)
- 提供了restful風(fēng)格的服務(wù)，便于和第三方集成
- 通過(guò)運(yùn)行多個(gè)api進(jìn)程實(shí)現(xiàn)高可用
OpenStack的開放性，一個(gè)重要方面就是基于Driver的框架。比如說(shuō)nov-acompute中為hypervisor定義了統(tǒng)一的接口，支持多種Hypervisor，如Xen、VirtualBox、Hyper-V、Docker等
nova-api
對(duì)外暴露若干個(gè)Restful API，用戶可以發(fā)送請(qǐng)求到指定Endpoint
- 收到HTTP請(qǐng)求后，會(huì)先進(jìn)行參數(shù)校驗(yàn)
- 調(diào)用nova其他子服務(wù)開始執(zhí)行相應(yīng)操作
- 再返回執(zhí)行的結(jié)果
和虛擬機(jī)生命周期的指定請(qǐng)求nova-api都可以收到并處理。
nova-scheduler
在創(chuàng)建虛擬機(jī)的時(shí)候需要指定一個(gè)flavor也就是規(guī)格，其中規(guī)定了vcpu、ram、disk等參數(shù)，隨后將falvor信息傳入到noca-scheduler中，會(huì)根據(jù)flavor選擇一個(gè)合適的節(jié)點(diǎn)創(chuàng)建虛擬機(jī)。
Filer scheduler是默認(rèn)調(diào)度器，過(guò)程分為兩步，第一是通過(guò)過(guò)濾器計(jì)算出滿足條件的計(jì)算節(jié)點(diǎn)，通過(guò)權(quán)重計(jì)算，在權(quán)重最大（最優(yōu)）的節(jié)點(diǎn)創(chuàng)建虛擬機(jī)。
同樣可以使用第三方的scheduler，只需要配置一個(gè)scheduler_driver即可，再次體現(xiàn)出OpenStack開放性。
過(guò)濾器類型
nova可以配置默認(rèn)使用全部過(guò)濾器acheduler_availiable_filters，但是真正使用到的是這個(gè)參數(shù)scheduler_default_filters
- RetryFilter：如果AB節(jié)點(diǎn)通過(guò)了第一步過(guò)濾，然后A權(quán)重最大，但是在A創(chuàng)建失敗了，那么下一次調(diào)度的時(shí)候，就會(huì)在第一步將A刷掉，避免再次失敗
- AvailabilityZoneFilter：為了提高容災(zāi)和隔離，將計(jì)算節(jié)點(diǎn)可以劃分到不同的AvailablittZone中，每個(gè)AZ都可能有著各自獨(dú)立的電力系統(tǒng)、獨(dú)立的網(wǎng)絡(luò)和機(jī)柜等，為了應(yīng)對(duì)故障的發(fā)生，一個(gè)Region可以有多個(gè)AZ，默認(rèn)是nova。這里會(huì)判斷將不屬于指定AZ的計(jì)算節(jié)點(diǎn)刪除
- RamFilter：將不滿足flavor中內(nèi)存規(guī)格的計(jì)算節(jié)點(diǎn)除去。OpenStack允許overcommit，可以在nova里面改這個(gè)參數(shù)ram_allocation_ratio=1.5，如果某個(gè)計(jì)算節(jié)點(diǎn)有10G內(nèi)存，OpenStack會(huì)認(rèn)為其有15G內(nèi)存
- DiskFilter：同上，同樣允許overcommit，默認(rèn)參數(shù)值為1
- CPUFilter：同上，允許overcommit，默認(rèn)參數(shù)值為16.也就是如果一個(gè)計(jì)算節(jié)點(diǎn)有8vcpu，那么OpenStack會(huì)默認(rèn)其有128vcpu。默認(rèn)過(guò)濾器是不包含這個(gè)過(guò)濾器，需要手動(dòng)添加
- ComputeFilter：保證工作正常的計(jì)算節(jié)點(diǎn)才會(huì)被篩選出來(lái)，是必須的一個(gè)過(guò)濾器
- ComputeCapabilitiesFilter：根據(jù)計(jì)算節(jié)點(diǎn)的特性篩選，如計(jì)算節(jié)點(diǎn)有x86_64和ARM架構(gòu)，如果指定ARM架構(gòu)，就需要這個(gè)過(guò)濾器，這個(gè)需要在flavor的Metadata中指定
- ImagePropertiesFilter：image同樣具有metadata，根據(jù)這個(gè)元數(shù)據(jù)篩選出匹配的計(jì)算節(jié)點(diǎn)。比如可以選擇hypervisor_type=kvm，那么使用這個(gè)鏡像過(guò)濾就只能篩選出kvm的節(jié)點(diǎn)
- ServerGroupAntiAffinityFilter：盡可能將實(shí)例分散到不同的節(jié)點(diǎn)上。需要?jiǎng)?chuàng)建一份server group，把實(shí)例添加進(jìn)來(lái)才有用
- ServerGroupAffinityFilter：盡可能創(chuàng)建實(shí)例在一個(gè)計(jì)算節(jié)點(diǎn)上。
nova-compute
compute和hypervisor一起共同管理虛擬機(jī)生命周期。
定義了很多統(tǒng)一的接口，hypervisor實(shí)現(xiàn)這些接口就可以在openstack里面了。
一個(gè)計(jì)算節(jié)點(diǎn)只能指定一種虛擬類型。
主要有兩種功能：
- 報(bào)告計(jì)算節(jié)點(diǎn)狀態(tài)
- 實(shí)現(xiàn)虛擬機(jī)生命周期管理
需要實(shí)時(shí)報(bào)告計(jì)算節(jié)點(diǎn)可用內(nèi)存、vcpu等數(shù)量，scheduler才可有進(jìn)行過(guò)濾調(diào)度的依據(jù)，通過(guò)hypervisor api獲取虛虛擬機(jī)的資源信息。
管理生命周期包括如下：
- 為實(shí)例準(zhǔn)備資源
- 創(chuàng)建實(shí)例鏡像文件
- 創(chuàng)建實(shí)例的.xml定定義文件
- 創(chuàng)建網(wǎng)絡(luò)并啟動(dòng)實(shí)例
在下載鏡像的時(shí)候，如果存在就直接使用，會(huì)很快，不存在會(huì)先下載。比如是qcow2格式的鏡像，由qemu-img轉(zhuǎn)為raw格式然后進(jìn)行backing file，這個(gè)不能是qcow2格式。
基本操作
- 軟硬重啟其實(shí)就分別是reboot重啟和關(guān)機(jī)再開機(jī)
- Pause/Resume：可以暫停虛擬機(jī)，并將狀態(tài)保存到內(nèi)存中，需要的時(shí)候再resume讀取內(nèi)存恢復(fù)虛擬機(jī)
- Suspend和Pause：前者可以暫停虛擬機(jī)并將狀態(tài)保存在磁盤上，后者保存到內(nèi)存中，相對(duì)較快；前者狀態(tài)會(huì)變成shutdown，后者是paused；前者對(duì)應(yīng)的恢復(fù)操作叫resume，后者其實(shí)是unpaused
- rescure/Unrecure：救援。當(dāng)因?yàn)閿嚯娀蛘哒`操作導(dǎo)致操作系統(tǒng)出現(xiàn)故障不能啟動(dòng)實(shí)例了，一般會(huì)使用一張引導(dǎo)盤進(jìn)入系統(tǒng)，然后試圖恢復(fù)系統(tǒng)，比如忘記密碼或者刪除了某個(gè)文件。rescure可以將某個(gè)image作為啟動(dòng)盤，然就將原系統(tǒng)盤掛載到這個(gè)操作系統(tǒng)上，fdisk可以看到，新的image是vda，原系統(tǒng)盤就是vdb，修好以后unrescure恢復(fù)引導(dǎo)盤
- snapshot：快照的原理就是對(duì)實(shí)例的鏡像文件進(jìn)行全量備份，保存到glance。
- rebuild：當(dāng)損壞嚴(yán)重的時(shí)候，可以使用快照恢復(fù)。rebuild會(huì)使用快照替換當(dāng)前實(shí)例的系統(tǒng)盤，并且保持實(shí)例原有的網(wǎng)絡(luò)、資源等信息
Keystone
常用的5000端口，以及沒(méi)怎么用過(guò)的35357端口
為OpenStack其他服務(wù)提供身份驗(yàn)證、服務(wù)規(guī)則和服務(wù)令牌的功能，管理Domains、Projects、Users、Groups、Roles。
- User：代指任何使用gopenstack的實(shí)體，可以是真正的用戶，也可以是一個(gè)系統(tǒng)服務(wù)，在訪問(wèn)openstack的時(shí)候，keystone會(huì)對(duì)User進(jìn)行身份認(rèn)證
- Credentials：User用來(lái)表明自己身份的憑證，可以是用戶名密碼、token或者API Key等
- Authentication：是keystone驗(yàn)證User身份的一個(gè)過(guò)程，User訪問(wèn)openstack的時(shí)候向keystone發(fā)送用戶名密碼等信息，keystone驗(yàn)證成功后返回一個(gè)token，作為用戶的Credentials
- Token：是一串?dāng)?shù)字和字母組成的字符串，用戶在keystone驗(yàn)證身份后會(huì)得到，在訪問(wèn)其他服務(wù)的時(shí)候會(huì)被用來(lái)驗(yàn)證身份有效性，一般默認(rèn)24小時(shí)。
- Project：用于將OpenStack的資源進(jìn)行分組和隔離，可以是一個(gè)客戶或者部門。一個(gè)用戶需要掛載到Project后才能訪問(wèn)其中的資源
- Service：Nova、Glance等就是OpenStack的服務(wù)，每個(gè)Service會(huì)提供若干個(gè)Endpoints供用戶去訪問(wèn)資源和執(zhí)行操作
- Endpoint：是一個(gè)可以訪問(wèn)的地址，通過(guò)Endpoint暴露自己的API，keystone維護(hù)
- Role：對(duì)用戶進(jìn)行鑒權(quán)，每個(gè)User會(huì)被分配一個(gè)或多個(gè)Role，該用戶擁有Role指定的權(quán)限。如果修改權(quán)限需要修改/etc{service_name}/policy.json
Glance
監(jiān)聽端口：
- glance-api：9292
- glance-registry：9191
傳統(tǒng)的安裝一個(gè)系統(tǒng)可能需要從CD或者ghost工具進(jìn)行安裝，非常繁瑣。二運(yùn)計(jì)算環(huán)境中有一個(gè)更高效地解決方案，就是Image。
每個(gè)Image中裝有操作系統(tǒng)以及相應(yīng)的配套軟件環(huán)境，用戶可以直接使用安裝即可快速創(chuàng)建一個(gè)虛擬機(jī)。
比如云計(jì)算中可以有這么一個(gè)場(chǎng)景：當(dāng)我們需要有一個(gè)新的系統(tǒng)需求的時(shí)候，我們可以先手動(dòng)創(chuàng)建一個(gè)虛擬機(jī)然后安裝好相應(yīng)的操作系統(tǒng)和需要的軟件環(huán)境，然后創(chuàng)建一個(gè)snapshot保存在云中，后續(xù)如果有用戶需要使用可以直接使用這個(gè)snapshot快速創(chuàng)建虛擬機(jī)，這都是可以自動(dòng)完成了。
為云主機(jī)提供不同系統(tǒng)鏡像，支持多種虛擬機(jī)鏡像格式（AKI、AMI、ARI、ISO、QCOW2、Raw、VDI、VHD、VMDK），有創(chuàng)建上傳鏡像、刪除鏡像、編輯鏡像基本信息的功能。
glance-api對(duì)外提供restful api接口調(diào)用，當(dāng)有請(qǐng)求來(lái)以后，api不會(huì)自己主動(dòng)處理，而是會(huì)調(diào)用glance-registry處理有關(guān)元數(shù)據(jù)的操作，調(diào)用store backend處理有關(guān)鏡像的操作。
Image默認(rèn)存儲(chǔ)在/var/lib/glance/images。
glance-registry負(fù)責(zé)處理有關(guān)metadata的操作，如存取。比如image的大小或者類型，支持多種格式：QCOW2、RAW、vmdk、ISO等，元數(shù)據(jù)默認(rèn)保存到mysql
store-backend：glance自己不保存鏡像，而是使用backend存儲(chǔ)，glance支持多種backend，如默認(rèn)的local filesystem本地文件系統(tǒng)、ceph、swift、cinder、EXSI等
Neutron
端口9292
提供云計(jì)算的網(wǎng)絡(luò)虛擬化技術(shù)，為OpenStack其他服務(wù)提供網(wǎng)絡(luò)連接服務(wù)。為用戶提供接口，可以定義Network、Subnet、Router，配置DHCP、DNS、負(fù)載均衡、L3服務(wù)，網(wǎng)絡(luò)支持GRE、VLAN。插件架構(gòu)支持許多主流的網(wǎng)絡(luò)廠家和技術(shù)，如OpenvSwitch。
根據(jù)網(wǎng)絡(luò)類型的不同有以下幾種網(wǎng)絡(luò)：
- Flat network：基于不使用 VLAN 的物理網(wǎng)絡(luò)實(shí)現(xiàn)的虛擬網(wǎng)絡(luò)。每個(gè)物理網(wǎng)絡(luò)最多只能實(shí)現(xiàn)一個(gè)虛擬網(wǎng)絡(luò)。
- local network（本地網(wǎng)絡(luò)）：一個(gè)只允許在本服務(wù)器內(nèi)通信的虛擬網(wǎng)絡(luò)，不進(jìn)行跨服務(wù)器的通信。主要用于單節(jié)點(diǎn)上測(cè)試。
- VLAN network（虛擬局域網(wǎng)） ：基于物理 VLAN 網(wǎng)絡(luò)實(shí)現(xiàn)的虛擬網(wǎng)絡(luò)。共享同一個(gè)物理網(wǎng)絡(luò)的多個(gè) VLAN 網(wǎng)絡(luò)是相互隔離的，甚至可以使用重疊的 IP 地址空間。每個(gè)支持 VLAN network 的物理網(wǎng)絡(luò)可以被視為一個(gè)分離的 VLAN trunk，它使用一組獨(dú)占的 VLAN ID。有效的 VLAN ID 范圍是 1 到 4094。
- GRE network （通用路由封裝網(wǎng)絡(luò)）：一個(gè)使用 GRE 封裝網(wǎng)絡(luò)包的虛擬網(wǎng)絡(luò)。GRE 封裝的數(shù)據(jù)包基于 IP 路由表來(lái)進(jìn)行路由，因此 GRE network 不和具體的物理網(wǎng)絡(luò)綁定。
- VXLAN network（虛擬可擴(kuò)展網(wǎng)絡(luò)）：基于 VXLAN 實(shí)現(xiàn)的虛擬網(wǎng)絡(luò)。同 GRE network 一樣， VXLAN network 中 IP 包的路由也基于 IP 路由表，也不和具體的物理網(wǎng)絡(luò)綁定。
網(wǎng)絡(luò)轉(zhuǎn)發(fā)
一般架構(gòu)是控制節(jié)點(diǎn)、計(jì)算節(jié)點(diǎn)和網(wǎng)絡(luò)節(jié)點(diǎn)。
網(wǎng)絡(luò)節(jié)點(diǎn)就dhcp服務(wù)之類的，計(jì)算節(jié)點(diǎn)是各種agent，控制節(jié)點(diǎn)是neutron-server一個(gè)組件。
然后如果跨子網(wǎng)通信的話，流量需要從計(jì)算節(jié)點(diǎn)到網(wǎng)絡(luò)節(jié)點(diǎn)，通過(guò)router路由一下，轉(zhuǎn)發(fā)到對(duì)應(yīng)的計(jì)算節(jié)點(diǎn)的實(shí)例上。而如果需要配置NAT的話是需要在router上面配置的，也就是網(wǎng)路節(jié)點(diǎn)，如果有需要流量轉(zhuǎn)發(fā)出去的話，都需要通過(guò)網(wǎng)絡(luò)節(jié)點(diǎn)。
但是這樣的話網(wǎng)絡(luò)節(jié)點(diǎn)的壓力就比較大，一旦網(wǎng)絡(luò)節(jié)點(diǎn)崩潰了，整個(gè)網(wǎng)絡(luò)就崩了；還有一個(gè)就是即便兩個(gè)實(shí)例在同一個(gè)計(jì)算節(jié)點(diǎn)上，如果不在一個(gè)網(wǎng)絡(luò)中，還需要經(jīng)過(guò)網(wǎng)絡(luò)節(jié)點(diǎn)路由一下才能回來(lái)，很麻煩。
那么就有一個(gè)東西DVR(Distributed Virtual Routing)，部署在計(jì)算節(jié)點(diǎn)，可以直接使用浮動(dòng)IP訪問(wèn)外網(wǎng)，不需要經(jīng)過(guò)網(wǎng)絡(luò)節(jié)點(diǎn)了。是通過(guò)openflow規(guī)則進(jìn)行判斷的。
Neutron功能：
- 二層交換：實(shí)例通過(guò)虛擬交換機(jī)連接到虛擬二層網(wǎng)絡(luò)，Nova支持多種交換機(jī)，Linux Bridge和OpenvSwitch（開源虛擬交換機(jī)）
- 三層路由：給實(shí)例配置不同網(wǎng)段的IP，router（虛擬路由器）可以實(shí)現(xiàn)跨網(wǎng)段通信，使用IP forwarding、iptables等實(shí)現(xiàn)路由和NAT
- 負(fù)載均衡
- 防火墻：一個(gè)是security group使用的iptables、另一個(gè)是firewall-as-a-service，也是基于iptables的
一些概念
- network：二層廣播域，支持多種類型網(wǎng)絡(luò)：local、flat、vlan、vxlan、gre
-
- local：這個(gè)網(wǎng)絡(luò)與其他網(wǎng)絡(luò)節(jié)點(diǎn)隔離，只能和同一節(jié)點(diǎn)的同一網(wǎng)絡(luò)實(shí)例通信
-
- flat：沒(méi)有vlan tag的網(wǎng)絡(luò)，網(wǎng)絡(luò)中的實(shí)例可以和其他實(shí)例通信
-
- vlan：802.1q標(biāo)簽的網(wǎng)絡(luò)，一個(gè)二層廣播域，同一個(gè)vlan中的實(shí)例可以相互通信，不同vlan只能通過(guò)router通信。vlan可以跨界點(diǎn)，標(biāo)簽數(shù)為1-4096
-
- vxlan：基于隧道技術(shù)的overlay網(wǎng)絡(luò)，VxLAN網(wǎng)絡(luò)使用唯一的段ID與其他VxLAN進(jìn)行隔離。會(huì)通過(guò)VNI封裝為UDP數(shù)據(jù)包傳輸，二層包通過(guò)封裝可以在三層傳輸，因此克服了物理網(wǎng)絡(luò)基礎(chǔ)設(shè)施的限制
-
- gre：是和VxLAN類似的overlay網(wǎng)絡(luò)，區(qū)別在于使用IP包封裝而不是UDP
一些虛擬的網(wǎng)絡(luò)設(shè)備
Veth pair
Veth是linux系統(tǒng)虛擬出來(lái)的一個(gè)網(wǎng)絡(luò)設(shè)備，總是成對(duì)出現(xiàn)的，功能類似虛擬網(wǎng)線的功能，在創(chuàng)建兩個(gè)Veth設(shè)備，假設(shè)放在兩個(gè)namespace里面，那么通過(guò)這個(gè)Veth設(shè)備可以實(shí)現(xiàn)相互通信，默認(rèn)情況下是不通的。
通常鏈接網(wǎng)絡(luò)的namespace，也鏈接linuxbridge，一般用于連接兩個(gè)linuxbridge或者一個(gè)linuxbridge和ovs，兩個(gè)ovs一般不太用這個(gè)，一般用patch連接兩個(gè)ovs bridge，效率更好。
實(shí)際操作
在這里創(chuàng)建一個(gè)新的namespace，然后創(chuàng)建一對(duì)Veth pair試一下，單純記錄，我沒(méi)有操作過(guò)。
TUN、TAP
Veth是兩端都一樣的虛擬網(wǎng)線，而這個(gè)就是兩端都不一樣的虛擬網(wǎng)先，相當(dāng)于一邊是水晶頭，另一端是USB接口，是用戶空間和內(nèi)核空間傳輸報(bào)文使用到的“網(wǎng)線”，一邊是普通的網(wǎng)卡比如eth0，另一端是文件描述符，用戶空間使用的。
實(shí)例的本質(zhì)是qemu進(jìn)程，因此TUN、TAP網(wǎng)線一般是給VM用的，所以這個(gè)文件描述符一般是VM，另一端則是虛擬出來(lái)的TAP設(shè)備，這也就是為什么Neutron幾種網(wǎng)絡(luò)模型里面的VM或者linuxbridge連接router的時(shí)候都是通過(guò)TAP設(shè)備的
Bridge
是一種虛擬集線器的實(shí)現(xiàn)方式，多個(gè)網(wǎng)卡連接到這個(gè)上面，一個(gè)發(fā)送報(bào)文其他都能接收到。
把TUN/TAP或者Veth pair放在Bridge上面，就可以實(shí)現(xiàn)相互通信。Docker就是用linuxbridge將所有的容器連接在一起，bridge模式，就是docekr0網(wǎng)卡
架構(gòu)
Neutron主要有以下幾個(gè)部分：
- Neutron Server：對(duì)外提供API，接收請(qǐng)求，調(diào)用Plugins處理請(qǐng)求
- Plugin：處理來(lái)自Server的請(qǐng)求，并且轉(zhuǎn)發(fā)調(diào)用Agent處理請(qǐng)求
- Agent：處理來(lái)自Plugin的請(qǐng)求，并且在network provider上具體實(shí)現(xiàn)每個(gè)網(wǎng)絡(luò)功能
- network provider：提供網(wǎng)絡(luò)服務(wù)的虛擬網(wǎng)絡(luò)設(shè)備或物理網(wǎng)絡(luò)設(shè)備，比如Linux Bridge或者OpenvSwitch或者其他支持Neutron的物理交換機(jī)
- Queue：組件之間交互的消息隊(duì)列
- Database：存放網(wǎng)絡(luò)狀態(tài)信息
架構(gòu)這么多層次有兩個(gè)原因
- 為了支持現(xiàn)有或者未來(lái)出現(xiàn)的網(wǎng)絡(luò)技術(shù)
- 為了支持分布式的靈活擴(kuò)展性
plugin有一個(gè)功能時(shí)需要維護(hù)數(shù)據(jù)庫(kù)中的網(wǎng)絡(luò)狀態(tài)信息，如果有多個(gè)插件的話，每一個(gè)provider的plugin都要寫一套類似的數(shù)據(jù)庫(kù)操作代碼，會(huì)很繁瑣，因此現(xiàn)有版本使用了ML2 plugin，對(duì)plugin進(jìn)行了抽象。只需要實(shí)現(xiàn)響應(yīng)driver就行了，不需要具體實(shí)現(xiàn)plugin了。
plugin主要分為兩種（均有對(duì)應(yīng)的agent）：
- core plugin：比如linux bridge或者openvswitch
- service plugin：比如routing、firewall、load balance等
物理架構(gòu)
有兩種。
第一種：控制節(jié)點(diǎn)+計(jì)算節(jié)點(diǎn)
控制節(jié)點(diǎn)配置neutron server、core plugin、service plugin和兩個(gè)對(duì)應(yīng)的agent
計(jì)算節(jié)點(diǎn)配置core plugin的agrnt，負(fù)責(zé)二層網(wǎng)絡(luò)功能。
通過(guò)agent實(shí)現(xiàn)控制節(jié)點(diǎn)和計(jì)算節(jié)點(diǎn)之間的二層網(wǎng)絡(luò)通信，可以部署多個(gè)控制節(jié)點(diǎn)和計(jì)算節(jié)點(diǎn)
第二種：控制節(jié)點(diǎn)+網(wǎng)絡(luò)節(jié)點(diǎn)+計(jì)算節(jié)點(diǎn)
控制節(jié)點(diǎn)配置neutron server
網(wǎng)絡(luò)節(jié)點(diǎn)配置core plugin、service plugin和對(duì)應(yīng)的agent
計(jì)算節(jié)點(diǎn)配置core plugin，負(fù)責(zé)二層網(wǎng)絡(luò)功能
- 將agent從控制節(jié)點(diǎn)分離出來(lái)，控制節(jié)點(diǎn)只通過(guò)neutron server處理分發(fā)api請(qǐng)求
- 可以通過(guò)增加網(wǎng)絡(luò)節(jié)點(diǎn)的個(gè)數(shù)提高負(fù)載
- 使用獨(dú)立的節(jié)點(diǎn)實(shí)現(xiàn)數(shù)據(jù)交換，并且可以配置路由、負(fù)載均衡等高級(jí)功能
- 適合大規(guī)模環(huán)境
Neutron Server
由上而下分別是
- Core API：對(duì)內(nèi)提供restful api，如管理子網(wǎng)網(wǎng)絡(luò)端口等
- Extension API：對(duì)外提供restful api，如管理router、firewall-as-a-service、負(fù)載均衡等
- Common Service：認(rèn)證校驗(yàn)API
- Core Plugin API：定義個(gè)Core Plugin抽象功能，通過(guò)API調(diào)用對(duì)應(yīng)plugin
- Neutron Core：Neutron的核心處理程序，調(diào)用相應(yīng)Plugin處理
- Extension Plugin API：定義。。。
- Service Plugin：維護(hù)管理router、負(fù)載均衡等資源狀態(tài)信息，調(diào)用agent在network privider上實(shí)現(xiàn)相應(yīng)功能
但是提出了兩個(gè)問(wèn)題
ML2 Plugin
主要解決上面說(shuō)的兩個(gè)問(wèn)題
允許網(wǎng)絡(luò)中使用多種二層網(wǎng)絡(luò)技術(shù)，不同節(jié)點(diǎn)直接按可以使用不同的網(wǎng)絡(luò)實(shí)現(xiàn)機(jī)制。
可以在不同節(jié)點(diǎn)上使用不同的agent了，而且不用重新開發(fā)core plugin，實(shí)現(xiàn)mechanism driver就可以了。
ML2對(duì)二層網(wǎng)絡(luò)進(jìn)行了抽象解耦，type driver和mechanism driver使得其具有非常好的彈性，能夠靈活支持多種agent（type或者mechanism）
每一種網(wǎng)絡(luò)都有這么兩種driver
Type Driver
負(fù)責(zé)管理網(wǎng)絡(luò)狀態(tài)、創(chuàng)建網(wǎng)絡(luò)等。
有這么集中網(wǎng)絡(luò)類型：local、flat、vlan、vxlan、gre
mechanism driver
獲取由type維護(hù)的網(wǎng)絡(luò)狀態(tài)，并且確保其在物理或者虛擬設(shè)備上的實(shí)現(xiàn)
比如創(chuàng)建一個(gè)VLAN100，VLAN的type driver負(fù)責(zé)將數(shù)據(jù)保存在數(shù)據(jù)庫(kù)里，然后linux bridge的mechanism driver負(fù)責(zé)在各個(gè)節(jié)點(diǎn)上調(diào)用agent創(chuàng)建相應(yīng)的vlan設(shè)備和bridge。
Mechanism Driver有三種：
- Agent-based：就是基于agent的，比如linux bridge和openvswitch
- Controller-based：基于控制器的，如opendaylight，就是sdn
- 基于物理交換機(jī)：如思科的設(shè)備
Linux Bridge實(shí)現(xiàn)
local network
local網(wǎng)絡(luò)不會(huì)和任何物理網(wǎng)卡連接，也不會(huì)有VLAN ID。
對(duì)于每一個(gè)local網(wǎng)絡(luò)都會(huì)創(chuàng)建一個(gè)網(wǎng)橋，將實(shí)例的tap設(shè)備綁定到網(wǎng)橋上。
同一網(wǎng)橋上的實(shí)例可以相互通信。每個(gè)local網(wǎng)絡(luò)都有自己的網(wǎng)橋，互不影響，因此同一個(gè)節(jié)點(diǎn)上不同往前的實(shí)例不能通信。
其實(shí)只有admin創(chuàng)建網(wǎng)絡(luò)可以選擇type driver，普通用戶在自己租戶里創(chuàng)建網(wǎng)絡(luò)的時(shí)候默認(rèn)使用/etc/neutron/plugins/mk2/ml2_conf.ini里面的一個(gè)參數(shù)tenant_networks_type=local，默認(rèn)是local，需要修改一下，可以指定多個(gè)，如vxlan,local，會(huì)從左到右按照順序依次創(chuàng)建，如果vxlan的id用完了，就會(huì)創(chuàng)建local。
命名
brqxxxxxx對(duì)應(yīng)的是網(wǎng)絡(luò)，表明這是網(wǎng)絡(luò)id為xxxxx創(chuàng)建的一個(gè)網(wǎng)橋
tapyyyyy，其實(shí)就是虛擬機(jī)的一個(gè)虛擬網(wǎng)卡，對(duì)應(yīng)的是port，說(shuō)明這是id為yyyy的port的tap接口設(shè)備，tap將連接到brq上
在創(chuàng)建實(shí)例的時(shí)候，neutron-linubgridge-agent根據(jù)port信息創(chuàng)建一個(gè)tap設(shè)備，連接到local網(wǎng)絡(luò)所在的bridge網(wǎng)橋上。這個(gè)tap設(shè)備就會(huì)映射為實(shí)例的虛擬網(wǎng)卡。
flat network
不帶tag的，要求和物理網(wǎng)卡連接，所以需要在ml2的配置文件里寫physical_interface_mappings=default:thh0，前面式一個(gè)label，用來(lái)標(biāo)識(shí)flat，可以是任意字符粗漢，就是表明和物理網(wǎng)卡的對(duì)應(yīng)關(guān)系，因?yàn)榭赡苊總€(gè)節(jié)點(diǎn)使用的物理網(wǎng)卡不一樣，因此這里的default就映射為配置好的物理網(wǎng)卡。
如果不同節(jié)點(diǎn)的實(shí)例連接到同一個(gè)網(wǎng)絡(luò)，他們所處的網(wǎng)橋名稱一致，通過(guò)provider network通信。
vlan network
vlan是帶tag的網(wǎng)絡(luò)。
如下所示，多個(gè)tap連接到brq網(wǎng)橋上。eth1網(wǎng)卡上創(chuàng)建了一個(gè)eth1.100的vlan interface接口，可以連接到這個(gè)brq上，然后通過(guò)eth1.100到eth1的數(shù)據(jù)包就會(huì)被標(biāo)記一個(gè)100的vlan tag。
如果有多個(gè)eth1.xxx接口連載eth1網(wǎng)卡上，就可以通過(guò)這個(gè)tag標(biāo)簽相互隔離不同的vlan。
如果需要這么設(shè)置的話，物理機(jī)連接的交換機(jī)端口需要設(shè)置為trunk，不能是access，因?yàn)樾枰鬟^(guò)多個(gè)tag數(shù)據(jù)包
vxlan
OpenStack支持VxLAN和GRE這兩種overlay網(wǎng)絡(luò)，overlay網(wǎng)絡(luò)指建立在其他網(wǎng)絡(luò)之上的網(wǎng)絡(luò)。
linuxbridge只支持vxlan，ovs兩個(gè)都支持。
優(yōu)點(diǎn)
- VLAN使用12bit標(biāo)記tag，最多4096個(gè)，而VxLAN支持24bit，最多16777216個(gè)二層網(wǎng)段
- 能夠很好利用已有路徑，封裝UDP通過(guò)三層傳輸和轉(zhuǎn)發(fā)，可以使用所有路徑。（VLAN用了Spanning Tree Protocol避免環(huán)路，有一半路徑用不成）
- 避免物理交換機(jī)MAC表耗盡，因?yàn)橛昧怂淼兰夹g(shù)，不需要再M(fèi)AC表里記錄虛擬機(jī)信息
缺點(diǎn)
其實(shí)也是有一些缺點(diǎn)的
- 比如強(qiáng)制在三層傳輸數(shù)據(jù)包可能路徑不是最優(yōu)傳輸速度慢
- 雖然避免了物理交換機(jī)記錄大量的虛擬機(jī)MAC，但是可能會(huì)造成路由器的ARP表有較多的記錄，影響正常的性能
- 而且標(biāo)準(zhǔn)規(guī)定VxLAN不能分片，要求物理鏈路層的MTU足夠大才行
VxLAN是將二層建立在三層上的網(wǎng)絡(luò)，把二層數(shù)據(jù)封裝在UDP數(shù)據(jù)包里擴(kuò)展二層網(wǎng)絡(luò)。IP+UDP
DHCP服務(wù)
通過(guò)DHCP agent實(shí)現(xiàn)DHCP服務(wù)。運(yùn)行在網(wǎng)絡(luò)節(jié)點(diǎn)，dnsmasq
當(dāng) 創(chuàng)建一個(gè)網(wǎng)絡(luò)的子網(wǎng)開啟dhcp功能后，agent會(huì)啟動(dòng)一個(gè)dnsmasq進(jìn)程提供服務(wù)，其實(shí)dnsmasq和network是對(duì)應(yīng)的，一個(gè)進(jìn)程可以給所有的子網(wǎng)提供dhcp服務(wù)。
通過(guò)dnsmasq獲取IP信息。
在創(chuàng)建實(shí)例的時(shí)候，實(shí)例會(huì)綁定一個(gè)port，有MAC和IP信息，dnsmasq會(huì)把這個(gè)記錄在一個(gè)host文件里。
實(shí)例啟動(dòng)以后，會(huì)發(fā)送DHCPDISCOVER廣播，然后廣播消息會(huì)在flat網(wǎng)絡(luò)里傳播，通過(guò)veth paur到達(dá)另一個(gè)namesapce里面，dhsmasq監(jiān)聽到了，然后返回對(duì)應(yīng)的IP信息，DHCPOFFER，包含IP地址、租期時(shí)間等給實(shí)例
最后實(shí)例返回一個(gè)DHCPREQUEST消息接收DNSOFFER。
NameSpace
二層網(wǎng)絡(luò)上可以通過(guò)VLAN將物理交換機(jī)分割為多個(gè)虛擬交換機(jī)。
而namespace可以將物理的三層網(wǎng)絡(luò)劃分為多個(gè)隔離的虛擬三層網(wǎng)絡(luò)，有這幾個(gè)字的網(wǎng)絡(luò)棧、防火墻規(guī)則、路由表等。
Neutron就是通過(guò)namespace為每個(gè)network提供DHCP服務(wù)和路由，讓租戶之間的網(wǎng)絡(luò)可以重疊不沖突，提高了靈活性。
每個(gè)namesapce里有各自的dnsmasq，ip nets list可以查看。
管理員可以將brq或者tap添加到某個(gè)namesapce里面。
如何讓兩個(gè)namespace相互通信呢
默認(rèn)是不能通信的，Neutron里面使用了 veth pair，相當(dāng)于虛擬網(wǎng)線，連接兩個(gè)namespace，這邊輸入另一邊接收。
Routing
路由提供了跨子網(wǎng)的通信。這里有兩個(gè)實(shí)例
vm1 - 172.16.100.3 - vlan100
vm3 - 172.16.101.3 - vlan101
這兩個(gè)實(shí)例是兩個(gè)不同vlan的，他們之間不能通過(guò)二層交換進(jìn)行通信，必須借助router。
虛擬router由L3 Agent在控制節(jié)點(diǎn)或者網(wǎng)絡(luò)節(jié)點(diǎn)運(yùn)行。
底層實(shí)現(xiàn)
通過(guò)配置一個(gè)router，vm1和vm3就可以進(jìn)行通信了。
首先vlan101的bridge網(wǎng)橋上多了一個(gè)tap設(shè)備，這個(gè)設(shè)備就是路由器的interface接口
同樣vlan100所在的網(wǎng)橋也有這么個(gè)接口設(shè)備。
L3 Agent會(huì)給每個(gè)router配置一個(gè)namespace，使用veth pair和tap設(shè)備連起來(lái)。對(duì)應(yīng)的gateway ip在namesapce內(nèi)的veth interface上。叫qr-…
其中namespace里的qr-xxxx和tap-xxxx組成veth pair進(jìn)行通信。
如下圖所示
引入namespace而不直接使用網(wǎng)關(guān)的作用
為了使得租戶之間的網(wǎng)絡(luò)可以重疊提高靈活性。
不然如果A和B都有相同子網(wǎng)，只用網(wǎng)關(guān)的話需要在控制節(jié)點(diǎn)的路由表上加兩項(xiàng)，而且目的IP可能一致，無(wú)法區(qū)分了。
router連接外網(wǎng)
給router配置好一個(gè)外部網(wǎng)絡(luò)（一般是flat或者vlan類型）的網(wǎng)關(guān)以后，router多一個(gè)接口，通過(guò)這個(gè)接口可以連接到外網(wǎng)，ip比如是10.10.10.2。
然后連接外部網(wǎng)絡(luò)的bridge的tap-xxxx設(shè)備，通過(guò)veth pair和路由器namesapce內(nèi)的qg-xxxx接口連接
冷知識(shí)，router的內(nèi)部網(wǎng)絡(luò)的接口叫qr-xxxxx，外部網(wǎng)絡(luò)叫qg-yyyyy
此時(shí)看ip nets exec qrouter-xxxx route，會(huì)看到10.10.10.1有一個(gè)qg的接口。說(shuō)明如果是外網(wǎng)流量的話，router會(huì)通過(guò)這個(gè)接口將流量轉(zhuǎn)發(fā)到這個(gè)網(wǎng)關(guān)，然后到linuxbrige的brq網(wǎng)橋上轉(zhuǎn)發(fā)到網(wǎng)卡上。。
從qg-xxxxx出去的話會(huì)進(jìn)行一個(gè)SNAT的轉(zhuǎn)換，將源IP修改為router的源IP 10.10.10.2，以便回來(lái)的時(shí)候可以找到路由器
floating IP
SNAT可以讓實(shí)例訪問(wèn)外網(wǎng)，但是還不能讓外網(wǎng)訪問(wèn)實(shí)例，使用浮動(dòng)IP可以解決這個(gè)。
floating ip可以提供一個(gè)一對(duì)一映射的靜態(tài)NAT。
創(chuàng)建好一個(gè)floating ip以后，會(huì)配置到router的外網(wǎng)的qg接口，然后iptables會(huì)添加兩個(gè)規(guī)則
- 如果是內(nèi)網(wǎng)IP到達(dá)路由器，轉(zhuǎn)換為對(duì)應(yīng)的floating ip發(fā)送出去
- 如果是floating ip對(duì)應(yīng)的數(shù)據(jù)包到達(dá)路由器，會(huì)修改為對(duì)應(yīng)的內(nèi)網(wǎng)IP
Fwaas
讓用戶可以創(chuàng)建和管理防火墻，在子網(wǎng)的邊界進(jìn)行流量過(guò)濾。傳統(tǒng)的防火墻是在網(wǎng)關(guān)上的，隔離子網(wǎng)，而這個(gè)是在router上配置的，控制租戶網(wǎng)絡(luò)進(jìn)出的流量。
分為：
- Firewall：必須關(guān)聯(lián)某個(gè)Policy
- Firewall Policy：是Rule的集合，會(huì)按照Policy中的順序依次過(guò)濾
- Firewall Rule：訪問(wèn)控制規(guī)則，包括源IP和端口、目的IP和端口，協(xié)議類型以及操作
安全組的對(duì)象是虛擬網(wǎng)卡，L2 Agent實(shí)現(xiàn)，對(duì)通過(guò)iptables實(shí)現(xiàn)對(duì)實(shí)例虛擬網(wǎng)卡流量的過(guò)濾。而fwaas是配置在虛擬路由器上的，在到達(dá)安全組之前可以先過(guò)濾一下，但是同一個(gè)subnet內(nèi)部的虛擬網(wǎng)卡間不會(huì)過(guò)濾，因?yàn)椴煌ㄟ^(guò)router。
fwaas沒(méi)有單獨(dú)的agent，是在L3 Agent中配置的，driver為IP tables，要在service plugins啟用fwaas。
FWaaS v2
上面說(shuō)的是v1，Stein版本以后，v1廢棄了，是v2了。
Firewall概念變?yōu)镕irewall Group了，而且不像v1是唯一綁定一個(gè)路由器，v2需要指定路由器的某個(gè)接口。
可以同時(shí)管理ingress和egress進(jìn)口和出口兩種流量。v1則不區(qū)分，對(duì)雙向流量進(jìn)行過(guò)濾，安全組區(qū)分流量。
OpenvSwitch
ovs是除了linuxbridge外的另一種虛擬化交換機(jī)技術(shù)。
安裝ovs agent，修改ml2的mechanism_drivers。
初始狀態(tài)有三個(gè)網(wǎng)橋：
- br-int：連接所有虛擬機(jī)的虛擬網(wǎng)卡或和其他虛擬網(wǎng)絡(luò)設(shè)備
- br-ex:連接外部網(wǎng)絡(luò)的網(wǎng)橋
- br-tun：隧道技術(shù)用這個(gè)，比如VxLAN或者GRE
計(jì)算節(jié)點(diǎn)沒(méi)有br-ex，因?yàn)橛?jì)算節(jié)點(diǎn)的外網(wǎng)流量是通過(guò)網(wǎng)絡(luò)節(jié)點(diǎn)的虛擬路由器轉(zhuǎn)發(fā)的，所以br-ex在網(wǎng)絡(luò)節(jié)點(diǎn)上。
local network
同樣的local網(wǎng)絡(luò)不會(huì)和網(wǎng)卡連接，流量被限制在宿主機(jī)內(nèi)，只有同一個(gè)網(wǎng)橋上的才可以通信。
創(chuàng)建了一個(gè)local網(wǎng)絡(luò)以后，br-int網(wǎng)橋上有一個(gè)tap設(shè)備，是dhcp的接口，tap設(shè)備是在這個(gè)命名空間里的。
創(chuàng)建一個(gè)實(shí)例以后，Neutron在子網(wǎng)subnet中創(chuàng)建一個(gè)port，分配IP和MAC，綁定在實(shí)例上，會(huì)創(chuàng)建一個(gè)tap-xxxx設(shè)備作為實(shí)例的虛擬網(wǎng)卡。
然后在linuxbridge上創(chuàng)建一個(gè)qbr-xxxx網(wǎng)橋，和tap設(shè)備相連。
然后通過(guò)veth pair連接到br-int，即qvb-xxxx與qvo-xxxx。
為什么需要使用一個(gè)linuxbridge中轉(zhuǎn)不能直接使用tap設(shè)備連接到br-int呢
因?yàn)閛vs不支持將iptables規(guī)則放在與其相連的tap設(shè)備上，因此為了實(shí)現(xiàn)security group安全組的功能，需要引入linuxbridge作為一個(gè)中轉(zhuǎn)
如下圖所示
一個(gè)實(shí)例的網(wǎng)絡(luò)設(shè)備連接情況如下（以次連接）：
- tap-xxxx：虛擬網(wǎng)卡
- qbr-xxxx：tap連接到linuxbridge的qbr，為了使用security group功能
- qbr通過(guò)一對(duì)veth pair（qvb-xxxx和qvo-xxxx）連接到br-int網(wǎng)橋
<font color="red>如果此時(shí)創(chuàng)建第二個(gè)local 網(wǎng)絡(luò)，然后創(chuàng)建一個(gè)虛擬機(jī)，其虛擬網(wǎng)卡同樣會(huì)連接到br-int上，那么可以通信嗎。
不可以。
ovs會(huì)將每個(gè)網(wǎng)橋看成一個(gè)虛擬機(jī)，然后可以支持vlan，每個(gè)local網(wǎng)絡(luò)的djcp和虛擬網(wǎng)卡都有一個(gè)tag，這個(gè)tag就是VLAN ID，相互之間隔離。僅用于隔離網(wǎng)橋中的port。
flat network
flat網(wǎng)絡(luò)的話是不帶tag的，而且一個(gè)flat網(wǎng)路需要和一個(gè)物理網(wǎng)卡相連。
這里在修改配置文件的bridge_mappings的時(shí)候，不是標(biāo)簽：物理網(wǎng)卡了，而是標(biāo)簽：連接網(wǎng)卡的網(wǎng)橋名。
因此需要先創(chuàng)建一個(gè)br-eth1網(wǎng)橋，連接到物理網(wǎng)卡eth1。
此時(shí)在br-int和br-eth1會(huì)分別多出一個(gè)接口int-br-eth1和phy-br-eth1，是patch類型的，用來(lái)連接br-int和br-eth1，可以訪問(wèn)外網(wǎng)。
如下所示
在linuxbridge里面用veth pair連接br-int和linuxbridge，而這里使用patch連接br-int和br-eth1。
veth pair 和 patch
兩者都可以作為一個(gè)類似虛擬網(wǎng)線的功能連接網(wǎng)橋。
- patch port是連接兩個(gè)ovs bridge的專屬，而且性能更好
- veth pair只能用于連接兩個(gè)linuxbridge或者linuxbridge與ovs連接
底層實(shí)現(xiàn)
創(chuàng)建一個(gè)flat網(wǎng)絡(luò)與后，會(huì)創(chuàng)建一個(gè)dhcp的接口，tap-xxxx連接到br-int網(wǎng)橋。
創(chuàng)建一個(gè)虛擬機(jī)后，同樣的，先創(chuàng)建一個(gè)tap設(shè)備作為虛擬機(jī)的虛擬網(wǎng)卡，然后連接到linuxbridge的qbr網(wǎng)橋上，然后qbr通過(guò)一對(duì)veth pair連接到br-int網(wǎng)橋。
VLAN 網(wǎng)絡(luò)
ovs中是所有虛擬網(wǎng)卡都連接到br-int網(wǎng)橋，而linuxbridge里面則是不同VLAN連接到不同網(wǎng)卡的VLAN網(wǎng)橋。因此物理交換機(jī)連接eth1的口也要設(shè)置為trunk。
ovs通過(guò)flow rule對(duì)流過(guò)br-int的數(shù)據(jù)包進(jìn)行轉(zhuǎn)發(fā)處理，比如打上tag或者去掉tag等。
ovs-ofctl dump-flow查看流規(guī)則。
比如br-eth1網(wǎng)橋的流規(guī)則如下，這里的in_port編號(hào)可以在ovs-ofctl show 查看到。
這里就是說(shuō)從br-eth1網(wǎng)橋的phy-br-eth1（port=2）端口進(jìn)來(lái)的vlan為1的數(shù)據(jù)包，修改vlan id為100然后發(fā)送出去
br-int網(wǎng)橋的規(guī)則同理
這里的tag和VLAN其實(shí)是不一樣的，tag是ovs內(nèi)部進(jìn)行網(wǎng)絡(luò)隔離使用的，在接收到數(shù)據(jù)包的時(shí)候，需要進(jìn)行vlan的一個(gè)映射，Neutron維護(hù)VLAN ID的映射關(guān)系。
Roting
兩個(gè)子網(wǎng)之間的實(shí)例通信需要使用路由器進(jìn)行通信。
創(chuàng)建一個(gè)路由器以后，將 子網(wǎng)可以添加到路由器的接口上，接口的IP分別為子網(wǎng)的網(wǎng)關(guān)。
br-int網(wǎng)橋上多了兩個(gè)接口port，叫qr-xxxx。router也是運(yùn)行在自己的namesapce里面。
如果路由器需要連接外網(wǎng)，需要綁定一個(gè)外部網(wǎng)關(guān)，然后router就多了一個(gè)接口10.10.10.2，用于連接外網(wǎng)。也就是路由器的qg-xxxx接口。
VxLAN
可以設(shè)置VxLAN 的vni也就是tag，需要在配置文件的[ovs]配置tunnel_bridge。
br-int和br-tun是通過(guò)patch port連接的，其中patch-tun在br-int上，patch-int在br-tun上。
底層實(shí)現(xiàn)
創(chuàng)建網(wǎng)絡(luò)以后，dhcp也會(huì)通過(guò)tap設(shè)備連接到br-int上。
實(shí)例的虛擬網(wǎng)卡tap設(shè)備還是連接到linuxbridge的網(wǎng)橋qbr上，通過(guò)veth pair（qvb和qvo）連接到br-int上。
而br-tun上則多了一個(gè)vxlan-xxxx的東西，比如用于連接控制節(jié)點(diǎn)和計(jì)算節(jié)點(diǎn)的，制定了VTEP的IP。
此時(shí)br-int充當(dāng)了一個(gè)二層交換機(jī)，查看flow rule以后可以看到是通過(guò)vlan和mac轉(zhuǎn)發(fā)數(shù)據(jù)包的。
而br-tun的flow-rule才是進(jìn)行真正轉(zhuǎn)發(fā)數(shù)據(jù)包的。
Cinder
為運(yùn)行實(shí)例提供穩(wěn)定持久化的數(shù)據(jù)塊存儲(chǔ)服務(wù)，如創(chuàng)建卷、刪除卷，在實(shí)例上掛載和卸載卷。
cinder-api：接收http請(qǐng)求調(diào)用cinder-volume
cinder-volume：管理volume服務(wù)，管理卷的生命周期
cinder-schedule：通過(guò)算法為卷調(diào)度一個(gè)合適的節(jié)點(diǎn)
Swift
Zun
openstack租戶管理_OpenStack容器服務(wù)Zun初探與原理分析
Keystone、Neutron以及Kuryr-libnetwork是運(yùn)行Zun必備的服務(wù)。分別提供了身份認(rèn)證以及網(wǎng)絡(luò)的功能支持。
zun-api負(fù)責(zé)接收api請(qǐng)求進(jìn)行處理。
zun-compute服務(wù)調(diào)用container driver進(jìn)行docker的創(chuàng)建，目前只實(shí)現(xiàn)了Docker Driver。
流程步驟
zun/api/controllers/v1/containers.py
進(jìn)行參數(shù)校驗(yàn)，如用戶是否具有policy權(quán)限，網(wǎng)絡(luò)、安全組、配額等是否符合。
zun/compute/api.py
先schedule調(diào)度一個(gè)合適的計(jì)算節(jié)點(diǎn)，返回host對(duì)象，這個(gè)功能集成在zun-api里面了。
檢查鏡像是否存在，遠(yuǎn)程調(diào)用zun-compute的image search方法，其實(shí)就是調(diào)用了docker search，為了實(shí)現(xiàn)快速失敗，避免到計(jì)算節(jié)點(diǎn)才發(fā)現(xiàn)錯(cuò)誤。
然后遠(yuǎn)程調(diào)用zun-compute進(jìn)行后續(xù)工作
zun/compute/manager.py
創(chuàng)建卷或者掛載硬盤，然后下載鏡像，創(chuàng)建端口，調(diào)用docker啟動(dòng)容器。
其中調(diào)用docker啟動(dòng)容器的操作的代碼位于zun/container/docker/driver.py，這個(gè)部分其實(shí)就是對(duì)于Docker SDK for python的一個(gè)封裝。
如import docker
Kuryr-libnetwork
這個(gè)項(xiàng)目的目的是將容器網(wǎng)絡(luò)與neutron進(jìn)行融合，提供接口南向連接neutron，北向連接容器網(wǎng)絡(luò)。
開始目的是為了提供Docker與Neutron的連接。將Neutron的網(wǎng)絡(luò)服務(wù)帶給Docker。隨著容器的發(fā)展，容器網(wǎng)絡(luò)的發(fā)展也出現(xiàn)了分歧。主要分為兩派，一個(gè)是Docker原生的CNM（Container Network Model），另一個(gè)是兼容性更好的CNI（Container Network Interface）。Kuryr相應(yīng)的也出現(xiàn)了兩個(gè)分支，一個(gè)是kuryr-libnetwork（CNM），另一個(gè)是kuryr-kubernetes（CNI）。
kuryr-libnetwork是運(yùn)行在Libnetwork框架下的一個(gè)plugin，替換了原有的docker engine，成為一個(gè)kuryr就是libnetwork的一個(gè)remote-driver，現(xiàn)在是docker的推薦remote-driver。
其實(shí)實(shí)際上kuryr起了一個(gè)http服務(wù)，23750端口，提供了libnetwork的所有接口，docker找到以后通過(guò)這個(gè)與kuryr通信。
kuryr借用了neutron的subnetpool，保證了子網(wǎng)間ip的不重復(fù)
實(shí)現(xiàn)原理
在上面zun調(diào)用docker模塊創(chuàng)建容器的時(shí)候，也會(huì)進(jìn)行網(wǎng)絡(luò)的配置，就在這里。
先檢查docker網(wǎng)絡(luò)是否存在，不存在就創(chuàng)建，創(chuàng)建的docker網(wǎng)絡(luò)name就是neutron的uuid，會(huì)調(diào)用neutron創(chuàng)建一個(gè)port，即容器的port是zun創(chuàng)建的，不是kuryr創(chuàng)建的。
然后對(duì)于虛擬網(wǎng)卡，會(huì)虛擬出一個(gè)tap設(shè)備，其中容器內(nèi)部命名空間有一個(gè)t_cxxxx的設(shè)備，兩個(gè)通過(guò)veth pair連接起來(lái)。然后tap設(shè)備會(huì)連接到qbr的linuxbridge網(wǎng)橋，隨后網(wǎng)橋通過(guò)qvb和qvo的veth連接到br-int集成網(wǎng)橋。
其實(shí)哦在那個(gè)接一下kuryr的作用就是把neutron的port綁定在容器上。
SDN
軟件定義網(wǎng)絡(luò)，是網(wǎng)絡(luò)虛擬化的一種實(shí)現(xiàn)方式。
主要體現(xiàn)在如下三個(gè)方面：
- 轉(zhuǎn)發(fā)與控制分離：SDN具有轉(zhuǎn)發(fā)與控制分離的特點(diǎn)，采用SDN控制器實(shí)現(xiàn)網(wǎng)絡(luò)拓?fù)涞氖占⒙酚傻挠?jì)算、流表的生成及下發(fā)、網(wǎng)絡(luò)的管理與控制等功能;而網(wǎng)絡(luò)層設(shè)備僅負(fù)責(zé)流量的轉(zhuǎn)發(fā)及策略的執(zhí)行。通過(guò)這種方式可使得網(wǎng)絡(luò)系統(tǒng)的轉(zhuǎn)發(fā)面和控制面獨(dú)立發(fā)展，轉(zhuǎn)發(fā)面向通用化、簡(jiǎn)單化發(fā)展，成本可逐步降低;控制面可向集中化、統(tǒng)一化發(fā)展，具有更強(qiáng)的性能和容量。
- 控制邏輯集中：轉(zhuǎn)發(fā)與控制分離之后，使得控制面向集中化發(fā)展。控制面的集中化，使得SDN控制器擁有網(wǎng)絡(luò)的全局靜態(tài)拓?fù)?#xff0c;全網(wǎng)的動(dòng)態(tài)轉(zhuǎn)發(fā)表信息，全網(wǎng)絡(luò)的資源利用率，故障狀態(tài)等。因此，SDN控制器可實(shí)現(xiàn)基于網(wǎng)絡(luò)級(jí)別的統(tǒng)一管理、控制和優(yōu)化，更可依托全局的拓?fù)涞膭?dòng)態(tài)轉(zhuǎn)發(fā)信息幫助實(shí)現(xiàn)快速的故障定位和排除，提高運(yùn)營(yíng)效率。
- 網(wǎng)絡(luò)能力開放化：SDN還有一個(gè)重要特征是支持網(wǎng)絡(luò)能力開放化。通過(guò)集中的SDN控制器實(shí)現(xiàn)網(wǎng)絡(luò)資源的統(tǒng)一管理、整合以及虛擬化后，采用規(guī)范化的北向接口為上層應(yīng)用提供按需分配的網(wǎng)絡(luò)資源及服務(wù)，進(jìn)而實(shí)現(xiàn)網(wǎng)絡(luò)能力開放。這樣的方式打破了現(xiàn)有網(wǎng)絡(luò)對(duì)業(yè)務(wù)封閉的問(wèn)題，是一種突破性的創(chuàng)新。
OpenFlow
OpenFlow是一種網(wǎng)上通信協(xié)議，屬于數(shù)據(jù)鏈路層，允許控制器直接訪問(wèn)和操作網(wǎng)絡(luò)設(shè)備的轉(zhuǎn)發(fā)平面，借此改變數(shù)據(jù)包的走向。這些設(shè)備可以是物理設(shè)備也可以是虛擬交換機(jī)。
轉(zhuǎn)發(fā)平面基于流的方式轉(zhuǎn)發(fā)。
網(wǎng)絡(luò)設(shè)備會(huì)維護(hù)若干個(gè)流表，數(shù)據(jù)流只按照流表進(jìn)行轉(zhuǎn)發(fā)，而流表的生成與維護(hù)都是控制器做的事。
這里的流表不僅僅是IP五元組，而是還有這一些關(guān)鍵詞和執(zhí)行動(dòng)作等。在實(shí)際使用中可以根據(jù)需要的粒度進(jìn)行一個(gè)限制，比如如果想要粗粒度，只需要設(shè)置IP就好了，不需要設(shè)置其他的參數(shù)比如端口之類的。
OF 1.0
一個(gè)流表包含一個(gè)流表項(xiàng)的集合（包頭域）、活動(dòng)計(jì)數(shù)器以及一個(gè)操作集。
所有流過(guò)交換機(jī)的數(shù)據(jù)包都需要進(jìn)行流表的匹配，如果匹配成功，執(zhí)行相應(yīng)的操作，如果沒(méi)有匹配上，將其轉(zhuǎn)發(fā)到控制器，由控制器決定如何處理這個(gè)數(shù)據(jù)包。
這個(gè)包頭域會(huì)根據(jù)數(shù)據(jù)包的信息進(jìn)行相應(yīng)的匹配，使用的是12元組
- 入口：交換機(jī)端口
- 以太網(wǎng)源端口
- 以太網(wǎng)源IP
- 以太網(wǎng)類型：VLAN是0x8100，ARP是0x0806、IP是0x0800
- VLAN ID
- VLAN優(yōu)先級(jí)
- 源IP
- 目的IP
- IP協(xié)議：TCP6、UDP7、ICMP1
- IP ToS位
- 源端口
- 目的端口
活動(dòng)計(jì)數(shù)器包含有多個(gè)計(jì)數(shù)器，會(huì)根據(jù)匹配的數(shù)據(jù)包進(jìn)行一個(gè)更新。
- 流表：流表的匹配數(shù)據(jù)包數(shù)
- 流表項(xiàng)flow：每一項(xiàng)接收的數(shù)據(jù)包字節(jié)數(shù)、數(shù)據(jù)包個(gè)數(shù)、延遲等
- 端口：每個(gè)端口接收到的數(shù)據(jù)包數(shù)、字節(jié)數(shù)、轉(zhuǎn)發(fā)的數(shù)據(jù)包數(shù)、字節(jié)數(shù)等
- 隊(duì)列：轉(zhuǎn)發(fā)的數(shù)據(jù)包數(shù)
操作集規(guī)定了對(duì)匹配成功數(shù)據(jù)包進(jìn)行什么操作，可以有0到多個(gè)操作，如果沒(méi)有相應(yīng)操作，丟棄數(shù)據(jù)包。
一些基本的操作有：
- ALL：給除了入口的所有接口發(fā)出數(shù)據(jù)包
- Controller：發(fā)給控制器
- INN PORT：往入口發(fā)送數(shù)據(jù)包
- DROP：丟棄
還有一些可選的
- NORMAL：傳統(tǒng)交換機(jī)的正常轉(zhuǎn)發(fā)
- FLOOD：泛洪至除了入口以外的所有出口
- 修改域：這個(gè)功能比較厲害，它可以對(duì)數(shù)據(jù)包里面的信息進(jìn)行修改隨后轉(zhuǎn)發(fā)，比如可以修改VLAN ID、VLAN優(yōu)先級(jí)、源IP和目的IP、源端口和目的端口等信息
OF 1.3
主要添加了多級(jí)流表（流水線），增加了一些多控制器的支持，增加了對(duì)數(shù)據(jù)包處理的動(dòng)作
一個(gè)流表項(xiàng)的組成
- 匹配域
- 優(yōu)先級(jí)
- 計(jì)數(shù)器
- 超時(shí)時(shí)間
- 指令
- cookie
將原來(lái)的動(dòng)作變更為指令，然后允許數(shù)據(jù)包在流表之間跳轉(zhuǎn)。
不同于1.0的十二元組，這里其實(shí)有四十多個(gè)字段，但是一般大多數(shù)用不到，主要也就是那么些。
有一個(gè)指令是go-to-table：轉(zhuǎn)向另一個(gè)流表
如果沒(méi)有這個(gè)，會(huì)有以下幾個(gè)動(dòng)作
- output：指定端口轉(zhuǎn)發(fā)出去
- drop：丟棄
- push-tag或者pop-tag：對(duì)VLAN等ID進(jìn)行處理
- setField：識(shí)別匹配的字段，并且可以修改
- change-TTL：修改數(shù)據(jù)包的TTL值
同時(shí) 還需要支持table-miss，就是說(shuō)如果沒(méi)有匹配成功，進(jìn)行什么樣的動(dòng)作，轉(zhuǎn)給控制器還是丟棄。
Django
概述
Django是一個(gè)開放源代碼的web應(yīng)用框架，使用python寫成。本身是基于MVC模型的，實(shí)際采用了MTV的框架模式，即模型（Model）、模（Templates）板和視圖（Views）。其中：
- 模型：數(shù)據(jù)存取曾，處理所有與數(shù)據(jù)有關(guān)的事務(wù)，比如如何存取數(shù)據(jù)、驗(yàn)證有效性等
- 模板：表現(xiàn)層，比如如何在頁(yè)面或者其他類型文檔中顯示
- 視圖：業(yè)務(wù)邏輯層，處理數(shù)據(jù)存儲(chǔ)以及調(diào)用模板的邏輯
簡(jiǎn)單流程：
用戶通過(guò)瀏覽器向我們的服務(wù)器發(fā)起一個(gè)請(qǐng)求(request)，這個(gè)請(qǐng)求會(huì)去訪問(wèn)視圖函數(shù)：
a.如果不涉及到數(shù)據(jù)調(diào)用，那么這個(gè)時(shí)候視圖函數(shù)直接返回一個(gè)模板也就是一個(gè)網(wǎng)頁(yè)給用戶。
b.如果涉及到數(shù)據(jù)調(diào)用，那么視圖函數(shù)調(diào)用模型，模型去數(shù)據(jù)庫(kù)查找數(shù)據(jù)，然后逐級(jí)返回。
視圖函數(shù)把返回的數(shù)據(jù)填充到模板中空格中，最后返回網(wǎng)頁(yè)給用戶。
Django的主要目的是簡(jiǎn)單快捷的開發(fā)數(shù)據(jù)驅(qū)動(dòng)的網(wǎng)站，強(qiáng)調(diào)代碼復(fù)用，多個(gè)組件可以很方便的以插件形式服務(wù)與整個(gè)框架。
有以下幾個(gè)特點(diǎn)：
MVC和MTV
MVC：
核心思想是解耦
- model：對(duì)數(shù)據(jù)庫(kù)的底層封裝
- view：向用戶展示結(jié)果
- controller：核心，處理請(qǐng)求、獲取數(shù)據(jù)、返回結(jié)果
MVT：
- model：與數(shù)據(jù)庫(kù)進(jìn)行交互
- views：核心，接受請(qǐng)求，獲取處理數(shù)據(jù)，返回結(jié)果
- template：呈現(xiàn)內(nèi)容到瀏覽器上
views里處理業(yè)務(wù)邏輯比如登錄驗(yàn)證、數(shù)據(jù)處理等
model里面不需要編寫一句sql，ORM會(huì)自動(dòng)轉(zhuǎn)為sql去執(zhí)行。
數(shù)據(jù)庫(kù)里每一行數(shù)據(jù)就是一個(gè)對(duì)象，每一個(gè)表是一個(gè)集合，python用列表表示這個(gè)集合
template呈現(xiàn)頁(yè)面，用css和js渲染html等
還需要一個(gè) URL 分發(fā)器，它的作用是將一個(gè)個(gè) URL 的頁(yè)面請(qǐng)求分發(fā)給不同的 View 處理，View 再調(diào)用相應(yīng)的 Model 和 Template，MTV 的響應(yīng)模式如下所示
和Flask Tornado的區(qū)別
Django提供了更多的組件支持，讓開發(fā)變得更加方便。
比如
- ORM對(duì)象關(guān)系映射，對(duì)數(shù)據(jù)庫(kù)進(jìn)行操作，不需要編寫sql語(yǔ)句
- Admin管理后臺(tái)
- 模板
- 表單
- 認(rèn)證權(quán)限
- 緩存
- session機(jī)制
Flask輕量級(jí)輕在它本身是一個(gè)內(nèi)核，其他功能都需要擴(kuò)展實(shí)現(xiàn)。比如可以引入其他模塊實(shí)現(xiàn)ORM，也沒(méi)有默認(rèn)數(shù)據(jù)庫(kù)，但是可以自行配置使用mysq或者nosql，性能比Django好。依賴于Werkzurg WSGI路由模塊和jinja2模板。
對(duì)于路由的匹配
- Django使用過(guò)urls.py種對(duì)路由進(jìn)行字符串的匹配，選擇匹配的views.py函數(shù)進(jìn)行業(yè)務(wù)處理
- Flask則是使用裝飾器給一個(gè)函數(shù)配置一個(gè)路由，然后進(jìn)行處理
Tornado
功能少而精，非阻塞式異步設(shè)計(jì)方式。
- iostream：對(duì)非阻塞式socket進(jìn)行封裝
- ioloop：對(duì)IO多路復(fù)用進(jìn)行封裝，實(shí)現(xiàn)單例
Tornado是一個(gè)使用python開發(fā)的全棧式的web框架和一部網(wǎng)絡(luò)庫(kù)，使用非阻塞式IO，可以處理數(shù)以萬(wàn)計(jì)的開放鏈接，常用于long polling、web sockets和其他需要維護(hù)長(zhǎng)連接應(yīng)用的選擇。
主要分為四個(gè)部分
- Web框架（RequestHandler，用于創(chuàng)建Web的基類支持各種類）
- 實(shí)現(xiàn)HTTP的客戶端和服務(wù)器端（HTTPServer、AsyncHTTPClient）
- 異步網(wǎng)絡(luò)庫(kù)（IOLoop、IOStream）
- 協(xié)程庫(kù)（tornado.gen），使得異步調(diào)用代碼可以更好編寫
tornado的性能比django和flask好就是因?yàn)槠涞讓觟o處理機(jī)制是根本不同。
- tornado、gevent、syncio、aiohttp：事件循環(huán)+協(xié)程
- django、flask：
Django請(qǐng)求生命周期
瀏覽器輸入網(wǎng)址，發(fā)送請(qǐng)求到服務(wù)器
匹配路由
url經(jīng)過(guò)uWSGI->WSGI，然后經(jīng)過(guò)中間件的處理，在urls.py路由映射中找到一個(gè)匹配的路由，從上到下依次匹配，匹配一個(gè)就可以停了
視圖處理
匹配到url以后，跳轉(zhuǎn)到對(duì)應(yīng)的視圖函數(shù)進(jìn)行相應(yīng)的業(yè)務(wù)處理，比如操作數(shù)據(jù)庫(kù)等
返回響應(yīng)
先經(jīng)過(guò)中間件對(duì)返回的數(shù)據(jù)再進(jìn)行處理，然后返回相應(yīng)的頁(yè)面文件，由瀏覽器渲染以后顯示給用戶，同時(shí)將模板內(nèi)容填充到html空白處。
一些額外的
在匹配路由的時(shí)候，有兩種方式，是CBV、FBV
- FBV(function base views)：一個(gè)url對(duì)應(yīng)一個(gè)視圖函數(shù)
- CBV(class base views)：一個(gè)url對(duì)應(yīng)一個(gè)類，會(huì)根據(jù)請(qǐng)求的方法調(diào)用對(duì)應(yīng)的函數(shù)
CBV，url匹配成功后會(huì)自動(dòng)去找dispatch方法,然后Django會(huì)通過(guò)dispatch反射的方式找到類中對(duì)應(yīng)的方法并執(zhí)行，類方法執(zhí)行完成以后，返回的結(jié)果回傳給dispatch()
對(duì)應(yīng)類的話如下所示
常見的web應(yīng)用程序
框架組件
RestFramework
面向資源是REST最明顯的特征，資源是一種看待服務(wù)器的方式，將服務(wù)器看作是由很多離散的資源組成。每個(gè)資源是服務(wù)器上一個(gè)可命名的抽象概念。因?yàn)橘Y源是一個(gè)抽象的概念，所以它不僅僅能代表服務(wù)器文件系統(tǒng)中的一個(gè)文件、數(shù)據(jù)庫(kù)中的一張表等等具體的東西，可以將資源設(shè)計(jì)的要多抽象有多抽象，只要想象力允許而且客戶端應(yīng)用開發(fā)者能夠理解。
可以使用URI統(tǒng)一資源標(biāo)識(shí)符標(biāo)記一個(gè)服務(wù)器的資源，通過(guò)不同的http方法對(duì)資源進(jìn)行相應(yīng)的操作。這里的資源可以是一個(gè)文本文件、視頻、圖片等。
符合REST架構(gòu)設(shè)計(jì)的API就是restful api。
繼承APIView
@api_view([‘POST’],[‘GET’])
在這個(gè)類中，傳入的參數(shù)是rest framework的request實(shí)例，不是django的httprequest。
可以返回rest framework的resonse，而不是HttpResponse。
傳入的請(qǐng)求可以進(jìn)行一些認(rèn)證
可以指定解析器Parser對(duì)傳入的數(shù)據(jù)進(jìn)行解析，如JSON、Form等解析。
一些功能模塊
認(rèn)證、權(quán)限和頻率
dispatch()方法中進(jìn)行一個(gè)判定。
認(rèn)證和權(quán)限需要檢查request.user和request.auth是否合法，是否允許請(qǐng)求。
緩存機(jī)制
網(wǎng)站訪問(wèn)量過(guò)大的時(shí)候，響應(yīng)速度可能會(huì)大大降低，出現(xiàn)卡死的狀況，可以使用緩存解決這類問(wèn)題。
緩存是將一個(gè)請(qǐng)求的響應(yīng)內(nèi)容保存到內(nèi)存、數(shù)據(jù)庫(kù)、文件或者高速緩存系統(tǒng)（memcached），如果接下來(lái)一段時(shí)間再次來(lái)同一個(gè)請(qǐng)求，就不需要執(zhí)行相應(yīng)過(guò)程，只需要讀取內(nèi)存或者高速緩存系統(tǒng)就可以了。
Django提供5種緩存方式：
- Memcached：一個(gè)高性能的分布式內(nèi)存對(duì)象緩存系統(tǒng)，用于動(dòng)態(tài)網(wǎng)站，減輕數(shù)據(jù)庫(kù)負(fù)載。適合在內(nèi)存中緩存數(shù)據(jù)和對(duì)象減少讀取數(shù)據(jù)庫(kù)的次數(shù)，適合超大型網(wǎng)站
- 數(shù)據(jù)庫(kù)緩存：將緩存的信息存儲(chǔ)在網(wǎng)站數(shù)據(jù)庫(kù)的緩存表中，適合中型網(wǎng)站
- 文件系統(tǒng)緩存：緩存的信息以文本文件的格式保存下來(lái)，適合中小型網(wǎng)站
- 本地內(nèi)存緩存：默認(rèn)保存緩存的方式，緩存存放于內(nèi)存中，僅用于測(cè)試
- 虛擬緩存：Django內(nèi)置的虛擬緩存，實(shí)際上只是提供一個(gè)接口，不實(shí)際緩存數(shù)據(jù)，用于測(cè)試
WSGI,uwsgi,uWSGI
WSGI
是python定義實(shí)現(xiàn)的一個(gè)web服務(wù)器和web應(yīng)用程序之間交互的一個(gè)接口，是一種規(guī)范，描述定義了服務(wù)器和應(yīng)用程序之間通信的規(guī)范。
WSGI包括server和applicatioon兩部分。
其中server負(fù)責(zé)接收客戶端請(qǐng)求，把request轉(zhuǎn)發(fā)給application，接收application的response返回給客戶端。
WSGI其實(shí)是一種server和application解耦的規(guī)范，有多個(gè)實(shí)現(xiàn)server的服務(wù)器，也有多個(gè)可以實(shí)現(xiàn)WSGI application的框架，可以自由組合。比如uWSGI、Gunicorn就是實(shí)現(xiàn)了WSGI server，而Django和Flask則實(shí)現(xiàn)了WSGI application的框架，可以自由組合，比如uWSGI+Django。
WSGI除了監(jiān)聽端口進(jìn)行解析http，還有流量轉(zhuǎn)發(fā)和管理application進(jìn)程。一般WSGI內(nèi)置的WSGI server都是單進(jìn)程，一次只能處理一個(gè)請(qǐng)求，而通用的比如gunicorn或者uwsgi都是pre fork模型，會(huì)有一個(gè)master進(jìn)行監(jiān)聽，啟動(dòng)多個(gè)slave（一個(gè)slave就是一個(gè)WSGI application）處理請(qǐng)求。
uwsgi
也是一種協(xié)議，用于定義傳輸信息的類型，可以和nginx等代理服務(wù)器通信
uWSGI
是一個(gè)web服務(wù)器，實(shí)現(xiàn)了WSGI協(xié)議、uwsgi和HTTP協(xié)議，把接收到的HTTP協(xié)議轉(zhuǎn)為支持的網(wǎng)絡(luò)協(xié)議，比如可以轉(zhuǎn)為WSGI協(xié)議，然后python可以直接使用。
比如可以使用nginx處理靜態(tài)內(nèi)容，使用uWSGI處理動(dòng)態(tài)內(nèi)容。
對(duì)于Django和Flask其實(shí)自己本身帶有一個(gè)簡(jiǎn)單的WSGI server，一般用于服務(wù)器調(diào)試，生產(chǎn)環(huán)境下建議使用其他的，比如manage.py runserver就是啟動(dòng)一個(gè)WSGI，只用于本地開發(fā)，生產(chǎn)環(huán)境建議nginx+uwsgi+django
請(qǐng)求的生命周期
中間件的作用和應(yīng)用場(chǎng)景
介于request和response中間對(duì)數(shù)據(jù)處理的一個(gè)流程，用于全局范圍改變django的輸入和輸出，中間件就是在視圖函數(shù)執(zhí)行之前或者之后可以執(zhí)行額外的操作。
比如
中間件的五個(gè)方法：
- process_request：請(qǐng)求進(jìn)來(lái)，進(jìn)行認(rèn)證等
- process_view：路由匹配后得到視圖函數(shù)
- process_exception：異常的時(shí)候執(zhí)行
- process_template_responseprocess：渲染模板的時(shí)候執(zhí)行
- process_response：請(qǐng)求有響應(yīng)的時(shí)候執(zhí)行
這五個(gè)方法分別大概以下功能
中間件
- process_request(request)：收到request以后，按照settings.py文件中的中間件順序依次執(zhí)行，如果返回None，則繼續(xù)，如果返回HttpResponse，就返回不繼續(xù)了，也就是報(bào)錯(cuò)了
- process_view(request, view_func, view_args, view_kwargs)：執(zhí)行完上一步的方法以后，在url里面找到對(duì)應(yīng)的視圖函數(shù)，然后獲取到相應(yīng)參數(shù)，在執(zhí)行視圖函數(shù)之前執(zhí)行這一步。如果返回為None，則繼續(xù)執(zhí)行這個(gè)方法剩下的操作，如果返回HttpResponse，不執(zhí)行這個(gè)方法和視圖函數(shù)，繼續(xù)后面的函數(shù)
- process_exception(request, exception)：如果執(zhí)行視圖函數(shù)出錯(cuò)，按照settings.py中的中間件順序，倒序執(zhí)行這個(gè)方法，如果返回None，就繼續(xù)上一個(gè)方法的process_exception方法，如果返回HttpResponse，則不會(huì)被調(diào)用。也就是說(shuō)，如果沒(méi)有響應(yīng)，就說(shuō)明報(bào)錯(cuò)，倒序一級(jí)一級(jí)報(bào)錯(cuò)，如果有返回值說(shuō)明還是正常的，就繼續(xù)往下執(zhí)行后面兩個(gè)函數(shù)
- process_template_response(request, response)：response是視圖或者某一中間件的返回，只有response實(shí)現(xiàn)了render才能執(zhí)行，所有中間件的這個(gè)函數(shù)執(zhí)行完了，調(diào)用render()方法
- process_response(request, response)：在視圖函數(shù)執(zhí)行完以后執(zhí)行，必須有響應(yīng)HttpResponse
默認(rèn)的中間件
有幾個(gè)默認(rèn)配置的中間件，主要功能如下
- django.middleware.security.SecurityMiddleware：防止xss腳本過(guò)濾的安全改進(jìn)
- django.contrib.sessions.middleware.SessionMiddleware：開始session會(huì)話支持，可以使用session，不開啟就不能session保存數(shù)據(jù)
- django.contrib.messages.middleware.MessageMiddleware：提供cookie的功能支持
- django.middleware.common.CommonMiddleware：用來(lái)重寫URL。如果APPEND_SLASH為True，那么URL末尾沒(méi)有斜杠或者沒(méi)有找到對(duì)應(yīng)匹配的時(shí)候，會(huì)自動(dòng)添加末尾斜杠；PREPEND_WWW為True則會(huì)將沒(méi)有www.開頭的URL重定向到同樣的www.開頭的URL路由
- django.middleware.csrf.CsrfViewMiddleware：跨站請(qǐng)求偽造就不說(shuō)了
- django.contrib.auth.middleware.AuthenticationMiddleware：收到request后，可以對(duì)user對(duì)象添加相應(yīng)的HttpRequest屬性，表示當(dāng)前用戶身份呢
django中的csrf實(shí)現(xiàn)機(jī)制
基于django的ajax發(fā)送請(qǐng)求給后端如何攜帶token
CSRF跨站請(qǐng)求偽造，是一種對(duì)網(wǎng)站的惡意利用、竊取網(wǎng)站用戶信息制造惡意請(qǐng)求。
為了防護(hù)這類攻擊，在用戶提交表單的時(shí)候，表單中會(huì)自動(dòng)加入一個(gè)叫csrfmiddlewaretoken的隱藏控件，后臺(tái)也保存有這個(gè)控件的值，當(dāng)請(qǐng)求到達(dá)后端時(shí)，服務(wù)器會(huì)檢查這個(gè)值，如果匹配則進(jìn)行后續(xù)處理，否則不處理。
原理：
但是XSRF防護(hù)一般只適用于POST請(qǐng)求，不能防護(hù)GET，因?yàn)镚ET一般是制度性是訪問(wèn)網(wǎng)頁(yè)資源，不會(huì)涉及資源的更新和修改等操作。
在前端的form表單中添加{% csrf_token %}即可
如果不想使用csrf防護(hù)，前端取消這個(gè)模板語(yǔ)法，后端在對(duì)應(yīng)視圖函數(shù)簽名添加一個(gè)裝飾器@csrf_execpt即可。如果只刪除前者不修改后者，訪問(wèn)會(huì)報(bào)錯(cuò)403未授權(quán)。
如果需要對(duì)整個(gè)網(wǎng)站取消CSRF，settings.py里面刪除這個(gè)中間件即可。
ajax請(qǐng)求的csrf解決方法
在POST請(qǐng)求中設(shè)置請(qǐng)求參數(shù)csrfmiddlewaretoken，否則會(huì)認(rèn)為是惡意請(qǐng)求，需要獲取這個(gè)控件的值。
如下
為什么不使用django的runserver部署（runserver和uWSGI的區(qū)別）
WSGI Server 運(yùn)行，主要在測(cè)試和開發(fā)中使用，并且 runserver 開啟的方式也是單進(jìn)程 。
Kubernetes
k8s是為容器而生的一個(gè)可以指容器的編排管理工具，主要應(yīng)用于云原生領(lǐng)域。
主要提供了以下幾種功能：
- 服務(wù)發(fā)現(xiàn)與調(diào)度
- 負(fù)載均衡
- 服務(wù)自愈
- 服務(wù)彈性擴(kuò)容
- 橫向擴(kuò)容
- 存儲(chǔ)卷掛載
集群主要由Master節(jié)點(diǎn)和Node節(jié)點(diǎn)組成。
Master節(jié)點(diǎn)是集群控制節(jié)點(diǎn)，接收控制命令進(jìn)行具體執(zhí)行，主要包括kube-controller-manager和kube-scheduler和etcd，前者負(fù)責(zé)管理所有資源對(duì)象、維護(hù)集群狀態(tài)（故障檢測(cè)和自動(dòng)擴(kuò)展等）；后者負(fù)責(zé)資源調(diào)度，按照相應(yīng)策略將Pod調(diào)度到對(duì)應(yīng)的機(jī)器上，主要包括kube-proxy代理pod網(wǎng)絡(luò)定期從etcd獲取service信息相應(yīng)執(zhí)行、kubelet作為agent接受分配pods任務(wù)和管理容器定期獲取容器數(shù)據(jù)傳給kube-apiserver；etcd則負(fù)責(zé)保存整個(gè)集群的狀態(tài)。
是自動(dòng)化容器操作的開源平臺(tái)，主要包括：部署、調(diào)度和節(jié)點(diǎn)集群間擴(kuò)展
具體功能：
- 自動(dòng)化容器部署和復(fù)制
- 實(shí)時(shí)彈性收縮容器規(guī)模
- 容器編排成組并提供負(fù)載均衡
- 調(diào)度，決定容器在哪個(gè)節(jié)點(diǎn)運(yùn)行
什么是容器編排
可以使用某種工具配置完成一組容器以及相應(yīng)的資源如網(wǎng)絡(luò)、CPU等資源的定義、配置、創(chuàng)建、刪除等管理工作。
服務(wù)配置
Master節(jié)點(diǎn)部署
- controller manager：負(fù)責(zé)容器編排，可以通過(guò)restful api給api server發(fā)起請(qǐng)求，獲取集群內(nèi)所有對(duì)象的信息，當(dāng)檢測(cè)到一些故障的時(shí)候可以進(jìn)行相應(yīng)的干預(yù)。Controller一般包括：Namespace Controller、Node Controller、Service Controller、Token Controller等
- api server：對(duì)外提供api，接受請(qǐng)求
- scheduler：接收來(lái)自api-server發(fā)來(lái)的請(qǐng)求，準(zhǔn)備床創(chuàng)建Pod任務(wù)，之后會(huì)檢索出符合這個(gè)Pod的Node節(jié)點(diǎn)，中選擇一個(gè)合適的進(jìn)行調(diào)度創(chuàng)建
- etcd：k8s沒(méi)有使用單獨(dú)的數(shù)據(jù)庫(kù)，而是使用etcd作為數(shù)據(jù)存儲(chǔ)。因?yàn)閗8s中數(shù)據(jù)是隨時(shí)會(huì)變化的，比如用戶提交了一個(gè)任務(wù)、創(chuàng)建新Node、節(jié)點(diǎn)宕機(jī)等都需要對(duì)數(shù)據(jù)庫(kù)進(jìn)行操作，然后同時(shí)新的變化也需要讓各個(gè)服務(wù)能夠感知到。etcd的其中一個(gè)特性就是可以調(diào)用api監(jiān)聽到相應(yīng)的數(shù)據(jù)i需改情況，有修改etcd會(huì)自動(dòng)推送到客戶端，有什么通知scheduler和controller manager只需要把消息放在etcd里面就行了不需要挨個(gè)通知
Node節(jié)點(diǎn)部署
- kubelet：相當(dāng)于agent，負(fù)責(zé)維護(hù)容器的生命周期、卷和網(wǎng)絡(luò)的管理。通過(guò)api-server監(jiān)聽scheduler是否有pod綁定事件，有的話就從etcd獲取相應(yīng)信息創(chuàng)建Pod。同時(shí)進(jìn)行Pod的監(jiān)視，定期將狀態(tài)或發(fā)生的事件告知給其他各個(gè)組件
- kube-proxy：負(fù)責(zé)微Service提供集群內(nèi)的服務(wù)發(fā)現(xiàn)和負(fù)載均衡。是一個(gè)守護(hù)進(jìn)程，以Watcher的方式不斷監(jiān)控Pod，如果有什么變動(dòng)比如IP變了，就會(huì)修改相應(yīng)的規(guī)則策略，比如IP變了會(huì)修改相應(yīng)的iptables。之后負(fù)載均衡的時(shí)候就會(huì)根據(jù)proxy制定下發(fā)的策略進(jìn)行實(shí)現(xiàn)了。
- Networking
- Volume Plugin
- Container Runtime：負(fù)責(zé)運(yùn)行容器的軟件，支持多個(gè)Docker、Container等任何實(shí)現(xiàn)接口的
Pod
Pod是k8s最基本的操作單元，包含一個(gè)或多個(gè)相關(guān)的容器，是最小部署單元，其實(shí)代表一個(gè)集群中運(yùn)行的一個(gè)進(jìn)程。
一個(gè)Pod可以被一個(gè)容器化的環(huán)境看成應(yīng)用層的邏輯宿主機(jī)，一個(gè)Pod內(nèi)的多個(gè)容器通常緊密耦合，在Node上被創(chuàng)建、啟動(dòng)或者銷毀，每個(gè)Pod還運(yùn)行一個(gè)特殊的Volume掛載卷，使得容器間數(shù)據(jù)通信比較方便。
同一個(gè)Pod的使用localhost就可以通信，共享一下五種資源：
- 進(jìn)程號(hào)命名空間：Pod中不同應(yīng)用程序可以看到其他應(yīng)用程序的進(jìn)程ID
- 網(wǎng)絡(luò)命名空間：多個(gè)容器訪問(wèn)同一個(gè)IP和端口范圍，每個(gè)Pod共享一個(gè)IP
- UTS命名空間：共享一個(gè)主機(jī)名。使用Pod名作為主機(jī)名
- 進(jìn)程間通信命名空間：可以使用SystemV IC和POSIX消息隊(duì)列通信
- Volume：共享存儲(chǔ)卷，各個(gè)容器可以訪問(wèn)
Pod控制器
kubernetes的控制器
稱為工作負(fù)載，用于實(shí)現(xiàn)管理Pod的中間層，確保Pod的運(yùn)行時(shí)符合預(yù)期的，以及出現(xiàn)故障后應(yīng)該采取什么策略措施，比如重啟或者重建。
Controller在集群上運(yùn)行和管理各個(gè)Pod
Pod控制器實(shí)現(xiàn)Pod的運(yùn)維，伸縮等
控制器類型
- ReplicaSet（RS）：保證一定數(shù)量的Pod運(yùn)行，并且監(jiān)控Pod的狀態(tài)，當(dāng)出現(xiàn)故障的時(shí)候，會(huì)進(jìn)行重啟，如果重啟失敗則會(huì)重新創(chuàng)建。（也就是自愈機(jī)制）
- Deployment：工作在ReplicaSet之上，管理無(wú)狀態(tài)應(yīng)用，是最好用的控制器，提供有滾動(dòng)更新和回滾的功
- DaemonSet：確保集群中的每一個(gè)節(jié)點(diǎn)只運(yùn)行特定的Pod副本，常用于實(shí)現(xiàn)系統(tǒng)級(jí)后臺(tái)任務(wù)；服務(wù)是無(wú)特性的，必須要守護(hù)進(jìn)程
- StatefulSet：管理有應(yīng)用
- Job：一旦完成任務(wù)就會(huì)立刻退出，不需要重啟或者中間（一次性）
- CronJob：周期任務(wù)，不需要手動(dòng)執(zhí)行，自動(dòng)定期運(yùn)行
Replica Set和Replica Controller的區(qū)別
功能都差不多，都是保證一定數(shù)量的Pod的運(yùn)行，不同之處在于兩者對(duì)于Pods的復(fù)制策略不同。
前者使用基于集合的選擇器，后者使用基于權(quán)限的選擇器。
后者允許通過(guò)標(biāo)簽鍵值進(jìn)行選擇。
Set是更好的，可以對(duì)多個(gè)標(biāo)簽進(jìn)行選擇匹配
云控制器的理解
最初目的是使得云服務(wù)商的代碼和k8s的核心代碼獨(dú)立解耦，使得云控制器可以和k8s的組件（controller manager或者api等）一起使用，也可以作為插件在k8s中使用。其設(shè)計(jì)是基于插件機(jī)制的，所以很容易和k8s集成
- 節(jié)點(diǎn)控制器：從云服務(wù)提供商獲取到集群中運(yùn)行的節(jié)點(diǎn)信息，并且對(duì)節(jié)點(diǎn)初始化。
-
- 以云服務(wù)特定區(qū)域/低于標(biāo)簽初始化
-
- 以云服務(wù)特定的實(shí)例詳細(xì)信息（如類型和規(guī)格等）初始化
-
- 獲取節(jié)點(diǎn)的網(wǎng)絡(luò)地址和hostname
-
- 檢查狀態(tài)，看節(jié)點(diǎn)是否還存在于云服務(wù)中，如果不存在在k8s中也將其刪除
- 卷控制器：在創(chuàng)建卷比如AWS的卷的時(shí)候，添加相應(yīng)的標(biāo)簽，用戶不需要手動(dòng)添加標(biāo)簽了。因?yàn)橹挥刑幱谕粋€(gè)區(qū)域地區(qū)才有用，用標(biāo)簽保證吧
- 路由控制器：負(fù)責(zé)在云服務(wù)中配置相應(yīng)的路由，使得k8s中的容器可以相互之間進(jìn)行通信，只適用于谷歌計(jì)算引擎集群
- 服務(wù)控制器：監(jiān)聽服務(wù)的創(chuàng)建、刪除和修改事件。比如說(shuō)基于當(dāng)前的k8s狀態(tài)配置云負(fù)載均衡服務(wù)，可以保證服務(wù)后端始終是最新狀態(tài)
支持四種服務(wù)類型
- Cluster IP（集群IP）：啟動(dòng)多個(gè)集群內(nèi)的Pod通信服務(wù)，相當(dāng)于是一個(gè)內(nèi)部通信，可以進(jìn)行內(nèi)部調(diào)試之類的
- Node Port（節(jié)點(diǎn)端口）：將主機(jī)上的隨機(jī)端口流量準(zhǔn)發(fā)到路由器的隨機(jī)端口去。有些缺點(diǎn)：外部不能用locahhost、每次Pod啟動(dòng)IP都會(huì)變，無(wú)法設(shè)置DNS
- LoadBalancer（負(fù)載均衡）：
- Ingress：是一個(gè)規(guī)則集合，作為集群的入口點(diǎn)，主要負(fù)責(zé)將入站鏈接配置為可達(dá)的URL，負(fù)載平衡流量以及基于名稱的對(duì)外提供虛擬服務(wù)器功能。其實(shí)像一個(gè)API服務(wù)，對(duì)外提供API進(jìn)行調(diào)用
什么是Headless Service
又叫無(wú)頭服務(wù)，是一種特殊的服務(wù)類型。
ClusterIP是None，運(yùn)行時(shí)不會(huì)給分配IP，可以通過(guò)查詢Server的DNS獲得所有Server和Pod的地址信息，可以根據(jù)自己的需求決定使用哪個(gè)Server
一般結(jié)合StatefulSet來(lái)部署有狀態(tài)的應(yīng)用，比如kafka集群，mysql集群，zk集群等
服務(wù)發(fā)現(xiàn)
k8s使用兩種方式進(jìn)行服務(wù)發(fā)現(xiàn)：
- 環(huán)境變量：創(chuàng)建一個(gè)Pod以后，kubelet會(huì)在Pod中注入集群內(nèi)所有Service相關(guān)環(huán)境變量，要求Service先于Pod創(chuàng)建
- DNS：通過(guò)claster add-on方式創(chuàng)建kubeDNS對(duì)集群Service進(jìn)行服務(wù)發(fā)現(xiàn)
CNI
Container Network Interface，容器網(wǎng)絡(luò)接口式Linux容器網(wǎng)絡(luò)配置的一組標(biāo)準(zhǔn)和庫(kù)，可以根據(jù)這些開發(fā)自己的容器網(wǎng)絡(luò)插件。只專注于容器網(wǎng)絡(luò)連接和容器銷毀時(shí)的資源釋放，支持大量不同的網(wǎng)絡(luò)模式。
kuryr-libnetwork
四層、七層負(fù)載均衡
- 二層負(fù)載均衡：基于MAC地址
- 三層負(fù)載均衡：基于IP地址
- 四層負(fù)載均衡：基于IP+端口號(hào)
- 七層負(fù)載均衡：基于URL等應(yīng)用層信息
網(wǎng)絡(luò)模型
每個(gè)Pod都有一個(gè)獨(dú)立IP，不管是否運(yùn)行在一個(gè)Node上的容器都可以通過(guò)IP直接訪問(wèn)
由docker0實(shí)際分配IP；內(nèi)部看到的IP與端口和外部一致；同一個(gè)Pod內(nèi)不同容器共享網(wǎng)絡(luò)可以通過(guò)localhost通信，相當(dāng)于一個(gè)虛擬機(jī)中的多個(gè)進(jìn)程。
Docker
一些參考
Docker 核心技術(shù)與實(shí)現(xiàn)原理
Docker進(jìn)階之Cgroup介紹
CSDN的云原生入門技能樹/容器(docker)/安裝docker
NameSpace
這個(gè)在linux知識(shí)點(diǎn)章節(jié)有
當(dāng)一個(gè)容器運(yùn)行時(shí)，會(huì)創(chuàng)建一系列namespace，使用命名空間將容器間進(jìn)行隔離。
- IPC命名空間（進(jìn)程間通信）：將消息隊(duì)列分離出來(lái)
- 進(jìn)程命名空間：命名空間內(nèi)的虛擬PID可能會(huì)和外面的pid重復(fù)，會(huì)映射到哇面的另一個(gè)pid
- 網(wǎng)絡(luò)命名空間：用來(lái)隔離網(wǎng)絡(luò)資源，可以虛擬出網(wǎng)卡，而且后臺(tái)進(jìn)程可以運(yùn)行在不同的命名空間的相同端口
- 掛載命名空間：可以將掛載點(diǎn)與系統(tǒng)分離
- UTS命名空間：獨(dú)立出主機(jī)名和網(wǎng)絡(luò)信息服務(wù)
- 用戶命名空間：不同空間可以存在相同ID的用戶
命名空間的缺點(diǎn)：
隔離不徹底，因?yàn)檫€是共享宿主機(jī)的操作系統(tǒng)和內(nèi)核，有可能通過(guò)容器的某些操作可以直接影響到宿主機(jī)（給應(yīng)用暴露的攻擊面太大）
有的資源沒(méi)法進(jìn)行命名空間隔離，比如修改容器的時(shí)間宿主機(jī)的時(shí)間也會(huì)修改。
Cgroups
可以對(duì)程序使用的資源進(jìn)行限制。可以限制CPU、內(nèi)存、磁盤讀寫速率、網(wǎng)絡(luò)帶寬等系統(tǒng)資源。Linux使用文件系統(tǒng)來(lái)實(shí)現(xiàn)Cgroups，cgroup是內(nèi)核提供的分組化管理的功能和接口。
有如下幾個(gè)特點(diǎn)：
- API以偽文件系統(tǒng)的方式實(shí)現(xiàn)，用戶態(tài)程序可以通過(guò)操作文件實(shí)現(xiàn)Cgroups的組織管理
- 單元細(xì)粒度可以精確到線程級(jí)別，可以創(chuàng)建銷毀Cgroup，實(shí)現(xiàn)資源再分配和管理
- 所有的資源管理以子系統(tǒng)的方式實(shí)現(xiàn)，接口統(tǒng)一
- 子任務(wù)剛創(chuàng)建的時(shí)候和父任務(wù)的Cgroups一致
cgroups是內(nèi)核附加在程序上的一系列鉤子，通過(guò)程序運(yùn)行時(shí)對(duì)資源的調(diào)度觸發(fā)相應(yīng)的鉤子以達(dá)到資源追蹤和限制的目的。
提供以下幾個(gè)功能：
- 資源限制，對(duì)任務(wù)使用的資源進(jìn)行限制，比如限制了內(nèi)存以后，超過(guò)內(nèi)存限制會(huì)報(bào)錯(cuò)OOM
- 優(yōu)先級(jí)分配，通過(guò)分配CPU時(shí)間片和IO帶寬大小，相當(dāng)于控制了任務(wù)運(yùn)行優(yōu)先級(jí)。
- 資源統(tǒng)計(jì)：可以統(tǒng)計(jì)資源使用情況，比如CPU使用時(shí)間，內(nèi)存使用量
- 任務(wù)控制：可以對(duì)任務(wù)掛起、恢復(fù)
有幾個(gè)概念：
- task：任務(wù)，指一個(gè)進(jìn)程或者線程
- cgroup：控制組，按照某種資源控制情況劃分的任務(wù)組，包含有一個(gè)或者多個(gè)子系統(tǒng)，一個(gè)任務(wù)可以加入某個(gè)cgroup，也可以從一個(gè)cgroup遷移到另一個(gè)cgroup
- subsystem（子系統(tǒng)）：每個(gè)子系統(tǒng)就是一個(gè)資源控制器，比如CPU子系統(tǒng)控制CPU使用的時(shí)間
- hierarchy（層級(jí)）：層級(jí)由一系列cgroup以樹狀結(jié)構(gòu)排列，每層綁定對(duì)應(yīng)子系統(tǒng)實(shí)現(xiàn)資源控制
有幾個(gè)規(guī)則關(guān)系：
- 同一個(gè)層級(jí)可以附加多個(gè)子系統(tǒng)，比如一個(gè)cgroup可以有CPU和Memory子系統(tǒng)
- 一個(gè)子系統(tǒng)可以附加到多個(gè)層級(jí)，當(dāng)且僅當(dāng)目標(biāo)層級(jí)只有唯一一個(gè)子系統(tǒng)，比如如果B層級(jí)有內(nèi)存子系統(tǒng)，不能附加CPU子系統(tǒng)了
- 每次新建一個(gè)層級(jí)的時(shí)候，所有任務(wù)默認(rèn)加入到這個(gè)初始cgroup
- frok、clone自身創(chuàng)建的子任務(wù)默認(rèn)與原任務(wù)在一個(gè)cgroup里，子任務(wù)允許被移動(dòng)到不同的cgroups
子系統(tǒng)
有如下
- blkio：為塊設(shè)備設(shè)置輸入、輸出限制，比如物理驅(qū)動(dòng)設(shè)備（磁盤、USB等）
- cpu：設(shè)置CPU使用時(shí)間，用于調(diào)度程序
- cpuset：多處理器系統(tǒng)可以為任務(wù)分配相應(yīng)的處理器和內(nèi)存
- cpuset：對(duì)cpu資源的使用情況生成報(bào)告
- memory：對(duì)任務(wù)的任務(wù)使用量進(jìn)行限制，同時(shí)生成內(nèi)存使用情況的報(bào)告
- devices：開啟或者管理cgroup里任務(wù)對(duì)設(shè)備的訪問(wèn)
- freezer：掛起或者恢復(fù)cgroup的任務(wù)
- perf_event：使得cgroup里的任務(wù)可以進(jìn)行性能測(cè)試
- net_cls：標(biāo)記網(wǎng)絡(luò)數(shù)據(jù)包，允許流量控制程序識(shí)別cgroup里生成的數(shù)據(jù)包
比如對(duì)于cpu子系統(tǒng)，/sys/fs/cgroup/cpu里面有一些控制組的文件，創(chuàng)建一個(gè)控制組文件夾以后，會(huì)出現(xiàn)一些文件。
限制一個(gè)指定進(jìn)程的cpu使用配額
先添加進(jìn)程PID，然后添加具體配置
在創(chuàng)建容器時(shí)，daemon會(huì)在單獨(dú)掛載的子系統(tǒng)控制目錄下創(chuàng)建一個(gè)對(duì)應(yīng)的docker控制組，然后再創(chuàng)建一個(gè)容器控制組名為Docker ID，容器的所有進(jìn)程好都會(huì)寫在這個(gè)的tasks里面，在對(duì)應(yīng)的控制文件里寫相應(yīng)的資源配額信息。
對(duì)于內(nèi)存如果超過(guò)cgroup最大限制以后，如果設(shè)置了OOM Control（內(nèi)存超限控制），進(jìn)程就會(huì)收到OOM信號(hào)然后結(jié)束，否則會(huì)一直掛起，直到其他進(jìn)程釋放對(duì)應(yīng)的內(nèi)存資源。
cgroup.procs可以對(duì)線程進(jìn)行配置，寫入線程組中的第一個(gè)進(jìn)程的PID，也就是把相關(guān)線程都加到cgroup里面
驅(qū)動(dòng)
docker的daemon進(jìn)程通過(guò)接收相應(yīng)的API請(qǐng)求，然后將去轉(zhuǎn)為使用相應(yīng)的系統(tǒng)調(diào)用，從而創(chuàng)建和管理容器。docker將這些系統(tǒng)調(diào)用抽象為了一些操作接口方便調(diào)用，包括：容器執(zhí)行驅(qū)動(dòng)、volume存儲(chǔ)驅(qū)動(dòng)以及鏡像存儲(chǔ)驅(qū)動(dòng)三種。
execdriver
對(duì)namesapce、cgroups等進(jìn)行了二次封裝，是默認(rèn)的libcontainer庫(kù)
volumedriver
負(fù)責(zé)volume的增刪改查，屏蔽不同驅(qū)動(dòng)帶來(lái)的差異，為上層提供一個(gè)統(tǒng)一的接口調(diào)用。
graphdriver
和鏡像有關(guān)，維護(hù)一個(gè)一組與鏡像曾對(duì)應(yīng)的目錄，以及相應(yīng)的元數(shù)據(jù)，用戶對(duì)鏡像的操作會(huì)對(duì)應(yīng)位對(duì)這些目錄文件以及元數(shù)據(jù)的增刪改查，屏蔽不同文件存儲(chǔ)實(shí)現(xiàn)帶來(lái)的差異。
docker daemon的主要啟動(dòng)步驟如下三步
- 啟動(dòng)API Server，工作在宿主機(jī)的HOST上
- 使用NewDaemon方法創(chuàng)建daemon對(duì)象，保存信息和處理業(yè)務(wù)邏輯
- 將API Server和daemon綁定起來(lái)，接受處理client的請(qǐng)求
啟動(dòng)一個(gè)容器的步驟
從client 到 daemon，docker run舉例
最后創(chuàng)建容器的時(shí)候會(huì)使用到libcontainer。
在準(zhǔn)備好配置文件以后，會(huì)創(chuàng)建一個(gè)container對(duì)象，這里面存儲(chǔ)的是配置信息的對(duì)象，然后才是有Container邏輯容器對(duì)象，libcontainer會(huì)根據(jù)信息創(chuàng)建相應(yīng)的namespace，以及cgroups，然后創(chuàng)建docker。
基礎(chǔ)
什么是Docker
Docker是一個(gè)容器化平臺(tái)，以容器的形式將應(yīng)用程序和其環(huán)境依賴打包，可以在任何Docker環(huán)境中無(wú)縫銜接運(yùn)行
Docker與虛擬機(jī)的不同
Docker不是虛擬化，依賴于實(shí)際實(shí)現(xiàn)基于容器的虛擬話或者操作系統(tǒng)級(jí)虛擬化的其他工具，最初使用LXC驅(qū)動(dòng)，后來(lái)移動(dòng)到libcontainer重命名為runc。
專注于應(yīng)用程序容器內(nèi)自動(dòng)部署應(yīng)用程序，應(yīng)用程序指打包和運(yùn)行一個(gè)應(yīng)用程序，操作系統(tǒng)容器則設(shè)計(jì)為運(yùn)行多個(gè)進(jìn)程，如虛擬機(jī)。
特點(diǎn)：
虛擬機(jī)底層是需要使用hypervisor來(lái)模擬硬件虛擬化的，可以虛擬出一個(gè)操作系統(tǒng)所需的各種硬件資源比如cpu、ram、disk，在其上安裝目標(biāo)操作系統(tǒng)。
Docker和普通進(jìn)程的區(qū)別
當(dāng)一個(gè)程序代碼被編譯為二進(jìn)制文件，然后這個(gè)文件被加載到內(nèi)存然后得到cpu的使用權(quán)時(shí)，這個(gè)程序就變成了一個(gè)正在運(yùn)行的進(jìn)程，會(huì)去對(duì)寄存器進(jìn)行操作，對(duì)堆棧進(jìn)行操作以實(shí)現(xiàn)相應(yīng)功能。
而容器則是通過(guò)約束和修改進(jìn)程的動(dòng)態(tài)表現(xiàn)，給其創(chuàng)造一個(gè)邊界。cgroups主要用來(lái)進(jìn)行約束，而namespace則主要用來(lái)創(chuàng)造邊界
鏡像
什么是Docker鏡像和Docker容器
鏡像就是容器的源代碼，用于創(chuàng)建容器。
Docker容器包含了應(yīng)用程序和其所需的以來(lái)，作為操作系統(tǒng)的一個(gè)獨(dú)立進(jìn)程運(yùn)行的。
鏡像保存在/var/lib/docker/
Docker鏡像分層
是基于UnionFs（聯(lián)合文件系統(tǒng)），這是一種分層的、輕量級(jí)的而且高性能的文件系統(tǒng)，支持對(duì)文件系統(tǒng)的修改作為一次提交來(lái)一層一層提交，而且可以把不同目錄掛載到同一個(gè)虛擬文件系統(tǒng)下。
實(shí)際上一次會(huì)加載多個(gè)文件系統(tǒng)，但是使用上只能看到一個(gè)文件系統(tǒng)，聯(lián)合加載會(huì)把每層文件系統(tǒng)疊加起來(lái)，最終的文件系統(tǒng)就會(huì)包含所有的底層文件和目錄。
實(shí)質(zhì)上就是一層一層的文件系統(tǒng)。
所有docker都初始于一個(gè)基礎(chǔ)鏡像層，增加或者修改內(nèi)容的時(shí)候，會(huì)在這個(gè)基礎(chǔ)上新增一層。
舉個(gè)例子
如果需要基于ubuntu18.04配置新鏡像，第一層就是ubuntu18.04
我們需要安裝python，第二層就是python包
我們需要安裝一個(gè)安全補(bǔ)丁，這個(gè)補(bǔ)丁就是第三層
Docker鏡像是只讀的，在啟動(dòng)容器的時(shí)候，會(huì)把一個(gè)可寫層加到鏡像頂部，就是容器層，容器層。下面都是鏡像層。
bootfs
boot file system。有一個(gè)bootloader和kernel，loader負(fù)責(zé)加載kernel，linux剛系統(tǒng)的時(shí)候就會(huì)加載bootfs，docker的底層就是bootfs，bootfs加載完成以后，內(nèi)核就在內(nèi)存里了，內(nèi)存的使用權(quán)就由bootfs交給內(nèi)核了，然后就可以卸載bootfs了。
rootfs，root file system在bootfs之上，包含有l(wèi)inux中的/dev、/proc、/bin、/etc等標(biāo)準(zhǔn)目錄和文件，這個(gè)其實(shí)就是各種linux發(fā)行版。
對(duì)于精簡(jiǎn)os，rootfs只需要包含最基本的命令、工具和程序庫(kù)，因?yàn)榭梢灾苯邮褂玫讓觡ernel，所以只需要rootfs，而對(duì)于不同的發(fā)行版，bootfs都是差不多的，所以可以公用
容器分層、寫時(shí)復(fù)制（copy-on-write）
容器和鏡像的區(qū)別其實(shí)就是容器會(huì)在最頂層有一個(gè)可寫層，對(duì)于容器的所有寫操作都會(huì)記錄在這里面，容器刪除的話這個(gè)可寫層就刪除了。
每個(gè)容器都有著自己的可寫層，所以多個(gè)容器可以共享一個(gè)鏡像
對(duì)于多個(gè)鏡像來(lái)說(shuō)，鏡像的分層會(huì)出現(xiàn)公用的情況，所以不能單純看docker images列出來(lái)的大小。
多個(gè)容器之間可以共享鏡像，在啟動(dòng)容器的時(shí)候不必單獨(dú)復(fù)制一份，而是把所有鏡像層以只讀的形式掛載到一個(gè)掛載點(diǎn)上，在最上層加一個(gè)可讀寫的容器層，在沒(méi)有更改的時(shí)候所有容器共享一份數(shù)據(jù)，只有對(duì)文件系統(tǒng)進(jìn)行修改的時(shí)候，會(huì)把相應(yīng)的內(nèi)容寫到可讀寫層里，并且隱藏只讀層里的老版本文件，用心的覆蓋，減少了鏡像對(duì)磁盤空間的占用和容器的啟動(dòng)時(shí)間。
DockerFile常見指令
Dockerfile 是一個(gè)用來(lái)構(gòu)建鏡像的文本文件，文本內(nèi)容包含了一條條構(gòu)建鏡像所需的指令和說(shuō)明。
- FROM：指定基礎(chǔ)鏡像，基于什么鏡像
- LABEL：指定鏡像的標(biāo)簽
- RUN：運(yùn)行指定命令
- CMD：啟動(dòng)容器的時(shí)候執(zhí)行什么命令，類似自啟動(dòng)，如果有多個(gè)指令，只執(zhí)行最后一條
- ENTRYPOINT：類似于CMD指令，但是不會(huì)被覆蓋掉，
build
docker build -t {name}:{tag} .
最后的點(diǎn)就表示上下文路徑。
docker在構(gòu)造的時(shí)候會(huì)使用到本機(jī)文件，比如復(fù)制進(jìn)去，他會(huì)在這個(gè)上下文路徑中去尋找，把里面的文件都打包進(jìn)去，不寫就默認(rèn)Dockerfile所在的目錄。
步驟時(shí)：
- 發(fā)送請(qǐng)求個(gè)Server端，然后創(chuàng)建臨時(shí)目錄讀取Dockerfile
- 根據(jù)解析的結(jié)果遍歷命令，將其分發(fā)給不同模塊進(jìn)行執(zhí)行。
- parser會(huì)給每個(gè)指令創(chuàng)建一個(gè)臨時(shí)容器，在臨時(shí)容器中執(zhí)行當(dāng)前指令，然后使用commit生成一個(gè)鏡像層
- 所有指令對(duì)應(yīng)的層的集合，就是build的而結(jié)果。最后一次commit生成的鏡像ID就是最后的鏡像ID
Dockerfile的COPY和ADD
COPY指的是從上下文目錄中復(fù)制文件到容器里的指定路徑。
ADD也是復(fù)制文件。
COPY的SRC只能是本地文件。
而且ADD會(huì)自動(dòng)解壓一些格式的文件gzip等，不解壓的時(shí)候tar就不能復(fù)制進(jìn)去，會(huì)使得構(gòu)建失敗。
ADD還可以給容器里添加遠(yuǎn)程文件。但是建議用curl或者wget命令下載文件，因?yàn)锳DD的話會(huì)給鏡像加一層，導(dǎo)致體積變大臃腫。
Docker容器的狀態(tài)
運(yùn)行、退出、已暫停、重新啟動(dòng)
網(wǎng)絡(luò)
docker的網(wǎng)絡(luò)部分已經(jīng)被獨(dú)立為libnetwork了。使用的CNM（容器網(wǎng)絡(luò)羋姓）提供了多種網(wǎng)絡(luò)接口可以使用。
daemon通過(guò)調(diào)用libnetwork對(duì)外提供的API完成網(wǎng)絡(luò)的創(chuàng)建和管理，libcontainer則使用CNM。libcontainer里面提供了五種網(wǎng)絡(luò)驅(qū)動(dòng)可以使用，有三個(gè)核心組件。
- 沙盒：包含一個(gè)容器網(wǎng)絡(luò)棧信息，可以對(duì)容器接口、路由和DNS等進(jìn)行管理，具體實(shí)現(xiàn)可以是namespace
- 端點(diǎn)：一個(gè)端點(diǎn)可以加入一個(gè)沙盒和一個(gè)網(wǎng)絡(luò)，具體實(shí)現(xiàn)有veth pair、ovs內(nèi)部端口等
- 網(wǎng)絡(luò)：是一組可以互聯(lián)互通的端點(diǎn)，具體實(shí)現(xiàn)可以是lunexbridge、vlan，一個(gè)網(wǎng)絡(luò)可以有多個(gè)端點(diǎn)
驅(qū)動(dòng)：
- bridge：默認(rèn)配置，會(huì)將創(chuàng)建出來(lái)的容器連接到docker0網(wǎng)橋上，和外界通信使用NAT，復(fù)雜場(chǎng)景下使用會(huì)有不少限制
- host：不會(huì)為容器創(chuàng)建網(wǎng)絡(luò)協(xié)議棧，不會(huì)有獨(dú)立的namespace，處于宿主機(jī)的網(wǎng)絡(luò)環(huán)境中，共用宿主機(jī)的namesapace，如IP、網(wǎng)卡端口等信息。較好的解決了與外界通信的地址轉(zhuǎn)換問(wèn)題，但是降低了容器和宿主機(jī)或者容器之間的網(wǎng)絡(luò)隔離問(wèn)題，網(wǎng)絡(luò)資源的使用可能會(huì)出現(xiàn)競(jìng)爭(zhēng)沖突。
- overlay：vxlan比如大型云計(jì)算虛擬化環(huán)境里的SDN Controller模式
- remote：這個(gè)欸有實(shí)現(xiàn)真正的網(wǎng)絡(luò)服務(wù)，而是會(huì)調(diào)用用戶所提供的網(wǎng)絡(luò)驅(qū)動(dòng)插件，比如Kuryr-libnetwork。根據(jù)libnetwork提供的標(biāo)準(zhǔn)實(shí)現(xiàn)相應(yīng)的接口就可以找daemon進(jìn)行注冊(cè)使用
- null：容器有自己的namespace，只有l(wèi)o網(wǎng)卡，需要用戶自己配置網(wǎng)卡IP等信息，優(yōu)點(diǎn)時(shí)配置使用非常自由，缺點(diǎn)就是 不配置不能使用，使用要求高。
docker0本質(zhì)上就是網(wǎng)橋，而且這里的網(wǎng)橋概念可以相當(dāng)于時(shí)交換機(jī)，可以為連接在其上的設(shè)備進(jìn)行數(shù)據(jù)幀的轉(zhuǎn)發(fā)，容器的網(wǎng)卡eth0通過(guò)veth連接到docker0網(wǎng)橋上，不需要配置IP地址就可以進(jìn)行數(shù)據(jù)幀的轉(zhuǎn)發(fā)。
Docker的網(wǎng)絡(luò)類型
有4種類型，bridge、host、container以及none
bridge：默認(rèn)情況創(chuàng)建容器是使用網(wǎng)橋bridge去連接，docker0，容器之間通過(guò)網(wǎng)橋通信。對(duì)外通信的話網(wǎng)橋會(huì)與宿主機(jī)進(jìn)行一個(gè)IP轉(zhuǎn)換。這里的虛擬連接也是使用類似與虛擬網(wǎng)線的那樣，就虛擬機(jī)里面的eth0連接到網(wǎng)橋?qū)?yīng)的veth。如果需要外部訪問(wèn)進(jìn)來(lái)，得通過(guò)端口映射，然后使用宿主機(jī)的端口和這個(gè)映射的端口進(jìn)行訪問(wèn)
host：會(huì)默認(rèn)使用宿主機(jī)的網(wǎng)絡(luò)，不會(huì)有自己的命名空間虛擬機(jī)網(wǎng)卡之類的，在網(wǎng)絡(luò)上是沒(méi)辦法隔離的。使用了host就只能指定端口了，訪問(wèn)進(jìn)來(lái)的話用宿主機(jī)的IP和這個(gè)映射的端口
container：指定新創(chuàng)建的容器和已有的容器共享namespace，同樣不會(huì)自己創(chuàng)建網(wǎng)卡和IP地址，和這個(gè)特定容器一起共享，進(jìn)程間通過(guò)lo通信。
none：會(huì)創(chuàng)建一個(gè)命名空間 ，但是ip、虛擬網(wǎng)卡之類的都得自己配置，很不好用不方便。但是隔離安全性非常好
docker常用命令
- docker images：查看鏡像
- docker rm / rmi：刪除容器/鏡像
- docker pull / push：拉取/上傳鏡像
- docker ps -a：列出所有鏡像，不帶參數(shù)只列出開機(jī)鏡像
- docker cp {path} {docker_id}:{docker_path}：復(fù)制文件到指定容器的路徑下，也可以返回來(lái)復(fù)制出文件
- docker run -d --name container cirros -p 5000:5050：啟動(dòng)容器
面經(jīng)
OpenStack
一些命令行
- 命令啟動(dòng)虛擬機(jī)：openstack server create --flaver {name} --nic net-id={network-id} --security-group {id} {name}
命令上傳下載鏡像：opensatck image create --disk-format qcow2 --container-format bare --public --file {local-path} {name}
glance image-download --file {id} {local-path} - 修改實(shí)例狀態(tài)為活動(dòng)狀態(tài)：比如有時(shí)候?qū)嵗龝?huì)卡住，比如刪除的時(shí)候因?yàn)槟承┕收峡ㄗ×?#xff0c;處于deleting狀態(tài)一直卡住，這個(gè)操作可以使其變?yōu)榛顒?dòng)狀態(tài)，然后他大概會(huì)進(jìn)入error，然后就可以正常刪除了。nova restet-state --active {server-id}
- 指定集群和節(jié)點(diǎn)：–availiable-zone {region}:{host}，指定在哪個(gè)集群的哪個(gè)節(jié)點(diǎn)創(chuàng)建
- 查看實(shí)例的日志和控制臺(tái)url：openstack console log {id}和openstack console url show {id}
OpenStack中計(jì)算節(jié)點(diǎn)上虛擬機(jī)默認(rèn)保存路徑在哪？
在計(jì)算節(jié)點(diǎn)的/var/lib/nova/instances目錄。
OpenStack中Glance鏡像的默認(rèn)保存路徑在哪？
控制節(jié)點(diǎn)的/var/lib/glance/images目錄。
OpenStack中計(jì)算節(jié)點(diǎn)的集成橋（br-int）的作用是什么？
對(duì)通過(guò)實(shí)例的流量進(jìn)行標(biāo)記和取消標(biāo)記的操作，VLAN網(wǎng)絡(luò)。
OpenStack中計(jì)算節(jié)點(diǎn)的隧道橋（br-tun）的作用是什么？
隧道橋（br-tun）根據(jù) OpenFlow 規(guī)則將 VLAN 標(biāo)記的流量從集成網(wǎng)橋轉(zhuǎn)換為隧道 ID。
隧道橋允許不同網(wǎng)絡(luò)的實(shí)例彼此進(jìn)行通信。隧道有利于封裝在非安全網(wǎng)絡(luò)上傳輸?shù)牧髁?#xff0c;它支持兩層網(wǎng)絡(luò)，即 GRE 和 VXLAN。
OpenStack中外部OVS橋（br-ex）的作用是什么？
用于轉(zhuǎn)發(fā)來(lái)往的網(wǎng)絡(luò)流量，允許實(shí)例與外部網(wǎng)絡(luò)進(jìn)行通信
OpenStack和Docker區(qū)別
OpenStack是一個(gè)成熟的完整的云資源管理的平臺(tái)。可以統(tǒng)一管理平臺(tái)中的計(jì)算、存儲(chǔ)以及網(wǎng)絡(luò)等資源，提供對(duì)于虛擬機(jī)的調(diào)度管理。底層默認(rèn)使用kvm和qemu去管理虛擬機(jī)，但是同樣可以管理容器。
而docker則是負(fù)責(zé)管理計(jì)算機(jī)中需要與其他進(jìn)程相互隔離的容器，容器的開銷相比于虛擬機(jī)更少，本質(zhì)上就是一個(gè)操作系統(tǒng)進(jìn)程，可以將自己的環(huán)境或者應(yīng)用程序部署在容器里，然后打包分發(fā)之類的，可以實(shí)現(xiàn)快速部署。
docker應(yīng)該和虛擬機(jī)是一個(gè)類別的。
OpenStack和kvm的區(qū)別
OpenStack本質(zhì)只是一個(gè)云管理平臺(tái)，不具備比如虛擬化這種功能。虛擬化是通過(guò)系統(tǒng)底層實(shí)現(xiàn)的hypervisior（kvm、qemu和Xen、virtual box等）實(shí)現(xiàn)的。
如果沒(méi)有OpenStack同樣可以使用其他工具來(lái)管理kvm，比如libvirt提供的vish-manager。
kvm和xen區(qū)別
kvm是一個(gè)內(nèi)核提供的輕量級(jí)虛擬化管理解決方案，需要虛擬化支持（Intel-VT或者AMD-V）。
Xen是運(yùn)行支持的Xen內(nèi)核，可以在系統(tǒng)上使用qemu模擬多個(gè)虛擬機(jī)。
kvm可以使用通常的linux調(diào)度和內(nèi)存管理
Xen更新以后需要重新編譯內(nèi)核，而kvm只需要重新安裝模塊即可，更加精簡(jiǎn)，避免出錯(cuò)的幾率。
Neutron
vlan和vxlan的區(qū)別
vlan的vni是12位：1-4096，vxlan是24位，最大可以一一千六百多萬(wàn)個(gè)vni。
vxlan是基于隧道技術(shù)在屋里三層網(wǎng)絡(luò)中模擬二層網(wǎng)絡(luò)，對(duì)二層數(shù)據(jù)包的一個(gè)封裝，使用UDP在三層網(wǎng)絡(luò)進(jìn)行一個(gè)轉(zhuǎn)發(fā)。
vlan只能用于廣播域的隔離，但是解決不了IP地址和MAC的重疊問(wèn)題，vxlan可以做到不同租戶獨(dú)立組網(wǎng)，通信地址分配以及多租戶的地址沖突問(wèn)題可以解決。
交換機(jī)一個(gè)端口對(duì)應(yīng)一個(gè)物理設(shè)備以及一個(gè)MAC地址，但是現(xiàn)在雖然一個(gè)端口還是連接一個(gè)物理機(jī)，但是可能會(huì)連接到多個(gè)虛擬機(jī)，傳統(tǒng)交換機(jī)收到一個(gè)數(shù)據(jù)幀以后，根據(jù)vlan和目的MAC找到相應(yīng)端口，將數(shù)據(jù)包轉(zhuǎn)發(fā)出去。同時(shí)交換機(jī)會(huì)記住學(xué)習(xí)這個(gè)MAC記錄，但是交換機(jī)內(nèi)存是有限的，隨著虛擬化的實(shí)現(xiàn)，網(wǎng)絡(luò)中的MAC地址非常多的，交換機(jī)如果不足以支持的話，可能會(huì)移除，然后就不能正常工作，如果找不到MAC會(huì)進(jìn)行flood，增加其他網(wǎng)絡(luò)設(shè)備的負(fù)擔(dān)和網(wǎng)絡(luò)擁塞。
使用VxLAN，以太幀會(huì)被VTEP封裝在UDP里面，一個(gè)VTEP可以被一個(gè)物理及的所有虛擬機(jī)使用，對(duì)于交換機(jī)，他看到的只是VTEP之間傳遞信息，并看不到實(shí)際虛擬機(jī)傳遞信息。所以交換機(jī)只需要記錄VTEP的信息即主機(jī)信息即可。
Docker
命名空間
- 網(wǎng)絡(luò)命名空間：網(wǎng)絡(luò)設(shè)備端口等
- 進(jìn)程命名空間：進(jìn)程編號(hào)
- 用戶命名空間：用戶和用戶組
- 掛載命名空間：掛載點(diǎn)、文件系統(tǒng)
- UTS命名空間：主機(jī)名和域名
- IPC命名空間：信號(hào)量、消息隊(duì)列共享內(nèi)存
總結(jié)
以上是生活随笔為你收集整理的面经 - OpenStack（Docker、Django、K8S、SDN）知识点的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： php判断是否夏令时,关于php：时区和
- 下一篇： Shell 脚本 一键安装/一键卸载/一