k8s —— deployment应用（转发）

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节点上

k8s —— deployment应用 （转发）