「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s 生态」 ( https://zhuanlan.zhihu.com/container )。

1

Conftest 正式加入 Open Policy Agent 项目

conftest ( https://www.conftest.dev/ ) 是一个非常实用的 CLI 工具，可以用于测试/验证配置文件是否符合预期。例如，可以通过如下内容来定义规则：

package main
deny[msg] {  input.kind = "Deployment"  not input.spec.template.spec.securityContext.runAsNonRoot = true  msg = "Containers must not run as root"}
deny[msg] {  input.kind = "Deployment"  not input.spec.selector.matchLabels.app  msg = "Containers must provide app label for pod selectors"}

使用此规则去检查一个未符合预期规则的 Deployment 的配置文件：

(MoeLove) ➜  conftest test deployment.yamlFAIL - deployment.yaml - Containers must not run as rootFAIL - deployment.yaml - Deployments are not allowed
2 tests, 0 passed, 0 warnings, 2 failures

就会看到有相应的检查结果了。

至于 OPA ( https://www.openpolicyagent.org/ ) 它是一个策略引擎，提供了一种非常灵活的方式来声明策略。

conftest 正式加入 OPA 项目，可以更好的让彼此进行集成和组合使用。并且，在 conftest 加入 OPA 项目后，会有部分功能从 conftest 移至 OPA，让 conftest 更间简便。期待后续的发展。

2

Traefik v2.2.7 发布

Traefik v2.2.6 中，修复了一个安全问题。在校验使用域前置的 TLS 连接时，如果 Host 头与 SNI 不同的话，则 Traefik 将会返回 421 状态码。

此次 Traefik 发布的 v2.2.7 版本，主要是为了解决上述在 v2.2.6 中由于修复此安全问题而引入的 bug 。

现象是在 v2.2.6 版本中，如果为 Host 指定了非标准端口（443）的话，则 Traefik 会返回 421 状态码，从而导致连接异常。

v2.2.7 中解决办法也很简单，直接忽略掉 Host 中的端口，与 SNI 进行比较即可。

建议如果打算升级的话，直接升至 v2.2.7 ，避开 v2.2.6 版本。可通过 Release 页面 ( https://github.com/containous/traefik/releases/tag/v2.2.7 ) 下载使用。

3

NGINX Ingress Controller v1.8.0 发布

这里介绍的是 NGINX 官方的 Ingress Controller 项目（避免和社区的 Kubernetes NGINX Ingress Controller 搞混）。

此次版本中有几个非常值得关注的特性。

#1028 ( https://github.com/nginxinc/kubernetes-ingress/pull/1028 ) 新增了一种资源 Policy 。

Policy 资源允许你为 VirtualServer 资源添加访问控制，可作用于认证，限流和 WAF 之类的特性。由于此版本中是首次添加，目前只实现了基于 IP 的访问控制。例如，你可以通过下方的配置文件，来允许 10.0.0.0/8 的访问：

apiVersion: k8s.nginx.org/v1alpha1kind: Policy metadata:  name: allow-localhostspec:  accessControl:    allow:    - 10.0.0.0/8

#1019 ( https://github.com/nginxinc/kubernetes-ingress/pull/1019 ) 支持注入片段（ Snippets ）

使用 Snippets 允许你为 VirtualServer 配置注入一段原生的 NGINX 配置片段，用于覆盖默认配置。示例如下：

apiVersion: k8s.nginx.org/v1kind: VirtualServermetadata:  name: cafe  namespace: cafespec:  http-snippets: |    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;    proxy_cache_path /tmp keys_zone=one:10m;  host: cafe.example.com  tls:    secret: cafe-secret  server-snippets: |    limit_req zone=mylimit burst=20;  upstreams:  - name: tea    service: tea-svc    port: 80  - name: coffee    service: coffee-svc    port: 80  routes:  - path: /tea    location-snippets: |      proxy_cache one;      proxy_cache_valid 200 10m;    action:      pass: tea  - path: /coffee    action:      pass: coffee

但要注意的是，如果你使用此特性，我建议你在使用之前，清楚的理解自己配置的含义。因为用这种方式配置，会绕过 Ingress Controller 的校验过程。会比较危险。并且使用此特性，不够直观。但，却可以让你对 NGINX 有更强的控制能力。

更多关于此版本的信息，请参考其 RelaseNote ( https://github.com/nginxinc/kubernetes-ingress/releases/tag/v1.8.0 )

4

上游进展

#92986 ( https://github.com/kubernetes/kubernetes/pull/92986 ) 如果 CSI 驱动抛出 FailedPrecondition 错误，则停止重试对卷进行扩展；

#80917 ( https://github.com/kubernetes/kubernetes/pull/80917 ) 移植 deviceManager 到 Windows 容器管理中以支持 GPU 的访问。（这是一个很关键的特性）

欢迎订阅我的文章公众号【MoeLove】

ITPub博客

K8S 生态周报| NGINX Ingress Controller又添新特性

最新文章