往期回顾
Kubernetes学习周报（第四期 ）: K8S中使用 Wireshark；K8S安全清单；如何缩小Docker镜像
Kubernetes学习周报（第三期 ）: Kubernetes 健康检查，如何使用 runc 生成容器
Kubernetes学习周报 : 一周好文推荐，K8s 网络请求分析，多集群 Kubernetes 的 7 个注意事项
Kubernetes Service 介绍
https://dev.to/vromanov/kubernetes-services-1bj
本文介绍了 Kubernetes Service，服务是 Kubernetes 的重要组成部分，用于管理和扩展集群中的应用程序。
关键点
- Kubernetes Service为集群水平或垂直扩展的服务提供 IP 分配和负载均衡。
- ClusterIP 服务是默认的服务类型，它根据指定的选择器将来自 Ingress 服务的请求转发到相应的节点和 Pod。
- Headless Services 允许应用程序直接与特定 Pod 通信，这对于需要访问特定主节点的数据库集群非常有用。
- NodePort 服务在节点上公开一个端口，以允许外部访问应用程序，但由于安全问题，不建议在生产环境中使用。
- LoadBalancer 服务是 NodePort 服务的扩展，它利用了部署 Kubernetes 集群的云提供商提供的负载均衡器。
Kubernetes Silent Pod Killer
https://itnext.io/kubernetes-silent-pod-killer-104e7c8054d9
本文探讨了 Kubernetes 中的“不可见 OOM 终止”问题，其中容器中的子进程可能会被 OOM（内存不足）杀掉终止，而 Kubernetes 系统并不知情。本文提供了针对此问题的见解和解决方案。
关键点
- 当容器中的子进程（任何不是主进程的进程，PID 1）被 OOM 杀死时，就会发生“不可见”的 OOM Kill，并且此事件对 Kubernetes 不可见。
- 从 Kubernetes 版本 1.28 开始，默认开启了一个名为“cgroup grouping”的 cgroup v2 特性，如果容器内的任何进程被 OOM 杀死，则会导致整个容器被杀死。
- 对于某些工作负载（例如 PostgreSQL 或 ML 工作负载），这种新行为可能并不可取，在这些工作负载中，子进程 OOM 是独立处理的。
- 在 Kubernetes 1.28 之前，您可以使用 mtail 等工具来监控内核日志消息并检测子进程 OOM 终止。
- 要监控“正常 OOM 终止”（root 进程终止），您可以使用度量标准“kube_pod_container_status_last_terminated_reason{reason=”OOMKilled“}”。
- 在编写Docker文件时，建议使用正确的ENTRYPOINT / CMD将主要工作负载保持在主进程内。
Argo CD 与Flux CD
https://blog.aenix.io/argo-cd-vs-flux-cd-7b1d67a246ca
本文详细比较了两种流行的 GitOps 工具 Argo CD 和 Flux CD，讨论了它们的特性、用例和对不同场景的适用性。
关键点
- Argo CD 比 Flux CD 更受欢迎，可能是由于其用户友好的图形界面和 pod 日志、清单编辑和自定义操作等附加功能，这些功能超出了标准的 GitOps 实践。
- Flux CD 专注于实现最标准的 Kubernetes 模式，可以用作构建其他系统的基础，并有大量基于它的第三方解决方案。
- Argo CD 有一个更复杂的部署模型，它首先调用一个配置插件来渲染清单，然后将它们应用到集群，这可能会导致 Helm chart 出现漂移问题。Flux CD 使用原生 Kubernetes 工具进行部署，更简单明了。
- Argo CD 有自己的访问控制模型，而 Flux CD 利用了标准的 Kubernetes RBAC 模型。Argo CD 的模型更方便限制开发人员对 Kubernetes 的访问。
- Argo CD 更容易使用自定义插件进行扩展，而扩展 Flux CD 需要付出更大的努力。
- Argo CD 将所有资源存储在单个命名空间中，而 Flux CD 可以使用标签对资源进行操作，使其更具可扩展性。
- Argo CD 和 Flux CD 之间的选择取决于您要解决的特定问题，无论您是需要一个工具来简化集群管理还是开发人员应用程序交付。
通过示例了解Docker层：RUN指令的影响
https://pointbase.hashnode.dev/understand-docker-layers-by-example-run-instructions-impact
本文讨论了在 Dockerfile 中使用多个 RUN 指令的影响，以及最小化其使用的重要性。它演示了每个 RUN 指令如何在 Docker 镜像中创建一个新层，如果与其他不好做法结合使用，有时会带来风险。
关键点
- 最小化 Dockerfile 中 RUN 指令的数量对于减小最终镜像的大小、提高构建和部署性能以及通过避免创建可能包含敏感或冗余数据的不必要层来增强安全性至关重要。
- 最佳做法是将相关命令合并到单个 RUN 指令中，从而减少层数并优化图像的效率。
- 本文提供了两个 Dockerfile 的示例，一个包含单个 RUN 指令，另一个包含两个 RUN 指令，并演示了如何使用 dive 工具检查生成的图像的不同层。
- 它展示了如何从 Docker 层中检索文件，并解释了不必要的层的存在可能会导致敏感信息的意外保存。
BGP、Cilium和FRR：ToR架构
https://blog.miraco.la/bgp-cilium-and-frr-top-of-rack-for-all
本文讨论如何使用 Cilium 的 BGP 功能来公开服务或导出 Pod CIDR 并将其范围告知给对方。作者解释了设置过程，其中包括在运行 K3S 和 Cilium 的 UDM-SE 和 Raspberry Pi 上使用 FRR。
关键点
- 作者解释了架顶式 （ToR） 的概念，以及如何使用它直接连接到应用程序，而无需负载均衡器或节点端口。
- 作者展示了 FRR 配置，其中包括设置 BGP 和允许所有连接的路由映射。
- 作者解释了在 K3s 集群上安装 Cilium 并禁用 flannel、servicelb 和 network-policy 的步骤。
- 作者提供了一个 CiliumBGPPeeringPolicy 示例，该示例允许对 Pod CIDR 进行通告，并设置本地 ASN。
- 作者演示了如何通过检查 BGP 对等体并向应用程序发出测试请求来验证设置。
由单个Kubernetes命令引发的悲剧
https://zouyee.medium.com/a-tragedy-caused-by-a-single-kubernetes-command-7b6126b06513
本文讨论了在 Kubernetes 中从 cgroup v1 迁移到 cgroup v2 时出现的一个问题，其中单个命令导致了悲剧。它提供了有关如何生成容器指标、Kubernetes 如何集成容器监控以及如何计算 CPU 负载的技术背景信息。文章还追溯了问题的根源，解释了 cAdvisor 和 Kubelet 在此过程中的作用。
关键点
- 由于 CentOS 被 EOL，团队正忙于迁移到新的操作系统，并从 cgroup v1 过渡到 cgroup v2。
- 在 cgroup v2 环境中，使用 -enable_load_reader 配置会导致 kubelet 崩溃。
- cAdvisor 是一个强大的 Docker 容器监控工具，Kubelet 使用它来收集节点上的容器资源和性能指标
- cAdvisor支持启用或禁用特定指标的功能，包括CPU负载指标。
- CPU 负载指标的生成由 cAdvisor 中的 -enable_load_reader 命令行标志控制。
- Kubelet 嵌入了 cAdvisor 服务，并在 /stats/ 以 Prometheus 指标格式公开所有相关的运行时指标。
- container_cpu_load_average_10s，CPU 平均负载指标是使用结合了前一个值和当前收集值的公式计算得出的。
- 该问题与 cgroupstats_build 函数中缺少对 cgroup v2 的处理有关，该函数用于检索 CPU 负载信息。
- 内核社区建议使用 Pressure Stall Information （PSI） 而不是 CGROUPSTATS_CMD_GET netlink API 来获取 CPU 统计信息
K8S安全手册分享，星球小伙伴自取!
更多K8S学习资料以及SRE学习手册，请扫码关注哦！
