基于Kubernetes服务机制怎么理解-成都创新互联网站建设

成都创新互联网站制作

028-86922220

关于创新互联

多方位宣传企业产品与服务 突出企业形象

公司简介 公司的服务 荣誉资质 新闻动态 联系我们

基于Kubernetes服务机制怎么理解

本篇内容主要讲解“基于Kubernetes服务机制怎么理解”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“基于Kubernetes服务机制怎么理解”吧!

成都创新互联专业为企业提供莲池网站建设、莲池做网站、莲池网站设计、莲池网站制作等企业网站建设、网页设计与制作、莲池企业网站模板建站服务，10年莲池做网站经验，不只是建网站，更提供有价值的思路和整体网络服务。

服务注册

注册中⼼作为一般的RPC/Web服务中的底层设施提供了服务进程元数据（IP, Port, Interface, Group,Method等）存储，被Watch的功能，每个服务进程均需接⼊同⼀组持久化的K/V介质集群（⽐如: zookeeper,etcdv3等)。各进程均需将本进程的元数据存储于注册中⼼，并且能够Watch到其他服务进程的元数据变化（包括创建，更新等）。

Kubernetes

Kubernetes作为容器集群化管理⽅案管理资源的维度可主观的分为服务进程管理和服务接⼊管理。服务进程管理，主要体现⽅式为Pod设计模式加控制器模式，控制器保证具有特定标签（Kubernetes-Label）的Pod保持在恒定的数量（多删，少补）。服务接⼊管理，主要为Kubernetes-Service，该Service默认为具有特定标签（KubernetesLabel）的Pod统⼀提供⼀个VIP（Kubernetes-ClusterIP）所有需要请求该组Pod的请求都会按照round-robin的负载策略转发到真正提供服务的Pod。并且CoreDNS为该Kubernetes-Service提供集群内唯⼀的域名。

Service 与 RPC/Web服务存在的冲突点

  • Kubernetes-Service标准的资源对象具有的服务描述字段 中并未提供完整的服务进程元数据字段因此，⽆法直接使⽤Kubernetes-Service进⾏服务注册与发现。

  • RPC/Web服务的服务注册是基于每个进程的，每个服务进程均需进⾏独⽴的注册。

  • Kubernetes-Service默认为服务创建VIP，提供round-robin的负载策略也与RPC/Web服务⾃有的负载策略形成了冲突。

抛弃Service对象，选择Pod对象进⾏注册

  • Kubernetes-Service与RPC/Web服务现有架构的冲突导致RPC/Web服务在选择服务注册与发现的时候只能选择放弃该资源对象。

  • RPC/Web服务既然选择了每个RPC/Web服务进程独⽴注册，因此RPC/Web服务选择将该进程具有的独有的元数据写⼊运⾏该RPC/Web服务进程的Pod在Kubernetes中的Pod资源对象的描述信息中。

  • 每个运⾏RPC/Web服务进程的Pod将本进程的元数据写⼊Kubernetes-Pod Annotations字段。为了避免与其他使⽤Annotations字段的Operator或者其他类型的控制器（Istio）的字段冲突，使⽤Key为 app.io/annotation value为具体存储的K/V对的数组的json编码后的base64编码。

样例：

  apiVersion: v1kind: Podmetadata: annotations:    app.io/annotation: 5LiN55So55yL5LqG5bCx5piv5LiA5Liq5paH5pys5Y2P6K6u

由于每个RPC/Web服务的Pod均只负责注册本进程的元数据，因此Annotations字段⻓度也不会因为运⾏RPC/Web服务进程的Pod数量增加⽽增加。

服务发现

解决掉了服务注册问题，接下来需要解决的是服务发现的问题。Kubernetes Api-Server提供了Watch的功能，可以观察特定namespace甚⾄整个集群内各类资源的变化。RPC/Web服务为了避免RPC/Web服务进程watch到与RPC/Web服务进程⽆关的Pod的变化，RPC/Web服务将watch的条件限制在当前Pod所在的namespace，以及 watch 具有 app.io/label Value为app.io-value 的Pod。在Watch到对应Pod的变化后实时更新本地Cache，并通过Registry提供的Subscribe通知建⽴在注册中⼼之上的服务集群管理，或者其他功能。

⼯作流程

  • 启动RPC/Web服务的Deployment或其他类型控制器使⽤Kubernetes Downward-Api将本Pod所在namespace通过环境变量的形式注⼊RPC/Web服务进程。

  • RPC/Web服务进程的Pod启动后通过环境变量获得当前的namespace以及该Pod名称， 调⽤
    Kubernetes-Apiserver PATCH 功能为本Pod添加Key为app.io/label Value为app.io-value的label。

  • RPC/Web服务进程调⽤Kubernetes-Apiserver 将本进程的元数据通过PATCH接⼝写⼊当前Pod的Annotations字段。

  • RPC/Web服务进程 LIST 当前namespace下其他具有同样标签的Pod，并解码对应的Annotations字段获取其他Pod的信息。

  • RPC/Web服务进程 WATCH 当前namespace下其他具有同样标签的Pod的Annotations的字段变化。

到此，相信大家对“基于Kubernetes服务机制怎么理解”有了更深的了解，不妨来实际操作一番吧！这里是创新互联网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！


本文标题：基于Kubernetes服务机制怎么理解
转载来于：http://kswsj.cn/article/picoji.html

其他资讯