k8s 陈述式资源管理

2024-01-02 19:44:26

k8s 陈述式资源管理

命令行:kubectl命令行工具

优点:90%以上的场景都可以满足

对资源的增,删,查比较方便,对改不是很友好

缺点:

命令比较冗长,复杂难记

声明式:

k8s当中的yaml文件来实现资源管理----声明式

GUI:图形化工具的管理。

1,kubectl命令的详解:

查:

部署:

查看pod的情况(详细信息,日志,发布和回滚)

Kubernetes kubectl 命令表 _ Kubernetes(K8S)中文文档_Kubernetes中文社区 kubu命令大全的网站

查看版本信息

kubectl version

Client Version 是指 kubectl 命令行工具的版本

Server Version 是指 Kubernetes 集群的版本

查看所有资源的简写(有的有简写,有的只有全称)

kubectl api-resources

查看k8s的集群信息

kubectl cluster-info

自动补齐的命令

source <(kubectl completion bash)

通过get的命令

基本信息查看

查看master节点的状态

kubectl get cs

查看node节点的状态,

查看默认命名空间内的pod信息

kubectl get pod

查看当前集群所有的命名空间

kubectl get ns

查看指定命名空间的pod信息

kubectl get pod -n chen

要查看指定命名空间内的pod需要加-n命名空间的名称

查看默认命名空间内pod的详细情况

kubectl get pod -o wide

练习:查看chen命名看见没的详细信息。

kubectl get pod -o wide -n chen

查询节点的信息和状态

查看node节点的详细信息。

kubectl get node -o wide

查看pod的详细信息。

查看已经部署好的pod的详细信息。

kubectl describe pod nginx-6799fc88d8-lrvkt

练习:

-n指定命名空间

如何查看pod的日志:

静态:

kubectl logs nginx-6799fc88d8-lrvkt

动态:

kubectl logs -f nginx-6799fc88d8-lrvkt

也默认的命名空间

查看指定命名空间

创建命名空间

kubectl create ns chen

删除命名空间

kubectl delete ns chen

删除pod

kubectl delete pod nginx-6799fc88d8-lrvkt

并没有删除,只是重启了

先声明动作: create delete get desvribe

对象: ns pod service

对象的名称guoqi nginx- 6799fc88d8 - f9c8g

nginx1 nginx2 -n命名空间。

对pod进行部署

deployment的部署pod:

陈述式部署:命令行

声明式:yaml文件进行部署

滚动更新:不是一次性的把所有pod全部不是,而是一个一个来。pod的更新时使用。逐步的引入新的pod。逐步的减少旧的pod。

自我修复:如果有pod节点发送故障,deploment会自动启动新的pod来进行代替

回滚:如果更新有问题,deployment会提供还原点,可以手动还原到未更新的状态。

扩容和缩容:deplayment可以随时调整pod的数量,以适用流量的变化。

上述的功能必须是基于deployment创建的访问才可以。绝大多数的pod都是由deployment创建的。

还有通过daemonsetcj创建的

daemonset:不能通过命令行创建。只能在yaml文件当中定义这种创建方式。

后台运行创建,在每个节点上都创建一个相同方式的,相同版本的容器运行的pod。

一般都是依赖环境和重要组件,一般也不会对执行资源进行操作。

用deployment命令行的方式创建pod

查看通过deployments创建的命名空间:

命名空间内的pod名称不能重复。

在指定命名空间创建pod

kubectl create deployment nginx1 --image=nginx --replicas=3 -n chen

删除pod删不掉。

kubectl delete pod myapp-test-777fc9d77b-2ngdk

删除马上又拉起来一个。

如果是基于deployment方式创建的pod,或者是daemonset方式创建的pod,是由控制器创建的pod。适用delete删除是删不掉的,相当于重启pod。

基于deployment方式创建pod.一 旦删除deployment,基于这个deployment创建的pod都会被删除。慎用

kubectl delete deployments.apps myapp-test

delete用于重启。不是running,基于控制器创建的。

不是基于控制器创建,会被直接删除。

只要是基于控制器创建的,删除要先删除控制器,根据控制器创建的pod就自动删除了。

一般不要动。要先查看,是不是deployment创建。

远程进入节点容器:

进入容器:

kubectl exec -it nginx-6799fc88d8-fz9mp bash

docker的exec只能在本机内部使用,不能跨主机,kubectlexec可以跨主机进入容器。

不同命名空间

kubectl create ns chen

kubectl create deployment nginxcc --image=nginx -n chen

kubectl get pod -n chen

kubectl exec -it nginxcc-98c959b58-5jzrc -n chen bash

快速删除pod中的容器的命令:

kubectl delete pod nginx1-b97c459f7-r8xrq --force --grace-period=0

grace-period:表示过度的存活期,默认是30秒。可以让pod优雅的结束容器内的进程,然后退出pod =0,表示立刻停止pod。必须要加--force

但是pod还在

主要是用于结束卡在销毁状态的pod.一般用delete就行了,但要等一会。

如何对deployment创建的pod进行扩容和缩容

扩容

kubectl scale deployment nginx1 --replicas=3

缩容:

kubectl scale deployment nginx1 --replicas=1

创建pod时并没有指定副本数,后续也可以对他的副本数进行修改

只有基于deployment才能扩缩容。

如何把服务的service进行发布:

ubectl create deployment nginx --image=nginx:1.10 --replicas=3

如何定义他的service

service的类型:

查看默认命名空间的service

删除:

kubectl delete svc nginx-service

查看不同命名空间的service

kubectl get svc -n chen

type类型:

ClusterIP:创建service的默认类型,通过一个集群内部的虚拟ip地址,这是service的默认类型,通过这个虚拟ip可以服务pod的资源,无法对外提供访问。

NodePort:会在每一个node节点上都开放一个相同的端口。外部可以通过node的本机ip+端口,访问pod资源,集群外部访问service资源的一种方式。四层代理方式。

nodeip:nodeport

随机指派,也可以指定 30000-32767

基于deployment创建的pod,可以使用的方式;

kubectl expose deployment nginx --port=88 --target-port=80 --name=nginx-service --type=NodePort

--port=80 service集群的端口

--target port=80 pod内部容器的端口

类型是NodePort

10.96.232.240集群内部的ip地址,外部是不可以访问这个ip地址的。

80:对应的是内部的service的端口

32436:和内部的service的80端口做映射。

pod内部容器的端口是固定的(可以进去改)不能随机指定。

--port是service和容器内部的端口做映射。

NodePort的端口是随机生成的。范围是: 30000-32767

访问地址,进行负载均衡。

一个是内部

负载均衡靠的就是kube-proxy

可以改外端访问端口

范围只能是30000-32767

LoadBalancer:如果service的类型设定为loadBalancer,映射地址(云平台提供LoadBalancer的地址)这种用法仅用于公有云服务供应商在云平台上设置service的场景。外部来访问。实现负载均衡。LoadBalancer这个地址是要付费的。

创建好了service,指定类型为LoadBalancer。会给你提供一个地址来带代理pod内部的ip地址。

只能等代地址分配。

内部可以访问。

ExternalName:DNS映射,给service分配一个域名,提供域名来访问后端pod资源。ExternalName的service类型,不能提供负载均衡,

必须要设置一个LoadBalancer地址池。

改一个

还要做映射,不能负载均衡。

更新和回滚以及发布的方式:

项目的生命周期

创建------发布------更新------回滚-----删除

对版本进行更新:

滚动更新:

如何回滚:

查看回滚点:

kubectl rollout history deployment nginx

数字的大小决定了距离上次操作的远近,数字越大,就是你最近的一次操作。

更新时添加标识。

kubectl set image deployment nginx nginx=nginx:1.15 --record

--record 加上

回滚:

kubectl rollout undo deployment nginx --to-revision=1

查看回滚的状态:

kubectl rollout status deployment nginx

动态的查看回滚情况:

kubectl get pod -w

每更新一次都会生成一个还原度

查看当前命名空间内的所有信息。

所有的详细信息。

指定命名空间。

三种常见的项目发布方式:

蓝绿发布

金丝雀发布(灰布发布)

滚动发布

应用程序升级,面临的最大的问题是新旧业务之间的切换。

立项---定稿---需求发布---开发---测试---发布,

测试之后上线,再完美有会有问题。为了不让发送的问题影响所有用户,上述的三种发布方式。

蓝绿发布:

把应用服务集群标记为两个组,蓝组和绿组,先升级蓝组,要把蓝组从负载均衡当中移除,绿组继续提供服务。

蓝组升级完毕,在把绿组从负载均衡当中移除,绿组升级,然后都加入回负载均衡当中去,完成对外服务。

对硬件资源要求很高,但是有了云计算和微服务,现在的成本也大大降低了

蓝绿发布的特点:

1,一旦出现问题,问题的影响范围很大

2,发布策略简单

3,基于现在的云计算和微服务,用户无感知。

4,升级和回滚都比较方便。

缺点:

在发布升级的过程中,只有一部分集群在对外提供服务,可能会使集群的负载能力下降,响应变慢,需要注意给集群增加负载能力(一般来说没什么特殊需要。)

短时间内可能会浪费一定资源成本。

金丝雀发布(灰布发布):

deployment控制器创建的服务,才可以使用这种发布方式。滚动更新,暂停。发布的过程中暂时停止,只有一部分的pod先升级,

其他的pod还是处于老的版本,绝大多数用户还是在老版本。确定无问题之后,在把剩下的老版本,升级成新的版本,把暂停取消,继续发布。如果有问题,可以立即回滚,暂停不是回滚, 一旦取消暂停只能全部升级完毕之后,再回滚。

实验:

查看回滚点:

kubectl rollout history deployment nginx

当前版本:1.21.5

执行这个命令之后会有pod中会有一个容器升级

kubectl set image deployment nginx nginx=nginx:1.24 --record && kubectl rollout pause deployment nginx

正在创建:

kubectl rollout status deployment nginx

查看状态:

一个新的,3个旧的

只有一个是1.24

继续,就全部更新:

kubectl rollout resume deployment nginx

动态的查看创建的状态

kubectl get pod -w

全部都是升级完毕。

查看回滚点:

kubectl rollout history deployment nginx

回滚:

kubectl rollout undo deployment nginx --to-revision=1

灰布发布的特点:

面试时:不要说金丝雀发布。

1,自动化的要求比较高,对运维人员的要求比较高

2,方便问题,即使解决。影响范围比较小。

3,用户无感知,平滑过度。节约资源。

4、发布策略比较复杂。

5、不易回滚,必须要全部发布

滚动更新:

deployment的默认更新方式。

面试题:

三个

说灰布发布:

一般情况下滚动

特殊情况:灰布发布。

文章来源:https://blog.csdn.net/weixin_51694382/article/details/135341176
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。