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