Kubernetes基础实战：从控制循环到生产级排障-平芜编程栈

1. 这不是“学完就能上手”的速成课，而是你真正理解Kubernetes的起点

很多人点开“k8s基础-实战”这个标题时，心里想的是：装个Minikube、跑个nginx Pod、敲几条kubectl命令，就算入门了。我带过不下二十个刚转云原生的开发和运维同学，几乎所有人最初都卡在同一个地方——命令能敲出来，但一旦Pod起不来，日志里全是Warning，就彻底懵了。不是不会查，是根本不知道该往哪个方向查。为什么Service连不上？为什么ConfigMap挂载后文件是空的？为什么HorizontalPodAutoscaler压根不触发？这些问题背后，从来不是某个命令记错了，而是对Kubernetes底层设计逻辑的陌生。

“k8s基础-实战”这六个字，核心不在“k8s”，也不在“实战”，而在于那个被很多人忽略的“基础”——它不是API对象列表，不是yaml字段填空，而是控制循环（Control Loop）如何驱动整个系统运转的因果链。你看到的Pod Running状态，其实是Scheduler分配节点、Kubelet拉镜像、CNI插件配置网络、Container Runtime启动容器、Liveness Probe持续探测……这一整条链路上十几个组件协同工作的结果。任何一个环节卡住，都会在kubectl get pods里显示为Pending、ContainerCreating或CrashLoopBackOff。而真正的“实战”，就是你能顺着这条链路，从现象反推故障点，而不是靠百度搜报错关键词再复制粘贴。

所以这篇内容，不教你怎么背kubectl get nodes -o wide，而是带你亲手搭一个最小可行集群，从零部署一个带健康检查、配置分离、服务发现和自动扩缩的真实微服务Demo，并在每个环节停下来问一句：“如果这里断了，系统会怎么表现？我该看哪条日志？哪个指标会异常？”它适合三类人：一是刚接触K8s、被yaml和术语绕晕的新手，需要建立清晰的系统观；二是已经会用但总在排障时抓瞎的中级使用者，需要补全底层逻辑断层；三是准备考CKA但发现刷题不如动手调试来得扎实的备考者。你不需要提前装好Docker或熟悉Go语言，但得愿意打开终端，一行行敲命令，观察输出变化——因为Kubernetes最好的老师，永远是你自己执行命令后返回的那行Status: Running。

2. 为什么放弃Minikube和Kind？从单机模拟到真实集群的认知跃迁

2.1 Minikube和Kind的“温柔陷阱”

市面上90%的K8s入门教程，第一课必是minikube start或kind create cluster。它们确实快：30秒内给你一个五脏俱全的单节点集群，kubectl能连，Dashboard能开，Pod能跑。但问题恰恰出在这里——它太“完美”了。Minikube把etcd、kube-apiserver、kube-scheduler全塞进一个Docker容器，Kubelet运行在宿主机，网络走VirtualBox/Native Docker桥接；Kind则用Docker-in-Docker模式，在容器里再起容器跑组件。这种架构下，你永远看不到真实的组件间通信延迟、网络策略拦截、节点资源争抢、证书轮换失败等生产环境高频问题。

我带的一个某高校实验室项目，学生用Minikube调试了一个月的Ingress路由，一切正常。一上测试环境（三节点裸金属集群），Ingress Controller直接503。排查三天才发现：Minikube默认禁用NodePort，而测试环境Ingress依赖NodePort暴露服务，且防火墙规则没开对应端口。这种差异，Minikube不会告诉你，因为它根本没模拟这个环节。

提示：Minikube和Kind是极佳的API学习沙盒，但不是认知K8s系统行为的可靠环境。它们帮你快速验证“语法是否正确”，却无法训练你判断“语义是否合理”。

2.2 选择kubeadm：亲手拧紧每一颗螺丝的意义

本实战采用kubeadm部署三节点集群（1 Master + 2 Worker），原因很实在：它强制你直面K8s最核心的四个抽象层——

基础设施层：你需要手动配置hostname、关闭swap、加载br_netfilter模块、配置iptables FORWARD链。这些不是“可选步骤”，而是Kubelet与CNI插件通信的物理前提。比如sysctl net.bridge.bridge-nf-call-iptables=1这行命令，本质是让网桥流量经过iptables规则，否则Calico或Flannel的网络策略将完全失效。
证书管理层：kubeadm init会自动生成CA证书、API Server证书、etcd证书、管理员kubeconfig等。当你执行kubeadm join时，Worker节点用的是由Master签发的client证书，而非简单token。这意味着你必须理解/etc/kubernetes/pki/目录下每个文件的作用——ca.crt是信任锚，apiserver-kubelet-client.crt是API Server向Kubelet发起TLS连接的凭证。一旦证书过期（默认1年），整个集群将拒绝所有kubectl请求，而错误信息只会显示x509: certificate has expired or is not yet valid，毫无上下文。
组件协调层：kubeadm不隐藏组件启动方式。你清楚看到kubelet通过systemd管理，静态Pod清单放在/etc/kubernetes/manifests/下，etcd以容器形式运行但数据目录独立挂载。当API Server Crash时，你能直接journalctl -u kubelet -n 100查看Kubelet日志，定位是etcd连接超时还是证书校验失败。
网络抽象层：kubeadm不预装CNI插件。你必须手动选择并部署Calico/Flannel/Cilium。这个过程迫使你理解CNI规范：每个Pod必须有独立IP，跨节点通信需Overlay网络或BGP路由，而CNI插件正是通过调用/opt/cni/bin/下的二进制文件完成IPAM（IP地址分配）和网络命名空间配置。

实操中，我建议用Vagrant+VirtualBox搭建三台CentOS 7虚拟机（2C4G/台），这样既避免云服务器费用，又能真实复现物理机部署流程。关键参数如下：

节点	IP地址	主机名	角色	关键配置
master	192.168.56.10	k8s-master	Control Plane	`--pod-network-cidr=10.244.0.0/16`（与Calico默认一致）
node1	192.168.56.11	k8s-node1	Worker	关闭SELinux：`setenforce 0`&`/etc/selinux/config`设为disabled
node2	192.168.56.12	k8s-node2	Worker	确保`/proc/sys/net/bridge/bridge-nf-call-iptables`值为1

注意：不要跳过swapoff -a和sed -i '/ swap / s/^/#/' /etc/fstab。Kubelet明确禁止swap启用，否则启动直接失败，错误日志藏在journalctl -u kubelet末尾，极易被忽略。

2.3 部署流程拆解：每一步背后的“为什么”

kubeadm init的核心命令是：

kubeadm init \ --kubernetes-version=v1.28.2 \ --pod-network-cidr=10.244.0.0/16 \ --service-cidr=10.96.0.0/12 \ --cri-socket unix:///var/run/containerd/containerd.sock

--kubernetes-version：指定K8s版本。v1.28是当前长期支持（LTS）版本，避免使用v1.29+的alpha特性导致兼容性问题。
--pod-network-cidr：定义Pod IP段。必须与后续CNI插件配置严格一致。Calico默认用192.168.0.0/16，但Flannel用10.244.0.0/16，选错会导致Pod间无法通信。
--service-cidr：定义ClusterIP Service的IP范围。10.96.0.0/12提供约100万个IP，足够大型集群使用。若设太小（如/16），Service数量超限后新创建会失败。
--cri-socket：指定容器运行时套接字。containerd是当前主流，路径为unix:///var/run/containerd/containerd.sock；若用Docker，则为unix:///var/run/docker.sock（已弃用）。

执行后，kubeadm会输出类似kubeadm join 192.168.56.10:6443 --token abcdef.0123456789abcdef --discovery-token-ca-cert-hash sha256:...的命令。这个token有效期24小时，hash值用于验证CA证书真实性。Worker节点执行此命令时，会：

向API Server发起TLS连接（用内置CA证书）
提交CSR（Certificate Signing Request）申请客户端证书
API Server批准CSR，下发kubelet.conf
Kubelet用新证书注册为Node，状态变为Ready

整个过程没有魔法，全是标准TLS握手和证书签发。理解这点，你就明白为什么kubeadm token create --print-join-command能生成新token，而kubeadm certs check-expiration能查看所有证书剩余天数。

3. 实战项目：从零部署一个带健康检查与自动扩缩的真实微服务

3.1 项目需求与架构设计

我们不部署hello-world，而是构建一个简化的“订单处理系统”：

frontend：React前端，通过HTTP调用backend API
backend：Python Flask服务，处理订单创建请求，依赖redis缓存
redis：作为共享缓存，存储订单计数器

核心要求：

所有服务必须通过Service暴露，禁止直接用Pod IP
backend必须配置Liveness和Readiness探针，模拟真实健康检查逻辑
frontend需通过Ingress实现域名访问（order.local）
整个系统需支持基于CPU使用率的自动扩缩（HPA）

这个设计刻意引入了K8s四大核心抽象的协同：

Pod：运行容器的最小单元，frontend/backend/redis各为一个Pod
Service：为Pod提供稳定网络端点，解决Pod IP不固定问题
Ingress：七层负载均衡，将域名路由到对应Service
HPA：监控指标并自动调整Pod副本数

实操心得：新手常犯的错误是先写Deployment再写Service，结果Service的selector匹配不上Deployment的label。正确顺序是：先确定Pod模板的labels（如app: backend），再写Service的selector指向它，最后写Deployment的template.labels保持一致。K8s不校验label一致性，错误只会在kubectl get endpoints为空时暴露。

3.2 核心YAML详解：不只是填空，而是理解每个字段的契约

Deployment: backend.yaml

apiVersion: apps/v1 kind: Deployment metadata: name: backend labels: app: backend spec: replicas: 2 selector: matchLabels: app: backend template: metadata: labels: app: backend spec: containers: - name: flask-app image: registry.example.com/backend:v1.0 ports: - containerPort: 5000 env: - name: REDIS_HOST value: "redis.default.svc.cluster.local" livenessProbe: httpGet: path: /healthz port: 5000 initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: httpGet: path: /readyz port: 5000 initialDelaySeconds: 5 periodSeconds: 5 resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m"

关键字段解析：

replicas: 2：声明期望副本数。Kubelet的控制循环会持续比对实际Running Pod数，不足则创建，过多则删除。
selector.matchLabels：定义Deployment管理哪些Pod。必须与template.metadata.labels完全一致，否则Deployment认为没有Pod可管。
env.REDIS_HOST：使用K8s DNS格式<service-name>.<namespace>.svc.cluster.local。这是Service发现的核心机制——Kube-DNS或CoreDNS会将此域名解析为Service ClusterIP。
livenessProbe：容器存活探针。initialDelaySeconds: 30表示启动30秒后再开始探测，避免应用未初始化完成就被误杀。periodSeconds: 10即每10秒探测一次。若连续失败，Kubelet会重启容器。
readinessProbe：就绪探针。与liveness不同，失败时Kubelet仅将Pod从Service的Endpoint列表中移除，不重启容器。initialDelaySeconds: 5更短，因就绪检查通常比存活检查更快。
resources.requests：声明容器最低资源需求。Scheduler依据此决定能否调度到某节点。若节点剩余资源<64Mi内存，则拒绝调度。
resources.limits：声明容器最大资源上限。cgroups会强制限制，超限时内存OOMKilled，CPU被节流。

注意：httpGet探针的path必须在应用中真实存在。Flask示例代码需添加：
@app.route('/healthz') def healthz(): return "OK", 200 @app.route('/readyz') def readyz(): # 检查Redis连接 try: redis_client.ping() return "OK", 200 except: return "Redis Unavailable", 503

Service: backend-service.yaml

apiVersion: v1 kind: Service metadata: name: backend spec: selector: app: backend ports: - protocol: TCP port: 80 targetPort: 5000 type: ClusterIP

selector.app: backend：必须与Deployment的label完全匹配，否则kubectl get endpoints backend将显示<none>。
port: 80：Service对外暴露的端口（ClusterIP:80）。
targetPort: 5000：转发到Pod容器的端口（容器内Flask监听5000）。
type: ClusterIP：默认类型，仅集群内部可访问。若需外部访问，改为NodePort或LoadBalancer。

Ingress: frontend-ingress.yaml

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: frontend-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: ingressClassName: nginx rules: - host: order.local http: paths: - path: / pathType: Prefix backend: service: name: frontend port: number: 80

ingressClassName: nginx：指定Ingress Controller类型。需提前部署nginx-ingress-controller（非K8s内置，需单独安装）。
host: order.local：定义域名。本地测试需在/etc/hosts添加192.168.56.10 order.local。
nginx.ingress.kubernetes.io/rewrite-target: /：Nginx注解，将/api/orders重写为/转发给frontend服务，避免前端路由404。

3.3 部署全流程与关键验证点

按顺序执行以下命令：

# 1. 创建Namespace隔离环境 kubectl create namespace order-system # 2. 部署Redis（StatefulSet更合适，但此处简化用Deployment） kubectl apply -f redis-deployment.yaml -n order-system kubectl apply -f redis-service.yaml -n order-system # 3. 部署Backend kubectl apply -f backend-deployment.yaml -n order-system kubectl apply -f backend-service.yaml -n order-system # 4. 部署Frontend kubectl apply -f frontend-deployment.yaml -n order-system kubectl apply -f frontend-service.yaml -n order-system # 5. 部署Ingress（需确保nginx-ingress已就绪） kubectl apply -f frontend-ingress.yaml -n order-system # 6. 部署HPA（需Metrics Server） kubectl autoscale deployment backend --cpu-percent=50 --min=2 --max=5 -n order-system

每步必须验证的关键点：

Namespace创建后：kubectl get ns order-system应显示Active状态。
Redis部署后：kubectl get pods -n order-system查看Pod状态，kubectl exec -it <redis-pod> -n order-system -- redis-cli ping应返回PONG。
Backend Service创建后：kubectl get svc -n order-system查看CLUSTER-IP，kubectl get endpoints backend -n order-system必须显示两个IP（对应两个Pod）。若为空，立即检查Deployment label与Service selector是否一致。
Ingress部署后：kubectl get ingress -n order-system查看ADDRESS列是否为Ingress Controller的Pod IP。若为空，检查Ingress Controller是否Running，且ingressClassName是否匹配。
HPA部署后：kubectl get hpa -n order-system查看TARGETS列。初始为<unknown>/50%，因Metrics Server需时间采集数据。等待2分钟，应变为0%/50%（当前CPU使用率0%）。

实操心得：kubectl describe是排障神器。当Pod卡在ContainerCreating，执行kubectl describe pod <name> -n order-system，Events部分会明确提示：“Failed to pull image”（镜像拉取失败）、“MountVolume.SetUp failed”（ConfigMap/Secret挂载错误）或“NetworkPlugin cni failed”（CNI插件未就绪）。这些信息比kubectl logs更早暴露根因。

4. 排查实战：从Pending到Running，一条链路的完整诊断手册

4.1 Pod状态机详解：每个状态背后的系统行为

Kubernetes Pod生命周期有7种核心状态，理解其转换条件是排障基础：

状态	触发条件	常见原因	排查命令
Pending	已被API Server接受，但未被调度到节点	资源不足（CPU/Memory）、节点污点（Taint）、PV绑定失败、镜像拉取失败	`kubectl describe pod <name>`→ Events
ContainerCreating	Scheduler已分配节点，Kubelet正创建容器	CNI网络未就绪、镜像拉取慢、Init Container未完成、SecurityContext权限拒绝	`kubectl logs <pod> --previous`（查看上次崩溃日志）
Running	容器已创建并至少一个主容器在运行	正常状态	`kubectl logs <pod>`查看应用日志
Succeeded	所有容器成功退出且不会重启	Job/CronJob完成	`kubectl logs <pod>`获取输出
Failed	所有容器都已终止，至少一个以失败状态退出	应用崩溃、OOMKilled、容器启动命令错误	`kubectl describe pod`→ Events +`kubectl logs --previous`
Unknown	节点失联，Kubelet无法上报状态	节点宕机、网络中断、Kubelet进程崩溃	`kubectl get nodes`查看节点状态
CrashLoopBackOff	容器启动后立即失败，Kubelet按指数退避重启	应用启动失败、依赖服务不可达、配置文件缺失	`kubectl logs <pod> --previous`+`kubectl describe pod`

注意：CrashLoopBackOff不是独立状态，而是Kubelet对反复失败容器的重试策略描述。实际Pod状态仍是Running（因Kubelet认为容器“正在运行”，尽管它刚崩溃）。因此kubectl get pods可能显示Running，但应用完全不可用。

4.2 典型故障场景与逐级排查法

场景1：Pod卡在Pending，Events显示“No nodes are available that match all of the predicates”

现象：kubectl get pods显示0/1，STATUS为Pending。

排查路径：

kubectl describe pod <name>→ Events末尾出现0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/control-plane: }; 2 node(s) didn't match pod affinity/anti-affinity, 2 node(s) didn't satisfy existing pods anti-affinity rules.
分析：节点有污点（Taint），而Pod无对应容忍（Toleration）。Control Plane节点默认有taint: node-role.kubernetes.io/control-plane:NoSchedule，防止工作负载调度到Master。
解决：
- 方案A（推荐）：将Pod调度到Worker节点，确保Deployment中无nodeSelector强制指定master。
- 方案B：为Pod添加容忍：
```
tolerations: - key: "node-role.kubernetes.io/control-plane" operator: "Exists" effect: "NoSchedule"
```
- 方案C（不推荐）：移除Master污点kubectl taint nodes k8s-master node-role.kubernetes.io/control-plane:NoSchedule-

实操心得：kubectl describe nodes可查看所有节点的Taints和Allocatable资源。若Allocatable内存远小于节点总内存，说明系统进程（如kubelet、containerd）占用了大量资源，需调整--system-reserved参数。

场景2：Pod卡在ContainerCreating，Events显示“networkPlugin cni failed”

现象：kubectl get pods显示0/1，STATUS为ContainerCreating，Events中出现Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container ... networkPlugin cni failed

排查路径：

kubectl get pods -n kube-system查看CNI相关Pod（如calico-node、flannel-ds）是否Running。
若calico-node为CrashLoopBackOff，执行kubectl logs -n kube-system calico-node-xxxxx。
常见日志：Error connecting to Typha: dial tcp 10.96.0.1:5473: i/o timeout—— Calico组件Typha的Service ClusterIP无法访问。
验证：kubectl get svc -n kube-system查看typha Service是否存在，kubectl get endpoints -n kube-system typha是否有Endpoints。
根因：CNI插件部署顺序错误。Calico要求先部署typha Deployment，再部署calico-node DaemonSet。若顺序颠倒，calico-node启动时找不到typha。

解决：重新按官方文档顺序部署Calico：

kubectl apply -f https://docs.projectcalico.org/manifests/calico-typha.yaml # 等待typha Pod Running kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

场景3：Service无法访问，curl ClusterIP超时

现象：kubectl get svc backend显示CLUSTER-IP为10.96.123.45，但curl 10.96.123.45:80返回Connection refused。

排查路径（四层穿透法）：

验证Service本身：kubectl get endpoints backend—— 若为空，说明无Pod匹配selector，回溯Deployment label。
验证Pod网络连通性：kubectl exec -it <backend-pod> -- curl http://localhost:5000/healthz—— 若失败，应用未监听或端口错误。
验证Service到Pod转发：kubectl exec -it <backend-pod> -- curl http://10.96.123.45:80/healthz—— 若失败，kube-proxy规则未生效。
验证kube-proxy状态：kubectl get pods -n kube-system | grep kube-proxy，kubectl logs -n kube-system kube-proxy-xxxxx查看是否有Failed to retrieve node info（节点信息获取失败）。

关键原理：kube-proxy在每个节点运行，监听Service变更，通过iptables或IPVS规则将ClusterIP流量DNAT到后端Pod IP。若kube-proxy Crash，Service将完全失效，但Pod仍Running。

4.3 HPA不触发的五大盲区

HPA（HorizontalPodAutoscaler）是K8s最易配置错误的组件之一。常见“配置了但不扩缩”问题：

盲区	表现	验证方法	解决方案
Metrics Server未部署	`kubectl top nodes`报错`error: Metrics API not available`	`kubectl get apiservice v1beta1.metrics.k8s.io`应为`True`	`kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.6.4/components.yaml`
Pod未设置requests	`kubectl get hpa`显示`<unknown>/50%`	`kubectl describe pod <backend-pod>`查看Containers.Resources.Requests	在Deployment中添加`resources.requests.memory/cpu`
指标采集延迟	HPA刚创建，TARGETS仍为`<unknown>`	等待3-5分钟，`kubectl get hpa`观察变化	耐心等待，Metrics Server默认30秒采集间隔
CPU指标来源错误	使用`kubectl top pods`看到CPU高，但HPA不扩	`kubectl top pods`显示的是节点cgroup统计，HPA读取的是metrics-server的聚合指标	确保metrics-server能访问Kubelet的`/metrics/cadvisor`端点（需开启`--authentication-token-webhook`）
HPA目标错误	扩缩的是Deployment而非ReplicaSet	`kubectl get hpa`的TARGET列显示`Deployment/backend`，而非`ReplicaSet/xxx`	HPA必须直接指向Deployment，K8s会自动关联其管理的ReplicaSet

实测案例：某次HPA不工作，最终发现是kubectl top nodes返回error: Metrics API not available。执行kubectl get apiservice发现v1beta1.metrics.k8s.io状态为False。检查metrics-server Pod日志，发现failed to listen on 0.0.0.0:443: listen tcp 0.0.0.0:443: bind: permission denied。原因是容器以非root用户运行，无法绑定443端口。解决方案：修改metrics-server Deployment，添加securityContext.runAsUser: 0。

5. 进阶思考：从“能跑”到“稳跑”，生产环境的隐形门槛

5.1 镜像安全与可信分发：为什么不能用latest标签

新手最爱用image: nginx:latest，但生产环境这是红线。latest标签不保证稳定性——今天pull是1.24，明天可能是1.25，而1.25可能移除了某个旧API。更严重的是安全漏洞：CVE-2023-1234可能影响nginx:1.23，但latest指向的1.24已修复，你却因缓存一直用着带毒镜像。

正确实践：

固定标签：image: nginx:1.24.0，明确版本号。
SHA256摘要：image: nginx@sha256:abc123...，绝对唯一，杜绝镜像篡改。
私有仓库签名：使用Notary或Cosign对镜像签名，K8s通过ImagePolicyWebhook验证签名后才允许拉取。

在Deployment中强制使用摘要：

containers: - name: nginx image: registry.example.com/nginx@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2

实操心得：docker pull后执行docker images --digests可查看本地镜像摘要。但生产环境应通过CI/CD流水线自动扫描镜像漏洞（Trivy、Clair），并生成带签名的摘要，写入K8s YAML。

5.2 资源管理的双刃剑：Requests/Limits的精确计算

resources.requests和limits不是随便填的数字，它们直接影响调度和稳定性：

Requests = 调度门槛：Scheduler将Pod调度到节点时，检查节点Allocatable - 已分配Requests > Pod Requests。若填requests.memory: 1Gi，但节点只有2Gi内存，已运行一个1.5Gi Pod，则新Pod无法调度。
Limits = OOM边界：当容器内存使用超limits.memory，Linux OOM Killer会杀死进程。但K8s不保证立即回收内存，可能造成短暂服务中断。

科学计算法：

压测获取基线：用wrk或hey对backend服务施加100QPS，kubectl top pods记录稳定后的内存/CPU使用率。
设置Requests：取压测峰值的120%。如压测峰值内存800Mi，则requests.memory: 960Mi。
设置Limits：Requests的1.5倍，留出缓冲。即limits.memory: 1440Mi。
验证：kubectl describe nodes查看Allocatable和Allocated Resources，确保余量>20%。

表格：某次压测后资源配置建议

组件	压测峰值CPU	压测峰值内存	Requests (CPU)	Requests (Memory)	Limits (CPU)	Limits (Memory)
frontend	120m	320Mi	150m	384Mi	300m	512Mi
backend	250m	750Mi	300m	900Mi	450m	1200Mi
redis	80m	200Mi	100m	240Mi	200m	320Mi

注意：CPU是可压缩资源，超limits会被节流（throttled），但不会OOM；内存是不可压缩资源，超limits直接OOMKilled。因此内存limits必须谨慎。

5.3 日志与监控的落地：不靠kubectl logs查生产问题

kubectl logs只能看当前容器日志，生产环境需三件套：

集中日志：EFK（Elasticsearch+Fluentd+Kibana）或Loki+Promtail。Fluentd DaemonSet收集每个节点/var/log/containers/*.log，发送至Loki。查询时用LogQL：{job="kubernetes-pods"} |~ "500"。
指标监控：Prometheus + Grafana。Prometheus通过ServiceMonitor抓取Kube-State-Metrics（集群状态）、cAdvisor（容器指标）、应用自定义指标（如Flask的/metrics端点）。
分布式追踪：Jaeger或Tempo。在Flask中集成OpenTelemetry SDK，记录HTTP请求链路，定位慢接口。

最小可行方案（单节点）：

# 部署Prometheus Operator kubectl apply -f https://raw.githubusercontent.com/prometheus-operator/kube-prometheus/main/manifests/setup/ # 部署Grafana kubectl apply -f https://raw.githubusercontent.com/prometheus-operator/kube-prometheus/main/manifests/grafana-dashboardDefinitions.yaml

然后访问kubectl port-forward svc/grafana 3000:3000，浏览器打开http://localhost:3000，导入K8s集群仪表盘（ID 6417）。

最后分享一个小技巧：当遇到诡异问题（如Pod偶尔503），别急着改代码。先执行kubectl top pods --all-namespaces，按CPU排序。往往发现是某个Sidecar容器（如istio-proxy）CPU打满，导致主容器网络延迟飙升。此时kubectl describe pod看Events，常有Back-off restarting failed container，根源在资源配额不足，而非应用Bug。

我在实际运维中发现，80%的“疑难杂症”其实源于资源配额、网络策略或镜像配置等基础设施层问题，而非应用代码。Kubernetes的威力不在于它多复杂，而在于它把所有不确定性——节点宕机、网络抖动、磁盘满——都转化为可观察、可控制、可自动恢复的状态。当你不再问“为什么Pod起不来”，而是习惯性输入kubectl describe、kubectl logs --previous、kubectl top，你就真正跨过了那道从“会用”到“懂系统”的门槛。