搜索结果: "kubectl"

| ⑥ 集群与策略层（K8s） | CNI/kube-proxy/NetworkPolicy/Service/Endpoint 一致？ | `kubectl get pod,svc,ep -A`, `kubectl get netpol -A` |

1. **K8s Pod 状态** — `kubectl get pod -A -o wide` → 看 STATUS / IP / NODE 字段

2. **Service 与 Endpoint** — `kubectl get svc,ep -A` → 看 CLUSTER-IP / PORT(S) / ENDPOINTS 是否为空

| Service 不通但 Pod IP 直连可通 | `kubectl get svc,ep` 看 ENDPOINTS | Selector/TargetPort 不匹配 / kube-proxy 异常 |

| NetworkPolicy 假性故障 | `kubectl get netpol -A` | PodSelector 或规则未放行默认流量 |

| Gateway API CRD | ≥ 1.0.0 | `kubectl get gatewayclass` 验证 |

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.0/standard-install.yaml

kubectl get crd | grep gateway

kubectl get storageclass

kubectl create ns jenkins-team-a

> Pod 卡在 Pending 意味着 Scheduler 找不到合适的节点分配，或 Kubelet 在创建容器阶段卡住。核心排查工具：**`kubectl describe pod` 的 Events 段**直接告诉你原因。

kubectl describe pod -n | tail -20

kubectl get events -n --sort-by='.lastTimestamp'

kubectl top nodes

kubectl top pods -n

**故障链：** 集群突然不可用 → `kubectl` 全部 timeout → 发现 API Server Pod 被 OOMKilled 循环重启。

kubectl get events -A --field-selector reason=OOMKilled

kubectl logs -n kube-system kube-apiserver-master01 --tail=50

**故障链：** 某天上班发现 `kubectl` 全部报 `x509: certificate has expired` → 整个集群不可管理。

kubectl describe node | grep -A5 Conditions

kubectl get pod -o jsonpath='{.status.qosClass}'

kubectl describe pod | grep -E "QoS|Memory|Limit|Request"

kubectl top pods --all-namespaces

kubectl top pod -n --containers

kubectl describe node | grep -A 10 "Allocated resources"

| Pod Pending，0/N nodes available | nodeSelector/Affinity 无匹配节点 | `kubectl get nodes --show-labels` |

kubectl label node key=value # 添加标签

kubectl label node key- # 删除标签

kubectl get nodes --show-labels # 查看所有标签

kubectl taint nodes key=value:NoSchedule # 添加污点

kubectl get svc -n

kubectl get pods -n -l app=

kubectl get endpoints -n

kubectl get pods -n -o wide | grep

kubectl get pods -n -o wide

kubectl get pod -L apps.kubernetes.io/pod-index

kubectl run test --image=busybox -- nslookup mysql-0.mysql.default.svc.cluster.local

kubectl rollout status sts/

- **PVC 未绑定 → Pod Pending：** `kubectl describe pod` 可看到 `pod has unbound immediate PersistentVolumeClaims`

- **回滚更新：** `kubectl rollout undo sts/`

**诊断入口：** `kubectl describe pod` → Events 段看最后几行

| **资源不足** | `kubectl top nodes` → 检查 Allocatable | 扩容节点 / 降低资源请求 / 清理低优 Pod |

| **污点/容忍** | `kubectl get node -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints` | 添加 tolerations 或临时 `kubectl taint node ... -` |

| **PVC 未就绪** | `kubectl get pvc -n ` → `kubectl describe pvc` | 检查 StorageClass / PV 绑定 / 存储后端 |

> 🔙 **回滚：** 如果是改 YAML 解决的，直接 `kubectl apply` 原配置；涉及污点则 taint 命令恢复。

tags: [kubernetes, troubleshooting, production, kubectl]

`kubectl get pod` 的 STATUS 列已能给出初步方向。CrashLoopBackOff 和 ImagePullBackOff 的处理路径完全不同。

kubectl get deployment -n -o yaml > backup_.yaml

| 1 | `kubectl get pods -n ` | 确认 STATUS（CrashLoopBackOff / ImagePullBackOff / Pending / Terminating） |

| 2 | `kubectl describe pod -n ` | 查看 Events 和 Conditions，判断方向 |

1. 确认 NotReady 现象和受影响范围（`kubectl describe node`）

kubectl get nodes -o wide

kubectl get nodes | grep -v Ready

kubectl describe node

kubectl get pods -o wide --all-namespaces | grep

> ⚠️ **核心认知：** CrashLoopBackOff 从来都不是根因。它只是 K8s 告诉你「容器一直在崩，我已经重启很多次了」。真正的问题一定在容器内部——**不要上来就 `kubectl delete pod`**，会丢失日志现场导致问题更难定位。

① kubectl get pod -A → 看 STATUS + RESTARTS

② kubectl describe pod → 看 Events 段（已直接告诉你原因）

③ kubectl logs --previous → 看上一次崩溃时的日志

④ kubectl exec / debug-pod → 进入容器内部排查

kubectl describe pod -n | grep -E "Last State|Reason|Exit Code"

kubectl get pod -n \

kubectl top nodes

1. **增大 memory limits**（如果是正常业务增长）`kubectl patch deployment`

2. **检查内存泄漏**（使用 `kubectl top pod` 观察趋势）

kubectl get svc -n -o jsonpath='{.spec.selector}'

kubectl get pods -n --show-labels | grep

kubectl get pods -n -l "="

kubectl get pods -n kube-system -l k8s-app=kube-dns

kubectl get pods -n kube-system -l app.kubernetes.io/name=coredns

kubectl describe pvc -n

kubectl get storageclass

kubectl get pods -n kube-system | grep -E "csi|storage"

kubectl get csidriver

kubectl get pvc -n -o jsonpath='{.spec.accessModes}'

kubectl top node

kubectl top pod -A --containers | head -30

kubectl describe node | egrep -A3 'Allocated resources'

| 代码 Bug（刚发布） | 回滚 | `kubectl rollout undo` |

| 集群级 | 紧急扩容 | `kubectl scale --replicas=N` |

1. 检查 Endpoints 是否正常：`kubectl get endpoints `

2. 检查 kube-proxy 模式：`kubectl logs -n kube-system kube-proxy-xxx`

2. 查看 Ingress 日志：`kubectl logs -n ingress-nginx deploy/ingress-nginx-controller`

3. 检查 Ingress 资源配置：`kubectl describe ingress `

kubectl exec -- mount | grep config

kubectl get configmap -n

kubectl describe pod -n

云原生时代业务从月级版本变为分钟级交付，传统"人工打包 + 手动 kubectl apply"已无法满足高频发布、多环境隔离、可回滚可追溯、自动化安全的需求。

kubectl create namespace argocd

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

| **生效** | `kubectl rollout restart -n kube-system deployment/coredns` |

| **验证** | `kubectl run -it --rm debug --image=busybox -- nslookup <域名>` |

| **回滚** | `kubectl rollout undo -n kube-system deployment/coredns` |

kubectl describe pod

kubectl get pod -o jsonpath='{.status.containerStatuses[0].lastState.terminated.reason}'

- kubectl: kubectl 命令

| 33 | 多集群管理？ | kubectl 多上下文 + 集群联邦(Karmada) + Rancher/OpenShift + 跨集群服务发现 + 统一监控 |

kubectl describe pod | grep -E "State|Exit|OOM"

| PVC Pending | `kubectl describe pvc` 查看事件 / `kubectl get pv` / `kubectl get storageclass` |

不靠 `kubectl rollout status`，而靠实时监控数据判断：

├── 4. upstream 进程状态（OOM/容器重启/kubectl）