當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

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

發布時間：2025/3/15 编程问答 49 豆豆

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

首先，向大家科普下Kubernetes所選擇的CNI網絡接口，簡單介紹下網絡實現的背景。

CNI即Container Network Interface，是一套容器網絡的定義規范，包括方法規范、參數規范、響應規范等等。CNI只要求在容器創建時為容器分配網絡資源、刪除容器時釋放網絡資源。CNI與調用者之間的整個交互過程如下圖所示：

CNI實現與外界的交互都通過進程參數和環境變量傳遞，也只要求輸出結果符合CNI規范即可，與實現語言也沒什么特殊要求。比如Calico早期版本就使用Python實現了CNI規范，為Kubernetes提供了網絡實現。常見的環境變量設置如下：

CNI_COMMAND：調用指定CNI動作，ADD表示增加網卡，DEL表示釋放網卡

?
CNI_CONTAINERID：容器ID

?
CNI_NETNS：容器網絡命名空間文件位置

?
CNI_ARGS：額外傳遞的參數

?
CNI_IFNAME：設置的容器網卡名稱，如eth0

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

相對的，Docker提出的CNM（Cotainer Network Model）模型實現就比較復雜，但更為完善，比較接近傳統的網絡概念。如下圖所示：

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

在CNM中，docker engine通過HTTP REST API調用網絡實現，為容器配置網絡。這些API接口涵蓋網絡管理、容器管理、創建endpoint等十幾個接口。同時CNM模型還隱含在docker自身附帶的service機制、dns機制等附加約束，因此可以在一定程度上說，CNM模型只是專為docker容器實現的，對別的容器運行時并不友好。

由于上面這些技術上的原因以及一些商業上的原因，Kubernetes最終選擇了CNI作為自己的網絡接口。

當然，Kubernetes也提供一些取巧的方法，將CNI接口轉化為對CNM模型的調用，從而實現兩種模型的通用。例如to_docker，這個腳本就將Kubernetes對CNI的調用轉換為Docker CNM網絡的對應操作，從而實現CNI到CNM的轉換。

接下來，給大家介紹下Kubernetes中網絡概念和通信原理。

在Kubernetes的網絡模型中，約定了三個基本約束：

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

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

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

在滿足約束的基礎上，Kubernetes不關心具體的網絡通信原理，只以三個約束為既定事實，在此基礎上，根據Kubernetes自身邏輯處理網絡通信，從而避免Kubernetes功能糾結在紛繁復雜的網絡實現中。

而在網絡概念上，Kubernetes中有兩種核心IP：

POD IP：有CNI實現提供，Kubernetes不管這個IP是否可達，只負責使用這個IP實現配置iptables、做健康檢查等功能。默認情況下，這個IP在Kubernetes集群范圍內都是可達的，并且可以進行ping等操作。

?
cluster IP：即服務IP，這個IP在Kubernetes中只是用于實現服務交互通信，本質上只是iptables上的幾條DNAT規則。默認情況下，這個IP上只能提供服務端口的訪問，且不可ping。

以集群的DNS服務為例，相關的核心iptables如下圖所示：

這些iptables都是由kube-proxy生成的，而且kube-proxy并不實際負責進行轉發，因此即使kube-proxy服務異常，已經產生的iptables依然可以使流量能夠正確的在服務IP和POD IP之間流轉。其網絡流量路徑可以參考下圖：

當訪問DNS服務的端口10.254.0.3時，kube-proxy生成的iptables DNAT規則，將流量轉發到后端POD IP及對應端口上，將流量按后端POD的IP個數實行隨機均等分配。

而kube-proxy可以從kube-apiserver獲取服務和POD的狀態更新，隨時根據其狀態更新iptables，從而實現服務的高可用與動態擴展。

在基礎的IP通信機制上，Kubernetes還通過Network Policy和Ingress提高網絡安全性和響應性能。

Network Policy提供了網絡隔離能力，它基于SIG－Network group演進而來，Kubernetes只提供內置的labelSelector和label以及Network Policy API定義，本身并不負責實現如何隔離。在Kubernetes使用的CNI網絡實現中，目前只有Calico、Romana、Contiv等少少幾個實現了Network Policy集成。一個典型的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標簽的POD只能被具有role:frontend標簽的POD訪問，除此之外拒絕所有流量。從功能上來講，Network Policy可以等價于Neutron的安全組。

Ingress是負責對外提供服務的，通過Nginx對外提供一個單獨接口，實現集群中的所有服務的對外提供，從而取代使用NodePort暴露每個服務的現有實現。目前，Kubernetes的Ingress提供了Nginx和GCE兩種實現，感興趣的同學可以直接參考官文檔，https://github.com/kubernetes/ingress/tree/master/controllers。

Kubernetes社區中，比較常見的幾種網絡實現主要是以下兩種：

基于Overlay網絡：以Flannel、Weave為代表。Flannel是CoreOS為Kubernetes專門定制實現的Overlay網絡方案，也是Kubernetes默認的網絡實現。它基于VXLAN或者UDP整個集群的Overlay網絡，從而實現容器在集群上的通信，滿足Kubernetes網絡模型的三大基本約束。由于在通信過程中存在數據包的封包解包等額外損耗，性能較差，但已經基本滿足使用。

以L3路由為基礎實現網絡：以Calico、Romana為代表。其中，Calico是廣泛流傳的性能最好的Kubernetes網絡實現，基于純三層的路由實現網絡通信，結合iptables實現的安全控制，可以滿足大多數云的性能需求。但是由于它要求主機上必須打開BGP形成路由拓撲，在一些數據中心上可能不會被允許。同時，Calico還比較早地支持了Network Policy，并且可以將Calico自身的數據直接托管在Kubernetes中，從而實現與Kubernetes的深度集成。

從上面這些網絡實現來看，目前Kubernetes的網絡實現都還談不上是比較成熟的SDN，因此我們公司在考察Kubernetes后，決定基于Neutron，為Kubernetes提供一個可用的SDN實現，這就是Skynet項目的由來。

下面我來跟大家分享下，Skynet在實踐過程中的一些經驗。

在實踐中，首先要解決的就是Kubernetes中的網絡概念，怎么翻譯到Neutron中，才能比較合適地實現功能。

在第一個版本中，Kubernetes網絡中概念翻譯對應如下表所示：

POD ----> 虛擬機

?
Service -------> loadbalancer

?
Endpoints -------> pool

?
Service后端POD ----> member

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

POD ----> 虛擬機

?
Service -----> lbaasv2 loadbalancer

?
Service port ----->lbaasv2 listener

?
Endpoints -----> lbaasv2 pool

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

?
POD livenessProbe ----->health monitor

LBaaS V2的基本術語圖解如下所示：

Load Balancer：負載均衡器，對應一個HAProxy進程，占據一個子網IP。可以邏輯上映射為Kubernetes中的Service。

?
Listener：監聽器，表示負載均衡器本身提供的一個前端監聽端口。對應service定義中的ports中port。

?
pool：監聽器后端的成員集合記錄。

?
member：監聽器后端的成員。對應service使用的Endpoints的addresses列表，每個地址可以對應service聲明中的targetPort的映射。

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

就資源數量的映射來說：Kubernetes的一個service，對應一個Load Balancer。service中的每個port對應監聽這個Load Balancer的一個Listener。每個Listener后端都對接一個pool包含其后端資源。而Kubernetes中的每個Service都有一個對應的Endpoints來包含其后端POD。Endpoints中的每個IP+Service聲明port的targetPort就對應pool中的一個member。

初步完成了概念的映射后，我們簡單介紹下開發中的思路。

在整體結構上，Skynet居于Kubernetes和Neutron之間，實現了CNI規范，基于Neutron為容器配置網絡。service-watcher負責監聽Kubernetes的資源，對服務等概念翻譯為Neutron實現，從而實現完整的網絡功能。如下所示：

kubelet是創建POD的直接操作者，在為POD設置網絡時，通過CNI接口規范，調用Skynet實現。Skynet通過調用Neutron為容器分配IP，并通過在POD容器網絡命令空間中操作，實現IP、路由等通信規則的設置。

而Neutron原生的DHCP、LBaaS v2等機制可以基本保持不變。從而實現完整的集成，可以使Kubernetes集群獲得完整的Neutron SDN功能。而當容器內需要進行DNS時，則可以通過Neutron自帶的DHCP Agent負責實現解析，在集群網絡中正常工作。

如前文所述，Skynet實現了CNI規范，kubelet與Skynet之間的交互過程如下所示：

簡要介紹下每個步驟：

kubelet通過CNI機制調用skynet，主要傳遞的參數如下：

CNI_COMMAND：調用指定CNI動作，ADD表示增加網卡，DEL表示釋放網卡

?
CNI_CONTAINERID：容器ID

?
CNI_NETNS：容器網絡命名空間文件位置

?
CNI_ARGS：額外傳遞的參數

?
CNI_IFNAME：設置的容器網卡名稱，如eth0

執行ADD操作時，Skynet根據傳入的參數和POD的配置，通過neutron-server為POD創建port。

執行ADD操作時，Skynet根據port和網絡配置，為容器創建網絡設備，并掛載到容器命名空間中。

neutron-linuxbridge-agent，根據容器的網絡和安全組規則生成iptables。從而利用Neutron原生的安全組功能，同時也可以直接利用Neutron的一整套SDN實現，包括vRouter、FWaaS、VPNaaS等服務。

service-watcher將Kubernetes服務映射為Neutron LBaaS v2實現后，以VLAN網絡為例，POD與服務之間的流量通信過程如下圖：

當集群內容器訪問服務時，Kubernetes默認都是通過服務名稱訪問，服務名通過Neutron的DHCP機制，可以由每個網絡的Dnsmasq進程負責解析，獲得service對應負載均衡的IP地址后，即可用于網絡通信，由物理交換機負責流量的中轉。

在實際實現中，以Kubernetes中一個服務的定義映射到Neutron的loadbalancer為例演示下。

例如對下面的service實現：

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通過特定注解來指定使用的Neutron網絡、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"

}

其對應的HAProxy進程配置如下所示：

# 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

綜上所述，通過基于Neutron的Skynet，我們為Kubernetes初步實現了SDN的功能，同時提供了如下網絡功能增強：

POD的IP、Mac、主機名等網絡配置的保持；

基于Neutron安全組，實現了POD之間的網絡隔離功能，更加通用；

支持通過HAProxy直接對外提供服務，性能上會比原生的iptables好很多。

當然，目前有一些Kubernetes特性在Skynet網絡方案中還不支持，需要在后面進行增強或實現：

Headless services這一類沒有集群IP的Service無法處理。

由于neutron-server與neutron-plugin之間的消息都是通過RabbitMQ進行，不是特別適合容器環境下網絡快速變更的現狀，會是整個方案的一大瓶頸。

轉載于:https://www.cnblogs.com/nongchaoer/p/6792756.html

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。