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的默认更新方式。
面试题：
三个
说灰布发布：
一般情况下滚动
特殊情况：灰布发布。
