popexizhi: 转:kubectl

#查询

kubectl get pods #查询全部的Pods (默认的命名空间)

kubectl get pods -o wide #查询更多信息:ip,所在节点,重启次数

kubectl get pods --all-namespaces #查询全部的命名空间的pod

#查询 Deployment ,Service,Node,PVC

kubectl get deployments

kubectl get svc

kubectl get nodes

kubectl get pvc

#深入排查

kubectl describe pod <pod名称> #查看pod的详细事件

kubectl describe node <node名称> #查看node的资源压力

get和describe的核心区别是: get -o yaml 看"配置长什么样", describe 看"集群里发生了什么"

#声明配置

kubectl apply -f deployment.yaml #创建或更新资源，可反复执行,幂等

kubectl delete -f deployment.yaml #删除资源

kubectl delete pod <pod名称> #删除指定的pod

kubectl delete deployment <部署名称> #删除deloyment 对应的pod也随着删除

kubectl delete -f deployment.yaml #基于文件删除和apply对应

解释:

为什么用 apply 而不是 create？

create 是命令式，资源已存在时报错；apply 会计算 diff 并更新，与 GitOps 理念一致。

[popexizhi: GitOps理念 :

核心思想：三句话概括

- 整个系统用代码描述：K8s YAML、Terraform 配置、Helm Chart 全部放在 Git。

- Git 是唯一真相源：任何人想改配置，不许登录服务器敲命令，只能提交 Pull Request 改 Git。

- 自动同步：集群里有个“机器人”（如 ArgoCD、Flux）盯着 Git，发现差异就自动应用。

ps:反常识点：kubectl 在生产环境其实是“不推荐”的——因为它绕过了 Git，导致仓库和实际环境不一致。

幂等（Idempotent）最简单的理解是：“一次操作和多次操作，产生的结果是一样的”

]

popexizhi