K8S学习圣经：大白话说K8S底层原理，14W字实现K8S自由

Posted 2023-04-11 疯狂创客圈

文章很长，持续更新，建议收藏起来，慢慢读！疯狂创客圈总目录 博客园版 为您奉上珍贵的学习资源 ：

免费赠送 :《尼恩Java面试宝典》 持续更新+ 史上最全 + 面试必备 2000页+ 面试必备 + 大厂必备 +涨薪必备
免费赠送 :《尼恩技术圣经+高并发系列PDF》 ，帮你 实现技术自由，完成职业升级， 薪酬猛涨！加尼恩免费领
免费赠送 经典图书:《Java高并发核心编程（卷1）加强版》 面试必备 + 大厂必备 +涨薪必备 加尼恩免费领
免费赠送 经典图书:《Java高并发核心编程（卷2）加强版》 面试必备 + 大厂必备 +涨薪必备 加尼恩免费领
免费赠送 经典图书:《Java高并发核心编程（卷3）加强版》 面试必备 + 大厂必备 +涨薪必备 加尼恩免费领

免费赠送 资源宝库： Java 必备 百度网盘资源大合集 价值>10000元 加尼恩领取

---

Kubernets 底层原理和实操 (学习圣经)

Kubernets 简称 k8s，用于自动部署，扩展和管理容器化应用程序的开源系统。也就是能帮我们部署和管理分布式系统。

学习 Kubernets 的相关资料

中文官网：https://kubernetes.io/zh-cn/docs/

官方文档：https://kubernetes.io/zh/docs/home/（推荐）

中文社区：https://www.kubernetes.org.cn/

社区文档：http://docs.kubernetes.org.cn/

Kubernetes API 规约：community/api-conventions.md at master · kubernetes/community (github.com)

Kubernetes kubectl 命令表: http://docs.kubernetes.org.cn/683.html

说在前面：

现在拿到offer超级难，甚至连面试电话，一个都搞不到。

尼恩的技术社群中（50+），很多小伙伴凭借 “左手云原生+右手大数据”的绝活，拿到了offer，并且是非常优质的offer，据说年终奖都足足18个月。

从Java高薪岗位和就业岗位来看，K8S 现在对于 高级工程师， 架构师，越来越重要，下面是一个高薪Java岗位的K8S技能要求：

但是 K8S 又很难。在这里，尼恩从架构师视角出发，基于自己的尼恩Java 架构师知识体系和知识宇宙，对K8S的核心原理做一个宏观的介绍， 一共十二部分， 组成一本《K8S学习圣经》

《K8S学习圣经》 带大家穿透K8S，实现K8S自由，让大家不迷路。

《K8S学习圣经》的组成

• 第一部分：云原生(Cloud Native)的原理与演进
• 第二部分：穿透K8S的8大宏观架构
• 第三部分：最小化K8s环境实操
• 第四部分：Kubernetes 基本概念
• 第五部分：Kubernetes 工作负载
• 第六部分：Kubernetes 的资源控制
• 第七部分: SVC负载均衡底层原理
• 第八部分: Ingress底层原理和实操
• 第九部分： 蓝绿发布、金丝雀发布、滚动发布、A/B测试 实操
• 第十部分： 服务网格Service Mesh 宏观架构模式和实操
• 第十一部分： 使用K8S+Harber 手动部署 Springboot 应用
• 第十二部分： SpringCloud+Jenkins+ K8s Ingress 自动化灰度发布
• 第十三部分： k8s springboot 生产实践（高可用部署、基于qps动态扩缩容、prometheus监控）
• 第十四部分：k8s生产环境容器内部JVM参数配置解析及优化

米饭要一口一口的吃，不能急。

结合《K8S学习圣经》，尼恩从架构师视角出发，左手云原生+右手大数据 +SpringCloud Alibaba 微服务 核心原理做一个宏观的介绍。由于内容确实太多， 所以写多个pdf 电子书：

(1) 《 Docker 学习圣经 》PDF （V1已经完成）

(2) 《 SpringCloud Alibaba 微服务 学习圣经 》PDF （V1已经完成）

(3) 《 K8S 学习圣经 》PDF （coding…）

(4) 《 flink + hbase 学习圣经 》PDF （planning …）

以上学习圣经，并且后续会持续升级，从V1版本一直迭代发布。 就像咱们的《 尼恩 Java 面试宝典 》一样， 已经迭代到V60啦。

40岁老架构师尼恩的掏心窝： 通过一系列的学习圣经，带大家穿透“左手云原生+右手大数据 +SpringCloud Alibaba 微服务“ ，实现技术 自由 ，走向颠覆人生，让大家不迷路。

本PDF 《K8S 学习圣经》完整版PDF的 V1版本，后面会持续迭代和升级。供后面的小伙伴参考，提升大家的 3高 架构、设计、开发水平。

以上学习圣经的 基础知识是 尼恩的 《 高并发三部曲 》，建议在看 学习圣经之前，一定把尼恩的《 Java高并发三部曲 》过一遍，切记，切记。

本书目录

• 学习 Kubernets 的相关资料
• 说在前面：
• 《K8S学习圣经》的组成
• 本书目录
• 第1部分：云原生(Cloud Native)的原理与演进
  • 1、什么是云原生(Cloud Native)？
    • 云原生的四要素：
  • 2、云原生发展历史时间轴
    • 2.1 从微服务到服务网格
    • 2.2 微服务架构的问题
      • 解决方案：
    • 2.3 SideCar 旁车模式（边车模式）
  • 3、2018 年云原生被CNCF重新定义
    • 3.1 服务网格 （Service Mesh）
    • 3.2 不可变基础设施（Immutable Infrastructure）
    • 3.3 声明式API ( declarative APIs)
  • 4、CNCF云原生组织发展和介绍
    • 什么是CNCF
    • CNCF解决了什么问题
    • 介绍几个常用的已经毕业的云原生项目
    • 孵化中的项目
  • 5、从微服务演进到Service Mesh（服务网格）的过程
    • 5.1 单体服务时代
    • 5.2 微服务时代
    • 5.3 服务网格新时期 （service mesh）
  • 6、服务网格（service mesh）原理和价值
    • 什么是服务网格（service mesh）
    • Service Mesh的价值
    • Linkerd
    • istio
    • 国内兴起的服务网格
  • 7、云原生应用和传统应用的区别
  • 8、云原生涉及的核心项目
• 第2部分：穿透K8S的8大宏观架构
  • 尼恩的K8S的独特视角：不是普通的视角
  • K8S的核心价值：带领大家从 容器管理的石器时代，进入工业时代
    • 图0：K8S 的宏观组件架构图
    • 图1：K8S 业务架构图
    • 图2：K8S 元数据架构图
    • 图3：K8S 容器管理流程架构
    • 图4：容器元数据的数据传输架构
    • 图5：容器对外暴露架构图
    • 图6：总的架构图
    • 图7：master 上APIServer 内部架构图
    • 图8：worker上 kubelet内部架构图
  • 学习 云原生+ 微服务的神器
• 第3部分：K8s运行时 实操
  • 什么是minikube
  • minikube 背景
  • Kubernetes集群架构 与minikube架构对比
    • 1、Kubernetes集群架构
    • 2、Minikube架构
  • minikube安装前准备
  • docker安装和环境检查
    • docker 版本要求
    • 关闭虚拟机swap、selinux、firewalld
    • 编辑虚拟机hosts文件
    • 登录阿里云
  • 创建用户，加入docker用户组
    • 让用户minikube获得root权限
  • 安装与启动minikube
    • 软件版本说明
    • 安装minikube
    • 启动minikube
    • 命令清单：血泪的安装史，尼恩用过的 命令list
    • minikube start 参数
    • 示例
      • --vm-driver=kvm2
      • --vm-driver=hyperv
      • --vm-driver=none
  • 解决拉取镜像的问题
    • 错误日志查看
    • Q1：解决minikube拉取镜像速度缓慢的问题
      • 解决 minikube start 过程中拉取镜像慢的问题
    • Q2：基础镜像拉不下来
      • 错误日志查看
      • 基础镜像拉不下来
      • 指定镜像启动
      • 终于开始创建容器，开始启动了
    • Q3：新的问题来了：coredns 镜像找不到
    • Q4：继续下载镜像
    • Q5：使用阿里云代理http://k8s.gcr.io镜像仓库
  • Virtual Box 使用的问题
    • Q1：嵌套虚拟化问题
      • 什么是嵌套 虚拟化特性？
      • 虚拟机启用嵌套VT-x/AMD-V
    • Q2：conntrack依赖
    • Q3：依赖kubectl、kubelet
    • Q4：桥接问题
    • Q5：初始化失败报错，升级内核
    • 启动Dashboard
    • 终于全部启动了
    • 如何从宿主机也就是我们的Windows中访问dashborad呢
    • 直接使用minikube
    • minikube重建
  • docker-compose to minikube
  • 部署minikube 遇到的问题
    • 外部访问问题
    • pull image问题
  • POD 容器的问题
    • K8s的常用命令
    • 查看所有的pod，看看哪些有问题
    • storage-provisioner 的ImagePullBackOff 状态
  • 启动minikube时指定harber仓库
    • minikube 复制证书
    • 进入minikube虚拟机
      • 增加私仓地址配置
      • 重启虚拟机的Docker
      • 测试
  • 命令清单：尼恩用过的 启动 命令清单 （都是血和泪）
  • minikube常用命令
    • 一、基本命令
    • 二、镜像命令
    • 三、配置和管理命令
    • 四、网络和连接命令
    • 五、高级命令
    • 六、疑难解答命令
    • 七、其它命令
  • 启动minikube完整的命令清单
  • Helm 的原理、安装、使用
    • Helm 组件及相关术语
    • Helm 工作原理
    • 安装Helm
• 第4部分：Kubernetes 基本概念
  • 1、基础概念理解
    • K8S集群
    • Node的核心组件
    • Pod
    • Label
    • Deployment
    • Service
    • Addons
    • DNS
    • Web UI (Dashboard)
  • 2、k8s对象（kubernetes Objects）
    • 对象的yaml结构
    • 关于 yaml文件的分割
    • 2.1 一个简单的Kubernetes API 对象
    • 2.1 什么是k8s 资源对象
      • kubernetes 对象必需字段
    • 2.2 kubernetes API的版本
      • 一、查看apiversion 可用版本
      • 二、各种apiVersion的含义
    • 2.3 获取各个属性字段的含义
      • 方式1：从命令行获取方式
      • 方式2：官方 API 文档方式
    • 2.4、管理k8s对象
      • 1、命令式
      • 2、指令性
      • 3、声明式
    • 2.5、对象名称与ID
      • Names
      • UID
    • 2.6 对象规约（Spec）与状态（Status）
      • 对象规约（Spec）与状态（Status）
      • spec 规约
      • status 状态
    • 2.7、名称空间
      • 名称空间的使用参考：
      • 如何访问其他名称空间的东西？
      • 查看名称空间
      • 在执行请求的时设定namespace
      • 设置名称偏好
      • 名称空间与DNS
      • 名称空间的作用
      • 并非所有对象都在命名空间中
    • 2.8 、标签和选择器
    • 2.9、注解annotation
    • 2.8、字段选择器
    • 2.10、认识kubectl 客户端命令
      • kubectl的所有命令参考：
    • 2.11、自动补全
    • 2.12、给idea安装kubernetes插件
      • 1、plugins kubernetes
      • 2、快速生成kubernetes 资源文件模板
      • 3、输入k即可触发自动命令提示
• 第5部分：Kubernetes 工作负载
  • 什么是Workloads?
  • Pod的原理与生命周期
    • 1、什么是Pod
    • 2、Pod使用
    • 3、Pod生命周期
  • “根容器” : Pause 容器
    • Pod中容器也有分类
    • Pod生命周期的 两个阶段
  • Pod的Init 初始化容器 (附Demo)
    • Pod 钩子Hook方法 (附Demo)
    • Pod 健康检查（探针）机制
    • Pod 的状态和重启策略
      • Pod 常见的状态
      • Pod重启策略
      • Pod常见状态转换场景
  • 临时容器：线上排错
    • 使用方法：
    • 通过临时容器查看Java容器log日志
    • 临时容器的参数说明：
    • 使用临时容器进行 dump 转储
      • 基于制作Java Debug 镜像
      • 临时容器不能用jmap、jps而只能用jattach
      • jattach指令集:
    • 临时容器的配置
    • 临时容器的使用场景
  • 静态Pod
    • 如何找到 静态pod 的文件路径
    • 静态Pod实操
    • Pod 资源需求和限制
  • Pod的Probe 探针机制（健康检查机制）
    • Probe 探针 背景
    • K8S 的3种探针
    • livenessProbe和readinessProbe 的区别
      • （1）livenessProbe
      • （2）readinessProbe
      • （3）就绪、存活两种探针的区别
    • 存活探针 (liveness)的三种探测方法
      • exec 方式示例
      • httpGet 方式示例
      • TCP 方式示例
      • 使用命名的端口
    • 就绪探针 (readiness)
      • ReadinessProbe 探针使用示例
    • ReadinessProbe + LivenessProbe 配合使用示例
      • 以上案例中存活探针 参数意思：
      • 以上案例中就绪探针 参数意思：
    • startupProbe探针
      • 1、startupProbe探针介绍
      • 2、startupProbe探针与另两种区别
      • 3、startupProbe探针方法、属性
      • 4、为什么要使用startupProbe、使用场景
• 第6部分：Kubernetes 的资源控制
  • 动态的扩容缩容的重要性
  • 1：Deployment 资源对象
    • Deployment的创建
    • Deployment 资源、replicaset资源、Pod资源 三者之间的关系
    • Deployment 基本操作
      • 副本扩容
      • 副本缩容
    • Deployment 更新机制
      • 准备：升级镜像
      • 在线修改yaml
      • 滚动机制相关的命令
      • 暂停和恢复
      • 回滚策略
        • 记录保留
        • 滚动更新数量
    • 使用Deployment 进行灰度发布
  • 2：副本资源 RC、副本集RS 资源对象
    • RC（Replication Controller）
    • RS（Replication Set）
    • ReplicatSet的三个部分
    • RS扩容缩容
  • 3：DaemonSet 守护集
    • DaemonSet 组成结构详解
    • 调度节点的选择
      • 方式一：nodeSelector方式
      • 方式二：nodeAffinity方式
      • 方式三：podAffinity方式
    • Toleration
  • 4：StatefulSet 有状态集
    • StatefulSet 使用场景
    • StatefulSet的一些限制和要求
    • StatefulSet示例
    • DNS解析
    • StatefulSet 的几个要点
      • （1）pod管理策略（podManagementPolicy）
      • （2）updateStrategy： 更新策略
      • （3）对应的headless service
  • 5：Job 任务、CronJob 定时任务
    • Job 任务
    • 并行 job 示例
    • CronJob 定时任务
      • CronJob示例
  • 6：HPA(Horizontal Pod Autoscaling)水平自动伸缩
    • 收集指标插件
    • Metrics API
    • 前置条件: 开启聚合路由
      • metrics安装方式一：minikube 中启用指标服务器作为插件
      • metrics server安装方式二：手动安装
      • 执行安装和检查
      • 执行安装的命令清单
  • 7：使用HPA对SpringCloud微服务进行自动伸缩
    • autoscale命令
    • Metrics支持的指标
    • 创建hpa、查看hpa、删除hpa
    • HPA扩容实操
    • 基于自定义指标的自动扩容
    • 扩展阅读: GC机制
    • 什么是垃圾回收
  • 什么是OCI、CRI、CNI、CSI
    • OCI、CRI、CNI、CSI、CRD、CNM规范基本概念：
    • 实现OCI、CRI、CNI、CSI组件介绍
      • 1、OCI、CRI组件
      • 2、CNI组件
        • CNI 和 CNM 的对比：
      • 3、CSI组件
    • CRI、OCI的关系
    • CRD是什么
    • CR是什么
    • CRD与CR的关系
    • CRD在API Server中的设计和实现机制
    • 如何创建 CRD？
• 第7部分：SVC负载均衡底层原理
  • Pod的IP 漂移问题
  • service 概念
  • 四大service 类型
  • kubernetes暴露端口的方式
    • 1：集群内部实现访问：Clusterip
    • 2：集群外部方式访问：NodePort
    • 3: LoadBalancer
    • 4: Ingress
  • DNS解析案例
    • 案例
  • SVC 流量分发的底层原理
    • VIP 和 Service 代理
    • 代理模式分类
    • Ⅰ、userspace 代理模式
    • Ⅱ、Iptables 代理模式
    • Ⅲ、ipvs 代理模式
      • ipvs为负载均衡提供算法：
      • ipvs 对比 iptables
    • iptables/netfilter 介绍
      • 1，iptables/netfilter介绍
      • 2，iptables 基础：
      • 3，链的概念：
      • 4，表的概念：
      • 5，数据经过防火墙的流程图：
      • 6，规则：
    • 总结： iptables包含4个表，5个链
  • iptables 在 K8s 中的应用剖析
    • 路由的流程分析:
    • service 的路由分析实例
      • 先看iptables 中的DNAT
      • 再看SNAT
  • 基于客户端地址的会话保持模式的svc负载分发策略
  • k8s集群中service的域名解析、pod的域名解析
    • service的域名
      • 1、创建namespace.yaml文件
      • 2、创建deployment.yaml文件
      • 3、创建service.yaml文件
      • 4、测试
    • 总结
  • 应用持久化存储（PV和PVC）
    • 1、Volume
      • 1.1、emptyDir
      • 1.2、hostPath
      • 1.3、外部存储（以NFS为例）
    • 2、PV与PVC
      • 持久卷的存储插件类型
      • 2.1、Static PV
        • 1）先搭建好NFS服务器（192.168.100.172）
        • 2）创建PV
        • 3）创建PVC
        • 4）创建Pod
      • 2.2、Dynamic PV
        • Dynamic PV属于PV的自动化：
        • 什么是StorageClass
        • 为什么需要StorageClass
        • StorageClass案例
        • 运行原理
• 第8部分：K8S Ingress原理和实操
  • 背景：
    • svc的作用与不足
    • Ingress 的来源
  • Ingress的构成
    • 什么是Ingress Controller？
      • Ingress 资源对象
      • ingress-controller组件
    • nginx-ingress-controller
  • 部署ingress-controller
    • Minikube安装Ingress
    • 手工部署ingress-controller pod及相关资源
    • ingress版本的问题
    • 调整RBAC api-versions 版本
    • 部署 ingress-nginx
    • 配置ingress资源
    • 报错 failed calling webhook
    • 获取 ingress 启动的svc
      • 加上本地的host
    • 测试访问
    • 实操的善后工作
  • k8s ingress的工作原理
    • （1）Ingress Controller 控制器
    • （2） Ingress 资源对象
  • 详解ingress资源
    • ingress规则
    • DefaultBackend
    • 资源后端
    • 路径类型
      • 路径类型示例
    • 路径多重匹配
  • 主机名通配符
  • ingress类
    • 名字空间域的参数
    • 默认ingress类
  • ingress部署的三种模式
    • 模式一：NodePort模式的Service
    • 模式二：DaemonSet+nodeSelector+HostNetwork
    • 模式三：Deployment+LoadBalancer模式的Service
  • 模式一的问题：service暴露服务的问题
  • DaemonSet+HostNetwork+nodeselector 实操
    • nodePort的NAT性能问题
    • 指定nginx-ingress-controller运行的node节点
    • 修改Deployment为Daemonset,指定节点运行，并开启 hostNetwork
    • 启动nginx-ingress-controller
    • 查看pod的IP和端口
    • 配置ingress资源
    • 命令清单
  • 生产环境 LVS+keepalive 做高可用和负载均衡
    • 边缘节点
    • 生产环境可以使用 HA + LB + DaemonSet hostNetwork 架构
  • 四种port底层原理：nodePort、port、targetPort、containerPort 的核心
    • 1、nodePort
    • 2、port
    • 3、targetPort
    • 4、containerPort
  • Ingress 动态域名配置底层原理
    • ingress生产建议
  • ingress总结
  • K8s的常用命令
    • kubectl命令 要求
• 第9部分：蓝绿发布、金丝雀发布、滚动发布、A/B测试 原理和实操
  • 背景：
  • 蓝绿发布、金丝雀发布、滚动发布、A/B测试 核心原理
    • 蓝绿发布（Blue-green Deployments） 核心原理
    • 金丝雀发布（anCanary Releases） 核心原理
    • 滚动发布的 核心原理
    • A/B测试（A/B Testing） 核心原理
  • 蓝绿发布、金丝雀发布、滚动发布实操
    • spring cloud 灰度实操
    • 反向代理网关灰度实操
    • Kubernetes 中的灰度策略
    • Deployment金丝雀部署：按照流量比例
      • step1 ：启动 V1 服务，查看服务是否正确，然后观察一下服务。
      • step2：启动 V2 的服务版本：1 个复本
      • step3：观察 V2 流量正常的情况的话，那么启动 V2 的 2 个复本。
      • step4：删除 V1 的 2 个复本，流量全部到 V2 上。
      • 实操总结
    • Deployment实现滚动发布
      • step1：启动 V1 服务，查看服务是否正确，然后观察一下服务。
      • step2：启动 app-v2-rolling 进行滚动发布
      • step3：观察所有容器版本变为 V2 版本
      • 实操总结
    • Deployment实现蓝绿部署
      • step1 ：启动 V1 服务，查看服务是否正确，然后观察一下服务。
      • step2：启动 V2 的服务版本
      • step3：将版本 1 服务切换到版本 2，观察服务情况
      • patch
      • 实操总结
    • Ingress Annotations实现金丝雀发布
      • Ingress Annotations实现金丝雀发布 实操
    • 华为云的金丝雀发布
    • 参考
• 第10部分：服务网格Service Mesh 宏观架构模式
  • 第1大模式：Sidecar （边车）模式 架构
    • sidecar的（边车）负责的功能
    • sidecar模式好处、坏处
    • 如何解决依赖的复杂性和性能问题呢？
    • 优化之后的sidecar模式优点：
  • 第2大模式：代理模式
  • 服务网格 istio 框架微服务与SpringCloud 对比
    • SpringCloud 和 istio 中间组件的对比
    • 云原生Sidecar分体架构微服务Provider一体架构对比
    • 两大基础组件的对比
  • 角色sidecar 对应到啥组件？
  • 小结：
  • Istio 架构
    • 控制平和数据面
    • Istio 的运转流程
    • （1）Sidecar自动注入：
    • （2）流量拦截：
    • （3）服务发现：
    • （4）负载均衡：
    • （5）流量治理：
    • （6）访问安全：
    • （7）服务遥测：
    • （8）策略执行：
    • （9）外部访问：
  • Istio组件介绍
    • 2.1 Pilot
    • 2.2 Mixer
    • 2.3 Citadel
    • 2.4 Galley
    • 2.5 Sidecar-injector
    • 2.6 Proxy(Envoy)
    • 2.7 Ingress gateway
    • 2.8 其他组件
  • Istio安装
    • 在本地搭建Istio环境
    • Kubernetes集群环境
  • 安装Istio
    • 快速部署Istio
    • 初步感受istio
    • 手动注入
    • 自动注入sidecar
  • istio项目案例：bookinfo
    • 什么是bookinfo
  • sidecar自动注入到微服务
  • 启动bookinfo
  • 通过ingress方式访问
  • 通过istio的ingress gateway访问
    • 确定 Ingress 的 IP 和端口
• 第11部分：使用K8S+Harber 手动部署 SpringCloud 应用
  • 启动minikube时指定私有仓库
  • minikube 复制证书
  • 进入minikube虚拟机
    • 增加私仓地址配置
    • 重启虚拟机的Docker
    • 测试
  • 完整的命令清单
  • Docker构建镜像后通过K8S部署
  • 镜像与容器关联
    • Docker构建镜像并且推送Harber
      • 前提：停止或者重启 Harbor
    • 创建Dockerfile
    • 镜像构建：将本地镜像打包
      • docker build语法
    • 镜像打tag：镜像添加版本号
    • 镜像推送：镜像推送到远程仓库
    • 测试
    • 完整的命令清单
  • k8s的Secrets：
    • 创建一个k8s的Secrets：
    • 1.Secret对象配置过程
    • 2.容器镜像拉取的两种策略
      • 2.1 ImagePullPolicy
      • 2.2 ImgaePullSecrets
  • k8s的configMap对象
    • Pod可以通过三种方式来使用ConfigMap，分别为：
    • configMap是什么
      • 1.单pod使用configmap示例图
      • 2.多pod使用configmap示例图
    • configmap来配置环境变量
      • 步骤1：创建configmap
        • 方法1：yaml档来设定configmap
        • 方法1：命令行设定configmap
      • 步骤3：使用configmap来配置
  • docker-compose to minikube
    • 简单案例
    • 实操案例
      • 参考的原始的docker-compose编排文件
    • 设置env环境变量
    • k8s向etc/hosts里添加内容
      • k8s默认被重写/etc/hosts
      • Dockerfile里的配置被覆盖
      • 将你的配置写到k8s yml里
    • Kubernetes volume hostPath explained with examples
      • hostPath
      • Example
  • 部署和创建服务
    • ImagePullBackOff错误排查
      • 解决问题：停止后重启 Harbor
    • CrashLoopBackOff 错误
      • 坑1：镜像拉取是ok，但是依赖包没有
      • 坑2：java 进程异常结束了
      • 坑3：minikube是套娃虚拟机，套娃里边没有映射目录，远程复制
      • 坑4：检查域名和环境变量
    • 解决问题有感
  • 完整的命令清单
  • openresty 镜像
    • dockerfile
• 第12部分：SpringCloud+Jenkins+ K8s Ingress 自动化灰度发布
  • 如何进行SpringCloud+Jenkins+ K8s Ingress 灰度发布？
  • 回顾Nginx-ingress 架构和原理
  • 灰度实操之前的准备
    • 部署和测试 stable 版本的 deployment 和 svc
    • 部署和测试 canary版本 的 deployment 和 svc
  • 基于用户的灰度场景
    • 接下来，开始基于 用户的灰度实操
  • 基于权重的灰度场景
    • 基于权重的 Canary 规则
    • 基于权重的发布实操
  • 如何进行自动化灰度？
  • jenkins安装和pipeline 流水线的使用
    • 下载和启动jenkins
    • 登录jenkins
    • 使用pipeline插件
      • 安装Pipeline 插件
    • pipeline 的hello world
    • pipeline 语法介绍
    • Jenkins插件SSH Pipeline Steps
      • sshCommand 在远程节点上执行给定的命令并响应输出
      • sshGet 从远程主机获取文件或目录
      • sshPut 将文件或目录放入远程主机
      • sshRemove 删除远程主机上的文件或目录
      • sshScript 在远程节点上执行给定的脚本(文件)并响应输出
      • 结合 withCredentials 从 Jenkins 凭证存储中读取私钥
    • pipeline支持的指令
  • ingress 灰度发布流水线设计
    • CICD流水线预览
    • step1：自动化的制品发布
      • 1、克隆 springboot代码项目到本地
      • 2、maven构建springboot代码项目
      • 3、构建docker镜像
      • 4、推送docker镜像到harber上，完成制品发布
    • step2：生产环境进行 A/B 测试
      • AB测试原理：
    • step3：生产环境进行 A/B 测试
    • step4：生产环境进行版本正式切换
  • 最后总结一下
• 第13部分：springboot 基于 qps 动态扩缩容
  • 步骤
  • 1、springboot安装prometheus依赖并获取metric
  • 2、安装prometheus operator 实现 kubernetes的监控指标
    • 2.1 helm安装prometheus operator、prometheus adapter（custom metric）
    • 2.2 kubernetes的监控指标
    • Prometheus Operator 极简配置Prometheus 监控
      • Operator
      • Operator介绍
      • Prometheus Operator vs. kube-prometheus vs. community helm chart
    • Prometheus Operator CRD介绍
    • 命令清单: 安装的Prometheus
    • 查看安装后的CRD、svc、pods：
  • 从外部访问promethus
    • 访问Prometheus
    • 访问Alertmanager
    • 访问Grafana
  • 移除kube-prometheus
    • 解决prometheus-adapter创建失败的问题
      • 查看 安装文件
    • 解决kube-state-metrics 创建失败的问题
    • 解决namespace 删除不来
  • 配置prometheus -adapter获取应用qps
  • prometheus采集到的metrics适配给kubernetes用
    • K8s中 kubernetes的监控指标分为两种：
    • Metrics-Server 简介
    • prometheus-adpater
  • 获取 metrics 定制化指标
    • checkout 仓库 k8s-prometheus-adapter
    • 脚本进行部署 k8s-prometheus-adapter
      • 请求metrics.k8s.io的 api
      • 直接访问 api 的方式来测试部署是否 ok
    • 排错 no matches for kind "APIService" in version "apiregistration.k8s.io/v1
      • 查看版本 kubectl api-versions
    • Prometheus adapter 的文件介绍
    • 配置文件
    • resource metrics API
    • 命令清单
  • 自定义alertmanager的PrometheusRule
  • 配置prometheus及adapter获取应用qps
    • 启动springboot应用
    • 添加自定义指标
    • 架构图原理
    • 添加一个自定义监控的步骤
    • 部署prometheus-adapter
  • custom-metrics-server 规则配置
    • 指标发现和配置展示(Metrics Discovery and Presentation Configuration)
    • http_requests（每秒请求数QPS)监控指标
    • 坑： /metrics 路径的定制化修改
    • 查询与 http_requests 相关的指标
  • 自定义metric rules、配置HPA
    • 配置自定义prometheus-adapter-config配置
    • 配置 qps 请求量指标
    • 查看 "pods/http_server_requests_per_second" 指标
    • HPA配置
      • 基于Pod做HPA
      • 基于cpu或者memory做HPA
    • 启动HPA的伸缩控制器
      • hpa验证测试
  • 配置grafana展示qps监控数据
  • hpa命令清单
  • 高阶知识：Adapter 的Discovery规则如何配置？
    • 以获取Per-pod HTTP Requests为例
      • 1 demo问题场景
      • 2 配置适配器
      • 3 查询api
  • prometheus operator 不足之处
    • 数据持久化
    • tsdb 保留天数
    • 告警方式不方便
    • 加监控target也不方便
• 第14部分：k8s生产环境容器内部JVM参数配置解析及优化
  • Java Heap基础知识
  • 容器环境的Java Heap
    • UseContainerSupport
  • 最佳实践
    • 常用容器内存大小对应的jvm内存配置
      • 容器启动常用配置
    • 配置项的具体介绍
      • 1.堆总内存初始化大小分配和最大值分配
      • 2.非堆总内存初始化大小分配和最大值分配（1.8为metaspace）
      • 3.堆内存之年轻代年老代大小设置
      • 4.线程栈大小
      • 5.GC日志输出
      • 6.每个线程堆栈大小
  • Kubernetes（k8s）配置Java服务自动Dump
  • 参考：Go语音解决 java 内存溢出时候 dump 文件的存储问题
    • 问题
    • 方案
    • 其他
• 参考文献

第1部分：云原生(Cloud Native)的原理与演进

云原生之所以解释不清楚，是因为云原生没有确切的定义，

云原生一直在发展变化之中，解释权不归某个人或组织所有。

如果要理解 Cloud Native， 首先就要理解字面意思 ，大概是：

• 首先生在云上 ，不是在本地
• 本身生在云上 ，不是在本地
• 天生长在云上 ，不是在本地
• 土生土长在云上 ，不是在本地

所以，这个概念，是建立在 云基础设施基础上的。 云基础设施有： 虚拟服务器、虚拟容器 等，代表作就是K8S。

好，接下来，就看看 官方介绍的 什么是云原生(Cloud Native)。

1、什么是云原生(Cloud Native)？

云原生之所以解释不清楚，是因为云原生没有确切的定义，

云原生一直在发展变化之中，解释权不归某个人或组织所有。

Pivotal公司的Matt Stine于2013年首次提出云原生（Cloud Native）的概念；

2015年，云原生刚推广时，

Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：

• 符合 12 因素应用、
• 面向微服务架构、
• 自敏捷架构、
• 基于API协作、
• 扛脆弱性；

Pivotal 推出过 Pivotal Cloud Foundry 云原生应用平台和 Spring 开源 Java 开发框架，成为云原生应用架构中先驱者和探路者。

Pivotal 是云原生应用平台第一股，2018 年在纽交所上市，2019 年底被 VMWare 以 27 亿美元收购，加入到 VMware 新的产品线 Tanzu。

到了 2015 年 Google 主导成立了云原生计算基金会（CNCF），开始围绕云原生的概念打造云原生生态体系，起初CNCF对云原生的定义包含以下三个方面：

• 应用容器化(software stack to be Containerized)
• 面向微服务架构(Microservices oriented)
• 应用支持容器的编排调度(Dynamically Orchestrated)

2017年, 云原生应用的提出者之一的Pivotal在其官网上将云原生的定义概况为DevOps、持续交付、微服务、容器这四大特征，这也成了很多人对 Cloud Native的基础印象。

云原生的四要素：

• 持续交付、
• DevOps、
• 微服务、
• 容器：

1） DevOps

DevOps（Development和Operations的组合词）即开发、运维一体化。

涉及软件在整个开发生命周期中的持续开发，持续测试，持续集成，持续部署和持续监控。
最佳实践：Git，Jenkins，Bamboo，Docker，Kubernetes

2） 持续交付

持续交付：持续交付是不误时开发，不停机更新，小步快跑，反传统瀑布式开发模型，这要求开发版本和稳定版本并存，其实需要很多流程和工具支撑。

最佳实践：CI/CD, gitlab， Jenkins，流水线pipeline，tekton等

3） 微服务 （Microservice）

几乎每个云原生的定义都包含微服务，跟微服务相对的是单体应用，

微服务有理论基础，那就是康威定律，指导服务怎么切分。

4） 容器 （Container）

2013年，Docker项目正式发布，2014年，K8s项目也正式发布。

Docker是应用最为广泛的容器引擎，在思科谷歌等公司的基础设施中大量使用。

K8S是容器编排系统，用于容器管理，容器间的负载均衡

2、云原生发展历史时间轴

2.1 从微服务到服务网格

• 微服务

马丁大师在2014年定义了微服务

• Kubernetes

从2014年6月由Google宣布开源，

到2015年7月发布1.0这个正式版本并进入CNCF基金会，再到2018年3月从CNCF基金会正式毕业，迅速成为容器编排领域的标准，是开源历史上发展最快的项目之一

• Linkerd

Scala语言编写，运行在JVM中，Service Mesh名词的创造者

2016年01月15号，0.0.7发布

2017年01月23号，加入CNCF组织

2017年04月25号，1.0版本发布

• Envoy

envoy 是一个开源的服务代理，为云原生设计的程序，由C++语言编程[Lyft]
2016年09月13号，1.0发布
2017年09月14号，加入CNCF组织

• Istio

Google、IBM、Lyft发布0.1版本

Istio是开源的微服务管理、保护和监控框架。Istio为希腊语，意思是”起航“。

2.2 微服务架构的问题

微服务时代有了Spring Cloud就完美了吗？不妨想一想会有哪些问题?

（1）最初是为了业务而写代码，比如登录功能、支付功能等，到后面会发现要解决网络通信的问题，虽然有 Spring Cloud里面的组件帮我们解决了，但是细想一下它是怎么解决的？

在业务代码里面加上spring cloud maven依赖，加上spring cloud组件注解，写配置，打成jar的时候还必须要把非业务的代码也要融合在一起，称为“侵入式框架”；

（2）微服务中的服务支持不同语言开发，也需要维护不同语言和非业务代码的成本；

（3）业务代码开发者应该把更多的精力投入到业务熟悉度上，而不应该是非业务上，Spring Cloud虽然能解决微服务领域的很多问题，但是学习成本还是较大的；

（4）互联网公司产品的版本升级是非常频繁的，为了维护各个版本的兼容性、权限、流量等，

因为Spring Cloud是“代码侵入式的框架”，这时候版本的升级就注定要让非业务代码一起，一旦出现问题，再加上多语言之间的调用，工程师会非常痛苦；

（5）其实我们到目前为止应该感觉到了，服务拆分的越细，只是感觉上轻量级解耦了，但是维护成本却越高了，那么怎么 办呢？

我们不是说spring cloud不好，只是为了引出service mesh,

目前spring cloud微服务还是比较主流的， 我们指出spring cloud的不好也只是为了突出service mesh的优点

问题解决思路

• 本质上是要解决服务之间通信的问题，不应该将非业务的代码融合到业务代码中

• 也就是从客户端发出的请求，要能够顺利到达对应的服务，这中间的网络通信的过程要和业务代码尽量无关

  服务通信无非就是服务发现、负载均衡、版本控制等等

• 在很早之前的单体架构中，其实通信问题也是需要写在业务代码中的，那时候怎么解决的呢？

  

解决方案：

把网络通信，流量转发等问题放到了计算机网络模型中的TCP/UDP层，也就是非业务功能代码下沉，

把这些网络的问题下沉到计算机网络模型当中，也就是网络七层模型

网络七层模型：应用层、表示层、会话层、传输层、网络层、数据链路层、物理层

思考：

我们是否也可以把每个服务配置一个代理，所有通信的问题都交给这个代理去做，

就好比大家熟悉的nginx,haproxy其实它们做反向代理把请求转发给其他服务器,也就为 Service Mesh的诞生和功能实现提供了一个解决思路

2.3 SideCar 旁车模式（边车模式）

Sidecar模式是一种将应用功能从应用本身剥离出来作为单独进程的方式。

SideCar降低了与微服务架构相关的复杂性，并且提供了负载平衡、服务发现、流量管理、电路中断、遥测、故障注入等基础特性。

服务业务代码与Sidecar绑定在一起，每个服务都配置了一个Sidecar代理，每个服务所有的流量都经过sidecar,

sidecar帮我们屏蔽了通信的细节，我的业务开发人员只需要关注业务就行了，而通信的事情交给sidecar处理

sidecar是为了通用基础设施而设计，可以做到与公司框架技术无侵入性

该模式允许我们向应用无侵入添加多种功能，避免了为满足第三方组件需求而向应用添加额外的配置代码。

很多公司借鉴了Proxy模式，推出了Sidecar的产品，比如像Netflix的Prana，蚂蚁金服的SofaMesh

很多公司借鉴了Proxy模式，推出了Sidecar的产品， 比如像Netflix的Prana，蚂蚁金服的SofaMesh

2014年 Netflix发布的Prana

2015年 唯品会发布local proxy

2016年 Twitter的基础设施工程师发布了第一款Service Mesh项目：Linkerd (所以下面介绍Linkerd)

3、2018 年云原生被CNCF重新定义

到了 2018 年，随着近几年来云原生生态的不断壮大，

所有主流云计算供应商都加入了该基金会，

且从 Cloud Native Landscape 中可以看出, 云原生有意蚕食原先非云原生应用的部分。

CNCF 基金会中的会员以及容纳的项目越来越多，该定义已经限制了云原生生态的发展，CNCF 为云原生进行了重新定位。

2018年6月，CNCF正式对外公布了更新之后的云原生的定义（包含中文版本）v1.0版本：

CNCF官方对Cloud Native的定义:

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.

中文版本：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。

云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。

我们通过将最前沿的模式民主化，让这些创新为大众所用。

新的定义中，继续保持原有的核心内容：容器和微服务，

但是非常特别的是：

将服务网格单独列出来，而不是将服务网格作为微服务的一个子项或者实现模式，体现了云原生中服务网格这一个新生技术的重要性。

而不可变基础设施和声明式API这两个设计指导理念的加入，则强调了这两个概念对云原生架构的影响和对未来发展的指导作用。

3.1 服务网格 （Service Mesh）

微服务技术架构实践中主要有侵入式架构和非侵入式架构两种实现形式。

侵入式架构是指服务框架嵌入程序代码，开发者组合各种组件，如RPC、负载均衡、熔断等，实现微服务架构。

非侵入式架构则是以代理的形式，与应用程序部署在一起，接管应用程序的网络且对其透明，开发者只需要关注自身业务即可，以服务网格为代表。

为了解决微服务框架的侵入性问题，引入Service Mesh。

Serice Mesh提供了专业化的解决方案，其中所涉及的服务通信、容错、认证等功能，都是专业度极高的领城，这些领城应该出现工业级成熟度的制成品，这对于中小企业来说是一个降低成本的选择。

Service Mesh的开源软件包括Istio、Linkerd、 Envoy、 Dubbo Mesh等。

同时，为了让Service Mesh有更好的底层支撑，我们又将Service Mesh运行在Kubernetes上。

3.2 不可变基础设施（Immutable Infrastructure）

What is “Immutable Infrastructure”?

参考URL：https://www.armory.io/blog/what-is-immutable-infrastructure/

不可变基础设施里的“不可变”非常类似于程序设计中的“不可变”概念。

程序设计中，不可变变量（Immutable Variable）就是在完成赋值后就不能发生更改，只能创建新的来整体替换旧的。

对于基础设施的不可变性，最基本的就是指运行服务的服务器在完成部署后，就不再进行更改。

可变基础设施通常会导致以下问题：

• 在灾难发生的时候，难以重新构建服务。持续过多的手工操作，缺乏记录，会导致很难由标准初始化后的服务器来重新构建起等效的服务。

• 在服务运行过程中，持续的修改服务器，就犹如程序中的可变变量的值发生变化而引入的状态不一致的并发风险。这些对于服务器的修改，同样会引入中间状态，从而导致不可预知的问题。

总结：不可变基础设施其实就是生产环境下基础设施不能改动，如果改动，已切都是被记录的，是可以回溯的。

3.3 声明式API ( declarative APIs)

Declarative APIs
https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/

声明式 API 的 “声明式” 是什么意思？

对于我们使用 Kubernetes API 对象的方式，一般会编写对应 API 对象的 YAML 文件交给 Kubernetes（而不是使用一些命令来直接操作 API）。
所谓“声明式”，指的就是我只需要提交一个定义好的 API 对象来“声明”（这个 YAML 文件其实就是一种“声明”），表示所期望的最终状态是什么样子就可以了。而如果提交的是一个个命令，去指导怎么一步一步达到期望状态，这就是“命令式”了。
“命令式 API”接收的请求只能一个一个实现，否则会有产生冲突的可能；“声明式API”一次能处理多个写操作，并且具备 Merge 能力。
Kubernetes 有很多能力，这些能力都是通过各种 API 对象来提供。也就是说，API 对象正是我们使用 Kubernetes 的接口，我们正是通过操作这些提供的 API 对象来使用 Kubernetes 能力的。

总结：声明式API其实就是所有资源抽象，抽象成api。这些api 标准化，相当于规范标准了。

4、CNCF云原生组织发展和介绍

CNCF 是一个开源软件基金会，致力于使云原生计算具有普遍性和可持续性。

云原生计算使用开源软件技术栈将应用程序部署为微服务，将每个部分打包到自己的容器中，并动态编排这些容器以优化资源利用率。

云原生技术使软件开发人员能够更快地构建出色的产品。

什么是CNCF

cncf官网：https://www.cncf.io/

CNCF基金会是 2015年由Linux基金会发起了一个 The Cloud Native Computing Foundation（CNCF）基金组织，

CNCF基金会的成立标志着云原生正式进入高速发展轨道，Google、Cisco、Docker各大厂纷纷加入，并逐步构建出围绕 Cloud Native 的具体工具，而云原生这个的概念也逐渐变得更具体化。

CNCF最初对云原生定义是也是狭窄的，当时把云原生定位为容器化封装+自动化管理+面向微服务。

CNCF的目的不一样，他成立的目的是希望打破云巨头的垄断，实际上是希望通过容器和k8s，将提供底层资源的云服务商变得无差异化。

这主要因为CNCF基金会在当时的核心拳头软件就是k8s，因此在概念定义上主要是围绕着容器编排建立起来的生态。

这也是为什么我们感觉CNCF 定义云原生的时候就是在说容器生态。

CNCF 是非营利性 Linux 基金会的一部分。

官网介绍：
Building sustainable ecosystems for cloud native software

为云原生软件建立可持续的生态系统

Cloud Native Computing Foundation (CNCF) serves as the vendor-neutral home for many of the fastest-growing open source projects, including Kubernetes, Prometheus, and Envoy.

云本地计算基金会(CNCF)是许多增长最快的开放源码项目的供应商中立主机，其中包括 Kubernetes、 Prometheus 和 truster。

CNCF 致力于培育和维护一个厂商中立的开源社区生态，用以推广云原生技术。

从 2015 年 Google 牵头成立 CNCF 以来，云原生技术开始进入公众的视线并取得快速的发展，到 2018 年包括 Google、AWS、Azure、Alibaba Cloud 等大型云计算供应商都加入了云原生基金会 CNCF，云原生技术也从原来的应用容器化发展出包括容器、Service Mesh、微服务、不可变基础设施、Serverless、FaaS 等众多技术方向。

CNCF解决了什么问题

• 统一基础平台：kubernetes
• 如果我们需要日志监控：Prometheus
• 需要代理：Envoy
• 需要分布式链路跟踪：Jaeger
• ......

地址：https://www.cncf.io/

介绍几个常用的已经毕业的云原生项目

Kubernetes

Kubernetes 是世界上最受欢迎的容器编排平台也是第一个 CNCF 项目。 Kubernetes 帮助用户构建、扩展和管理应用程序及其动态生命周期。

Prometheus

Prometheus 为云原生应用程序提供实时监控、警报包括强大的查询和可视化能力，并与许多流行的开源数据导入、导出工具集成。

Jaeger

Jaeger 是由 Uber 开发的分布式追踪系统，用于监控其大型微服务环境。 Jaeger 被设计为具有高度可扩展性和可用性，它具有现代 UI，旨在与云原生系统（如 OpenTracing、Kubernetes 和 Prometheus）集成。

Containerd

Containerd 是由 Docker 开发并基于 Docker Engine 运行时的行业标准容器运行时组件。
作为容器生态系统的选择，Containerd 通过提供运行时，可以将 Docker 和 OCI 容器镜像作为新平台或产品的一部分进行管理。

Envoy

Envoy 是最初在 Lyft 创建的 Service Mesh（服务网格），现在用于Google、Apple、Netflix等公司内部。 Envoy 是用 C++ 编写的，旨在最大限度地减少内存和 CPU 占用空间，同时提供诸如负载均衡、网络深度可观察性、微服务环境中的跟踪和数据库活动等功能。

Fluentd

Fluentd 是一个统一的日志记录工具，可收集来自任何数据源（包括数据库、应用程序服务器、最终用户设备）的数据，并与众多警报、分析和存储工具配合使用。
Fluentd 通过提供一个统一的层来帮助用户更好地了解他们的环境中发生的事情，以便收集、过滤日志数据并将其路由到许多流行的源和目的地。

孵化中的项目

Open Tracing

OpenTracing：为不同的平台，供应中立的API，使开发人员可以轻松地应用分布式跟踪。

GRPC

gRPC 是一个高性能、开源和通用的 RPC 框架,语言中立，支持多种语言。

CNI

CNI 就是这样一个标准，它旨在为容器平台提供网络的标准化。不同的容器平台能够通过相同的接口调用不同的网络组件。

Helm

Helm 是 Kubernetes 的包管理器。包管理器类似于我们在Centos中使用的yum一样，能快速查找、下载和安装软件包。

Etcd

一个高可用的分布式键值(key-value)数据库。etcd内部采用raft协议作为一致性算法，etcd基于Go语言实现。一般用的最多的就是作为一个注册中心来使用

5、从微服务演进到Service Mesh（服务网格）的过程

CNCF非常特别的是：

将服务网格单独列出来，而不是将服务网格作为微服务的一个子项或者实现模式，体现了云原生中服务网格这一个新生技术的重要性。

来看看 从微服务演进到Service Mesh（服务网格）的过程

5.1 单体服务时代

2010年前，大多数服务业务单一且简单，采用典型的单机+数据库模式，

所有的功能都写在一个应用里并进行集中部署

论坛业务、聊天室业务、邮箱业务全部都耦合在一台小型机上面，所有的业务数据也都存储在一台数据库上。

随着应用的日益复杂与多样化，开发者对系统的容灾，伸缩以及业务响应能力有了更高的要求

如果小型机和数据库中任何一个出现故障，整个系统都会崩溃，

若某个板块的功能需要更新，那么整个系统都需要重新发布，

如何保障可用性的同时快速响应业务的变化，需要将系统进行拆分，将上面的应用拆分出多个子应用。

优点：应用跟应用解耦，系统容错提高了，也解决了独立应用发布的问题

应用垂直拆分解决了应用发布的问题，但是随着用户数量的增加，单机的计算能力依旧是杯水车薪

用户量越来越大，同时也要进行高可用保证， 大部分系统，需要进行横向扩展（水平扩展）

在接入层，引入负载均衡组件，有了负载均衡之后，架构图如下

阿里巴巴在2008提出去“IOE”，也就是IBM小型机、Oracle数据库，EMC存储，

全部改成集群化负载均衡架构，在2013年支付宝最后一台IBM小型机下线

优点：

应用跟应用解耦，系统容错提高了，也解决了独立应用发布的问题，同时可以水平扩展来提供应用的并发量

5.2 微服务时代

分布式微服务时代

微服务是在2012年提出的概念，微服务的希望的重点是一个服务只负责一个独立的功能。

拆分原则，任何一个需求不会因为发布或者维护而影响到不相关的服务，一切可以做到独立部署运维。

比如传统的“用户中心”服务，对于微服务来说，需要根据业务再次拆分，可能需要拆分成“买家服务”、“卖家服务”、“商家服务”等。

典型代表：

Spring Cloud，相对于传统分布式架构，SpringCloud使用的是HTTP作为RPC远程调用，配合上注册中心Eureka和API网关Zuul，可以做到细分内部服务的同时又可以对外暴露统一的接口，让外部对系统内部架构无感，此外Spring Cloud的config组件还可以把配置统一管理。

马丁大师对微服务的定义：https://martinfowler.com/articles/microservices.html

微服务真正定义的时间是在2014年

The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.

大概意思：可独立部署服务，服务会越来越细

spring cloud地址：https://spring.io/projects/spring-cloud

集群部署多了，这些重复的功能无疑会造成资源浪费，所以会把重复功能抽取出来，名字叫"XX服务（Service）"

为了解决服务跟服务如何相互调用，需要一个程序之间的通信协议，所以就有了远程过程调用（RPC），作用就是让服务之间的程序调用变得像本地调用一样的简单

5.3 服务网格新时期 （service mesh）

服务网格和微服务的本质区别，主要在于 单体服务进行 业务服务和 非业务基础 服务进行解耦

非业务基础 服务，交给基础框架进行 管理和控制

非业务基础 （sidecar）服务 + 服务治理 中间件 （Pilot/mixor），组成一个网络结构， 被称之为服务网格

如下图所示

为啥叫做服务网格，主要 从架构层面看起来跟网格很像，

如果每一个格子都是一个sidecar数据单位（单元格），然后sidecar进行彼此通信，所以这些单元格 组成 数据面

这些 sidecar数据单位（单元格），由统一的控制/配置中间组件（类似nacos注册中心）进行配置和控制， 那些控制组件 组成 了 控制面

宏观上 ，服务网格 =数据面 + 控制面

特点：

• 基础设施：

服务网格是一种处理服务之间通信的基础设施层。

• 支撑云原生：

服务网格尤其适用于在云原生场景下帮助应用程序在复杂的服务间可靠地传递请求。

• 网络代理：

在实际使用中，服务网格一般是通过一组轻量级网络代理来执行治理逻辑的。

• 对应用透明：

轻量网络代理与应用程序部署在一起，但应用感知不到代理的存在，还是使用原来的方式工作。

6、服务网格（service mesh）原理和价值

什么是服务网格（service mesh）

istio官网 也对什么是service mesh给出了定义

地址：https://istio.io/docs/concepts/what-is-istio/#what-is-a-service-mesh

Istio addresses the challenges developers and operators face as monolithic applications transition 
Jarque-Bera test|pp图|K-S检验|


Jarque-Bera test:
 
 
 
 
 
 
 
 
 
如何绘制pp图?
 
 
 
 
 
 
找该直线的截距和斜率，通过截距和斜率的值找到正态参数均值和方差，可对这些正态参数进行正态检验。
K-S检验的的特点？
并不是只针对正态分布，是针对某一分布。在大样本时针对正态分布。
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
以上是关于K8S学习圣经：大白话说K8S底层原理，14W字实现K8S自由的主要内容，如果未能解决你的问题，请参考以下文章
 
 Docker圣经：大白话说Docker底层原理，6W字实现Docker自由
 K8S学习圣经6：资源控制+SpringCloud动态扩容原理和实操
 K8S学习圣经5：Pod负载管理的十八般兵器
 K8S圣经12：SpringCloud+Jenkins+ K8s Ingress 自动化灰度发布
 kubernetes(k8s)大白学习02：容器和docker基础使用架构学习
 1W字长文：K8S Ingress 原理和实操