TL;DR: 开放讨论的焦点是Kubernetes，由Pinax的Guillaume和Matthew主持。他们讨论了使用kind对Kubernetes应用程序进行测试、使用FluxCD初始化集群以及使用Helm和Flux部署Launchpad图表等话题。讨论还涉及将LXC容器桥接到Kubernetes以及使用Crossplane管理外部端点等内容。
大家好，欢迎阅览 Indexer Office Hours 会议纪要，第 180 场！
观看 GRTiQ 播客，与先驱企业家、联合创始人和投资者 Ben Huh 一起。
Ben 是 Cheezburger 取得巨大成功背后的远见卓识者，Cheezburger 是互联网上的轰动者，将meme和用户生成的内容转变为商业巨头。
重要存储库的最新更新
- sfeth/fireeth：新版本 v2.7.5：
- 修复了 set_sum 存储策略操作中的数据损坏，需要删除缓存;改进了开发模式请求的启动时间。
- Nethermind：新版本 v1.29.1 ：
- 此版本是强制性验证器升级，解决了 Linux 内存回归、OP Stack 同步性能问题和 Gnosis 链区块生产边缘情况。
- Avalanche：新版本 v1.11.12 ：
- 可选但强烈建议的更新，其中包含许多改进，包括 ACP-77 费用计算、OP 堆栈同步优化和增强的 P2P 处理;插件版本仍为 37。
有关不同客户端的信息
- Prysm：新版本：
- 5.1.1 版：
- 推荐的更新，默认使用选择退出标志打开实验性状态管理，并通过 libp2p 更新提高带宽稳定性。此版本弃用了 gRPC 网关，转而使用信标 API。
- 5.1.2 版：
- 修复了影响 v5.1.1 REST 模式验证程序和第三方集成的信标 API 流式处理事件终端节点中的紧急恢复问题;对于那些使用 beacon API 而不是 gRPC 的人来说至关重要。
- Teku：新版本 v24.10.2 ：
- 此版本是一个修补程序，用于解决影响使用版本 24.10.0 和 24.10.1 的 Windows 用户阻止 Teku 启动的问题。
索引器服务和点击代理（RS）：新版本发布：
- 索引器-tap-agent-v1.2.0 ：
- 改进了将回退移至跟踪器的错误处理。
- 通过并发 RAV 请求和使用 latest_rav 优化费用计算来增强性能。
- indexer-tap-agent-v1.2.1 ：
- 包括错误修复，以使用 INFO 作为日志的默认级别。
Matthew |Pinax 发布： Pinax 正在进行 Firehose 升级。
协议重要变更的最新更新
- Chiliz Chain 集成
Matthew |Pinax：Johnathan 很忙......适用于 Chiliz 的 EVM RPC
Johnathan |Pinax：Pinax 已经支持 Chiliz。Firehose 、Substreams 将很快受支持。
- chore（deps）：将 SECP256K1 从 4.0.3 升级到 4.0.4 #1063（open）
- 修复：为部署脚本添加了缺少的参数，并将 SubgraphService 的运行次数减少到 50 次 #1062（open）
- 修复（Horizon）：为 TAPCollector 部署添加了缺少的参数 #1061（closed）
继续！由Pinax的Guillaume和Matthew主持的Kubernetes办公时间的更详细。
- 使用 kind 测试 Kubernetes 应用程序
- 使用 FluxCD 引导集群
- 将 Helm 与 Flux 结合使用以部署 launchpad 图表
Guillaume：这周我将慢一点地演示。希望您有时间查看 Kubernetes IOH 演示代码库并尝试一下。如果有任何问题，欢迎询问。
作为上周的复习，此代码库是以简单方式使用 Kubernetes 的起点。生态系统正在向 Kubernetes 发展，因此部署它而不是一堆 Docker Compose 文件更具可扩展性。
Matthew Darwin |Pinax： Marc-André，有任何 k8s 问题。😉 （我看到你在问 Launchpad 问题）
Marc-André |Ellipfra： 我在听！寻找前沿链的解决方案。可能必须学习构建 Helm 图表并回馈社会。
chris.eth |GraphOps：谁伤害了你，你为什么选择 Kubernetes 来应对它？
Vince |Nodeify：我很快就会为这些做出贡献。🙂
Matthew Darwin |Pinax：Vince 和 Johnathan 希望能在这方面有所帮助。
kind 是一种使用 Docker 容器“节点”运行本地 Kubernetes 集群的工具。kind 主要用于测试 Kubernetes 本身，但也可用于本地开发或 CI。
Guillaume：kind 不是生产级的，但它对于以最简单的方式开发、尝试和部署 Kubernetes 集群非常有用。您唯一需要做的就是在您的机器上安装 Docker，然后它将创建控制平面、工作节点 — Docker 容器中的所有 Kubernetes 组件，您可以通过设置多个 Docker 容器来创建多个节点。然后，您可以在本地环境中复制整个集群，并且可以从同类集群中使用它来执行一系列操作，例如外部负载均衡、入口和本地 DNS。
在 Pinax，我们为服务建立了自己的 DNS 提供商，因此我能够使用 kind 在 kind 内部引导 DNS 基础设施，然后使用它来测试服务，然后我们可以将其部署到生产环境中。
设置集群非常简单 [12：09]。
一切都是从 tiltfile 部署的，你可以把它看作是一个 makefile，但专门针对 Kubernetes。这样，如果你有一个想要编码的应用程序，并且你想在集群内进行实时更新，你可以使用 tiltfile 重新加载和重新编译你的应用程序，并自动更新你的集群。
kind cluster 配置基本上只是一个 YAML 文件，你设置了很多东西。在视频 12：48 处观看。
观看 Guillaume 在 13：48 创建集群。
将为您的集群部署的工具：
- 控制器管理器
- Kube 调度器
- API 服务器
通常，它还会部署内部 DNS。kind 使用 Flannel 来执行容器网络接口 （CNI），该工具能够链接集群内的 Pod 和容器，因此，如果一个 Pod 想要向集群中运行的另一个 Pod 发送请求，它们需要能够相互通信，也称为 kube-dns 或 CoreDNS。
在这个演示中，我们请求禁用 CNI，因为我们不想使用 flannel。我们想使用 Cilium。
观看 15：40 从 tiltfile 部署的内容。
在此演示中，我们将 Flux 用于集群中的持续部署 （CD）。
集群等待 CNI 和本地存储预置程序，因为本地路径预置程序需要 CNI 才能在您的机器上预置存储。所以有了 tiltfile，我们部署了 Cilium，所以 Cilium 使用了 cilium-envoy， cilium-operator。部署后，CoreDNS 和本地路径配置程序将工作，因此您拥有一个完全可操作的 Kubernetes 集群。
Matthew：为什么要选择 Cilium？
Guillaume：因为 Cilium 可以做 cluster mesh，这是一种跨数据中心的集群之间提供服务的方式。这是我们在 Pinax 需要的，因为我们有多个数据中心，我们希望服务可以从一个集群访问到另一个集群，而无需使用某种速度很慢的 WireGuard 隧道。Cilium 不使用 WireGuard 隧道，它的核心使用 eBPF，因此它直接挂接到 Linux 内核中，您可以直接在内核中注入代码，以跨数据中心重新路由数据包。它比隧道更快、更灵活。
我认为在 Kubernetes 世界的这一点上，Cilium 就像 Kubernetes 和 CNI 的黄金标准。几乎每个云提供商都在转向 Cilium。
CJ |GraphOps：集群网格不是通过集群之间的隧道建立的吗？Cilium 可以使用 IPSec 或 WireGuard 来做什么？我认为是的，但可能是错的。
Guillaume：不确定，我已经有一段时间没有玩 cluster mesh 了。
Vince |Nodeify：您可以自动使用：Talos KubeSpan [学习使用 KubeSpan 跨网络安全地连接 Talos Linux 机器。自动魔术 WireGuard。
Matthew |Pinax：根据 Vince 的说法，一切都是 Talos。Abel |GraphOps 听起来像是 Vince 的未来演示。😉
AbelsAbstracts.eth |GraphOps：是的，先生，Vince 和我已经在谈判😎了，他将在 11 月 5 日发表演讲。🥳
还有已部署的 Flux。我们这里有一个命名空间：flux – system。
Flux 部署了一堆控制器：helm-controller、image-automation-controller 为您提供自动更新、image-reflector，它也是 image-automation-controller 的一部分——这两个控制器协同工作。
然后，您有 kustomize-controller，它允许您从自定义项创建部署。
你可以告诉通知控制器在有更新时在 Discord 或 Slack 上通知你。您可以将 Webhook 与 notification-controller 一起使用，以便您可以跟踪每个部署或是否有新版本的应用程序并发出警报。
源控制器拉取 GitHub 或 Helm 存储库或应用程序将使用的任何容器映象代码库，甚至是应用程序的存储位置。
我们选择 Pinax 的 Flux，因为从操作员的角度来看，它很容易。引导、使用和扩展都很简单，因为它变得简单且没有主见。它只做一件事：CD（持续部署），但它很容易扩展。您可以使用 Flux 创建具有多租户的多个集群。
还有 Argo，它类似于 Flux，但更注重一体化工具包，而不是能够为整个集群的不同部分扩展和使用不同的解决方案。Argo 的主要优点是其漂亮的 UI，而 Flux UI 是 kubectl 命令和工具。
您可以一起使用它们。假设您希望有 500 个聚类进行协调;您可以将 Flux 用于基础设施，然后使用 Argo 管理您的应用程序和租户。
Vince |Nodeify：您可以使用一个 Argo 实例管理 1000 个集群。
calinah |GraphOps：但你试过吗？因为光是想想我就头疼。
Vince |Nodeify：我在 homelab 中做了三个，这很好。1,000 听起来很糟糕。
Matthew Darwin |Pinax：需要更多硬件。
Vince |Nodeify：我宁愿让集群更强大，也不愿让另一个更强大，哈哈。但对 prod、stage、dev 有好处。
calinah |GraphOps：取决于用例——在某些时候，更强大是不够的。拥有像 Argo 这样的东西来管理多个集群很棒——只要我们谈论的不是 100 个集群。
Vince |Nodeify：是的，特别好，因为它可以将内容抽象为项目，因此您可以管理同一集群中的团队，并查看哪些团队在做什么，等等，对于那些不想担心扩展并且喜欢花钱少做事的人，还有 Akuity：适用于 Kubernetes 的端到端 GitOps 平台。部署 Argo，具有良好的计算能力。
calinah |GraphOps：你玩过 Akuity 吗？
Vince |Nodeify：是的，我将在我自己的基础设施上使用它。
从用户或开发人员的角度来看，此存储库用于协调集群和集群中运行的应用程序。所以 Flux 用它来协调集群中除了 CNI（即 Cilium）之外的基本上所有正在运行的东西。
请跟随 Guillaume 在 24：50 解释存储库的结构和不同部分。
您可以使用 Helm 图表来部署 Graph Node，并且可以将其用作 Flux 的一部分。因此，如果您查看 Graph Node 自定义，它将尝试部署此目录中运行的所有内容，例如应用程序、Launchpad、Graph Node。它将获取此自定义并创建命名空间 graph-node（如果尚不存在），然后将此文件部署到此处，即 graph-node.yaml，它基本上是一个 Helm 存储库。
Helm 存储库的名称是 graphops，它每 12 小时从存储库中提取一次，以便所有 launchpad 图表保持最新状态。
然后我们创建 HelmRelease，它将 Helm Chart 部署到集群中的应用程序中。我们正在部署一个名为 graph-node 的 Helm 图表。
Vince |Nodeify：KubeVision 为您提供了一个可以看到您的集群的 Kube ChatGPT。🙂
无限 59 美元/月，少了一件需要担心的事情，Kargo 处理促销非常好。
- 宣布 KubeVision with AI 发布：提高 Akuity 平台上的可见性
- Kargo 仓库
calinah |GraphOps：这看起来不错，但似乎只有在你使用 Akuity 并且无法独立获得它时才可用？
Vince |Nodeify：Kargo 应该与任何 Argo 一起使用，但不确定 KubeVision。
Matthew：即使你不同意我们在 Pinax 的所有配置，也许它会给你一些其他的想法，并提出问题或需要考虑的事情。我很想更多地了解其他团队或人员围绕 Kubernetes 所做的工作。
Vince |Nodeify：Reloader 很棒，请告诉我，你们都在使用 GitOps，无论口味如何，那些吃过药的人。
- CJ |GraphOps：顺便说一句，GitOps +1，Git 确实很好地完成了整个版本控制部分。
Marc-André |Ellipfra：我肯定了解了我可以用我的集群做的其他事情。谢谢你。
Vince |Nodeify：如果你在 Argo 上，请查看其他可用的东西。很多工具和插件。
Marc-André |Ellipfra：是的，我可能只用了 1% 的 Argo CD。
Vince |Nodeify：这对我来说在索引领域变得不错：Sync Phases 和 Waves。
chris.eth |GraphOps：Launchpad 中所有官方支持的 Chart
- Graph 节点
- The Graph网络索引器（indexer-service、indexer-agent、tap-agent 等）
Pierre | Chain-Insights.io：使用 Lens 而不是 K9s （Lens IDE for Kubernetes）。
stake-machine.eth 中：我知道 Lens，但仍然......🙂 你买不到真爱。
Marc-André |Ellipfra：是的，对于我们的非 Kubernetes 朋友来说，你不需要从 Pinax 正在做的事情这样全面的事情开始。您可以从使用云服务的超小规模开始，然后迁移到您自己的硬件。
Vince |Nodeify：此外，如果您有多个集群，kubie 是必须的。让生活变得轻松。kubectx
stake-machine.eth：Proxmox
Matthew：现在在 Pinax，我们处于 Kubernetes 中有东西而 Kubernetes 中没有的东西的状态，现在我们需要将 Kubernetes 的东西与非 Kubernetes 的东西联系起来。所以，我们正在研究一个全新的事情：我们如何在不停机的情况下从旧式过渡到新式。
我们所有的东西最初都部署在 LXC 容器中。实际上，大多数东西仍然在 LXC 中，比如 Proxmox，现在我们正在部署 Kubernetes 集群，我们正在考虑将控制平面节点放在 Proxmox 中。
Guillaume，在将 LXC 容器桥接到 Kubernetes 方面，您考虑了什么？
Guillaume：好吧，我现在要打破这个独家新闻，因为它从昨天开始工作。我们现在正在做的是在 Kubernetes 内部拥有自己的 DNS 提供商，我们使用 Crossplane 来配置和监控集群外部的一些外部端点。我们有一堆在 Kubernetes 之外的 LXC 中运行的应用程序，但我们希望使用 Kubernetes 内部的基础设施 DNS 提供商来提供这些服务，这样我们就可以保留这些服务，但在某个时候将它们迁移到集群中......或者没有。我们希望能够自由地选择我们做什么，因此我们使用 Crossplane 创建带有终端节点的服务，这些服务可以连接到在集群外部运行的东西，但仍然能够从 GitOps 和集群本身内部协调运行在外部的服务。
Pierre |Chain-Insights.io 发布： KubeVirt
Guillaume：是的，KubeVirt 也真的很有趣。我已经尝试了相当多的方法来设置 Kubernetes 集群，它非常棒。如果您想在 Kubernetes 中管理一些 VM，则可以使用 KubeVirt 将 VM 作为 Kubernetes Pod 进行扩展、升级和管理。
John K.：不是 K8s，但我有一个关于 tap-agent 的问题。我需要将此地址添加到 [tap.sender_aggregator_endpoints] 配置中吗？
Ana回答说：您无需添加该地址，这只是某人设置的附加网关。目前，唯一官方支持的网关是Edge & Node网关，但是tap-agent将显示存在的任何网关。
（相关专业名词、注释、代码库、超链接等请关注博客阅读原文查找）
#web3数据索引 #区块链开发 #索引器 #TheGraph
All Comments