Skip to main content

14 posts tagged with "Network"

View All Tags

· 3 min read

Linux Bridge 的 MTU 設定不如一般網卡簡單設定,其 MTU 預設情況下會自動調整,會自動使用所有 slave 網卡上最小的值來取代 以下列程式碼來看,剛有任何 slave 網卡加入到 bridge 上後

int br_add_if(struct net_bridge *br, struct net_device *dev,
struct netlink_ext_ack *extack)
{
struct net_bridge_port *p;
int err = 0;
unsigned br_hr, dev_hr;
bool changed_addr, fdb_synced = false;

/* Don't allow bridging non-ethernet like devices. */
if ((dev->flags & IFF_LOOPBACK) ||
dev->type != ARPHRD_ETHER || dev->addr_len != ETH_ALEN ||
!is_valid_ether_addr(dev->dev_addr))
return -EINVAL;

/* No bridging of bridges */
if (dev->netdev_ops->ndo_start_xmit == br_dev_xmit) {
NL_SET_ERR_MSG(extack,
"Can not enslave a bridge to a bridge");
return -ELOOP;
}

/* Device has master upper dev */
if (netdev_master_upper_dev_get(dev))
return -EBUSY;

/* No bridging devices that dislike that (e.g. wireless) */
if (dev->priv_flags & IFF_DONT_BRIDGE) {
NL_SET_ERR_MSG(extack,
"Device does not allow enslaving to a bridge");
return -EOPNOTSUPP;
}

p = new_nbp(br, dev);
if (IS_ERR(p))
return PTR_ERR(p);

call_netdevice_notifiers(NETDEV_JOIN, dev);

err = dev_set_allmulti(dev, 1);
if (err) {
br_multicast_del_port(p);
netdev_put(dev, &p->dev_tracker);
kfree(p); /* kobject not yet init'd, manually free */
goto err1;
}

err = kobject_init_and_add(&p->kobj, &brport_ktype, &(dev->dev.kobj),
SYSFS_BRIDGE_PORT_ATTR);
if (err)
goto err2;

err = br_sysfs_addif(p);
if (err)
goto err2;

err = br_netpoll_enable(p);
if (err)
goto err3;

err = netdev_rx_handler_register(dev, br_get_rx_handler(dev), p);
if (err)
goto err4;

dev->priv_flags |= IFF_BRIDGE_PORT;

err = netdev_master_upper_dev_link(dev, br->dev, NULL, NULL, extack);
if (err)
goto err5;

dev_disable_lro(dev);

list_add_rcu(&p->list, &br->port_list);

nbp_update_port_count(br);
if (!br_promisc_port(p) && (p->dev->priv_flags & IFF_UNICAST_FLT)) {
/* When updating the port count we also update all ports'
* promiscuous mode.
* A port leaving promiscuous mode normally gets the bridge's
* fdb synced to the unicast filter (if supported), however,
* `br_port_clear_promisc` does not distinguish between
* non-promiscuous ports and *new* ports, so we need to
* sync explicitly here.
*/
fdb_synced = br_fdb_sync_static(br, p) == 0;
if (!fdb_synced)
netdev_err(dev, "failed to sync bridge static fdb addresses to this port\n");
}

netdev_update_features(br->dev);

br_hr = br->dev->needed_headroom;
dev_hr = netdev_get_fwd_headroom(dev);
if (br_hr < dev_hr)
update_headroom(br, dev_hr);
else
netdev_set_rx_headroom(dev, br_hr);

if (br_fdb_add_local(br, p, dev->dev_addr, 0))
netdev_err(dev, "failed insert local address bridge forwarding table\n");

if (br->dev->addr_assign_type != NET_ADDR_SET) {
/* Ask for permission to use this MAC address now, even if we
* don't end up choosing it below.
*/
err = dev_pre_changeaddr_notify(br->dev, dev->dev_addr, extack);
if (err)
goto err6;
}

err = nbp_vlan_init(p, extack);
if (err) {
netdev_err(dev, "failed to initialize vlan filtering on this port\n");
goto err6;
}

spin_lock_bh(&br->lock);
changed_addr = br_stp_recalculate_bridge_id(br);

if (netif_running(dev) && netif_oper_up(dev) &&
(br->dev->flags & IFF_UP))
br_stp_enable_port(p);
spin_unlock_bh(&br->lock);

br_ifinfo_notify(RTM_NEWLINK, NULL, p);

if (changed_addr)
call_netdevice_notifiers(NETDEV_CHANGEADDR, br->dev);

br_mtu_auto_adjust(br);
br_set_gso_limits(br);

kobject_uevent(&p->kobj, KOBJ_ADD);

return 0;

err6:
if (fdb_synced)
br_fdb_unsync_static(br, p);
list_del_rcu(&p->list);
br_fdb_delete_by_port(br, p, 0, 1);
nbp_update_port_count(br);
netdev_upper_dev_unlink(dev, br->dev);
err5:
dev->priv_flags &= ~IFF_BRIDGE_PORT;
netdev_rx_handler_unregister(dev);
err4:
br_netpoll_disable(p);
err3:
sysfs_remove_link(br->ifobj, p->dev->name);
err2:
br_multicast_del_port(p);
netdev_put(dev, &p->dev_tracker);
kobject_put(&p->kobj);
dev_set_allmulti(dev, -1);
err1:
return err;
}

其中上述的重點是 br_mtu_auto_adjust,該 function 的內容如下,基本上就去找出最小MTU並且設定

void br_mtu_auto_adjust(struct net_bridge *br)
{
ASSERT_RTNL();

/* if the bridge MTU was manually configured don't mess with it */
if (br_opt_get(br, BROPT_MTU_SET_BY_USER))
return;

/* change to the minimum MTU and clear the flag which was set by
* the bridge ndo_change_mtu callback
*/
dev_set_mtu(br->dev, br_mtu_min(br));
br_opt_toggle(br, BROPT_MTU_SET_BY_USER, false);
}

· 2 min read

預設的 istio-proxy 都會吃掉一些 CPU/Memory,當叢集內的 Pod 數量過多時,這些 sidecar 吃掉的數量非常可觀 如果是採用 istiooperator 的方式安裝,可以採用下列方式修改

...
spec:
values:
global:
proxy:
privileged: false
readinessFailureThreshold: 30
readinessInitialDelaySeconds: 1
readinessPeriodSeconds: 2
resources:
limits:
cpu: 2000m
memory: 1024Mi
requests:
cpu: 100m
memory: 128Mi

這個設定是 global 的設定,如果是單一的 Pod 要自行調整,可以於 Pod annotations 中加入列下資訊調整

annotations:
sidecar.istio.io/proxyCPU: 50m
sidecar.istio.io/proxyMemory: 128Mi

如果要更新 istio,建議參考官方 Canary Approach 的步驟,使用金絲雀部署的方式逐步調整 其原理很簡單

  1. 同時部署兩個版本的 istiod
  2. 逐步重啟 Pod 來套用新版本的 istio,直到所有 pod 都轉移到新版本的 istiod
  3. 移除舊的

基本上安裝過程要透過 "--revision=1-14-2" 的方式去打版本,安裝完畢後就是單純只有 control plane

接下來就取決當初如何設定 sidecare 的,如果是 namespace 的話,就可以直接改 namespace 裡面的

istio.io/rev=1-14-2

接下來就逐步重啟 Pod 就可以切換到新的 istio 版本。

另外可以透過 istioctl proxy-status 觀察每個 Pod 目前搭配的版本,透過此指令觀察升級進度

一旦全部升級完畢可以用 istioctl uninstall --revision 1-13-1 -y 來移除舊版本

· 2 min read

GCP 的世界中透過 Cloud NAT 來處理對外流量,由該 NAT GW 進行 SNAT 的轉換。 之前遇到一個問題是某對外服務的連線會不定時 timeout 無法連線,輾轉各種測試最後終於發現問題出在 Cloud NAT 上

Cloud NAT 上有一個設定稱為 Port Reservation 該設定會影響 Cloud NAT 要如何幫後方所有流量進行 SNAT,要用哪個 Source IP 以及哪個 Source Port 去處理。

其中有一個設定是 "Minimum Ports per VM",這個欄位的意思是每個 VM 上可以對相同目標 (IP + Port) 同時發起多少條連線 舉例來說,假設今天想要連接 1.2.3.4:2345 這個網站,且設定為 32,那就代表這個 VM 上最多只能有 32 條連線,超過的就會被 Cloud NAT 丟掉而無法處理,最後產生 timeout

如果今天 VM 規格夠大,上面部署 GKE 同時有多個相同副本的 Pod 同時運行,那就有可能會踩到這個數字導致連線 timeout,可以到 Cloud NAT 的設定將其調整,預設應該是 64。

另外 Cloud NAT 本身對外流量都會收費,要計算流量資訊需要到 VPC 去打開 Logging 紀錄,這個 Logging 也需要特別設定取樣頻率,因為會收費 所以設定完成後,就可以於 Cloud Logging 收到相關資訊,可以把 Logging 轉換為 Metrics 去計算流量的走向,譬如以 IP/hostname 為基準去分析到底流量都跑去那,再透過這個資訊來除錯省錢

· 2 min read

標題: 「分散式系統上的常見網路謬誤」 類別: others 連結: https://architecturenotes.co/fallacies-of-distributed-systems/

本篇文章是探討分散式系統上很常被開發者所忽略的網路情況,這些情境都容易被忽略與考慮,但是每個點實際上都會影響整個系統的效能與功能

這些常常被忽略的網路情況包含

  1. The network is reliable
  2. Latency is zero
  3. Bandwidth is infinite
  4. The network is secure
  5. Topology doesn't change
  6. There is one administrator
  7. Transport cost is zero
  8. The network is homogeneous

The network is reliable

開發分散式系統的時候,一定要去考慮網路壞掉的情況,切記網路中的任何傳輸都不是 100% 穩定的。千萬不要假設所有封包與傳輸都沒有問題,必要時還要考慮重新連線,重新傳輸的情況。

Latency

網路時間還有一個要注意的就是延遲時間,通常 Client/Server 如果都是同一個系統內的服務時,這類型的時間可能非常短,如 ms 等級。 但是當 client 可能是來自真實使用者的手機裝置時,就要將 latency 這些因素給考慮進去,不能假設所有的 API 與網路請求都是秒回的情況。

更常見的還有導入 CDN 等方式透過地理性的位置來減少 client/server 之間要傳輸的距離。

文章內針對剩下的類別都有簡單的圖文並茂來解釋,淺顯易懂,有興趣的可以參閱全文

· 3 min read

標題: 「Mizu, 一套用來檢視 Kubernetes Traffic 的視覺化工具」 類別: tools 連結: https://getmizu.io/docs/

Mizu 是一個專門針對 Kubernetes 開發的流量分析工具,該工具透過簡單好用的 UI 讓你檢視叢集內的流量走向,其支持的協定有 HTTP, REST, gRPC, Kafka, AMQP 以及 Redis 等相關的應用程式封包。

雖然說透過大部分的 Service Mesh 也都可以提供一樣的功能,但是 Mizu 的特色就是其輕量的架構設計,就是針對流量分析而已,所以如果團隊目前沒有現成的解決方案時, 可以考慮試試看 Mizu 這套輕量級的解決方案。

Mizu 本身由兩個元件組成,分別是 CLI 以及 Agent,當你安裝 Mizu 的 Kubernetes 內時,其會安裝兩個元件

  1. 透過 Daemonset 安裝 Agent 到所有節點
  2. 透過 Pod 安裝一個 API Server

Agent 會針對需求去抓取節點上特定的 TCP 封包(目前也只有支援 TCP 流量,這意味如 ICMP, UDP, SCTP 等就沒有辦法),此外要特別注意這類型的解決方案為了能夠 抓取到節點上的所有流量,通常都會讓這類型的 Agent 都設定為 hostnetwork: true,如此一來該 Agent 才有辦法觀察到節點上的所有網卡來進行流量擷取。

有些 k8s 環境會透過如 OPA(Gatekeeper) 等機制去控管要求所有的 Pod 不准使用 hostnetwork,有這些規範的可能就要注意一下整合上的問題。

有興趣的可以稍微玩看看,看看這類型的工具是否可以幫忙除錯

· One min read

標題: 「視覺化系統內 iptables 規則」 類別: tools 連結: https://github.com/Nudin/iptable_vis

這是一個非常有趣的小工具,目標就是視覺化系統中的 iptables 規則,把 chain 之間的關聯給視覺化呈現出來 整個專案非常小,該專案主要會透過 awk 來解析系統中的規則並且產生特定輸出,接者使用別的軟體將該輸出給轉換成圖檔

有興趣的都可以使用看看

· 2 min read

連結: https://matduggan.com/mistakes/

本文是作者踩過的各種 Infrastructure 雷,希望讀者能夠避免這些雷。

總共有幾大類,分別

  1. Don't migrate an application from the datacenter to the cloud
  2. Don't write your own secrets system
  3. Don't run your own Kubernetes cluster
  4. Don't Design for Multiple Cloud Providers
  5. Don't let alerts grow unbounded
  6. Don't write internal cli tools in python

其中第六點簡短扼要,大概就是「沒有人知道如何正確地去安裝與打包你的 python apps, 你真的要寫一個內部的 python 工具就給我讓他完全跨平台不然就給我改用 go/rust, 不要浪費生命去思考到底該如何安裝那些東西」

這讓我想到你的 Python 跟我的 Python 每次都不一樣,有已經不支援的 python 2.x, 還有各種可能會互相衝突的 python 3.x....

· 2 min read

連結: https://www.weave.works/blog/racy-conntrack-and-dns-lookup-timeouts

今天跟大家分享一個 UDP 於 Linux Kernel 內的 Race Condition 問題。這問題我以前於 Linux Kernel 3.14 也有採過一樣的雷,但是到今日都還沒有一個很漂亮的解決方案,這邊就快速的跟大家介紹一下這個問題> 是什麼,以及跟 k8s 有什麼關係

發生前提

  1. 使用 UDP 這種沒有重送機制的協定
  2. Kernel 有開啟 conntrack 此功能

發生條件

相同的 Client 短時間內透過 UDP (也許是不同 thread) 送出兩個 UDP 封包到外面,對於 Linux Kernel 來說,會希望透過 conntrack 來追蹤每一條連線,但是底層建立的時候會有一些會有一些機制,因此當兩個封 包同時進入的時候,有可能就會因為先後順序導致第二個封包被丟棄

可能發生問題

DNS 的請求封包預設情況下會同時透過 UDP 送出 A & AAAA 兩個封包,而這兩個封包如果很巧的採到這個情況,然後你的 A 封包就沒有辦法順利解出 DNS,最後就要等五秒的 timeout 來重新發送 下偏這篇文章就是 weave works 遇到 DNS 5秒 timeout 的問題,然後仔細的將我上面所寫的總結給解釋清楚,每一個步驟發生什麼事情,什麼是 conntrack 以及暫時的 workaround 是什麼 之後會在跟大家分享目前一些解決方法怎麼做

· 2 min read

連結: https://www.cncf.io/blog/2020/09/29/enforce-ingress-best-practices-using-opa/

不知道大家有沒有聽過 Open Policy Agent (OPA) 這個 CNCF 專案? 有滿多專案的背後都使用基於 OPA 的語言 Rego 來描述各式各樣的 Policy,譬如可以使用 conftest 來幫你的 kubernetes yaml 檢查語意是否有符合事先設定的 Policy。 本篇文章則是跟大家分享如何使用 OPA 來針對 Ingress 資源進行相關防呆與除錯,一個最基本的範例就是如何避免有多個 Ingress 使用相同的 hostname 卻指向不同的 backend service. 過往可能都是靠人工去維護 ,確保沒有一致的名稱,但是透過 OPA 的概念我們可以再佈署 Ingress 到 Kubernetes 前先進行一次動態的比對,確保當前設定符合所有 Policy,得到所謂的 Approved 後才能夠佈署進去。 有興趣的人可以看看這篇文章,甚至學習一下 OPA 的使用方式

· 2 min read

連結: https://blog.cloudflare.com/the-sad-state-of-linux-socket-balancing/

今天要來跟大家分享一個單一節點如何提高應用程式吞吐量與服務能力的方式 這個方式主要探討的是應用程式對於網路連線的 I/O 模型,試想一個常見的使用範例。 一個主要的 Process 會去聽取一個固定的 port number (ex port 80),並且通知後面眾多的 worker 來幫忙處理這些封包連線,而這些 worker 的工作就是處理連線。 整個架構中是一個 1 v.s N 的狀況, 一個負責 Listen ,N個負責處理連線內容 而今天要分享的則是想要讓架構變成 N v.s N 的狀況, 會有 N 個 Process, 每個 Process 配上一個 Worker。 而這 N個 process 同時共享一樣的 Port (ex, port 80) 這種情況下可以減少多個 worker 共享一個 listen socket 時的各種保護機制,取而代之的則是每個 listen socket 配上一個專屬的 worker 來處理。 要達成這樣的架構非常簡單,只要透過 SO_REUSEPORT 這個 socket option 告 訴 Kernel 當前這個 PORT 可以重複使用。 當封包送到 kernel 後則是由 kernel 幫你分配封包到所有使用相同地址的 Listen Socket (Process) 根據 nginx 官方文章的測試,這種架構下對於 RPS (Request per second) 有顯著的提升,有興趣的可以看看下列兩篇文章