文章列表

812字1 分钟

Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub. # Quick Start # Create a new post $ hexo new "My New Post" More info: Writing # Run server $ he
5.2k字5 分钟

Seldon Core一个运行在 Kubernetes 上的机器学习模型服务平台，用来把训练好的模型部署成可访问、可扩缩、可观测的在线推理服务。这里学习的是1版本。 它解决的不是“怎么训练模型”，而是： 模型训练好了，怎么部署上线？ 怎么暴露 REST / gRPC 接口？ 怎么做版本切换、流量分配？ 怎么同时管理大量模型？ 怎么监控延迟、错误率和资源使用？ 怎么把多个模型、预处理和后处理串成推理流水线？ 当前官方重点已经转向 Seldon Core 2。Core 2 被定位为 Kubernetes 上的 MLOps/LLMOps 框架，可以管理单模型、多个模型以及模
1.9k字2 分钟

# 心智模型 攻击者容易利用特权容器从受限容器环境侵入宿主机操作系统。 # 🛠️ 实操手册：逃逸演示与防御配置 # 第一阶段：演示特权容器逃逸（危险操作，仅限实验） 我们将演示攻击者如何利用特权容器直接访问宿主机的磁盘。 部署一个特权 Pod： 注意 privileged: true 这个开关。 YAML apiVersion: v1 kind: Pod metadata: name: privileged-escape-demo spec: containers: - name: attacker-container image: alpine comma
2.3k字2 分钟

Seccomp (Secure Computing mode) 是 Linux 内核的一项功能，用于限制容器可以发起的系统调用 (System Calls)。 # 🛠️ 实操手册：配置 Seccomp Profile 在 Kubernetes 中，Seccomp 已经比 AppArmor 更加标准化，直接集成在 securityContext 字段中。 # 第一阶段：使用 RuntimeDefault (最推荐的生产配置) 这是容器运行时（如 containerd 或 Docker）自带的一套“安全模板”，它禁用了大约 40 多个危险的系统调用。 编写 Pod 配置文件： 与 AppArm
2.1k字2 分钟

# 心智模型 最小权限原则，要求每个程序或系统进程这你能访问其任务所必须的信息和资源。 # 实验：部署和引用 AppArmor Profile # 第一阶段：在 Worker 节点准备 Profile AppArmor 是 Linux 内核模块，因此 Profile 必须加载到每一个运行 Pod 的节点内核中。 登录到你的 Worker 节点。 创建 Profile 文件：创建一个名为 k8s-deny-write 的配置文件，禁止容器写入任何文件。 Bash cat <<EOF > /etc/apparmor.d/k8s-deny
3.3k字3 分钟

实验在 Killercoda 进行，自己搭的网络实在是太麻烦了。 # 步骤 1：安装 NGINX Ingress Controller Killercoda 的默认集群没有自带 Ingress 控制器，我们需要手动部署官方的裸机（Bare-metal）版本。 在终端中执行以下命令： kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.10.0/deploy/static/provider&
1.5k字1 分钟

kube-bench 进行集群安全加固是 Kubernetes 运维中的高级进阶任务。它主要基于 CIS (Center for Internet Security) Kubernetes Benchmark 标准来检查集群配置。 # 心智模型： 在操作之前，需要建立这样一个逻辑回路： 扫描 (Scan)： kube-bench 作为一个二进制工具或容器运行，它会读取主机的进程参数（如 ps -ef grep kube-apiserver）和配置文件。 比对 (Compare)： 它将获取到的参数与 CIS 标准进行比对。 报告 (Report)： 输出 [PASS]（通过）、[FAIL]（
2.9k字3 分钟

ectdctl 是一个命令行界面 （CLI）工具，专门用于与 etcd 数据库进行交互。 目前 ectd 普遍使用 v3 版本的 API ，操作前需要指定环境变量 ETCDCTL_API=3。 新版将 etcdctl 功能拆分了： ectdctl:用于与正在运行的 etcd 服务交互 （通过网络） etcdutl:用于处理离线文件 # 第一部分：etcd 备份与恢复的心智模型 集群所有状态都以键值对形式存储在 etcd 中。除了 kube-apiserver，没有任何组件可以直接和 etcd 对话。 备份的本质是拷贝那一瞬间 etcd 底层 BoltDB 引擎的物理文件。 恢复
2.4k字2 分钟

在真实的生产环境中，很多老旧系统（Legacy Systems）并不符合云原生标准。它们不会把日志输出到终端（stdout），而是死板地写进容器内的某个文件里（比如 /var/log/app.log）。这就导致 Kubernetes 原生的 kubectl logs 命令直接失效（因为它只抓取容器的 stdout）。 # 核心技术逻辑：Sidecar（边车）模式与共享卷 要在不修改老旧代码的前提下解决这个问题，K8s 给出的标准答案是：Sidecar 模式。 Pod 的本质： Pod 不是一个容器，而是一个“容器组”。同一个 Pod 内的多个容器共享网络（loc