目录
一、陈述式资源管理方法
二、基本信息查看
2.1 基本信息查看格式
2.2 查看master节点组件状态
2.3 查看命名空间
2.4 创建/查看命名空间
2.5 删除(重启)命名空间/pod
2.6 查看资源的详细信息
2.7 创建副本控制器来启动Pod
2.8 查看指定命名空间中的pod信息
2.9 跨主机登录容器
2.10 强制删除pod
2.11 扩容/缩容
2.12 删除副本控制器
2.13 查看service所对应的端点
三、项目的生命周期结合陈述式管理方法
3.1 项目的生命周期过程
3.2 创建nginx实例(创建项目)
3.3 发布项目--kubectl expose命令
3.4 Kubernetes中的service
① service的作用
② service的type类型
③ service与pod的端口
3.5 更新项目--kubectl set 命令
3.6 回滚操作--kubectl rollout 命令
3.7 删除项目(删除控制器、service资源)
四、项目的发布方式
4.1 项目发布的方式分类
4.2 蓝绿发布
4.3 红黑发布
4.4 灰度发布(金丝雀发布)
① 灰度发布的概念及特点
② 金丝雀发布示例
一、陈述式资源管理方法
-
kubernetes集群管理集群资源的唯一入口是通过相应的方法调用apiserver的接口
-
kubectl 是官方的CLI命令行工具,用于与apiserver 进行通信,将用户在命令行输入的命令,组织并转化为apiserver能识别的信息,进而实现管理k8s 各种资源的一种有效途径
-
kubectl 的命令大全
- kubectl --help
- k8s中文文档: docs.kubernetes.org.cn/683.html
-
对资源的增、删、查操作比较方便,但对改的操作就不容易了
#查看版本信息 kubectl version 复制代码
#查看资源对象简写(缩写)
kubectl api-resources
复制代码
#查看集群信息(查看K8S集群的控制平面即master节点)
kubectl cluster-info
复制代码
#配置kubect1自动补全:将下方内容放入到/etc/bashrc文件中
source <(kubectl completion bash)
#配置完成后使用su命令切换一次shell环境
复制代码
#在node节点上查看相关日志
journalctl -u kubelet -f
复制代码
二、基本信息查看
2.1 基本信息查看格式
kubectl get <resource> [-o wide|jason|yaml] [-n namespace]
#获取资源的相关信息
-n 指定命名空间,不使用该选项指定,则默认查看default命名空间
-o 指定输出格式
resource可以是具体的资源名称,如pod nginx-xxxx;也可以是资源类型,如pod或all(all仅展示几种核心资源,并不完整)
-all-namespace或-A:用于表示所有命名空间
-l app:仅显示标签为app的资源
-l app-nginx:仅显示包含app标签,并且值为nginx的资源
复制代码
2.2 查看master节点组件状态
kubectl get componentstatuses
kubectl get cs
#以上两条命令均可以实现查看master节点组件的健康状态
复制代码
2.3 查看命名空间
kubectl get namespaces
kubectl get ns
#以上两条命令均可以实现查看命名空间
#命名空间的作用:用于允许不同命名空间的相同类型的资源重名
复制代码
#查看default命名空间的所有资源
kubectl get all [-n default]
复制代码
2.4 创建/查看命名空间
kubectl create ns <命名空间名称> #创建命名空间
kubectl get ns <命名空间名称> #查看命名空间
复制代码
2.5 删除(重启)命名空间/pod
kubectl delete ns <命名空间>
#删除指定命名空间,此命令慎用,防止删除该命名空间下方所有的业务资源
kubectl delete pod <pod名称> -n <pod所属命名空间>
#删除指定的pod
#若删除的pod归控制器进行管理,控制器会在删除原有pod后拉取一个新的pod,则需要删除控制器后方能实现删除pod的效果
复制代码
2.6 查看资源的详细信息
kubectl describe deployments.apps nginx-test -n kube-public
#指定命名空间为kube-public,查看该命名空间下名为nginx-test的副本控制器资源的详细信息
复制代码
kubectl describe pods nginx-test-795d659f45-bw7qz -n kube-public
#查看kube-public这个资源类型下的指定pod的详细信息
#若pod的状态为非Running状态,可以通过此命令查看pod创建失败的相关原因
复制代码
2.7 创建副本控制器来启动Pod
kubectl create deployment <指定副本控制器名称> --image=<指定需要创建的容器基于的镜像> -n <指定命名空间> [--replicas=<数字>]
#创建一个指定名称的副本控制器资源,并指定该容器基于的镜像与容器所属的命名空间
#--replicas选项用于设置容器的副本数(不加该选项默认副本数为1)
复制代码
2.8 查看指定命名空间中的pod信息
kubectl get pods -n kube-public
#查看命名空间kube-public下的pod信息
复制代码
2.9 跨主机登录容器
kubectl exec -it <容器名称> bash -n <命名空间名称> [-c 容器名称] <指定shell环境> [-- 命令内容]
#kubectl exec可以用于跨主机登录容器,而docker exec只能在容器所在的宿主机上进行登录
#想要在外部实现容器内部的命令执行命令,则在命令最后方加入[-- 命令内容]
kubectl exec -it nginx-test-795d659f45-bw7qz bash -n kube-public
#进入命名空间为kube-public下的容器名称为nginx-test-795d659f45-bw7qz的容器,以bash的shell环境进入
复制代码
2.10 强制删除pod
#若pod无法删除,并且总是处于terminate状态,则要强行删除pod
kubectl delete pod <pod名称> -n <命名空间> --force --grace-period=0
#--grace-period选项表示过度存活期,默认为30s,在删除pod之前允许pod慢慢终止在该pod上运行的容器进程,从而优雅退出,0表示立即终止pod
复制代码
2.11 扩容/缩容
#扩容示例
kubectl scale <deployment|statefulset> nginx-test --replicas=3 -n kube-public
#只有deployment和statefulset两个副本控制器可以设置调整副本数量
复制代码
#缩容示例
kubectl scale <deployment|statefulset> nginx-test --replicas=1 -n kube-public
复制代码
#查看副本个数
kubectl get rs -A
复制代码
2.12 删除副本控制器
kubectl delete deployments.apps <副本控制器名称> -n <指定命名空间>
#删除指定命名空间下的指定副本控制器
复制代码
2.13 查看service所对应的端点
#以下两种方式均可查看到service所对应的端口信息
kubectl describe svc <service名称>
#查看service资源的详细信息
kubectl get endpoints
#查看service所关联的podIP以及所对应的端口号
复制代码
三、项目的生命周期结合陈述式管理方法
3.1 项目的生命周期过程
- 项目的生命周期过程主要分为以下几个步骤
- 创建
- 发布
- 更新
- 回滚
- 删除
3.2 创建nginx实例(创建项目)
#启动nginx实例,暴露容器端口80,设置副本数为3
kubectl create deployment nginx-test --image=nginx:1.14 --port=80 --replicas=3
复制代码
3.3 发布项目--kubectl expose命令
#将资源暴露为新的service
kubectl expose deployment nginx-test --port=80 --target-port=80 --name=nginx-service --type=NodePort
#为deployment的nginx-test创建service,并通过service的80端口转发至容器的80端口上,service的名称为nginx-service,类型为NodePort
复制代码
3.4 Kubernetes中的service
① service的作用
- Kubernetes之所以需要service,一方面是因为pod的IP不是固定的(Pod可能会重建),另一方面则是因为一组Pod实例之间总会有负载均衡的需求。
- Service通过Label Selector 实现的对一组的Pod的访问。
- 对于容器应用而言,Kubernetes 提供了基于VIP (虚拟IP)的网桥的方式访问 Service, 再由Service 重定向到相应的Pod。
② service的type类型
- ClusterIP:默认的service资源的类型,提供clusterIP供K8S集群内部的虚拟IP以供Pod访问
- NodePort:在每个Node节点上开启一个端口,K8S集群将会在每个Node节点上打开一个端口并且每个Node的端口都是一样的,内外的用户都可以通过Node节点的IP和NodePort(即NodeIP:NodePort)的方式访问到service。
- 每个端口只能是一种服务,端口范围只能是30000-32767。
- LoadBalancer:通过设置LoadBalancer映射到云服务商提供的LoadBalancer地址。这种用法仅用于在公有云服务提供商的云平台上设置service的场景。通过外部的负载均衡器来访问,通常在云平台部署LoadBalancer还需要额外的费用。
- ExternalName:相当于给一个域名做别名,Pod可以通过service访问集群外部的资源
③ service与pod的端口
-
service端口
- port: service的ClusterIP所使用的端口
- nodePort:NodePort类型的service所定义的在每个Node节点上开启的端口(默认端口范围:30000-32767)
- targetPort:以上port或者nodeport,所要转发到的后端Pod的容器所暴露的端口
-
pod端口
- containerPort:后端Pod的容器所使用的端口(跟targetPort保持一致)
K8S集群内部访问流向:http://ClusterIP:port -->> PodIP:containerPort
K8S集群外部访问流向:http://NodeIP:NodePort -->> PodIP:containerPort
3.5 更新项目--kubectl set 命令
kubectl set image deployment nginx-test nginx=nginx:1.16
#将deployment副本控制器nginx-test的镜像进行更新,将nginx的版本更新为1.16
#开启另一个master节点的终端进行监听pod状态
kubectl get pods -w #该命令可以持续监控pod容器的状态
复制代码
由上方图片可以看到,我们在更新pod(项目时),会先创建一个pod容器,等到新创建的pod容器正常运行后,会对原来的容器进行删除的操作,并且后续再创建一个新的容器,再创建的容器正常运行后,会对原来的其他容器(相当于第二个容器)进行删除的操作,按照此方式循环至所有pod全部重新创建更新完毕,这个更新方式名为滚动更新(按一定的比例进行创建新的pod容器,在新创建的pod容器成功运行后,再按一定比例删除原有的容器)
3.6 回滚操作--kubectl rollout 命令
kubectl rollout history deployment nginx-test
#查看rollout的历史记录
复制代码
#回滚到上一版本
kubectl rollout undo deployment nginx-test
#将控制器nginx-test回滚到上一版本
#回滚结束后,原版本序号1会变为当前版本,也就是3,原序号1版本会消失
#再次使用kubectl rollout history 命令将看到以下内容
deployment.apps/nginx-test
REVISION CHANGE-CAUSE
2 <none> #nginx版本1.16版本
3 <none> #nginx版本1.14版本,原序号1版本由于回滚,会变成新版本序号3
#开启第二个master节点终端进行pod的跟踪查看
kubectl get pods -w
复制代码
#查看回滚是否成功
kubectl rollout status deployment nginx-test
#若在回滚时,使用此命令,可以记录回滚的状态
复制代码
#指定回滚的序号
kubectl rollout undo deployment nginx-test --to-revision=2
#指定恢复到回滚序号为2的版本
#不添加参数--to-revision= ,将默认恢复到上一版本
复制代码
3.7 删除项目(删除控制器、service资源)
#删除控制器
kubectl delete deployments.apps nginx-test
#删除名为nginx-test的控制器
#删除service资源
#kubectl delete svc nginx-service
#删除名为nginx-service的service资源
复制代码
四、项目的发布方式
4.1 项目发布的方式分类
- 在项目中常用的几种发布方式为以下几种
- 蓝绿发布
- 红黑发布
- 滚动发布
- 灰度发布(金丝雀发布)
4.2 蓝绿发布
-
概念定义:
- 蓝绿发布是一种以最小的停机时间做服务升级的策略。需要维护的两个版本的环境分别称为 “蓝环境” 和 “绿环境”。一般当前生产流量指向环境为绿环境,而在蓝环境上部署新版本,短时间内作为测试环境。
-
发布流程:
- 首先将一半的服务流量从负载均衡列表中移除,并且更新服务版本,验证新版本没有问题后,将生产流量指向蓝环境,然后对于老版本的绿环境进行版本升级,最后将所有服务流量加回负载均衡。
- 蓝绿发布的特点
- 升级过程无需停机,用户感知小
- 升级过程一半资源提供服务
- 升级/回滚速度快
- 如果出了问题,影响面较广
4.3 红黑发布
-
概念定义:
- 与蓝绿发布类似,红黑发布也是通过两个环境完成软件版本的升级,将当前生产流量指向的环境称为红环境,新版本环境称为黑环境。
-
发布流程:
- 需申请新资源用于部署黑环境,在黑环境部署新版本的服务;黑环境部署完成后,一次性将生产流量指向黑环境;释放红环境的资源。
-
红黑发布的特点
- 升级过程无需停机,用户感知小
- 短时间内需要使用双倍资源
-
与蓝绿发布相比,红黑发布充分利用了云计算的弹性伸缩的优势,实现:
- 简化发布流程
- 避免在升级的过程中,由于只有一半资源提供服务,而导致的系统过载问题
4.4 灰度发布(金丝雀发布)
① 灰度发布的概念及特点
-
概念定义:
- 灰度发布属于增量发布,新老版本同时为用户提供服务。灰度发布的主要目的是保证系统的可用性。每一次的线上变更都无法保证系统 100% 的无 bug,所以变更后要在线上小范围验证,等没问题再全面放开。而金丝雀发布是灰度发布的一种实现。
- 金丝雀发布由来:以前矿工开矿,在下矿洞前需要检查下方是否有毒气,矿工们先会放一只金丝雀进去探是否有毒气体,看金丝雀能否活下来。
-
发布流程:
- 在现有环境中部署少量服务的新版本(金丝雀),部署完成后,对线上流量进行监测,如果没有问题就对老版本服务进行全量升级。
- 灰度发布的特点
- 用户体验影响小,灰度发布过程出现问题影响范围较小
- 新版本功能逐步发布,可以逐步评估新版服务性能、稳定性和健康状态
- 发布自动化程度不够,发布期间可能引发服务中断
② 金丝雀发布示例
#创建副本控制器nginx-test,并设置副本为10个
kubectl create deployment nginx-test --image=nginx:1.14 --replicas=10
#进行端口的暴露
kubectl expose deployment nginx-test --port=80 --target-port=80
复制代码
#开启master节点的另一个终端,进行pod的跟踪
kubectl get pods -w
#原终端进行副本控制器nginx-test的版本升级,将pod的镜像中的nginx版本升级为1.16版本,并且在升级完第一批pod后,立即停止升级的过程
kubectl set image deployment nginx-test nginx=nginx:1.16 && kubectl rollout pause deployment nginx-test
复制代码
使用curl -I 命令访问容器IP,查看nginx服务版本号信息
#若经过测试,新版本pod所提供服务无异常,我们继续后续的其他pod的更新内容
kubectl rollout resume deployment nginx-test
#设置副本控制器继续后续更新
#使用curl -I命令对ClusterIP进行访问,验证是否存在其他版本的pod
curl -I 10.103.160.63
复制代码