「K8S 生态周报」内容次要蕴含我所接触到的 K8S 生态相干的每周值得举荐的一些信息。欢送订阅知乎专栏「k8s生态」。

大家好,我是张晋涛。

因为上周在假期,所以没有推送新的文章。大家的假期过的如何呢?

我有一个托管在 Pipedream 上的 workflow ,
该 workflow 订阅了我博客的 RSS, 当有新文章公布后,会调用 Bitly 生成短网址,而后主动发推。
失常状况下,它会放弃 RSS 的解决状态,仅解决增量数据。

然而在两周前某天早上醒来,我收到一堆的告警和音讯揭示,发现该 workflow 工作异样了,它将我的很多历史博客都推送了一遍。
(事实上,幸好触发了 Bitly 的申请限度,否则它的确会把我的所有博客都推一遍)

通过与该司的 Co-founder 沟通,问题呈现的起因是该平台呈现了一些故障,导致 RSS 解决的状态数据失落了。所以会将 RSS 的工作从新进行解决。

问题呈现的起因和影响面这和我关系不大,晓得在个论断曾经足够了。简略说下如何防止后续再呈现这种状况。

该平台提供了一个 Data Stores 的服务,用于进行一些长久化数据的存储。所以后续的解决方法就是抉择了 guid 作为惟一值,存储在该服务中。
该平台首选反对的语言是 NodeJS,所以也比较简单,如下配置即可。

export default defineComponent({  props: {    db: {      type: "data_store",      label: "RSS item keys",    }  },  async run({ steps, $ }) {    const { guid } = steps.trigger.event    // Exit early if no GUID found    if (!guid) return $.flow.exit("No GUID found")    // Exit early if key is found    const key = await this.db.get(guid)    if (key) return $.flow.exit("GUID already found")    // Else set and continue    await this.db.set(guid, true)  },})

另外为了避免再反复推送,所以在复原 workflow 运行前,
我创立了一个新的 workflow,应用了 RSS 和上述的解决步骤,对数据做了下预热,确保曾经都存储到了 Data Stores,并且能按预期工作。

既然 Data Stores 是一个长久化服务,这应该不至于再出问题了吧(笑

Prometheus v2.39 正式公布

Prometheus v2.39 近期正式公布了,这个版本中做了大量的资源优化和减少了一些新的个性。我聊一下我感觉比拟要害的局部。

大幅度优化内存资源用量

在这个版本中 @bboreham 提交了一系列的 PR 来进行资源用量相干的优化,比方:

  • Optimise relabeling by re-using memory by bboreham · Pull Request #11147 · prometheus/prometheus
  • tsdb: turn off transaction isolation for head compaction by bboreham · Pull Request #11317 · prometheus/prometheus
  • tsdb: remove chunk pool from memSeries by bboreham · Pull Request #11280 · prometheus/prometheus
  • tsdb: remove chunkRange and oooCapMax from memSeries by bboreham · Pull Request #11288 · prometheus/prometheus
  • WAL loading: check sample time is valid earlier by bboreham · Pull Request #11307 · prometheus/prometheus

此外还有一些PR,我就不一一列举了。总结来说是改良了 relabeling 中的内存重用,优化了 WAL 重放解决,从 TSDB head series 中删除了不必要的内存应用,
以及敞开了 head compaction 的事务隔离等。

只管这些优化会依据不同的 Prometheus 应用状况造成不同的实际效果,
但在 Grafana Labs 的一个大型 Prometheus 实例中能够看到,通过降级最新的版本,内存用量缩小了一半左右。

试验个性:减少对无序样本的反对

  • Add out-of-order sample support to the TSDB by jesusvazquez · Pull Request #11075 · prometheus/prometheus

这个个性的确能够多聊一点。咱们晓得对于 Prometheus 而言,它默认应用了本人的 TSDB,并且有两个次要的限度:

  • 在给定的工夫序列中,只能以基于工夫戳的程序附加样本,因而当雷同 series 已有较新的样本时,不能摄取较旧的样本;
  • 在整个 TSDB 中,最多只能追加比 TSDB 中最新样本早 1 小时的样本(这里假如默认是 2h 的 block 设置);
尽管这通常实用于实时监控用例,但有时您可能有指标生产者须要摄取无序数据或超过一小时的数据。这可能是因为生产者并不总是连贯到网络,须要在发送数据之前在更长的工夫内聚合数据,或者相似的限度。在技术层面上,此类生产者能够以度量规范公开格局公开自定义客户端工夫戳,或者应用 Prometheus 中的近程写入接收器来笼罩 Prometheus 本人的抓取工夫戳。然而,Prometheus 的 TSDB 通常不会在这些样本呈现故障或太旧时承受这些样本。

当初增加个这个试验个性是容许生产者发送无序数据,或者超 1 小时的数据(和上述假如统一)。能够通过 out_of_order_time_window 配置项进行配置。
它承受的是一个工夫周期的配置。比方能够进行如下配置:

tsdb:  out_of_order_time_window: 12h

示意容许无序数据的工夫窗口为 12h 。

然而请留神,只管这个个性不须要额定的开启,但它的确是试验个性,后续有可能还会进行调整,请按需进行应用。

此外就是一些小的个性批改了,当然顺便一说,这个版本依然还是连续了之前的习惯,在公布了 v2.39.0 后,很快就公布了 v2.39.1 版本来进行 bugfix 。
如果你要对生产环境中的 Prometheus 降级,倡议先做个测试,跑几天看看成果。

Istio 正式成为 CNCF 孵化我的项目

其实在之前的 「K8S 生态周报」中,我始终都有同步 Istio 进入 CNCF 相干的信息和停顿,这个事件的确耗时比拟长了。
可能曾经一年多了?但印象较深的最近一次的正式布告应该是 IstioCon 2022 上的 keynote 。

Istio 正式成为 CNCF 孵化我的项目,意味着其将会应用 CNCF 的治理模式,社区能够更加多样化的倒退。
当然,当前在一些 CNCF 的会议上来分享 Istio 也就变的很天然了,(比方咱们正在做的 APISIX 作为 Istio 数据面的 Service Mesh 我的项目)

期待它的后续倒退!

Cilium v1.13.0-rc1 公布

这里我简略介绍下比拟重要的一些个性:

  • add support for k8s 1.25.0 by aanm · Pull Request #20995 · cilium/cilium

减少了对 Kubernetes v1.25 的反对,一些文档,测试和依赖等。

  • Add IPv6 BIG TCP support by NikAleksandrov · Pull Request #20349 · cilium/cilium

如有此方面需要的小伙伴能够查看 PR 的形容,还是比拟具体的,这里就不开展了。

  • Add preliminary support for SCTP by DolceTriade · Pull Request #20033 · cilium/cilium

减少了局部 SCTP 协定的反对,蕴含如下方面:

  • Pod 和 Pod 之间的交换
  • Pod 和 Service 之间的交换,这里须要留神,因为不反对对 SCTP 包的端口该写,所以定义 Service 的时候, targetPort 必须与 port 保持一致,否则包会被抛弃
  • Pod 与 Pod 之间通过减少了 SCTP 流量的网络策略

不反对的局部是:

  • Multihoming
  • pod-to-VIP 的策略
  • KPR
  • BPF masquerading
  • Egress gateway
  • Add trace points for socket-LB by aditighag · Pull Request #20492 · cilium/cilium

对用户的体现上是减少了一个 --trace-sock 的参数,默认是开启的。

  • ingress: Support shared load balancer mode by sayboras · Pull Request #21386 · cilium/cilium

在之前 Cilium 会为每个 Ingress 资源创立一个 LoadBalancer service ,但这个形式并不高效。
所以当初引入了两种模式。

一种就是以后的实现,称之为 dedicated mode ,每个 Ingress 一个 LB。

另一种是新增的,称之为 shared mode ,所有的 Ingress 共享一个 LB。如果呈现 path/host 抵触,申请将被散发到各个后端。

上游停顿

  • kubelet: append options to pod if there are multi options in /etc/resolv.conf by pacoxu · Pull Request #112414 · kubernetes/kubernetes

以后 kubelet 创立 Pod 的时候,如果 /etc/resolv.conf 中存在多行 options 配置,则只取最初一行。

例如 /etc/resolv.conf 蕴含的配置如下:

options timeout:1 options attempts:3

则 Pod 中的 /etc/resolv.conf 只蕴含如下内容

options attempts:3

但事实上即便在 /etc/resolv.conf 中配置多行 options ,DNS 也是能够失常工作的。所以以后的 kubelet 行为就不统一了。

通过这个 PR, 会将主机的 /etc/resolv.conf 中的多行配置合并为一行。如果还是下面的例子,则 Pod 内看到的就是如下内容了.

options timeout:1 attempts:3

略微聊点其余的,这个修复其实在 fix resolv.conf multi options cover issue by xiaoanyunfei · Pull Request #91052 · kubernetes/kubernetes
就尝试做过了,并且是在 2 年多之前。

未合并的起因是因为之前 reviewer 说没有看到 SPEC 形容这种多行的行为,所以不确定这是否能工作,之后便关掉了。

事实上本次的修复,同样也没有找到任何的 SPEC 形容这个行为,只不过是翻了 musl libc 的代码,发现它能够对这种行为进行反对,所以 reviewer 也就承受了。

我想要说的是,在开源我的项目/社区中进行奉献或者合作的时候,每个人都能够有一些特定的理由去承受或者回绝一些个性,但不存在相对。(如果你发现某个开源我的项目/社区是这样的,那阐明该我的项目并不衰弱)

如果你是一个贡献者,
并且你认为你所做的批改是有意义的,那么你须要更被动的去推动该事件,而不是对方给出意见后就默默承受。

谐和有善并不意味着默默承受全副,该 battle 的时候就应该据理力争,管它是谁

当然,记得要有理有据

好了,以上就是本次的全部内容,咱们下期再见!


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