Kubernetes学习周报(第四期 ): K8S中使用 Wireshark;K8S安全清单;如何缩小Docker镜像

文摘   2024-07-06 21:04   挪威  


往期回顾

Kubernetes学习周报(第三期 ): Kubernetes 健康检查,如何使用 runc 生成容器

Kubernetes学习周报 : 一周好文推荐,K8s 网络请求分析,多集群 Kubernetes 的 7 个注意事项 

 

Kubernetes学习周报 : 一周好文推荐

    

 

如何将我的第一个发布的 docker 镜像大小缩减 40%  

         

 

https://bhupesh.me/publishing-my-first-ever-dockerfile-optimization-ugit/


本文讨论了作者将他们第一个发布的 Docker 镜像的大小减少 40% 的经验,从 31.4 MB 减少到 17.6 MB,用于名为“ugit”的 shell 脚本(一种撤销 Git 命令的工具)。作者遵循一个循序渐进的优化过程,包括使用多阶段构建,识别并仅包含必要的依赖项,以及最小化终端信息数据库。最终的 Docker 镜像可在 Docker Hub 上找到。

关键点

  • - 作者希望将“ugit”shell 脚本作为 Docker 镜像提供。

  • - 作者使用多阶段构建来减小图像大小,从 Alpine 基础镜像开始,然后仅将必要的二进制文件和依赖项复制到最终镜像。

  • - 作者使用“ldd”工具识别并仅包含二进制文件所需的共享库(依赖项)

  • - 作者从脚本中删除了(#!),因为已经包含了 bash 二进制文件,从而节省了几个字节。

  • - 作者通过仅包含“xterm-256color”终端类型来最小化终端信息数据库,额外节省了 97 KB

  • - 最终的 Docker 镜像大小减少了 40%,从 31.4 MB 减少到 17.6 MB。


Docker 不是未来


https://blog.kylegalbraith.com/the-future-is-not-docker/

本文讨论了作者对 Docker 和容器未来的看法。它重点介绍了作者在构建名为 Depot 的远程容器构建服务方面的经验,该服务解决了 Docker 和 BuildKit 的低效率和复杂性。

关键点

- 未来不是 Docker,而是容器

- Docker 难以实现商业化,现在严重依赖 Docker Desktop,这不是一种新产品,而是一种许可策略。

- Docker 和 BuildKit 过于复杂且效率低下,具有许多不必要的特性和复杂性。

- 有更好的方法来组装容器,而不依赖于 Docker 和 BuildKit 的复杂性


The Traffic Polic : 使用mirrord控制出站流量


https://dev.to/meowchinist/the-traffic-police-controlling-outgoing-traffic-with-mirrord-216

本文讨论了mirrord工具中的一项功能,该功能允许开发人员在 Kubernetes 环境中测试应用程序时控制应用程序的传出流量。主要观点是:  

 

关键点

- Mirrord 可用于将应用程序的传出流量重定向到本地环境,同时仍允许应用程序与集群中的其他服务进行通信。

- mirrord 中新的“传出流量过滤器”功能允许开发人员根据目的地指定应在本地发送哪些传出流量,而不是远程发送。

- 本文提供了一个详细的示例,如何使用 mirrord 来测试一个 “uwu-app”,该 “uwu-app” 与集群中的 “uwu-service” 通信,同时写入本地数据库而不是集群中的数据库。

- 传出流量过滤器功能以及其他镜像功能为开发人员提供了前所未有的控制权,可以控制其应用程序与集群环境的通信方式,从而简化开发和测试过程。


在Kubernetes中优化Wireshark


https://sysdig.com/blog/optimizing-wireshark-in-kubernetes/

本文讨论了在 Kubernetes 环境中使用 Wireshark 等传统数据包捕获工具所面临的挑战,并提出了一种使用 Falco 和 Falco Talon 来改进网络流量分析的新方法。         

 

关键点    

- 容器的短暂性和 Kubernetes 结构的分层抽象使得使用传统工具捕获和分析网络流量变得困难。

- Wireshark 本身并不了解 Kubernetes 抽象,因此很难将网络流量直接关联回特定的 pod 或服务。

- 传统的数据包捕获策略通常会导致大量不相关的数据,从而更难快速有效地隔离重要信息。

- Falco 和 Falco Talon 通过将云原生检测引擎 Falco 与 Wireshark 的终端版本 tshark 集成来解决这些缺点,以便在 Kubernetes 环境中进行更有效和有针对性的网络流量分析。

- Falco Talon 的事件驱动的 API 威胁响应方法允许根据 Falco 警报实时启动 tshark 捕获,从而提供更具针对性和上下文化的数据包捕获。

- 这种有针对性的方法不仅可以减少捕获的数据量,还可以确保捕获的数据与检测到的安全事件立即相关,从而提高响应时间和有效性。


重塑监控:Prometheus和Thanos的进化故事

https://medium.com/myntra-engineering/monitoring-reinvented-prometheus-and-thanos-evolutionary-tale-f36ae95c2c60

本文讨论了如何使用 Prometheus 和 Thanos 来执行大规模监控。它涵盖了使用独立 Prometheus 设置的挑战以及 Thanos 如何解决这些限制。

关键点

- 独立版 Prometheus 在水平扩展、高可用性、长期存储和缓存方面面临挑战。

- Thanos 是一个开源项目,它扩展了 Prometheus 以提供可扩展性、高可用性和长期存储。

- Thanos 使用 Sidecar、Querier、Query Frontend 和 Store 等组件来实现这些功能。

- 本文介绍了一个使用 Prometheus Operator、Querier 和 Thanos 组件的综合监控设置,以解决独立 Prometheus 的局限性。

         

 


Kubernetes安全清单

https://sysdig.com/content/c/sysdig-kubernetessec?utm_campaign=pspt_global_secure-cloud-speed_na&utm_medium=referral-ad&utm_offer=securing-kubernetes-checklist&utm_source=kubefm&x=-FqYfv

本文讨论了实施全面的安全清单以保护 Kubernetes(云的实际操作系统)的重要性。它强调了DevOps团队在维护云基础设施和应用程序完整性方面面临的挑战,同时还要解决关键的安全措施,特别是在容器环境变得越来越动态和短暂的情况下。

关键点

- Kubernetes 已成为开发和部署云原生应用程序的主要平台,但其复杂性通常会导致关键安全措施的推迟。

- 云环境变得越来越复杂,到 2024 年,70% 的容器的生命周期为 5 分钟或更短,这使得检测和调查异常行为变得具有挑战性。

- 尽早解决容器安全风险至关重要,因为延迟可能会阻碍云采用的势头,并加剧安全性和合规性漏洞。

- DevOps 团队在过渡到生产环境时,在为关键云应用程序创建、管理和更新安全清单方面面临额外的负担。

- 重新构想与云速度相适应的安全性至关重要,并且提供了一个全面的安全清单来指导 Kubernetes 和容器部署的安全策略。

K8S安全手册分享,星球小伙伴自取! 


加入知识星球,共同探索云原生学习之旅!

更多K8S学习资料以及SRE学习手册,请扫码关注哦!


云原生SRE
懂点K8S的SRE,关注云原生、DevOps、AI\x26amp;ChatGPT等技术热点
 最新文章