更新 gitops

GitOps/summary.md

@@ -1,12 +1,11 @@
 # 第十章 GitOps 落地实践
 
-工欲善其事必先利其器，软件研发的管理是一件非常复杂的事情。业务系统有多么复杂，研发管理就有多么复杂
+现代软件工程领域中，无论是通过服务化的方式进行架构设计，还是使用敏捷开发流程，主要的目的都是提高开发效率，因此应用的构建和部署也要跟得上迭代的脚步。随着云原生技术和 PaaS 平台的普及以及 DevOps 文化的盛行，人们也一直在寻找一种能更好解决云环境中持续部署的最佳实践。在云原生时代继承 DevOps 思想，加速持续集成和持续部署的，这就是 GitOps。
 
-随着 DevOps 文化的盛行，人们也一直在寻找一种能更好解决云环境中持续部署的最佳实践。
 
 GitOps 起源于 weaveworks 公司在 2017 年发表的一篇博客：​GitOps - Operations by Pull Request[^1]。在这篇文章中，作者 Alexis Richardson 介绍了一种以 Git 为唯一事实来源的软件部署方式。在这种方式下，我们需要将软件设施定义在 Git 仓库中进行管理，这里的软件设施不限于应用本身，也包括 IaaS、Kubernetes 这样的基础设置。每个工程师都可以通过提交 Pull Request 来修改软件设施，然后通过自动化程序（譬如 Flux CD、Argo CD）的方式在线上执行这些修改。
 
-这种方式的交付（使用声明式描述、使用 Git 类似的版本控制系统进行跟踪管理、更优雅的可观测性）不仅缩短了构建过程、提高部署速度，更为
+这种方式的交付（使用声明式描述、使用 Git 类似的版本控制系统进行跟踪管理、更优雅的可观测性），开发人员可以更高效地将注意力集中在创建新功能而不是运维相关任务上（例如，应用系统安装、配置、迁移等）。
 
 
 

container/k8s-deploy-clilium.md

@@ -1,5 +1,9 @@
 # 使用 clilium 配置网络
 
+cilium和其他的cni组件最大的不同在于其底层使用了ebpf技术，而该技术对于Linux的系统内核版本有较高的要求
+
+cilium官方还给出了一份列表描述了各项高级功能对内核版本的要求：
+
 |  特性 |  最低版本 |  
 |---|---|
 | Bandwidth Manager（带宽管理器）  | >= 5.1  |

container/k8s-deploy-containerd.md

@@ -1,3 +1,27 @@
 # 配置容器运行时 containerd 
 
 
+https://www.huaqiang.art/assets/img/kubelet-containerd.png
+
+
+在 Linux 上，控制组（CGroup）用于限制分配给进程的资源。kubelet 和底层容器运行时都需要对接控制组来强制执行 为 Pod 和容器管理资源 并为诸如 CPU、内存这类资源设置请求和限制。若要对接控制组，kubelet 和容器运行时需要使用一个 cgroup 驱动。关键的一点是 kubelet 和容器运行时需使用相同的 cgroup 驱动并且采用相同的配置。
+
+配置 systemd cgroup 驱动
+
+可用的 cgroup 驱动有两个：
+
+- cgroupfs：当使用 cgroupfs 驱动时，kubelet 和容器运行时将直接对接 cgroup 文件系统来配置 cgroup。
+- systemd
+
+
+
+在 /etc/containerd/config.toml 中设置
+
+```
+[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
+  ...
+  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
+    SystemdCgroup = true
+```
+
+debian 系统，centos7 系统，都是使用 systemd 初始化系统的。systemd 这边已经有一套 cgroup 管理器了，如果容器运行时和 kubelet 使用 cgroupfs，此时就会存在 cgroups 和 systemd 两种 cgroup 管理器。也就意味着操作系统里面存在两种资源分配的视图，当操作系统上存在 CPU，内存等等资源不足的时候，将 kubelet 和容器运行时配置为使用 cgroupfs、但为剩余的进程使用 systemd 的那些节点将在资源压力增大时变得不稳定。