當(dāng)前位置：首頁(yè) > 编程资源 > 编程问答 >内容正文

编程问答

基于Neutron的Kubernetes SDN实践经验之谈

發(fā)布時(shí)間：2025/3/15 编程问答 35 豆豆

生活随笔收集整理的這篇文章主要介紹了基于Neutron的Kubernetes SDN实践经验之谈小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

首先，向大家科普下Kubernetes所選擇的CNI網(wǎng)絡(luò)接口，簡(jiǎn)單介紹下網(wǎng)絡(luò)實(shí)現(xiàn)的背景。

CNI即Container Network Interface，是一套容器網(wǎng)絡(luò)的定義規(guī)范，包括方法規(guī)范、參數(shù)規(guī)范、響應(yīng)規(guī)范等等。CNI只要求在容器創(chuàng)建時(shí)為容器分配網(wǎng)絡(luò)資源、刪除容器時(shí)釋放網(wǎng)絡(luò)資源。CNI與調(diào)用者之間的整個(gè)交互過(guò)程如下圖所示：

CNI實(shí)現(xiàn)與外界的交互都通過(guò)進(jìn)程參數(shù)和環(huán)境變量傳遞，也只要求輸出結(jié)果符合CNI規(guī)范即可，與實(shí)現(xiàn)語(yǔ)言也沒(méi)什么特殊要求。比如Calico早期版本就使用Python實(shí)現(xiàn)了CNI規(guī)范，為Kubernetes提供了網(wǎng)絡(luò)實(shí)現(xiàn)。常見(jiàn)的環(huán)境變量設(shè)置如下：

CNI_COMMAND：調(diào)用指定CNI動(dòng)作，ADD表示增加網(wǎng)卡，DEL表示釋放網(wǎng)卡

?
CNI_CONTAINERID：容器ID

?
CNI_NETNS：容器網(wǎng)絡(luò)命名空間文件位置

?
CNI_ARGS：額外傳遞的參數(shù)

?
CNI_IFNAME：設(shè)置的容器網(wǎng)卡名稱(chēng)，如eth0

正因如此，CNI規(guī)范實(shí)現(xiàn)起來(lái)非常容易擴(kuò)展，除了CNI自帶的Bridge、Macvlan等基本實(shí)現(xiàn)以外，還有大量的第三方實(shí)現(xiàn)可供選擇，包括Calico、Romana、Flannel等常用實(shí)現(xiàn)。同時(shí)CNI支持多種容器運(yùn)行時(shí)，包括Docker、rkt、Mesos、Hyper等容器引擎都可以使用。這也是Kubernetes選擇使用CNI的一大重要原因。

相對(duì)的，Docker提出的CNM（Cotainer Network Model）模型實(shí)現(xiàn)就比較復(fù)雜，但更為完善，比較接近傳統(tǒng)的網(wǎng)絡(luò)概念。如下圖所示：

Sandbox就是容器的網(wǎng)絡(luò)命名空間，Endpoint為容器連接到網(wǎng)絡(luò)中的一張網(wǎng)卡，而網(wǎng)絡(luò)則是一組相互通信的Endpoint的集合，比較接近Neutron中的網(wǎng)絡(luò)定義。

在CNM中，docker engine通過(guò)HTTP REST API調(diào)用網(wǎng)絡(luò)實(shí)現(xiàn)，為容器配置網(wǎng)絡(luò)。這些API接口涵蓋網(wǎng)絡(luò)管理、容器管理、創(chuàng)建endpoint等十幾個(gè)接口。同時(shí)CNM模型還隱含在docker自身附帶的service機(jī)制、dns機(jī)制等附加約束，因此可以在一定程度上說(shuō)，CNM模型只是專(zhuān)為docker容器實(shí)現(xiàn)的，對(duì)別的容器運(yùn)行時(shí)并不友好。

由于上面這些技術(shù)上的原因以及一些商業(yè)上的原因，Kubernetes最終選擇了CNI作為自己的網(wǎng)絡(luò)接口。

當(dāng)然，Kubernetes也提供一些取巧的方法，將CNI接口轉(zhuǎn)化為對(duì)CNM模型的調(diào)用，從而實(shí)現(xiàn)兩種模型的通用。例如to_docker，這個(gè)腳本就將Kubernetes對(duì)CNI的調(diào)用轉(zhuǎn)換為Docker CNM網(wǎng)絡(luò)的對(duì)應(yīng)操作，從而實(shí)現(xiàn)CNI到CNM的轉(zhuǎn)換。

接下來(lái)，給大家介紹下Kubernetes中網(wǎng)絡(luò)概念和通信原理。

在Kubernetes的網(wǎng)絡(luò)模型中，約定了三個(gè)基本約束：

所有容器之間都可以無(wú)須SNAT即可相互直接以IP通信。

所有主機(jī)與容器之間都可以無(wú)須SNAT即可相互直接以IP通信。

容器看到的自身IP與其他容器看到的容器IP相同。

在滿足約束的基礎(chǔ)上，Kubernetes不關(guān)心具體的網(wǎng)絡(luò)通信原理，只以三個(gè)約束為既定事實(shí)，在此基礎(chǔ)上，根據(jù)Kubernetes自身邏輯處理網(wǎng)絡(luò)通信，從而避免Kubernetes功能糾結(jié)在紛繁復(fù)雜的網(wǎng)絡(luò)實(shí)現(xiàn)中。

而在網(wǎng)絡(luò)概念上，Kubernetes中有兩種核心IP：

POD IP：有CNI實(shí)現(xiàn)提供，Kubernetes不管這個(gè)IP是否可達(dá)，只負(fù)責(zé)使用這個(gè)IP實(shí)現(xiàn)配置iptables、做健康檢查等功能。默認(rèn)情況下，這個(gè)IP在Kubernetes集群范圍內(nèi)都是可達(dá)的，并且可以進(jìn)行ping等操作。

?
cluster IP：即服務(wù)IP，這個(gè)IP在Kubernetes中只是用于實(shí)現(xiàn)服務(wù)交互通信，本質(zhì)上只是iptables上的幾條DNAT規(guī)則。默認(rèn)情況下，這個(gè)IP上只能提供服務(wù)端口的訪問(wèn)，且不可ping。

以集群的DNS服務(wù)為例，相關(guān)的核心iptables如下圖所示：

這些iptables都是由kube-proxy生成的，而且kube-proxy并不實(shí)際負(fù)責(zé)進(jìn)行轉(zhuǎn)發(fā)，因此即使kube-proxy服務(wù)異常，已經(jīng)產(chǎn)生的iptables依然可以使流量能夠正確的在服務(wù)IP和POD IP之間流轉(zhuǎn)。其網(wǎng)絡(luò)流量路徑可以參考下圖：

當(dāng)訪問(wèn)DNS服務(wù)的端口10.254.0.3時(shí)，kube-proxy生成的iptables DNAT規(guī)則，將流量轉(zhuǎn)發(fā)到后端POD IP及對(duì)應(yīng)端口上，將流量按后端POD的IP個(gè)數(shù)實(shí)行隨機(jī)均等分配。

而kube-proxy可以從kube-apiserver獲取服務(wù)和POD的狀態(tài)更新，隨時(shí)根據(jù)其狀態(tài)更新iptables，從而實(shí)現(xiàn)服務(wù)的高可用與動(dòng)態(tài)擴(kuò)展。

在基礎(chǔ)的IP通信機(jī)制上，Kubernetes還通過(guò)Network Policy和Ingress提高網(wǎng)絡(luò)安全性和響應(yīng)性能。

Network Policy提供了網(wǎng)絡(luò)隔離能力，它基于SIG－Network group演進(jìn)而來(lái)，Kubernetes只提供內(nèi)置的labelSelector和label以及Network Policy API定義，本身并不負(fù)責(zé)實(shí)現(xiàn)如何隔離。在Kubernetes使用的CNI網(wǎng)絡(luò)實(shí)現(xiàn)中，目前只有Calico、Romana、Contiv等少少幾個(gè)實(shí)現(xiàn)了Network Policy集成。一個(gè)典型的Network Policy定義如下所示：

apiVersion: extensions/v1beta1

kind: NetworkPolicy

metadata:

namespace: default

spec:

podSelector:

matchLabels:

role: db

ingress:

- from:

- podSelector:

? ?matchLabels:

? ? role: frontend

ports:

- protocol: tcp

? port: 6379

它指定約束，具有role:db標(biāo)簽的POD只能被具有role:frontend標(biāo)簽的POD訪問(wèn)，除此之外拒絕所有流量。從功能上來(lái)講，Network Policy可以等價(jià)于Neutron的安全組。

Ingress是負(fù)責(zé)對(duì)外提供服務(wù)的，通過(guò)Nginx對(duì)外提供一個(gè)單獨(dú)接口，實(shí)現(xiàn)集群中的所有服務(wù)的對(duì)外提供，從而取代使用NodePort暴露每個(gè)服務(wù)的現(xiàn)有實(shí)現(xiàn)。目前，Kubernetes的Ingress提供了Nginx和GCE兩種實(shí)現(xiàn)，感興趣的同學(xué)可以直接參考官文檔，https://github.com/kubernetes/ingress/tree/master/controllers。

Kubernetes社區(qū)中，比較常見(jiàn)的幾種網(wǎng)絡(luò)實(shí)現(xiàn)主要是以下兩種：

基于Overlay網(wǎng)絡(luò)：以Flannel、Weave為代表。Flannel是CoreOS為Kubernetes專(zhuān)門(mén)定制實(shí)現(xiàn)的Overlay網(wǎng)絡(luò)方案，也是Kubernetes默認(rèn)的網(wǎng)絡(luò)實(shí)現(xiàn)。它基于VXLAN或者UDP整個(gè)集群的Overlay網(wǎng)絡(luò)，從而實(shí)現(xiàn)容器在集群上的通信，滿足Kubernetes網(wǎng)絡(luò)模型的三大基本約束。由于在通信過(guò)程中存在數(shù)據(jù)包的封包解包等額外損耗，性能較差，但已經(jīng)基本滿足使用。

以L3路由為基礎(chǔ)實(shí)現(xiàn)網(wǎng)絡(luò)：以Calico、Romana為代表。其中，Calico是廣泛流傳的性能最好的Kubernetes網(wǎng)絡(luò)實(shí)現(xiàn)，基于純?nèi)龑拥穆酚蓪?shí)現(xiàn)網(wǎng)絡(luò)通信，結(jié)合iptables實(shí)現(xiàn)的安全控制，可以滿足大多數(shù)云的性能需求。但是由于它要求主機(jī)上必須打開(kāi)BGP形成路由拓?fù)?#xff0c;在一些數(shù)據(jù)中心上可能不會(huì)被允許。同時(shí)，Calico還比較早地支持了Network Policy，并且可以將Calico自身的數(shù)據(jù)直接托管在Kubernetes中，從而實(shí)現(xiàn)與Kubernetes的深度集成。

從上面這些網(wǎng)絡(luò)實(shí)現(xiàn)來(lái)看，目前Kubernetes的網(wǎng)絡(luò)實(shí)現(xiàn)都還談不上是比較成熟的SDN，因此我們公司在考察Kubernetes后，決定基于Neutron，為Kubernetes提供一個(gè)可用的SDN實(shí)現(xiàn)，這就是Skynet項(xiàng)目的由來(lái)。

下面我來(lái)跟大家分享下，Skynet在實(shí)踐過(guò)程中的一些經(jīng)驗(yàn)。

在實(shí)踐中，首先要解決的就是Kubernetes中的網(wǎng)絡(luò)概念，怎么翻譯到Neutron中，才能比較合適地實(shí)現(xiàn)功能。

在第一個(gè)版本中，Kubernetes網(wǎng)絡(luò)中概念翻譯對(duì)應(yīng)如下表所示：

POD ----> 虛擬機(jī)

?
Service -------> loadbalancer

?
Endpoints -------> pool

?
Service后端POD ----> member

但是，由于Kubernetes中支持同一服務(wù)上設(shè)置多個(gè)服務(wù)端口，而Neutron的每個(gè)Load Balancer僅支持一個(gè)對(duì)外端口。好在，去年OpenStack的Mitaka版本后，Neutron LBaaS V2正式發(fā)布，因此有了第二個(gè)版本的概念翻譯。

POD ----> 虛擬機(jī)

?
Service -----> lbaasv2 loadbalancer

?
Service port ----->lbaasv2 listener

?
Endpoints -----> lbaasv2 pool

?
Service后端POD ------>lbaasv2 member

?
POD livenessProbe ----->health monitor

LBaaS V2的基本術(shù)語(yǔ)圖解如下所示：

Load Balancer：負(fù)載均衡器，對(duì)應(yīng)一個(gè)HAProxy進(jìn)程，占據(jù)一個(gè)子網(wǎng)IP?？梢赃壿嬌嫌成錇镵ubernetes中的Service。

?
Listener：監(jiān)聽(tīng)器，表示負(fù)載均衡器本身提供的一個(gè)前端監(jiān)聽(tīng)端口。對(duì)應(yīng)service定義中的ports中port。

?
pool：監(jiān)聽(tīng)器后端的成員集合記錄。

?
member：監(jiān)聽(tīng)器后端的成員。對(duì)應(yīng)service使用的Endpoints的addresses列表，每個(gè)地址可以對(duì)應(yīng)service聲明中的targetPort的映射。

?
health monitor：pool中的成員健康檢查器，類(lèi)似Kubernetes中的livenessProbe，目前不映射。

就資源數(shù)量的映射來(lái)說(shuō)：Kubernetes的一個(gè)service，對(duì)應(yīng)一個(gè)Load Balancer。service中的每個(gè)port對(duì)應(yīng)監(jiān)聽(tīng)這個(gè)Load Balancer的一個(gè)Listener。每個(gè)Listener后端都對(duì)接一個(gè)pool包含其后端資源。而Kubernetes中的每個(gè)Service都有一個(gè)對(duì)應(yīng)的Endpoints來(lái)包含其后端POD。Endpoints中的每個(gè)IP+Service聲明port的targetPort就對(duì)應(yīng)pool中的一個(gè)member。

初步完成了概念的映射后，我們簡(jiǎn)單介紹下開(kāi)發(fā)中的思路。

在整體結(jié)構(gòu)上，Skynet居于Kubernetes和Neutron之間，實(shí)現(xiàn)了CNI規(guī)范，基于Neutron為容器配置網(wǎng)絡(luò)。service-watcher負(fù)責(zé)監(jiān)聽(tīng)Kubernetes的資源，對(duì)服務(wù)等概念翻譯為Neutron實(shí)現(xiàn)，從而實(shí)現(xiàn)完整的網(wǎng)絡(luò)功能。如下所示：

kubelet是創(chuàng)建POD的直接操作者，在為POD設(shè)置網(wǎng)絡(luò)時(shí)，通過(guò)CNI接口規(guī)范，調(diào)用Skynet實(shí)現(xiàn)。Skynet通過(guò)調(diào)用Neutron為容器分配IP，并通過(guò)在POD容器網(wǎng)絡(luò)命令空間中操作，實(shí)現(xiàn)IP、路由等通信規(guī)則的設(shè)置。

而Neutron原生的DHCP、LBaaS v2等機(jī)制可以基本保持不變。從而實(shí)現(xiàn)完整的集成，可以使Kubernetes集群獲得完整的Neutron SDN功能。而當(dāng)容器內(nèi)需要進(jìn)行DNS時(shí)，則可以通過(guò)Neutron自帶的DHCP Agent負(fù)責(zé)實(shí)現(xiàn)解析，在集群網(wǎng)絡(luò)中正常工作。

如前文所述，Skynet實(shí)現(xiàn)了CNI規(guī)范，kubelet與Skynet之間的交互過(guò)程如下所示：

簡(jiǎn)要介紹下每個(gè)步驟：

kubelet通過(guò)CNI機(jī)制調(diào)用skynet，主要傳遞的參數(shù)如下：

CNI_COMMAND：調(diào)用指定CNI動(dòng)作，ADD表示增加網(wǎng)卡，DEL表示釋放網(wǎng)卡

?
CNI_CONTAINERID：容器ID

?
CNI_NETNS：容器網(wǎng)絡(luò)命名空間文件位置

?
CNI_ARGS：額外傳遞的參數(shù)

?
CNI_IFNAME：設(shè)置的容器網(wǎng)卡名稱(chēng)，如eth0

執(zhí)行ADD操作時(shí)，Skynet根據(jù)傳入的參數(shù)和POD的配置，通過(guò)neutron-server為POD創(chuàng)建port。

執(zhí)行ADD操作時(shí)，Skynet根據(jù)port和網(wǎng)絡(luò)配置，為容器創(chuàng)建網(wǎng)絡(luò)設(shè)備，并掛載到容器命名空間中。

neutron-linuxbridge-agent，根據(jù)容器的網(wǎng)絡(luò)和安全組規(guī)則生成iptables。從而利用Neutron原生的安全組功能，同時(shí)也可以直接利用Neutron的一整套SDN實(shí)現(xiàn)，包括vRouter、FWaaS、VPNaaS等服務(wù)。

service-watcher將Kubernetes服務(wù)映射為Neutron LBaaS v2實(shí)現(xiàn)后，以VLAN網(wǎng)絡(luò)為例，POD與服務(wù)之間的流量通信過(guò)程如下圖：

當(dāng)集群內(nèi)容器訪問(wèn)服務(wù)時(shí)，Kubernetes默認(rèn)都是通過(guò)服務(wù)名稱(chēng)訪問(wèn)，服務(wù)名通過(guò)Neutron的DHCP機(jī)制，可以由每個(gè)網(wǎng)絡(luò)的Dnsmasq進(jìn)程負(fù)責(zé)解析，獲得service對(duì)應(yīng)負(fù)載均衡的IP地址后，即可用于網(wǎng)絡(luò)通信，由物理交換機(jī)負(fù)責(zé)流量的中轉(zhuǎn)。

在實(shí)際實(shí)現(xiàn)中，以Kubernetes中一個(gè)服務(wù)的定義映射到Neutron的loadbalancer為例演示下。

例如對(duì)下面的service實(shí)現(xiàn)：

kind: Service

apiVersion: v1

metadata:

namespace: default

labels:

app: neutron-service

annotations:

skynet/subnet_id: a980172e-638d-474a-89a2-52b967803d6c

spec:

ports:

- name: port1

protocol: TCP

port: 8888

targetPort: 8000

- name: port2

protocol: TCP

port: 9999

targetPort: 9000

selector:

app: neutron-service

type: NodePort

kind: Endpoints

apiVersion: v1

metadata:

namespace: default

labels:

app: neutron-service

subsets:

- addresses:

- ip: 192.168.119.187

targetRef:

?kind: Pod

?namespace: default

?name: neutron-service-puds0

?uid: eede8e24-85f5-11e6-ab34-000c29fad731

?resourceVersion: '2381789'

- ip: 192.168.119.188

targetRef:

?kind: Pod

?namespace: default

?name: neutron-service-u9nnw

?uid: eede9b70-85f5-11e6-ab34-000c29fad731

?resourceVersion: '2381787'

ports:

- name: port1

port: 8000

protocol: TCP

- name: port2

port: 9000

protocol: TCP

POD和Service通過(guò)特定注解來(lái)指定使用的Neutron網(wǎng)絡(luò)、IP等配置，與Kubernetes盡量解耦。

上面的Service映射成Load Balancer后，其定義如下所示：

{

"statuses": {

"loadbalancer": {

?"name": "neutron-service",

?"provisioning_status": "ACTIVE",

?"listeners": [

? ?{

? ? ?"name": "neutron-service-8888",

? ? ?"provisioning_status": "ACTIVE",

? ? ?"pools": [

? ? ? ?{

? ? ? ? ?"name": "neutron-service-8888",

? ? ? ? ?"provisioning_status": "ACTIVE",

? ? ? ? ?"healthmonitor": {},

? ? ? ? ?"members": [

? ? ? ? ? ?{

? ? ? ? ? ? ?"name": "",

? ? ? ? ? ? ?"provisioning_status": "ACTIVE",

? ? ? ? ? ? ?"address": "192.168.119.188",

? ? ? ? ? ? ?"protocol_port": 8000,

? ? ? ? ? ? ?"id": "461a0856-5c97-417e-94b4-c3486d8e2160",

? ? ? ? ? ? ?"operating_status": "ONLINE"

? ? ? ? ? ?},

? ? ? ? ? ?{

? ? ? ? ? ? ?"name": "",

? ? ? ? ? ? ?"provisioning_status": "ACTIVE",

? ? ? ? ? ? ?"address": "192.168.119.187",

? ? ? ? ? ? ?"protocol_port": 8000,

? ? ? ? ? ? ?"id": "1d1b3da6-b1a1-485b-a25a-243e904fcedb",

? ? ? ? ? ? ?"operating_status": "ONLINE"

? ? ? ? ? ?}

? ? ? ? ?],

? ? ? ? ?"id": "95f42465-0cab-477e-a7de-008621235d52",

? ? ? ? ?"operating_status": "ONLINE"

? ? ? ?}

? ? ?],

? ? ?"l7policies": [],

? ? ?"id": "6cf0c3dd-3aec-4b35-b2a5-3c0a314834e8",

? ? ?"operating_status": "ONLINE"

? ?},

? ?{

? ? ?"name": "neutron-service-9999",

? ? ?"provisioning_status": "ACTIVE",

? ? ?"pools": [

? ? ? ?{

? ? ? ? ?"name": "neutron-service-9999",

? ? ? ? ?"provisioning_status": "ACTIVE",

? ? ? ? ?"healthmonitor": {},

? ? ? ? ?"members": [

? ? ? ? ? ?{

? ? ? ? ? ? ?"name": "",

? ? ? ? ? ? ?"provisioning_status": "ACTIVE",

? ? ? ? ? ? ?"address": "192.168.119.188",

? ? ? ? ? ? ?"protocol_port": 9000,

? ? ? ? ? ? ?"id": "2faa9f42-2734-416a-a6b2-ed922d01ca50",

? ? ? ? ? ? ?"operating_status": "ONLINE"

? ? ? ? ? ?},

? ? ? ? ? ?{

? ? ? ? ? ? ?"name": "",

? ? ? ? ? ? ?"provisioning_status": "ACTIVE",

? ? ? ? ? ? ?"address": "192.168.119.187",

? ? ? ? ? ? ?"protocol_port": 9000,

? ? ? ? ? ? ?"id": "81f777b1-d999-48b0-be79-6dbdedca5e97",

? ? ? ? ? ? ?"operating_status": "ONLINE"

? ? ? ? ? ?}

? ? ? ? ?],

? ? ? ? ?"id": "476952ac-64a8-4594-8972-699e87ae5b9b",

? ? ? ? ?"operating_status": "ONLINE"

? ? ? ?}

? ? ?],

? ? ?"l7policies": [],

? ? ?"id": "c6506b43-2453-4f04-ba87-f5ba4ee19b17",

? ? ?"operating_status": "ONLINE"

? ?}

?],

?"pools": [

? ?{

? ? ?"name": "neutron-service-8888",

? ? ?"provisioning_status": "ACTIVE",

? ? ?"healthmonitor": {},

? ? ?"members": [

? ? ? ?{

? ? ? ? ?"name": "",

? ? ? ? ?"provisioning_status": "ACTIVE",

? ? ? ? ?"address": "192.168.119.188",

? ? ? ? ?"protocol_port": 8000,

? ? ? ? ?"id": "461a0856-5c97-417e-94b4-c3486d8e2160",

? ? ? ? ?"operating_status": "ONLINE"

? ? ? ?},

? ? ? ?{

? ? ? ? ?"name": "",

? ? ? ? ?"provisioning_status": "ACTIVE",

? ? ? ? ?"address": "192.168.119.187",

? ? ? ? ?"protocol_port": 8000,

? ? ? ? ?"id": "1d1b3da6-b1a1-485b-a25a-243e904fcedb",

? ? ? ? ?"operating_status": "ONLINE"

? ? ? ?}

? ? ?],

? ? ?"id": "95f42465-0cab-477e-a7de-008621235d52",

? ? ?"operating_status": "ONLINE"

? ?},

? ?{

? ? ?"name": "neutron-service-9999",

? ? ?"provisioning_status": "ACTIVE",

? ? ?"healthmonitor": {},

? ? ?"members": [

? ? ? ?{

? ? ? ? ?"name": "",

? ? ? ? ?"provisioning_status": "ACTIVE",

? ? ? ? ?"address": "192.168.119.188",

? ? ? ? ?"protocol_port": 9000,

? ? ? ? ?"id": "2faa9f42-2734-416a-a6b2-ed922d01ca50",

? ? ? ? ?"operating_status": "ONLINE"

? ? ? ?},

? ? ? ?{

? ? ? ? ?"name": "",

? ? ? ? ?"provisioning_status": "ACTIVE",

? ? ? ? ?"address": "192.168.119.187",

? ? ? ? ?"protocol_port": 9000,

? ? ? ? ?"id": "81f777b1-d999-48b0-be79-6dbdedca5e97",

? ? ? ? ?"operating_status": "ONLINE"

? ? ? ?}

? ? ?],

? ? ?"id": "476952ac-64a8-4594-8972-699e87ae5b9b",

? ? ?"operating_status": "ONLINE"

? ?}

?],

?"id": "31b61658-4708-4a48-a3c4-0d61a127cd09",

?"operating_status": "ONLINE"

}

其對(duì)應(yīng)的HAProxy進(jìn)程配置如下所示：

# Configuration for neutron-service

global

daemon

user nobody

group nogroup

log /dev/log local0

log /dev/log local1 notice

stats socket /var/lib/neutron/lbaas/v2/31b61658-4708-4a48-a3c4-0d61a127cd09/haproxy_stats.sock mode 0666 level user

defaults

log global

retries 3

option redispatch

timeout connect 5000

timeout client 50000

timeout server 50000

frontend 6cf0c3dd-3aec-4b35-b2a5-3c0a314834e8

option tcplog

bind 192.168.119.178:8888

mode tcp

default_backend 95f42465-0cab-477e-a7de-008621235d52

frontend c6506b43-2453-4f04-ba87-f5ba4ee19b17

option tcplog

bind 192.168.119.178:9999

mode tcp

default_backend 476952ac-64a8-4594-8972-699e87ae5b9b

backend 476952ac-64a8-4594-8972-699e87ae5b9b

mode tcp

balance roundrobin

server 81f777b1-d999-48b0-be79-6dbdedca5e97 192.168.119.187:9000 weight 1

server 2faa9f42-2734-416a-a6b2-ed922d01ca50 192.168.119.188:9000 weight 1

backend 95f42465-0cab-477e-a7de-008621235d52

mode tcp

balance roundrobin

server 1d1b3da6-b1a1-485b-a25a-243e904fcedb 192.168.119.187:8000 weight 1

server 461a0856-5c97-417e-94b4-c3486d8e2160 192.168.119.188:8000 weight 1

綜上所述，通過(guò)基于Neutron的Skynet，我們?yōu)镵ubernetes初步實(shí)現(xiàn)了SDN的功能，同時(shí)提供了如下網(wǎng)絡(luò)功能增強(qiáng)：

POD的IP、Mac、主機(jī)名等網(wǎng)絡(luò)配置的保持；

基于Neutron安全組，實(shí)現(xiàn)了POD之間的網(wǎng)絡(luò)隔離功能，更加通用；

支持通過(guò)HAProxy直接對(duì)外提供服務(wù)，性能上會(huì)比原生的iptables好很多。

當(dāng)然，目前有一些Kubernetes特性在Skynet網(wǎng)絡(luò)方案中還不支持，需要在后面進(jìn)行增強(qiáng)或?qū)崿F(xiàn)：

Headless services這一類(lèi)沒(méi)有集群IP的Service無(wú)法處理。

由于neutron-server與neutron-plugin之間的消息都是通過(guò)RabbitMQ進(jìn)行，不是特別適合容器環(huán)境下網(wǎng)絡(luò)快速變更的現(xiàn)狀，會(huì)是整個(gè)方案的一大瓶頸。

轉(zhuǎn)載于:https://www.cnblogs.com/nongchaoer/p/6792756.html

總結(jié)

以上是生活随笔為你收集整理的基于Neutron的Kubernetes SDN实践经验之谈的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。