[{"content":"k8s故障场景 1.亲和性规则冲突 1.排查问题 kubectl describe pods 2.查看evtens字段 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 103s default-scheduler 0/3 nodes are available: 1 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }, 2 node(s) didn\u0026#39;t match Pod\u0026#39;s node affinity/selector. preemption: 0/3 nodes are available: 3 Preemption is not helpful for scheduling. 警告 调度失败 103秒前 默认调度器 3个节点均不可用： - 一个节点无法容忍的五点（污点键：node-role.kubernetes.io/control-plane) - 2个节点不匹配pod的亲和性/选择器 抢占调度：0/3个节点可用，抢占对当前调度无帮助 3.查看pod的资源清单 kubectl get pod \u0026lt;pod-name\u0026gt; -o yaml |grep -A 10 \u0026#34;affinity\\|nodeSelector\u0026#34; 4.查看node节点是否存在disktype这个节点 kubectl get nodes --show-labels NAME STATUS ROLES AGE VERSION LABELS master Ready control-plane 20d v1.32.13 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=master,kubernetes.io/os=linux,node-role.kubernetes.io/control-plane=,node.kubernetes.io/exclude-from-external-load-balancers= worker1 Ready \u0026lt;none\u0026gt; 20d v1.32.13 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=worker1,kubernetes.io/os=linux worker2 Ready \u0026lt;none\u0026gt; 20d v1.32.13 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=worker2,kubernetes.io/os=linux 并没有这个disktype这个标签，所有3个节点都无法创建pod 2.DNS解析失败 1.查看节点状态 kubectl get node -o wide 2.查看pod详细信息 kubectl describe pods 3.查看pod日志 kubectl logs dns-failure-pod 报错信息 ;; connection timed out; no servers could be reached 显示无法到达任何服务器 根据报错信息得到，是容器内部的dns解析问题，进入容器内部查看解析 root@master:~# kubectl exec -it dns-failure-pod -- /bin/sh /etc # cat /etc/resolv.conf nameserver 192.0.2.1 /etc # ping 192.0.2.1 PING 192.0.2.1 (192.0.2.1): 56 data bytes ^C --- 192.0.2.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss ping指向的IP 192.0.2.1 无法ping通 4.查看pod对应的yaml文件 root@master:~# kubectl get pod dns-failure-pod -o yaml 5.根据pod名查看Pod yaml文件对应的位置 root@master:~# grep -r \u0026#34;name: dns-failure-pod\u0026#34; . ./kubernetes-like-a-pro/troubleshoot-kubernetes-like-a-pro/scenarios/dns-resolution-failure/issue.yaml: name: dns-failure-pod 6.修改pod yaml中192.0.2.1的ip地址，将ip改为对应svc的ip 查看对应svc的ip root@master:~# kubectl get svc -n kube-system |grep dns kube-dns ClusterIP 10.96.0.10 \u0026lt;none\u0026gt; 53/UDP,53/TCP,9153/TCP 20d 7.删除pod并新建pod后查看pod日志显示正常 kubectl delete dns-failure-pod kubectl apply -f 查询到的yaml文件地址 3.资源不足 1.查看pod状态 kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES insufficient-resources-pod 0/1 Pending 0 89s \u0026lt;none\u0026gt; \u0026lt;none\u0026gt; \u0026lt;none\u0026gt; \u0026lt;none\u0026gt; pod处于pending状态 2.查看详细信息 kubectl describe pods insufficient-resources-pod Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 2m45s default-scheduler 0/3 nodes are available: 1 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }, 2 Insufficient memory. preemption: 0/3 nodes are available: 1 Preemption is not helpful for scheduling, 2 No preemption victims found for incoming pod. 警告 pod调度失败 2m45s前 默认调度器 3个节点均不可用 1 个节点存在无法容忍的污点（污点键：`node-role.kubernetes.io/control-plane`） 2个节点不匹配Pod的节点亲和性/选择器 抢占调度：0/3个节点可用 3个节点均无法通过抢占来解决调度问题 3.查看pod对应yaml文件请求的资源数量 root@master:~# kubectl get pod insufficient-resources-pod -o yaml | grep -A 5 \u0026#34;resources:\u0026#34; resources: requests: cpu: \u0026#34;2\u0026#34; memory: 4Gi terminationMessagePath: /dev/termination-log terminationMessagePolicy: File 请求4g内存，而2个worker节点和1个master的内存都只有4g，所有无法创建pod，物理机器的资源不够pod请求，必须修改对应的资源清单 4.删除pod并重建pod root@master:~# kubectl delete pods insufficient-resources-pod root@master:~# kubectl apply -f kubernetes-like-a-pro/troubleshoot-kubernetes-like-a-pro/scenarios/insufficient-resources/issue.yaml 4.k8s版本过旧 5.安全上下文问题 root@master:~/kubernetes-like-a-pro/troubleshoot-kubernetes-like-a-pro/scenarios/security-context-issues# ll total 24 drwxr-xr-x 2 root root 4096 Apr 7 14:27 ./ drwxrwxr-x 37 root root 4096 Apr 7 14:27 ../ -rw-rw-r-- 1 root root 539 Aug 27 12:18 description.md -rw-rw-r-- 1 root root 306 Apr 7 14:27 fix.yaml -rw-rw-r-- 1 root root 309 Apr 7 14:27 issue.yaml -rw-rw-r-- 1 root root 139 Apr 7 14:27 security_context.sh root@master:~/kubernetes-like-a-pro/troubleshoot-kubernetes-like-a-pro/scenarios/security-context-issues# cat fix.yaml apiVersion: v1 kind: Pod metadata: name: security-context-fixed-pod spec: containers: - name: busybox image: busybox command: - \u0026#34;sh\u0026#34; - \u0026#34;-c\u0026#34; - \u0026#34;echo \u0026#39;Security context fixed\u0026#39; \u0026amp;\u0026amp; sleep 1000\u0026#34; securityContext: runAsUser: 1000 # Set to a non-root user runAsGroup: 1000 root@master:~/kubernetes-like-a-pro/troubleshoot-kubernetes-like-a-pro/scenarios/security-context-issues# cat issue.yaml apiVersion: v1 kind: Pod metadata: name: security-context-issue-pod spec: containers: - name: busybox image: busybox command: - \u0026#34;sh\u0026#34; - \u0026#34;-c\u0026#34; - \u0026#34;echo \u0026#39;Simulating security context issue\u0026#39; \u0026amp;\u0026amp; sleep 1000\u0026#34; securityContext: runAsUser: 0 # Simulating root user runAsGroup: 0 对比问题前yaml文件和修复后yaml文件 排查出是securityContext字段发生了变化，从0（root）用户切换到1000（普通用户） 实践： 1.查看pod的用户是啥 root@master:~/kubernetes-like-a-pro/troubleshoot-kubernetes-like-a-pro/scenarios/security-context-issues# kubectl exec -it security-context-issue-pod -- bin/sh / # id uid=0(root) gid=0(root) groups=0(root),10(wheel) 2.修改后pod的用户 root@master:~/kubernetes-like-a-pro/troubleshoot-kubernetes-like-a-pro/scenarios/security-context-issues# kubectl exec -it security-context-fixed-pod -- bin/sh ~ $ id uid=1000 gid=1000 groups=1000 6.CGroup问题 1.查看pod状态 root@master:~# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES cgroup-issue-pod 0/1 ImagePullBackOff 0 2m17s 10.244.2.23 worker2 \u0026lt;none\u0026gt; \u0026lt;none\u0026gt; 这里的报错信息并不对，是我网络的问题造成的镜像拉取失败，正确的报错关键字应该是`OOMKilled`，`Exit Code: 137`，pod状态为CrashLoopBackOff或者Error 2.查看详细信息 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 111s default-scheduler Successfully assigned default/cgroup-issue-pod to worker2 Normal Pulling 17s (x4 over 110s) kubelet Pulling image \u0026#34;polinux/stress\u0026#34; Warning Failed 16s (x4 over 109s) kubelet Failed to pull image \u0026#34;polinux/stress\u0026#34;: failed to pull and unpack image \u0026#34;docker.io/polinux/stress:latest\u0026#34;: failed to resolve image: unexpected status from HEAD request to https://docker.m.daocloud.io/v2/polinux/stress/manifests/latest?ns=docker.io: 403 Forbidden denied: 🚫 👀-\u0026gt; https://github.com/DaoCloud/public-image-mirror/issues/2328 🔗 这镜像不在白名单. this image is not in the allowlist. Warning Failed 16s (x4 over 109s) kubelet Error: ErrImagePull Normal BackOff 3s (x6 over 109s) kubelet Back-off pulling image \u0026#34;polinux/stress\u0026#34; Warning Failed 3s (x6 over 109s) kubelet Error: ImagePullBackOff 核心错误。表示请求被服务器拒绝，场景，镜像不在白名单中 3.看出对应资源清单 root@master:~# cat ./kubernetes-like-a-pro/troubleshoot-kubernetes-like-a-pro/scenarios/cgroup-issues/issue.yaml apiVersion: v1 kind: Pod metadata: name: cgroup-issue-pod spec: containers: - name: stress image: polinux/stress command: [\u0026#34;stress\u0026#34;, \u0026#34;--vm\u0026#34;, \u0026#34;1\u0026#34;, \u0026#34;--vm-bytes\u0026#34;, \u0026#34;100M\u0026#34;] resources: limits: memory: \u0026#34;50Mi\u0026#34; 可以看到容器启动使用内存为100m，但是limits限制的内存为50m，所以容器一达到50mi就被杀死 7.资源限制失败 1.查看pod信息 root@master:~# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES failed-resource-limits-pod 0/1 ImagePullBackOff 0 16s 10.244.2.31 worker2 \u0026lt;none\u0026gt; \u0026lt;none\u0026gt; 2.查看详细信息 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 55s default-scheduler Successfully assigned default/failed-resource-limits-pod to worker2 Normal BackOff 25s (x2 over 53s) kubelet Back-off pulling image \u0026#34;polinux/stress\u0026#34; Warning Failed 25s (x2 over 53s) kubelet Error: ImagePullBackOff Normal Pulling 14s (x3 over 55s) kubelet Pulling image \u0026#34;polinux/stress\u0026#34; Warning Failed 13s (x3 over 53s) kubelet Failed to pull image \u0026#34;polinux/stress\u0026#34;: failed to pull and unpack image \u0026#34;docker.io/polinux/stress:latest\u0026#34;: failed to resolve image: unexpected status from HEAD request to https://docker.m.daocloud.io/v2/polinux/stress/manifests/latest?ns=docker.io: 403 Forbidden denied: 🚫 👀-\u0026gt; https://github.com/DaoCloud/public-image-mirror/issues/2328 🔗 这镜像不在白名单. this image is not in the allowlist. Warning Failed 13s (x3 over 53s) kubelet Error: ErrImagePull 报错关键字：Failed to pull image 可以判断出是镜像拉取失败 3.找到pod对应yaml文件排查 未解决 8.存活探针失败 1.查看pod具体信息 可以看到pod已经重启过一次 2.查看详细信息 kubectl describe pods liveness-probe-failure-pod Events: Type Reason Age From Message ---- ------ ---- ---- ------- ...... Warning Unhealthy 0s (x8 over 27s) kubelet Liveness probe failed: HTTP probe failed with statuscode: 404 ..... 根据告警，可以得知是存活探针的问题 3.查看pod的yaml资源清单 所有pod会一直进行重启 4.修改对应pod的资源清单，改成有相应路径的yaml后，删除并重启pod，就无报错 9.持久卷声明问题 1.查看详细报错信息 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 61s default-scheduler 0/3 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/3 nodes are available: 3 Preemption is not helpful for scheduling. 警告 调度器尝试将pod放在3个节点上失败，pod未绑定pvc 2.查看对应pod的yaml清单 root@master:~# grep -r \u0026#34;name: pvc-issue-pod\u0026#34; . ./kubernetes-like-a-pro/scenarios/persistent-volume-claim-issues/issue.yaml: name: pvc-issue-pod 注解或者删除图片上对应的行就可解决报错 10.SELinux/AppArmor 策略冲突 11.集群自动伸缩问题 1.查看pod信息 发现有多个pod状态处于pending状态 2.查看pod的详细信息 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 90s default-scheduler 0/3 nodes are available: 1 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }, 2 Insufficient cpu. preemption: 0/3 nodes are available: 1 Preemption is not helpful for scheduling, 2 No preemption victims found for incoming pod. 警告 调度失败 90s前 来自默认调度器 可用节点0/3: 1个节点存在不可容忍的污点：node-role.kubernetes.io/control-plane: 2个节点cpu不足，抢占评估结果：0/3节点可用，其中1个节点抢占无法解决调度问题，另外2个节点未找到可被抢占到pod 3.查看pod对应的资源清单 发现启动的pod配置信息为0.5核心256m的内存，启动20个pod 但是我1master2worker都是4h4g的内存，所以我的集群硬件条件无法满足启动20个pod，所以有的pod无法启动 解决办法： 1.要么修改对应的pod配置 2.要么减少启动的pod数量 12.挂载卷文件权限问题 1.查看pod状态为error状态 2.查看详细信息 警告 回退重启 7s前 来自 kubelet 正在退避重启pod file-permissions-issue-pod(位于名称空间 default，UID为 7c99128...)中失败的容器 busybox 3.查看pod日志 root@master:~# kubectl logs file-permissions-issue-pod sh: line 0: can\u0026#39;t create /tmp/test.txt: Read-only file system 无法创建/tmp/test.txt\u0026#39; 4.查看pod的yaml清单 发现是限制了只读，注解或者删除securityContext字段就可以了 13.存活/就绪探针失败 1.查看Pod状态 root@master:~# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES liveness-readiness-failure-pod 0/1 Running 1 (12s ago) 24s 10.244.1.36 worker1 \u0026lt;none\u0026gt; \u0026lt;none\u0026gt; 虽然状态为running状态，但是重启过一次 2.查看pod详细信息 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning Unhealthy 5s (x12 over 36s) kubelet Readiness probe failed: HTTP probe failed with statuscode: 404 Warning Unhealthy 5s (x9 over 35s) kubelet Liveness probe failed: HTTP probe failed with statuscode: 404 警告 不健康 5s（在36s内出现12次） kubelet 就绪探针失败：http探测失败，状态码为404 警告 不健康 5s（在35s内出现9次） kubelet 存活探针失败：http探测状态，状态码为404 3.查看对应pod的yaml文件 可以看到yaml文件中的存活探针和就绪探针都需要存在/nonexistent文件夹才能通过探针，但是nginx默认没有这个文件，所以探针失败，将标红的这两个删除后，重启pod，现在正常 14.PID命明空间冲突 root@master:~# kubectl get pod pid-namespace-collision-pod -o yaml | grep -E \u0026#34;hostPID|shareProcessNamespace\u0026#34; {\u0026#34;apiVersion\u0026#34;:\u0026#34;v1\u0026#34;,\u0026#34;kind\u0026#34;:\u0026#34;Pod\u0026#34;,\u0026#34;metadata\u0026#34;:{\u0026#34;annotations\u0026#34;:{},\u0026#34;name\u0026#34;:\u0026#34;pid-namespace-collision-pod\u0026#34;,\u0026#34;namespace\u0026#34;:\u0026#34;default\u0026#34;},\u0026#34;spec\u0026#34;:{\u0026#34;containers\u0026#34;:[{\u0026#34;command\u0026#34;:[\u0026#34;sh\u0026#34;,\u0026#34;-c\u0026#34;,\u0026#34;echo \u0026#39;WARNING: Host PID namespace shared - security risk\u0026#39; \\u0026\\u0026 sleep 3600\u0026#34;],\u0026#34;image\u0026#34;:\u0026#34;busybox\u0026#34;,\u0026#34;name\u0026#34;:\u0026#34;busybox\u0026#34;,\u0026#34;securityContext\u0026#34;:{\u0026#34;runAsUser\u0026#34;:1000}}],\u0026#34;hostPID\u0026#34;:true}} hostPID: true 查看pod的yaml文件，该pod共享宿主机pid命名空间 后果: 1.进入pod内可以执行ps aux可以看到宿主机的全部进程 2.如果pod内的应用被攻破，可以使用kill -9 杀死宿主机上的进程 3.当pid资源全局耗尽后，节点上的所以pod都无法创建新进程 15.ServiceAccount权限问题 16.容器运行时（CRI）错误 1.查看pod状态 root@master:~# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES cri-error-pod 0/1 ContainerCreating 0 59s \u0026lt;none\u0026gt; worker2 \u0026lt;none\u0026gt; \u0026lt;none\u0026gt; pod状态被卡到containerCreating 容器创建中 2.查看pod详细状态信息 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 104s default-scheduler Successfully assigned default/cri-error-pod to worker2 Warning FailedCreatePodSandBox 104s kubelet Failed to create pod sandbox: rpc error: code = Unknown desc = unable to get OCI runtime for sandbox \u0026#34;c1d55779fc3edbd434abb06b671c048441fc59230848f785b9615edf26e30a4c\u0026#34;: no runtime for \u0026#34;non-existent-handler\u0026#34; is configured 警告 创建pod沙盒失败 104s前 来自kubelet 创建pod沙盒失败，错误码=Unknown，描述 = 无法为沙盒 c1.... 获取oci运行时：未配置名为non-existent-handler的运行时 3.查看对应pod的yaml文件 root@master:~# cat ./kubernetes-like-a-pro/scenarios/container-runtime-cri-errors/issue.yaml apiVersion: node.k8s.io/v1 kind: RuntimeClass metadata: name: broken-runtime handler: non-existent-handler --- apiVersion: v1 kind: Pod metadata: name: cri-error-pod spec: runtimeClassName: broken-runtime containers: - name: busybox image: busybox command: [\u0026#34;sh\u0026#34;, \u0026#34;-c\u0026#34;, \u0026#34;sleep 3600\u0026#34;] handler字段指定了容器运行时的处理名称，用于告知kubelet应用使用那个具体的OCI（Open Container lnitiative）运行时来运行该pod的容器 可以看到yaml文件中配置了non-existent-handler，所以和报错信息相对应，没有对应的non-existent-handler运行时，所以无法启动pod 4.确定从节点部署了哪些handler cat /etc/containerd/config.toml | grep -A 10 \u0026#34;runtimes\u0026#34; 可能会看到类似下面的内容： root@worker2:~# cat /etc/containerd/config.toml | grep -A 10 \u0026#34;runtimes\u0026#34; [plugins.\u0026#39;io.containerd.cri.v1.runtime\u0026#39;.containerd.runtimes] [plugins.\u0026#39;io.containerd.cri.v1.runtime\u0026#39;.containerd.runtimes.runc] runtime_type = \u0026#39;io.containerd.runc.v2\u0026#39; runtime_path = \u0026#39;\u0026#39; pod_annotations = [] container_annotations = [] privileged_without_host_devices = false privileged_without_host_devices_all_devices_allowed = false cgroup_writable = false base_runtime_spec = \u0026#39;\u0026#39; cni_conf_dir = \u0026#39;\u0026#39; cni_max_conf_num = 0 -- [plugins.\u0026#39;io.containerd.cri.v1.runtime\u0026#39;.containerd.runtimes.runc.options] BinaryName = \u0026#39;\u0026#39; CriuImagePath = \u0026#39;\u0026#39; CriuWorkPath = \u0026#39;\u0026#39; IoGid = 0 IoUid = 0 NoNewKeyring = false Root = \u0026#39;\u0026#39; ShimCgroup = \u0026#39;\u0026#39; SystemdCgroup = true 其中这两行是关键： [plugins.\u0026#39;io.containerd.cri.v1.runtime\u0026#39;.containerd.runtimes.runc] [plugins.\u0026#39;io.containerd.cri.v1.runtime\u0026#39;.containerd.runtimes.runc.options] 这两行配置位于containerd的配置文件（通常在/etc/containerd/config.toml）中，定义并配置runc这个运行时常量区（handler）的核心部分 17.防火墙限制 通过17个案例后，通用的三步走应该很熟练了： kubectl get nodes -o wide kubectl get pods -o wide kubectl describe pods \u0026lt;pod-name\u0026gt; kubectl logs \u0026lt;pod-name\u0026gt; 1.前面都没有问题，查看pod的log日志出现问题 root@master:~# kubectl logs firewall-restriction-pod wget: download timed out blocked wget下载超时 2.进入pod检查dns解析 ","date":"2026-08-27T00:00:00Z","permalink":"/posts/k8s%E6%8E%92%E9%9A%9C/","title":"k8s排障"},{"content":"自动订阅下载 + 局域网手机流畅播放 + 看完自动删 基于你 SER5 Max + PVE + 内置 2T SATA 固态 + LXC Ubuntu Docker 方案，全程内置硬盘无 USB 掉盘，核显硬解保证手机不卡顿，搭配脚本实现观影后自动清理。\n一、整套组件分工（全部 Docker 部署在同一 LXC） Jellyseerr：手机 / 浏览器选片订阅（你提交想看的电影 / 剧集） Radarr (电影) / Sonarr (剧集)：自动搜资源、推送下载、管理媒体库 qBittorrent：后台下载，硬链接入库，不重复复制文件 Jellyfin：局域网串流，AMD Vega8 核显硬解，手机 4K 流畅无缓冲 定时清理脚本：识别「已看完」影片，N 天自动删除释放硬盘空间 ","date":"2026-08-11T00:00:00Z","permalink":"/posts/%E4%B8%AA%E4%BA%BA%E5%BD%B1%E9%9F%B3%E6%90%AD%E5%BB%BA/","title":"个人影音搭建"},{"content":"k8s架构 master - controller manager 维护集群状态 - scheduler 调度pod - etcd 存储数据 - apiserver (6443/https) 入口 worker - kube-proxy (代理pod) - kubulet (管理pod生命周期) CNI - flannel - calico - canal - cilium k8s常用的资源 应用部署类 pod pod其实包含三种容器类型： - 基础架构容器 - 初始化容器 - 业务容器 启动顺序依次是：基础架构容器、初始化容器、业务容器 响应式管理pod kubectl run kubectl scale kubectl delete 等这些 声明式管理pod kubectl apply -f 资源清单 Deployment deployment是k8s中用于管理应用（pod）的控制器，用于部署和管理无状态应用 Replicaset 副本集，负责确保集群中始终运行指定数量的pod副本，是edployment实现滚动更新、回滚和版本管理的基础组件 Statefulset 缩写sts，管理有状态应用，为pod提供稳定的网络标识和持久化存储 Daemonset 是k8s的控制器，确保集群中等每个节点上都运行一个特定的pod job 负责运行一次性的批处理任务，确保任务成功完成 Cronjob 基于时间调度运行job，实现周期性任务 Namespace 命名空间，在k8s集群中的虚拟隔离分区，用于将集群资源（如pod、service、deployment、pve等）划分为不同的逻辑组 网络访问类 Service-给pod提供稳定访问地址 Ingress-http/https七层路由 IngressClass-指定由那个Ingress Controller处理 networkPolicy-限制pod之间的网络访问 EndpointSlice-记录Service后端pod地址 配置和敏感信息类 ConfigMap-保存普通配置 secret-保存密码、token、证书等敏感信息 存储类 Volume-pod内挂载存储 PersistentVolume（PV）-集群中的实际存储资源 PersistentVolumeClaim（PVC）-应用申请存储 StorageClass-定义动态创建存储方式 CSI-存储插件接口 资源调度和限制 ResourceQuota-限制Namespace总资源 LimitRange-设置容器默认/最大资源 PriorityClass-设置Pod优先级 Resource Request-调度时预留资源 Resource Limit-限制最大使用量 NodeSelector-指定节点标签 Affinity/Anti-Affinity-控制pod调度关系 Taint/Toleration-控制节点是否允许pod调度 自动扩缩容和发布 HorizontalPodAutoscaler(HPA)-根据指标括缩Pod VerticalPodAutoscale(VPA)-自动调整cpu/内存建议 PodDisruptionBudget（PDB）-保证维护期间最低可用副本 Lease-租约和选主机制 权限和安全 ServicAccount-pod使用的身份 Role-Namespace内权限 ClusterRole-集群级权限 RoleBinding-绑定Namespace权限 ClusterRoleBinding-绑定集群权限 PodSecurity-Pod安全控制 NetworkPolicy-网络隔离 集群和节点级资源 Node-工作节点 ClusterRole-集群级权限 CustomResourceDefintion（CRD）-扩展k8s api Operator-通过控制器自动管理复杂应用 Event-记录调度、启动、失败等事件 ","date":"2026-08-09T00:00:00Z","permalink":"/posts/k8s%E5%A4%8D%E5%AD%A6/","title":"k8s复学"},{"content":"这是我的第一篇文章 为什么要写这个文章，是因为原来的我都是使用的hexo主题+git手动进行上传的文章，最近使用obsidan做笔记，完整的插件生态让我彻底爱上了这个软件，就琢磨这能否将手动上传更改为自动上传。\n缺陷 1.有着将近2~3分钟的延迟，根据你实际的网速来 2.使用的obsidian git插件必须开启翻墙工具，因为国内有时无法访问github仓库 ","date":"2026-08-07T00:00:00Z","permalink":"/posts/obsidian+github-pages-%E8%87%AA%E5%8A%A8%E5%8F%91%E5%B8%83%E5%8D%9A%E5%AE%A2%E5%86%85%E5%AE%B9/","title":"obsidian+github pages 自动发布博客内容"}]