PAB's Blog

Hello World

Sun, 19 Jul 2026 11:07:32 +0000

Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.

# Quick Start

# Create a new post

$ hexo new "My New Post"

More info: Writing

# Run server

$ hexo server

More info: Server

# Generate static files

$ hexo generate

More info: Generating

# Deploy to remote sites

$ hexo deploy

More info: Deployment

Seldon Core 1

Fri, 17 Jul 2026 07:58:34 +0000

Seldon Core一个运行在 Kubernetes 上的机器学习模型服务平台，用来把训练好的模型部署成可访问、可扩缩、可观测的在线推理服务。这里学习的是1版本。

它解决的不是“怎么训练模型”，而是：

模型训练好了，怎么部署上线？
怎么暴露 REST / gRPC 接口？
怎么做版本切换、流量分配？
怎么同时管理大量模型？
怎么监控延迟、错误率和资源使用？
怎么把多个模型、预处理和后处理串成推理流水线？

当前官方重点已经转向 Seldon Core 2。Core 2 被定位为 Kubernetes 上的 MLOps/LLMOps 框架，可以管理单模型、多个模型以及模块化推理应用。

# 架构

Seldon Core 1 在K8s 上增加了一个更高层的抽象：SeldonDeployment。

这里描述的是模型推理服务，Seldon Operator 再将它转换成 k8s 能运行的资源。

# 认识 SeldonDeployment

官方将 SeldonDeployment 定义为 Kubernetes 自定义资源，用户通过它描述模型组件和推理图。

一个简单示例如下：

apiVersion: machinelearning.seldon.io/v1
kind: SeldonDeployment
metadata:
  name: iris-model
  namespace: seldon
spec:
  name: iris
  predictors:
    - name: default
      replicas: 1

      graph:
        name: classifier
        type: MODEL
        implementation: SKLEARN_SERVER
        modelUri: gs://seldon-models/sklearn/iris

      componentSpecs:
        - spec:
            containers:
              - name: classifier
                resources:
                  requests:
                    cpu: 100m
                    memory: 256Mi
                  limits:
                    cpu: 1
                    memory: 1Gi

这一份 YAML 里混合了两类信息：


模型语义
+
Kubernetes 运行配置

spec.predictors

predictors:
    - name: default

一个 predictors 可以理解为：一套可以独立接收推理请求的模型服务配置。

其中可以包含：

模型；
输入转换器；
输出转换器；
路由器；
组合器；
副本数量；
Pod 配置。

replicas
```
repicas: 1
```
描述该 predictor 的副本数量。但实际生成资源时，可能根据图结构和组件配置创建一个或多个 Deployment，因此不要机械认为一个 predictor 永远只对应一个 Deployment。

graph

graph:
  name: classifier
  type: MODEL
  implementation: SKLEARN_SERVER
  modelUri: gs://seldon-models/sklearn/iris

是 Seldon 相比普通 Deployment 最核心的能力之一，描述的是推理组件之间的调用关系。

只有一个模型时：

request
   ↓
classifier
   ↓
response

稍微复杂一点：

request
   ↓
input-transformer
   ↓
classifier
   ↓
output-transformer
   ↓
response

还可以存在：

request
   ↓
router
 ┌─┴─────────┐
 ↓           ↓
model-a    model-b
 └────┬──────┘
      ↓
   combiner
      ↓
  response

Seldon Core 1 官方文档说明，推理图可以由模型以及 router、combiner、输入和输出 transformer 等组件构成。

普通 Kubernetes Deployment 只知道：

运行哪些容器

SeldonDeployment 还知道：

这些模型组件之间应该如何调用

graph 是根节点，children 表示连接的下一层节点，多个 - 表示多个并列节点，implementation 选择预打包服务器，modelUri 指向模型目录。

implementation
```
implementation: SKLEARN_SERVER
```
意思是：

使用 Seldon 已经准备好的 sklearn 推理服务器运行模型。

Seldon Core 1 提供了多种预打包推理服务器，例如：
- SKLearn Server；
- XGBoost Server；
- TensorFlow Serving；
- MLflow Server；
- 自定义服务器。
因此你不一定要自己完整实现：
```
HTTP Server
请求反序列化
模型加载
predict 调用
响应序列化
```
这是 Seldon 比“直接写 Deployment”多做的一层标准化。

什么是预打包服务器？

预：提前准备好

打包：把代码、依赖库、运行环境放进一个容器镜像里

“服务器”则表示它不是普通脚本，而是一个会持续运行、接收网络请求并返回预测结果的程序。

所以预打包服务器指：提前打包好的，用于运行模型的服务器程序。之所以叫这个名字，核心原因就是：服务器代码和运行环境已经由 Seldon 提前封装好了，你不需要自己再写和配置。
modelUri
```
modelUri: gs://seldon-models/sklearn/iris
```
描述模型文件的位置，而不是容器镜像的位置。

Seldon 可以使用预打包模型服务器，然后根据 modelUri 加载模型。官方 SKLearn 示例就是通过 implementation 和 modelUri 描述模型服务。
conponentSpec
```
componentSpecs:
  - spec:
      containers:
        - name: classifier
          resources:
            requests:
              cpu: 100m
              memory: 256Mi
```
非常接近 Kubernetes 的：
```
PodTemplateSpec
```
它用于描述：
- 容器；
- 环境变量；
- CPU、内存；
- Volume；
- VolumeMount；
- 安全上下文；
- 节点选择；
- GPU 资源；
- 其他 Pod 配置。
因此可以这样理解：
```
graph
```
描述模型推理逻辑。
```
componentSpecs
```
描述模型组件如何在 Kubernetes 中运行。

# Sldon Operator

核心循环抽象：


func Reconcile(request Request) {
    // 1. 获取 SeldonDeployment
    sdep := getSeldonDeployment(request)

    // 2. 根据 spec 计算期望资源
    desiredDeployments := buildDeployments(sdep)
    desiredServices := buildServices(sdep)

    // 3. 查询当前资源
    currentDeployments := getDeployments(sdep)
    currentServices := getServices(sdep)

    // 4. 对比期望状态与当前状态
    diff := compare(
        desiredDeployments,
        currentDeployments,
    )

    // 5. 创建、更新或删除资源
    apply(diff)

    // 6. 更新状态
    updateStatus(sdep)
}

# 与直接写 Deployment 相比

模型语义 Deployment 只知道运行镜像，SeldonDeployment 能表达：
```
这是 MODEL
这是 ROUTER
这是 TRANSFORMER
这是 COMBINER
```
推理图

Deployment 本身不能直接表达：
```
请求 → 预处理 → 模型 → 后处理
```
SeldonDeployment 可以通过 graph 描述这种关系。
标准推理服务器

普通 Deployment 通常需要你自己准备完整模型服务镜像。

Seldon 可以使用预打包服务器运行 sklearn、XGBoost、MLflow 等模型。

22-系统加固：特权容器逃逸与配置安全上下文限制

Thu, 16 Jul 2026 06:01:22 +0000

# 心智模型

攻击者容易利用特权容器从受限容器环境侵入宿主机操作系统。

# 🛠️ 实操手册：逃逸演示与防御配置

# 第一阶段：演示特权容器逃逸（危险操作，仅限实验）

我们将演示攻击者如何利用特权容器直接访问宿主机的磁盘。

部署一个特权 Pod：注意 privileged: true 这个开关。

YAML


apiVersion: v1
kind: Pod
metadata:
  name: privileged-escape-demo
spec:
  containers:
  - name: attacker-container
    image: alpine
    command: ["sh", "-c", "sleep 3600"]
    securityContext:
      privileged: true  # 开启特权模式

执行逃逸攻击：特权容器可以看到宿主机的设备文件。我们可以直接挂载宿主机的根磁盘。

Bash


## 进入容器
kubectl exec -it privileged-escape-demo -- sh

## 在容器内，查看宿主机的磁盘设备（通常是 /dev/sda1 或 /dev/nvme0n1p1）
fdisk -l

## 创建一个挂载点并挂载宿主机根目录
mkdir /host_root
mount /dev/sda1 /host_root  # 请根据 fdisk 结果替换设备名

## 现在，你已经在容器里看到了宿主机的所有敏感文件
ls /host_root/etc/shadow
ls /host_root/root/.ssh/

结论：一旦开启 privileged: true，容器与宿主机之间已无安全可言。

# 第二阶段：配置安全上下文限制权限提升

仅仅不开启 privileged 就够了吗？不够。很多进程会利用 setuid（如 sudo 命令）在运行时尝试获取更高级别的权限。我们需要通过 allowPrivilegeEscalation: false 封死这条路。

编写安全加固的 Pod 配置：

YAML


apiVersion: v1
kind: Pod
metadata:
  name: hardened-pod
spec:
  containers:
  - name: safe-container
    image: alpine
    command: ["sh", "-c", "sleep 3600"]
    securityContext:
      # 1. 明确禁止特权模式
      privileged: false
      # 2. 禁止进程通过 setuid 等方式获取比父进程更高的权限
      allowPrivilegeEscalation: false
      # 3. 配合之前的实验，以非 root 用户运行
      runAsNonRoot: true
      runAsUser: 1000

# 🔍 核心参数深度解析

allowPrivilegeEscalation (禁止权限提升)

它是干什么的？ 它控制 no_new_privs 内核标志。如果设为 false，即使一个程序设置了 SUID 位（比如一个只有 root 才能跑的程序），普通用户也无法通过它获得 root 权限。
为什么重要？ 很多提权漏洞（Exploit）依赖于在容器内通过特殊手段获取 root。关掉这个开关，就砍掉了攻击者的“阶梯”。

readOnlyRootFilesystem (只读根文件系统)

建议配合使用：

YAML

securityContext:
  readOnlyRootFilesystem: true

效果：容器的整个根目录变成只读。如果黑客想下载一个木马脚本到 /tmp 或 /bin，会直接被内核拦截。

21-系统加固：Seccomp

Thu, 16 Jul 2026 06:00:35 +0000

Seccomp (Secure Computing mode) 是 Linux 内核的一项功能，用于限制容器可以发起的系统调用 (System Calls)。

# 🛠️ 实操手册：配置 Seccomp Profile

在 Kubernetes 中，Seccomp 已经比 AppArmor 更加标准化，直接集成在 securityContext 字段中。

# 第一阶段：使用 `RuntimeDefault` (最推荐的生产配置)

这是容器运行时（如 containerd 或 Docker）自带的一套“安全模板”，它禁用了大约 40 多个危险的系统调用。

编写 Pod 配置文件：与 AppArmor 不同，Seccomp 建议直接写在 spec 字段中。

YAML


apiVersion: v1
kind: Pod
metadata:
  name: seccomp-default-pod
spec:
  securityContext:
    # 在 Pod 级别应用 seccomp
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: web-app
    image: nginx

# 第二阶段：自定义 Seccomp Profile (精细化控制)

有时候默认配置还是太宽松，或者你需要运行极其特殊的应用。

在 Worker 节点创建 Profile 目录： Kubelet 默认在特定的安全目录下寻找 Profile。

Bash
```
# 在所有 Worker 节点执行
sudo mkdir -p /var/lib/kubelet/seccomp/profiles
```
编写 JSON Profile：创建一个名为 audit-only.json 的文件，它的作用是：允许大部分操作，但对某些操作记录日志（用于审计）。

JSON


{
    "defaultAction": "SCMP_ACT_ALLOW",
    "architectures": [
        "SCMP_ARCH_X86_64"
    ],
    "syscalls": [
        {
            "names": [
                "reboot"
            ],
            "action": "SCMP_ACT_KILL"
        }
    ]
}

语法解释：如果进程尝试调用 reboot（重启），内核会直接杀掉 (SCMP_ACT_KILL) 该进程。

将文件放入 Worker 节点指定路径：将此 JSON 放在 /var/lib/kubelet/seccomp/profiles/audit-only.json。
在 Pod 中引用自定义 Profile：

YAML


apiVersion: v1
kind: Pod
metadata:
  name: seccomp-custom-pod
spec:
  containers:
  - name: test-container
    image: busybox
    command: ["sh", "-c", "sleep 3600"]
    securityContext:
      seccompProfile:
        type: Localhost
        # 注意：这里的路径是相对于 /var/lib/kubelet/seccomp/ 的相对路径
        localhostProfile: profiles/audit-only.json

# 第三阶段：验证实验结果

部署 Pod：

Bash

kubectl apply -f seccomp-custom-pod.yaml

测试拦截效果：由于我们设置了 reboot 就会被 KILL，我们可以进入容器尝试触发这个调用。

Bash
```
kubectl exec seccomp-custom-pod -- reboot
```
预期现象：你会发现连接被断开，或者提示 command terminated with exit code 137。这是因为内核检测到非法调用，瞬间终止了进程。

# 避坑指南

路径陷阱：在 Pod YAML 中写 localhostProfile 时，不要写绝对路径 /var/lib/...。Kubelet 会自动拼凑前缀。
权限陷阱：由于 Seccomp 需要在每个节点部署 JSON 文件，建议在生产中使用 DaemonSet 来自动把 Profile 文件同步到所有节点的磁盘上。

20-系统加固：Apparmor

Thu, 16 Jul 2026 05:59:46 +0000

# 心智模型

最小权限原则，要求每个程序或系统进程这你能访问其任务所必须的信息和资源。

# 实验：部署和引用 AppArmor Profile

# 第一阶段：在 Worker 节点准备 Profile

AppArmor 是 Linux 内核模块，因此 Profile 必须加载到每一个运行 Pod 的节点内核中。

登录到你的 Worker 节点。
创建 Profile 文件：创建一个名为 k8s-deny-write 的配置文件，禁止容器写入任何文件。

Bash


cat <<EOF > /etc/apparmor.d/k8s-deny-write
profile k8s-deny-write flags=(attach_disconnected) {
  # 包含基本抽象
  include <abstractions/base>

  # 拒绝所有写入操作
  deny /** w,
}
EOF

加载 Profile 到内核：使用 apparmor_parser 命令解析并加载该配置文件。

Bash


sudo apparmor_parser -r -W /etc/apparmor.d/k8s-deny-write

确认加载成功：

Bash


sudo aa-status  grep k8s-deny-write

第二阶段：在 Pod 中通过 Annotation 引用

在 Kubernetes 1.30 之前的版本中，AppArmor 主要通过 Annotation (注解) 进行配置。

编写 Pod 部署文件：注意 Annotation 的格式：container.apparmor.security.beta.kubernetes.io/<container_name>: localhost/<profile_name>。

YAML


apiVersion: v1
kind: Pod
metadata:
  name: apparmor-test-pod
  annotations:
    # 这里的 'test-container' 必须匹配下方的容器名
    # 'localhost/k8s-deny-write' 表示引用节点本地加载的 profile
    container.apparmor.security.beta.kubernetes.io/test-container: localhost/k8s-deny-write
spec:
  containers:
  - name: test-container
    image: busybox
    command: ["sh", "-c", "echo 'Hello AppArmor' && sleep 3600"]

部署 Pod：

Bash


kubectl apply -f apparmor-pod.yaml

# 第三阶段：验证防御效果

我们要验证“最小权限”是否生效：

尝试在容器内创建文件：

Bash


kubectl exec apparmor-test-pod -- touch /tmp/test.txt

预期结果：系统应报错：touch: /tmp/test.txt: Permission denied。
查看内核日志（在 Worker 节点上）：

Bash


dmesg  grep -i apparmor

你会看到类似 apparmor="DENIED" 的记录，这证明内核成功拦截了违规操作。

# 💡 关键要点总结

步骤

核心操作

注意事项

节点侧

加载 Profile 到内核

必须在所有潜在的 Worker 节点上执行。

集群侧

Pod Annotation 引用

格式必须极其精确，否则 Pod 可能无法启动或静默失败。

维护

审计与调优

生产环境通常先使用 complain 模式（仅记录不拦截）观察业务需求，再转为 enforce。

注意： 从 Kubernetes 1.30 开始，AppArmor 已进入正式版 (GA)，推荐开始使用 securityContext.appArmorProfile 字段替代 Annotation，但目前社区中 Annotation 仍是最通用的学习和迁移方式。

19-集群设置：TLS Ingress 实验

Thu, 16 Jul 2026 05:56:40 +0000

实验在 Killercoda 进行，自己搭的网络实在是太麻烦了。

# 步骤 1：安装 NGINX Ingress Controller

Killercoda 的默认集群没有自带 Ingress 控制器，我们需要手动部署官方的裸机（Bare-metal）版本。

在终端中执行以下命令：

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.10.0/deploy/static/provider/baremetal/deploy.yaml

提示：安装需要拉取镜像并启动 Pod，你可以运行 kubectl get pods -n ingress-nginx 查看状态，等到 ingress-nginx-controller 开头的 Pod 变成 Running 状态再继续。

# 步骤 2：生成自签名的 TLS 证书

openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout tls.key -out tls.crt \
  -subj "/CN=my-secure-app.com/O=my-local-test"

-x509: 最关键的参数。告诉 OpenSSL 直接输出一个自签名证书

-nodes: 读作 “no DES”。意思是不对私钥进行加密。这样生成的 tls.key 文件就不需要密码保护。在 Kubernetes Secret 中使用时，必须加这个参数，否则 Pod 启动时会因为无法输入密码解密私钥而报错。

-newkey rsa:2048: 同时生成一个新的私钥。指定算法为 RSA，长度为 2048 位

-days 365: 设置证书的有效期。这里是 1 年。

-keyout tls.key: 指定生成的私钥保存的文件名。

-out tls.crt: 指定生成的公钥证书保存的文件名。

-subj "...": 以命令行方式直接提供证书的身份信息，避免进入交互式问答模式。

/CN (Common Name)：域名。比如 my-secure-app.com，这要和你的 Ingress 规则里的 host 匹配。
/O (Organization)：组织机构名称。

# 步骤 3：在 Kubernetes 中创建 TLS Secret

将生成的证书存入 Secret 中：


kubectl create secret tls my-tls-secret \
  --key tls.key \
  --cert tls.crt

# 步骤 4：部署测试应用 (后端服务)

部署简单的 NGINX 容器作为后端。可以直接在终端粘贴以下命令，它会使用 cat 直接生成并应用配置文件：

cat <<EOF  kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello-app
  template:
    metadata:
      labels:
        app: hello-app
    spec:
      containers:
      - name: hello-app
        image: nginxdemos/hello:plain-text
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: hello-service
spec:
  selector:
    app: hello-app
  ports:
  - port: 80
    targetPort: 80
EOF

# 步骤 5：配置带有 TLS 的 Ingress

与 Minikube 稍有不同，在标准集群中，显式声明 ingressClassName: nginx 是一个好习惯，确保流量被正确接管。

Bash

cat <<EOF  kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: secure-ingress
spec:
  ingressClassName: nginx  # 指定使用我们刚刚安装的 Nginx Ingress
  tls:
  - hosts:
    - my-secure-app.com
    secretName: my-tls-secret
  rules:
  - host: my-secure-app.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: hello-service
            port:
              number: 80
EOF

# 步骤 6：在 Killercoda 中测试 HTTPS

我们刚才安装的裸机版 Ingress Controller 是通过 NodePort 暴露在集群上的。我们需要获取它暴露的 443 (HTTPS) 端口的映射端口。

1. 自动提取 HTTPS 的 NodePort 端口号并存入变量：

HTTPS_NODEPORT=$(kubectl get svc ingress-nginx-controller -n ingress-nginx -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}')
echo "HTTPS NodePort is: $HTTPS_NODEPORT"

2. 发起请求测试： 我们直接在 Killercoda 的终端里，向本机的（localhost）这个 NodePort 发起请求，同样强制指定 Host 头：

curl -kv https://localhost:$HTTPS_NODEPORT -H "Host: my-secure-app.com"

-k：允许连接到“不安全”的 SSL 站点。

-v：输出详细日志。

-H：手动注入 HTTP Header 中的 Host 字段

期望结果： 会在输出信息中看到 Server certificate: my-secure-app.com 的 TLS 握手信息，并看到底层 NGINX 应用返回的纯文本内容（如 Server address 和 Server name 等信息）。这证明在 Killercoda 标准集群上，TLS 终结实验圆满成功！

18-集群设置：kube-bench

Thu, 16 Jul 2026 05:54:29 +0000

kube-bench 进行集群安全加固是 Kubernetes 运维中的高级进阶任务。它主要基于 CIS (Center for Internet Security) Kubernetes Benchmark 标准来检查集群配置。

# 心智模型：

在操作之前，需要建立这样一个逻辑回路：

扫描 (Scan)： kube-bench 作为一个二进制工具或容器运行，它会读取主机的进程参数（如 ps -ef grep kube-apiserver）和配置文件。
比对 (Compare)： 它将获取到的参数与 CIS 标准进行比对。
报告 (Report)： 输出 [PASS]（通过）、[FAIL]（失败）或 [WARN]（警告）。每个 [FAIL] 都会附带一个 Remediation（修复建议）。
修复 (Fix)： 修改 /etc/kubernetes/manifests/ 下的 YAML。由于这些是 Static Pod，kubelet 会监控文件变化并自动重启组件应用新参数。

# 实验步骤指南

# 方式一（推荐）：直接用 Job


kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml

查看结果：


kubectl logs job/kube-bench

你会看到类似：


[PASS] 1.1.1 Ensure API server pod specification file permissions are set to 644 or more restrictive
[FAIL] 1.2.7 Ensure that the --authorization-mode argument includes Node

2.定位漏洞与修复

假设报告中出现以下失败项：

[FAIL] 1.2.7 Ensure that the --authorization-mode argument includes Node
[FAIL] 1.2.19 Ensure that the --profiling argument is set to false

3. 修改 Manifest

进入目录并编辑 API Server 的定义文件：


cd /etc/kubernetes/manifests/
vi kube-apiserver.yaml

在 spec.containers.command 列表下添加或修改参数：


- --authorization-mode=Node,RBAC  # 确保包含 Node
- --profiling=false               # 关闭分析接口以减少攻击面

保存退出后，等待约 30 秒，使用 kubectl get pods -n kube-system 查看 api-server 是否重启成功

# Kubernetes 安全 = 4层防线


① 身份（RBAC / authn）
② 权限（authorization）
③ 数据（etcd encryption）
④ 节点（kubelet security）

Untitled Post - 4

Thu, 16 Jul 2026 05:52:01 +0000

17-使用 etcdctl 练习备份与恢复集群数据

Thu, 16 Jul 2026 05:46:01 +0000

ectdctl 是一个命令行界面（CLI）工具，专门用于与 etcd 数据库进行交互。

目前 ectd 普遍使用 v3 版本的 API ，操作前需要指定环境变量 ETCDCTL_API=3。

新版将 etcdctl 功能拆分了：

ectdctl:用于与正在运行的 etcd 服务交互（通过网络）
etcdutl:用于处理离线文件

# 第一部分：etcd 备份与恢复的心智模型

集群所有状态都以键值对形式存储在 etcd 中。除了 kube-apiserver，没有任何组件可以直接和 etcd 对话。
备份的本质是拷贝那一瞬间 etcd 底层 BoltDB 引擎的物理文件。
恢复操作不是覆盖，而是那旧的快照文件，在一个全新的目录下解压重现当时的数据结构，然后修改 etcd 配置文件，指向这个新目录。

# 第二部分：实战演练指南

# 第一步：准备“万能钥匙”（设置 Alias）

在 kubeadm 搭建的集群中，etcd 启用了双向 TLS 认证。每次敲击 etcdctl 都需要带上一长串证书路径，非常反人类。我们先设置一个临时别名来简化操作：

## 确认 etcdctl 已安装 (如果没有，可通过 apt/yum 安装 etcd-client)
## 设置别名，指定 API 版本为 3，并带上 kubeadm 默认的 etcd 证书路径
alias etcdctl='ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key'

验证一下： 运行 sudo etcdctl endpoint health，如果返回 is healthy，说明钥匙管用。

# 第二步：制造“案发现场”（创造测试数据）

我们在集群里留下一些独特的痕迹，证明当前的“时间线”。

kubectl create namespace disaster-recovery
kubectl run survivor-pod --image=nginx -n disaster-recovery
kubectl get pods -n disaster-recovery
## 确保 pod 处于 Running 状态

# 第三步：时空冻结（执行备份）

现在，我们将当前的集群状态备份到 /opt/etcd-backup.db 文件中。

etcdctl snapshot save /opt/etcd-backup.db

验证一下： 运行 etcdutl snapshot status /opt/etcd-backup.db -w table，你会看到备份文件的详细哈希和体积。

# 第四步：模拟灾难（破坏数据）

现在，假装有新手误删了整个核心业务线。

kubectl delete namespace disaster-recovery

验证一下： 此时再运行 kubectl get pods -n disaster-recovery，会提示 Namespace 不存在。案发现场已被破坏。

# 第五步：解压快照（生成新目录）

注意心智模型：我们要把备份恢复到一个全新的空目录（例如 /var/lib/etcd-restore），而不是直接覆盖现有的 /var/lib/etcd。

etcdutl snapshot restore /opt/etcd-backup.db \
  --data-dir=/var/lib/etcd-restore

执行完毕后，你可以 ls -l /var/lib/etcd-restore，会发现里面生成了新的数据文件。

# 第六步：大脑移植（切换 etcd 数据目录）

在 kubeadm 集群中，etcd 是以 Static Pod（静态 Pod）的形式运行的。kubelet 会死死盯着 /etc/kubernetes/manifests/ 目录。只要我们修改了里面的 yaml，kubelet 就会自动重启对应的 Pod。

vi /etc/kubernetes/manifests/etcd.yaml

翻到文件最下面，找到 volumes 挂载部分的 hostPath。 将原来的 /var/lib/etcd 修改为 /var/lib/etcd-restore：

  volumes:
  - hostPath:
      path: /etc/kubernetes/pki/etcd
      type: DirectoryOrCreate
    name: etcd-certs
  - hostPath:
      path: /var/lib/etcd-restore  # <--- 修改这里！
      type: DirectoryOrCreate
    name: etcd-data

保存并退出 (:wq)。

# 第七步：见证奇迹

保存退出后，kubelet 会发现 yaml 发生了变化，开始销毁旧的 etcd pod 并挂载新目录启动新的 etcd。这个过程大概需要 30 秒到 1 分钟。在这期间，你敲 kubectl 可能会卡住或报错（因为 apiserver 连不上数据库了），这是正常现象。

耐心等待一小会儿，再次输入：

kubectl get pods -n disaster-recovery

你会发现，刚才被删除的 disaster-recovery 命名空间和里面的 survivor-pod 又奇迹般地复活了！这就标志着你的集群时光倒流成功。

# 总结

常用命令：

数据备份：etcdctl snapshot save backup.db

查看备份文件哈希和体积： etcdutl snapshot status /opt/etcd-backup.db -w table

备份恢复到指定路径：

etcdutl snapshot restore /opt/etcd-backup.db \
  --data-dir=/var/lib/etcd-restore

16-多容器架构实战（Sidecar 边车模式收集日志）

Thu, 16 Jul 2026 05:35:25 +0000

在真实的生产环境中，很多老旧系统（Legacy Systems）并不符合云原生标准。它们不会把日志输出到终端（stdout），而是死板地写进容器内的某个文件里（比如 /var/log/app.log）。这就导致 Kubernetes 原生的 kubectl logs 命令直接失效（因为它只抓取容器的 stdout）。

# 核心技术逻辑：Sidecar（边车）模式与共享卷

要在不修改老旧代码的前提下解决这个问题，K8s 给出的标准答案是：Sidecar 模式。

Pod 的本质： Pod 不是一个容器，而是一个“容器组”。同一个 Pod 内的多个容器共享网络（localhost）和存储卷。
EmptyDir 卷（桥梁）： 我们创建一个生命周期与 Pod 绑定的临时存储卷 emptyDir，把它同时挂载给这两个容器。
数据流向：
- 业务容器 (Main)： 把日志不断写入挂载的目录中（例如 /var/log/app/sys.log）。
- 边车容器 (Sidecar)： 同样挂载这个目录，只运行一个极为简单的命令（如 tail -f /var/log/app/sys.log），把文件内容实时读取出来，并输出到自己的终端（stdout）。
最终结果： 此时，你只需要用 kubectl logs 去看那个 Sidecar 容器，就能完美获取老旧系统的日志了！

# 实战挑战

我们将从零手写一个包含两个容器的 Pod YAML。

1. 编写多容器 Pod 配置文件 sidecar-pod.yaml：


apiVersion: v1
kind: Pod
metadata:
  name: legacy-app-pod
spec:
  # 1. 声明一个共享的空目录卷
  volumes:
  - name: shared-logs
    emptyDir: {}

  containers:
  # 2. 这是老旧的业务主容器（它只往文件里写，不往屏幕上打）
  - name: main-app
    image: busybox
    command: ["/bin/sh", "-c", "while true; do echo '$(date) - ERROR: legacy system failure' >> /var/log/app/sys.log; sleep 2; done"]
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log/app   # 挂载到业务容器的这个路径

  # 3. 这是我们注入的 Sidecar 日志收集容器
  - name: log-sidecar
    image: busybox
    command: ["/bin/sh", "-c", "tail -f /var/log/app/sys.log"] # 实时读取文件并输出到标准输出
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log/app   # 必须挂载同一个卷到相同的（或不同的）路径

2. 部署这个“双黄蛋” Pod：


kubectl apply -f sidecar-pod.yaml

3. 观察多容器的就绪状态：


kubectl get pod legacy-app-pod -w

预期现象： 注意看 READY 那一列。普通的 Pod 是 1/1，而这个 Pod 在启动时会显示 0/2，最终变成 2/2。这代表里面的两个容器都已成功运行。

# 阶段二：见证 Sidecar 的魔法 (CKA 必考命令)

现在，我们来验证日志提取。

1. 尝试直接获取 Pod 日志（会报错）： 在单容器时代，你习惯直接敲 kubectl logs <pod-name>。但在多容器时代，这行不通了：


kubectl logs legacy-app-pod

预期输出： error: a container name must be specified for pod legacy-app-pod... K8s 会抱怨：你这 Pod 里有两个容器，你到底要看谁的？

2. 明确指定容器名称（查看主容器）： 使用 -c 参数指定容器名。


kubectl logs legacy-app-pod -c main-app

预期输出： 空空如也。因为老旧系统没有向终端输出任何东西。

3. 见证奇迹时刻（查看 Sidecar 容器）：


kubectl logs legacy-app-pod -c log-sidecar

预期输出： 你会看到屏幕上源源不断地打印出带有时间戳的 ERROR: legacy system failure！

这就是 Sidecar 模式的魅力：解耦。业务容器专心跑业务，日志容器专心搬运日志，互不干扰，却完美协同。

# 清理


kubectl delete pod legacy-app-pod

Custom Styles

Thu, 16 Jul 2026 05:32:52 +0000

Custom Styles

Thu, 26 Mar 2026 04:38:10 +0000

Transformer 简介

Tue, 24 Mar 2026 04:44:17 +0000

# 背景

给定一个翻译任务：将 I love you baby 翻译为中文。

先把每一个词转换成对应的 词向量，考虑按照下面方式处理：

直接丢到 MLP 中，那么：
- 每个词都会失去上下文信息，且长度只能一一对应

用 RNN，那么：
- 会面临串行计算
- 句子太长会导致记不住长距离的信息

# 注意力机制 Attention

上面两个方法都有缺陷，可以考虑按照下面的方法处理：

首先，给每个 词向量加上各自的 位置编码（表示该词出现在整个句子中的位置），现在这个词向量就具备了位置信息

但现在每个词都还没有其他词的上下文信息（注意不到其他词的存在）。用权重矩阵 $W\_q$ $W_q$ 与第一个词向量相乘(MatMul)，得到维度不变的 $q\_1$ $q_1$ 矩阵。同理，用 $W\_k, W\_v$ $W_k, W_v$ 矩阵处理得到 $k\_1, v\_1$ $k_1, v_1$ 。同理，得到 $q\_{1,2,3,4}, k\_{1,2,3,4}, v\_{1,2,3,4}$ $q_1, 2, 3, 4, k_1, 2, 3, 4, v_1, 2, 3, 4$ 。
- 其中 $W\_q, W\_k, W\_v$ 矩阵都是可以经过训练学习到的一组权重值。
- 实际在 GPU 中运算时，是把词向量拼接成一个矩阵，再与 W 矩阵相乘。

现在，原来的词向量已经通过线性变换映射成了维度相同的 $q, k, v$ 。将 $q\_1$ 与 $k\_2$ 做 内积 得到 $a\_{12}$ ，表示在第一个词的视角下，与第二个词的 相似度系数。同理，得到 $a\_{11}, a\_{12}, a\_{13}, a\_{14}$ 。

得到相似度系数后，分别和 v 向量相乘，再相加，得到 $a\_1$ ，表示在第一个词的视角下的全部上下文信息。同理，得到 $a\_1, a\_2, a\_3, a\_4$ 。

从全局的视角看，就是把最初的词向量，处理得到新的词向量（包含了位置信息和其他词上下文信息），这就是 注意力机制 Attention 的原理

# 多头注意力机制 Multi-Head Attention

对于注意力机制而言，通过一种方式计算一次相关性，那么灵活性会大大降低。

之前是每个词向量计算一组 $q\_{i}, k\_{i}, v\_{i}$ ，现在基于原来的 $q\_{i}, k\_{i}, v\_{i}$ ，再经过两个权重矩阵 W 变成两组 $q\_{i}, k\_{i}, v\_{i}$ ，相当于给每个词向量两次学习机会，学习到不同的待计算相似度的 $q_{ij}, k_{ij}, v_{ij} $（头部 head）来增加语言的灵活性。

两个 head 经过注意力层的计算，得到 $a\_{ij}$ 向量，再把两个 $a\_{ij}$ 向量拼接起来，得到和原词向量相同维度的新词向量。这种方式也即 多头注意力机制机制 Multi-Head Attention。

# Transformer 论文架构图

# 整体架构

把输入的内容通过 词嵌入 Word Embedding 的方式转换为向量矩阵

加入位置信息

经过多头注意力的处理，输入、输出的矩阵在维度上没有变化，输出的矩阵的每个词向量都增加了上下文信息。
- 后面的 Add & Norm 是优化步骤。表示 残差网络 和 归一化，是为了解决梯度消失问题、让分布更加稳定。

# 多头注意力架构

单头注意力：先让 q, k 内积，得到一个 相似度系数 的矩阵，再和 v 相乘，得到包含上下文信息的词向量矩阵
- Scale：缩放
- Mask：掩码
- SoftMax：将输出映射到(0, 1)区间

Attention(Q,K,V)=softmax(QKTdk)VAttention(Q,K,V)=softmax(\fracQK(T){\sqrt{d_k}})V

多头注意力机制
q,k,v 分别经过 线性变换 Linear（矩阵乘法）拆分成多组（相当于给了多次机会学习到不同的相似度关系），依次经过 单头注意力机制 运算后，把运算结果拼接 Concat 起来。最后再用权重矩阵 $W^O$ 进行线性变换

MultiHead(Q,K,V)=Concat(head1,…,headh)WOheadi=Attention(QWiQ,KWiK,VWiV)\beginalign\*} \\text{MultiHead}(Q, K, V) &= \\text{Concat}(\\text{head}\_1, \\dots, \\text{head}\_h) W(O \\\\ \\text{head)_i &= \textAttention}(Q W\_i(Q, K W\_i^K, V W\_i^V) \\\\ \\end{align\*)

# 编码器与解码器

用原来的翻译任务为例：

编码器：

输入要翻译的文本
经过词嵌入 Embedding，引入位置编码 Positional Encoding
经过多头注意力、残差和归一化
送入一个全连接神经网络 Feed Forward，再残差和归一化
结果送入解码器的一个多头注意力机制的两个输入中（作为 K, V）

解码器：

输入要翻译的文本
经过词嵌入 Embedding，引入位置编码 Positional Encoding
经过 掩码后的多头注意力、残差和归一化，送入多头注意力的一个输入中（作为 Q）
K,V,Q 进行多头注意力，再残差和归一化
最后结果一层线性变换的神经网络，把向量投射到词表向量中
Softmax 转化为概率

Masked Attention

作用：屏蔽未来位置信息，保证解码器只能基于已生成的前缀序列预测下一个词

Transformer 解码器是自回归生成模型：每一步的输出都依赖于之前所有的输出

掩码是一个上三角矩阵，未来位置的注意力权重置为 −∞（或极小值）

参考链接：Transformer 其实是个简单到令人困惑的模型【AI入门06】_哔哩哔哩_bilibili

长短期记忆 LSTM

Tue, 24 Mar 2026 04:05:53 +0000

长短期记忆（Long Short-Term Memory，LSTM）是 RNN 最重要的变体，也是深度学习 NLP 发展史上的里程碑。在 Transformer 出现之前（2017 年），LSTM 是序列建模的绝对王者。

# 背景：RNN 梯度消失

句子："我住在法国，...（中间 200 个字）... 所以我会说___"
空格应该填 “法语”

RNN 的问题：
需要记住 200 个字前的"法国"。反向传播 时，梯度要连乘 200 次，导致前面的信息传不过来。
如果每次乘 0.9 → 0.9^200 ≈ 0.000000001 → 梯度消失

# LSTM 的结构及接口

LSTM 与 RNN 的接口的不同之处在于，LSTM 还有路径 c。这个 c 称为 记忆单元（或者简称为“单元”），相当于 LSTM 专用的记忆部门。

记忆单元的特点：仅在 LSTM 层内部接收和传递数据，对外部不可见，我们甚至不用考虑它的存在
$\\sigma$ ：sigmoid函数用于求门的开合程度（sigmoid函数的输出范围在0.0 ~ 1.0）

# 输出门 Output Gate

作用：决定输出哪些信息作为隐藏状态 $h\_t$ （求出隐藏状态 $h\_t$ ）
公式： $o\_t = \\sigma\\left(x\_t W\_x^{(o)} + h\_{t-1} W\_h^{(o)} + b^{(o)}\\right)$

隐藏状态 $h\_t=o\_t ⊙ \\tanh(c\_t)$ ，记忆单元 $c\_t$ 和隐藏状态 $h\_t$ 的关系只是按元素应用 $\\tanh$ 函数。这意味着，记忆单元 $c\_t$ 和隐藏状态 $h\_t$ 的_元素个数相同_。

⊙ 表示 阿达玛乘积。即，对应元素的乘积

# 遗忘门 Forget Gate

作用：决定从细胞状态中丢弃哪些信息
公式： $f\_t = \\sigma\\left(x\_t W\_x^{(f)} + h\_{t-1} W\_h^{(f)} + b^{(f)}\\right)$

# 输入门 Input Gate

作用：决定更新哪些新信息到细胞状态
公式： $i\_t = \\sigma\\left(x\_t W\_x^{(i)} + h\_{t-1} W\_h^{(i)} + b^{(i)}\\right)$

# 新的记忆单元

向记忆单元添加的新信息 ： $\\hat{c\_t} = \\tanh\\left(x\_t W\_x^{(g)} + h\_{t-1} W\_h^{(g)} + b^{(g)}\\right)$
新的记忆单元： $c\_t=f ⊙ c\_{t-1} + i ⊙ \\hat{c\_t}$ ，细胞状态 = 遗忘 × 旧细胞 + 输入 × 新候选

$\\hat{c\_t}$ 也即上面的 g

这个 tanh 节点的作用不是门，而是将新的信息添加到记忆单元中。因此，它不用 sigmoid 函数 作为激活函数，而是使用 tanh 函数。

# LSTM 不会梯度消失

观察记忆单元的反向传播：

记忆单元的反向传播仅流过 + 和 × 节点。

+ 节点 将上游传来的梯度原样流出，所以梯度没有变化（退化）
× 节点 的计算并不是矩阵乘积，而是对应元素的乘积（阿达玛积）

# PyTorch 代码示例

基础 LSTM：

import torch
import torch.nn as nn

class SimpleLSTM(nn.Module):
def __init__(self, input_size, hidden_size, num_layers, num_classes):
super().__init__()
self.hidden_size = hidden_size
self.num_layers = num_layers

    # LSTM 层
    self.lstm = nn.LSTM(input\_size, hidden\_size, 
                       num\_layers=num\_layers,
                       batch\_first=True,
                       dropout=0.3)  # 层间 Dropout
    
    # 全连接层
    self.fc = nn.Linear(hidden\_size, num\_classes)

def forward(self, x):
    # x: (batch\_size, seq\_len, input\_size)
    
    # 初始化隐藏状态
    h0 = torch.zeros(self.num\_layers, x.size(0), self.hidden\_size)
    c0 = torch.zeros(self.num\_layers, x.size(0), self.hidden\_size)
    
    # 前向传播
    out, (hn, cn) = self.lstm(x, (h0, c0))
    # out: (batch, seq\_len, hidden\_size)
    # hn: (num\_layers, batch, hidden\_size)
    
    # 取最后一个时间步的输出
    out = self.fc(out\[:, -1, :\])
    return out

# 使用

model = SimpleLSTM(input_size=100, hidden_size=128,
num_layers=2, num_classes=2)

IMDB 情感分析:

import torch.optim as optim

# 超参数

batch_size = 64
seq_len = 100
learning_rate = 0.001
epochs = 10

# 模型、损失、优化器

model = SentimentBiLSTM(vocab_size=10000, embed_dim=300,
hidden_size=128, num_classes=2)
criterion = nn.CrossEntropyLoss()
optimizer = optim.Adam(model.parameters(), lr=learning_rate)

# 训练循环

for epoch in range(epochs):
model.train()
total_loss = 0

for batch\_x, batch\_y in train\_loader:
    # batch\_x: (64, 100), batch\_y: (64,)
    
    optimizer.zero\_grad()
    output = model(batch\_x)
    loss = criterion(output, batch\_y)
    loss.backward()
    
    # 梯度裁剪（防止 LSTM 梯度爆炸）⭐
    torch.nn.utils.clip\_grad\_norm\_(model.parameters(), 1.0)
    
    optimizer.step()
    total\_loss += loss.item()

# 验证
model.eval()
correct = 0
total = 0
with torch.no\_grad():
    for batch\_x, batch\_y in val\_loader:
        output = model(batch\_x)
        predicted = torch.argmax(output, dim=1)
        correct += (predicted == batch\_y).sum().item()
        total += batch\_y.size(0)

val\_acc = correct / total
print(f"Epoch {epoch+1}: Loss={total\_loss:.4f}, Val Acc={val\_acc:.4f}")

循环神经网络 RNN

Tue, 24 Mar 2026 03:54:06 +0000

# 背景及推导

需求：输入一句话，输出每个单词的褒贬性

假设对于上面 5 个单词，每个单词采用 300 维的 词向量，那么输入端就需要 1500 个词向量，这会带来几个缺点：

输入层的节点太多了，并且是变长的，会随着句子的长短发生变化
无法体现词语之间的先后顺序，仅仅只是把他们拉直展开成一个大向量，直接送入输入层（类似于 MLP）

为了解决上述缺点，可以让上一步的信息参与下一步的运算，具体可以这样做：

第一个词 $X^{<1>}$ 经过非线性变换 g( $\\cdot$ ) 后得到一个中间结果(隐藏状态) $h^{<1>}$ ，它再经过一次非线性变换得到第一个输出 $Y^{<1>}$
接着，第二个词 $X^{<2>}$ 与刚才的隐藏状态 $h^{<1>}$ 一起参与非线性变换，得到隐藏状态 $h^{<2>}$ ，它再经过一次非线性变换得到 $Y^{<2>}$
g( $\\cdot$ )：激活函数，一般取双曲正切 tanh
$W\_{xh}$ ：专门针对词向量的矩阵
$W\_{hh}$ ：专门针对隐藏状态的矩阵
$W\_{hy}$ ：专门针对输出结果的矩阵
$b$ ：偏置项 bias

上图流程可以简化为下面两种等效表达方式：

参考链接：语言居然可以被计算出来？从 RNN 到 Transformer【AI入门05】_哔哩哔哩_bilibili

# RNN 的问题：梯度消失/爆炸

反向传播时，梯度需要从后往前传：

∂L∂W=∂L∂sn×∂sn∂sn−1×∂sn−1∂sn−2×...×∂s1∂W\frac{\partial L}{\partial W}=\frac{\partial L}{\partial s_n}\times\frac{\partial s_n}{\partial s_{n-1}}\times\frac{\partial s_{n-1}}{\partial s_{n-2}}\times ... \times\frac{\partial s_1}{\partial W}

如果 $\\frac{\\partial s\_t}{\\partial s\_{t-1}} < 1$ （如 0.5），连乘 100 次 → 0.5^100 ≈ 0 → 梯度消失 → 前面的权重几乎不更新 → 模型记不住长距离信息
如果 $\\frac{\\partial s\_t}{\\partial s\_{t-1}} > 1$ （如 1.5），连乘 100 次 → 1.5^100 ≈ 亿 → 梯度爆炸 → 权重变成 NaN → 模型训练崩溃

解决方案：
原始的 RNN 几乎已被淘汰

方法

说明

梯度裁剪

限制梯度最大值（如 1.0）

ReLU 激活

缓解梯度消失（但 RNN 常用 tanh）

LSTM/GRU

最有效的方案 ⭐ LSTM 和 GRU 中增加了一种名为“门”的结构

Gated RNN

在 RNN 的学习中，梯度消失 也是一个大问题。为了解决这个问题，需要从根本上改变 RNN 层的结构。人们已经提出了诸多 Gated RNN 框架，其中具有代表性的有 LSTM 和 GRU

# PyTorch 代码示例

基础 RNN：

import torch
import torch.nn as nn

class SimpleRNN(nn.Module):
def __init__(self, input_size, hidden_size, num_classes):
super().__init__()
self.rnn = nn.RNN(input_size, hidden_size, batch_first=True)
self.fc = nn.Linear(hidden_size, num_classes)

def forward(self, x):
    # x: (batch, seq\_len, input\_size)
    out, hidden = self.rnn(x)  # out: (batch, seq\_len, hidden)
    # 取最后一个时间步
    out = self.fc(hidden\[-1\])
    return out

# 使用

model = SimpleRNN(input_size=100, hidden_size=128, num_classes=2)

用上面的 model，结合 IMDB 数据集进行情感分析：

# 超参数
batch_size = 64
seq_len = 100
learning_rate = 0.001

# 损失和优化器

criterion = nn.CrossEntropyLoss()
optimizer = torch.optim.Adam(model.parameters(), lr=learning_rate)

# 训练

for epoch in range(10):
model.train()
for batch_x, batch_y in train_loader:
optimizer.zero_grad()
output = model(batch_x)
loss = criterion(output, batch_y)
loss.backward()

    # 梯度裁剪（防止 RNN 梯度爆炸）⭐
    torch.nn.utils.clip\_grad\_norm\_(model.parameters(), 1.0)
    
    optimizer.step()

# 验证
model.eval()
val\_acc = evaluate(model, val\_loader)
print(f"Epoch {epoch}: Val Acc = {val\_acc:.4f}")

Word2Vec

Tue, 24 Mar 2026 03:46:01 +0000

Word2Vec 其实就是一个没有隐藏层激活函数的 2 层神经网络（浅层神经网络），用来将单词映射为低维稠密向量。

# 1. 核心原理

基于分布假设。通过大量文本语料学习词语的共现规律，将语义相似的词映射到向量空间中彼此靠近的位置

分布假设

"A word is characterized by the company it keeps."

（一个词是由它周围的词决定的。）

Word2Vec 包含两种浅层神经网络结构，核心目标是学习词向量，输入层到隐藏层为词嵌入映射，隐藏层到输出层为概率预测。

# 2.1 CBOW（Continuous Bag-of-Words，连续词袋模型）

核心任务：用上下文词预测中心词
特点：计算效率高，适合大规模语料；对高频词效果更优
类比：像 “完形填空”，根据周围词语推测中间缺失的词

# 2.2 Skip-gram（跳字模型）

核心任务：用中心词预测上下文词
特点：对低频词、生僻词效果更好；适合小数据集
类比：像 “联想扩散”，由一个词联想到周围相关的词

💡 经验：默认首选 Skip-Gram，除非数据量极大且追求速度。

# 3. 训练优化技巧

为解决大规模语料下的计算瓶颈，Word2Vec 引入两大核心优化，大幅提升训练效率。

# 0. 🔑 关键点：我们要的是什么？

训练完成后：

输出层权重：扔掉 ❌
投影层权重矩阵：保留 ✅

这个 V×N 的矩阵，每一行就是一个词的向量

# 1. 负采样（Negative Sampling）⭐ 最常用

思想：不需要更新所有词的权重，只更新正确的词和几个错误的词。
原理：将多分类问题转化为二分类任务
操作：对每个正样本（中心词 + 真实上下文词），随机采样 K 个负样本（中心词 + 噪声词）
优势：仅更新目标词与采样词的参数，避免全词表计算，训练速度提升显著

# 2. 层次 Softmax（Hierarchical Softmax）

原理：用 Huffman树 组织词汇表，将根节点到叶节点的 路径概率乘积 作为预测结果，类似于二叉搜索
优势：将时间复杂度从 O (V) 降至 O (logV)，V 为词汇量，适合超大词汇表

# 4. 局限性与发展

# 4.1 主要局限

静态向量：一词一向量，无法处理一词多义（如 “bank” 既指银行也指河岸）
忽略词序：依赖固定窗口，无法捕捉长距离语义依赖和词序信息
未登录词 OOV：无法处理训练语料外的新词（如新兴术语、专有名词）
上下文无关：同一词在不同语境下向量相同，语义表达不够精细

# 4.2 后续演进

FastText：引入子词信息，支持未登录词生成
GloVe：结合全局统计与局部上下文，提升语义表达
Transformer 系列：动态上下文编码，解决一词多义与长距离依赖问题（如 BERT、GPT）

# Word2Vec 示例代码

安装依赖库：pip install gensim nltk

import gensim
from gensim.models import Word2Vec
from gensim.utils import simple_preprocess
import nltk
from nltk.corpus import stopwords

# ---------------------- 1. 数据准备与预处理 ----------------------

# 下载nltk停用词（仅首次运行需要）

nltk.download('stopwords')
stop_words = stopwords.words('english')

# 示例语料（可替换为你自己的文本文件/大规模语料）

corpus = [
"Natural language processing is a subfield of artificial intelligence",
"Word2Vec is a popular technique for word embedding in NLP",
"Word embedding converts words into numerical vectors",
"Semantic similarity can be measured using word vectors",
"King minus man plus woman equals queen in word2vec",
"Tokyo is the capital of Japan, Beijing is the capital of China",
"Machine learning models use word vectors as input features",
"Cat likes eating fish and dog loves enjoying bones"
]

# 文本预处理函数：分词 + 去除停用词 + 过滤短词

def preprocess(text):
# 分词（gensim内置的简单分词，适合英文）
tokens = simple_preprocess(text, deacc=True) # deacc=True去除标点
# 过滤停用词和长度<2的词
tokens = [token for token in tokens if token not in stop_words and len(token) > 2]
return tokens

# 对语料库进行预处理，得到训练用的句子列表（每个句子是分词后的token列表）

processed_corpus = [preprocess(sentence) for sentence in corpus]
print("预处理后的语料：")
for sent in processed_corpus:
print(sent)

# ---------------------- 2. 训练Word2Vec模型 ----------------------

# 核心参数说明（新手重点关注）：

# - vector_size：词向量维度（常用50/100/300，小语料用50即可）

# - window：上下文窗口大小（中心词左右各window个词）

# - min_count：最小词频，低于该值的词忽略（过滤低频噪声）

# - sg：训练模型类型，sg=0为CBOW，sg=1为Skip-gram

# - workers：并行训练线程数（根据CPU核心数调整）

model = Word2Vec(
sentences=processed_corpus,
vector_size=50, # 词向量维度
window=3, # 上下文窗口
min_count=1, # 保留所有出现过的词（小语料专用）
sg=1, # 使用Skip-gram模型（对小语料更友好）
workers=4, # 4线程训练
epochs=100 # 训练轮数（小语料需增加轮数保证效果）
)

# 保存模型（可选，后续可直接加载）

model.save("word2vec_demo.model")

# 加载模型（后续使用时）：model = Word2Vec.load("word2vec_demo.model")

# ---------------------- 3. 模型使用示例 ----------------------

# 3.1 查看单个词的向量

print("\n=== 查看'plus'的词向量（前10维）===")
print(model.wv['plus'][:10]) # wv是word vector的缩写，存储所有词向量量

# 3.2 计算两个词的语义相似度

print("\n=== 计算语义相似度 ===")
print(f"like vs love: {model.wv.similarity('like', 'love'):.4f}")
print(f"beijing vs tokyo: {model.wv.similarity('beijing', 'tokyo'):.4f}")
print(f"king vs queen: {model.wv.similarity('king', 'queen'):.4f}")
print(f"china vs japan: {model.wv.similarity('china', 'japan'):.4f}")

# 3.3 找最相似的词

print("\n=== 找与'like'最相似的5个词 ===")
similar_words = model.wv.most_similar('like', topn=5)
for word, score in similar_words:
print(f"{word}: {score:.4f}")

# 3.4 语义类比（国王-男人+女人=王后）

print("\n=== 语义类比：king - man + woman == ? ===")
try:
analogy = model.wv.most_similar(positive=['king', 'woman'], negative=['man'], topn=1)
print(f"结果：{analogy[0][0]} (相似度：{analogy[0][1]:.4f})")
except KeyError as e:
print(f"类比失败：缺少词 {e}（语料太小导致）")

参数调整：

大规模语料：可将vector_size调至 100/300，min_count调至 5/10（过滤低频词），epochs调至 10-20；
小语料：保持 min_count=1，增加 epochs（如 100）保证训练效果。

如果结果奇怪：
根本原因：语料库太小了
直接用别人训练好的模型，不要自己训练小语料：

from gensim.models import KeyedVectors

# 加载 Google 预训练的 Word2Vec (300 维，300 万词)

# 下载地址：https://code.google.com/archive/p/word2vec/

model = KeyedVectors.load_word2vec_format('GoogleNews-vectors-negative300.bin', binary=True)

# 现在测试结果会正常！

print(model.wv.similarity('like', 'love')) # 应该 > 0.5
print(model.wv.similarity('king', 'queen')) # 应该 > 0.6

# 类比也会正确

result = model.wv.most_similar(positive=['king', 'woman'], negative=['man'])
print(result[0][0]) # 应该输出 'queen'

自然语言和单词的分布式表示

Tue, 24 Mar 2026 03:19:50 +0000

核心问题：神经网络只能处理数字，但人类语言是文字。
如下，怎么把"我"、"喜欢"、"深度"、"学习"变成向量？

人类： "我喜欢深度学习"
↓ ???
计算机： [?, ?, ?, ?, ?, ?]

# 表示方法的演进

# 1️⃣ 最早期：One-Hot 编码（独热编码）

方法：每个词用一个超长向量表示，只有一个位置是 1，其他都是 0。

词典：["我", "喜欢", "讨厌", "深度", "学习", "电影", ...] 假设共 10000 词

"我" → [1, 0, 0, 0, 0, 0, ..., 0] (第 1 位是 1)
"喜欢" → [0, 1, 0, 0, 0, 0, ..., 0] (第 2 位是 1)
"讨厌" → [0, 0, 1, 0, 0, 0, ..., 0] (第 3 位是 1)
"学习" → [0, 0, 0, 0, 1, 0, ..., 0] (第 5 位是 1)

优点

缺点

简单直观

维度灾难：词典 10 万词 = 10 万维向量

容易实现

语义鸿沟：任意两个词向量正交（内积=0）

无法表示相似性："喜欢"和"讨厌"距离一样远（如下例）

向量空间示意（One-Hot）：

"喜欢" ● 所有词都在坐标轴上
│ 彼此距离相等
│
●──────┼──────● "讨厌"
"me" │ "学习"
│
●
"电影"

问题：无法表达"喜欢"和"爱"更接近 ❌

# 2️⃣ 突破：分布式表示（Distributed Representation）⭐

核心思想（Hinton, 1986）：用低维稠密向量表示单词，语义相似的词向量也相似。

词典：10000 词 → 向量维度：300

"我" → [0.25, -0.31, 0.67, ..., 0.12] (300 维稠密向量)
"喜欢" → [0.82, -0.45, 0.33, ..., 0.56]
"爱" → [0.79, -0.42, 0.35, ..., 0.54] ← 和"喜欢"很接近！
"讨厌" → [-0.75, 0.51, -0.28, ..., -0.61] ← 和"喜欢"距离远
"学习" → [0.45, -0.12, 0.78, ..., 0.33]

向量空间示意（分布式表示）：

    "爱" ●
        ╱
       ╱   ← 语义相近，向量距离近 ✅
      ╱

"喜欢" ●───────● "热爱"
╲
╲
╲
● "讨厌" ← 语义相反，距离远

"学习" ● ● "电影" ← 无关词，距离中等

为什么叫"分布式"？

One-Hot：信息集中在一个位置（向量中只有 1 个 1，其余都是 0）

分布式：信息分布在整个向量的所有维度

# 向量相似度

可以用两个词向量之间的 内积 或 余弦相似度 来表示向量之间的相关性

把所有词向量组成的大矩阵称为 嵌入矩阵：每一列都是一个词向量。
这个矩阵可以通过 word2vec 等方式训练获得

词向量的维度很高，所以它所在空间的维度也很高，这个空间叫做 潜空间。对于高维潜空间，可以通过降维投影等操作直观感受，参考： https://projector.tensorflow.org/ 。

# 学习词向量的经典方式

# 1️⃣ Word2Vec（2013）⭐ 最经典

提出者：Google 的 Tomas Mikolov
核心思想：一个词的语义由它周围的词决定，文本中离得越近的词语相似度越高（分布假说）
两种训练方式：

模型

输入

输出

比喻

Skip-Gram 跳元模型（常用）

中心词

上下文词

"给定这个词，预测周围"

CBOW 连续词袋

上下文词

中心词

"猜中间是什么词"

CBOW: ["我", "深度", "学习"] → "喜欢"
(上下文) (中心词)

Skip-Gram: "喜欢" → ["我", "深度", "学习"]
(中心词) (上下文)

Word2Vec 的架构：

    输入层          隐藏层         输出层
   (词索引)        (词向量)       (概率分布)
      
      ●              ●              ● ● ● ●
      │              │              │ │ │ │
      │              │              │ │ │ │
输入词索引  →   查找向量表  →   Softmax  →  预测词
(one-hot)      (V×N 矩阵)        (V 维)

V = 词典大小 (如 10000)
N = 向量维度 (如 300)

💡 关键：训练完成后，隐藏层的权重矩阵就是词向量表！

# 2️⃣ GloVe（2014）

提出者：Stanford 的 Jeffrey Pennington
核心思想：基于全局词共现统计，而不是局部窗口。
500
GloVe 目标：让上面 共现矩阵（co-occurence matrix）向量内积 ≈ log(共现次数)

# 3️⃣ FastText（2016）

提出者：Facebook AI
核心思想：考虑词内部的字符 n-gram。

优点

缺点

能处理未登录词（OOV）

向量维度更大

适合形态丰富的语言（如德语、俄语）

计算稍慢

中文效果提升有限

# 静态 vs 动态词向量

# 1️⃣ 静态词向量（2013-2017）

方法

特点

Word2Vec

一个词只有一个向量

GloVe

不管上下文

FastText

考虑子词，但仍静态

"苹果"在以下句子中意思不同，但向量相同 ❌

"我吃了一个苹果" → 水果
"我买了苹果股票" → 公司
"苹果发布了新手机" → 公司

Word2Vec: "苹果" → [0.5, -0.3, 0.8, ...] (固定不变)

# 2️⃣ 动态词向量（2018-至今）主流⭐

方法

特点

ELMo (2018)

用双向 LSTM，上下文相关

BERT (2018)

用 Transformer，上下文相关 ⭐

GPT 系列

自回归，上下文相关

BERT:
"我吃了一个苹果" → "苹果" → [0.6, -0.2, 0.9, ...] (水果义)
"我买了苹果股票" → "苹果" → [0.8, -0.5, 0.4, ...] (公司义)

同一个词，不同上下文，向量不同 ✅

自然语言处理 NLP

Tue, 24 Mar 2026 03:10:03 +0000

自然语言处理（Natural Language Processing，NLP） = 让计算机理解、生成、处理人类语言的技术。NLP 的核心任务著有可以分为 3 类：理解类、生成类、其他类。

# NLP 技术演进史

# 1️⃣ 规则系统时代（1950s-1990s）

方法：人工编写语法规则、词典
例子：ELIZA 聊天机器人（1966）
缺点：规则太多，维护困难，无法处理例外

# 2️⃣ 统计机器学习时代（1990s-2010s）

方法：HMM、CRF、SVM 等统计模型
优点：可以从数据中学习，不需要手工写规则
缺点：特征工程复杂，需要大量人工设计特征

# 3️⃣ 深度学习时代（2013-2017）⭐

突破：Word2Vec（2013）让词有了向量表示
模型：RNN、LSTM、GRU、CNN
优点：自动学习特征，效果大幅提升

# 4️⃣ Transformer 时代（2017-至今）🚀

突破：Attention Is All You Need（2017）
模型：BERT（2018）、GPT 系列、T5
优点：并行计算、长距离依赖、效果碾压 RNN

# 5️⃣ 大语言模型时代（2020-至今）🦄

特点：超大规模参数（千亿级）、预训练 + 微调
代表：GPT-3/4、Claude、LLaMA、ChatGLM
能力：零样本学习、多任务通用、接近人类水平

# NLP 的核心概念

# 1️⃣ 分词（Tokenization）

把句子切成模型能处理的"单元"

英文："I love NLP" → ["I", "love", "NLP"]
中文："我爱 NLP" → ["我", "爱", "NLP"]

更细粒度（Subword）：
"playing" → ["play", "##ing"]
"不喜欢" → ["不", "喜欢"]

空格分词

英文适用，中文不行

字符级

每个字独立，序列太长

词级

需要词典，未登录词问题

Subword

BPE、WordPiece，平衡粒度和词汇量 ⭐

# 2️⃣ 词嵌入（Word Embedding）

把单词变成稠密向量，保留语义信息

"国王" → [0.85, -0.32, 0.67, ...]
"王后" → [0.83, -0.30, 0.69, ...]
"男人" → [0.75, -0.45, 0.55, ...]
"女人" → [0.73, -0.43, 0.57, ...]

向量运算："国王" - "男人" + "女人" ≈ "王后" ✅

One-Hot

早期

稀疏，无语义关系

Word2Vec

2013

稠密，有语义，静态 ⭐

GloVe

2014

基于全局共现统计

FastText

2016

支持子词，处理未登录词

BERT Embedding

2018

上下文相关，动态 ⭐⭐⭐

# 3️⃣ 注意力机制（Attention）⭐ 核心突破

让模型学会"关注重要的部分"

翻译："The animal didn't cross the street because it was too tired"
↓
"it" 指的是谁？
↓
注意力指向 "animal" ✅

自注意力（Self-Attention）：

每个词都可以"看"句子中的其他词
计算权重，决定关注谁
并行计算，比 RNN 快得多

# 4️⃣ 预训练 + 微调（Pretrain + Finetune）

现代 NLP 的标准范式：

第 1 步：预训练
用海量无标签文本（维基百科、网页）训练通用语言模型
学习：语法、语义、常识、推理...
↓
第 2 步：微调
用少量有标签数据（如情感分析数据）训练特定任务
学习：分类边界、任务特定模式

💡 类比：预训练 = 读万卷书（通识教育），微调 = 专业训练（职业技能）

NetworkPolicy

Fri, 13 Mar 2026 23:03:39 +0000

NetworkPolicy = Kubernetes 里 Pod 级别的网络防火墙，它基于标签选择器定义允许的入站（Ingress）和出站（Egress）流量，默认遵循“白名单”原则：一旦某个 Pod 被任何 NetworkPolicy 选中，未明确允许的流量都会被拒绝。

实验要求：

从提供的 YAML 样本中查看并应用适当的 NetworkPolicy。
确保选择的 NetworkPolicy 不过于宽松，同时允许运行在 frontend 和 backend namespaces 中的 frontend 和 backend Deployment 之间的通信。
- 首先，分析 frontend 和 backend Deployment，以确定需要应用的 NetworkPolicy 的具体要求。
- 接下来，检查位于 ~/netpol 文件夹中的 NetworkPolicy YAML 示例。
  - 注意：请勿删除或修改提供的示例。仅应用其中一个。否则可能会导致分数降低。
- 最后，应用启用 frontend 和 backend Deployment 之间的通信的 NetworkPolicy，但不要过于宽容。
  - 注意：请勿删除或修改现有的默认拒绝所有入站流量或出口流量 NetworkPolicy。否则可能导致零分。

参考链接：无
难度：⭐⭐

# 0. 环境确认

题干要求：“不过于宽松”，即最小权限原则

查看`~/netpol`目录，发现存在 3 个文件，内容如下：

# netpol1.yaml ❌ 过于宽松


apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: netpol-1
  namespace: backend
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: frontend

第 7 行，⚠️ 会选择 backend 命名空间 ALL Pods

# netpol2.yaml ✅ 正确选择


apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: netpol-2
  namespace: backend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: frontend
      podSelector:
        matchLabels:
          app: frontend

第 7 行，只选择 backend Pods
第 19 行，同时检查 namespace + Pod 标签

# netpol3.yaml ❌ 配置错误


apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: netpol-3
  namespace: backend
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: frontend
      podSelector:
        matchLabels:
          app: frontend
    - ipBlock:
        cidr: 10.0.0.0/24

第 9 行，错误标签（应该是 backend）
第 21 行，⚠️ 额外开放整个网段，过于宽松

# 1. 选择 netpol2.yaml 并应用

# 2. 检查

netpol2.yaml 中配置的 NetworkPolicy 位于命名空间 backend

Gateway

Fri, 13 Mar 2026 22:40:27 +0000

K8s Gateway 是官方新一代流量入口标准（Gateway API），用来替代 / 升级传统 Ingress，专门管理外部流量进入 Kubernetes 集群的南北向流量。

Gateway = 更强大、更规范、云原生的下一代 Ingress

实验要求：

将现有 Web 应用程序从 Ingress 迁移到 Gateway API。您必须维护 HTTPS 访问权限。
- 注意：集群中安装了一个名为 nginx 的 GatewayClass 。
首先，创建一个名为 web-gateway 的 Gateway ，主机名为 gateway.web.k8s.local ，并保持现有名为 web 的 Ingress 资源的现有 TLS 和侦听器配置。
接下来，创建一个名为 web-route 的 HTTPRoute ，主机名为 gateway.web.k8s.local ，并保持现有名为 web 的 Ingress 资源的现有路由规则。
- 您可以使用以下命令测试 Gateway API 配置：
  - [candidate@cka000057]$ curl -Lk https://gateway.web.k8s.local:31443
最后，删除名为 web 的现有 Ingress 资源。

参考链接： https://kubernetes.io/docs/concepts/services-networking/gateway/
难度：⭐⭐⭐

# 0. 环境确认

kubectl get ingress web -o yaml：

创建 Gateway 时需要：查看 spec.tls.secretName
创建 HTTPRoute 时需要：查看 spec.rules.http.paths.backend 和 spec.rules.http.paths.path

# 1. 编写 gateway.yaml 并应用

# 2. 编写 httproute.yaml 并应用

# 3. 验证并删除 ingress web

# 补充内容

# Ingress，Gateway 和 HTTPRoute

Gateway 和 HTTPRoute 是 Kubernetes Gateway API 的两个核心资源，共同替代传统的 Ingress 实现更灵活的流量管理。

Gateway 负责基础设施层，定义监听器（端口、协议、主机名）和 TLS 配置，由平台团队管理；
HTTPRoute 负责应用层，定义路由规则（路径匹配、权重分发、后端服务），由应用团队管理。两者通过 parentRefs 关联，实现职责分离。

Gateway 和 HTTPRoute

Ingress

关系

说明

Ingress

第一代流量入口资源（已成熟，但功能有限）

Gateway

第二代流量入口的基础设施层（监听器+TLS）

HTTPRoute

第二代流量入口的应用层（路由规则）

Gateway + HTTPRoute

替代 Ingress 的新标准

# 配置对比

Ingress 配置（全部在一起）:


apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
spec:
  # ⚠️ TLS 配置在这里
  tls:
  - hosts:
    - example.com
    secretName: tls-secret

  # ⚠️ 路由规则也在这里
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

Gateway + HTTPRoute 配置（职责分离）:


## ===== Gateway（基础设施团队管理）=====
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: web-gateway
spec:
  gatewayClassName: nginx
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    hostname: example.com
    # ⚠️ TLS 配置在这里
    tls:
      mode: Terminate
      certificateRefs:
      - kind: Secret
        name: tls-secret

---
## ===== HTTPRoute（应用团队管理）=====
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: web-route
spec:
  # ⚠️ 引用 Gateway
  parentRefs:
  - name: web-gateway
    kind: Gateway

  hostnames:
  - example.com

  # ⚠️ 路由规则在这里
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: web-service
      kind: Service
      port:
        number: 80

# 功能对比

功能

Ingress

Gateway + HTTPRoute

HTTP 路由

✅ 支持

HTTPS/TLS

✅ 支持

✅ 支持（更灵活）

路径匹配

✅ 前缀/精确

✅ 前缀/精确/正则

主机名匹配

✅ 支持

多监听器

❌ 有限

✅ 原生支持

TCP/UDP

❌ 不支持

✅ 支持 (TCPRoute/UDPRoute)

gRPC

❌ 不支持

✅ 支持 (GRPCRoute)

流量拆分

❌ 困难

✅ 原生支持

跨命名空间

❌ 困难

✅ 原生支持

角色分离

❌ 混合

✅ 清晰分离

API 成熟度

✅ GA

✅ GA (v1)

PAB's Blog

Hello World

# Quick Start

# Create a new post

# Run server

# Generate static files

# Deploy to remote sites

Seldon Core 1

# 架构

# 认识 SeldonDeployment

# Sldon Operator

# 与直接写 Deployment 相比

22-系统加固：特权容器逃逸与配置安全上下文限制

# 心智模型

# 🛠️ 实操手册：逃逸演示与防御配置

# 第一阶段：演示特权容器逃逸（危险操作，仅限实验）

# 第二阶段：配置安全上下文限制权限提升

# 🔍 核心参数深度解析

21-系统加固：Seccomp

# 🛠️ 实操手册：配置 Seccomp Profile

# 第一阶段：使用 RuntimeDefault (最推荐的生产配置)

# 第二阶段：自定义 Seccomp Profile (精细化控制)

# 第三阶段：验证实验结果

# 避坑指南

20-系统加固：Apparmor

# 心智模型

# 实验：部署和引用 AppArmor Profile

# 第一阶段：在 Worker 节点准备 Profile

# 第三阶段：验证防御效果

# 💡 关键要点总结

19-集群设置：TLS Ingress 实验

# 步骤 1：安装 NGINX Ingress Controller

# 步骤 2：生成自签名的 TLS 证书

# 步骤 3：在 Kubernetes 中创建 TLS Secret

# 步骤 4：部署测试应用 (后端服务)

# 步骤 5：配置带有 TLS 的 Ingress

# 步骤 6：在 Killercoda 中测试 HTTPS

18-集群设置：kube-bench

# 心智模型：

# 实验步骤指南

# 方式一（推荐）：直接用 Job

# Kubernetes 安全 = 4层防线

Untitled Post - 4

17-使用 etcdctl 练习备份与恢复集群数据

# 第一部分：etcd 备份与恢复的心智模型

# 第二部分：实战演练指南

# 第一步：准备“万能钥匙”（设置 Alias）

# 第二步：制造“案发现场”（创造测试数据）

# 第三步：时空冻结（执行备份）

# 第四步：模拟灾难（破坏数据）

# 第五步：解压快照（生成新目录）

# 第六步：大脑移植（切换 etcd 数据目录）

# 第七步：见证奇迹

# 总结

16-多容器架构实战（Sidecar 边车模式收集日志）

# 核心技术逻辑：Sidecar（边车）模式与共享卷

# 实战挑战

# 阶段二：见证 Sidecar 的魔法 (CKA 必考命令)

# 清理

Custom Styles

Custom Styles

Transformer 简介

# 背景

# 注意力机制 Attention

# 多头注意力机制 Multi-Head Attention

# Transformer 论文架构图

# 整体架构

# 多头注意力架构

# 编码器与解码器

长短期记忆 LSTM

# 背景：RNN 梯度消失

# LSTM 的结构及接口

# 输出门 Output Gate

# 遗忘门 Forget Gate

# 输入门 Input Gate

# 新的记忆单元

# LSTM 不会梯度消失

# PyTorch 代码示例

# 使用

# 超参数

# 第一阶段：使用 `RuntimeDefault` (最推荐的生产配置)