云原生愛好者周刊：VMware Tanzu 社區(qū)版發(fā)布，無任何限制！

云原生一周動態(tài)要聞：

• VMware Tanzu 推出社區(qū)版
• Kubernetes Cluster API 1.0 版已生產(chǎn)就緒
• Linkerd 2.11 發(fā)布
• Cartografos 工作組推出云原生成熟度模型
• OpenEBS 3.0 發(fā)布
• 開源項目推薦
• 文章推薦

云原生動態(tài)

VMware Tanzu 推出社區(qū)版

世界正在向基于 Kubernetes 構(gòu)建的云原生基礎(chǔ)設(shè)施發(fā)展。這就是 VMware 創(chuàng)建 VMware Tanzu 的原因。但是，僅有技術(shù)本身是不夠的，如果沒有開發(fā)人員、基礎(chǔ)設(shè)施和平臺操作員、站點可靠性工程師以及其他擁有使用技術(shù)所需知識和技能的人，即使有再好的技術(shù)也無濟于事。

Tanzu 社區(qū)版包含了利用 Kubernetes 實現(xiàn)端到端應(yīng)用交付自動化所需的所有開源技術(shù)，以及定制平臺的能力。這意味著你可以從小事做起，然后隨著你的需求增長，隨時輕松地增加新的功能。而且，無論未來你走到哪里，你用 Tanzu 社區(qū)版開發(fā)的知識、技能和工件都可以隨身攜帶，并且可以完全轉(zhuǎn)移到 Tanzu 的商業(yè)產(chǎn)品中。

Tanzu 社區(qū)版是免費的開源軟件，不受使用限制或功能限制的影響。

詳情見^[1]

Kubernetes Cluster API 1.0 版已生產(chǎn)就緒

Cluster API v1.0 已準(zhǔn)備好投入生產(chǎn)并正式遷移到 v1beta1 API。Cluster API 是一個 Kubernetes 項目，它為 Kubernetes 啟用聲明式管理，使用 API 輕松創(chuàng)建、配置和更新集群。它是一種端到端的方法，可以簡化 Kubernetes 生命周期的重復(fù)性任務(wù)，同時在統(tǒng)一的基礎(chǔ)架構(gòu)中保持一致性和可重復(fù)性。

Cluster API 的主要目標(biāo)是使集群生命周期管理變得枯燥。API 和可擴展性模型有一個成熟的生產(chǎn)記錄；隨著時間的推移，Cluster API 的目標(biāo)是進一步鞏固基礎(chǔ)，并建立抽象，以簡化終端用戶的體驗。

詳情見^[2]

Linkerd 2.11 發(fā)布

Linkerd 2.11 發(fā)布，此版本標(biāo)志著 Linkerd 向前邁進了一大步。Linkerd 2.11 引入了“策略”，這是一項期待已久的功能，允許用戶控制允許哪些服務(wù)相互連接和發(fā)送請求。此版本還引入了許多改進和性能增強，包括 gRPC 調(diào)用的重試、容器啟動順序問題的一般修復(fù)、更小的代理、更小的控制平面等等。

• 授權(quán)策略 Linkerd 的新服務(wù)器授權(quán)策略(server authorization policy)功能使您可以細粒度控制允許哪些服務(wù)相互通信。這些策略直接建立在 Linkerd 的自動 mTLS 功能提供的安全服務(wù)身份上。與 Linkerd 的設(shè)計原則保持一致，授權(quán)策略以可組合的 Kubernetes 原生方式表達，這種方式只需最少的配置，就可表達廣泛的行為。
• 重試帶有正文的 HTTP 請求 重試失敗的請求是 Linkerd 提高 Kubernetes 應(yīng)用程序可靠性能力的關(guān)鍵部分。到目前為止，出于性能原因，Linkerd 只允許重試無正文請求，例如 HTTP GET。在 2.11 中，Linkerd 還可以重試帶有 body 的失敗請求，包括 gRPC 請求，最大 body 大小為 64KB。
• 容器啟動排序解決方法 Linkerd 2.11 現(xiàn)在默認確保 linkerd2-proxy 容器在 Pod 中的任何其他容器初始化之前準(zhǔn)備就緒。這是 Kubernetes 對容器啟動順序缺乏控制的一種解決方法，并解決了一大類棘手的競爭條件，即應(yīng)用程序容器在代理準(zhǔn)備就緒之前嘗試連接。
• 更小、更快、更輕
• 控制平面減少到只有 3 個部署。
• 由于高度活躍的 Rust 網(wǎng)絡(luò)生態(tài)系統(tǒng)，Linkerd 的數(shù)據(jù)平面“微代理”更小、更快。
• SMI 功能大部分已從核心控制平面中刪除，并移至擴展中。
• Linkerd 鏡像現(xiàn)在使用最少的“distroless”基礎(chǔ)鏡像。

詳情見^[3]

Cartografos 工作組推出云原生成熟度模型

Cartografos 工作組的第一個項目是創(chuàng)建云原生成熟度模型。這個小組的成員都圍繞著云原生和 Kubernetes 的發(fā)展歷程，分別撰寫了成熟度模型。其目標(biāo)是將這些模型結(jié)合起來，形成一個涵蓋整個云原生生態(tài)系統(tǒng)的全方位模型。

隨著成熟度模型的建立，該小組很快就發(fā)現(xiàn)，這個過程并不局限于技術(shù)。圍繞人、流程和政策有明確的主題，因為每一個主題都在采用云原生技術(shù)方面發(fā)揮著巨大的作用。

云原生成熟度的 5 個階段：

第 1 級：構(gòu)建。你有一個基線的云原生實施，并處于預(yù)生產(chǎn)狀態(tài)。

第 2 級：運營。云原生的基礎(chǔ)已經(jīng)建立，你正在轉(zhuǎn)向生產(chǎn)。

第 3 級：規(guī)模。你的能力正在增長，你正在為規(guī)模化定義流程。

第 4 級：改進。你正在改善整個環(huán)境的安全性、政策和治理。

第 5 級：優(yōu)化。你正在重新審視先前的決定，并監(jiān)測應(yīng)用程序和基礎(chǔ)設(shè)施的優(yōu)化。

詳情見^[4]

OpenEBS 3.0 發(fā)布

OpenEBS 3.0（請參閱發(fā)行說明^[5]）是旨在為更輕松地加入和接受社區(qū)貢獻奠定基礎(chǔ)的努力的結(jié)晶，使每個引擎運營商為未來的 Kubernetes 版本做好準(zhǔn)備，從而輕松管理和排除各種引擎的故障。

該版本功能增強包括：

• CStor 和 Jiva 的 CSI 驅(qū)動程序以及將卷遷移到更新的 CSI 驅(qū)動程序的工具。3.0.0 已棄用舊版供應(yīng)商，用戶需要盡快遷移到相應(yīng)的 CSI 驅(qū)動程序。
• 對現(xiàn)有 LocalPV 風(fēng)格的若干增強和新類型 LocalPV 的引入。
• Mayastor 的新控制平面正在開發(fā)中，其設(shè)計更能處理規(guī)模和彈性。
• 還包括用于 OpenEBS 的 kubectl 插件的初始版本和用于管理 OpenEBS 存儲和卷的 prometheus grafana mixin。

詳情見^[6]

開源項目推薦

Otomi^[7]

Otomi 是一個開源的基于 Kubernetes 的平臺，它提供了類似于 Linux 桌面環(huán)境的用戶界面，你可以像部署 Linux 中的軟件包一樣部署 Kubernetes 中的應(yīng)用。默認已經(jīng)集成了 Istio、Knative、Prometheus、Harbor、Keycloak、Nginx ingress、External-DNS、Cert-manager、Hashicorp Vault、Gatekeeper、Drone、Gitea 等項目，開箱即用。

Damon^[8]

Damon 是 Nomad 的一個終端用戶界面（TUI），可以用來管理 Nomad 的 Jobs、Deployments 和 Allocations 等資源。該項目目前還在持續(xù)增加新功能中。

Kdigger^[9]

kdigger 是 "Kubernetes digger" 的簡稱，是一個用于 Kubernetes 滲透測試的上下文發(fā)現(xiàn)工具。這個工具集成了多種插件，每個插件負責(zé)發(fā)現(xiàn)不同的上下文信息。例如：

$?kdigger?dig?dev
###?DEVICES?###
Comment:?16?devices?are?available.
+-------------+-------+----------------------+-----------------+
|?????MODE????|?ISDIR?|????????MODTIME???????|???????NAME??????|
+-------------+-------+----------------------+-----------------+
|?Lrwxrwxrwx??|?false?|?2021-10-11T07:32:14Z?|?core????????????|
|?Lrwxrwxrwx??|?false?|?2021-10-11T07:32:14Z?|?fd??????????????|
|?Dcrw-rw-rw-?|?false?|?2021-10-11T07:32:14Z?|?full????????????|
|?dtrwxrwxrwx?|?true??|?2021-10-11T07:31:54Z?|?mqueue??????????|
|?Dcrw-rw-rw-?|?false?|?2021-10-11T07:32:14Z?|?null????????????|
|?Lrwxrwxrwx??|?false?|?2021-10-11T07:32:14Z?|?ptmx????????????|
|?drwxr-xr-x??|?true??|?2021-10-11T07:32:14Z?|?pts?????????????|
|?Dcrw-rw-rw-?|?false?|?2021-10-11T07:32:14Z?|?random??????????|
|?dtrwxrwxrwx?|?true??|?2021-10-11T07:31:54Z?|?shm?????????????|
|?Lrwxrwxrwx??|?false?|?2021-10-11T07:32:14Z?|?stderr??????????|
|?Lrwxrwxrwx??|?false?|?2021-10-11T07:32:14Z?|?stdin???????????|
|?Lrwxrwxrwx??|?false?|?2021-10-11T07:32:14Z?|?stdout??????????|
|?-rw-rw-rw-??|?false?|?2021-10-11T07:32:14Z?|?termination-log?|
|?Dcrw-rw-rw-?|?false?|?2021-10-11T07:32:14Z?|?tty?????????????|
|?Dcrw-rw-rw-?|?false?|?2021-10-11T07:32:14Z?|?urandom?????????|
|?Dcrw-rw-rw-?|?false?|?2021-10-11T07:32:14Z?|?zero????????????|
+-------------+-------+----------------------+-----------------+

$?kdigger?dig?authorization
###?AUTHORIZATION?###
Comment:?Checking?current?context/token?permissions?in?the?"default"?namespace.
+---------------------------------+-----------------+----------------+----------+
|????????????RESOURCES????????????|?NONRESOURCEURLS?|?RESSOURCENAMES?|???VERBS??|
+---------------------------------+-----------------+----------------+----------+
|?selfsubjectaccessreviews.author?|?[]??????????????|?[]?????????????|?[create]?|
|?ization.k8s.io??????????????????|?????????????????|????????????????|??????????|
|?selfsubjectrulesreviews.authori?|?[]??????????????|?[]?????????????|?[create]?|
|?zation.k8s.io???????????????????|?????????????????|????????????????|??????????|
|?????????????????????????????????|?[/api/*]????????|?[]?????????????|?[get]????|
|?????????????????????????????????|?[/api]??????????|?[]?????????????|?[get]????|
|?????????????????????????????????|?[/apis/*]???????|?[]?????????????|?[get]????|
|?????????????????????????????????|?[/apis]?????????|?[]?????????????|?[get]????|
|?????????????????????????????????|?[/healthz]??????|?[]?????????????|?[get]????|
|?????????????????????????????????|?[/healthz]??????|?[]?????????????|?[get]????|
|?????????????????????????????????|?[/livez]????????|?[]?????????????|?[get]????|
|?????????????????????????????????|?[/livez]????????|?[]?????????????|?[get]????|
|?????????????????????????????????|?[/openapi/*]????|?[]?????????????|?[get]????|
|?????????????????????????????????|?[/openapi]??????|?[]?????????????|?[get]????|
|?????????????????????????????????|?[/readyz]???????|?[]?????????????|?[get]????|
|?????????????????????????????????|?[/readyz]???????|?[]?????????????|?[get]????|
|?????????????????????????????????|?[/version/]?????|?[]?????????????|?[get]????|
|?????????????????????????????????|?[/version/]?????|?[]?????????????|?[get]????|
|?????????????????????????????????|?[/version]??????|?[]?????????????|?[get]????|
|?????????????????????????????????|?[/version]??????|?[]?????????????|?[get]????|
|?apiservices?????????????????????|?[]??????????????|?[]?????????????|?[list]???|
|?namespaces??????????????????????|?[]??????????????|?[]?????????????|?[list]???|
|?apiservices.apiregistration.k8s?|?[]??????????????|?[]?????????????|?[list]???|
|?.io?????????????????????????????|?????????????????|????????????????|??????????|
|?namespaces.apiregistration.k8s.?|?[]??????????????|?[]?????????????|?[list]???|
|?io??????????????????????????????|?????????????????|????????????????|??????????|
+---------------------------------+-----------------+----------------+----------+

Istio 運維實戰(zhàn)^[10]

通過將微服務(wù)中原本在 SDK 中實現(xiàn)的應(yīng)用流量管理、可見性、通信安全等服務(wù)治理能力下放到一個專門的“服務(wù)網(wǎng)格”基礎(chǔ)設(shè)施中，Istio 解開了微服務(wù)的服務(wù)治理需求和業(yè)務(wù)邏輯之間的代碼、編譯、部署時機等的耦合，讓微服務(wù)真正做到了承諾的“按需選擇開發(fā)語言”，“獨立部署升級”等能力，提升了微服務(wù)開發(fā)和部署的敏捷性，釋放了微服務(wù)模式的生產(chǎn)力。

然而，“服務(wù)網(wǎng)格”這一基礎(chǔ)設(shè)施的引入也給整個微服務(wù)的運維技術(shù)棧帶來了新的挑戰(zhàn)。對于運維同學(xué)來說，Istio 和 Envoy 的運維存在著較陡的學(xué)習(xí)曲線。TCM（Tencent Cloud Mesh）團隊是業(yè)內(nèi)最早一批接觸服務(wù)網(wǎng)格技術(shù)的人員之一，有著大量 Istio/Envoy 故障排查和運維經(jīng)驗。本電子書記錄了 TCM 團隊從大量實際案例中總結(jié)出來的 Istio 運維經(jīng)驗，以及使用 Istio 的最佳實踐，感興趣的可以拜讀一下。

文章推薦

粘性會話是如何破壞 K8s 中的彈性伸縮的^[11]

通常我們認為，彈性伸縮和負載均衡是幾乎沒有關(guān)聯(lián)的，但本文作者偶然發(fā)現(xiàn)了 AWS 應(yīng)用負載平衡器（ALB）的問題，粘性會話會影響到負載均衡和彈性伸縮之間的關(guān)系。本文探討了背后的原因及其解決方案。

使用 eBPF 破解 Linux 內(nèi)核^[12]

本文旨在從一個漏洞開發(fā)人員的角度對 eBPF 進行詳細介紹。簡單地說，eBPF 為用戶模式的應(yīng)用程序提供了一種在內(nèi)核中運行代碼的方法，無需編寫內(nèi)核模塊。相比于內(nèi)核模塊，使用 eBPF 的好處是易于使用、穩(wěn)定且安全。

引用鏈接