taint
-
kubectl taint nodes node1 foo=bar:NoSchedule -- 某个节点被加上了一个 Taint，即被“打上了污点”，那么所有 Pod 就都不能在这个节点上运行，除非，有个别的 Pod 声明自己能“容忍”这个“污点”，即声明了 Toleration，它才可以在这个节点上运行。该 node1 节点上就会增加一个键值对格式的 Taint，即：foo=bar:NoSchedule。其中值里面的 NoSchedule，意味着这个 Taint 只会在调度新 Pod 时产生作用，而不会影响已经在 node1 上运行的 Pod，哪怕它们没有 Toleration。
-
kubectl taint nodes --all node-role.kubernetes.io/master- -- 删除这个 Taint,在“node-role.kubernetes.io/master”这个键后面加上了一个短横线“-”，这个格式就意味着移除所有以“node-role.kubernetes.io/master”为键的 Taint
apiVersion: v1
kind: Pod
...
spec:
tolerations:
- key: "foo"
operator: "Exists"
effect: "NoSchedule"
exec
-
kubectl exec -it test-projected-volume -- /bin/sh -- 进入容器
node
-
kubectl get nodes -- 查看节点状态
-
kubectl describe node master -- 查看这个节点（Node）对象的详细信息、状态和事件（Event）
pod
-
kubectl create -f xxx.yaml -- 创建pod
-
kubectl replace -f xxx.yaml -- 修改pod
-
kubectl apply -f xxx.yaml -- 应用修改或创建
-
kubectl get pods -l app=nginx -- 加上了一个 -l 参数，即获取所有匹配 app: nginx 标签的 Pod
-
kubectl exec -it nginx-deployment-5c678cfb6d-lg9lw -- /bin/bash -- 进入pod
-
kubectl delete -f nginx-deployment.yaml --删除
-
kubectl attach -it nginx -c shell -- 连接进容器
-
kubectl get pod testpodname -o yaml -- 这样的参数，会将指定的 Pod API 对象以 YAML 的方式展示出来。
-
kubectl get pods -w -l app=nginx-- -w 参数，即：Watch 功能，实时查看创建实例的过程
- 生命周期
- Pending。这个状态意味着，Pod 的 YAML 文件已经提交给了 Kubernetes，API 对象已经被创建并保存在 Etcd 当中。但是，这个 Pod 里有些容器因为某种原因而不能被顺利创建。比如，调度不成功。
- Running。这个状态下，Pod 已经调度成功，跟一个具体的节点绑定。它包含的容器都已经创建成功，并且至少有一个正在运行中。
- Succeeded。这个状态意味着，Pod 里的所有容器都正常运行完毕，并且已经退出了。这种情况在运行一次性任务时最为常见。
- Failed。这个状态下，Pod 里至少有一个容器以不正常的状态（非 0 的返回码）退出。这个状态的出现，意味着你得想办法 Debug 这个容器的应用，比如查看 Pod 的 Events 和日志。
- Unknown。这是一个异常状态，意味着 Pod 的状态不能持续地被 kubelet 汇报给 kube-apiserver，这很有可能是主从节点（Master 和 Kubelet）间的通信出现了问题。
secrets
- kubectl get secrets -- 获取到secrets
-
scale -- 水平扩展与收缩
-
kubectl scale deployment nginx-deployment --replicas=4 -- 将nginx-deployment的 ReplicaSet 的个数改为4
-
kubectl rollout status deployment/nginx-deployment -- 实时查看 Deployment 对象的状态变化
edit -- 滚动更新
-
kubectl edit deployment/nginx-deployment -- kubectl edit 指令，会帮你直接打开 nginx-deployment 的 API 对象。然后，你就可以修改这里的 Pod 模板
- 修改了 Deployment 里的 Pod 定义之后，Deployment Controller 会使用这个修改后的 Pod 模板，创建一个新的 ReplicaSet，这个新的 ReplicSet 的初始 Pod 副本数是：0。
-
kubectl set image deployment/nginx-deployment nginx=nginx:1.91 -- 滚动升级镜像
-
kubectl rollout undo deployment/nginx-deployment -- 因为镜像不存在等原因，“滚动更新”被触发后，会立刻报错并停止。这时候使用 roollout undo及能把整个 Deployment 回滚到上一个版本
-
kubectl rollout history deployment/nginx-deployment 查看每次 Deployment 变更对应的版本
-
kubectl rollout undo deployment/nginx-deployment --to-revision=2 在 kubectl rollout undo 命令行最后，加上要回滚到的指定版本的版本号,回滚到指定版本。
-
kubectl rollout pause deployment/nginx-deployment -- 让这个 Deployment 进入了一个“暂停”状态,接下来，你就可以随意使用 kubectl edit 或者 kubectl set image 指令，修改这个 Deployment 的内容,我们对 Deployment 的所有修改，都不会触发新的“滚动更新”，也不会创建新的 ReplicaSet。
-
kubectl rollout resume deploy/nginx-deployment -- 对 Deployment 修改操作都完成之后，只需要再执行一条 kubectl rollout resume 指令，就可以把这个 Deployment“恢复”回来，在 kubectl rollout pause 指令之后的这段时间里，我们对 Deployment 进行的所有修改，最后只会触发一次“滚动更新”。
- 每执行一次扩展升级操作都会产生一个RS，即使我们用pause和resume控制了 ReplicaSet 的生成数量，随着应用版本的不断增加，Kubernetes 中还是会为同一个 Deployment 保存很多不同的 ReplicaSet。那么，我们又该如何控制这些“历史”ReplicaSet 的数量呢？很简单，Deployment 对象有一个字段，叫作 spec.revisionHistoryLimit，就是 Kubernetes 为 Deployment 保留的“历史版本”个数。所以，如果把它设置为 0，你就再也不能做回滚操作了。
