update

huataihuang · Aug 20, 2023 · 1322a71 · 1322a71
1 parent 3f4c7fe
commit 1322a71
Show file tree

Hide file tree

Showing 26 changed files with 147 additions and 47 deletions.
diff --git a/source/arm/raspberry_pi/startup/pi_400_4k_display.rst b/source/arm/raspberry_pi/startup/pi_400_4k_display.rst
@@ -17,7 +17,7 @@ Raspberry Pi 400的4K显示
 
 当我在YouTube上看到能够 :ref:`fydeos_pi` ，让我非常心动：仅仅500RMB就能够实现Linux融合Android应用，能够用Android应用软件来补充Linux桌面应用，应该是非常适合工作环境。 
 
-我购买了4K显示器和 :ref:`pi_400` ，想要实现一个轻量级的Linux开发环境(大量的计算和部署实践在我的 :ref:`pi_cluster` 通过 :ref:`kubernetes_arm` 实现)。不过，当我使用中发现:
+我购买了4K显示器和 :ref:`pi_400` ，想要实现一个轻量级的Linux开发环境(大量的计算和部署实践在我的 :ref:`pi_cluster` 通过 :ref:`arm_k8s` 实现)。不过，当我使用中发现:
 
 - 在Raspberry Pi 400上如果配置了 ``hdmi_enable_4kp60=1`` ，则重启系统后，4K显示器在 :ref:`xfce` 的Display配置中，虽然刷新率确实是 ``60Hz`` ，但是分辨率最高只有 ``1920x1080`` ，无法设置更高的分辨率。
 - 如果去掉 ``hdmi_enable_4kp60=1`` ，则Raspberry Pi 400能够自动检测到4K显示器并且设置最高分辨率 ``3840*2160`` ，但是很不幸，刷新率只有 ``30Hz``

diff --git a/source/arm/raspberry_pi/startup/pi_400_desktop.rst b/source/arm/raspberry_pi/startup/pi_400_desktop.rst
@@ -8,7 +8,7 @@ Raspberry Pi 400桌面定制
 
 .. note::
 
-   当前Raspberry Pi OS没有提供官方64位操作系统，所以 :ref:`pi_400` 运行的是32位操作系统。为了能够充分发挥 :ref:`pi_4` 的64位架构能力( :ref:`pi_cluster` 使用的是 :ref:`pi_4` 的8G内存硬件 )，同时构建 :ref:`kubernetes_arm` 集群，在服务器端我使用的是64位Ubuntu ARM版本。
+   当前Raspberry Pi OS没有提供官方64位操作系统，所以 :ref:`pi_400` 运行的是32位操作系统。为了能够充分发挥 :ref:`pi_4` 的64位架构能力( :ref:`pi_cluster` 使用的是 :ref:`pi_4` 的8G内存硬件 )，同时构建 :ref:`arm_k8s` 集群，在服务器端我使用的是64位Ubuntu ARM版本。
 
 目标
 ======
@@ -20,7 +20,7 @@ Raspberry Pi 400桌面定制
 
 - 本地开发环境通过Docker来构建
 
-  - 为了能够降低客户端资源消耗，我使用多台树莓派和Jetson Nano构建 :ref:`kubernetes_arm` ，所以容器都运行在服务器端，桌面电脑几乎不需要消耗资源
+  - 为了能够降低客户端资源消耗，我使用多台树莓派和Jetson Nano构建 :ref:`arm_k8s` ，所以容器都运行在服务器端，桌面电脑几乎不需要消耗资源
 
 安装
 =====

diff --git a/source/clang/upgrade_gcc_on_ubuntu22.04.rst b/source/clang/upgrade_gcc_on_ubuntu22.04.rst
@@ -4,7 +4,7 @@
 Ubuntu 22.04升级GCC
 ===========================
 
-其实没有必要在 :ref:`ubuntu_linux` 22.04 上升级GCC，因为发行版提供的 gcc 11.3 已经足够新，支持足够的C feature。不过，我最近在 :ref:`upgrade_gcc_on_suse12.5` 编译GCC非常缓慢，考虑到服务器是多核处理器性能足够强劲，但是依然没有快速完成编译，显然是编译并行没有搞好。所以我想重新在我的 ``zcloud`` 上验证以下并行编译和非并行编译的差异。(对于 :ref:`gentoo_linux` 的 :ref:`emerge` 配置参数有)
+其实没有必要在 :ref:`ubuntu_linux` 22.04 上升级GCC，因为发行版提供的 gcc 11.3 已经足够新，支持足够的C feature。不过，我最近在 :ref:`upgrade_gcc_on_suse12.5` 编译GCC非常缓慢，考虑到服务器是多核处理器性能足够强劲，但是依然没有快速完成编译，显然是编译并行没有搞好。所以我想重新在我的 ``zcloud`` 上验证以下并行编译和非并行编译的差异。
 
 - 编译准备: 安装基本GCC toolchain和扩展工具
 

diff --git a/source/gluster/performance/gluster_tunning.rst b/source/gluster/performance/gluster_tunning.rst
@@ -7,8 +7,6 @@ GlusterFS性能优化
 对比
 =====
 
-软件版本都是 GlusterFS 11 ，区别是操作系统和内核
-
 CentOS7.2服务端/SuSE15.5客户端
 --------------------------------
 
@@ -35,7 +33,7 @@ CentOS7.2服务端/SuSE15.5客户端
 CentOS7.2服务端/SuSE12.5客户端
 --------------------------------
 
-再次部署 :ref:`deploy_centos7_suse15_suse12_gluster11` ，同样复制客户端 ``/usr`` 目录(1.9GB，大约6.24w文件)复制到GlusterFS卷::
+再次部署 :ref:`deploy_centos7_suse15_suse12_gluster11` ，同样复制客户端 ``/usr`` 目录(4.3GB，大约12w文件)复制到GlusterFS卷::
 
    # time cp -R /usr/ /data/backup
 
@@ -51,10 +49,28 @@ CentOS7.2服务端/SuSE12.5客户端
    user    0m0.227s
    sys     0m1.779s
 
-初步结论
----------
+CentOS7.2服务端/SuSE12.5客户端(软RAID)
+-----------------------------------------
+
+改进部署 :ref:`deploy_centos7_gluster11_lvm_mdadm_raid10` ，同样复制客户端 ``/usr`` 目录(4.3GB，大约12w文件)复制到GlusterFS卷::
+
+   # time cp -R /usr/ /mqha/foreignexmuamqha/
+   
+   real    3m35.887s
+   user    0m1.137s
+   sys     0m7.584s
+
+可以看到性能略有提升，耗时降低了 25%
+
+删除文件::
+
+   # time rm -rf /mqha/foreignexmuamqha/usr
+   
+   real    1m48.089s
+   user    0m0.450s
+   sys     0m2.209s
 
-操作系统对GlusterFS性能的影响较大，明显看到客户端从 SuSE 12 (kernel 4.12) 升级到 SuSE 15 (kernel 5.14)，大约能够获得 30% 的性能提升。推测操作系统的内核默认参数也有一些优化，所以推荐采用新版本操作系统。
+总体来说，采用 :ref:`linux_software_raid` 构建大容量磁盘(同时降低了brick数量)对于性能似乎有所提高。我感觉可能还是客户端的分发性能没有优化，无法充分利用多bricks的优势，反而被客户端瓶颈拖累了...
 
 优化思路
 ==========

diff --git a/source/kubernetes/concepts/objects/labels_and_selectors.rst b/source/kubernetes/concepts/objects/labels_and_selectors.rst
@@ -37,7 +37,7 @@ Node的众所周知标签、申明、瑕疵
 标签实践
 =========
 
-- 首先需要准备一个Kubernetes集群，我采用 :ref:`kubernetes_arm` ::
+- 首先需要准备一个Kubernetes集群，我采用 :ref:`arm_k8s` ::
 
    kubectl get nodes -o wide --show-labels
 

diff --git a/source/kubernetes/deploy/deploy_pod/k8s_django.rst b/source/kubernetes/deploy/deploy_pod/k8s_django.rst
@@ -9,7 +9,7 @@ Kubernetes环境部署Django应用
 准备
 =====
 
-我部署了 :ref:`kubernetes_arm` 来完成自己的一系列学习和测试，所以在这里部署Django应用，也采用这个ARM集群。
+我部署了 :ref:`arm_k8s` 来完成自己的一系列学习和测试，所以在这里部署Django应用，也采用这个ARM集群。
 
 - 检查集群::
 

diff --git a/source/kubernetes/monitor/prometheus/promql/promql_basics.rst b/source/kubernetes/monitor/prometheus/promql/promql_basics.rst
@@ -16,6 +16,35 @@ Prometheus的表达式语言(Expression language)中，表达式 或 子表达
 - 标量(Scalar) - 一个简单的浮点数字值
 - 字符串(String) - 一个简单的字符串值，目前未使用
 
+.. note::
+
+   Tips: 其实我开始的时候也不适应 ``PromQL`` ，毕竟 PromQL 内置指标非常多，得摸索。不过，我发现 :ref:`gpt` 能够提供很好的起步参考(简单向GPT-3.5提出需要查询prometheus的要求就能返回一些案例和解释，稍加修改就能使用)
+
+内置指标
+==========
+
+PromQL提供了很多非常有用的Kubernetes集群内置指标，只需要检查查询这些指标就能获得集群概况，加上一些 ``label`` 过滤(类似 :ref:`sql` 的 ``where`` )就能组装成所需的查询:
+
+- ``kube_pod_status_phase`` Pod状态:
+
+.. literalinclude:: promql_basics/kube_pod_status_phase_running
+   :caption: 查询集群中指定 ``<YOUR_NAMESPACE>`` 中处于 ``Running`` 状态Pod数量
+
+- 增加限定: 在 ``kube_pod_status_phase`` PromQL内置指标，可以使用 ``namespace`` , ``phase`` , ``deployment`` 等标签来筛选指定 Namespace 中处于 Running 状态且属于指定 Deployment 的 Pod:
+
+.. literalinclude:: promql_basics/kube_pod_status_phase_running_deployment
+   :caption: 查询集群中指定 ``<YOUR_NAMESPACE>`` 中且指定 ``<YOUR_DEPLOYMENT_NAME>`` 的处于 ``Running`` 状态Pod数量
+
+- 分组统计(类似于 :ref:`sql` 的 ``GROUP BY`` ): 将上述查询按照 ``Deployment`` 进行分组:
+
+.. literalinclude:: promql_basics/kube_pod_status_phase_running_deployment_count_by_deployment
+   :caption: 按照 ``Deployment`` 统计(count)集群中指定 ``<YOUR_NAMESPACE>`` 中且指定 ``<YOUR_DEPLOYMENT_NAME>`` 的处于 ``Running`` 状态Pod数量
+
+- 找 ``cluster`` 和 ``deployment`` 分组:
+
+.. literalinclude:: promql_basics/kube_pod_status_phase_running_deployment_count_by_cluster_deployment
+   :caption: 按照 ``Cluster`` 和  ``Deployment`` (组合进行分组) 统计(count)集群中指定 ``<YOUR_NAMESPACE>`` 中且指定 ``<YOUR_DEPLOYMENT_NAME>`` 的处于 ``Running`` 状态Pod数量
+
 快速起步
 =========
 

diff --git a/source/kubernetes/monitor/prometheus/promql/promql_basics/kube_pod_status_phase_running b/source/kubernetes/monitor/prometheus/promql/promql_basics/kube_pod_status_phase_running
@@ -0,0 +1 @@
+count(kube_pod_status_phase{namespace="<YOUR_NAMESPACE>", phase="Running"})
diff --git a/...bernetes/monitor/prometheus/promql/promql_basics/kube_pod_status_phase_running_deployment b/...bernetes/monitor/prometheus/promql/promql_basics/kube_pod_status_phase_running_deployment
@@ -0,0 +1 @@
+count(kube_pod_status_phase{namespace="<YOUR_NAMESPACE>", phase="Running", deployment="<YOUR_DEPLOYMENT_NAME>"})
diff --git a/...promql/promql_basics/kube_pod_status_phase_running_deployment_count_by_cluster_deployment b/...promql/promql_basics/kube_pod_status_phase_running_deployment_count_by_cluster_deployment
@@ -0,0 +1 @@
+count by (cluster, deployment) (kube_pod_status_phase{namespace="<YOUR_NAMESPACE>", phase="Running"}) 
diff --git a/...metheus/promql/promql_basics/kube_pod_status_phase_running_deployment_count_by_deployment b/...metheus/promql/promql_basics/kube_pod_status_phase_running_deployment_count_by_deployment
@@ -0,0 +1 @@
+count by (deployment) (kube_pod_status_phase{namespace="<YOUR_NAMESPACE>", phase="Running"})
diff --git a/source/linux/gentoo_linux/：:w b/source/linux/gentoo_linux/：:w
diff --git a/source/linux/storage/disk/parted.rst b/source/linux/storage/disk/parted.rst
@@ -170,6 +170,9 @@ parted是一个创建和维护分区表的工具，提供了交互模式和直
 案例实践
 ============
 
+案例一
+---------
+
 在 :ref:`lfs_linux` 磁盘分区准备工作中，使用 ``parted`` 来完成分区
 
 - 初始化磁盘分区表（擦除原先的所有数据）::
@@ -200,6 +203,14 @@ parted是一个创建和维护分区表的工具，提供了交互模式和直
    /dev/sda2     499712 115234815 114735104 54.7G Linux filesystem
    /dev/sda3  115234816 118487039   3252224  1.6G Linux swap
 
+案例二
+-------
+
+在 :ref:`xfs_startup` 有一个很好的常见案例:
+
+.. literalinclude:: ../filesystem/xfs/xfs_startup/parted
+   :caption: 为 :ref:`linux_lvm` 准备磁盘
+
 参考
 =======
 

diff --git a/source/linux/storage/filesystem/xfs/xfs_startup.rst b/source/linux/storage/filesystem/xfs/xfs_startup.rst
@@ -55,17 +55,15 @@ XFS案例
 
 以下案例在LVM上创建XFS文件系统
 
-- 创建GPT分区::
+- 创建GPT分区:
 
-   parted -s /dev/nvme0n1 mklabel gpt
-   parted -s -a optimal /dev/nvme0n1 mkpart primary 0% 100%
+.. literalinclude:: xfs_startup/parted
+   :caption: 为 :ref:`linux_lvm` 准备磁盘
 
-如果有多个NVMe磁盘，依次执行::
+如果有多个NVMe磁盘，依次执行:
 
-   parted -s /dev/nvme0n2 mklabel gpt
-   parted -s -a optimal /dev/nvmd0n2 mkpart primary 0% 100%
-   parted -s /dev/nvme0n3 mklabel gpt
-   parted -s -a optimal /dev/nvmd0n3 mkpart primary 0% 100%
+.. literalinclude:: xfs_startup/parted_multi_disk
+   :caption: 多个磁盘分区
 
 - 完成后检查磁盘::
 
@@ -82,16 +80,10 @@ XFS案例
    └─nvme0n3p1 259:2    0  3.5T  0 part 
    ...
 
-- 创建逻辑卷::
+- 创建逻辑卷:
 
-   pvcreate /dev/nvme0n1p1
-   pvcreate /dev/nvme0n2p1
-   pvcreate /dev/nvme0n3p1
-
-   vgcreate vgdb /dev/nvme0n1p1 /dev/nvme0n2p1 /dev/nvme0n3p1
-
-   lvcreate -n log -l 10%FREE -i 3 -I 128k vgdb
-   lvcreate -n data -l 100%FREE -i 3 -I 128k vgdb
+.. literalinclude:: xfs_startup/lvm_striped
+   :caption: 创建条代化LVM卷
 
 说明:
 
@@ -106,8 +98,8 @@ XFS案例
 
 - 创建文件系统::
 
-   mkfs.xfs -n ftype=1 /dev/vgdb/log
-   mkfs.xfs -n ftype=1 /dev/vgdb/data
+   mkfs.xfs -n ftype=1 /dev/vg_db/vl_log
+   mkfs.xfs -n ftype=1 /dev/vg_db/vl_data
 
 说明:
 

diff --git a/source/linux/storage/filesystem/xfs/xfs_startup/lvm_striped b/source/linux/storage/filesystem/xfs/xfs_startup/lvm_striped
@@ -0,0 +1,5 @@
+pvcreate /dev/nvme0n{0..2}p1
+vgcreate vg_db /dev/nvme0n{0..2}p1
+
+lvcreate -n vl_log -l 10%FREE -i 3 -I 128k vg_db
+lvcreate -n vl_data -l 100%FREE -i 3 -I 128k vg_db
diff --git a/source/linux/storage/filesystem/xfs/xfs_startup/parted b/source/linux/storage/filesystem/xfs/xfs_startup/parted
@@ -0,0 +1,4 @@
+parted -s /dev/nvme0n1 mklabel gpt
+parted -s -a optimal /dev/nvme0n1 mkpart primary 0% 100%
+parted -s /dev/nvme0n1 set 1 lvm on
+parted -s /dev/nvme0n1 name 1 db_data
diff --git a/source/linux/storage/filesystem/xfs/xfs_startup/parted_multi_disk b/source/linux/storage/filesystem/xfs/xfs_startup/parted_multi_disk
@@ -0,0 +1,6 @@
+for i in {0..2};do
+    parted -s /dev/nvme0n${i} mklabel gpt
+    parted -s -a optimal /dev/nvmd0n${i} mkpart primary 0% 100%
+    parted -s /dev/nvmd0n${i} set 1 lvm on
+    parted -s /dev/nvmd0n${i} name 1 db_data
+done
diff --git a/source/linux/storage/lvm/lvmraid.rst b/source/linux/storage/lvm/lvmraid.rst
@@ -4,13 +4,35 @@
 LVM RAID( ``lvmraid`` )
 =========================
 
-虽然 :ref:`linux_software_raid` 的 :ref:`mdadm` 使用更为广泛和成熟，我也依然想尝试一下 ``lvmraid`` 部署。 ``lvmraid`` 基于 ``MD`` 驱动实现了RAID功能，是另一种解决方案。不过，从各方面信息来看， ``lvmraid`` 可能不够成熟，存在一些性能问题。具体等实践时候再对比...
+虽然 :ref:`linux_software_raid` 的 :ref:`mdadm` 使用更为广泛和成熟，我也依然想尝试一下 ``lvmraid`` 部署。 ``lvmraid`` 基于 ``MD`` 驱动实现了RAID功能，是另一种解决方案。不过，从各方面信息来看， ``lvmraid`` 可能不够成熟，存在一些性能问题。
+
+.. note::
+
+   以下是我的构想方案，尚未实践(还没有遇到实践环境)，谨慎参考
+
+- 假设方案使用 3块 磁盘构建 RAID 5(构建RAID5只少需要3块磁盘，我这里复用了 :ref:`xfs_startup`  的磁盘分区方案):
+
+.. literalinclude:: ../filesystem/xfs/xfs_startup/parted_multi_disk
+   :caption: 3块 :ref:`nvme` 磁盘使用 :ref:`parted` 完成分区
+
+- 使用LVM创建RAID的方法其实和 :ref:`striped_lvm` (条代化也是分布数据到多个数据磁盘)非常类似，区别在于传递了参数 ``--type`` ，例如 ``--type raid5`` ，并且数据盘数量参数 ``-i`` 需要比 :ref:`striped_lvm` 减少 ``1`` （因为有一块磁盘作为校验盘不直接存储数据)
+
+举例，之前在 :ref:`striped_lvm` 使用以下命令构建跨3块磁盘的条代化LVM:
+
+.. literalinclude:: ../filesystem/xfs/xfs_startup/lvm_striped
+   :caption: 创建跨3块磁盘的条代化LVM卷
+   :emphasize-lines: 4,5
+
+则需要调整数据盘数量(n-1) ``-i 2`` ，并且传递类型 ``--type raid5`` :
+
+.. literalinclude:: lvmraid/lvmraid5
+   :caption: 简单的创建RAID5的LVM卷
+   :emphasize-lines: 4,5
 
 参考
 =========
 
 - `Configure RAID Logical Volumes on Oracle Linux <https://docs.oracle.com/en/learn/ol-lvmraid/>`_
 - `Create RAID with LVM <https://blog.programster.org/create-raid-with-lvm>`_
 - `Raid1 with LVM from scratch <https://wiki.gentoo.org/wiki/Raid1_with_LVM_from_scratch>`_
-- `How to Create a RAID 5 System With LVM Tool and Recover Data After Failures <https://hetmanrecovery.com/recovery_news/how-to-create-software-raid-5-with-lvm.htm>`_
 - `RAIDing with LVM vs MDRAID - pros and cons? <https://unix.stackexchange.com/questions/150644/raiding-with-lvm-vs-mdraid-pros-and-cons>`_ 回答中包含了一个完整的指南
diff --git a/source/linux/storage/lvm/lvmraid/lvmraid5 b/source/linux/storage/lvm/lvmraid/lvmraid5
@@ -0,0 +1,5 @@
+pvcreate /dev/nvme0n{0..2}p1
+vgcreate vg_db /dev/nvme0n{0..2}p1
+
+lvcreate -n vl_log -l 10%FREE -i 2 -I 128k --type raid5 vg_db
+lvcreate -n vl_data -l 100%FREE -i 2 -I 128k --type raid5 vg_db
diff --git a/source/linux/storage/lvm/lvmraid_vs_mdadm.rst b/source/linux/storage/lvm/lvmraid_vs_mdadm.rst
@@ -16,7 +16,7 @@ lvmraid vs. mdadm
 
 .. note::
 
-   我在生产环境采用 :ref:`mdadm` 构建稳定的 :ref:`mdadm_raid6` ，然后在软RAID之上使用 :ref:`linux_lvm` 构建卷管理，最终部署 :ref:`deploy_centos7_gluster11_lvm_mdadm_raid6`
+   我在生产环境采用 :ref:`mdadm` 构建稳定的 :ref:`mdadm_raid10` ，然后在软RAID之上使用 :ref:`linux_lvm` 构建卷管理，最终部署 :ref:`deploy_centos7_gluster11_lvm_mdadm_raid10`
 
    个人的实验室环境，我将模拟测试 :ref:`lvmraid` 进行对比和学习
 

diff --git a/source/linux/storage/lvm/striped_lvm.rst b/source/linux/storage/lvm/striped_lvm.rst
@@ -16,9 +16,21 @@
    :caption: 检查LVM磁盘数据分布
    :emphasize-lines: 20,25
 
-
 可以看到这里的类型是 ``linear`` ，也就是顺序分布
-
+
+构建条代化分布LVM
+=======================
+
+条代化 ``striped`` 配置实际上也非常简单，主要是传递参数 ``-i`` 表示数据跨几块物理磁盘分布，以及 ``-I`` 参数设置条代化大小。我在 :ref:`xfs_startup` 为数据库构建的就是跨3块磁盘的条代化LVM，以便能够实现性能提升以及大容量磁盘:
+
+.. literalinclude:: ../filesystem/xfs/xfs_startup/lvm_striped
+   :caption: 创建条代化LVM卷 
+
+说明:
+
+  - ``-i 3`` 表示使用3块磁盘作为volume group，这样条带化会分布到3个磁盘上
+  - ``-I 128k`` 表示使用 128k 作为条带化大小，也可以使用单纯数字 ``128`` 默认单位就是 ``k``
+  - ``-l`` 表示扩展百分比，这里采用了 ``10%FREE`` 和 ``100%FREE`` 表示空闲空间的10%和100% ; 另外一种常用的扩展大小表示是使用 ``-L`` 参数，则直接表示扩展多少容量，例如 ``-L 10G`` 表示扩展 10GB 空间
 
 参考
 =======

diff --git a/source/machine_learning/jetson/studio/deploy_jetson_server.rst b/source/machine_learning/jetson/studio/deploy_jetson_server.rst
@@ -4,7 +4,7 @@
 部署Jetson Nano Server
 =========================
 
-最初我 :ref:`jetson_nano_startup` 时，采用了卸载Jetson Nano NVIDIA深度定制操作系统中不需要的应用软件，并且将Gnome桌面切换到轻量级Xfce4桌面。不过，实际上我日常中桌面系统使用的是macOS，Jetson Nano是作为 :ref:`kubernetes_arm` 集群中的GPU工作节点来使用的。所以并没有使用图形桌面的需求。
+最初我 :ref:`jetson_nano_startup` 时，采用了卸载Jetson Nano NVIDIA深度定制操作系统中不需要的应用软件，并且将Gnome桌面切换到轻量级Xfce4桌面。不过，实际上我日常中桌面系统使用的是macOS，Jetson Nano是作为 :ref:`arm_k8s` 集群中的GPU工作节点来使用的。所以并没有使用图形桌面的需求。
 
 为了能够减少资源消耗，同时能够实现类似阿里云的GPU虚拟化，我在第二次部署时改为完全的字符模式运行，并清理掉不必要软件。后续使用将完全基于 :ref:`kvm` 和 :ref:`docker` 模式来使用Jetson Nano。本文为部署实践整理。
 

diff --git a/source/machine_learning/jetson/studio/jetson_nano_startup.rst b/source/machine_learning/jetson/studio/jetson_nano_startup.rst
@@ -8,7 +8,7 @@ NVIDIA :ref:`jetson_nano` Developer Kit是一个小型AI计算机，面向创客
 
 .. note::
 
-   2021年初，我重新 :ref:`deploy_jetson_server` 来作为 :ref:`kubernetes_arm` 集群工作节点。有一些部署改进和调整，请参考。
+   2021年初，我重新 :ref:`deploy_jetson_server` 来作为 :ref:`arm_k8s` 集群工作节点。有一些部署改进和调整，请参考。
 
 下载和准备启动
 =================

diff --git a/source/machine_learning/jetson/studio/jetson_soft_ap.rst b/source/machine_learning/jetson/studio/jetson_soft_ap.rst
@@ -4,7 +4,7 @@
 Jetson Nano无线AP
 =====================
 
-Jetson Nano安装了外接的Intel无线模块以后，非常类似一个无线路由器，所以我考虑利用这个现有硬件结合 :ref:`create_ap` 实现一个个人使用的无线路由器，方便我测试基于 :ref:`raspberry_pi` 的 :ref:`kubernetes_arm` 。
+Jetson Nano安装了外接的Intel无线模块以后，非常类似一个无线路由器，所以我考虑利用这个现有硬件结合 :ref:`create_ap` 实现一个个人使用的无线路由器，方便我测试基于 :ref:`raspberry_pi` 的 :ref:`arm_k8s` 。
 
 由于这是在ARM架构上实现无线AP，所以可以作为通用的低功耗路由器的实践基础，为后续实现无线路由交换设备做一个参考。
 

diff --git a/source/real/edge_cloud/edge_cloud_infra.rst b/source/real/edge_cloud/edge_cloud_infra.rst
@@ -4,7 +4,7 @@
 边缘云计算架构
 ======================
 
-我陆续购买多多代 :ref:`raspberry_pi` 设备，在最初构建 :ref:`priv_cloud_infra` 时，我采用的还是完整的 :ref:`kubernetes_arm` 。不过，我也在思考如何能够尽可能少消耗树莓派的硬件资源来完成更多的计算。轻量级始终是ARM架构(资源有限的系统)的技术关键，类似 :ref:`akraino` ，我逐步想要在ARM架构上构建一个轻量级的边缘计算平台。
+我陆续购买多多代 :ref:`raspberry_pi` 设备，在最初构建 :ref:`priv_cloud_infra` 时，我采用的还是完整的 :ref:`arm_k8s` 。不过，我也在思考如何能够尽可能少消耗树莓派的硬件资源来完成更多的计算。轻量级始终是ARM架构(资源有限的系统)的技术关键，类似 :ref:`akraino` ，我逐步想要在ARM架构上构建一个轻量级的边缘计算平台。
 
 .. note::
 

diff --git a/source/real/network/proxy/apt_proxy_arch.rst b/source/real/network/proxy/apt_proxy_arch.rst
@@ -40,7 +40,7 @@ APT无阻碍代理架构
 
 综合我的几次实践，目前我选择 :ref:`squid_socks_peer` 作为基础，结合 SSH tunnel 来实现无阻碍网络:
 
-- 在 :ref:`pi_cluster` 上部署了 :ref:`kubernetes_arm` ，其中管控服务器节点 ``pi-master1`` 运行 squid 本地代理服务器
+- 在 :ref:`pi_cluster` 上部署了 :ref:`arm_k8s` ，其中管控服务器节点 ``pi-master1`` 运行 squid 本地代理服务器
 
 - 租用海外云计算厂商的VPS，采用  :ref:`squid_socks_peer` 架构，在服务器端运行一个只监听本地回环地址 ``127.0.0.1`` 的squid代理服务器：这样代理服务器不能被外部用户直接访问，只能通过ssh方式建立Tunnel之后才能通过端口映射方式被客户端访问到，这就提供了极强的安全加密