Kubernetes 架构与 kubectl¶
Kubernetes 集群由控制平面和工作节点组成。控制平面保存期望状态并作出调度与控制决策；工作节点真正运行 Pod。
控制平面组件¶
| 组件 | 作用 | 故障影响与检查方向 |
|---|---|---|
| kube-apiserver | Kubernetes API 入口，负责认证、鉴权、准入与资源操作 | kubectl/控制器无法访问集群；查 API 健康、证书、负载均衡 |
| etcd | 保存所有 Kubernetes API 数据的高可用键值数据库 | 集群状态无法可靠读写；必须做快照、监控空间和磁盘延迟 |
| kube-scheduler | 为尚未绑定节点的 Pod 选择 Node | Pod 长期 Pending；查资源、污点、亲和性、PVC 与调度事件 |
| kube-controller-manager | 运行 Deployment、Node、Job 等控制器 | 实际状态无法向期望状态收敛 |
| cloud-controller-manager | 对接云负载均衡、路由、节点等 API，可选 | LoadBalancer、云盘或节点集成异常 |
控制平面不直接运行你的业务容器。它保存和协调状态；Pod 最终由工作节点上的组件执行。
Node 组件¶
| 组件 | 作用 | 常见排障点 |
|---|---|---|
| kubelet | 监听分配到本节点的 Pod，调用容器运行时并执行 Probe | Pod 创建失败、Volume 挂载、Probe、Node NotReady |
| Container Runtime | 拉取镜像并运行容器，如 containerd | ImagePull、容器退出、镜像空间 |
| kube-proxy | 维护 Service 转发规则，部分方案可能使用其他实现 | Service 网络、规则同步 |
| CNI 插件 | 为 Pod 分配网络并实现连通/策略 | Pod 无 IP、跨节点不通、NetworkPolicy |
| CSI 插件 | 提供卷创建、挂载和卸载 | PVC Pending、Attach/Mount 失败 |
kubectl 怎样工作¶
kubectl
→ 读取 kubeconfig 中的 current-context
→ 得到 API Server、用户凭据和默认 Namespace
→ 调用 kube-apiserver
→ API Server 完成认证、RBAC 鉴权和准入检查
→ 查询或修改资源
操作生产前先确认身份和目标：
kubectl config current-context
kubectl config get-contexts
kubectl config view --minify
kubectl auth whoami
kubectl auth can-i get pods -n app
kubectl auth can-i delete deployment -n app
不要只根据终端目录判断当前集群；kubectl 的目标由 kubeconfig context 决定。
Namespace¶
Namespace 用于对大部分资源进行逻辑分组，便于配置 RBAC、ResourceQuota 和 NetworkPolicy。Node、PV、StorageClass、Namespace 本身等是集群级资源，不属于某个 Namespace。
kubectl get namespaces
kubectl create namespace app
kubectl config set-context --current --namespace=app
kubectl get pods -n app
业务不要长期堆在 default。Namespace 也不是完整的安全隔离，仍需权限、网络策略和资源配额配合。
核心查看命令¶
# 集群和节点
kubectl cluster-info
kubectl get nodes -o wide
kubectl describe node <node-name>
# 常见业务对象
kubectl get deploy,rs,pod,svc,ingress -n app
kubectl get pods -n app -o wide
kubectl get pods -n app --show-labels
kubectl get pod <pod-name> -n app -o yaml
# 按标签筛选
kubectl get pods -n app -l app=order-service
# 持续观察变化
kubectl get pods -n app -w
# 最近事件
kubectl get events -n app --sort-by=.lastTimestamp
kubectl get all 并不真的包含所有资源，例如 ConfigMap、Secret、Ingress、PVC 通常需要单独查看。
get、describe、logs 和 events 的区别¶
| 命令 | 回答什么问题 |
|---|---|
get |
对象现在处于什么概要状态 |
describe |
对象配置、Condition 和相关 Event 是什么 |
logs |
容器内应用输出了什么 |
events |
调度、拉镜像、挂载、Probe 等平台动作发生了什么 |
kubectl describe pod <pod-name> -n app
kubectl logs <pod-name> -n app --all-containers --tail=200
kubectl logs <pod-name> -n app -c <container> --previous
容器 CrashLoop 时，--previous 用来查看上一次已经退出的容器日志，经常比当前空日志更有价值。
进入容器与临时调试¶
kubectl exec -it <pod-name> -n app -c <container> -- sh
kubectl port-forward -n app service/order-service 18080:8080
kubectl cp app/<pod-name>:/tmp/report.txt ./report.txt -c <container>
生产镜像可能没有 shell、curl 和诊断工具。不要为了方便把大量工具永久塞进业务镜像；可使用经过授权的临时调试容器或专用诊断方案。exec 只用于取证，不应在容器内手工修改长期配置，因为 Pod 重建后修改会消失。
创建、修改和删除¶
kubectl diff -f deployment.yaml
kubectl apply --server-side -f deployment.yaml
kubectl rollout status deployment/order-service -n app
kubectl edit deployment/order-service -n app
kubectl patch deployment/order-service -n app --type merge -p '{"spec":{"replicas":4}}'
kubectl scale deployment/order-service -n app --replicas=4
长期配置应回写 Git/Helm Values，由 Argo CD 或受控流水线发布。edit、patch 和 scale 适合确认问题或应急操作，但可能被 GitOps self-heal 恢复。
删除前先确认对象、Namespace、控制器和持久化影响：
删除 Deployment 管理的 Pod 后，控制器会再创建一个；这只是重建实例，不等于修复根因。删除 PVC、StatefulSet、Namespace 或 CRD 具有更大数据影响，必须先确认备份和级联删除范围。
输出格式与 JSONPath¶
kubectl get pods -n app -o name
kubectl get pods -n app -o json
kubectl get pods -n app \
-o custom-columns='NAME:.metadata.name,NODE:.spec.nodeName,PHASE:.status.phase'
kubectl get pod <pod-name> -n app \
-o jsonpath='{.status.containerStatuses[*].restartCount}'
脚本中优先使用 JSON/JSONPath/custom-columns，不要依赖默认表格的空格位置进行文本截取。