cloud
k8s 容器热替换/重启主进程 - gdb execve syscall 法
· ☕ 8 åˆ†é’Ÿ
k8s 环境下,在不停止或重启 container 的情况下,重启应用进程(pid:1),甚至重新加载运行新版本的应用。本文以 gdb 作为工具,调用 execve syscall,去实现这个目标。

k8s 容器热替换/重启主进程 - gdb exec 法
· ☕ 6 åˆ†é’Ÿ
k8s 环境下,在不停止或重启 container 的情况下,重启应用进程(pid:1),甚至重新加载运行新版本的应用。本文以 gdb 作为工具,调用应用容器自带的 libc 的 close & exec 法函数,去实现这个目标。

调试与观察 istio-proxy Envoy sidecar 的启动过程
· ☕ 7 åˆ†é’Ÿ
学习 Istio 下 Envoy sidecar 的初始化过程,有助于理解 Envoy 是如何构建起整个事件驱动和线程互动体系的。其中 Listener socket 事件监初始化是重点。而获取这个知识最直接的方法是 debug Envoy 启动初始化过程,这样可以直接观察运行状态的 Envoy 代码,而不是直接读无聊的 OOP 代码去猜现实行为。但要 debug sidecar 初始化有几道砍要过。本文记录了我通关打怪的过程。

调试 Istio 网格中运行的 Envoy sidecar C++ 代码
· ☕ 5 åˆ†é’Ÿ
调试在 Istio 网格中运行的 Envoy sidecar C++ 代码。 它有助于在代码级别深入研究 sidecar。 它使我们在解决 Istio 问题或编写更好的 EnvoyFilter 或 eBPF 跟踪程序时更有信心。 本文介绍如何使用 VSCode 和 lldb 调试 Envoy istio-proxy sidecar。

玩火的容器内存控制 CGroup - 容器基础拾遗 Part 1
· ☕ 20 åˆ†é’Ÿ
容器内存限制是个矛盾而重要的选择,给多了浪费资源,给少了服务随机崩溃。CGroup 内存控制是容器资源控制的核心。她是个规律严明的看守者,在应用超限时狠心地 OOM Klll。她同时也有宽容的一面,在应用资源不足时,调配和释放 Cache 给应用使用。而其内心的记账算法却耐人寻味。要观察和监控她的状态和行为,更是千条万绪。本文尝试用作分析和梳理。

上帝和 Istio 打架时,程序员如何自我救赎? —— 记一次开发 Envoy WASM Filter 修正任性的 HTTP Header
· ☕ 7 åˆ†é’Ÿ
在未引入 Istio 前正常 HTTP 200 的请求,引入后变为 HTTP 400 。出现问题的流量均带有不合 HTTP 规范的 HTTP Header。于是尝试开发 Envoy WASM Filter 修正错误的 HTTP Header 。

重新思考云原生时代的开发环境——从 Dev-to-Cloud 到 Dev@Cloud
· ☕ 7 åˆ†é’Ÿ
大背景 滾滾長江東逝水,浪花淘盡英雄。 作为一个一直在底层苦苦挣扎多年程序员,保持一分学习的好奇心,对技术时势的感知,由为重要。因为这最终决定了

记一次 Istio 冲刺调优
· ☕ 5 åˆ†é’Ÿ
为何要调优 如果说,引入一个技术需要兴趣和冲劲,那么,让这个技术上线需要的是坚持和执着。 Cloud Native 如是, Istio 如是。 在上线前的性能测试中,Istio 的使

K8s Custom Resources(CR)
· ☕ 2 åˆ†é’Ÿ
Custom Resource 的入口 请求是这样分发到 api 扩展点的: 例如我们有 (Custom Resource)CR 1 2 3 4 5 6 7 8 apiVersion: cnat.programming-kubernetes.info/v1alpha1 kind: At metadata: name: example-at spec: schedule: "2019-07-03T02:00:00Z" status: phase: "pending" 相应的 CustomResourceDefinition (CRD) 会是