亚洲av午夜成人影院老师机影院_3000部国产bt视频_久久婷婷精品日韩_鲁鲁狠色综合色综合网站_搞机time下载不用不收钱嘉兴_在线欧美日韩_国产高清无码日韩一区_朋友人妻翘臀迎接我粗大撞击在线播放

在以Kubernetes 為代表的云原生浪潮席卷全球之前，OpenStack 一度風(fēng)光無兩，但是隨著K8s的日益普及，有很多OpenStack用戶開始轉(zhuǎn)向云原生，OpenStack + Kubernetes 是目前相對流行的云應(yīng)用解決方案棧。

在前不久舉辦的OpenInfra Days China 2021大會上，英特爾Chief Architect Andrew Zhang，以及Kube-OVN項目發(fā)起人/靈雀云資深研發(fā)工程師劉夢馨帶來了一個聯(lián)合分享，介紹怎樣把OpenStack和K8s融合在一起。

以下為演講實錄：

云原生趨勢下融合OpenStack與K8s（by Andrew Zhang）

多年以來， OpenStack都是業(yè)界私有云方案主流，企業(yè)用戶也在這方面投資了很多，比如基礎(chǔ)架構(gòu)還有工作流等方面?，F(xiàn)在又有了新的趨勢，那就是云原生和微服務(wù)，很多企業(yè)用戶都在快速進入這個領(lǐng)域?，F(xiàn)在他們面臨的最大問題是怎樣把現(xiàn)有的 OpenStack架構(gòu)遷移到云原生平臺上。

簡單來說，OpenStack上VM工作負載，有的需要花很多時間或者是資源才能重構(gòu)成容器化微服務(wù)，有的甚至是不可能的，比如那種傳統(tǒng)大型單體應(yīng)用的架構(gòu)就很難改變。目前來看，OpenStack在很多的企業(yè)客戶里面還會繼續(xù)使用，最起碼在我們看得到的未來4~5年還會有持續(xù)的需求。但不可否認的是云原生是一個無法逆轉(zhuǎn)的大趨勢，怎樣使得客戶在保持以前的 OpenStack投資的同時，能夠發(fā)掘云原生的紅利，是目前很多企業(yè)都要解決的問題。

目前來看，絕大部分企業(yè)的做法都是用OpenStack來做云資源的管理，然后在上面部署K8s 去管理應(yīng)用容器。這種做法實際上有一定的局限性。這個是這種方案的架構(gòu)示意。剛才說到在這個方案里面，OpenStack作為底座，那么K8s是部署在 OpenStack上面，大家看到的橙色是K8s的集群，用K8s管理容器，黃顏色的容器都是工作負載。

這個方案的問題是，很多工作負載是在 VM里面由 OpenStack來管理，所以要讓這些VM和 容器能夠一起工作，就需要解決一些問題。一個就是網(wǎng)絡(luò)要有雙倍或者3倍的 overlay，這些問題還可以解決，比如說我們可以用Kuryr 連接到Neutron，用VLAN/trunk的形式，這樣可以減少一些 overlay，但這種方案OpenStack還是作為整個架構(gòu)的基礎(chǔ)，這樣以后往云原生發(fā)展會有非常大的局限性，因為OpenStack日積月累就尾大不掉了。

我們提出了一個新的方案，這個方案就是把現(xiàn)有的 OpenStack的集群，把它做lift & shift，不用大規(guī)模改動，就lift & shift到K8s上去，使得客戶的基礎(chǔ)設(shè)施能夠更好的發(fā)展。

這個方案，使得目前有很多投資在 OpenStack上面的用戶，可以繼續(xù)沿用以前OpenStack的東西，同時又可以把新的云原生的K8s和容器用上，也不需要做很大的變化，比如說各種配置，所以這是一個優(yōu)勢。

這個方案采用了基于OVN/OVS統(tǒng)一的SDN（軟件定義網(wǎng)絡(luò)）技術(shù)，實現(xiàn)OpenStack和K8s同時工作，而且能夠做service遷移。和其他方案比，這個方案還有一個好處，對于邊緣計算端資源比較受限、工作負載也沒那么大的場景，可以實現(xiàn)在同一個node上同時支持VM和容器。這種方案的靈活性，使得你可以根據(jù)自己的需求將VM和容器部署在不同的節(jié)點上或者是同一個節(jié)點，或者是比較少量或者很大量的節(jié)點上。K8s可以統(tǒng)一的、實時的來定義、連接或者斷開網(wǎng)絡(luò)，重新配置這些VM和容器的子網(wǎng)連接。

我這里舉個多租戶的例子，比如說同一個公司里面有不同的部門，他們可以是不同的租戶，不同的公司也可以用到多租戶的特性，那么這種網(wǎng)絡(luò)方案提供了租戶之間的隔離。

比如說這個租戶的工作負載是使用的這個VM，連接了 NW4的子網(wǎng)，我們可以配置NW4跟NW2相連，NW2是跟這兩個容器一起工作。

類似的第二個租戶，比如說這個容器，它是和NW3連接，我們可以把NW3配置和NW5相連接，那NW5是和這個VM的工作負載連接的，這一個租戶就能實現(xiàn)容器和VM的連接。

這兩個租戶之間他們是有邏輯類型的隔離的，也就是這個方案可以實現(xiàn)多用戶的隔離。

同時OpenStack的管理平臺網(wǎng)絡(luò)是獨立的,它是不和這些業(yè)務(wù)負載相連接的，可以和K8s的管理部署在另外的網(wǎng)絡(luò)上面，這樣就避免了它的控制平面和多租戶用戶平面的混雜，就保證了它的安全性，也保證了它的隔離度。

這個方案實際上對于我們以后的IPU（ interface with the internet processing unit）等擴展架構(gòu)是完全兼容的。我們還可以實現(xiàn)OVS dpdk來加速 OVS 網(wǎng)絡(luò)，使得它的數(shù)據(jù)平面能夠更快，性能更好。

這個就是它的大的架構(gòu)的示意圖。細化到具體網(wǎng)絡(luò)層面，目前是這樣做的，例子中右邊這個是OpenStack 的VM，左邊是以K8s來做管理的容器，他們都是用 OVN來組網(wǎng)。怎么把二者合并成同一個OVN？比如說這是一個在 OpenStack里面的router，我們稍微修改這個router的配置，然后用CRD把它導(dǎo)出到K8s里面，使得它能夠在K8s里面做統(tǒng)一的管理。這樣就是把在OpenStack和K8s里面的這兩個OVN統(tǒng)一起來。

這個就是網(wǎng)絡(luò)示意圖。在這個框架圖里面大家看到不同的node上，有的是vm，有的是容器Pod，它們都統(tǒng)一在一個OVN網(wǎng)絡(luò)里，由北向控制平面來管理，也就是OpenStack上的OVN和K8s上的OVN兩個是統(tǒng)一的。

Intel目前和靈雀云合作融合OpenStack與K8s，采用了靈雀云Kube-OVN技術(shù)，這個方案提供了一個非常平滑的過渡，使得現(xiàn)在的OpenStack企業(yè)用戶能夠很好的過渡到 K8s上去，同時避免了比較大的遷移工程。這實際上是一個lift & shift的工作，同時也是統(tǒng)一的SDN方案，其好處就是能夠做統(tǒng)一的部署，使得OpenStack和K8s能夠同時部署和運行，并能夠做服務(wù)關(guān)聯(lián)。此外，可以發(fā)揮intel的一些優(yōu)勢，提高方案的性能。

方案的另外一個優(yōu)點是很靈活的方式，同時它也是面向未來的架構(gòu)，比如說smart dpu、ipu這些未來都可以。

Kube-OVN方案融合OpenStack與K8s（by 劉夢馨）

下面介紹一下如何通過Kube-OVN實現(xiàn)統(tǒng)一的架構(gòu)，把共用一個OVN的Kube-OVN和Neutron實現(xiàn)SDN網(wǎng)絡(luò)的打通。

在這套方案中，OVN作為唯一的數(shù)據(jù)中心，它有兩個控制平面，一個是Neutron，一個是Kube-OVN。所以我們要做的事情，就是要把這兩者的數(shù)據(jù)結(jié)構(gòu)打通，也就是我們?nèi)绾卧贙8s的一側(cè)來識別出Neutron創(chuàng)建的VPC。

我們的做法是在Kube-OVN里面實現(xiàn)一個控制器，定期的去OVN里面掃描，看哪些是Kube-OVN創(chuàng)建的vpc，哪些是Neutron創(chuàng)建的vpc。

我們通過實例來演示。比如我們在OpenStack里面創(chuàng)建了一個router，然后通過OpenStack的命令行，就可以看到這個 router已經(jīng)創(chuàng)建了。但這個時候 router只存在于OVN里面，并沒有同步到Kube-OVN的CRD里面。

我們的Kube-OVN里面的控制器會不斷的去掃描 OVN的數(shù)據(jù)庫，當(dāng)他發(fā)現(xiàn)在OVN里面有這樣的一個router的時候，就會向K8s反寫一個vpc的CR。這樣，通過定期的掃描，我們就可以把Neutron的 vpc數(shù)據(jù)同步到K8s里面。這時我們在K8s里面就會看到如下的一個CR，它顯示 vpc的類型是一個外部的類型，它的name是Neutron后面連接一個ID，也就是在Neutron里面的一串ID號。至此，我們就可以在K8s側(cè)通過kubectl get crd cmd來拿到這個VPC信息了。

當(dāng)有了 VPC的CR之后，我們就可以在K8s一側(cè)來創(chuàng)建子網(wǎng)。這個子網(wǎng)我們可以選擇關(guān)聯(lián)到一個由OpenStack創(chuàng)建的 vpc，就像上面這個示例yaml所寫的，我們創(chuàng)建一個subnet，名字叫net2。然后這里的vbc，我們不是使用的Kube-OVN自己創(chuàng)建的vpc，而是引用一個從Neutron導(dǎo)入的 vpc，這樣的話我們就可以在Kube-OVN的控制側(cè)，把這個 subnet和Neutron那一側(cè)創(chuàng)建的一個router連接起來。

然后，下面其實就是Kube-OVN常規(guī)的一些操作，比如說我把這個subnet跟一個namespace關(guān)聯(lián)，這個namespace是net2，再去設(shè)置 subnet的一些cidr還有它的一些觸網(wǎng)的策略。

這時候，我們其實就可以創(chuàng)建Pod了。在創(chuàng)建 Pod的時候，我們可以在namespace側(cè)選擇net2，這樣的話由于 net2關(guān)聯(lián)的是 subnet的net2這樣的一個子網(wǎng)，新創(chuàng)建的pod就會落在這個子網(wǎng)上。由于這個子網(wǎng)又和Neutron 側(cè)創(chuàng)建的 VPC相連，也就等同于我們把這個pod運行在了Neutron一側(cè)的 VPC網(wǎng)絡(luò)上。

最后，大家可以看到，通過上面的一些操作之后，我們在OVN這一側(cè)看到的數(shù)據(jù)結(jié)構(gòu)的情況。

我們通過OVN的nbctl的命令，來觀察OVN側(cè)的一些數(shù)據(jù)結(jié)構(gòu)。大家可以看到最上面的 switch是Neutron創(chuàng)建的一個subnet，然后下面這個net2其實就是我們通過Kube-OVN創(chuàng)建的一個subnet。在這個subnet里面，我們創(chuàng)建了一個Ubuntu的port，然后給它分配了對應(yīng)的MAC和IP地址。然后再看這一個router的port這個端口，這個端口其實是將我們在Kube-OVN這一側(cè)，也就是K8s這一側(cè)，創(chuàng)建的一個子網(wǎng)router，進行了一個連接。

這時候我們其實就實現(xiàn)了在K8s這一側(cè)的一個subnet和在Neutron 這一側(cè)創(chuàng)建的一個vpc通過邏輯交換機的方式進行了一個互聯(lián)。最終實現(xiàn)的效果就是，如果你在 openstack一側(cè)對應(yīng)的這個子網(wǎng)里面創(chuàng)建vm，它會在這里面創(chuàng)建邏輯端口。而你在K8s創(chuàng)建的pod會在 net2的logic switch下創(chuàng)建pod，但是他們最終都會通過router進行互聯(lián)。也就是說，他們最終是統(tǒng)一到同一個 Neutron 側(cè)的vpc下網(wǎng)絡(luò)中，這里面的pod和vm的網(wǎng)絡(luò)就可以達到互通了。

上一篇：第2期容器網(wǎng)絡(luò)方案調(diào)研：Kube-OVN 邁向主流

下一篇：Kube-OVN V1.8: Underlay 多網(wǎng)卡強化，延遲大幅優(yōu)化，VPC 功能完善以及更多新功能