一、k8s陈述资源管理方法的说明
1.1 管理k8s核心资源的三种基本方法
陈述式资源管理方法
主要依赖命令行工具kubectl进行管理
优点
可以满足90%以上的使用场景
对资源的增、删、查操作比较容易
缺点
命令冗长，复杂，难以记忆
特定场景下，无法实现管理需求
对资源的修改麻烦，需要patch来使用json串更改。
声明式资源管理方法
主要依赖统一资源配置清单进行管理
GUI式资源管理方法
主要依赖图形化操作界面进行管理
k8s中文文档 ：
Kubernetes kubectl 命令表 _ Kubernetes(K8S)中文文档_Kubernetes中文社区
陈述式资源管理方法：
1.kubernetes 集群管理集群资源的唯一入口是通过相应的方法调用 apiserver 的接口
2.kubectl 是官方的CLI命令行工具，用于与 apiserver 进行通信，将用户在命令行输入的命令，组织并转化为
apiserver 能识别的信息，进而实现管理 k8s 各种资源的一种有效途径
3.kubectl 的命令大全
kubectl --help
k8s中文文档：http://docs.kubernetes.org.cn/683.html
4.对资源的增、删、查操作比较方便，但对改的操作就不容易了1.2 kubectl命令行工具 的说明
二进制安装的 k8s , kubectl 工具没有自动补全功能(其他方式安装的未验证),可以使用以下方式开启命令自动补全
vim /root/.bashrc
——在最后一行添加——
source <(kubectl completion bash)
bash
二、k8s集群中的基本信息查看
2.1 查看版本信息
kubectl version
2.2 查看资源对象简写
kubectl api-resources
2.3 查看集群信息
kubectl cluster-info
2.4 node节点查看日志
journalctl -u kubelet -f
2.5 基本信息查看
kubectl get <resource> [-o wide|json|yaml] [-n namespace]
获取资源的相关信息，-n 指定命令空间，-o 指定输出格式
resource可以是具体资源名称，如pod nginx-xxx；也可以是资源类型，如pod；或者all(仅展示几种核心资源，并不完整)
--all-namespaces 或 -A ：表示显示所有命令空间，
--show-labels ：显示所有标签
-l app ：仅显示标签为app的资源
-l app=nginx ：仅显示包含app标签，且值为nginx的资源
2.6 查看 master 节点状态
kubectl get componentstatuses
kubectl get cs
2.7 查看命令空间
kubectl get namespace
kubectl get ns
命令空间的作用：用于允许不同 命令空间 的 相同类型 的资源 重名的
也就是说 一个命名空间中不能出现两个相同的资源名称，两个命名空间中可以出现相同的资源名称。主要作用有：1、实现资源的逻辑隔离，2、基于命名空间来分配权限，3、设置资源配额
总之，命名空间为Kubernetes提供了一种在单一集群内划分多个虚拟集群的能力，提高了资源组织的灵活性和管理效率。
2.8 查看default命名空间的所有资源
kubectl get all [-n default]
-n ：指定命名空间
三、k8s资源的基本管理
3.1 创建命名空间xwx
kubectl create ns xwx
kubectl get ns
3.2 删除命名空间
kubectl delete namespace xwx
kubectl get ns
3.3 在命名空间中创建副本控制器来启动Pod
kubectl create deployment nginx-web --image=nginx -n kube-public
kubectl get pod -n kube-public
在命名空间kube-public 创建副本控制器（deployment）来启动Pod（nginx-web）
kubectl run nginx-ji --image=nginx -n wang
kubectl get pod -n wang
kubectl run ： 用于创建一个自主式/静态的 pod
使用kubectl创建的pod 进行删除或者在运行时挂了不会自动创建一个新的pod来替代。
kubectl create deployment：用于创建 deployment 控制器管理的pod
使用kubectl create deployment创建的pod 无论是挂了还是我们手动删除它都会创建一个新的pod，如果我们指定了副本数量那么就可以保证pod的运行数量始终与副本数一致。
3.4 描述某个资源的详细信息
kubectl describe deployment nginx-web -n kube-public
kubectl describe pod nginx-web-5bf45d88df-l2hrd -n kube-public
3.5 查看命名空间kube-public 中的pod 信息
kubectl get pods -n kube-public
3.6 跨主机登录容器
kubectl exec -it nginx-web-5bf45d88df-l2hrd bash -n kube-public
与docker不同的是
docker exec 只能在容器所在主机上登录，kubectl exec可以跨主机登录容器
3.7 pod资源的删除 （重启）
kubectl delete pod nginx-web-5bf45d88df-l2hrd -n kube-public
3.8 强行删除pod
kubectl delete pod <pod-name> -n <namespace> --force --grace-period=0
#grace-period表示过渡存活期，默认30s，在删除pod之前允许POD慢慢终止其上的容器进程，从而优雅退出，0表示立即终止pod
3.9 对相同的pod数进行增加，减少
kubectl scale deployment nginx-web --replicas=3 -n kube-public # 扩容
kubectl scale deployment nginx-web --replicas=1 -n kube-public # 缩容
3.10 删除副本控制器
kubectl delete deployment nginx-web -n kube-public
kubectl delete deployment/nginx-web -n kube-public
四、项目的生命周期管理
对于一个k8s的项目，它的声明周期大致可以分为以下几个步骤：
创建 --> 发布 --> 更新 --> 回滚 --> 删除
4.1 创建项目
创建并运行一个或多个容器镜像
创建一个deployment或job来管理容器
kubectl run --help 或者 kubectl run -h
//启动nginx 实例，暴露容器端口80，设置副本数3
kubectl create deployment nginx --image=nginx:1.14 --port=80 --replicas=3
kubectl get pods
kubectl get all
4.2 发布项目
●将资源暴露为新的 Service。
kubectl expose --help//为deployment的nginx创建service，并通过Service的80端口转发至容器的80端口上，Service的名称为nginx-service，类型为NodePort
kubectl expose deployment nginx --port=80 --target-port=80 --name=nginx-service --type=NodePort
查看pod网络状态详细信息和 Service暴露的端口
kubectl get pods,svc -o wide
Kubernetes 之所以需要 Service，一方面是因为 Pod 的 IP 不是固定的（Pod可能会重建），另一方面则
是因为一组 Pod 实例之间总会有负载均衡的需求。
Service 通过 Label Selector 实现的对一组的 Pod 的访问。
对于容器应用而言，Kubernetes 提供了基于 VIP（虚拟IP） 的网桥的方式访问 Service，再由 Service
重定向到相应的 Pod。
service 的 type 类型：
●ClusterIP：提供一个集群内部的虚拟IP以供Pod访问（service默认类型)
●NodePort：在每个Node上打开一个端口以供外部访问，Kubernetes将会在每个Node上打开一个端口并且每个
Node的端口都是一样的，通过 NodeIp:NodePort 的方式Kubernetes集群外部的程序可以访问Service。
每个端口只能是一种服务，端口范围只能是 30000-32767。
●LoadBalancer：通过设置LoadBalancer映射到云服务商提供的LoadBalancer地址。这种用法仅用于在公有
云服务提供商的云平台上设置Service的场景。通过外部的负载均衡器来访问，通常在云平台部署LoadBalancer还需要额外的费用。
在service提交后，Kubernetes就会调用CloudProvider在公有云上为你创建一个负载均衡服务，并且把被代
理的Pod的IP地址配置给负载均衡服务做后端。
嫁接云（一般不用，直接搭建在公有云和私有云上）
●externalName：将service名称映射到一个DNS域名上，相当于DNS服务的CNAME记录，用于让Pod去访问集群
外部的资源，它本身没有绑定任何的资源。 tgc.benet.com www.benet.com
headless clusterIP 无头模式 名称
扩展
●port
port 是 k8s 集群内部访问service的端口，即通过 clusterIP: port 可以从 Pod 所在的 Node 上访问到 service
●nodePort
nodePort 是外部访问 k8s 集群中 service 的端口，通过 nodeIP: nodePort 可以从外部访问到某个 service。
●targetPort
targetPort 是 Pod 的端口，从 port 或 nodePort 来的流量经过 kube-proxy 反向代理负载均衡转发到后端 Pod 的 targetPort 上，最后进入容器。
●containerPort
containerPort 是 Pod 内部容器的端口，targetPort 映射到 containerPort。
查看 service 关联后端的节点
kubectl get endpoints
查看 service 的描述信息
kubectl describe svc nginx
在 node01 节点上操作，查看负载均衡端口
yum install ipvsadm -y
ipvsadm -Ln
在 node02 节点上操作，同样方式查看负载均衡端口
yum install ipvsadm -y
ipvsadm -Ln
在master01主节点分别在3个pod内写入网页文件
kubectl exec -it nginx-d9d8cf5c7-224d2 bash
echo "<h1>this is test1</h1>" > /usr/share/nginx/html/index.html
kubectl exec -it nginx-d9d8cf5c7-m9sgj bash
echo "<h1>this is test2</h1>"/usr/share/nginx/html/index.html
kubectl exec -it nginx-d9d8cf5c7-n4rq8 bash
echo "<h1>this is test3</h1>" >/usr/share/nginx/html/index.html浏览器访问clusterip和nodeport
curl 10.96.94.138:80
curl 192.168.80.7:31331
curl 192.168.80.11:31331
curl 192.168.80.12:31331
在master01操作 查看访问日志
kubectl logs nginx-d9d8cf5c7-224d2
kubectl logs nginx-d9d8cf5c7-m9sgj
kubectl logs nginx-d9d8cf5c7-n4rq8
4.3 更新项目
查看资源模板的使用
kubectl set --help
//获取修改模板
kubectl set image --help
Examples:
# Set a deployment's nginx container image to 'nginx:1.9.1', and its busybox container image to 'busybox'.
kubectl set image deployment/nginx busybox=busybox nginx=nginx:1.9.1
查看当前 nginx 的版本号
curl -I 192.168.80.7:31331
curl -I 192.168.80.11:31331
curl -I 192.168.80.12:31331
将nginx 版本更新为 1.18 版本
kubectl set image deployment/nginx nginx=nginx:1.18
处于动态监听 pod 状态，由于使用的是滚动更新方式，所以会先生成一个新的pod，然后删除一个旧的pod，往后依次类推
kubectl get pods -w
再看更新好后的 Pod 的 ip 会改变
kubectl get pods -o wide
kubectl get svc -o wide
再看 nginx 的版本号
4.4 项目的回滚
每一个的项目版本更新都会经过测试，并不是所有的新版本都会优于旧版版，为了防止更新后，发现新版的服务优化不如旧版本，此时后悔。所以k8s在项目中设置了回滚功能
对资源进行回滚管理
kubectl rollout --help
查看历史回滚点
kubectl rollout history deployment/nginx
我们有两种回滚方法：
//执行回滚到上一个版本
kubectl rollout undo deployment/nginx//执行回滚到指定版本
kubectl rollout undo deployment/nginx --to-revision=1
进行回滚
4.5 删除项目
1.删除副本控制器
kubectl delete deployment.apps/nginx
2.删除service资源
kubectl delete service/nginx-service
kubectl get all
五、三种常用的项目发布方式
应用程序升级面临最大挑战是新旧业务切换，将软件从测试的最后阶段带到生产环境，同时要保证系统不间断提供服务。而最为常见三种发布方式分别为：蓝绿发布，灰度发布和滚动发布。
三种发布方式的最终目的都是为了减小或避免对应用项目更新时，对客户使用的影响。
5.1 蓝绿发布
首先将所有的应用服务集群为蓝绿两组，首先将绿组的集群从负载均衡中移除，蓝组则继续对用户提供服务。此时移除的绿组进行服务的升级，等升级完毕后，再从新将绿组接入到负载均衡中为用户提供服务。
再把蓝组进行移除，进行服务升级，升级完毕后再接入到负载均衡的集群中。此时整个项目集群得进行升级完毕，我们将此称为蓝绿发布
特点
- 如果出问题，影响范围较大；
- 发布策略简单；
- 用户无感知，平滑过渡；
- 升级/回滚速度快。
缺点
- 需要准备正常业务使用资源的两倍以上服务器，防止升级期间单组无法承载业务突发；
- 短时间内浪费一定资源成本；
- 基础设施无改动，增大升级稳定性。
蓝绿发布在早期物理服务器时代，还是比较昂贵的，由于云计算普及，成本也大大降低。
5.2 灰度发布
灰度发布又叫金丝雀发布，灰度是指在黑与白之间，能够平滑过渡的一种发布方式（为什么叫金丝雀发布（Canary）？以前，矿工开矿，在下矿洞前需要检查下方是否有毒气，矿工们先会放一只金丝雀进去探是否有有毒气体，看金丝雀能否活下来。）
该过程类似于游戏中的体验服，首先会让一部分用户进行使用测试，如果没什么问题后，会逐步面积推广，彻底替代旧的版本
以下示意图可描述灰度发布的大致流程：先切分20%的流量到新版本，若表现正常，逐步增加流量占比，继续测试新版本表现。若新版本一直很稳定，那么将所有流量都切分到新版本，并下线老版本。
切分20%的流量到新版本后，新版本出现异常，则快速将流量切回老版本。
图片转自灰度发布、蓝绿部署、金丝雀都是啥？ - 知乎 (zhihu.com)
特点
-
保证整体系统稳定性，在初始灰度的时候就可以发现、调整问题，影响范围可控；
-
新功能逐步评估性能，稳定性和健康状况，如果出问题影响范围很小，相对用户体验也少；
-
用户无感知，平滑过渡。
-
自动化要求高
5.3 滚动发布
滚动发布就是刚刚我们在k8s中使用的项目服务更新方式。滚动发布是指每次只升级一个或多个服务，升级完成后加入生产环境，不断执行这个过程，直到集群中的全部旧版本升级新版本。
特点
-
用户无感知，平滑过渡；
-
节约资源。
-
部署时间慢，取决于每阶段更新时间；
-
发布策略较复杂；
-
无法确定OK的环境，不易回滚。
六、金丝雀发布方式的运用
Deployment控制器支持自定义控制更新过程中的滚动节奏，如“暂停(pause)”或“继续(resume)”更新操作。
比如等待第一批新的Pod资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧的版本。然后，再筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新，否则立即回滚更新操作。这就是所谓的金丝雀发布。
进行金丝雀的更新方式
更新deployment的版本，并配置暂停deployment
kubectl create deployment nginx --image=nginx:1.14 --port=80 --replicas=3
kubectl expose deployment nginx --port=80 --target-port=80 --name=nginx-service --type=NodePort#先创建资源并创建3个副本
kubectl set image deployment nginx nginx=nginx:1.18 && kubectl rollout pause deployment nginxkubectl set image deployment/nginx nginx=nginx:1.18 && kubectl rollout pause deployment nginx
#更新并暂停
kubectl rollout status deployment nginx #观察更新状态
监控更新的过程
可以看到已经新增了一个资源，但是并未按照预期的状态去删除一个旧的资源，就是因为使用了pause暂停命令
kubectl get pods,svc -o wide
kubectl get pods -w
curl -I 192.168.73.106:31589
继续更新
确保更新的pod没问题了，继续更新
kubectl rollout resume deployment/nginx
如果对第二次或则往后的更新仍然保留测试的想法，可以采用再更新一部分暂停的方式：
kubectl rollout resume deployment nginx && kubectl rollout pause deployment nginx
总结
1.查看版本信息
kubectl version
2.查看资源对象简写
kubectl api-resources
3.查看集群信息
kubectl cluster-info
4.配置kubectl自动补全
source <(kubectl completion bash)
5.node节点查看日志
journalctl -u kubelet -f
查看
kubectl get 查看资源类型 -owide 输出详细信息也可以输出yamlison
pod
service
namespaCe #所有的命名空间的下的资源--all-namespace或-A
all
创建
kubectl create 控制器
kubectl run 自助式
kubectl scale --replicas=
kubectl run ： 用于创建一个自主式/静态的 pod
kubectl create deployment：用于创建 deployment 控制器管理的pod
发布，创建 service
kubectl expose
更新
kubectl set image
回滚
kubectl rollout undo
删除
kubectl delete 控制器|pod ...
查看资源状态
kubectl get ... -o wide [-l 标签] [--show-lables] [-n ...] [-A] -w
查看详细信息
kubectl describe
查看日志
kubectl logs
进入pod容器
kubectl exec -it
查看资源缩写
kubectl api-resource
总结 生命周期
创建 ---> 发布 ---> 更新 ---> 回滚 ---> 删除
创建 ：
kubectl create <资源类型> <资源名称> --image=<镜像名称> --port=端口 --replicas=副本数
发布：
kubectl expose <资源类型> <资源名称> --port= --target-port= --type=ClusterIP/NodePort
更新：
kubectl set image <资源类型> <资源名称> <容器名>=<镜像名 标签版本>
回滚：
kubectl rollout undo <资源类型> <资源名称> 默认是回滚到上一个版本状态
--to-revision= 回滚到制定版本
删除: kubectl delete <资源类型> <资源名称>
蓝绿发布
需要准备两套设备 进行新旧版本的切换
好处：用户无感知 业务稳定
滚动发布
按照比例 每次更新一部分，k8s的默认更新机制
会先创建更新的那一部分 ，创建完成后把旧的那一部分删除 接着把更新的加入服务
灰度发布（金丝雀）
先更新一部分pod ，然后再暂停更新
接着 安排一小部分用户流量去访问更新的pod 来进行测试 ，当测试没问题后再扩大比例 直到全部更新完成为止。
灰度发布/金丝雀发布
kubectl set image ... && kubectl rollout pause（暂停操作） ...
如果验证没有问题
kubectl rollout resume（恢复操作）
滚动更新
先更新一部分（个数|比例默认25%）pod资源，更新完毕后再删除一部分资源
905
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
