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的默认就是滚动更新。