全黄一级裸片视频在线观看_日本三级欧美视频_黄色小说在线看_亚洲熟女另类av_欧美丝美脚交footjob_成人午夜精品无码区不卡_亚洲国产精品懂色_日本麻豆一一在线观看黄色网

8 月 26 日，「Kube-OVN 社區第二期線上 Meetup」成功舉辦。本次活動由項目發起人劉夢馨主講，他分享了當前Kube-OVN 項目及社區的發展情況，同時帶來了Kube-OVN 1.8版本的特性預覽及未來功能規劃，吸引了眾多用戶一起交流討論。

Kube-OVN 項目及社區成果

Kube-OVN 項目的代碼通過 Apache2.0 的方式進行開源，社區提供的所有功能，包括代碼、文檔、故障報告和運維手冊，都在 Github 上開源。

 Kube-OVN 在發展過程中得到了很多企業和個人用戶的支持，用戶分別來自于天翼云、金山、華為、銳捷、浪潮、字節跳動、Intel 等公司。在社區用戶的支持下， Kube-OVN 項目到目前為止已經收到大約 1780 個 commit，在這兩年多進行了 31 次發版，有 43 位貢獻者為項目貢獻了代碼、文檔，在 Dockerhub 上的鏡像數據，主鏡像有約160 萬次的拉取。

Kube-OVN1.8 新特性  

Kube-OVN 1.8 新版本的功能從 『Underlay 網絡強化』、『網絡延遲優化』、『Kubernetes和 OpenStack 互聯互通』、『VPC 能力進一步完善』這些調整方向來介紹。

『Underlay 網絡強化』

隨著 Underlay 的用戶越來越多，需求也會變得越來越復雜。在1.7發版之后，社區交流群里提出了非常多關于 Underlay 的問題，比如：

● 宿主機只有單網卡可不可以？

● 多個網卡對應多個 Vlan可不可以？

● 網卡配錯了只能刪了重搭嗎？

● 網卡名不一致可不可以？

● 容器內多個網卡在不同的 Vlan可不可以？

● 部分 Vlan只在部分主機的部分網卡存在可不可以？

● 組播能不能支持？

● Overlay 和 Underlay 混部行不行？

三個月以來，1.7版本在社區的反饋中一步步迭代，上述所有問題已經全部得到解決，并且經過了很多次 poc 和 社區用戶的打磨，在生產環境中得到了驗證。可以說 Underlay 的網絡能力比上個版本強化了很多。

更新功能：

?ProviderNetwork 定義主機、網卡、底層網絡三者映射關系

?動態按需調整網絡映射

?Vlan 和 ProviderNetwork 關聯

?無 Vlan 關聯 Subnet自動為 Overlay網絡

『網絡延遲優化』

"你們用了OVS 性能會不會有影響呀" ，"你們和Calico的性能相比怎么樣"，"為什么我這邊性能壓不上去呢？""看了其他人的性能測評你們的性能好像很差呀" ......這些來自用戶的靈魂拷問在1.8 版本統統都有解答。并且在這個周期內對小包的延遲做了深入的性能分析和性能優化。

優化方向：

?選取特定物理環境做基準測試

?開發自動化性能測試工具進行頻繁測試優化

?生成火焰圖進行瓶頸分析

?fastpath 內核模塊，OVS 編譯優化，OVN LB 流表裁剪

經過優化之后，在當前的測試環境下，TCP和 UDP 的延遲相對于宿主機的延遲能控制在 5% 左右，UDP 的帶寬有比較大的提升，比之前提升了大概兩倍多，接近到百分之90%的主機帶寬水平。 關于Calico 性能的橫評，我們測試了五組數據：在 Kube-OVN overlay 對標 Calico 的 overlay ，Kube-OVN underly 對標 Calico 的不封裝的模式下，我們都會比 Calico要好一些。具體的性能優化的方案可以在 Github 上看到。之后有機會也可以專門分享一期我們究竟是如何把性能優化上去的。

『Kubernetes和 OpenStack 互聯互通』

?OVN-IC 方式實現OpenStack 內VPC 和Kubernetes 內VPC 對等連接

?Kubernetes 和 OpenStack 共享底層 OVN 基礎設施

?Kubernetes 內導入 OpenStack VPC，直接在 Kubernetes 內創建 OpenStack VPC 網絡下 Pod

在之前 1.7 版本周期用的是異構的模式打通網絡，讓 OpenStack 和 K8s 里面的工作負載可以相互進行訪問。而這次1.8 版本我們想更進一步，最終實現在 OpenStack 或者是 K8s 里面的一個 VPC 下，可以直接創建 Pod 和 VM 。這個功能正在和 Intel 團隊一塊來推進，并且在一些客戶的場景已經有了初步驗證。

『VPC 能力進一步完善』

?VPC 內Service 支持

?Security Group 支持

?VPC 內支持 L4 SLB

在1.8版本后用戶自定義的 VPC 會有 service 支持、 Security 的 Group 支持。4層負載均衡這條路基本上調通了，外部 LB 也可以在 VPC里面來做。當前的VPC內的功能包括子網、路由觸網的網關EIP、Floating IP，NAT dataway，然后再加上安全組，功能已經比較完整了。在下個周期 VPC 會做更多的完善，希望今年年底的時候，整個VPC多租戶網絡能夠比較完整的呈現。開源社區里面如果能把多租戶的這些功能引入到 K8s 里面來的話，可能對 K8s 之后在數據中心的落地都會有比較大的一個幫助。

『其他功能增強』

本次版本升級還有其他小功能的增強，比如Pod 粒度流量鏡像、Tunnel IP 動態調整、多網卡自定義路由等。

Kube-OVN 未來功能展望

Kube-OVN 未來功能主要從三個方向進行規劃：性能進一步增強、VPC能力下層、KubeVirt 虛擬化能力增強。

性能進一步增強主要通過優化數據平面和控制平面實現，希望把 Kube-OVN 的性能做得更好，減少用戶的擔心。

在VPC的層面上，根據兩種不同的場景支持Cluster CRD 和 Namespaced CRD，再加上南北向的QoS，接著實現VPC對等連接，然后考慮引進L4 LoadBalancer和L7 LoadBalancer（因為7層的功能比較豐富）。

KubeVirt 虛擬化能力增強主要是希望做一套完整的方案來使 KubeVirt 固定 IP 熱遷移，還包括網絡直通，避免多次復制性能消耗，以及智能網卡直通、DPDK 網卡直通等一些規劃的介紹。希望越來越多的用戶能參與到項目的規劃過程中。

QA 匯總

1、 Kube-OVN 網絡插件性能怎么樣？

在剛才的分享中已經基本回答了，后續我們計劃做一個完整的、面向幾個主流容器網絡方案的橫評，把測評工具、測試方案和數據全部開放出來，請大家拭目以待。

2、 Kube-OVN 后續考慮支持關于 VPC 之間軟路由互聯么？或者分享下當前的實現方案？

我不太清楚軟路由具體是什么樣的方式，互聯的話我們目前在做的是跨集群互聯。就是有兩個 K8s 集群，都跑在 Kube-OVN，但是他們可能是部署在不同的環境里，那么基于我們的一些集群互聯的方式，可以把兩個集群的網絡拉平，然后只要每個集群內各有一個節點，這個節點之間相互是可以跟對端進行互通的，就可以打造兩個集群之間的隧道，實現兩個集群之間的直接互通。

3、 目前對 network policy 能完全支持嗎？

我們現在能做到對容器網絡的 network policy 完全支持，但是因為用戶有一部分容器可能會跑在主機網絡上，因為主機網絡的流量不過 OVS，所以對主機網絡那部分目前還沒有很好的支持方法。

 4、OVS 本身的 lb 應該還不支持健康監測吧？有沒有針對四層 lb 的健康監測的設計？

我們目前在做的是 K8s 層面的健康檢查，直接把 endpoint里面的后端信息直接加到 4 層 LB 上面。

5、OVN 層面獨立部署，從而多集群共享 vpc 這個有支持計劃嗎？

我們在跟 OpenStack 互聯的方案里面目前是這么做的。你可以當成這個 OVN 是獨立部署的，然后 Kube-OVN 和 OpenStack 是共用的 OVN ，VPC 共享也是通過這個方式來做的。但是多個 K8s 共享一個vpc，目前還沒有這方面的計劃。

 6、后續會考慮實現基于 K8s 中的 ip 和 node 的信息進行流表重建的工具么？ 因為OpenStack neutron 這邊的 ovn 是有這樣的工具的，即使把 ovn 數據庫以及組件清空，也是可以基于一條命令重建流表的。

我們現在把所有的網絡信息往OVN 同步，同時往 K8s 的 annotation 上同步一份。所以就算把 Kube-OVN 都刪掉，我們還有恢復信息的能力。這個數據是都有的，這方面的工具還沒有研發，完整的驗證還沒有進行，這應該是下個周期內要做的工作。

7、面向多個云廠商，如何讓上面的 K8s 集群網絡互通？

這個問題有幾種做法，最好的做法其實是跟多個公有云之間買互通的線，讓他們幫你把網絡打通，這種理論上性能和可靠性都是最好的。如果公有云不愿意做這個事情的話，拿 Kube-OVN 也可以實現，你需要在每個公有云上各選幾個節點，這個節點相當于是做互聯的網關。這幾個節點之間，不管是通過公網 IP 的方式也好，或者是在這幾個機器之間打隧道的方式也好，跨集群互聯的功能就可以跑起來了。

8、對通過 service 訪問的流量能實現 networkpolicy 策略嗎？

通過 service 訪問的流量，如果是對Cluster IP做限制，我們現在應該也是支持的，因為我們這邊做完 nat 之后，你看到的目標其實是原目標的 IP，所以你即使通過 service 送到了那邊，但是你 Ingress 的時候，由于我看到的是你的原IP，我還是會按照對應的策略進行一個限制。如果更嚴格一點的話，你其實是應該把 Service IP 這樣的一些東西也寫到一個 network policy 里面，這樣可以做一個比較完整的限制。

9、metalLB 結合 ovs virtual ip 也可以做負載均衡，這個方案感覺怎么樣？

 metalLB 本身是一個還算比較清晰、比較直接的方式，我們也試過這個方案，覺得挺好的。

本屆Meetup圓滿結束，感謝大家對 Kube-OVN 的支持。歡迎更多朋友加入社區，我們共同把這個項目打造得更好。

活動回看

復制活動鏈接：https://qdrl.qq.com/yNkgduq1至瀏覽器打開，即可觀看活動視頻。

在 Kube-OVN 微信公眾號后臺回復“0826”，即可獲取演講PPT。

上一篇：千人圍觀，Kube-OVN社區周年慶

下一篇：數字化裝備制造新標桿！靈雀云攜手騰訊云打造三一集團技術中臺