k8s的deployment应用
Kubernetes 通过各种 Controller 来管理 Pod 的生命周期。为了满足不同业务场景，Kubernetes 开发了 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等多种 Controller。我们首先学习最常用的 Deployment。
运行一个deployment
[root@k8s-master k8s]# kubectl run nginx-deployment --image=nginx:1.79 --replicas=2 kubectl run --generator=deployment/apps.v1beta1 is DEPRECATED and will be removed in a future version. Use kubectl create instead. deployment.apps/nginx-deployment created
[root@k8s-master k8s]# kubectl get deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 2 2 2 2 3m17s
[root@k8s-master k8s]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
nginx-deployment-5fd98dbf5f-w94g4 1/1 Running 0 3m55s 10.244.2.7 k8s-node1 <none>
nginx-deployment-5fd98dbf5f-x5jt5 1/1 Running 0 3m55s 10.244.1.7 k8s-node2 <none>
部署一个deployment名称叫 nginx-deployment 镜像是nginx:1.79 2个副本
查看详细信息
通过kubectl describe deployment 查看该deployment详细信息
这个对象 nginx-deployment-5fd98dbf5f 2个副本被创建了 来自deployment-controller
查看pod
发觉这两个pod的前缀都是 nginx-deployment-5fd98dbf5f 不同的是后面的5位随机数
查看pod的详细信息
通过查看pod的详细信息，可以看到 控制管理器是 replicasset，事件（Events）记录了 pod的创建过程，如果创建失败可以从事件中查找原因
创建过程
1、kubectl创建deployment
2、deployment创建Replcasset
3、根据Replicaset创建pod
命名方式
replicas的命名方式 ：deployment名称+随机数
pod的命名方式：replicas名称+随机数
k8s资源应用的自由伸缩Scale（up/down）
伸缩（Scale Up/Down）是指在线增加或减少 Pod 的副本数。
1.增加副本
Deployment nginx-deployment初始是两个副本。
[root@k8s-master k8s]# kubectl apply -f nginx.yaml deployment.extensions/nginx-deployment created [root@k8s-master k8s]# kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE nginx-deployment-57f56449d9-8b9xp 1/1 Running 0 16s 10.244.2.11 k8s-node1 <none> nginx-deployment-57f56449d9-lnxlb 1/1 Running 0 16s 10.244.1.11 k8s-node2 <none>
现在将配置文件中原先replicas为2 改为5 pod将会怎么分布
[root@k8s-master k8s]# kubectl apply -f nginx.yaml deployment.extensions/nginx-deployment configured
2.master节点工作负载选择
这里由于我将master节点去除了污点，所以他既是管理节点也是工作节点。
下面的命令就是去除master节点污点的命令
kubectl taint node k8s-master node-role.kubernetes.io/master-
如果不想让master节点参与到工作负载
kubectl taint node k8s-master node-role.kubernetes.io/master="":NoSchedule
删除deployment 重新执行
[root@k8s-master k8s]# kubectl delete -f nginx.yaml deployment.extensions "nginx-deployment" deleted
3.减少副本
接下来修改配置文件，将副本数减少为 3 个，重新执行 kubectl apply：
可以看到两个副本被删除，最终保留了 3 个副本。
k8s的故障切换（failover）
当前3个节点的状态都为ready
当前node1有两个pod node2有1个pod
现在将node1关机会有怎样的现象
ping 分布在node1节点的pod地址已经ping不通。
在node1节点上的pod状态都变为unknow，并重新在node2上开启两个pod维持副本数始终为3，实现了fail over。
当 k8s-node1 恢复后，Unknown 的 Pod 会被删除，不过已经运行的 Pod 不会重新调度回 k8s-node1。（也就是说是非抢占式的）
pod的状态 Unkown状态 变为 Terminating 状态 最后这些pod会消失。
删除deployment
[root@k8s-master k8s]# kubectl delete -f nginx.yaml deployment.extensions "nginx-deployment" deleted
k8s通过label来控制pod的位置
默认情况下，scheduler会将pod调度到所有可用的Node，不过有些情况我们希望将 Pod 部署到指定的 Node，比如将有大量磁盘 I/O 的 Pod 部署到配置了 SSD 的 Node；或者 Pod 需要 GPU，需要运行在配置了 GPU 的节点上。
kubernetes通过label来实现这个功能
label 是 key-value 对，各种资源都可以设置 label，灵活添加各种自定义属性。比如执行如下命令标注 k8s-node1 是配置了 SSD 的节点
首先我们给k8s-node1节点打上一个ssd的标签
kubectl label node k8s-node1 disktype=ssd
通过 kubectl get node --show-labels
disktype=ssd 已经成功添加到 k8s-node1，除了 disktype，Node 还有几个 Kubernetes 自己维护的 label。
有了自定义的disktype=ssd 这个标签，只需要在配置文件中定义 nodeselector 为这个自定义标签，就可以指定pod在k8s-node1中运行
部署deployment验证
全部 6 个副本都运行在 k8s-node1 上，符合我们的预期。
要删除 label disktype，执行如下命令：
kubectl label node k8s-node1 disktype-
node/k8s-node1 labeled
不过删除标签 并不会重新部署，所以pod依旧是在k8s-node1上。
要想让k8s-node2也参与到工作负载，则必须删掉当前的deployment，并删除或注释掉配置文件中的 nodeSelector配置。
我们看到之前的pod会被全部删除掉，并重新调度到不同的k8s节点上