「K8S 生態週報」內容主要包含我所接觸到的 K8S 生態相關的每週值得推薦的一些信息。歡迎訂閱知乎專欄「k8s生態」。
微軟開源了 Open Service Mesh
微軟近期開源了一個新的名爲 Open Service Mesh 的項目並準備捐贈給 CNCF 。
OSM 主打輕量&可擴展，支持 Service Mesh Interface (SMI) 規範 附帶開箱即用的可觀察性功能。截至目前，已經發布了v0.2.0 版本。
主要特性如下：
- 支持 Service Mesh Interface (SMI) 的規範，主要包括
Traffic Access Control，Traffic Specs和Traffic Split。剩下的Traffic Metrics正在開發中； - 服務間的通信加密使用 mTLS ；
- 定義和執行服務間的訪問控制策略；
- 通過 Prometheus 和 Grafana 完成其觀察性；
- 可與外部證書管理服務進行集成；
- Envoy sidecar 自動注入；
關於 Open Service Mesh 更詳細的內容，請參考我上一篇文章 初試 Open Service Mesh（OSM）
runc v1.0-rc92 發佈
這個版本在本週發佈，主要是因爲上個版本 v1.0-rc91 發佈之後，我發現了它會導致 Docker 無法使用 --privileged 參數運行一個容器，總是會提示 invalid argument 這個錯誤。
查看代碼後，發現它來自於 Golang 中 golang.org/x/sys/unix 的 unix.Mknod() 這個方法，這其實是一個系統調用。本着求真務實的態度，我去檢查了下這個函數的源碼， glibc 以及 linux kernel 的源碼，一番折騰後，也定位到了問題所在。
發現問題來自於 runc 的某次修改，並聯繫到了 runc 的維護者 Aleksa Sarai ，他在一次更新中 刪除了一段用於檢查設備類型的代碼，所以才導致了隱藏在 runc 中的 bug 這次被暴露了出來。
而這個 bug 目前隻影響到了 Docker ，並未影響 runc 作爲容器運行時自身的功能。
隨後 Aleksa Sarai 提交代碼進行了漏洞修復，我們來看看這段折騰了我好幾天的代碼：
- 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
其實就是一段用來判斷系統設備類型的代碼，但很遺憾，之前的類型判定一直都是錯誤的，用來判定設備類型，不能使用類似 mode&unix.S_IFBLK == unix.S_IFBLK 這樣的方法，而是需要使用 mode & unix.S_IFMT 作爲判定。
這在 Linux 內核的源碼中也早有體現 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)
最終，這個修復被合併了，Docker 也可以繼續和新版本的 runc 一起工作了。(個人體會就是，有些 bug 隱藏太深，這段代碼我之前看過，但太像了，被我給忽略掉了 orz)
containerd v1.4.0-rc.0 發佈
這是 containerd 的第 5 個主要版本，此版本中包含了大量的更新，比如對 CGroups v2 的支持，擴展的 SELinux 支持，通過 CRI 提供了 Kubernetes On Windows 的支持，共享遠端存儲的快照支持等。
此版本中包含的重大 bug 的修復也會移植到當前還受支持的版本中。此外，在這個版本中，也包含了兩個不向後兼容的 API 修改，需要注意。
以下是我覺得值得關注的變更：
- #3726 添加對 CGroups v2 的支持；
-
#4384 標記
io.containerd.runtime.v1.*和io.containerd.runc.v1這兩個 runtime 爲廢棄。 在當前 Docker v19.03.x 版本中，默認的 runtime 調用的 API 就是 io.containerd.runtime.v1.linux , 如果要升級 Docker 或者單獨升級 containerd ， 需要格外注意; - #3765 支持 FUSE 掛載；
- #3972 修復了鏡像併發下載的問題；
-
#3925 爲快照添加了
cleanup的 API； -
#4439 安裝 containerd 的時候， 不需要在額外安裝
libseccomp， 內置了；
以上就是我認爲 containerd v1.4.0-rc.0 中值得注意的變更，更多關於此版本的信息，請參考其 ReleaseNote
Docker v19.03.13-beta2 發佈
本次版本主要是進行一些 bugfix，目前沒什麼太值得單獨聊的，本期暫且跳過，等正式版本發佈時再具體聊。
上游進展
#93570 componentstatus API 被標記廢棄。
有時，我們會通過 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 已經不能很好的正常工作了。 所以現在將其標記爲廢棄，不建議再通過此 API 來獲取集羣組件的狀態信息了。
歡迎訂閱我的文章公衆號【MoeLove】
[