您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 
 订阅
什么是 Kubernetes 中的服务?
 
作者:inicho
  954  次浏览      15 次
 2022-5-10
 
编辑推荐:
本文主要介绍了复习 pod 相关核心结构、pod 如何对外提供访问及pod 的负载均衡。希望对您的学习有所帮助。
本文来自于微信公众号高效运维,由Linda编辑、推荐。

1. 复习 pod 相关核心结构

1.1 pod 结构

pod 相当于一个容器,pod 有独立的 ip 地址,也有自己的 hostname,利用 namespace 进行资源隔离,相当于一个独立沙箱环境。

pod 内部封装的是容器,可以封装一个,或者多个容器(通常是一组相关的容器)

1.2 pod 网络

pod 有自己独立的 IP 地址

pod 内部的容器之间是通过 localhost 进行访问

2. pod 如何对外提供访问

首先 pod 有自己的 IP 和 hostname,但 pod 是虚拟的资源对象 (在计算机中表现为进程),没有对应实体 (物理机,物理网卡) 与之对应,所以是无法直接对外提供服务访问的。

因此如果 pod 想对外提供服务,必须绑定物理机端口 (即在物理机上开启端口,让这个端口和 pod 的端口进行映射),这样就可以通过物理机进行数据包的转发。

下面以一台 Linux 系统的机器为例子( logstash 是做日志收集用的)

3. pod 的负载均衡

很关键的一个问题:一组相关的 pod 副本,如何实现访问负载均衡?就如当请求达到,请求转发给哪个 pod 比较好?

一个想法就是用 pod 再部署一个 Nginx。

举例:如下图,注意下图右边的 Node 里面有两个是 支付 服务,与订单服务的是不同类型的 pod。如果一个请求订单的服务发来上面那个 Nginx,那这个 pod 可以有 4 条转发路线,可以想到用 hash 呀什么的把不同请求映射到不同的 pod 去转发。但能不能这么做呢?

思考:pod 是一个进程,是有生命周期的,一旦宕机、版本更新都会创建新的 pod( IP 地址会变化,hostname 会变化),此时再使用 Nginx 做负载均衡不太合适,因为它不知道 pod 发生了改变,那请求就不能被接受了。所以服务发生了变化它根本不知道,Nginx 无法发现服务,不能用 Nginx 做负载均衡。那该如何实现呢?使用 Service 资源对象。

3.1 什么是 Service 资源对象

POD IP:pod 的 IP 地址

NODE IP:物理机的 IP 地址

cluster IP:虚拟 IP,是由 kubernetes 抽象出的 service 对象,这个 service 对象就是一个 VIP (virtual IP, VIP) 的资源对象

3.2 service 如何实现负载均衡

例如现在要负载均衡地访问一组相同的服务副本——订单,这时就要去做一个 service,对外表现出是一个进程或资源对象,有虚拟的 IP (VIP) 和端口。请求会访问 service,然后 service 自己会 负载均衡 地发送给相应服务的 POD,也就是下图中 4 个相同的 pod。

3.3 深入 service VIP

service 和 pod 都是一个进程,都是虚拟的,因此实际上 service 也不能对外网提供服务

service 和 pod 之间可以直接进行通信,它们的通信属于局域网通信

负载策略:把请求交给 service 后,service 使用 iptables,ipvs 来实现数据包的分发

而要对外网提供服务,首先需要和之前一样 在物理机上也绑定一个端口 来接受访问请求,然后把请求转发给 service,service 再把数据包分发给相应的 POD。访问流程如下图所示:

思考1:那 service 对象是如何和 pod 进行关联的呢?

它们之间的关联利用的 还是标签选择器 selector。且service 只能对 一组相同的副本 提供服务,不能跨组提供服务。如果有另一组,需要再创建一个 service。因此不同的业务会有不同的 service。

举例:service 和 一组 pod 副本是通过标签选择器进行关联的,相同的副本的标签是一样的。

selector:app = x 选择一组订单的服务的 pod,创建一个 service;app = y 选择了一组支付的服务的 pod。通过一个 endpoints 属性存储这组 pod 的 IP 地址,这样就有了映射关系了 (关联起来)。

思考2:pod 宕机或发布新版本了,service 是如何发现 pod 已经发生变化的?

通过 k8s 中的一个组件 —— kube-proxy (第 1 篇有提到过),每个 NODE 里都运行着这个服务。它需要做的工作如下图右侧:

service 实现服务的发现:kube-proxy 监控 pod,一旦发现 pod 服务变化,将会把新的 ip 地址更新到 service。

注意:endpoints 那些都是存储在 etcd 里的 (也是第 1 篇提到过的),所以 kube-proxy 更新的存储在 etcd 里的映射关系。

 

   
954 次浏览       15
相关文章

聊聊云原生和微服务架构
Serverless:微服务架构的终极模式
如何实现微服务架构下的分布式事务?
微服务下的数据架构设计
相关文档

微服务和云原生应用
微服务架构原理和设计方法
0到3000万用户微服务之旅
微服务在微信后台的架构实践
相关课程

微服务架构设计与实践
领域驱动+微服务架构设计
云计算、微服务与分布式架构
云平台与微服务架构设计

最新活动计划
MBSE(基于模型的系统工程)4-18[北京]
自然语言处理(NLP) 4-25[北京]
基于 UML 和EA进行分析设计 4-29[北京]
以用户为中心的软件界面设计 5-16[北京]
DoDAF规范、模型与实例 5-23[北京]
信息架构建模(基于UML+EA)5-29[北京]
 
 
最新文章
云原生架构概述
K8S高可用集群架构实现
容器云管理之K8S集群概述
k8s-整体概述和架构
十分钟学会用docker部署微服务
最新课程
云计算、微服务与分布式架构
企业私有云原理与构建
基于Kubernetes的DevOps实践
云平台架构与应用(阿里云)
Docker部署被测系统与自动化框架实践
更多...   
成功案例
北京 云平台与微服务架构设计
通用公司GE Docker原理与实践培训
某军工研究单位 MDA(模型驱动架构)
知名消费金融公司 领域驱动设计
深圳某汽车企业 模型驱动的分析设计
更多...