Travis CI 支援 Arm64 平台的編譯與測試了

剛剛看到 Travis CI 宣佈支援 Arm64 的編譯與測試環境了:「Announcing General Availability of Graviton2 CPU Support!」。

架構上是利用 AWS 推出的機器來做,其中支援的 OS image 目前看起來是以 Ubuntu 為主,其中 16.04 (xenial) 與 18.04 (bionic) 只有 LXD container 的環境,而 20.04 (focal) 則除了 LXD container 環境外,也有完整的 VM 環境可以跑:

Following Arm64 distributions of Ubuntu are available for you as LXD containers:

Xenial (16.04)
Bionic (18.04)
Focal (20.04)

Following Arm64 distribution of Ubuntu is available for you as a full VM option:

Focal (20.04)

看起來底層是用 Ubuntu 20.04 為主力,然後提供 container 跑其他版本。

在網路流量很大時,Container 的網路對資料庫效能的影響

Percona 的「How Container Networking Affects Database Performance」這篇在討論 Kubernetes 上選擇不同的 CNI 對於資料庫效能的影響。

最重要的是結果的這張圖:

可以看到 TPS 與 throughput 都有影響到,要注意的是這是兩個不同的工具測出來的結果,在 TPS 上是用 sysbench,可以看到最好的 Kube-Router 上也掉了 13% 的 TPS:

Another key thing we found was that even in the best-case with Kube-Router we see an approximate 13% decrease in database performance comparing bare metal to running within Kubernetes. This illustrates that there are still improvements to be made to the performance of container networking in Kubernetes.

throughput 是用 iperf3,只要不是真的掉很多,就沒那麼關心了...

不過這個測試另外一個解讀是,如果你用資料庫不單純是 PK find() 類的處理,那麼效能應該是還好,因為會有不少 CPU 資源 (以及對應的時間) 是用在 join 或是其他處理上,對於 latency 與 throughput 應該就沒有那麼敏感了...

AWS Fargate 推出 Spot

相較於 Amazon EC2 有 Spot Instance (可以利用 Spot Instance 的競價機制省下很多費用),這次 AWS re:InventFargate 也推出了對應的產品線:「AWS Fargate Spot Now Generally Available」。

跟 EC2 的相同,你在上面跑的應用程式必須可以接受隨時中斷服務 (i.e. 必須是 crash-safe),常見的情境是 worker 類的程式。

價錢上大約在三折 (寫這篇時 us-east-1 目前的價錢),考慮到啟動的速度比 EC2 快很多,這樣好像是個可以考慮的方案...

Ubuntu 改變放掉 i386 的計畫

先前在「Ubuntu 19.10 要放掉 i386 架構」這邊提到 Ubuntu 要放掉 i386 的計畫,因為造成的迴響很大,現在官方決定修改本來的結論:「Statement on 32-bit i386 packages for Ubuntu 19.10 and 20.04 LTS」。

在本來的計畫裡,是完全放生 i386 架構 (完全不管):

While this means we will not provide 32-bit builds of new upstream versions of libraries, there are a number of ways that 32-bit applications can continue to be made available to users of later Ubuntu releases, as detailed in [4]. We will be working to polish the 32-bit support story over the course of the 19.10 development cycle. To follow the evolution of this support, you can participate in the discourse thread at [5].

現在則是打算透過 container 技術支援 32-bit library & binary,算是某種緩衝方式:

We will also work with the WINE, Ubuntu Studio and gaming communities to use container technology to address the ultimate end of life of 32-bit libraries; it should stay possible to run old applications on newer versions of Ubuntu. Snaps and LXD enable us both to have complete 32-bit environments, and bundled libraries, to solve these issues in the long term.

但應該還是會有程式沒辦法在 container 環境裡跑,看起來官方決定放掉了...

Kubernetes 的失敗案例

有人把 Kubernetes (通常縮寫成「K8S」) 的失敗案例 (轉移失敗、爛掉、...) 整理到 GitHub 上:「Kubernetes Failure Stories」,裡面有文章也有演講影片,然後也有重複的公司在不同時間點說明。

先來講 K8S 好了,如果要粗略的解釋 K8S 是什麼東西,我會說就像是架一組 AWS 服務起來,但是是基於 container 而非 VM。

拿 AWS 的詞彙來說,他在上面疊了一層 Amazon VPC (會對應到 Kubernetes 的 overlay network 與 CNI),然後也提供 AMI (透過 Docker Image) 與 EC2 (因為是比喻,這邊就拿 AMI + EC2 來對比),還有基本的 ELB (各種 NodePort、HostPort 與 Ingress) 與 Service Discovery。

比較特別的是 Pod 的概念,在一般的雲上不太會看到。

不過大致上你可以想像這是一個小型的 AWS,而試著去猜測管理一個小型的 AWS 會需要了解多少底層知識,加上 K8S 一直在發展,很多功能可能都還不成熟 (所以用起來會覺得設計很奇怪),然後上面整理出的失敗案例就不意外了... XD

如果你是自己有機房,或是用便宜的 VPS (像是 LinodeDigitalOceanVultr),那麼我覺得在上面堆 K8S cluster 還算合理,畢竟你可以透過 K8S 幫你整合不少以前得自己架設的服務。

但如果你是已經在 Cloud 上面,然後還想在上面跑 K8S cluster,我是覺得還是要有個理由 (不管是技術上或是政治上的)。如果只是因為 K8S 潮到出水而用的話,可能過一個月後你家就淹水了 XD

另外講一些題外話,因為最近弄 Kubernetes 的關係 (可以參考我的筆記「Kubernetes」),才能理解為什麼 Linode 這些 VPS 會推出 load balancer 與 block storage,算是後知後覺...

AWS 宣佈 Fargate 大幅降價

AWS Fargate 大幅降價:「Announcing AWS Fargate Price Reduction By Up To 50%」、「AWS Fargate Price Reduction – Up to 50%」。

先前 Fargate 的定價超級高,基本上是不會有正常應用會丟上去的情境... 如果可以接受 Fargate 的價錢,平常就用 ECS 或是 EKS 開三到五倍的機器在旁邊待機就好了,container scale 的速度還比 Fargate 快。

這次降價幅度很大,vCPU 降 20% 其實不算小,但相較於 Memory 降的 65% 就感覺好像沒降很多 (...):

Effective Jan 07, 2019, we are reducing the price for AWS Fargate by 20% for vCPU and 65% for memory across all regions where Fargate is currently available.

us-east-1m5.24xlarge 的價錢來看是 USD$4.608/hr。以他的 96 vCPU + 384 GiB RAM 對應到 Fargate 來算是 USD$5.59296/hr,大約多 21% 的價錢。

這樣的產品價位看起來才有對應的空間...

AWS 的 Firecracker 技術 (安全的 Container?)

AWS 放出來的 open source 專案 Firecracker,也就是在 AWS 內打造安裝的 container 環境所使用的技術:「Firecracker – Lightweight Virtualization for Serverless Computing」。

依照說明,看起來是利用 crosvm (KVM-based) 但讓他更輕,啟動 image 的時間更快,達到跟 container 類似的效果:

High Performance – You can launch a microVM in as little as 125 ms today (and even faster in 2019), making it ideal for many types of workloads, including those that are transient or short-lived.

Low Overhead – Firecracker consumes about 5 MiB of memory per microVM. You can run thousands of secure VMs with widely varying vCPU and memory configurations on the same instance.

看起來有機會在自己機器上跑看看 (i.e. 非虛擬環境)?跑之前要注意目前只支援 Intel 的硬體:

Firecracker currently supports Intel CPUs, with planned AMD and Arm support. Firecracker will also be integrated with popular container runtimes.

用 Dive 看 Docker Image 裡面每一層的內容

看到 wagoodman/dive 這個工具,只要給 Docker 的 image 與 tag 資訊,就可以看每一層裡面的內容:

安裝上也有提供各平台的套件包 (deb、rpm 之類的)。操作的熱鍵在首頁的下方也有提供,用起來很方便。

Travis CI 將轉移到 VM-based 環境

Travis CI 宣佈了將目前 container-based 的環境轉移到 VM-based 的時程:「Upcoming Required Linux Infrastructure Migration」,裡面有提到十月初的時候的文章「Combining The Linux Infrastructures」。

看起來是因為安全性的考慮,container-based 的環境必須在指定 sudo: false 的情境下才能使用。如果需要 root 權限一定會丟到 VM-based 的環境跑。現在看起來 Travis CI 不打算維護 container-based 環境了,所以整個轉移到 VM-based 的環境...

另外一個方向應該是 Google 之前提出來的 gVisor 專案 (參考「Google 推出 gVisor 強化 Container 的安全性」),不過看起來相容性又是個問題...

Google 推出 gVisor 強化 Container 的安全性

Google 發表了 gVisor,針對 Linux 所使用的 container 技術強化安全的部份:「Open-sourcing gVisor, a sandboxed container runtime」。

依照 Google 的說法,一般 container 的架構是這樣:

而具有強隔離性的 VM 技術則是這樣:

在 VM 的 overhead 偏重,但一般的 container 安全性又不夠。而 gVisor 則是這樣:

對於目前最常見的 Docker 系統上,在安裝 gVisor 後只需要指定 --runtime=runsc 就可以使用 (預設是 --runtime=runc),像是這樣:

$ docker run --runtime=runsc hello-world
$ docker run --runtime=runsc -p 3306:3306 mysql

其中 runsc 的意思是「run Sandboxed Container」。

另外而因為 gVisor 卡在中間,不認識的 syscall 都會被擋下來,所以目前並不是所有的應用程式都可以跑,但開發團隊已經測了不少應用程式可以在上面運作,算是堪用的程度:

gVisor implements a large part of the Linux system API (200 system calls and counting), but not all. Some system calls and arguments are not currently supported, as are some parts of the /proc and /sys filesystems. As a result, not all applications will run inside gVisor, but many will run just fine, including Node.js, Java 8, MySQL, Jenkins, Apache, Redis, MongoDB, and many more.

值得一提的是,雖然是處理 syscall,但是是用 Go 開發的,而不是 C 或是 C++,這點頗特殊的...