往期回顾
Kubernetes学习周报（第7期 ）:K8S容器运行时CRI接口；Kluctl管理集群API；K8S无服务器应用监控
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 网络：云原生数据包管理之旅
https://otterize.com/blog/mastering-kubernetes-networking-otterize-s-journey-in-cloud-native-packet-management
本文深入探讨了 Kubernetes 网络，重点介绍了其通过容器网络接口 （CNI） 进行网络管理的独特方法，以及网络策略对安全性的重要性。它讨论了 Otterize 如何根据实际流量模式自动创建这些策略，从而简化云原生环境中的管理并增强安全性。
关键点
- Kubernetes 抽象化网络管理以提高可扩展性和简单性，使用容器网络接口 （CNI） 实现网络解决方案的灵活性。
- Kubernetes 中的 Pod 网络为每个 Pod 分配一个唯一的 IP，从而简化了整个集群的通信，而无需复杂的路由。
- 服务网络使用 ClusterIP 实现对 Pod 的稳定访问，kube-proxy 使用 iptables、IPVS 或 nftables 处理流量路由。
- NodePort 和 LoadBalancer 服务允许对 Kubernetes 集群进行外部访问，而 Ingress Controller 提供更专业的流量管理。
- Kubernetes 中的网络策略提供对 Pod 通信的精细控制，这在多租户环境中对于隔离和安全性至关重要。
- 建议使用零信任安全模型，从拒绝所有策略开始，并明确允许必要的通信。
- 本文提供了 Kubernetes 网络的详细数据包演练，说明了从用户到应用程序的流量。
- Otterize 通过映射实际流量模式、简化管理流程并与 CI/CD 管道保持一致来自动创建网络策略。
- Otterize 的自动化有助于维护安全且自适应的 Kubernetes 环境，从而减少攻击面并支持持续合规性。
Kubernetes 如何在Scale缩减期间选择要删除的 Pod
https://rpadovani.com/k8s-algorithm-pick-pod-scale-in
本文探讨了 Kubernetes 如何确定在缩减操作期间要删除哪些 Pod，这是一个没有详细记录的过程。作者调查源代码以解释逻辑，重点介绍 Kubernetes 版本 v1.30.0-alpha.0。本文详细介绍了 ReplicaSet 在管理 Pod 缩容中的作用、用于决定要删除哪些 Pod 的排名和排序标准，以及 pod-deletion-cost 注解的影响。
关键点
- Kubernetes 必须在缩减期间选择要删除的 Pod，并且不会随机删除。用户可以使用 pod-deletion-cost 注解来影响此决策。
- 缩减意味着减少 Deployment 中的 Pod 数量，这可以通过 autoscaler 手动或自动完成。
- ReplicaSet 控制器管理缩容 Pod 的逻辑，使用排名系统和排序规则来决定要删除哪些 Pod。
- 计算 RelatedPod 来通知排名，包括具有相同所有者的任何 ReplicaSet 拥有的所有 Pod。
- 该排名考虑同一节点上的 Pod，在一个节点上共存的 Pod 排名更高。
- 排序逻辑涉及 8 个标准来确定 Pod 删除的顺序，包括 Pod 分配、阶段、就绪情况和 pod-deletion-cost。
- pod-deletion-cost 功能允许用户分配删除 Pod 的成本，从而影响其删除优先级。
- 本文总结了用于对 Pod 进行排序的标准，强调了删除的顺序。
K8S 探针配置对了吗？
https://medium.com/@juliorenner123/k8s-probes-done-wrong-184d238b3883
K8S 探针对于监控在 Kubernetes 中运行的应用程序的运行状况至关重要。但是，不正确的配置可能会导致更多问题。本文讨论了三种类型的探测：Startup、Readiness 和 Liveness，并解释了它们的用途和潜在的陷阱。启动探测会延迟其他检查，直到应用程序准备就绪，而就绪情况探测则确定容器是否可以处理流量，而不会在失败时终止流量。活动情况探测会检查容器是否正常运行，并在必要时重新启动容器。本文使用场景来强调常见错误，例如对多个探测使用相同的终端节点，并检查可能导致不必要重启或停机的依赖关系。它建议了解探测行为并避免依赖项检查，以防止加剧现有问题。
关键点
- Kubernetes 探测对于应用程序运行状况检查至关重要，但如果配置错误，可能会导致问题。
- 启动探测器会暂停其他检查，直到应用程序准备就绪，从而防止过早失败。
- 就绪情况探测确定容器是否可以在不影响其运行状态的情况下处理流量。
- 活动情况探测检查容器是否正常运行，并可能在失败时重新启动容器
- 滥用探针（例如重用终端节点或检查依赖项）可能会导致停机和不稳定。
- 正确理解探针行为对于避免使现有问题恶化至关重要。
当 Kubernetes 和 Go 不能很好地协同工作时
https：//lalatron.hashnode.dev/when-kubernetes-and-go-don't-work-well-together
本文讨论了在 Kubernetes 环境中使用 Go 时遇到的一个特定问题，其中 Go 运行时不知道容器的内存限制，从而导致内存不足错误。作者描述了故障排除过程，并探讨了 Go 的垃圾回收器如何导致该问题。提出了一种使用 GOMEMLIMIT 环境变量的解决方案，以更好地使 Go 的内存管理与 Kubernetes 限制保持一致。
关键点
- Go 不知道 Kubernetes 容器限制，当超出内存时会导致 OOM 错误。
- API 终端节点导致 Kubernetes Pod 因超出内存限制而重启，尽管分配了足够的 RAM。
- Go 的垃圾回收器扩展了堆内存，不知道容器限制，导致 OOM 错误。
- GOMEMLIMIT 环境变量可以通过为 Go 的垃圾回收器设置软限制来帮助管理内存使用。
使用 Cluster API 管理 100 个 Kubernetes 集群
https://techblog.citystoragesystems.com/p/managing-100s-of-kubernetes-clusters
为了高效管理数百个 Kubernetes 集群，City Storage Systems 的核心基础设施团队过渡到使用 Cluster API，从而显著自动化了集群配置和管理。这种转变减少了集群设置时间，并支持无缝迁移到 Microsoft Azure，尽管最初托管的 Kubernetes 发行版面临挑战。该团队利用 Kubernetes 操作员和 GitOps 实现完全自动化，从而提高可靠性和运营效率。他们计划通过自动化更多流程和增加集群数量来进一步扩展。
关键点
- City Storage Systems 使用 Cluster API 自动化 Kubernetes 集群管理，将设置时间从 1.5 周缩短到不到一天。
- 过渡包括将 80 多个集群迁移到 Microsoft Azure，使管理的集群数量翻了一番。
- Cluster API 的可扩展性和操作员模式允许高效管理多租户集群。
- 最初的挑战包括对托管 Kubernetes 发行版的有限支持，这些支持通过与 Microsoft 的合作得到了解决。
- 自动化包括利用自定义 Kubernetes 运算符创建集群和工作负载准备。
- 节点池管理实现了自动化，以简化升级和更换期间的操作。
- 该团队计划通过进一步自动化流程和最大限度地减少人工干预来管理 500 多个集群。
更多K8S学习资料以及SRE学习手册，请扫码关注哦！
