K8S 生態(tài)周報| runc v1.0-rc92 發(fā)布

「K8S 生態(tài)周報」內(nèi)容主要包含我所接觸到的 K8S 生態(tài)相關(guān)的每周值得推薦的一些信息。歡迎訂閱知乎專欄「k8s生態(tài)」迁霎。

微軟開源了 Open Service Mesh

微軟近期開源了一個新的名為 Open Service Mesh 的項目并準(zhǔn)備捐贈給 CNCF 吱抚。

OSM 主打輕量&可擴(kuò)展，支持 Service Mesh Interface (SMI) 規(guī)范附帶開箱即用的可觀察性功能考廉。截至目前秘豹，已經(jīng)發(fā)布了v0.2.0 版本。

主要特性如下：

支持 Service Mesh Interface (SMI) 的規(guī)范昌粤，主要包括 Traffic Access Control既绕， Traffic Specs 和 Traffic Split 啄刹。剩下的 Traffic Metrics 正在開發(fā)中；
服務(wù)間的通信加密使用 mTLS 岸更；
定義和執(zhí)行服務(wù)間的訪問控制策略鸵膏；
通過 Prometheus 和 Grafana 完成其觀察性膊升；
可與外部證書管理服務(wù)進(jìn)行集成怎炊；
Envoy sidecar 自動注入；

關(guān)于 Open Service Mesh 更詳細(xì)的內(nèi)容廓译，請參考我上一篇文章初試 Open Service Mesh（OSM）

runc v1.0-rc92 發(fā)布

這個版本在本周發(fā)布评肆，主要是因?yàn)樯蟼€版本 v1.0-rc91 發(fā)布之后，我發(fā)現(xiàn)了它會導(dǎo)致 Docker 無法使用 --privileged 參數(shù)運(yùn)行一個容器非区，總是會提示 invalid argument 這個錯誤瓜挽。

查看代碼后，發(fā)現(xiàn)它來自于 Golang 中 golang.org/x/sys/unix 的 unix.Mknod() 這個方法征绸，這其實(shí)是一個系統(tǒng)調(diào)用久橙。本著求真務(wù)實(shí)的態(tài)度，我去檢查了下這個函數(shù)的源碼管怠， glibc 以及 linux kernel 的源碼淆衷，一番折騰后，也定位到了問題所在渤弛。

發(fā)現(xiàn)問題來自于 runc 的某次修改祝拯，并聯(lián)系到了 runc 的維護(hù)者 Aleksa Sarai ，他在一次更新中刪除了一段用于檢查設(shè)備類型的代碼她肯，所以才導(dǎo)致了隱藏在 runc 中的 bug 這次被暴露了出來佳头。

而這個 bug 目前只影響到了 Docker ，并未影響 runc 作為容器運(yùn)行時自身的功能晴氨。

隨后 Aleksa Sarai 提交代碼進(jìn)行了漏洞修復(fù)康嘉，我們來看看這段折騰了我好幾天的代碼：

- switch {
- case mode&unix.S_IFBLK == unix.S_IFBLK:
+ switch mode & unix.S_IFMT {
+ case unix.S_IFBLK:
    devType = configs.BlockDevice
- case mode&unix.S_IFCHR == unix.S_IFCHR:
+ case unix.S_IFCHR:
    devType = configs.CharDevice
- case mode&unix.S_IFIFO == unix.S_IFIFO:
+ case unix.S_IFIFO:
    devType = configs.FifoDevice
default:
    return nil, ErrNotADevice

其實(shí)就是一段用來判斷系統(tǒng)設(shè)備類型的代碼，但很遺憾籽前，之前的類型判定一直都是錯誤的亭珍，用來判定設(shè)備類型，不能使用類似 mode&unix.S_IFBLK == unix.S_IFBLK 這樣的方法聚假，而是需要使用 mode & unix.S_IFMT 作為判定块蚌。

這在 Linux 內(nèi)核的源碼中也早有體現(xiàn) https://github.com/torvalds/linux/blob/bcf876870b95592b52519ed4aafcf9d95999bc9c/include/uapi/linux/stat.h#L21-L27

// include/uapi/linux/stat.h
#define S_ISLNK(m)  (((m) & S_IFMT) == S_IFLNK)
#define S_ISREG(m)  (((m) & S_IFMT) == S_IFREG)
#define S_ISDIR(m)  (((m) & S_IFMT) == S_IFDIR)
#define S_ISCHR(m)  (((m) & S_IFMT) == S_IFCHR)
#define S_ISBLK(m)  (((m) & S_IFMT) == S_IFBLK)
#define S_ISFIFO(m) (((m) & S_IFMT) == S_IFIFO)
#define S_ISSOCK(m) (((m) & S_IFMT) == S_IFSOCK)

最終，這個修復(fù)被合并了膘格，Docker 也可以繼續(xù)和新版本的 runc 一起工作了峭范。(個人體會就是，有些 bug 隱藏太深瘪贱，這段代碼我之前看過纱控，但太像了辆毡，被我給忽略掉了 orz)

containerd v1.4.0-rc.0 發(fā)布

這是 containerd 的第 5 個主要版本，此版本中包含了大量的更新甜害，比如對 CGroups v2 的支持舶掖，擴(kuò)展的 SELinux 支持，通過 CRI 提供了 Kubernetes On Windows 的支持尔店，共享遠(yuǎn)端存儲的快照支持等眨攘。

此版本中包含的重大 bug 的修復(fù)也會移植到當(dāng)前還受支持的版本中。此外嚣州，在這個版本中鲫售，也包含了兩個不向后兼容的 API 修改，需要注意该肴。

以下是我覺得值得關(guān)注的變更：

#3726 添加對 CGroups v2 的支持情竹；
#4384 標(biāo)記 io.containerd.runtime.v1.* 和 io.containerd.runc.v1 這兩個 runtime 為廢棄。在當(dāng)前 Docker v19.03.x 版本中匀哄，默認(rèn)的 runtime 調(diào)用的 API 就是 io.containerd.runtime.v1.linux , 如果要升級 Docker 或者單獨(dú)升級 containerd 秦效，需要格外注意;
#3765 支持 FUSE 掛載；
#3972 修復(fù)了鏡像并發(fā)下載的問題涎嚼；
#3925 為快照添加了 cleanup 的 API阱州；
#4439 安裝 containerd 的時候，不需要在額外安裝 libseccomp铸抑，內(nèi)置了贡耽；

以上就是我認(rèn)為 containerd v1.4.0-rc.0 中值得注意的變更，更多關(guān)于此版本的信息鹊汛，請參考其 ReleaseNote

Docker v19.03.13-beta2 發(fā)布

本次版本主要是進(jìn)行一些 bugfix蒲赂，目前沒什么太值得單獨(dú)聊的，本期暫且跳過刁憋，等正式版本發(fā)布時再具體聊滥嘴。

上游進(jìn)展

#93570 componentstatus API 被標(biāo)記廢棄。

有時至耻，我們會通過 kubectl get componentstatus 來查看集群組件是否健康若皱。例如：

(MoeLove) ?  ~ kubectl get componentstatus
NAME                 STATUS    MESSAGE             ERROR
controller-manager   Healthy   ok                  
scheduler            Healthy   ok                  
etcd-0               Healthy   {"health":"true"}

但隨著 secure port 相繼被啟用，這個 API 已經(jīng)不能很好的正常工作了尘颓。所以現(xiàn)在將其標(biāo)記為廢棄走触，不建議再通過此 API 來獲取集群組件的狀態(tài)信息了。

歡迎訂閱我的文章公眾號【MoeLove】

[