一、容器逃逸的定义与危害

1.1 什么是容器逃逸？

容器逃逸（Container Escape）是指攻击者突破容器隔离边界，获取宿主机操作系统权限的过程。这违背了容器设计的核心安全假设，可能引发：

• 横向移动攻击
• 敏感数据泄露
• 宿主机资源劫持
• 持久化后门植入

1.2 逃逸发生的根本原因

graph TD
    A[容器共享内核] --> B(内核漏洞利用)
    C[配置不当] --> D(特权容器/危险挂载)
    E[软件缺陷] --> F(RunC/CVE-2019-5736)

前言

笔者由于工作变动去做了云安全，第一次真正的使用上k8s作为部署和安全场景，记录一下k8s学习的过程，本篇是k8s核心组件的学习。

一、Kubernetes架构全景

graph TD
    A[Control Plane] --> B[API Server]
    A --> C[etcd]
    A --> D[Scheduler]
    A --> E[Controller Manager]
    F[Node] --> G[kubelet]
    F --> H[kube-proxy]
    F --> I[Container Runtime]
    B --> G
    B --> H

前言

上一篇文章写了Pytest的基础用法

由于最新启动的Django项目，最终选型Pytest作为测试框架，就想着分享下测试代码的最佳实践。

为什么不是unittest

unittest作为官方的测试框架，在测试方面更加基础，并且可以再次基础上进行二次开发，同时在用法上格式会更加复杂；而pytest框架作为第三方框架，方便的地方就在于使用更加灵活，并且能够对原有unittest风格的测试用例有很好的兼容性，同时在扩展上更加丰富，可通过扩展的插件增加使用的场景，比如一些并发测试等；

Pytest

The pytest framework makes it easy to write small, readable tests, and can scale to support complex functional testing for applications and libraries.

这是Pytest官网对其的描述，毋庸置疑，pytest已经是最好的python测试框架。

现代软件开发推崇TDD(Test-Driven Development) —— 测试驱动开发，所以pytest可以说是python后端的必要技术栈。

由于最近的项目对代码质量要求较高，当然对测试代码也需要很高的完成度，首先来讲讲如何使用pytest开展工作，后面再补上Pytest在Django和DRF中的最佳实践。

Poetry是什么

Poetry 和 Pipenv 类似，是一个 Python 虚拟环境和依赖管理工具，另外它还提供了包管理功能，比如打包和发布。你可以把它看做是 Pipenv 和 Flit 这些工具的超集。它可以让你用 Poetry 来同时管理 Python 库和 Python 程序。

相比于pip、 pipenv和requirements.txt，Poetry更加强大、对依赖维护更友好

Pipenv 描绘了一个美梦，让我们以为 Python 也有了其他语言那样完善的包管理器，不过这一切却在后来者 Poetry 这里得到了更好的实现。

前言

继上一篇文章，继续补充MySQL索引的优化步骤

在日常的后端开发中，离不开对数据库的增删改查，往往在查询性能指标、操作日志这种大表时，会遇到数据库瓶颈，优化的方法有很多，例如水平拆分、垂直拆分等，其中最简单有效、代价最低的方法就是利用索引。

先来精炼复习下索引原理。

前言

索引的建立对于MySQL的高效运行是很重要的，索引可以大大提高MySQL的检索速度。

我最近在一个工单系统的迭代中遇到了性能问题，由于匆忙上线了个人的待办和待认领功能，导致数据库的查询难度激增，所以需要从数据库优化的方向来考虑，分为查询优化、索引优化与表结构拆分重构。我打算先从最简单高效的索引入手。

所谓索引就是为特定的 MySQL 字段进行一些特定的算法排序，比如二叉树的算法和哈希算法，哈希算法是通过建立特征值，然后根据特征值来快速查找。而用的最多，并且是 MySQL 默认的就是二叉树算法 BTREE，通过BTREE算法建立索引的字段，比如扫描20行就能得到未使用BTREE前扫描了2^20行的结果。

去年我也有一篇文章有提到 MySQL 索引相关的内容，现在看来不太全面，所以打算系统又全面地写一写索引和性能优化的内容。

前言

上文提到了，索引分单列索引和组合索引。单列索引，即一个索引只包含单个列，一个表可以有多个单列索引，但这不是组合索引。

组合索引（Composite Index），又称复合索引、联合索引、多列索引，为什么可以有这么多别名，下文中可任意替代！

顾名思义，是建立在多个列上的索引，适用在多个列必须一起使用或者是从左到右方向部分连续列一起使用的业务场景。创建索引时，你需要确保该索引是应用在 SQL 查询语句的条件(一般作为 WHERE 子句的条件，且条件不为OR)。

前言

最近对开源监控系统比较感兴趣，之前的博客对Prometheus 、Zabbix（去年）都做过研究，也稍微提及了Grafana，甚至Telegraf+InfluxDB。最终在云服务器上逐个进行了部署和体验。

但是明显感受到知识是不成体系的，所以决定结合个人体验和文档，对多个监控解决方案进行横向对比，这样才能更好地理解它们的优劣和擅长的领域。

以下将详细对比Prometheus和Zabbix，它们分别作为监控领域的新宠和老将，是具有代表性的。

什么是 Prometheus

Prometheus is an open-source systems monitoring and alerting toolkit originally built at SoundCloud.

From metrics to insight. Power your metrics and alerting with a leading open-source monitoring solution.

Prometheus是新一代的监控系统解决方案，也是基于Golang的重量级云原生开源项目。

在容器化监控领域，Prometheus是不二之选，并且能兼容传统的监控方案。

从部署、使用到开发，我个人的感受是：

特点

• 开箱即用，使用门槛低
• 强大的开源社区和生态支持
• 通过PromQL实现多维度数据模型的灵活查询
• 灵活的自定义探针（如Exporter等），编写简单方便
• 时序数据库更契合监控场景

局限

• 不适合存储事件或者日志，更多地展示的是趋势性的监控，主要面向metrics
  • 对策：使用Loki，他是面向log的类Prometheus系统，与Grafana同门
• 本地存储短期数据，不适合大量历史数据存储，这是设计初衷
  • 对策：远程存储使用其他TSDB，如InfluxDB
• Exporter种类繁多，每个Exporter又相互独立、各司其职，Exporter越多，维护压力越大
  • 对策：使用Telegraf集成Prometheus（Telegraf是用于数据收集的开源Agent，资源使用率更低）