3.8k字3 分钟

# 核心心智模型：API 边界 vs 宿主机内核边界 在一个运行的容器（Pod）中，它的“权限”被严格划分为两个完全不同的维度： ServiceAccount (服务账号) —— 突破 Kubernetes API 边界 技术本质： 它是与 kube-apiserver 通信的凭证（JWT Token）。 作用域： 决定了容器内的进程是否能调用 K8s API 去操作集群资源（比如：读取 Secret、删除 Pod、查看 Node）。它完全不关心容器在 Linux 系统层面的权限。 SecurityContext (安全上下文) —— 限制 Linux 宿主机内核边界 技术本质： 它
2.9k字3 分钟

在 CKA 考试中，排错通常分为两大类：节点级故障（Node NotReady）和工作负载级故障（Pod Crash/Pending）。 # 核心排错心智模型：自上而下的漏斗排查法 遇到任何故障，考场上千万不要像没头苍蝇一样乱敲，牢记这个四步排查漏斗： 看宏观状态： kubectl get nodes / kubectl get pods -o wide （谁出事了？在哪出事的？） 看资源事件： kubectl describe <resource> <name> （翻到底部的 Events，K8s 会直接告诉你哪里卡住了） 看容器日志： kube
7k字6 分钟

# 核心心智模型：Ingress 的技术架构 Pod (工作负载)：实际处理业务请求的容器，拥有动态分配的内部 IP。 Service (ClusterIP)：内部的四层负载均衡器。它提供一个固定的内部虚拟 IP，并将流量轮询转发给后端的 Pod 集合。外部网络无法直接路由到 ClusterIP。 Ingress Controller (反向代理网关)：本质上是一个运行在集群内的守护进程 Pod（通常基于 Nginx、Envoy 或 Traefik）。它通过 NodePort 或 LoadBalancer 的方式将自己暴露给集群外部，负责接收所有外部的 HTTP/HTTP
3.2k字3 分钟

# 核心心智模型 1.PV (PersistentVolume - 持久卷) = 墙上的插座 角色： 由**集群管理员（Admin）**提前建好。 本质： 它是真实的底层存储资源（比如一块 50G 的 NFS 网络硬盘，或云上的 EBS 盘）。插座建好后，它就在那里，里面有电，等待被使用。 2.PVC (PersistentVolumeClaim - 持久卷声明) = 电器的插头 角色： 由**开发人员（Developer/User）**提出申请。 本质： 它是对存储的“需求清单”。比如声明：“我需要一个 10G 容量、能读能写的插座”。 3.Bindin
2.6k字2 分钟

NetworkPolicy 必须依赖底层网络插件（CNI）的支持。比如 Flannel 就不支持网络策略。 这里集群使用的网络插件是 Calico ，支持 NetworkPolicy。 Kubernetes 网络“白名单“机制： 在没有任何 NetworkPolicy 情况下，集群内部网络默认全通（Default Allow)。任何 Pod 都能随意访问其他 Pod。 一旦创建 NetworkPolicy，并且通过 PodSelector 选中某个 Pod，这个 Pod 的网络就会立刻变成默认拒绝，只有在 Policy 中明确写明允许的流量（白名单）才能进出。 # 实验目的 创建一个模拟数
4.6k字4 分钟

卷积神经网络（Convolutional Neural Network），是深度学习里专门处理图像、视频、语音等 “网格型数据”的神经网络。 # 背景：MLP 不适用于图像处理 假设你有一张 28×28 的黑白手写数字图片，如 MNIST 数据集。 # 1️⃣ MLP 的做法：拉平 图片 (28×28) → 拉成向量 (784 个数字) → 输入全连接层 问题： 丢失空间信息：像素之间的上下左右关系没了。 参数爆炸：如果图片是 224×224×3 (RGB)，输入就是 150,528 维。第一层如果有 1000 个神经元，光权重就有 1.5 亿个，显存直接爆掉。 无法识别位置变化：
2k字2 分钟

本实验分为四个阶段：快速创建、弹性伸缩、滚动更新、故障回滚。 # 阶段一：快速拉起 在考试中，除非题目明确要求创建 Pod ，否则一律优先使用 Deployment，因为它具备自愈金额扩缩容能力。 1、快速创建一个 Pod（仅用于临时测试） kubectl run nginx-pod --image=inginx:1.23 --labels="app=test" 2、快速创建一个 Deployment（标准做法） ## 创建一个 Deployment 的部署，包含 3 个副本。 kubectl create deployment web-de
3.3k字3 分钟

# 实验前置：清理与打标签 ## 清理之前的 Pod kubectl delete pods -all ## 给 node1 打上磁盘类型标签 （SSD） kubectl label nodes node1 disk=ssd ## 给 node2 打上磁盘区域标签 （Zone Top） kubectl label nodes node2 zone=top # 实验一：NodeSelector 与 NodeAffinity （定向调度） 目标：让 Pod 必须运行在 node1（SSD 节点），并优先选择 node2（但因为 node1 是硬性条件，最终会留在 node1
2.6k字2 分钟

# 实验目标 创建一个名为 cluster-manager-sa 的服务账号，赋予它： 集群级权限：可以查看（get/list）集群中所有的 Nodes（节点）。 全空间权限：可以查看 所有命名空间 下的 Deployments。 # 实验过程大纲 创建服务账号 创建 ClusterRole 和 ClusterRoleBinding 验证权限 # 实验过程 # 阶段一：创建服务账号 我们统一把这个账号放在 kube-system 命名空间下（模拟系统级管理账号）。 kubectl create serviceaccount cluster-manager-sa -n kube
4.7k字4 分钟

RBAC 是 Kubernetes 安全性的基石。考试中这类题目的逻辑非常固定，通常是：“创建一个用户/账号 -> 赋予他某些权限 -> 验证他是否真的有了这些权限”。 # 实验目标 创建一个名为 pod-reader-sa 的服务账号（ServiceAccount），只允许它在 development 命名空间内查看（get/list/watch） Pod，禁止它进行删除或对其他资源的操作。 # 实验过程大纲 阶段一：创建 namespace和 ServiceAccount 阶段二：创建 Role 和 RoleBinding 阶段三：验证权限 # 实