update

.vuepress/config.js

@@ -365,7 +365,19 @@ export default defineUserConfig({
  '/GitOps/ArgoCD.md',
  '/GitOps/conclusion.md',
  ]
- }
+ }/*
+ ,{
+ text: '第十一章：构建大模型计算平台',
+ collapsable: false,
+ sidebarDepth: 1,
+ link: '/AI/summary.md',
+ children: [
+ '/AI/background.md',
+ '/AI/RDMA.md',
+ '/AI/Storage.md',
+ '/AI/GPU.md'
+ ]
+ },*/
  ]
  })
 });

GitOps/Tekton-test.md

@@ -1,6 +1,8 @@
 # 10.4.3 创建 Task
 
-流水线的第一个任务是先 Clone 应用程序代码进行测试。先创建一个 Task 用来 Clone 程序代码并进行测试，Task 的资源文件（task-test.yaml ）内容如下所示。
+流水线的第一个任务是从 Git 仓库中拉取代码进行集成测试。
+
+先创建一个 Task 类型的 yaml 文件（task-test.yaml），其内容如下所示：
 
 ```yaml
 apiVersion: tekton.dev/v1
@@ -19,8 +21,7 @@ spec:
  command: ["go"]
  args: ["test"]
 ```
-
-Task 的作用是从一个 Git 仓库获取代码，并使用 golang:1.14-alpine 容器镜像在 /workspace/repo 目录下运行 go test 命令来执行测试。
+上面代码的作用是从一个 Git 仓库拉取代码，使用 golang:1.14-alpine 镜像在 /workspace/repo 目录下运行 go test 命令执行测试。
 
 将 Task 提交到 Kubernetes 集群。
 
@@ -29,9 +30,9 @@ $ kubectl apply -f task-test.yaml
 task.tekton.dev/test created
 ```
 
-Task 只是声明了我们要做什么，是一个静态的对象，如果要得到其结果，还得再定义一个 TaskRun 实例化和执行上面的 Task。
+Task 只是声明了我们要做什么，如果要真正执行任务，还得再定义一个 TaskRun 对象，用来实例化和执行上面的 Task。
 
-接下来创建一个 TaskRun 对象，资源文件（test-run.yaml ）内容如下所示。
+接下来创建一个 TaskRun 类型的 yaml 文件（test-run.yaml），其内容如下所示：
 
 ```yaml
 apiVersion: tekton.dev/v1
@@ -46,23 +47,21 @@ spec:
  value: "https://github.com/isno/tekton-example"
 ```
 
-TaskRun 通过 taskRef 引用上面定义的 Task ，并传递名为 repo 的参数来执行具体。
+上面的代码中，TaskRun 通过 taskRef 关联名称为 test 的 Task ，并传递名为 repo 参数给 Task。
 
 :::tip 注意
+TaskRun 没有指定 name，是用的 generateName，该对象也必须使用 create 命令来创建，而不是 apply。
 
-TaskRun 没有指定 name，而是用的 generateName。同时该对象也必须使用 create 命令来创建，而不是 apply。
-
-这是因为一个 TaskRun 只能触发一次任务运行，而一个任务可能会反复运行，如果在 TaskRun 中写死名称，就会导致该任务只会触发一次，就算 apply 多次也会因内容没有变化被忽略掉。
-
+这是因为一个任务可能会反复运行，如果在 TaskRun 中写死名称，会导致该任务只会触发一次，就算 apply 多次也会因内容没有变化被忽略掉。
 :::
 
-将 TaskRun 提交到 kubernetes 集群之后 Task 开始自动执行。
+将 TaskRun 提交到 Kubernetes 集群之后，测试 Task 开始自动执行。
 
 ```bash
 $ kubectl create -f test-run.yaml 
 ```
 
-查看 TaskRun 资源对象的状态确认构建结果。
+在 Kubernetes 集群中，查看 TaskRun 的状态确认运行结果。
 
 ```bash
 $ kubectl get taskrun

network/networking.md

@@ -2,7 +2,7 @@
 
 客户端发起请求，先通过 DNS 获得目的地 IP，然后封装成 HTTP 协议，数据包经过路由，还有拥塞控制，最终到达目的地网卡（eth0），并进入 Linux 内核。
 
-这一节，笔者根据图 3-1 所示的 Linux ingress 架构，概述数据包在 Linux 内核中是被如何处理的。
+这一节，我们根据图 3-1 所示的 Linux ingress 架构，了解数据包在 Linux 内核中是被如何处理的。
 
 <div align="center">
  <img src="../assets/networking.svg" width="650" align=center />
@@ -20,9 +20,8 @@
 7. 内核中传输层协议栈：L4（Transport Layer）处理。
 8. 网络协议栈处理数据后，并将其发送到对应应用的 socket 接收缓冲区。
 
-如以上的过程所示，设计一个 C10M（Millions of concurrent Connections，单机 1000 万并发）[^1]的系统或者组建一个大规模的容器网络，那就不能忽略 Linux 内核带来的各种影响，这些影响包括用户进程调用系统进入内核态的开销，响应数据包时产生的硬中断开销，以及 ksoftirqd 处理软中断而产生的上下文开销等等
+如以上的过程所示，设计一个 C10M（Millions of concurrent Connections，单机 1000 万并发）[^1]的系统或者组建一个高性能计算集群，那就不能忽略 Linux 内核带来的各种影响，这些影响包括用户进程调用系统进入内核态的开销，响应数据包时产生的硬中断开销，以及 ksoftirqd 处理软中断而产生的上下文开销等等。
 
-无论是高并发的技术挑战，还是容器网络中 overlay/underlay 的设计选型，关乎这两者设计影响的是：**“用户态内核态的频繁转换、网络协议栈的冗长流程”**，也就是说内核才是导致瓶颈的原因所在。
 
 下一节，我们将继续深入 Linux 内核网络框架，了解数据包在内核协议栈中是如何被过滤、修改和转发的。