开发者学堂课程【云原生实践公开课：第2步生产环境上 K8s 前，需要注意哪些问题】学习笔记，与课程紧密联系，让用户快速学习知识
课程地址：https://developer.aliyun.com/learning/course/698/detail/12267
第2步 生产环境上 K8s 前，需要注意哪些问题
基础篇:5步上手 K8s
- 第1步︰如何创建及部署应用
- 第2步:上 K8 s应用到生产之前有哪些注意事项
- 第3步:Kubernetes 集群的监控与日志
- 第4步:关于 K8s 集群的弹性伸缩问题
- 第5步∶怎样升级一个 Kubernetes 集群
内容介绍：
一、 课程介绍
二、 生产集群与应用部署
三、 资源的声明
四、 优雅上下线
五、 集群级生产准备介绍
一、 课程介绍
1. 应用级别生产 ready
资源声明
优雅上下线
2. 集群级别生产 ready
监控体系
日志体系
微服务体系
安全体系等
二、 生产集群与应用部署—集群创建
1. 集群创建
- Minikube不具备生产环境使用的能力
- 直接创建生产集群—阿里云托管 Kubernetes
打开阿里云的容器服务，创建标准的专有集群
集群名称：open-classl
地域：华北2(北京)
Kubernetes版本：1.16.9-aliyun.1
容器运行时：Docker 19.03.5
专有网络：(vpc-
虚拟交换机：switch_az_h
网络插件：Flannel
配置SNAT：为专有网络配置SNAT
公网访问：打开
安全组：自动创建企业级安全组
付费类型: 按量付费
Master 实例数量: 3
实力规格：高主频通用型hfg6
操作系统：默认
密码：********
选择配套组件，可以选默认的。之后勾选同意协议。
集群创建过程为10到15分钟之间。
使用集群
在集群的详情中有连接信息，连接集群的凭证，保存到本地，创建自己的环境。
- 通过控制台创建集群
2. 生产集群与应用部署—应用部署
按照上一节课程里面的步骤来进行部署︰
(1） 生产环境的 mysql、redis 等数据库不建议放在 K8s 里面，就目前行业的程度来说，这种存有业务数据比较危险的存储应用，没有一个很成熟的管理体系来做，就目前的程度来说还不够成熟。提前构建对应实例，并通过 external 类型的 svc 来指向对应实例。
数据初始化脚本: https://github.comlwonderflow/gin-vue-admin/blob/master/server/db/qmplus.sql
Mysql：变成 eternal name 类型的 service，然后还叫 mysql，然后，内容实际上是指向一个现有的 mysql 实例。
Redis：在这里面基本上处于一个缓存的状态，所以保留它原来的样子。
Web-server：这个部分主要改革的就是对应的数据库的这些参数，其他部分，基本没有动弹。
使用Kubectl apply，先将Mysql 做apply处理，得到一个servers，然后把Redis 做apply处理，得到另一个servers以及一的deploy。之后把Web-server 做apply处理，得到一的svc，此时的svc还处于pending状态，即在等到一个external-ip，等待之后得到一个external-ip，之后到登录页看该应用是否正常即可。
(2） 应用的部署与之前保持一致
$ k apply -f https://raw.githubusercontent.com/wonderflow/gin-vue-admin/master/k8s/web-server.yaml
三、应用-资源声明
资源的声明是什么。
- 很多学员在使用 K8S 的时候，想做到更高的资源率的目标，但讲师优先保证系
统的稳定性。问题：QS 是 QS 里面本身的一个服务等级的保障等级的一个描述。当 request 小于 limit，或者不设置的时，QS 等级是 Burstable。
只有 request 和 limit 全设置，等级才是 Guaranteed。然后，对应的 Pod 来说，当你的 Container 全都是 Guaranteed 的时候，Pod 等级才是 Guaranteed，如果说，其中有两个都是 Burstable，Pod 等级是 best effort，其他的，这个 POD 等级都是 boss 的。等级生效就是当业务高峰来的时候，POD 的压力就会变大的，，POD 压力变大， node 的压力就会变大, 压力变大的时候，node 就会按照从上到下的设计去驱逐POD。
- 如果核心应用不设置request和limit，等级会变成Burstable，当业务高峰来
时，就可能第一个时间被驱逐掉。
- 驱逐：把这个POD原理进行重启。
- 重启相当于在业务高峰期的时候，把核心重启一次，本身服务的压力变得更
大。
- 建议：在刚开始的时候，对这些应用不太熟悉的时候，把request limit全都设置
起来，而且要设置成request等于limit，这样可以把POD等级推到Guaranteed类型。这种类级别，基本上是不会被取掉，达到一个稳定运行的这个状态。
- 一段时间后，对运行的业务、程序熟悉了，可以选非核心业务，设置
request limit的一些差异，进行一些超慢，进而拿到整个集群高资源使用率等，这个实际上就是对应的自然生命的一种方式。
四、应用-优雅上下线
1. 为什么在容器时代更重要?
- 更多的弹性：云原生就是要充分发挥云的弹性。实际上要做到尽可能多的，随
着业务的峰值和谷值，对 photoshop 进行分解，这样就带来了更多的 pod 的增删。
- 声明式的 API：比如声明需要三个副本，副本数高于这个会减少，少于这个会
增
加，这个过程都是自动化的。如果说上下限不优雅的话，每一个 pod 的牺牲和消亡过程中，都会对用户造成影响，在容器这个时间，会放大这个效果。
2. 优雅上线分为优雅上线，优雅下线
- 优雅上线：Liveness 即失败重启和 readiness 即失败摘除服务。
- 优雅下线: 服务端负载均衡和客户端负载均衡两部分。
服务端负载均衡类似于 K8s 、svc 模式：当一个 pod 正在运行的时候，收到要该pod 销毁的这个消息，接收消息之后。会先从对应 service 的 end point 列表里面，把这个 point 对应 endpoint 摘除，然后，把这个信息同步到所有的kubeproxy 里面去。就不会有新的流量，再往这一台 pod 上进行转发。之后，把pod 之前进入的流量处理完成。
客户端负载均衡类似于 dubbo、springcloud 模式：收到一个 pop 要销毁的消息时，大部分的动作需要手动来完成，首先要服务注销，也就是反注册。我先从 K8s double 的体系里，把本身的 pod 对应的IP摘掉，阻止新流量进来，之后把现有的流量优雅地执行完之后，做一个 Q 的信号，把这个 code 真正的销毁掉。
3.非优雅下线
- 注释掉优雅上下线的配置
kubectl apply -f web-server.yaml
kubectl get svc
k scale --replicas 3 deployment web-server
- 给应用压力
ab -c 2 -n 5000 http://182.92 8888/admin/#/login
- 在此过程中缩小副本数，模拟下线或者是滚动升级中pod下线的过程
k scale --replicas 1 deployment web-server
- 压力端断开
实验：
使用压力压一遍服务，用 ab-C 射程为2-射程5000-，然后，我们的 url，直接是是之前的 last year 的 url。
简单的压测，每500次打印一下，然后，看到里面没有对personal进行设置。然后，设置 requests 和 limits，把脚本保留注释掉，先压一个非优雅下线。
模拟过程，首先，在 open-class 输入 k scale –replicas 3 depioym，观察效果，同时给压力时，把副本3调到1，给完压力就会立刻断开。
4. 优雅下线
- 打开优雅上下线的配置
kubectl apply -f web-server.yaml
k scale --replicas 3 deployment web-server
- 给应用压力
ab -c 2 -n 5000 http://182.92 8888/admi
- 在此过程中缩小副本数，模拟下线或者是滚动升级中 pod 下线的过程
k scale --replicas 1 deployment web-server
- 压力端正常压测
打开 perstop 对应的脚本打开并更新，把脚本数设置为3，等待3个 pod 准备完成，压力数值与之前操作一致，把副本3调到1，等待程序执行完成，未观察到突然断开，为进行巩固，把副本数调到3，等待程序结束，输入脚本并设为1，按照之前的步骤重复一遍。即为优雅下线。
五、集群级生产准备介绍
集群级别的生产 ready
微服务体系
日志体系
监控体系
安全体系
弹性体系
- K8s集群是微服务的，需加入微服务体系，包括你的微服务中心、服务的限流降
级等等能力，都需要在微服务体系里面构建。
- 日志体系需要可以做到收集日志、分析日志、分析制作高级等等。
- 监控体系，要从上到下做每一层的监控，然后，要从应用到业务，从数据到入
口，都是要完成的。
- 安全体系，弹性体系，以及AI相关的体系，都要去完成对应的设计。
