转载

微服务和K8S集成-探索实践

微服务对DevOps的挑战

  • 快速配置计算资源

  • 基本监控

  • 持续集成,持续交付,持续部署

  • 易于配置存储

  • 认证/授权

  • 网络的问题

  • 服务管理

Kubernetes - 容器编排王者

  • 资源调度

  • 弹性伸缩

  • 自动化部署

  • 滚动发布,蓝绿发布,灰度发布

服务发现 — Eureka高可用

  • 部署三个或更多对等节点

  • 注册动作会传递

  • 客户端同时向所有Eureka注册

微服务和K8S集成-探索实践

微服务和K8S集成-探索实践

节点A和C无法交换数据

选型方案1: K8S Headless + DaemonSets

K8S Headless Service

  • 没有负载均衡

  • 1个服务名标明集群

  • 多个A记录对于此服务名

K8S DaemonSets(生产环境可选)

  • 1个Node节点1个Pod

  • 所有节点或部分节点

Eureka扩展

  • 读取DNS信息,把1个服务名转化为多个节点的IP地址

  • 服务器端:扩展EurekaClientConfigBean,同时过滤自身IP

  • 客户端:扩展EurekaInstanceConfigBean

优点:

简洁的配置

K8S的便利

缺点

需要扩展Eureka

方案2: K8S StatefulSets

K8S StatefulSets

  • 要求Headless

  • 每个实例对应的网络ID

  • 网络Id列表标明集群

  • 持久的存储卷Volume

Eureka扩展(可选由于网络Id存在)

  • 读取DNS信息,把1个服务名转化为多个节点的IP地址

  • 服务器端:扩展EurekaClientConfigBean,同时过滤自身IP

优点

简洁的配置

K8S的便利

缺点

需要扩展Eureka(可选)

配置管理 - ConfigMap

ConfigMap到Pod环境变量

  • 单个ConfigMap数据

  • 多个ConfigMap数据

ConfigMap到存储卷

  • 存储到文件

  • 指定路径和权限

  • 自动更新

服务发现 — No Service Discovery

Spring Cloud?

  • AP系统(Consul, Eureka) or CP系统(Zookeeper, etcd)?

  • 多语言支持?

  • 只使用DNS?

弹性DNS,动态DNS

  • 只使用Kubernetes服务?

客户端负载平衡? Ribbon

Turbine / Hystrix Dashboard

选型方案: K8S + spring-cloud-kubernetes 

1. DiscoveryClient for Kubernetes

2. Ribbon discovery in Kubernetes

3. Zipkin discovery in Kubernetes

优点

K8S提供的便利

多语言微服务

简化原有SpringCloud部署

缺点

代码的K8S依赖

需求转化:从Eureka高可用到K8S高可用

Service Mesh 

演变过程:

微服务和K8S集成-探索实践

微服务和K8S集成-探索实践

微服务和K8S集成-探索实践

微服务和K8S集成-探索实践

Service Mesh — 定义

  • 处理服务到服务通信的专用基础设施层

  • 透过云原生应用程序的复杂拓扑结构,负责可靠地传递请求

  • 实践中,Service Mesh通常被实现为与应用程序代码一起部署的一组轻量级网络代理,应用程序无需知道代理组的存在

Service Mesh — Istio 实现

微服务和K8S集成-探索实践

Service Mesh — No Service Discovery & Even Less

选型方案:K8S + Service Mesh

使用K8S DaemonSets

  • K8S Ingress Controller

  • Istio [4]集成作为控制面板

Conduit

  • K8S紧密集成

  • K8S Deployment作为管理单元

Istio

  • K8S部署

原文  http://mp.weixin.qq.com/s?__biz=MzUzODU4MjE2MQ==&mid=2247484125&idx=1&sn=86d05577a4ecfd51feb96d349f0b103d
正文到此结束
Loading...