Posts

前言 这篇博客是属于对《Kubernetes Operator 进阶开发》的初步章节一个笔记总结，作为 2023 第一篇博文，也作为重新深入梳理 K8s 的基础，往后会逐步将之前的坑给填上 Operator的基本概念 作为最入门的篇章，我们将从写一个 Demo 开始，在这里将默认已经存在了一个可用的集群环境，当然如果在开始学习之前，你能有一些 Client-Go 基础那就再好不过了 控制器模式 控制器模式在日常生活中的应用非常广泛，也是根据原书的例子进行举例，当然这里缩减了非常多，也加入了些个人的想法 夏天我们需要调整空调制冷，现在过程如下： 空调启动后设置一个温度，例如 25 度 空调检测室温，确定室温是否高于目标值 如果高于目标阈值，例如室温 27 度，则开始制冷操作 如果低于目标阈值，保持静默到下一个探测周期 这其实就是控制器模式典型的工作流程，外部输入一个 “期望值”，期间一个 “控制器” 不断按照 “周期” 观测 “环境状态” 的 “实际值” 和 “期望值” 之间的差异，然后不断调整两者，以便维持平衡，这个过程则被称为 “调谐” Kubernetes中的控制器 Kubernetes 中通过 “声明式API” 定义了一系列的资源对象，然后通过许多的 Controllers 来 “调谐” 这些资源对象的实际状态以向期待状态靠拢，从而实现整个集群 “尽可能” 靠拢配置中声明的期望状态 一个Deployment的创建 我们都知道集群中有个组件，叫做 Kube-Controller-Manager，这个组件就是一系列控制器的集合，现在可以重新梳理一下这个面试中经常被问到的问题了 在编辑好一个 Deployment YAML 配置文件并使用 Kubectl 提交后，这个资源声明就被传递给了 Kube-ApiServer，接着 Kube-Controller-Manager 中的 Deployment 控制器监听到了消息，注意 K8s 中的组件传递原则 — 是上层组件先将自身置于被修改后的状态，即先假设资源已经被创建，而下层组件监听到了上游变化后，将自身或者环境状态 “调谐” 为上游一致，在这里 Deployment Controller 根据 Spec 字段的定义创建对应的 ReplicaSet 资源，而 RS Controller 监听到了 RS 的变化，并也根据 Spec 字段中声明创建了 Pod，这里其实还有一个 Kubelet 的环节在中间，只是这里被我们抽象掉了...

KVM 是一种让 Linux 变成虚拟机监控程序的技术，它可以让多个虚拟机在同一台物理机上运行。为了让虚拟机正常运行，KVM 需要一些操作系统的组件，如内存管理器、进程调度程序、输入/输出堆栈、设备驱动程序、安全管理器和网络堆栈等，这些组件都包含在 KVM 中。每个虚拟机都像一个 Linux 进程一样运行，使用虚拟的硬件设备，如网卡、图形适配器、CPU、内存和磁盘等。 初始化和安装软件依赖 由于 KVM 和 Linux 内核紧密相关，所以为了保持文档的一致性，我们这里使用 5.15 版本的 Ubuntu 内核 $ uname -a Linux sxueck-server 5.15.0-1034-realtime #37-Ubuntu SMP PREEMPT_RT Wed Mar 1 20:50:08 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux $ sudo apt update $ sudo apt upgrade $ sudo apt -y install bridge-utils cpu-checker libvirt-clients libvirt-daemon qemu qemu-kvm genisoimage libguestfs-tools linux-tools-common $ echo 1024 | sudo tee /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages # 启用hugepages 在进行任务之前，我们需要对前置条件进行检查...

引言 最近在阅读 《Linux内核观测技术BPF》这本书，非常薄的一本书却能带领我走入 Bpf 技术的世界，但是它只能起到一个入门的作用，用于工作的时候还是有点捉襟见肘，这篇文章只能当成一个较为深入的理解，不能取代系统性的学习。 当我们使用网络应用时，性能和可靠性是至关重要的。然而，由于内核网络栈的设计和实现方式，传统的用户空间网络应用在处理大量网络流量时会面临性能瓶颈。为了解决这一问题，Linux 内核引入了一种名为 eBPF（Extended Berkeley Packet Filter）的技术，它允许开发人员在内核中运行自定义的代码，从而提高网络应用程序的性能和灵活性。而下面要重点提到的 XDP（eXpress Data Path）是 eBPF 的一个子集，提供了一种快速的数据处理方法，它通过在数据包接收阶段运行代码来提高网络应用的性能。 这里有个点需要注意一下，eBPF 和 BPF 都是一种可以在Linux内核中使用的虚拟机技术，但是它们有一些不同之处，BPF 最初是一种用于数据包过滤的技术。随着时间的推移，它的功能逐渐扩展，被用于在内核中运行的各种任务，例如系统跟踪和安全审计等。BPF 程序在内核中直接执行，它可以访问内核数据结构，但是它的功能和灵活性受到了一些限制。 而 eBPF 是对 BPF 的扩展，即 “extended BPF”。它通过引入一个新的指令集，允许在内核中运行的 BPF 程序更加灵活和强大。eBPF 可以在安全的环境下执行用户定义的代码，而不会影响内核的稳定性和安全性。eBPF 还支持在内核和用户空间之间进行通信，并提供了一些新的功能，例如支持用户定义的映射和钩子程序。 总的来说，eBPF 是 BPF 的一个更加灵活和功能强大的版本，它为内核和用户空间提供了更多的通信和交互能力，同时保持了与内核的兼容性和安全性。我们入门的话会从 BPF 开始进行解析。 微服务时代Linux内核的问题 如果论起 eBpF 最出名的案例，莫过于 Cilium 了，我参考了 Cilium 项目发起人的演讲《How to Make Linux Microservice-Aware with Cilium and eBPF》，在云原生时代，为什么 eBpf 至关重要。而他其中列出了四个为什么当前 Linux 内核不适合当前的时代（背景为内核尚未对云原生做支持的时代）。 Abstractions 抽象 上图是一张和网络相关的抽象，它清晰地展示了 Linux 内核中各个部分的抽象，例如如果我们想用 Netfilter 做包过滤，那就必须要经过 socket 和 TCP 协议栈。而如果从网卡往上看的话，包需要经过 Netdevice -> traffic shaping -> Ethernet 等等才能到达上部分应用。...

年底事情太多了，加上最近 COVID-2019 的事件，我也不幸中招，一直没有时间更新博客 分数就当乐呵就行，纯当给生活增点趣味 SSL 安全评分 SSL 技术评分 A+ 级 速度 谷歌 Insights 评分满分 Gtmetrix 速度测试优秀 至此也算给 2022 画上一个极其潦草的句号（明年保证将以前的坑填完！！！）

前言 K3s 自带的 SQLite 应付普通的嵌入式小服务来说绰绰有余，但是对于公司这种动辄吃掉几个核的高频调度来说，虽然勉强能支撑起日常的响应，却总有时候出现奇奇怪怪的 BUG，我已经不止一次碰到了因为默认 ServiceAccount 和 Namespace 中的资源无法做实时绑定，导致 SpringCloud 一直无法正常启动的问题了，虽然可以通过万能重启做解决，但这远算不上高可用边缘部署方案 下面是官方给 K3s 画的一副简图，我们之前已经将默认的 LB 换成了 MetaLB 并表示效果非常优秀，这次我们也来缝缝补补，按照文档来说，K3s 支持以下的外接数据库 K3s supports the following datastore options Embedded SQLite PostgreSQL (certified against versions 10.7, 11.5, and 14.2) MySQL (certified against versions 5.7 and 8.0) MariaDB (certified against version 10.6.8) Etcd (certified against version 3.5.4) Embedded etcd for High Availability 因为想要为以后的 Cluster Metrics 做接口准备，所以就暂时不考虑内嵌 Etcd 的方式，而是选择自己外接，这样对于整个集群的运行状况有一个直观的了解，也方便做监控 —— K3s 砍去了太多东西换取轻量化 我们都知道 K8s 的默认 Datastore 是 Etcd，而 K3s 则是使用了一种称为 Kine 的组件将 Etcd 的 K/V 操作翻译为了关系数据库的语法，Kine 将自己的接口暴露给 K3s ApiServer，也就是说，在集群组件看起来，自己还是针对 Etcd 进行读写，然而如果我们设置真正的 Etcd Backend，Kine 会略过并直接暴露真实的 Etcd-servers 给 K3s ApiServer...

公司的某一台即将交付的生产环境数据库处理异步请求忽然异常缓慢，而且同事反馈说安装软件也有卡顿情况。 问题排查流程 初步尝试 首先我尝试将 PgSQL 服务进行重启，因为服务的异步处理速度延迟达到了1秒之久，况且该服务的依赖性没有那么高 $ kubectl rollout restart -n databases statefulset postgres-postgresql 结果出现了麻烦，整个 Pods 一直处于 Terminating 状态，一开始还以为是 PreStop 任务没有处理结束导致堵塞，后来发现 PgSQL 的日志已经在几分钟之前就不输出了，看起来是集群没有进行处理。 $ kubectl get event -n databases 47m Warning Unhealthy pod/postgres-postgresql-0 Liveness probe errored: rpc error: code = NotFound desc = failed to exec in container: failed to load task: no running task found: task dbd0aae87722bdababfdf720ec389aaeaab040f594b782451ea39edfbc1261bb not found: not found 47m Warning Unhealthy pod/postgres-postgresql-0 Readiness probe errored: rpc error: code = NotFound desc = failed to exec in container: failed to load task: no running task found: task dbd0aae87722bdababfdf720ec389aaeaab040f594b782451ea39edfbc1261bb not found: not found 通过查看错误事件即可发现，是清理 Container 的任务无法被正确处理，让我们手动清理一下...