From bf060be93a6de18579245ad0831b12504be1dc5c Mon Sep 17 00:00:00 2001 From: isno Date: Sat, 28 Dec 2024 16:01:03 +0800 Subject: [PATCH] fix typo --- Observability/profiles.md | 10 ++-- application-centric/ArgoCD.md | 87 --------------------------------- application-centric/OAM.md | 2 +- application-centric/Operator.md | 2 +- 4 files changed, 7 insertions(+), 94 deletions(-) delete mode 100644 application-centric/ArgoCD.md diff --git a/Observability/profiles.md b/Observability/profiles.md index aa6919d1..0ab9ae2f 100644 --- a/Observability/profiles.md +++ b/Observability/profiles.md @@ -1,10 +1,10 @@ # 9.3.4 性能剖析 Profiling -熟悉 Golang 的开发者对 pprof 工具一定不陌生。进行软件性能调试和分析时，利用 pprof 提供的 CPU 和内存分析功能，深入了解 Golang 函数的执行时间和内存使用情况。 +熟悉 Golang 的工程师对 pprof 工具一定不陌生。借助 pprof 提供的 CPU 和内存分析功能，工程师能够深入了解 Golang 函数的执行时间、内存使用情况，从而分析、优化软件性能。 -在可观测性领域，性能剖析（Profiling）的作用与 Go 语言中的 pprof 类似，**都是对运行中的程序进行动态分析，生成程序运行时的详细数据（即 Profiles），全面了解程序资源的使用情况，确定代码和性能瓶颈之间的关联**。 +可观测性领域内的性能剖析（Profiling）的目标与 Golang 中的 pprof 类似，两者皆是对运行中应用动态分析、生成详细的运行数据（Profiles），帮助工程师全面了解软件资源使用情况，确定代码和性能瓶颈之间的关联。 -Profiles 数据一般表示成火焰图、堆栈图或内存分析图等形式，是从“是什么”到“为什么”这一过程中至关重要的依据。例如，通过链路追踪发现延迟产生的位置，然后依靠 Profiles 生成的火焰图进一步定位到具体的代码行。2021 年，国内某站崩溃，工程师们使用火焰图观察到到一处 Lua 代码存在异常，最终定位到问题的源头[^1]。 +Profiles 数据通常以火焰图、堆栈图或内存分析图等形式呈现，是从“是什么”到“为什么”这一过程中重要的依据。例如，通过链路追踪识别出延迟（是什么）的位置，然后根据火焰图进一步定位到具体的代码行（为什么）。2021 年，国内某网站崩溃，工程师分析火焰图发现 Lua 代码存在异常，最终成功定位到问题源头[^1]。 :::center ![](../assets/lua-cpu-flame-graph.webp)
@@ -22,7 +22,7 @@ Profiles 数据一般表示成火焰图、堆栈图或内存分析图等形式 ::: -Profiles 数据通常由多种不同的分析器（Profiler）生成，以下是一些常见的分析器类型： +Profiles 数据包括多种类型，由不同的分析器（Profiler）生成，常见分析器如下： - **CPU 分析器**：用于分析哪些函数或方法在运行时消耗了最多的 CPU 时间。例如，通过 CPU Profiler，我们可以确定某个算法的优化是否减少了 CPU 使用率。 - **堆分析器（Heap Profiler）**：用于监测程序的内存使用情况，帮助发现内存泄漏或不必要的内存分配。例如，在 Java 应用中，Heap Profiler 可以帮助找到导致内存溢出的具体对象或数据结构。 @@ -31,7 +31,7 @@ Profiles 数据通常由多种不同的分析器（Profiler）生成，以下是 - **I/O 分析器**：分析 I/O 操作的性能，如用来分析文件读写操作的延迟或网络请求的耗时，从而优化数据传输效率。 - **特定编程语言的分析器**：如 JVM Profiler，专门分析运行在 Java 虚拟机上的应用程序。 -过去，由于分析器的资源消耗较大，工程师们往往仅在紧急情况下才会临时使用它们。随着低开销分析技术的发展，如编程语言层面的 Java Flight Recorder 和 Async Profiler，以及操作系统层面的 systemTap 和 eBPF 技术的出现，让生产环境中的持续性能分析（Continuous Profiling）变得越来越可行，捕获偶发故障的现场快照也变得更加容易。 +过去，由于分析器资源消耗较高，工程师通常仅在紧急情况下临时启用它们。随着低开销分析技术的兴起，如编程语言层面的 Java Flight Recorder 和 Async Profiler 技术、操作系统层面的 systemTap 和 eBPF 技术，让生产环境中的“持续性能分析”（Continuous Profiling）逐渐成为现实，捕获“疑难杂症”的现场快照也变得更加容易。 [^1]: 参见《2021.07.13 我们是这样崩的》https://www.bilibili.com/read/cv17521097/ diff --git a/application-centric/ArgoCD.md b/application-centric/ArgoCD.md deleted file mode 100644 index e6e7c624..00000000 --- a/application-centric/ArgoCD.md +++ /dev/null @@ -1,87 +0,0 @@ -# 10.5 使用 Argo CD 进行持续交付 - -Argo CD 是一款用于 Kubernetes 的声明式持续交付工具，它被实现为一个Kubernetes 控制器，该控制器持续监控 Git 仓库的变更来实现自动拉取和更新机制。其背后工作原理如下： - -- **定时轮询**: Argo CD Controller 定期轮询指定的 Git 仓库，检查是否有新的提交。默认情况下，轮询周期每 3 分钟一次。 -- **Webhook 触发**: 为了更快地响应更新，Argo CD 支持通过 Git 仓库的 Webhook 来触发同步操作。当仓库中发生提交或合并请求时，GitLab、GitHub 等平台可以通过 Webhook 通知 Argo CD 立即进行同步。 -- **状态对比**: 每次拉取到最新的 Git 仓库状态后，Argo CD 会与当前集群中的应用状态进行对比。如果发现差异，Argo CD 会自动执行同步操作，确保集群与 Git 仓库的配置一致。 - - -:::center - ![](../assets/argocd_architecture.png)
- 图 10-10 Argo CD 如何工作 [图片来源](https://argo-cd.readthedocs.io/en/stable/) -::: - -接下来，笔者将演示如何在集群中安装 Argo CD 并部署示例应用，简要介绍其使用方法。 - -## 10.5.1 安装 Argo CD - -首先，创建一个专门用于 Argo CD 的命名空间“argocd”。然后通过 kubectl apply 安装 Argo CD 提供的 yaml 文件即可。 - -```bash -$ kubectl create namespace argocd -``` -安装 Argo CD 有多种方法，这里选择使用 kubectl apply 命令应用官方 YAML 清单文件进行安装。下面的命令会在之前创建的 argocd 命名空间中安装 Argo CD 的所有必要组件，包括控制器、服务器、UI 等。 - -```bash -$ kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml -``` -Argo CD 提供了一个用户友好的 Web 界面来管理应用。要访问 UI，首先需要获取初始密码。运行以下命令来获取密码： - -```bash -$ kubectl -n argocd get secret argocd - initial - admin - secret - o jsonpath ="{.data.password}"| base64 -d -``` -然后，使用以下命令设置端口转发来访问 UI。 - -```bash -$ kubectl port - forward svc/argocd - server -n argocd 8080:443 -``` - -之后，你可以在浏览器中访问https://localhost:8080，并使用 admin 作为用户名和上面获取的密码进行登录。 - -## 10.5.2 部署应用 - -在 Argo CD 中，Application 是核心的自定义资源定义（CRD），它是 Argo CD 实现 GitOps 工作流的关键抽象，定义了应用的源代码位置、目标部署环境以及同步和监控策略。 - -以下是一个 Argo CD Application 资源的示例，展示如何从 Git 仓库部署一个 Kubernetes 应用到目标集群的特定命名空间： - -```yaml -apiVersion: argoproj.io/v1alpha1 -kind: Application -metadata: - name: example-app # 应用名称 - namespace: argocd # Argo CD 安装的命名空间 -spec: - project: default # Argo CD 项目名称（默认项目） - source: - repoURL: https://github.com/example/repo.git # 配置来源的 Git 仓库地址 - targetRevision: main # Git 仓库分支或标签 - path: manifests # 仓库中存放 Kubernetes 配置的目录路径 - destination: - server: https://kubernetes.default.svc # 目标集群 API Server 地址 - namespace: default # 部署目标命名空间 - syncPolicy: - automated: # 启用自动同步 - prune: true # 删除目标集群中不需要的资源 - selfHeal: true # 自愈机制：检测到差异时自动修复 - syncOptions: - - CreateNamespace=true # 自动创建目标命名空间 -``` -将该 yaml 文件 apply 到 Kubernetes 集群。 - -```yaml -$ kubectl apply -f application.yaml -``` - -默认情况下，新创建的 Application 状态为 OutOfSync，Argo CD 尚未将 Git 仓库中的资源同步到目标集群。在 UI 控制台点击 “SYNC” 按钮触发同步操作，如果配置了 syncPolicy.automated Argo CD 会自动触发同步操作。 - -手动或自动触发同步后，状态会变为 Synced。 - -:::center - ![](../assets/argocd-demo.png)
- 图 10-11 Argo CD 应用部署示例 -::: - -此后，Argo CD 会根据 Application 的定义，持续跟踪应用在 Git 仓库中的期望状态和在 Kubernetes 集群中的实际状态，如果两者出现差异，它会尝试将实际状态同步到期望状态。例如，如果有人手动在集群中修改了某个应用资源的副本数量，Argo CD 会发现这种配置漂移，并根据 Application 的定义将副本数量恢复到 Git 仓库中配置的数量。 - -相比传统持续交付流程，Argo CD 下的应用程序的部署和生命周期管理明显变得更加**自动化**（通过自动同步、自动修复等），**可审计**（通过 Git 历史和审计日志），并且**易于理解**（通过可视化的 Web UI 和简化的部署流程）。 \ No newline at end of file diff --git a/application-centric/OAM.md b/application-centric/OAM.md index bb3e7069..b1835702 100644 --- a/application-centric/OAM.md +++ b/application-centric/OAM.md @@ -1,4 +1,4 @@ -# 10.3.5 OAM +# 10.3.4 OAM 2019 年 10 月，阿里云与微软在上海 QCon 大会上联合发布了开源项目 Open Application Model（OAM）。该项目以“关注点分离”（Separation of Concerns）为核心理念，为云原生应用的完整 DevOps 流程提供了高度抽象和封装。 diff --git a/application-centric/Operator.md b/application-centric/Operator.md index 2b54d69d..80fd759c 100644 --- a/application-centric/Operator.md +++ b/application-centric/Operator.md @@ -1,4 +1,4 @@ -# 10.3.4 Operator +# 10.3.3 Operator Operator 的概念由 CoreOS 于 2016 年提出，它并非一个具体的工具或系统，而是一种封装、部署和管理 Kubernetes 应用的方法，尤其适合需要特定领域知识的复杂有状态应用，如数据库、分布式缓存和消息队列等。