【云原生】k8s管理工具--Kubectl（二）

指尖_流逝的年华

已于 2023-05-17 21:01:17 修改

阅读量689

点赞数 1

文章标签： kubernetes 云原生 docker

于 2023-05-17 10:14:29 首次发布

本文链接：https://blog.csdn.net/m0_73865971/article/details/130717855

版权

文章详细介绍了如何使用Kubectl管理Kubernetes集群，包括项目生命周期的各个阶段，如创建Deployment、发布Service、更新应用版本、回滚操作，以及负载均衡和删除资源。特别强调了Service在Pod动态IP和负载均衡中的作用，以及如何进行滚动更新和金丝雀发布等DevOps实践。

摘要由CSDN通过智能技术生成

k8s管理工具--Kubectl（二）

一、项目生命周期

1、项目生命周期

创建–>发布–>更新–>回滚–>删除

2、创建kubectl run命令

创建并运行一个或多个容器镜像
创建一个deployment或job来管理容器
kubectl run --help查看使用帮助

启动nginx实例，暴露容器端口80，设置副本数3

[root@master01 ~]#kubectl create deployment nginx --image=nginx:1.14 --port=80 --replicas=3

在这里插入图片描述

3、发布kubectl expose命令

将资源暴露为新的Service

为Deployment的nginx创建Service，并通过Service的80端口转发至容器的80端口上，Service的名称为nginx-service，类型为NodePort。

[root@master01 ~]#kubectl expose deployment nginx --port=80 --target-port=80 --name=nginx-service --type=NodePort

在这里插入图片描述

（1） Service的作用

Kubernetes之所以需要Service，一方面是因为Pod的IP不是固定的（Pod可能会重建），另一方面是因为一组Pod实例之间总会有负载均衡的需求。
Service通过Label Selector实现的对一组的Pod的访问。
对于容器应用而言，Kubernetes提供了基于VIP（虚拟IP）的网桥的方式访问Service，再由Service重定向到相应的Pod。

（2）Service的类型

ClusterIP:提供一个集群内部的虚拟IP以供Pod访问（Service默认类型）
NodePort:在每个Node上打开一个端口以供外部访问，Kubernetes将会在每个Node上打开一个端口并且每个Node的端口都是一样的，通过NodeIP:NodePort的方式
LoadBalancer:通过外部的负载均衡器来访问，通常在云平台部署LoadBalancer还需要额外的费用。

（3）查看Pod网络状态详细信息和Service暴露端口

在这里插入图片描述

（4）查看关联后端的节点

在这里插入图片描述

（5）查看service的描述信息

在这里插入图片描述

（6）查看日志

在这里插入图片描述

二、更新kubectl set

1、获取修改模板

在这里插入图片描述

2、查看当前nginx版本

在这里插入图片描述

3、将nginx版本更新为1.15

在这里插入图片描述

注：更新规则可通过“kubetl describe deployment nginx”的“RollingUpdateStrategy”查看，默认配置为“25% max unavailable, 25% max surge”，即按照25%的比例进行滚动更新。
在这里插入图片描述

三、回滚kubectl rollout

对资源进行回滚

kubectl rollout --help查看使用帮助

1、查看历史版本

在这里插入图片描述

2、执行回滚到上一个版本

在这里插入图片描述

3、执行回滚到指定版本

在这里插入图片描述

4、检查回滚状态

在这里插入图片描述

四、实现负载均衡

1、首先在node1 node2节点安装ipvsadm

[root@node01 ~]# yum install ipvsadm.x86_64 -y
[root@node02 ~]#yum install ipvsadm.x86_64  -y

2、在master01节点分别在3个pod内写入网页文件

在这里插入图片描述

五、删除kubectl delete

1、删除副本控制器

在这里插入图片描述

2、删除service

在这里插入图片描述

六、金丝雀发布

Deployment控制器支持自定义控制更新过程中的滚动节奏，如“暂停(pause)”或“继续(resume)”更新操作。比如等待第一批新的Pod资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧的版本。然后，再筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新，否则立即回滚更新操作。这就是所谓的金丝雀发布。

蓝绿发布：是指在生产环境中同时部署两个版本的应用程序，一个是当前正在使用的稳定版本（蓝色），
另一个是新版本（绿色）。新版本在生产环境中进行测试，直到它被确认为稳定可靠后，再将流量逐渐切换到新版本上。这种发布方式可以保证系统的高可用性和稳定性。就是两套设备进行新旧版本的切换，用户毫无感知业务稳定。缺点：要消耗2倍的资源成本特别高。

滚动发布：是指在生产环境中逐步推出新版本，将新版本逐步扩展到整个系统。这种发布方式可以逐步发现和解决问题，降低风险，并且可以确保系统一直处于可用状态。安装比例一部分一部分滚动更新，k8s默认的更新机制，无法创建一定比例的新pod，再删除一定旧的pod。

灰度发布：是一种软件发布策略，它是在生产环境中逐步将新版本的应用程序发布给一小部分用户，以便测试新版本的功能和性能，以及发现和解决潜在的问题。这种发布方式可以减少风险，因为只有一小部分用户会受到影响，同时也可以获得反馈和数据来帮助改进应用程序。一旦新版本被确认为稳定可靠，就可以逐步将其推出到整个系统中。先更新一部分pod，然后暂停更新，安排一小部分用户的流量去访问这部分行的pod，当测试没问题再扩大测试比例。