![\"\"](\"/wp-uploads/2026/03/1774354582-image-744x1024.png\")
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.
\n$ hexo new \"My New Post\"More info: Writing
\n$ hexo serverMore info: Server
\n$ hexo generateMore info: Generating
\n$ hexo deployMore info: Deployment
\n", "tags": [] }, { "id": "https://www.bondrewd.com/2026/07/17/seldon-core-1/", "url": "https://www.bondrewd.com/2026/07/17/seldon-core-1/", "title": "Seldon Core 1", "date_published": "2026-07-17T07:58:34.000Z", "content_html": "Seldon Core一个运行在 Kubernetes 上的机器学习模型服务平台，用来把训练好的模型部署成可访问、可扩缩、可观测的在线推理服务。这里学习的是1版本。
\n它解决的不是“怎么训练模型”，而是：
\n\n\n当前官方重点已经转向 Seldon Core 2。Core 2 被定位为 Kubernetes 上的 MLOps/LLMOps 框架，可以管理单模型、多个模型以及模块化推理应用。
\n
Seldon Core 1 在K8s 上增加了一个更高层的抽象：SeldonDeployment。
\n这里描述的是模型推理服务，Seldon Operator 再将它转换成 k8s 能运行的资源。
\n官方将 SeldonDeployment 定义为 Kubernetes 自定义资源，用户通过它描述模型组件和推理图。
一个简单示例如下：
\napiVersion: machinelearning.seldon.io/v1\nkind: SeldonDeployment\nmetadata:\n name: iris-model\n namespace: seldon\nspec:\n name: iris\n predictors:\n - name: default\n replicas: 1\n\n graph:\n name: classifier\n type: MODEL\n implementation: SKLEARN_SERVER\n modelUri: gs://seldon-models/sklearn/iris\n\n componentSpecs:\n - spec:\n containers:\n - name: classifier\n resources:\n requests:\n cpu: 100m\n memory: 256Mi\n limits:\n cpu: 1\n memory: 1Gi这一份 YAML 里混合了两类信息：
\n\n模型语义\n+\nKubernetes 运行配置spec.predictors
predictors:\n - name: default一个 predictors 可以理解为：一套可以独立接收推理请求的模型服务配置。
\n其中可以包含：
\n模型；\n输入转换器；\n输出转换器；\n路由器；\n组合器；\n副本数量；\nPod 配置。replicas
repicas: 1描述该 predictor 的副本数量。但实际生成资源时，可能根据图结构和组件配置创建一个或多个 Deployment，因此不要机械认为一个 predictor 永远只对应一个 Deployment。
\ngraph
graph:\n name: classifier\n type: MODEL\n implementation: SKLEARN_SERVER\n modelUri: gs://seldon-models/sklearn/iris是 Seldon 相比普通 Deployment 最核心的能力之一，描述的是推理组件之间的调用关系。
\n只有一个模型时：
\nrequest\n ↓\nclassifier\n ↓\nresponse稍微复杂一点：
\nrequest\n ↓\ninput-transformer\n ↓\nclassifier\n ↓\noutput-transformer\n ↓\nresponse还可以存在：
\nrequest\n ↓\nrouter\n ┌─┴─────────┐\n ↓ ↓\nmodel-a model-b\n └────┬──────┘\n ↓\n combiner\n ↓\n responseSeldon Core 1 官方文档说明，推理图可以由模型以及 router、combiner、输入和输出 transformer 等组件构成。
\n普通 Kubernetes Deployment 只知道：
\n运行哪些容器SeldonDeployment 还知道：
\n这些模型组件之间应该如何调用graph 是根节点，children 表示连接的下一层节点，多个 - 表示多个并列节点，implementation 选择预打包服务器，modelUri 指向模型目录。
implementation
implementation: SKLEARN_SERVER意思是：
\n\n\n使用 Seldon 已经准备好的 sklearn 推理服务器运行模型。
\n
Seldon Core 1 提供了多种预打包推理服务器，例如：
\n因此你不一定要自己完整实现：
\nHTTP Server\n请求反序列化\n模型加载\npredict 调用\n响应序列化这是 Seldon 比“直接写 Deployment”多做的一层标准化。
\n\n\n什么是预打包服务器？
\n预：提前准备好
\n打包：把代码、依赖库、运行环境放进一个容器镜像里
\n“服务器”则表示它不是普通脚本，而是一个会持续运行、接收网络请求并返回预测结果的程序。
\n所以预打包服务器指：提前打包好的，用于运行模型的服务器程序。之所以叫这个名字，核心原因就是：服务器代码和运行环境已经由 Seldon 提前封装好了，你不需要自己再写和配置。
\n
modelUri
modelUri: gs://seldon-models/sklearn/iris描述模型文件的位置，而不是容器镜像的位置。
\nSeldon 可以使用预打包模型服务器，然后根据 modelUri 加载模型。官方 SKLearn 示例就是通过 implementation 和 modelUri 描述模型服务。
conponentSpec
componentSpecs:\n - spec:\n containers:\n - name: classifier\n resources:\n requests:\n cpu: 100m\n memory: 256Mi非常接近 Kubernetes 的：
\nPodTemplateSpec它用于描述：
\n因此可以这样理解：
\ngraph描述模型推理逻辑。
\ncomponentSpecs描述模型组件如何在 Kubernetes 中运行。
\n核心循环抽象：
\n\nfunc Reconcile(request Request) {\n // 1. 获取 SeldonDeployment\n sdep := getSeldonDeployment(request)\n\n // 2. 根据 spec 计算期望资源\n desiredDeployments := buildDeployments(sdep)\n desiredServices := buildServices(sdep)\n\n // 3. 查询当前资源\n currentDeployments := getDeployments(sdep)\n currentServices := getServices(sdep)\n\n // 4. 对比期望状态与当前状态\n diff := compare(\n desiredDeployments,\n currentDeployments,\n )\n\n // 5. 创建、更新或删除资源\n apply(diff)\n\n // 6. 更新状态\n updateStatus(sdep)\n}模型语义 Deployment 只知道运行镜像，SeldonDeployment 能表达：
\n这是 MODEL\n这是 ROUTER\n这是 TRANSFORMER\n这是 COMBINER推理图
\nDeployment 本身不能直接表达：
\n请求 → 预处理 → 模型 → 后处理SeldonDeployment 可以通过 graph 描述这种关系。
标准推理服务器
\n普通 Deployment 通常需要你自己准备完整模型服务镜像。
\nSeldon 可以使用预打包服务器运行 sklearn、XGBoost、MLflow 等模型。
\n攻击者容易利用特权容器从受限容器环境侵入宿主机操作系统。
\n我们将演示攻击者如何利用特权容器直接访问宿主机的磁盘。
\nprivileged: true 这个开关。YAML
\n\napiVersion: v1\nkind: Pod\nmetadata:\n name: privileged-escape-demo\nspec:\n containers:\n - name: attacker-container\n image: alpine\n command: [\"sh\", \"-c\", \"sleep 3600\"]\n securityContext:\n privileged: true # 开启特权模式Bash
\n\n## 进入容器\nkubectl exec -it privileged-escape-demo -- sh\n\n## 在容器内，查看宿主机的磁盘设备（通常是 /dev/sda1 或 /dev/nvme0n1p1）\nfdisk -l\n\n## 创建一个挂载点并挂载宿主机根目录\nmkdir /host_root\nmount /dev/sda1 /host_root # 请根据 fdisk 结果替换设备名\n\n## 现在，你已经在容器里看到了宿主机的所有敏感文件\nls /host_root/etc/shadow\nls /host_root/root/.ssh/\n\n结论：一旦开启
\nprivileged: true，容器与宿主机之间已无安全可言。
仅仅不开启 privileged 就够了吗？不够。 很多进程会利用 setuid（如 sudo 命令）在运行时尝试获取更高级别的权限。我们需要通过 allowPrivilegeEscalation: false 封死这条路。
YAML
\n\napiVersion: v1\nkind: Pod\nmetadata:\n name: hardened-pod\nspec:\n containers:\n - name: safe-container\n image: alpine\n command: [\"sh\", \"-c\", \"sleep 3600\"]\n securityContext:\n # 1. 明确禁止特权模式\n privileged: false\n # 2. 禁止进程通过 setuid 等方式获取比父进程更高的权限\n allowPrivilegeEscalation: false\n # 3. 配合之前的实验，以非 root 用户运行\n runAsNonRoot: true\n runAsUser: 1000allowPrivilegeEscalation (禁止权限提升)
no_new_privs 内核标志。如果设为 false，即使一个程序设置了 SUID 位（比如一个只有 root 才能跑的程序），普通用户也无法通过它获得 root 权限。readOnlyRootFilesystem (只读根文件系统)
建议配合使用：
\nYAML
\nsecurityContext:\n readOnlyRootFilesystem: true效果：容器的整个根目录变成只读。如果黑客想下载一个木马脚本到 /tmp 或 /bin，会直接被内核拦截。
Seccomp (Secure Computing mode) 是 Linux 内核的一项功能，用于限制容器可以发起的系统调用 (System Calls)。
\n在 Kubernetes 中，Seccomp 已经比 AppArmor 更加标准化，直接集成在 securityContext 字段中。
RuntimeDefault (最推荐的生产配置)这是容器运行时（如 containerd 或 Docker）自带的一套“安全模板”，它禁用了大约 40 多个危险的系统调用。
\nspec 字段中。YAML
\n\napiVersion: v1\nkind: Pod\nmetadata:\n name: seccomp-default-pod\nspec:\n securityContext:\n # 在 Pod 级别应用 seccomp\n seccompProfile:\n type: RuntimeDefault\n containers:\n - name: web-app\n image: nginx有时候默认配置还是太宽松，或者你需要运行极其特殊的应用。
\n在 Worker 节点创建 Profile 目录： Kubelet 默认在特定的安全目录下寻找 Profile。
\nBash
\n# 在所有 Worker 节点执行\nsudo mkdir -p /var/lib/kubelet/seccomp/profiles编写 JSON Profile： 创建一个名为 audit-only.json 的文件，它的作用是：允许大部分操作，但对某些操作记录日志（用于审计）。
JSON
\n\n{\n \"defaultAction\": \"SCMP_ACT_ALLOW\",\n \"architectures\": [\n \"SCMP_ARCH_X86_64\"\n ],\n \"syscalls\": [\n {\n \"names\": [\n \"reboot\"\n ],\n \"action\": \"SCMP_ACT_KILL\"\n }\n ]\n}\n\n语法解释：如果进程尝试调用
\nreboot（重启），内核会直接杀掉 (SCMP_ACT_KILL) 该进程。
/var/lib/kubelet/seccomp/profiles/audit-only.json。YAML
\n\napiVersion: v1\nkind: Pod\nmetadata:\n name: seccomp-custom-pod\nspec:\n containers:\n - name: test-container\n image: busybox\n command: [\"sh\", \"-c\", \"sleep 3600\"]\n securityContext:\n seccompProfile:\n type: Localhost\n # 注意：这里的路径是相对于 /var/lib/kubelet/seccomp/ 的相对路径\n localhostProfile: profiles/audit-only.json部署 Pod：
\nBash
\nkubectl apply -f seccomp-custom-pod.yaml测试拦截效果： 由于我们设置了 reboot 就会被 KILL，我们可以进入容器尝试触发这个调用。
Bash
\nkubectl exec seccomp-custom-pod -- reboot预期现象： 你会发现连接被断开，或者提示 command terminated with exit code 137。这是因为内核检测到非法调用，瞬间终止了进程。
localhostProfile 时，不要写绝对路径 /var/lib/...。Kubelet 会自动拼凑前缀。最小权限原则，要求每个程序或系统进程这你能访问其任务所必须的信息和资源。
\nAppArmor 是 Linux 内核模块，因此 Profile 必须加载到每一个运行 Pod 的节点内核中。
\nk8s-deny-write 的配置文件，禁止容器写入任何文件。Bash
\n\ncat <<EOF > /etc/apparmor.d/k8s-deny-write\nprofile k8s-deny-write flags=(attach_disconnected) {\n # 包含基本抽象\n include <abstractions/base>\n\n # 拒绝所有写入操作\n deny /** w,\n}\nEOFapparmor_parser 命令解析并加载该配置文件。Bash
\n\nsudo apparmor_parser -r -W /etc/apparmor.d/k8s-deny-writeBash
\n\nsudo aa-status grep k8s-deny-write第二阶段：在 Pod 中通过 Annotation 引用
\n在 Kubernetes 1.30 之前的版本中，AppArmor 主要通过 Annotation (注解) 进行配置。
\ncontainer.apparmor.security.beta.kubernetes.io/<container_name>: localhost/<profile_name>。YAML
\n\napiVersion: v1\nkind: Pod\nmetadata:\n name: apparmor-test-pod\n annotations:\n # 这里的 'test-container' 必须匹配下方的容器名\n # 'localhost/k8s-deny-write' 表示引用节点本地加载的 profile\n container.apparmor.security.beta.kubernetes.io/test-container: localhost/k8s-deny-write\nspec:\n containers:\n - name: test-container\n image: busybox\n command: [\"sh\", \"-c\", \"echo 'Hello AppArmor' && sleep 3600\"]Bash
\n\nkubectl apply -f apparmor-pod.yaml我们要验证“最小权限”是否生效：
\nBash
\n\nkubectl exec apparmor-test-pod -- touch /tmp/test.txttouch: /tmp/test.txt: Permission denied。Bash
\n\ndmesg grep -i apparmor你会看到类似 apparmor="DENIED" 的记录，这证明内核成功拦截了违规操作。
步骤
\n核心操作
\n注意事项
\n节点侧
\n加载 Profile 到内核
\n必须在所有潜在的 Worker 节点上执行。
\n集群侧
\nPod Annotation 引用
\n格式必须极其精确，否则 Pod 可能无法启动或静默失败。
\n维护
\n审计与调优
\n生产环境通常先使用 complain 模式（仅记录不拦截）观察业务需求，再转为 enforce。
\n\n", "tags": [ "k8s 实验" ] }, { "id": "https://www.bondrewd.com/2026/07/16/19-%E9%9B%86%E7%BE%A4%E8%AE%BE%E7%BD%AE%EF%BC%9Atls-ingress-%E5%AE%9E%E9%AA%8C/", "url": "https://www.bondrewd.com/2026/07/16/19-%E9%9B%86%E7%BE%A4%E8%AE%BE%E7%BD%AE%EF%BC%9Atls-ingress-%E5%AE%9E%E9%AA%8C/", "title": "19-集群设置：TLS Ingress 实验", "date_published": "2026-07-16T05:56:40.000Z", "content_html": "注意： 从 Kubernetes 1.30 开始，AppArmor 已进入正式版 (GA)，推荐开始使用
\nsecurityContext.appArmorProfile字段替代 Annotation，但目前社区中 Annotation 仍是最通用的学习和迁移方式。
实验在 Killercoda 进行，自己搭的网络实在是太麻烦了。
\nKillercoda 的默认集群没有自带 Ingress 控制器，我们需要手动部署官方的裸机（Bare-metal）版本。
\n在终端中执行以下命令：
\nkubectl 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 状态再继续。
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \\\n -keyout tls.key -out tls.crt \\\n -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)：组织机构名称。将生成的证书存入 Secret 中：
\n\nkubectl create secret tls my-tls-secret \\\n --key tls.key \\\n --cert tls.crt部署简单的 NGINX 容器作为后端。可以直接在终端粘贴以下命令，它会使用 cat 直接生成并应用配置文件：
cat <<EOF kubectl apply -f -\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: hello-app\nspec:\n replicas: 1\n selector:\n matchLabels:\n app: hello-app\n template:\n metadata:\n labels:\n app: hello-app\n spec:\n containers:\n - name: hello-app\n image: nginxdemos/hello:plain-text\n ports:\n - containerPort: 80\n---\napiVersion: v1\nkind: Service\nmetadata:\n name: hello-service\nspec:\n selector:\n app: hello-app\n ports:\n - port: 80\n targetPort: 80\nEOF与 Minikube 稍有不同，在标准集群中，显式声明 ingressClassName: nginx 是一个好习惯，确保流量被正确接管。
Bash
\ncat <<EOF kubectl apply -f -\napiVersion: networking.k8s.io/v1\nkind: Ingress\nmetadata:\n name: secure-ingress\nspec:\n ingressClassName: nginx # 指定使用我们刚刚安装的 Nginx Ingress\n tls:\n - hosts:\n - my-secure-app.com\n secretName: my-tls-secret\n rules:\n - host: my-secure-app.com\n http:\n paths:\n - path: /\n pathType: Prefix\n backend:\n service:\n name: hello-service\n port:\n number: 80\nEOF我们刚才安装的裸机版 Ingress Controller 是通过 NodePort 暴露在集群上的。我们需要获取它暴露的 443 (HTTPS) 端口的映射端口。
\n1. 自动提取 HTTPS 的 NodePort 端口号并存入变量：
\nHTTPS_NODEPORT=$(kubectl get svc ingress-nginx-controller -n ingress-nginx -o jsonpath='{.spec.ports[?(@.name==\"https\")].nodePort}')\necho \"HTTPS NodePort is: $HTTPS_NODEPORT\"2. 发起请求测试： 我们直接在 Killercoda 的终端里，向本机的（localhost）这个 NodePort 发起请求，同样强制指定 Host 头：
curl -kv https://localhost:$HTTPS_NODEPORT -H \"Host: my-secure-app.com\"-k： 允许连接到“不安全”的 SSL 站点。
\n-v：输出详细日志。
\n-H：手动注入 HTTP Header 中的 Host 字段
\n期望结果： 会在输出信息中看到 Server certificate: my-secure-app.com 的 TLS 握手信息，并看到底层 NGINX 应用返回的纯文本内容（如 Server address 和 Server name 等信息）。这证明在 Killercoda 标准集群上，TLS 终结实验圆满成功！
kube-bench 进行集群安全加固是 Kubernetes 运维中的高级进阶任务。它主要基于 CIS (Center for Internet Security) Kubernetes Benchmark 标准来检查集群配置。
在操作之前，需要建立这样一个逻辑回路：
\nkube-bench 作为一个二进制工具或容器运行，它会读取主机的进程参数（如 ps -ef grep kube-apiserver）和配置文件。[PASS]（通过）、[FAIL]（失败）或 [WARN]（警告）。每个 [FAIL] 都会附带一个 Remediation（修复建议）。/etc/kubernetes/manifests/ 下的 YAML。由于这些是 Static Pod，kubelet 会监控文件变化并自动重启组件应用新参数。\nkubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml查看结果：
\n\nkubectl logs job/kube-bench你会看到类似：
\n\n[PASS] 1.1.1 Ensure API server pod specification file permissions are set to 644 or more restrictive\n[FAIL] 1.2.7 Ensure that the --authorization-mode argument includes Node2.定位漏洞与修复
\n假设报告中出现以下失败项：
\n3. 修改 Manifest
\n进入目录并编辑 API Server 的定义文件：
\n\ncd /etc/kubernetes/manifests/\nvi kube-apiserver.yaml在 spec.containers.command 列表下添加或修改参数：
\n- --authorization-mode=Node,RBAC # 确保包含 Node\n- --profiling=false # 关闭分析接口以减少攻击面保存退出后，等待约 30 秒，使用 kubectl get pods -n kube-system 查看 api-server 是否重启成功
\n① 身份（RBAC / authn）\n② 权限（authorization）\n③ 数据（etcd encryption）\n④ 节点（kubelet security）ectdctl 是一个命令行界面 （CLI）工具，专门用于与 etcd 数据库进行交互。
\n目前 ectd 普遍使用 v3 版本的 API ，操作前需要指定环境变量 ETCDCTL_API=3。
新版将 etcdctl 功能拆分了：
\nectdctl:用于与正在运行的 etcd 服务交互 （通过网络）etcdutl:用于处理离线文件在 kubeadm 搭建的集群中，etcd 启用了双向 TLS 认证。每次敲击 etcdctl 都需要带上一长串证书路径，非常反人类。我们先设置一个临时别名来简化操作：
## 确认 etcdctl 已安装 (如果没有，可通过 apt/yum 安装 etcd-client)\n## 设置别名，指定 API 版本为 3，并带上 kubeadm 默认的 etcd 证书路径\nalias etcdctl='ETCDCTL_API=3 etcdctl \\\n --endpoints=https://127.0.0.1:2379 \\\n --cacert=/etc/kubernetes/pki/etcd/ca.crt \\\n --cert=/etc/kubernetes/pki/etcd/server.crt \\\n --key=/etc/kubernetes/pki/etcd/server.key'验证一下： 运行 sudo etcdctl endpoint health，如果返回 is healthy，说明钥匙管用。
我们在集群里留下一些独特的痕迹，证明当前的“时间线”。
\nkubectl create namespace disaster-recovery\nkubectl run survivor-pod --image=nginx -n disaster-recovery\nkubectl get pods -n disaster-recovery\n## 确保 pod 处于 Running 状态现在，我们将当前的集群状态备份到 /opt/etcd-backup.db 文件中。
etcdctl snapshot save /opt/etcd-backup.db验证一下： 运行 etcdutl snapshot status /opt/etcd-backup.db -w table，你会看到备份文件的详细哈希和体积。
现在，假装有新手误删了整个核心业务线。
\nkubectl 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 \\\n --data-dir=/var/lib/etcd-restore执行完毕后，你可以 ls -l /var/lib/etcd-restore，会发现里面生成了新的数据文件。
在 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:\n - hostPath:\n path: /etc/kubernetes/pki/etcd\n type: DirectoryOrCreate\n name: etcd-certs\n - hostPath:\n path: /var/lib/etcd-restore # <--- 修改这里！\n type: DirectoryOrCreate\n name: etcd-data保存并退出 (:wq)。
保存退出后，kubelet 会发现 yaml 发生了变化，开始销毁旧的 etcd pod 并挂载新目录启动新的 etcd。这个过程大概需要 30 秒到 1 分钟。在这期间，你敲 kubectl 可能会卡住或报错（因为 apiserver 连不上数据库了），这是正常现象。
耐心等待一小会儿，再次输入：
\nkubectl get pods -n disaster-recovery你会发现，刚才被删除的 disaster-recovery 命名空间和里面的 survivor-pod 又奇迹般地复活了！这就标志着你的集群时光倒流成功。
常用命令：
\n数据备份：etcdctl snapshot save backup.db
查看备份文件哈希和体积： etcdutl snapshot status /opt/etcd-backup.db -w table
备份恢复到指定路径：
\netcdutl snapshot restore /opt/etcd-backup.db \\\n --data-dir=/var/lib/etcd-restore在真实的生产环境中，很多老旧系统（Legacy Systems）并不符合云原生标准。它们不会把日志输出到终端（stdout），而是死板地写进容器内的某个文件里（比如 /var/log/app.log）。这就导致 Kubernetes 原生的 kubectl logs 命令直接失效（因为它只抓取容器的 stdout）。
要在不修改老旧代码的前提下解决这个问题，K8s 给出的标准答案是：Sidecar 模式。
\nemptyDir，把它同时挂载给这两个容器。/var/log/app/sys.log）。tail -f /var/log/app/sys.log），把文件内容实时读取出来，并输出到自己的终端（stdout）。kubectl logs 去看那个 Sidecar 容器，就能完美获取老旧系统的日志了！我们将从零手写一个包含两个容器的 Pod YAML。
\n1. 编写多容器 Pod 配置文件 sidecar-pod.yaml：
\napiVersion: v1\nkind: Pod\nmetadata:\n name: legacy-app-pod\nspec:\n # 1. 声明一个共享的空目录卷\n volumes:\n - name: shared-logs\n emptyDir: {}\n\n containers:\n # 2. 这是老旧的业务主容器（它只往文件里写，不往屏幕上打）\n - name: main-app\n image: busybox\n command: [\"/bin/sh\", \"-c\", \"while true; do echo '$(date) - ERROR: legacy system failure' >> /var/log/app/sys.log; sleep 2; done\"]\n volumeMounts:\n - name: shared-logs\n mountPath: /var/log/app # 挂载到业务容器的这个路径\n\n # 3. 这是我们注入的 Sidecar 日志收集容器\n - name: log-sidecar\n image: busybox\n command: [\"/bin/sh\", \"-c\", \"tail -f /var/log/app/sys.log\"] # 实时读取文件并输出到标准输出\n volumeMounts:\n - name: shared-logs\n mountPath: /var/log/app # 必须挂载同一个卷到相同的（或不同的）路径2. 部署这个“双黄蛋” Pod：
\n\nkubectl apply -f sidecar-pod.yaml3. 观察多容器的就绪状态：
\n\nkubectl get pod legacy-app-pod -w\n\n预期现象： 注意看
\nREADY那一列。普通的 Pod 是1/1，而这个 Pod 在启动时会显示0/2，最终变成2/2。这代表里面的两个容器都已成功运行。
现在，我们来验证日志提取。
\n1. 尝试直接获取 Pod 日志（会报错）： 在单容器时代，你习惯直接敲 kubectl logs <pod-name>。但在多容器时代，这行不通了：
\nkubectl logs legacy-app-pod\n\n预期输出：
\nerror: a container name must be specified for pod legacy-app-pod...K8s 会抱怨：你这 Pod 里有两个容器，你到底要看谁的？
2. 明确指定容器名称（查看主容器）： 使用 -c 参数指定容器名。
\nkubectl logs legacy-app-pod -c main-app\n\n预期输出： 空空如也。因为老旧系统没有向终端输出任何东西。
\n
3. 见证奇迹时刻（查看 Sidecar 容器）：
\n\nkubectl logs legacy-app-pod -c log-sidecar\n\n预期输出： 你会看到屏幕上源源不断地打印出带有时间戳的
\nERROR: legacy system failure！
这就是 Sidecar 模式的魅力：解耦。业务容器专心跑业务，日志容器专心搬运日志，互不干扰，却完美协同。
\n\nkubectl delete pod legacy-app-pod给定一个翻译任务：将 I love you baby 翻译为中文。
\n先把每一个词转换成对应的 词向量，考虑按照下面方式处理：
![\"\"](\"/wp-uploads/2026/03/1774354614-image-1024x450.png\")
上面两个方法都有缺陷，可以考虑按照下面的方法处理：
\n词向量加上各自的 位置编码（表示该词出现在整个句子中的位置），现在这个词向量就具备了位置信息![\"\"](\"/wp-uploads/2026/03/1774354656-image-1024x366.png\")
权重矩阵 W_q 与第一个词向量相乘(MatMul)，得到维度不变的 q_1 矩阵。同理，用 W_k,W_v 矩阵处理得到 k_1,v_1。同理，得到 q_1,2,3,4,k_1,2,3,4,v_1,2,3,4。\n![\"\"](\"/wp-uploads/2026/03/1774355126-image-1024x607.png\")
![\"\"](\"/wp-uploads/2026/03/1774355131-image-1024x607.png\")
![\"\"](\"/wp-uploads/2026/03/1774355170-image-1024x731.png\")
内积 得到 a_12，表示在第一个词的视角下，与第二个词的 相似度系数。同理，得到 a_11,a_12,a_13,a_14。![\"\"](\"/wp-uploads/2026/03/1774355272-image-1024x490.png\")
![\"\"](\"/wp-uploads/2026/03/1774355339-image-1024x296.png\")
![\"\"](\"/wp-uploads/2026/03/1774355350-image-1024x696.png\")
注意力机制 Attention 的原理![\"\"](\"/wp-uploads/2026/03/1774355506-image-1024x653.png\")
对于注意力机制而言，通过一种方式计算一次相关性，那么灵活性会大大降低。
\n权重矩阵 W 变成两组 q_i,k_i,v_i，相当于给每个词向量两次学习机会，学习到不同的待计算相似度的 $q_{ij}, k_{ij}, v_{ij} $（头部 head）来增加语言的灵活性。![\"\"](\"/wp-uploads/2026/03/1774355598-image-1024x622.png\")
head 经过注意力层的计算，得到 a_ij 向量，再把两个 a_ij 向量拼接起来，得到和原词向量相同维度的新词向量。这种方式也即 多头注意力机制机制 Multi-Head Attention。![\"\"](\"/wp-uploads/2026/03/1774355635-image-1024x502.png\")
![\"\"](\"/wp-uploads/2026/03/1774355638-image-1024x642.png\")
词嵌入 Word Embedding 的方式转换为向量矩阵![\"\"](\"/wp-uploads/2026/03/1774355930-image-1024x710.png\")
![\"\"](\"/wp-uploads/2026/03/1774355902-image-1024x618.png\")
Add & Norm 是优化步骤。表示 残差网络 和 归一化，是为了解决梯度消失问题、让分布更加稳定。![\"\"](\"/wp-uploads/2026/03/1774355939-image-1024x636.png\")
相似度系数 的矩阵，再和 v 相乘，得到包含上下文信息的词向量矩阵\nAttention(Q,K,V)=softmax(QKTdk)VAttention(Q,K,V)=softmax(\\fracQK{\\sqrt{d_k}})V
\n![\"\"](\"/wp-uploads/2026/03/1774355952-image.png\")
线性变换 Linear（矩阵乘法）拆分成多组（相当于给了多次机会学习到不同的相似度关系），依次经过 单头注意力机制 运算后，把运算结果拼接 Concat 起来。最后再用权重矩阵 WO 进行线性变换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_i &= \\textAttention}(Q W\\_i
\n![\"\"](\"/wp-uploads/2026/03/1774356093-image.png\")
![\"\"](\"/wp-uploads/2026/03/1774356122-image-670x1024.png\")
用原来的翻译任务为例：
\n编码器：
\nK, V）解码器：
\n掩码后的多头注意力、残差和归一化，送入多头注意力的一个输入中（作为 Q）K,V,Q 进行多头注意力，再残差和归一化\n\nMasked Attention
\n\n
\n- 作用：屏蔽未来位置信息，保证解码器只能基于已生成的前缀序列预测下一个词
\n- Transformer 解码器是自回归生成模型：每一步的输出都依赖于之前所有的输出
\n- 掩码是一个上三角矩阵，未来位置的注意力权重置为 −∞（或极小值）
\n
参考链接：Transformer 其实是个简单到令人困惑的模型【AI入门06】_哔哩哔哩_bilibili
\n长短期记忆（Long Short-Term Memory，LSTM） 是 RNN 最重要的变体，也是深度学习 NLP 发展史上的里程碑。在 Transformer 出现之前（2017 年），LSTM 是序列建模的绝对王者。
\n\n句子："我住在法国，...（中间 200 个字）... 所以我会说___"
\n
\n空格应该填 “法语”
RNN 的问题：
\n需要记住 200 个字前的"法国"。反向传播 时，梯度要连乘 200 次，导致前面的信息传不过来。
\n如果每次乘 0.9 → 0.9^200 ≈ 0.000000001 → 梯度消失
![\"\"](\"/wp-uploads/2026/03/1774353528-image-1024x403.png\")
![\"\"](\"/wp-uploads/2026/03/1774353542-image.png\")
LSTM 与 RNN 的接口的不同之处在于，LSTM 还有路径 c。这个 c 称为 记忆单元（或者简称为“单元”），相当于 LSTM 专用的记忆部门。
sigmoid函数用于求门的开合程度（sigmoid函数的输出范围在0.0 ~ 1.0）隐藏状态 h_t=o_t⊙tanh(c_t)，记忆单元 c_t 和隐藏状态 h_t 的关系只是按元素应用 tanh 函数。这意味着，记忆单元 c_t 和隐藏状态 h_t 的_元素个数相同_。
\n\n⊙ 表示
\n阿达玛乘积。即，对应元素的乘积
![\"\"](\"/wp-uploads/2026/03/1774353784-image-1024x712.png\")
向记忆单元添加的新信息 ：hatc_t=tanhleft(x_tW_x(g)+h_t−1W_h(g)+b(g)right)
\n新的记忆单元： c_t=f⊙c_t−1+i⊙hatc_t，细胞状态 = 遗忘 × 旧细胞 + 输入 × 新候选
hatc_t 也即上面的 g
\n这个 tanh 节点的作用不是门，而是将新的信息添加到记忆单元中。因此，它不用 sigmoid 函数 作为激活函数，而是使用 tanh 函数。
观察记忆单元的反向传播：
\n![\"\"](\"/wp-uploads/2026/03/1774353862-image-1024x298.png\")
记忆单元的反向传播仅流过 + 和 × 节点。
+ 节点 将上游传来的梯度原样流出，所以梯度没有变化（退化）× 节点 的计算并不是矩阵乘积，而是对应元素的乘积（阿达玛积）基础 LSTM：
\nimport torch
\nimport torch.nn as nn
class SimpleLSTM(nn.Module):
\ndef __init__(self, input_size, hidden_size, num_layers, num_classes):
\nsuper().__init__()
\nself.hidden_size = hidden_size
\nself.num_layers = num_layers
# LSTM 层\n self.lstm = nn.LSTM(input\\_size, hidden\\_size, \n num\\_layers=num\\_layers,\n batch\\_first=True,\n dropout=0.3) # 层间 Dropout\n \n # 全连接层\n self.fc = nn.Linear(hidden\\_size, num\\_classes)\n\ndef forward(self, x):\n # x: (batch\\_size, seq\\_len, input\\_size)\n \n # 初始化隐藏状态\n h0 = torch.zeros(self.num\\_layers, x.size(0), self.hidden\\_size)\n c0 = torch.zeros(self.num\\_layers, x.size(0), self.hidden\\_size)\n \n # 前向传播\n out, (hn, cn) = self.lstm(x, (h0, c0))\n # out: (batch, seq\\_len, hidden\\_size)\n # hn: (num\\_layers, batch, hidden\\_size)\n \n # 取最后一个时间步的输出\n out = self.fc(out\\[:, -1, :\\])\n return out\nmodel = SimpleLSTM(input_size=100, hidden_size=128,
\nnum_layers=2, num_classes=2)
IMDB 情感分析:
\nimport torch.optim as optim
\nbatch_size = 64
\nseq_len = 100
\nlearning_rate = 0.001
\nepochs = 10
model = SentimentBiLSTM(vocab_size=10000, embed_dim=300,
\nhidden_size=128, num_classes=2)
\ncriterion = nn.CrossEntropyLoss()
\noptimizer = optim.Adam(model.parameters(), lr=learning_rate)
for epoch in range(epochs):
\nmodel.train()
\ntotal_loss = 0
for batch\\_x, batch\\_y in train\\_loader:\n # batch\\_x: (64, 100), batch\\_y: (64,)\n \n optimizer.zero\\_grad()\n output = model(batch\\_x)\n loss = criterion(output, batch\\_y)\n loss.backward()\n \n # 梯度裁剪（防止 LSTM 梯度爆炸）⭐\n torch.nn.utils.clip\\_grad\\_norm\\_(model.parameters(), 1.0)\n \n optimizer.step()\n total\\_loss += loss.item()\n\n# 验证\nmodel.eval()\ncorrect = 0\ntotal = 0\nwith torch.no\\_grad():\n for batch\\_x, batch\\_y in val\\_loader:\n output = model(batch\\_x)\n predicted = torch.argmax(output, dim=1)\n correct += (predicted == batch\\_y).sum().item()\n total += batch\\_y.size(0)\n\nval\\_acc = correct / total\nprint(f"Epoch {epoch+1}: Loss={total\\_loss:.4f}, Val Acc={val\\_acc:.4f}")\n需求：输入一句话，输出每个单词的褒贬性
\n![\"\"](\"/wp-uploads/2026/03/1774352814-image-1024x509.png\")
假设对于上面 5 个单词，每个单词采用 300 维的 词向量，那么输入端就需要 1500 个词向量，这会带来几个缺点：
为了解决上述缺点，可以让上一步的信息参与下一步的运算，具体可以这样做：
\n![\"\"](\"/wp-uploads/2026/03/1774352850-image-1024x521.png\")
![\"\"](\"/wp-uploads/2026/03/1774352856-image.png\")
第一个词 X<1> 经过非线性变换 g(cdot) 后得到一个中间结果(隐藏状态) h<1> ，它再经过一次非线性变换得到第一个输出 Y<1>
接着，第二个词 X<2> 与刚才的隐藏状态 h<1> 一起参与非线性变换，得到隐藏状态 h<2> ，它再经过一次非线性变换得到 Y<2>
\ng(cdot)：激活函数，一般取双曲正切 tanh
\nW_xh：专门针对词向量的矩阵
\nW_hh：专门针对隐藏状态的矩阵
\nW_hy：专门针对输出结果的矩阵
\nb：偏置项 bias
\n上图流程可以简化为下面两种等效表达方式：
\n![\"\"](\"/wp-uploads/2026/03/1774352905-image-1024x507.png\")
![\"\"](\"/wp-uploads/2026/03/1774352921-image-1024x377.png\")
\n\n\n
![\"\"](\"/wp-uploads/2026/03/1774352959-image.png\")
反向传播时，梯度需要从后往前传：
\n∂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}
\n0.5^100 ≈ 0 → 梯度消失 → 前面的权重几乎不更新 → 模型记不住长距离信息1.5^100 ≈ 亿 → 梯度爆炸 → 权重变成 NaN → 模型训练崩溃解决方案：
\n原始的 RNN 几乎已被淘汰
方法
\n说明
\n梯度裁剪
\n限制梯度最大值（如 1.0）
\nReLU 激活
\n缓解梯度消失（但 RNN 常用 tanh）
\nLSTM/GRU
\n最有效的方案 ⭐ LSTM 和 GRU 中增加了一种名为“门”的结构
\n\n\nGated RNN
\n在 RNN 的学习中，
\n梯度消失也是一个大问题。为了解决这个问题，需要从根本上改变 RNN 层的结构。人们已经提出了诸多 Gated RNN 框架，其中具有代表性的有 LSTM 和GRU
基础 RNN：
\nimport torch
\nimport torch.nn as nn
class SimpleRNN(nn.Module):
\ndef __init__(self, input_size, hidden_size, num_classes):
\nsuper().__init__()
\nself.rnn = nn.RNN(input_size, hidden_size, batch_first=True)
\nself.fc = nn.Linear(hidden_size, num_classes)
def forward(self, x):\n # x: (batch, seq\\_len, input\\_size)\n out, hidden = self.rnn(x) # out: (batch, seq\\_len, hidden)\n # 取最后一个时间步\n out = self.fc(hidden\\[-1\\])\n return out\nmodel = SimpleRNN(input_size=100, hidden_size=128, num_classes=2)
\n用上面的 model，结合 IMDB 数据集进行情感分析：
# 超参数
\nbatch_size = 64
\nseq_len = 100
\nlearning_rate = 0.001
criterion = nn.CrossEntropyLoss()
\noptimizer = torch.optim.Adam(model.parameters(), lr=learning_rate)
for epoch in range(10):
\nmodel.train()
\nfor batch_x, batch_y in train_loader:
\noptimizer.zero_grad()
\noutput = model(batch_x)
\nloss = criterion(output, batch_y)
\nloss.backward()
# 梯度裁剪（防止 RNN 梯度爆炸）⭐\n torch.nn.utils.clip\\_grad\\_norm\\_(model.parameters(), 1.0)\n \n optimizer.step()\n\n# 验证\nmodel.eval()\nval\\_acc = evaluate(model, val\\_loader)\nprint(f"Epoch {epoch}: Val Acc = {val\\_acc:.4f}")\nWord2Vec 其实就是一个没有隐藏层激活函数的 2 层神经网络（浅层神经网络），用来将单词映射为低维稠密向量。
基于分布假设。通过大量文本语料学习词语的共现规律，将语义相似的词映射到向量空间中彼此靠近的位置
\n\n\n分布假设
\n"A word is characterized by the company it keeps."
\n（一个词是由它周围的词决定的。）
\n
Word2Vec 包含两种浅层神经网络结构，核心目标是学习词向量，输入层到隐藏层为词嵌入映射，隐藏层到输出层为概率预测。
![\"\"](\"/wp-uploads/2026/03/1774352468-image.png\")
![\"\"](\"/wp-uploads/2026/03/1774352492-image-1024x672.png\")
![\"\"](\"/wp-uploads/2026/03/1774352527-image-1024x805.png\")
\n\n💡 经验：默认首选
\nSkip-Gram，除非数据量极大且追求速度。
为解决大规模语料下的计算瓶颈，Word2Vec 引入两大核心优化，大幅提升训练效率。
训练完成后：
\n这个 V×N 的矩阵，每一行就是一个词的向量
\nHuffman树 组织词汇表，将根节点到叶节点的 路径概率乘积 作为预测结果，类似于二叉搜索O (V) 降至 O (logV)，V 为词汇量，适合超大词汇表安装依赖库：pip install gensim nltk
import gensim
\nfrom gensim.models import Word2Vec
\nfrom gensim.utils import simple_preprocess
\nimport nltk
\nfrom nltk.corpus import stopwords
nltk.download('stopwords')
\nstop_words = stopwords.words('english')
corpus = [
\n"Natural language processing is a subfield of artificial intelligence",
\n"Word2Vec is a popular technique for word embedding in NLP",
\n"Word embedding converts words into numerical vectors",
\n"Semantic similarity can be measured using word vectors",
\n"King minus man plus woman equals queen in word2vec",
\n"Tokyo is the capital of Japan, Beijing is the capital of China",
\n"Machine learning models use word vectors as input features",
\n"Cat likes eating fish and dog loves enjoying bones"
\n]
def preprocess(text):
\n# 分词（gensim内置的简单分词，适合英文）
\ntokens = simple_preprocess(text, deacc=True) # deacc=True去除标点
\n# 过滤停用词和长度<2的词
\ntokens = [token for token in tokens if token not in stop_words and len(token) > 2]
\nreturn tokens
processed_corpus = [preprocess(sentence) for sentence in corpus]
\nprint("预处理后的语料：")
\nfor sent in processed_corpus:
\nprint(sent)
model = Word2Vec(
\nsentences=processed_corpus,
\nvector_size=50, # 词向量维度
\nwindow=3, # 上下文窗口
\nmin_count=1, # 保留所有出现过的词（小语料专用）
\nsg=1, # 使用Skip-gram模型（对小语料更友好）
\nworkers=4, # 4线程训练
\nepochs=100 # 训练轮数（小语料需增加轮数保证效果）
\n)
model.save("word2vec_demo.model")
\nprint("\\n=== 查看'plus'的词向量（前10维）===")
\nprint(model.wv['plus'][:10]) # wv是word vector的缩写，存储所有词向量量
print("\\n=== 计算语义相似度 ===")
\nprint(f"like vs love: {model.wv.similarity('like', 'love'):.4f}")
\nprint(f"beijing vs tokyo: {model.wv.similarity('beijing', 'tokyo'):.4f}")
\nprint(f"king vs queen: {model.wv.similarity('king', 'queen'):.4f}")
\nprint(f"china vs japan: {model.wv.similarity('china', 'japan'):.4f}")
print("\\n=== 找与'like'最相似的5个词 ===")
\nsimilar_words = model.wv.most_similar('like', topn=5)
\nfor word, score in similar_words:
\nprint(f"{word}: {score:.4f}")
print("\\n=== 语义类比：king - man + woman == ? ===")
\ntry:
\nanalogy = model.wv.most_similar(positive=['king', 'woman'], negative=['man'], topn=1)
\nprint(f"结果：{analogy[0][0]} (相似度：{analogy[0][1]:.4f})")
\nexcept KeyError as e:
\nprint(f"类比失败：缺少词 {e}（语料太小导致）")
参数调整：
\nvector_size调至 100/300，min_count调至 5/10（过滤低频词），epochs调至 10-20；min_count=1，增加 epochs（如 100）保证训练效果。如果结果奇怪：
\n根本原因：语料库太小了
\n直接用别人训练好的模型，不要自己训练小语料：
from gensim.models import KeyedVectors
\nmodel = KeyedVectors.load_word2vec_format('GoogleNews-vectors-negative300.bin', binary=True)
\nprint(model.wv.similarity('like', 'love')) # 应该 > 0.5
\nprint(model.wv.similarity('king', 'queen')) # 应该 > 0.6
result = model.wv.most_similar(positive=['king', 'woman'], negative=['man'])
\nprint(result[0][0]) # 应该输出 'queen'
核心问题：神经网络只能处理数字，但人类语言是文字。
\n如下，怎么把"我"、"喜欢"、"深度"、"学习"变成向量？
\n\n人类： "我喜欢深度学习"
\n
\n↓ ???
\n计算机： [?, ?, ?, ?, ?, ?]
方法：每个词用一个超长向量表示，只有一个位置是 1，其他都是 0。
\n词典：["我", "喜欢", "讨厌", "深度", "学习", "电影", ...] 假设共 10000 词
\n"我" → [1, 0, 0, 0, 0, 0, ..., 0] (第 1 位是 1)
\n"喜欢" → [0, 1, 0, 0, 0, 0, ..., 0] (第 2 位是 1)
\n"讨厌" → [0, 0, 1, 0, 0, 0, ..., 0] (第 3 位是 1)
\n"学习" → [0, 0, 0, 0, 1, 0, ..., 0] (第 5 位是 1)
优点
\n缺点
\n简单直观
\n维度灾难：词典 10 万词 = 10 万维向量
\n容易实现
\n语义鸿沟：任意两个词向量正交（内积=0）
\n无法表示相似性："喜欢"和"讨厌"距离一样远（如下例）
\n向量空间示意（One-Hot）：
\n"喜欢" ● 所有词都在坐标轴上
\n│ 彼此距离相等
\n│
\n●──────┼──────● "讨厌"
\n"me" │ "学习"
\n│
\n●
\n"电影"
问题：无法表达"喜欢"和"爱"更接近 ❌
\n核心思想（Hinton, 1986）：用低维稠密向量表示单词，语义相似的词向量也相似。
\n词典：10000 词 → 向量维度：300
\n"我" → [0.25, -0.31, 0.67, ..., 0.12] (300 维稠密向量)
\n"喜欢" → [0.82, -0.45, 0.33, ..., 0.56]
\n"爱" → [0.79, -0.42, 0.35, ..., 0.54] ← 和"喜欢"很接近！
\n"讨厌" → [-0.75, 0.51, -0.28, ..., -0.61] ← 和"喜欢"距离远
\n"学习" → [0.45, -0.12, 0.78, ..., 0.33]
向量空间示意（分布式表示）：
\n "爱" ●\n ╱\n ╱ ← 语义相近，向量距离近 ✅\n ╱\n"喜欢" ●───────● "热爱"
\n╲
\n╲
\n╲
\n● "讨厌" ← 语义相反，距离远
"学习" ● ● "电影" ← 无关词，距离中等
\n\n\n为什么叫"分布式"？
\n\n
\n- One-Hot：信息集中在一个位置（向量中只有 1 个 1，其余都是 0）
\n- 分布式：信息分布在整个向量的所有维度
\n
可以用两个词向量之间的 内积 或 余弦相似度 来表示向量之间的相关性
![\"\"](\"/wp-uploads/2026/03/1774350936-image-1024x588.png\")
嵌入矩阵：每一列都是一个词向量。word2vec 等方式训练获得![\"\"](\"/wp-uploads/2026/03/1774350962-image-1024x605.png\")
潜空间。对于高维潜空间，可以通过降维投影等操作直观感受，参考： https://projector.tensorflow.org/ 。模型
\n输入
\n输出
\n比喻
\nSkip-Gram 跳元模型（常用）
\n中心词
上下文词
"给定这个词，预测周围"
\nCBOW 连续词袋
\n上下文词
中心词
"猜中间是什么词"
\nCBOW: ["我", "深度", "学习"] → "喜欢"
\n(上下文) (中心词)
Skip-Gram: "喜欢" → ["我", "深度", "学习"]
\n(中心词) (上下文)
Word2Vec 的架构：
\n 输入层 隐藏层 输出层\n (词索引) (词向量) (概率分布)\n \n ● ● ● ● ● ●\n │ │ │ │ │ │\n │ │ │ │ │ │\n输入词索引 → 查找向量表 → Softmax → 预测词\n(one-hot) (V×N 矩阵) (V 维)\n\nV = 词典大小 (如 10000)\nN = 向量维度 (如 300)\n\n\n💡 关键：训练完成后，隐藏层的权重矩阵就是
\n词向量表！
GloVe 目标：让上面 共现矩阵（co-occurence matrix）向量内积 ≈ log(共现次数)优点
\n缺点
\n能处理未登录词（OOV）
向量维度更大
\n适合形态丰富的语言（如德语、俄语）
\n计算稍慢
\n中文效果提升有限
\n方法
\n特点
\nWord2Vec
一个词只有一个向量
\nGloVe
不管上下文
\nFastText
考虑子词，但仍静态
\n"苹果"在以下句子中意思不同，但向量相同 ❌
\nWord2Vec: "苹果" → [0.5, -0.3, 0.8, ...] (固定不变)
\n方法
\n特点
\nELMo (2018)
\n用双向 LSTM，上下文相关
BERT (2018)
\n用 Transformer，上下文相关 ⭐
GPT 系列
\n自回归，上下文相关
\nBERT:
\n"我吃了一个苹果" → "苹果" → [0.6, -0.2, 0.9, ...] (水果义)
\n"我买了苹果股票" → "苹果" → [0.8, -0.5, 0.4, ...] (公司义)
同一个词，不同上下文，向量不同 ✅
\n自然语言处理（Natural Language Processing，NLP） = 让计算机理解、生成、处理人类语言的技术。NLP 的核心任务著有可以分为 3 类：理解类、生成类、其他类。
HMM、CRF、SVM 等统计模型RNN、LSTM、GRU、CNNBERT（2018）、GPT 系列、T5把句子切成模型能处理的"单元"
\n英文："I love NLP" → ["I", "love", "NLP"]
\n中文："我爱 NLP" → ["我", "爱", "NLP"]
更细粒度（Subword）：
\n"playing" → ["play", "##ing"]
\n"不喜欢" → ["不", "喜欢"]
空格分词
\n英文适用，中文不行
\n字符级
\n每个字独立，序列太长
\n词级
\n需要词典，未登录词问题
\nSubword
\nBPE、WordPiece，平衡粒度和词汇量 ⭐
\n把单词变成稠密向量，保留语义信息
\n"国王" → [0.85, -0.32, 0.67, ...]
\n"王后" → [0.83, -0.30, 0.69, ...]
\n"男人" → [0.75, -0.45, 0.55, ...]
\n"女人" → [0.73, -0.43, 0.57, ...]
向量运算："国王" - "男人" + "女人" ≈ "王后" ✅
\nOne-Hot
\n早期
\n稀疏，无语义关系
\nWord2Vec
\n2013
\n稠密，有语义，静态 ⭐
\nGloVe
\n2014
\n基于全局共现统计
\nFastText
\n2016
\n支持子词，处理未登录词
\nBERT Embedding
\n2018
\n上下文相关，动态 ⭐⭐⭐
\n让模型学会"关注重要的部分"
\n翻译："The animal didn't cross the street because it was too tired"
\n↓
\n"it" 指的是谁？
\n↓
\n注意力指向 "animal" ✅
自注意力（Self-Attention）：
\nRNN 快得多现代 NLP 的标准范式：
\n第 1 步：预训练
\n用海量无标签文本（维基百科、网页）训练通用语言模型
\n学习：语法、语义、常识、推理...
\n↓
\n第 2 步：微调
\n用少量有标签数据（如情感分析数据）训练特定任务
\n学习：分类边界、任务特定模式
\n\n💡 类比：预训练 = 读万卷书（通识教育），微调 = 专业训练（职业技能）
\n
NetworkPolicy = Kubernetes 里 Pod 级别的网络防火墙，它基于标签选择器定义允许的入站（Ingress）和出站（Egress）流量，默认遵循“白名单”原则：一旦某个 Pod 被任何 NetworkPolicy 选中，未明确允许的流量都会被拒绝。
\n实验要求：
\nfrontend 和 backend namespaces 中的 frontend 和 backend Deployment 之间的通信。\nfrontend 和 backend Deployment，以确定需要应用的 NetworkPolicy 的具体要求。~/netpol 文件夹中的 NetworkPolicy YAML 示例。\n参考链接：无
\n难度：⭐⭐
题干要求：“不过于宽松”，即最小权限原则
\n![\"\"](\"/wp-uploads/2026/03/1773471099-image.png\")
查看`~/netpol`目录，发现存在 3 个文件，内容如下：
\n\napiVersion: networking.k8s.io/v1\nkind: NetworkPolicy\nmetadata:\n name: netpol-1\n namespace: backend\nspec:\n podSelector: {}\n policyTypes:\n - Ingress\n ingress:\n - from:\n - namespaceSelector:\n matchLabels:\n kubernetes.io/metadata.name: frontend第 7 行，⚠️ 会选择 backend 命名空间 ALL Pods
\n\napiVersion: networking.k8s.io/v1\nkind: NetworkPolicy\nmetadata:\n name: netpol-2\n namespace: backend\nspec:\n podSelector:\n matchLabels:\n app: backend\n policyTypes:\n - Ingress\n ingress:\n - from:\n - namespaceSelector:\n matchLabels:\n kubernetes.io/metadata.name: frontend\n podSelector:\n matchLabels:\n app: frontend\napiVersion: networking.k8s.io/v1\nkind: NetworkPolicy\nmetadata:\n name: netpol-3\n namespace: backend\nspec:\n podSelector:\n matchLabels:\n app: database\n policyTypes:\n - Ingress\n ingress:\n - from:\n - namespaceSelector:\n matchLabels:\n kubernetes.io/metadata.name: frontend\n podSelector:\n matchLabels:\n app: frontend\n - ipBlock:\n cidr: 10.0.0.0/24![\"\"](\"/wp-uploads/2026/03/1773471298-image.png\")
![\"\"](\"/wp-uploads/2026/03/1773471312-image.png\")
netpol2.yaml 中配置的 NetworkPolicy 位于命名空间 backend
K8s Gateway 是官方新一代流量入口标准（Gateway API），用来替代 / 升级传统 Ingress，专门管理外部流量进入 Kubernetes 集群的南北向流量。
\nGateway = 更强大、更规范、云原生的下一代 Ingress
\n实验要求：
\nweb-gateway 的 Gateway ，主机名为 gateway.web.k8s.local ，并保持现有名为 web 的 Ingress 资源的现有 TLS 和侦听器配置。web-route 的 HTTPRoute ，主机名为 gateway.web.k8s.local ，并保持现有名为 web 的 Ingress 资源的现有路由规则。\nweb 的现有 Ingress 资源。参考链接： https://kubernetes.io/docs/concepts/services-networking/gateway/
\n难度：⭐⭐⭐
![\"\"](\"/wp-uploads/2026/03/1773469142-image.png\")
kubectl get ingress web -o yaml：
Gateway 时需要： 查看 spec.tls.secretNameHTTPRoute 时需要：查看 spec.rules.http.paths.backend 和 spec.rules.http.paths.path![\"\"](\"/wp-uploads/2026/03/1773469169-image.png\")
![\"\"](\"/wp-uploads/2026/03/1773469195-image.png\")
![\"\"](\"/wp-uploads/2026/03/1773469239-image.png\")
![\"\"](\"/wp-uploads/2026/03/1773469270-image.png\")
Gateway 和 HTTPRoute 是 Kubernetes Gateway API 的两个核心资源，共同替代传统的 Ingress 实现更灵活的流量管理。
监听器（端口、协议、主机名）和 TLS 配置，由平台团队管理；路由规则（路径匹配、权重分发、后端服务），由应用团队管理。两者通过 parentRefs 关联，实现职责分离。![\"\"](\"/wp-uploads/2026/03/1773469306-image.png\")
Gateway 和 HTTPRoute
\n![\"\"](\"/wp-uploads/2026/03/1773469873-image.png\")
Ingress
\n关系
\n说明
\nIngress
第一代流量入口资源（已成熟，但功能有限）
\nGateway
第二代流量入口的基础设施层（监听器+TLS）
\nHTTPRoute
第二代流量入口的应用层（路由规则）
\nGateway + HTTPRoute
替代 Ingress 的新标准
\nIngress 配置（全部在一起）:
\n\napiVersion: networking.k8s.io/v1\nkind: Ingress\nmetadata:\n name: web-ingress\nspec:\n # ⚠️ TLS 配置在这里\n tls:\n - hosts:\n - example.com\n secretName: tls-secret\n\n # ⚠️ 路由规则也在这里\n rules:\n - host: example.com\n http:\n paths:\n - path: /\n pathType: Prefix\n backend:\n service:\n name: web-service\n port:\n number: 80Gateway + HTTPRoute 配置（职责分离）:
\n\n## ===== Gateway（基础设施团队管理）=====\napiVersion: gateway.networking.k8s.io/v1\nkind: Gateway\nmetadata:\n name: web-gateway\nspec:\n gatewayClassName: nginx\n listeners:\n - name: https\n protocol: HTTPS\n port: 443\n hostname: example.com\n # ⚠️ TLS 配置在这里\n tls:\n mode: Terminate\n certificateRefs:\n - kind: Secret\n name: tls-secret\n\n---\n## ===== HTTPRoute（应用团队管理）=====\napiVersion: gateway.networking.k8s.io/v1\nkind: HTTPRoute\nmetadata:\n name: web-route\nspec:\n # ⚠️ 引用 Gateway\n parentRefs:\n - name: web-gateway\n kind: Gateway\n\n hostnames:\n - example.com\n\n # ⚠️ 路由规则在这里\n rules:\n - matches:\n - path:\n type: PathPrefix\n value: /\n backendRefs:\n - name: web-service\n kind: Service\n port:\n number: 80功能
\nIngress
\nGateway + HTTPRoute
\nHTTP 路由
\n✅ 支持
\n✅ 支持
\nHTTPS/TLS
\n✅ 支持
\n✅ 支持（更灵活）
\n路径匹配
\n✅ 前缀/精确
\n✅ 前缀/精确/正则
\n主机名匹配
\n✅ 支持
\n✅ 支持
\n多监听器
\n❌ 有限
\n✅ 原生支持
\nTCP/UDP
\n❌ 不支持
\n✅ 支持 (TCPRoute/UDPRoute)
\ngRPC
\n❌ 不支持
\n✅ 支持 (GRPCRoute)
\n流量拆分
\n❌ 困难
\n✅ 原生支持
\n跨命名空间
\n❌ 困难
\n✅ 原生支持
\n角色分离
\n❌ 混合
\n✅ 清晰分离
\nAPI 成熟度
\n✅ GA
\n✅ GA (v1)
\n