《Kubernetes集成外部服务实践》- 第三期Docker技术沙龙主题剖析系列【第一篇】
发布于 7 天前 作者 limeflavor 207 次浏览 来自 分享

分享嘉宾:柴宗三,亚信大数据云平台部高级研发工程师。目前负责亚信DataFoundry大数据PaaS云平台。本文源自于3月12号《第三期Kubernetes沙龙》四个Topic之一,是《第三期 kubernetes沙龙主题剖析系列·第一篇》。本文对如何将后端服务(backend service)接入kubernetes进行了比较详尽的介绍。

Part I. Kubernetes简介

Kubernetes不同组件的交互是异步的,不同组件负责不同的功能模块。Kubernetes集群目前为单master结构,一般情况下master节点上运行APIServer、kube-controller-manager、kube-scheduler、etcd,node节点上运行kubelet、kube-proxy、flannel。Etcd和flannel用于网络管理,不是kubernetes本身的组件,这里不做介绍。虽然k8s是单master结构,但是master的宕机并不会导致导致集群应用service unavailable,只是暂时无法从管理层面对容器应用进行操作。

● APIServer(master组件)的功能是作为集群的Master,提供集群管理的API,接收客户端的REST请求,读写etcd中的数据。 ● kube-controller-manager(master组件)监听Replication Controller的变化,并创建对应的Pod,使其达到期望的运行状态。 ● kube-scheduler(master组件)根据节点的资源和限制条件将pod分配给特定slave节点的kubelet。 ● Kubelet(node组件)作为daemon运行在每个slave节点上,用来维持节点上的容器,保持与APIServer、etcd的数据同步。Kubelet默认集成cadvisor组件,用于搜集主机和容器的监控数据。 ● kube-proxy(node组件)用于接收打给service的流量,根据podSelector分发给特定的backend pods。如果配置了service的external endpoint,则会将请求分发给外部服务。

Part II. 将外部服务接入kubernetes

backend service,即后台服务,具有持久化、插件化、服务化的特点。对于PaaS平台,其backend service还要满足四个需求:需求多样、服务共享、按需分配、开箱即用。为了满足PaaS平台的这些需求,必须对backend service做一些规范规范。对此,亚信的PaaS平台采用了CloudFoundry的规范(如下)。每个backend service都会暴露自己的REST API供其它服务调用。通过REST API的方式,极大方便了Resource Register、Controller Handler、Api Router、CLI 的实现。

沙龙干货分享3.png

Backend service(后台服务)与kubernetes通过两种方式集成。第一种,每个backend service作为Pod中的一个container运行在kubernetes中,不同的后端服务可以使用Pod级别的编排相互串联起来。Backend service的REST API通过service映射到外部,对外提供服务。为了保持服务的持久性,不能采用本地存储,建议将分布式文件系统的块挂载到后端服务对应的Pod上。第二种方式,backend service作为一个独立的服务,与kubernetes集群分开。在kubernetes集群中创建service,将后台服务的访问方式设置到service的external endpoint中。

Part III. 访问REST API

无论后端服务在kubernetes集群中作为Container运行,或者处于kubernetes集群之外,都通过kubernetes的service做请求分发。Kubernetes的Service本身非常灵活,可以选择暴露到外网,或者只是在内网访问。同时Service具备load balance功能,如果后端服务独立于kubernetes集群,那么可以充当简化版的haproxy使用。

回到顶部