fakecore

引言 在现代云原生生态系统中，Kubernetes 和 Helm 被广泛用于资源部署和管理。Helm，作为 Kubernetes 的包管理工具，简化了应用的部署和管理。然而，在使用 Operator 部署非 Helm 管理的 Kubernetes 资源时，如 DaemonSet，我们面临一个独特的挑战：如何在卸载时正确处理这些资源。 问题深入 通常，Helm Chart 定义了资源的卸载顺序。但当涉及到 Operator 直接管理的资源时，例如 DaemonSet，这些资源并不在 Helm Chart 的控制之下。因此，在执行 Helm 卸载操作时，可能会导致相关 RBAC 资源先于 DaemonSet 的 Pods 被删除，进而导致 Pods 中的 pre-stop 钩子执行失败，留下未清理的资源。 解决方案介绍 为了应对这一挑战，我们可以利用 Kubernetes 的 finalizers 和 Helm 的 pre-delete 钩子。Finalizers 允许在删除 Kubernetes 对象之前执行清理逻辑，而 pre-delete 钩子则允许我们在 Helm 删除资源之前进行干预。 实现细节 Finalizers 的应用：我们在 Custom Resource (CR) 中添加 finalizers 字段，这确保在完全删除资源之前，可以执行必要的清理步骤。 Pre-delete 钩子的使用：通过添加一个 Job 作为 pre-delete 钩子，该 Job 触发 kubectl delete clusteroperator 命令，在 Helm 卸载流程中先行执行。...

Hi,大家好,我是fakecore. 这次是我第一次写年终总结.有点不知道该写点啥. 今年算是我的改变之年,把拖延症给修复了不少(感谢某人),一直在追热点(一直追不上), 偶尔会想要写文章(虽然还是没有输出) 从去年下半年开始到今年上半年在前司呆到焦躁,不知道我该做什么能缓解焦虑之后. 我决定开始寻找工作机会.花了几个月找到一份非常不错的工作. 在小厂,WLB. 做云原生的infra(gou-operator)相关. 挺幸运的,加入之后就处在学习,干活的循环. 充实且享受. 今年在开源都没做什么东西.尝试写了一两个小demo,但是自己写的都不太满意,也没有公开.希望明年能够有能够分享的东西 今年上半年还在持续学习英语口语,但自从换工作后,时间不太够,就把重心转到工作了. 真希望人类的一天能有48h啊 关于明年: 首先,祝君好,希望世界和平 第二,想做一些开源的贡献,以及自己维护一个项目(脑子里idea很多) 第三.多写点文章(输出). 第四.口语/书面英语的增近 第五. 答案是""?

cgroup(control group)将一组任务与一个或多个子系统的一组参数相关联 用来控制,限制单个进程或者进程组的资源(CPU,内存,IO等等) docker就是用cgroup技术进行container的资源限制 cgroup的历史与演变 cgroup v1 资源控制 涉及的资源控制组有: CPU (cpu 子系统)： CPU 访问和使用的限制和控制。 可以设置进程组的相对权重。 CPU 帐户 (cpuacct 子系统)： 报告进程组使用的总CPU时间。 内存 (memory 子系统)： 限制进程组的内存使用。 报告内存使用统计信息。 可以设置硬限制和软限制。 块设备I/O (blkio 子系统)： 控制和限制块设备的输入/输出。 可以设置读/写的I/O带宽限制或IOPS限制。 网络 (net_cls 和 net_prio 子系统)： net_cls：标记网络数据包，使其可以被流量控制工具（如 tc）处理。 net_prio：为每个网络接口设置优先级。 设备访问 (devices 子系统)： 控制进程组对设备的访问。 Freezer (freezer 子系统)： 允许你暂停或恢复进程组的所有任务。 进程号 (pid 子系统)： 限制进程组中的进程数量。 cpuset (cpuset 子系统)： 指定进程组可以使用的CPU和内存节点。 perf_event (perf_event 子系统)： 允许监控进程组的性能事件。 cgroup 命名空间 (ns 子系统)： 为进程组提供独立的cgroup命名空间视图。 rdma (rdma 子系统)： 管理和限制RDMA/InfiniBand资源。 Hierarchy 层次结构 层次结构是cgroup的组织方式,决定了对于进程如何进行分组和管理....

最近刚好遇到多容器单Pod的数据共享需求. 随着需求做完,想着写点文章分享下. 本文只分享两个场景,共享空目录,共享非空目录 背景知识 Pod Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元 可以在单个Pod中创建多个Container,他们之间共享上下文 Pod 的共享上下文包括一组 Linux 名字空间、控制组（cgroup）和可能一些其他的隔离方面， 即用来隔离容器的技术。 在 Pod 的上下文中，每个独立的应用可能会进一步实施隔离。 Pod 类似于共享名字空间并共享文件系统卷的一组容器。 Volume Kubernetes 卷（Volume） 这一抽象概念用于解决Container文件存储和跨Container数据共享问题 共享空目录 这个场景比较常见,也比较好处理. 通常使用volumes中的emptyDir来处理 https://kubernetes.io/zh-cn/docs/concepts/storage/volumes/#emptydir apiVersion: v1 kind: Pod metadata: name: test-pd spec: containers: - image: registry.k8s.io/test-webserver name: test-container volumeMounts: - mountPath: /cache name: cache-volume - image: registry.k8s.io/test-webserver name: test-container1 volumeMounts: - mountPath: /cache name: cache-volume volumes: - name: cache-volume emptyDir: {} test-conainer和test-conainer1的/cache目录就进行保持共享,当然你要记住,之前存在于/cache的内容将会无法看到 共享非空目录 k8s本身的设计,不允许直接挂载非空目录, 所以我们这里使用initContainer进行操作 apiVersion: apps/v1 kind: Pod spec: initContainers: - image: name: command: [ "/bin/sh", "-c", "mkdir /tmp/dir; cp -r /target/folder /tmp/dir", ] volumeMounts: - name: sharing mountPath: /tmp/dir containers: - image: name: volumeMounts: - name: sharing mountPath: /usr/local/sharing volumes: - name: sharing emptyDir: {} 在PodInitialization的过程中,首先会启动initContainer....

Desc Text.

Desc Text.