共计 4687 个字符，预计需要花费 12 分钟才能阅读完成。
「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】
