Kubernetes横空出世
解决了哪些问题
- 如果5个服务 3个副本 那么手工管理就可以了
- 如果大规模容器 交给k8s框架本身
Kubernetes成为事实上的编排标准
它为何这般茁壮?
- Spring Cloud仅限于Java，而Kubernetes适用于所有编排语言，且解决更广泛的MSA的问题
- Kubernetes还支持
- 配置环境
- 设置资源约束
- RBAC
- 管理应用程序生命周期
- 启用自动扩展和自我修复等
- 自带反脆弱能力
一句话总结
Kubernetes是一套容器编排系统 为服务治理 底层基础设施
k8s矩阵覆盖
配置管理
- config map 、secrets
服务发现
- Kubernets Service
- Ingerss Resources
服务发布
- Kubernets Service
- Ingerss Resources
负载均衡
- Kubernets Service
日志中心
EFK stack
监控指标中心
promethues grafana
链路追踪
opentracing zipkin
韧性 容错能力
- Kubernets health check
- resource isolation 资源隔离
自动伸缩 自愈能力
- Kubernets health check
- self healing 自愈
- 如果删除pod 会自动创建出来
- autoscaling
打包
- Docker
部署
- Deployment
- statefulset
- operater
调度
- Kubernets scheduler 高级的调度机制
作业管理
- Kubernets Jobs
- Scheduled Jobs 周期性作业
自主应用
- Kubernets Pod
kubernetes的问题
- 没有针对不同的平台（例如 Spring Cloud for JVM）进行优化
- 非以开发人员为中心的平台，对DevOps目标的用户具有更友好的特性
解决方案是什么？
研发人员借助 Spring cloud框架开发微服务 运维人员借助 Kubernets 以容器化的方式编排、部署、运维 微服务
带来的问题
Spring cloud和Kubernets很多东西重合了, 使得系统变得很冗余
背景 克服服务通信和治理的复杂性，例如服务发现、融合、节流和端到端跟踪的挑战，需要用到专门的微服务治理框架
- 微服务框架，如 HSF、Dubbo 或 Spring Cloud，将这些能力打包成代码库，形成SDK
- 程序员开发微服务时，将这些代码库内置于应用程序中，并随应用程序一起发布和维护
问题2 存在问题：库模型可能会抽象出满足微服务架构所需要的特性，但它本身仍然是一个需要维护的组件
-
学习和使用库需要相当程度力量的投入
-
本质上，服务通信和治理是横向连接不同部门的系统，因此与业务逻辑是正交的；
-
但是，在微服务架构中，实现和生命周期是与业务逻辑耦合的，微服务框架的升级会导致整个服务应用的重新构建和重新部署
-
代码库通常与特定语言绑定，因此难以支持企业应用程序的多语言实现
Sidecar
旁挂程序 边车代理
SDK的东西放到 sidecar中 每次更新 不会影响其他服务
功能分离开 自己完成自己的功能 基础网络由tcpip
SDK自己发布 sidcar 不需要重新发布SDK工具
开发时遵循微服务的体系 遵循契约和规范 开发自己的代码就行了
Service Mesh 服务网格
在Kubernets的上层 加一个服务治理框架
将服务治理能力下沉到基础设施中，并将它们部署为服务消费者和服务提供者的独立流程
- 每个服务都使用一个专用的代理Sidecar来完成高级网络功能
- 各服务间仅通过Sidecar代理互相通信
- 各代理之间形成了一个网状网络，2017年，William为其创建一个专用定义，并称之为Service Mesh
新一代Service Messh: 为Service Mesh中各独立工作的代理提供集中式的“控制平面
- 实际的服务流量仍然直接在各代理之间完成，但控制平面知道每个代理实例
- 控制平面使代理能够实现诸如访问控制和指标收集之类的事情
