往期回顾
Kubernetes学习周报（第六期 ）:K8S API 实用指南；Etcd灾难恢复方案；K8S Gateway API介绍
Kubernetes学习周报（第五期 ）: K8S隐藏的“OOM 终止”问题；一个K8S命令引发的悲剧；Cilium的BGP功能
Kubernetes学习周报（第四期 ）: K8S中使用 Wireshark；K8S安全清单；如何缩小Docker镜像
Kubernetes学习周报（第三期 ）: Kubernetes 健康检查，如何使用 runc 生成容器
Kubernetes学习周报 : 一周好文推荐，K8s 网络请求分析，多集群 Kubernetes 的 7 个注意事项
Kubernetes容器运行时CRI接口介绍
https://kubernetes.io/blog/2024/05/01/cri-streaming-explained/
本文探讨了 Kubernetes 容器运行时接口 （CRI） 及其在协助 kubelet 和容器运行时之间的通信方面的作用。它深入探讨了三个关键远程过程调用 （RPC） 的历史和功能：Exec、Attach 和 PortForward，并解释了它们的协议定义和实现。本文讨论了这些 RPC 提供的灵活性、向使用 WebSocket 的转变，以及在 Kubernetes 和容器运行时（如 CRI-O）中增强和维护这些功能的持续努力。
关键点
- Kubernetes 容器运行时接口 （CRI） 使用 gRPC 服务器将 kubelet 连接到容器运行时
- 本文重点介绍 Exec、Attach 和 PortForward RPC，详细介绍了它们的独特功能和协议定义
- Exec 允许在容器内执行命令，Attach 流处理输出，PortForward 允许从主机到容器的端口转发
- 这些 RPC 的原始设计早于 Kubernetes 增强提案 （KEP），最初与 Docker 和 rkt 相关联。
- CRI 设计允许运行时灵活地实现流服务器方法，支持功能而无需修改 CRI。
- Exec 和 Attach 协议存在于多个版本中，并努力用 WebSockets 替换 SPDY。
- kubelet 中的流式服务器实现概述了容器运行时要实现的运行时接口。
- PortForward 需要输入容器的网络命名空间和流数据，没有像 Exec 或 Attach 这样的简单协议。
- 未来的工作包括在运行时和客户端中支持 WebSockets，CRI-O 将探索用于处理流会话的 conmon-rs。
使用Kluctl管理集群API
https://kluctl.io/blog/2024/03/13/cluster-api-kluctl/
本文提供了一个关于使用 Kluctl 管理基于 Kubernetes 集群 API 的集群的综合教程。它涵盖了 Kluctl 的安装和设置、基本项目结构、工作负载集群的部署以及使用模板进行高效的配置管理。本文还比较了 Kluctl 和 ClusterClass，强调了 Kluctl 在集群管理方面的灵活性和优势。
关键点
- 介绍如何在网站上使用第三方 cookie 和脚本来增强功能和用户体验。
- Kubernetes 演变为具有自定义资源定义的 API 平台以及集群 API 的诞生概述。
- 使用 Kubectl、Helm、Flux、ArgoCD 和 Kluctl 等工具管理 Kubernetes 资源的说明。
- Kluctl 是 Kubernetes 的通用部署工具，允许通过 CLI 或 GitOps 控制器进行复杂的部署。
- Kluctl 的功能包括管理多个工作负载集群、模板、部署项目和变量源。
- Kluctl 的安装说明和使用 CAPD 设置本地 Kind 集群。
- 初始化集群 API 并创建管理集群的步骤。
- 解释 Kluctl 项目的基本结构以及 .kluctl.yaml 和 deployment.yaml 文件的使用。
- 有关使用 Kustomize 创建工作负载群集并使用 Kluctl 进行部署的说明。
- 通过调整机器部署副本并使用 Kluctl 的试运行和差异功能来修改工作负载集群。
- 添加和删除节点池，并使用 Kluctl 的修剪功能进行清理
- 介绍在 Kluctl 中进行模板化，以实现可重用和高效的部署。
- 使用模板化部署部署重构的工作负载集群。
- 通过复制配置和使用 GitOps 进行集群管理来添加更多集群。
- Kluctl 和 ClusterClass 之间的比较，突出了 Kluctl 的灵活性和易用性。
以GitOps方式存储Secret
https://mirceanton.com/posts/doing-secrets-the-gitops-way/
本文探讨了如何使用 age 和 Mozilla SOPS 等工具在 GitOps 工作流中安全地管理和加密机密。它详细介绍了这些工具的安装和使用，以便在不损害敏感信息的情况下安全地将加密密钥推送到 Git 存储库。作者还分享了一些技巧、窍门和自动化脚本，以实现高效的机密管理。
关键点
- 在不加密的情况下将密钥推送到 git 是有风险的;对它们进行加密是必要的。
- 作者提供了一种安全加密 Kubernetes 和 Talos 密钥文件的解决方案。
- 本文跟进了之前有关 Talos Linux 和在 YAML 中存储操作系统配置的内容。
- 对使用期限的文件进行加密涉及生成密钥对并使用公钥进行加密。
- Age 是一种简单、安全的文件加密工具，可将文件转换为二进制格式。
- Mozilla SOPS 有选择地加密文件中的值，保持可读性和安全性。
- SOPS 使用各种加密后端（包括 age）来加密特定的 YAML 键值。
- 作者使用命名约定来有效地管理密钥并避免意外推送。
- Bash脚本自动化密钥的加解密，提高效率。
- Taskfile 用于简化仓库中运行密钥管理脚本的过程。
节省Flux与Github之前流量的网络成本
https://medium.com/tenets/saving-networking-costs-for-traffic-flow-between-flux-github-b1cebc76fd41
本文讨论了 VTS Engineering 的 NAT 网关成本显著增加，这是由于 GitHub 的 Flux 源控制器进行过多的数据轮询，尤其是在大型 monorepo 提交之后。该解决方案涉及调整轮询间隔并在 GitHub Actions 中实施shallow克隆以降低成本，最终每年节省约 70K 美元。最后，它提出了一个长期策略，即使用轻量级存储库来托管自定义 helm chart。
关键点
- 由于 GitHub 的 Flux 源控制器进行过多的数据轮询，VTS Engineering 面临着 NAT 网关成本突然飙升的问题。
- 根本原因是 monorepo 中的大量提交，导致频繁的数据获取和流量增加。
- 该解决方案涉及增加 GitRepository 和 ImageUpdateAutomation 控制器的轮询间隔，以减少出站调用。
- 在 GitHub Actions 中实施shallow克隆进一步有助于降低成本。
- 一个长期的解决方案是切换到一个轻量级的仅限工件的 GitHub 仓库来自定义 helm chart。
停止忽视Kubernetes资源管理
https://thenewstack.io/neglect-kubernetes-resource-management-at-your-peril/
本文讨论了有效管理 Kubernetes 资源的挑战和解决方案。它强调了忽视、一刀切和蛮力方法等常见策略的陷阱，并强调了设置适当的资源请求和限制以避免可靠性差、成本高和运营负担等问题的重要性。作者分享了从大规模管理 Kubernetes 中吸取的个人经验和教训，并建议使用 StormForge 等机器学习和自动化工具来优化资源管理。
关键点
- 忽视 Kubernetes 资源管理可能会导致可靠性差和云成本高等挑战。
- 设置适当的资源请求和限制对于有效的 Kubernetes 管理至关重要。
- 常见的策略，如无所事事、一刀切和蛮力方法是不够的，并可能导致资源争用和过度配置。
- 机器学习和自动化为精确的 Kubernetes 资源管理提供了解决方案，减少了人工工作和运营负担。
Varnish Sharding与Istio的结合
https://medium.com/hamburger-berater-team/varnish-sharding-with-istio-in-kubernetes-402f313919aa
本文讨论了在 Kubernetes 环境中使用 Istio 和 Varnish 实现一致的基于哈希的负载均衡。它强调了缓存策略、高可用性和最优请求路由的挑战，并提出了一个使用 Istio 的服务网格功能来改善负载分布和减少延迟的解决方案。
关键点
- Varnish 是一种流行的 HTTP 缓存，用于通过减少到第一个字节指标的时间来改善用户体验。
- Istio 是一个服务网格，它使用 Envoy 代理在 Kubernetes 部署中进行流量分发、可观察性和访问控制。
- 挑战包括处理不断增加的负载、实现高可用性以及在多个 Varnish 实例之间保持有效的缓存。
- 朴素的解决方案涉及轮询负载均衡，这可能导致缓存利用率和后端负载分配效率低下。
- 基于 VCL 的解决方案涉及使用 Varnish 的原生分片功能，但它需要使 Varnish 能够感知 Kubernetes。
- Istio 可以充当 Layer 7 负载均衡器，通过基于 HTTP 请求信息路由请求来解决负载分布不均的问题。
- Istio 的一致哈希可用于将请求最佳路由到 Varnish 实例，使用 :p ath 伪标头进行哈希。
- 实现基于 Istio 的 Varnish 分片可以减少延迟并改善请求分发。
- 虽然 Istio 提供了一个全面的解决方案，但更简单的替代方案（如使用 Nginx 或 VCL）可能足以解决特定问题。
监控Kubernetes无服务器应用的可用性
https://awstip.com/monitoring-availability-for-serverless-applications-on-kubernetes-ab879ba79137
在文章中，Peilun Li 讨论了无服务器架构（尤其是 Kubernetes 上的无服务器架构）如何为应用程序提供动态扩展和成本效益，特别是那些需要零星和密集计算能力的应用程序，如 AI/ML 工作负载。本文探讨了由于无服务器应用程序的规模化为零的性质，因此在监控无服务器应用程序的可用性方面面临的挑战，传统方法可能无法有效解决这一问题。它建议使用 Kubernetes 部署指标作为一种更通用的方法来监控可用性，并采用特定的策略来设置警报阈值，使用算术表达式来区分应用程序就绪的不同状态。
关键点
- 无服务器架构允许动态扩展，从而降低资源密集型工作负载的成本。
- 传统的监控方法对于无服务器应用程序来说已经不够用了，因为它们具有扩展到零的能力。
- 替代监控方法涉及使用服务网格指标或 Kubernetes 部署信号。
- 本文使用 Knative（Serving）作为 Kubernetes 上无服务器部署的案例研究。
- 提出了一种使用 Kubernetes 指标监控可用性的方法，重点关注就绪副本和期望副本之间的关系。
- 讨论了由于可观测性平台的限制而在设置警报条件方面面临的挑战。
- 引入数学表达式，有效设置告警阈值，避免触发状态和健康状态重叠
K8S安全手册分享，星球小伙伴自取!
更多K8S学习资料以及SRE学习手册，请扫码关注哦！
