往期回顾
如何检查 Kubernetes 网络
https://medium.com/@helpme.zhang/how-to-inspect-kubernetes-networking-0d89dfefee95
本文概述了如何检查 Kubernetes 集群中的网络。它包括查找 Pod 和服务的集群 IP 地址、输入 Pod 的网络命名空间、检查 Pod 的虚拟以太网接口，以及探索连接跟踪和 iptables 规则。本文还讨论了查询群集 DNS 并查看 Kubernetes 1.11 及更高版本的 IPVS 详细信息。
关键点
- 使用 'kubectl get pod -o wide' 查找 Pod 的集群 IP。
- 使用 'kubectl get service --all-namespaces' 查找服务的 IP。
- 使用“nsenter”和容器的进程ID输入Pod的网络命名空间。
- 使用 'ip addr' 命令将 Pod 的虚拟以太网接口 （'eth0'） 与节点的接口 （'veth'） 相关联。
- 使用“conntrack”命令检查连接跟踪，并调整跟踪的最大连接数。
- 使用“iptables-save”转储 iptables 规则以查看 Kubernetes 服务 NAT 规则。
- 使用 dig 和 kube-dns 服务 IP 查询集群 DNS。
- 使用 Kubernetes 1.11 及更高版本的“ipvsadm”探索 IPVS 详细信息。
https://medium.com/adidoescode/adidas-how-we-are-managing-a-container-platform-1-3-6ce24e756490
本文讨论了时尚公司阿迪达斯如何管理其容器平台向基于 GitOps 的设置的过渡，这是其技术进步的重大战略举措。
关键点
- 五年多来，阿迪达斯一直在增强其容器平台，使各个团队能够更高效地工作。
- 在 GitOps 过渡之前，adidas 有一个复杂的配置管理系统，包含多个存储库、分支和管道，这既耗时又容易出错。
- GitOps 过渡的主要目标是减少运营时间、更有效地管理平台集群、提高流程弹性以及增强全球和本地配置状态的可见性。
Leaky Vessels deep dive: Docker系统调用分析
https://dev.to/snyk/leaky-vessels-deep-dive-escaping-from-docker-one-syscall-at-a-time-4479
本文深入探讨了 Snyk Security Labs 团队对 Docker 引擎进行的研究，他们发现了四个高严重性漏洞，这些漏洞允许恶意攻击者突破容器环境。本文探讨了用于识别这些漏洞的技术，包括使用 strace 工具来分析 Docker 引擎的内部工作原理并发现竞争条件。
关键点
- 研究团队使用功能强大的 Linux 工具 strace 来调查 Docker 引擎并识别漏洞。
- 他们发现了一个漏洞 （CVE-2024-21626），该漏洞允许攻击者利用由于争用条件导致的混乱代理情况来突破容器环境。
- 另一个漏洞 （CVE-2024-23652） 允许攻击者在容器拆解过程中通过交换目录树来删除主机文件系统上的任意文件。
- 第三个漏洞 （CVE-2024-23651） 是一种争用条件，允许攻击者执行任意绑定挂载，从而有效地访问主机文件系统。
- 本文还讨论了缓解此类漏洞的最佳实践，例如对同一文件描述符执行检查和操作以避免争用条件。
https://itnext.io/using-k8s-requests-for-allocating-resources-other-than-cpu-or-memory-75471a390fbb
本文讨论了 Kubernetes 中一个鲜为人知的功能，称为“扩展资源”，它允许用户在 Kubernetes 节点上管理和分配 CPU 或内存以外的资源。
关键点
- Kubernetes 调度程序不知道某些节点级资源（如 IP 地址），这可能会导致调度问题。
- 扩展资源允许用户通告和管理这些额外的节点级资源，使调度程序了解它们。
- Pod 可以请求和使用扩展资源，就像它们消耗 CPU 和内存一样。调度程序在调度 Pod 之前确保请求的扩展资源可用。
- 扩展资源不能过度提交，如果 Pod 规范中同时存在请求和限制，则请求和限制必须相等。
如何实现 Kubernetes 请求
https://itnext.io/how-kubernetes-requests-are-implemented-59c23a08c0af
本文详细介绍了 Kubernetes （K8s） 请求是如何实现的，重点介绍了 K8s 节点上 CPU 和内存资源的分配。
关键点
- 在每个 K8s 节点上运行的 Kubelet 都带有两个标志，“system-reserved”和“kube-reserved”，允许管理员为系统守护进程和 Kubelet/容器运行时保留部分节点资源。
- 未能设置“system-reserved”和“kube-reserved”标志可能会导致系统守护进程和 Kubelet/容器运行时没有足够的资源，从而影响节点的性能。
- CPU 请求是使用称为控制组 （cgroups） 的 Linux 内核机制实现的，该机制允许在用户定义的任务组之间分配 CPU 时间、系统内存和网络带宽等资源。
- K8s 节点上的 cgroups 层次结构分为 'system-reserved'、'kube-reserved' 和 'kubepods' 的不同切片，这决定了系统每个部分的 CPU 分配比例。
从Kubernetes节点中删除特定image
https://medium.com/@nmaguiar/removing-specific-images-from-all-kubernetes-nodes-afd248feea60
本文提供了从所有 Kubernetes 节点中删除或拉取特定映像的问题的解决方案，即使该映像在不同版本中具有相同的名称和标记也是如此。
关键点
- 出现此问题的原因是每个 Kubernetes 节点都有自己的容器映像缓存，并且这些节点可能具有同一映像的不同版本。
- 该解决方案涉及使用 crictl CLI 工具列出、拉取或删除每个节点上的图像，而不是依赖于更改节点缓存 TTL 或其他解决方法。
- 本文提供了在每个节点上运行必要操作的示例命令，以及不同 Kubernetes 发行版（K3S、OpenShift/CRI-O、ECR/GKE/AKS）的变体。
- 提供了其他提示和注意事项，例如使用 shell 脚本自动执行操作以及潜在的安全/存储影响。
多集群 Kubernetes 的 7 个注意事项
https://dev.to/rayedwards/7-considerations-for-multi-cluster-kubernetes-44gb
本文讨论了采用多集群 Kubernetes 或混合云方法的组织面临的挑战和注意事项。它强调了云编排、互操作性、数据可移植性、安全性和治理、资源优化、人才短缺和弹性的复杂性，这些都是组织需要解决的关键领域。
关键点
- 云编排的复杂性：跨云提供商浏览不同的 Kubernetes 发行版是一项重大挑战。
- 互操作性：由于供应商特定的自定义，实现跨不同云环境的应用程序互操作性可能很困难。
- 数据可移植性：云提供商在将数据移出其平台时可能会收取高额的“数据出口”费用，从而产生“加州酒店”效应。
- 安全性和治理：确保跨混合云和多云部署的全面安全性和治理至关重要。
- 资源优化：在多云环境中优化资源利用率和成本需要专门的工具和技术。
- 人才短缺：寻找和留住熟练的架构师来管理混合云和多云环境可能是一项挑战
- 弹性：实施强大的云原生灾难恢复策略对于确保应用程序可用性至关重要
Kubernetes多集群部署中的 弹性 （RTO/RPO）
https://dev.to/rayedwards/kubernetes-resiliency-rtorpo-in-multi-cluster-deployments-32be
关键点
- Kubernetes 通过卷复制在单个集群内提供复原能力，从而实现零恢复时间目标 （RTO） 和可能为零的恢复点目标 （RPO）。
- 在跨平台和云提供商的多集群部署中，集群与“南北”网络流量之间的异步通信给数据弹性和恢复带来了挑战。
- KubeSlice 等工具可以通过在集群之间建立低延迟数据平面互连来帮助应对这些挑战，从而实现同步数据复制和更快的恢复，并实现接近零的 RTO。
- 在多集群环境中部署 Kubernetes 时，仔细考虑应用程序和数据弹性需求至关重要，因为它会显著影响生产力和收益
更多K8S学习资料以及SRE学习手册，请扫码关注哦！
