0


k8s的陈述式资源管理

k8s的陈述式资源管理

命令行

kubectl命令行工具

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

对资源的增,删,查比较方便,对改不不太好

缺点:

命令比较冗长,复杂,难记

声明式:

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

GUI:图形化工具的管理

1 kubectl命令的详解 查看 部署 产看pod的情况(详细的信息,日志,发布和回滚)

kubectl get cs #查看master节点的状态(基本信息查看)

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

kubectl get ns #查看当前集群所有的命名空间

kubectl get pod -n kube-system #要查看指定命令空间内的pod需要加-n 命令空间的名称

kubectl get pod -o wide #查看默认命名空间内pod的详细信息

#kubectl get node #查询节点的信息和状态

kubectl get node -o wide #查看node节点的详细信息。

kubectl describe pod +pod的名称 #查看已经部署好的pod的详细信息。

kubectl create ns xxx 创建命名空间

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

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

不是基于控制器创建,会被直接删除。(比如 run 创建的)

deployment的部署pod:

陈述式部署:命令行

声明式: yaml文件部署

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

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

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

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

上述的功能必须是基于deployment创建的服务才可以。绝大多岁的POD都是使用deployment创建的。

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

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

一般都是依赖环境和重要组件,一般也不会去对

kubectl exec -it nginx-dn-6d6cd9c7c5-j7ffr bash #远程进入节点容器。

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

kubectl delete pod nginx-dn-6d6cd9c7c5-j7ffr --force --grace-period=o

快速结束pod的创建(主要是用于结束卡在销毁状态的pod.)

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

#对deployment创建的pod进行扩缩容

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

kubectl scale deployment nginx-dn --replicas=3 扩容

kubectl scale deployment nginx-dn --replicas=1 缩容

service的类型:

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

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

nodeip:nodeport

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

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

--port=80service集群的端口

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

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

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

ExternalName: DNS映射,给service分配一个域名,通过域名来访问后端pod资源。ExternalName的service类型,不能提供负载均衡,必须要设置一个LoadBalancer的地址才可以实现。

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

项目的生命周期:

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

更新版本:

加标签:

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

回到1 这个还原点

查看当前命名空间里的所有信息的详细信息

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

蓝绿发布
金丝雀发布(灰度发布)
滚动发布

应用程序升级,面临的最大的问题是新旧业务之间的切换。立项………定稿……需求发布…….……开发----测试.……发布,测试之后上线,再完美也会有问题。为了不让发生的问题影响所有用户,上述的三种发布方式。

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

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

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

蓝绿发布的特点:

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

2、发布策略简单

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

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

缺点:

1 在发布升级的过程之中,只有一部分集群在对外提供服务,可能会是集群的负载能力下降,响应变慢,需要注意给集群增加负载能力()

2 短时间内可能会浪费—定的资源成本。

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

deployment控制器创建的服务,才可以使用这种发布方式。滚动更新,暂停。发布的过程中,暂时停止,只有一部分的pod先升级,其他的pod还是处于老的版本。只有一部分用户可以访问新的版本,绝大数用户还是在老版本。确定无问题之后,再把剩下的老版本,升级成新的版本,把暂停取消,继续发布。如果有问题,可以立刻回滚。暂停不是回滚,一旦取消暂停只能全部升级完毕之后,再回滚。

更新一个pod就暂停:

继续更新:

灰度发布:

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

2、方便问题,及时解决。影响范围比较小。

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

4、发布策略比较复杂。

5、不易回滚,必须要全部发布成功之后才能回滚。

滚动更新:

deployment的默认就是滚动更新。

标签: linux docker kubernetes

本文转载自: https://blog.csdn.net/wyh20030130/article/details/135503923
版权归原作者 喝点维C 所有, 如有侵权,请联系我们删除。

“k8s的陈述式资源管理”的评论:

还没有评论