Kubernetes命令（持续更新）_minute5的专栏文章_微信文章

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 功能，实时查看创建实例的过程

生命周期
1. Pending。这个状态意味着，Pod 的 YAML 文件已经提交给了 Kubernetes，API 对象已经被创建并保存在 Etcd 当中。但是，这个 Pod 里有些容器因为某种原因而不能被顺利创建。比如，调度不成功。
2. Running。这个状态下，Pod 已经调度成功，跟一个具体的节点绑定。它包含的容器都已经创建成功，并且至少有一个正在运行中。
3. Succeeded。这个状态意味着，Pod 里的所有容器都正常运行完毕，并且已经退出了。这种情况在运行一次性任务时最为常见。
4. Failed。这个状态下，Pod 里至少有一个容器以不正常的状态（非 0 的返回码）退出。这个状态的出现，意味着你得想办法 Debug 这个容器的应用，比如查看 Pod 的 Events 和日志。
5. 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，你就再也不能做回滚操作了。