「K8S 生态周报」内容首要包括我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。
咱们好，我是张晋涛。
Apache APISIX Ingress v1.5.0 发布
现在 Apache APISIX Ingress controller 项目现已进入了 v1.5 的发布窗口，之前现已发布了 1.5.0-rc1 版别，现在发现的一些 bug 现已得到修正，咱们现已方案发布 v1.5.0 的正式版别了。
待投票流程结束后，将会有正式的公告和对应的 Release 发布。
间隔上一个特性版别 v1.4.0 发布现已过去了将近 7 个月的时间，这期间咱们进行了大量的开发作业，有 155 次提交和 32 位贡献者参加，感谢咱们的参加让这个版别有了很大的不同。
这里我列一些首要的变化，后续还会有专门的发版公告和特性解读文章等。
在这个版别中，正式将一切 CRD 资源的 API version 升级到了 v2 stable ，这也标志着用户运用起来会愈加的便利和一致，一起这些资源也现已过多个版别迭代和用户在出产环境的运用，达到了足够稳定的等级。
此外，在这个版别中供给了对 Gateway API 的支撑，不过此特性现在尚处于实验性质，默许不敞开，用户能够经过为它传递 enable_gateway_api=true 的装备项来敞开此能力。在下个版别中咱们将引进 Gateway API 项目的一致性测验，来保证咱们的完成与 Gateway API 项目的一致性。这样做的好处在于但凡经过了 Gateway API 一致性校验的完成，均可进行互相替换，不会存在锁定的情况。而且在搬迁的过程中，也能够保证装备的兼容性。
Apache APISIX Ingress controller 项目是支撑多种装备方法的，无论运用 CRD 的方法，或许运用 Kubernetes 中原生的 Ingress 资源都是能够的。但在之前版别中，关于 Ingress 资源来说，想要运用 APISIX 供给的 plugin 能力，就必须先完成一个对应的 annotation，这种方法可扩展能力很差。
在这个版别中，咱们为 Ingress 资源供给了一个新的 annotation 答应一切的 Ingress 资源能够直接运用 APISIX 所供给的 70+ 种 plugin 的能力，这关于一些运用开源的仅支撑装备 Ingress 资源的用户而言，对错常有用的。
除掉这些新功用外，现在无论是开源项目的维护者，还是运用者，都在活跃的关注供应链安全。在 Apache APISIX Ingress controller 中，咱们也升级了它运用的 Golang 版别，以及一切依靠的模块均升级到了最新版别，而且借助 GitHub 的 Dependabot 进行依靠的周期性扫描和更新，尽可能的供给安全可信的软件。
这里我先介绍这么多，咱们假如对此项目感兴趣，欢迎在 GitHub 加个 star github.com/apache/api…
发布流程未结束前，也可直接从最新的代码中构建镜像测验运用。
Wasmtime v1.0 正式发布
Wasmtime 是一个快速且安全的 WebAssembly 运转时，是 Bytecode Alliance （非营利安排）下的项目。
字节码联盟是一个非营利安排，致力于创立安全的新软件根底，树立在WebAssembly和WebAssembly 体系接口 (WASI)等标准之上。
字节码联盟致力于树立一个功用强大、安全的渠道，让应用程序开发人员和服务供给商能够自信地在任何根底设施、任何操作体系或设备上运转不受信任的代码，并运用数十年来在 Web 浏览器中的经历。
咱们的愿景是为一切渠道树立一个默许安全的 WebAssembly 生态体系。
关于 WebAssembly 的具体介绍，并不是此处的要点，推荐能够看看 MDN 的 WebAssembly 文档 进行了解。
Wasmtime 的言语支撑现在是有限的，其间最受支撑的言语是 Rust。此外，多种言语都支撑嵌入 Wasmtime，比方 Rust、C、Python、C#、Go 和 Bash 等。
以下我运用 Rust 来快速的介绍下 Wasmtime 的运用。
首先在安装完 Rust 和 Wasmtime 的环境后，写一个最简略的 hello.rs
fn main() {
println!(“Hello, Wasmtime!”);
}
然后进行编译和运转即可：
➜ ws rustup target add wasm32-wasi
info: component ‘rust-std’ for target ‘wasm32-wasi’ is up to date
➜ ws rustc hello.rs –target wasm32-wasi
➜ ws wasmtime hello.wasm
Hello, Wasmtime!
能够看到非常简略，当然你也能够挑选运用 cargo new 的方法创立个新项目来进行运用，此处仅做为示例。
来自 Fastly 的工程师说到，在一年多以前就能够将 Wasmtime 称为出产就绪了，之所以没有这样做，是希望能在正式宣告它出产就绪前，能在出产中稳定
运转 Wasmtime 很长一段时间。
此事与 K8s 生态比较相关的一个重要内容是，Microsoft 在 Azure Kubernetes （AKS）服务中供给了一个预览版功用：
答应创立具有 WASM/WASI 运转时的节点池，并运转 WASM 应用程序 。当然，此处能够运用的 WASM 运转时就是 Wasmtime 。
期待后续 WebAssembly 生态在云原生领域中的开展！
上游进展
Add auth API to get self subject attributes by nabokihms Pull Request #111333 kubernetes/kubernetes
这是 KEP-3325: Self subject attributes review API 完成的一部分。
咱们想必都知道，Kubernetes 中并没有 User（用户）的资源，可是 Kubernetes 中有权限校验的方法，比方咱们常用到的运用 x509 证书进行用户权限相关的校验，或许
经过外部的 OIDC 和 webhook 等进行校验。
此功用实际上是为了增加一个新的接口，以便于用户身份经过校验后，获取其所具有的特点。这样就能够简略的经过增加一个 kubectl auth whoami 的指令，来了解当时用户的相关信息了。
这功用比较类似于咱们做 OAuth 的时分，可能会做个 UserInfo 之类的接口，用来检查用户相关的特点。
该功用是经过在 authentication.k8s.io Group 下增加了 SelfSubjectReview 资源来完成的，具体如下：
// SelfSubjectReview contains the user information that the kube-apiserver has about the user making this request.
// When using impersonation, users will receive the user info of the user being impersonated.
type SelfSubjectReview struct {
metav1.TypeMeta json:",inline"
// Standard object’s metadata.
// More info: git.k8s.io/community/c…
// +optional
metav1.ObjectMeta json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"
// Status is filled in by the server with the user attributes.
Status SelfSubjectReviewStatus json:"status,omitempty" protobuf:"bytes,2,opt,name=status"
}
// SelfSubjectReviewStatus is filled by the kube-apiserver and sent back to a user.
type SelfSubjectReviewStatus struct {
// User attributes of the user making this request.
// +optional
UserInfo v1.UserInfo json:"userInfo,omitempty" protobuf:"bytes,1,opt,name=userInfo"
}
此功用在 v1.26 版别开始引进，并作为 Alpha 特性供给，可经过 APISelfSubjectReview feature gate 控制是否启用。
一起，本次也在 kubectl 中增加了 kubectl alpha auth whoami 子指令，可直接检查当时用户的相关特点信息。
Limit redirect proxy handling to redirected responses by liggitt Pull Request #112526 kubernetes/kubernetes
在上一篇 《K8S 生态周报| Kubernetes 爆出全版别缝隙》 中，
我曾介绍过 CVE-2022-3172 缝隙相关的信息。
上游中的修正方法是供给了一个选项 –aggregator-reject-forwarding-redirect=true 来设置拒绝跟随重定向，防止 SSRF 。
但一起该修正也引进了新的问题，因为该修正仅判断了 HTTP Code 是否在 300～399 ，但这是个不完整的假设，并非一切的 3xx 状况码都是重定向，
比方 304 Not Modified 表示无需再次传输恳求的内容。
所以本次的修正额定增加了对 Location Header 的判断。如下：
diff –git a/staging/src/k8s.io/apimachinery/pkg/util/proxy/upgradeaware.go b/staging/src/k8s.io/apimachinery/pkg/util/proxy/upgradeaware.go
index a3a14241cc6..278ed089d95 100644
— a/staging/src/k8s.io/apimachinery/pkg/util/proxy/upgradeaware.go
+++ b/staging/src/k8s.io/apimachinery/pkg/util/proxy/upgradeaware.go
@@ -263,7 +263,7 @@ func (h *UpgradeAwareHandler) ServeHTTP(w http.ResponseWriter, req *http.Request
oldModifyResponse := proxy.ModifyResponse
proxy.ModifyResponse = func(response *http.Response) error {
code := response.StatusCode
-
if code >= 300 && code <= 399 {
-
if code >= 300 && code <= 399 && len(response.Header.Get("Location")) > 0 { // close the original response response.Body.Close() msg := "the backend attempted to redirect this request, which is not permitted"
此修正也会被 cherry-pick 到其他的分支中，并将在下个版别进行发布。
Removal of GlusterFS code from the repo by humblec Pull Request #112015 kubernetes/kubernetes
在之前的 「K8S 生态周报」中我曾介绍过，在 v1.25 中将树内的 GlusterFS plugin 标记为废弃，并建议搬迁至运用 CSI ，
现在这些插件现已被完全删除了。
欢迎订阅我的文章公众号【MoeLove】
来历： K8S 生态周报| Kubernetes 新增 auth whoami 子指令，可获取用户特点
