淮南建设厅网站,wordpress仿微信菜单栏,宝塔搭建网站教程,广州最新通知本文介绍了 Kubernetes Service 的概念、原理和具体使用。 作者#xff1a;沈亚军 爱可生研发团队成员#xff0c;负责公司 DMP 产品的后端开发#xff0c;爱好太广#xff0c;三天三夜都说不完#xff0c;低调低调… 本文来源#xff1a;原创投稿 爱可生开源社区出品沈亚军 爱可生研发团队成员负责公司 DMP 产品的后端开发爱好太广三天三夜都说不完低调低调… 本文来源原创投稿 爱可生开源社区出品原创内容未经授权不得随意使用转载请联系小编并注明来源。 Service 是什么
Service 是 Kubernetes 一种资源用于实现恒定的入口访问一组提供相同服务的 Pod。每个 Service 在其生命周期内拥有固定的 IP 和 Port客户端可以通过访问该 IP 和端口访问到和其关联的所有 Pod。这样服务的客户端不需要知道提供服务的各个 Pod 的位置从而允许这些 Pod 在集群中移动。
首先我们使用 Deployment 创建标签为 appnginx 的三个 Pod
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 3selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.14.2ports:- containerPort: 80
如下使用 Deployment 创建了三个 Pod。
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-deployment-6b474476c4-hc6k4 1/1 Running 0 7d2h 10.42.1.3 node8 none none
nginx-deployment-6b474476c4-mp8vw 1/1 Running 0 7d2h 10.42.0.7 node10 none none
nginx-deployment-6b474476c4-wh8xd 1/1 Running 0 7d2h 10.42.1.4 node8 none none
接下来我们定义一个名为 my-service 的 Service 资源并指定选择器为 appnginx其中 selector 定义了可以通过 Label selector 访问的 Pod 组。
apiVersion: v1
kind: Service
metadata:name: my-service
spec:selector:app: nginxports:- name: defaultprotocol: TCPport: 80 #service porttargetPort: 80
如下我们成功创建了一个默认类型为 ClusterIP 的 Service 对象并随机分配了一个 ClusterIP 10.109.163.26 此后我们就可以通过该 IP 和 Port 访问到之前创建的 Pod 了Service 的默认方访问模式为轮询模式即轮询将请求转发到后端的各个 Pod。
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
my-service ClusterIP 10.109.163.26 none 80/TCP 4d1h appnginx
为什么需要 Service
Service 在我们使用 Kubernetes 几乎必不可少的一个资源对象主要包括以下原因
集群中的每一个 Pod 都可以通过 PodIP 被直接访问的但是 Kubernetes 中的 Pod 是有生命周期的对象尤其是被 ReplicaSet、Deployment 等对象管理的 Pod随时都有可能由于集群的状态变化被销毁和创建导致 Pod 的 IP 发生变化。Pod 被 Kubernetes 调度到确定的节点后才会为 Pod 分配 IP 地址在启动之前客户端无法知道服务器 Pod 的 IP 地址。水平扩展意味着多个 Pod 可以提供相同的服务每个 Pod 都可以提供相同的服务 Pod 有自己的 IP 地址。客户端不应该关心有多少 Pod 支持服务及其 IP 是什么而且不应该保留所有 Pod 的 IP 列表。相反所有这些 Pod 都应该可以通过单个 IP 地址提供服务。
Service 工作原理
在 Kubernetes 中创建一个新的 Service 对象会涉及到两大模块其中一个模块是控制器它需要在每次客户端创建新的 Service 对象时生成用于暴露一组 Pod 的 Kubernetes 对象也就是 Endpoint 对象另一个模块是 kube-proxy它运行在 Kubernetes 集群中的每一个节点上两大模块同时协作实现了 Service 功能 当我们发起创建 Service 请求时 kube-apiserver 会生成一个 Service 对象并将其保存到 ETCD。Endpoint Controller 在订阅到 Service 创建时会创建对应的 Endpoint 对象。kube-proxy 会订阅 Service 和 Endpoint 变动以此改变节点上 iptables/ipvs 中保存的规则。
接下来会分别介绍这两大模块是何协作实现 Service 功能
Endpoint
如上文所述当我们创建 Service 时同时也会生成如下所示的 Endpoint。
NAME ENDPOINTS AGE
my-service 10.42.0.7:80,10.42.1.3:80,10.42.1.4:80 7d3h
Endpoint 是 Kubernetes 集群中的一个资源对象存储在 Etcd 中从上文可以看到 Endpoint 中保存了一个 Service 对应的所有 Pod 的访问地址Endpoint 的创建和更新是通过 Endpoint Controller当我们通过 API 创建/修改 Service 对象时Endpoints Controller 的 informer 机制监听到 Service对象更新然后根据 Service 的配置的 selector 创建对应 Endpoint 对象此对象将 Pod 的 IP、容器端口做记录并存储到 Etcd这样 Service 只要看一下自己名下的 Endpoint 就可以知道所对应Pod信息了。
Endpoint Controller 是 kube-controller-manager 组件中众多控制器中的一个是 Endpoint 资源对象的控制器其通过对 Service、Pod 两种资源的监听实现对的 Endpoint 资源进行管理主要包括以下功能
负责生成和维护所有 Endpoint 对象负责监听 Service 和对应 Pod 的变化监听到 Service 被删除则删除和该 Service 同名的 Endpoint 对象监听到新的 Service 被创建则根据新建 Service 信息获取相关 Pod 列表然后创建对应 Endpoint 对象监听到 Service 被更新则根据更新后的 Service 信息获取相关 Pod 列表然后更新对应 Endpoint 对象监听到 Pod 事件则更新 endpoint 对象保存的 Pod IP 列表, 如 Pod 处于非健康状态时则把 Pod 从保存的 IP 列表中移除恢复时再重新加入
kube-proxy
kube-proxy 是 Kubernetes 的一个网络代理组件运行在每个 worker 节点上。kube-proxy 维护节点上的网络规则实现了 Kubernetes Service 概念的一部分它的作用是使发往 Service 的流量通过 ClusterIP 和端口负载均衡到正确的后端 Podkube-proxy 支持多种配置模式主要包括 iptable 和 ipvs 模式本文则基于 iptable 模式描述 kube-proxy 的工作原理 kube-proxy 的主要职责包括两大块
监听 Service 更新事件并更新 Service 相关的 iptables 规则。监听 Endpoint 更新事件更新 Endpoint 相关的 iptables 规则, 如 KUBE-SVC-链中的规则会把包请求转入 Endpoint 对应的Pod。如果某个 Service 尚没有 Pod 创建那么针对此 Service 的请求将会被 drop 掉。
在 iptables 模式下,创建 Service 会创建一系列的 iptable 规则
首先我们在任意一台 worker 节点执行 iptables -nvL OUTPUT -t nat 查看 iptables net 表的 output 链存在 kube-proxy 创建的 KUBE-SERVICE 链
Chain OUTPUT (policy ACCEPT 40606 packets, 2435K bytes)
pkts bytes target prot opt in out source destination
15M 929M KUBE-SERVICES all -- * * 0.0.0.0/0 0.0.0.0/0 /* kubernetes service portals */
执行 iptables -nvL KUBE-SERVICES -t nat 查看 KUBE-SERVICES 链可以看到 clusterIP 10.43.7.11 跳转到 KUBE-SVC-KEAUNL7HVWWSEZA6
Chain KUBE-SERVICES (2 references)pkts bytes target prot opt in out source destination0 0 KUBE-SVC-KEAUNL7HVWWSEZA6 tcp -- * * 0.0.0.0/0 10.43.7.11 /* default/my-service: cluster IP */ tcp dpt:80
然后我们执行 iptables -nvL KUBE-SVC-KEAUNL7HVWWSEZA6 -t nat 查看 KUBE-SVC-KEAUNL7HVWWSEZA6 可以看到以不同的概率进行了跳转
Chain KUBE-SVC-KEAUNL7HVWWSEZA6 (1 references)pkts bytes target prot opt in out source destination0 0 KUBE-SEP-SKMF2UJJQ24AYOPG all -- * * 0.0.0.0/0 0.0.0.0/0 /* default/my-service: */ statistic mode random probability 0.333333333490 0 KUBE-SEP-BAKPXLXOJZJDGFKA all -- * * 0.0.0.0/0 0.0.0.0/0 /* default/my-service: */ statistic mode random probability 0.500000000000 0 KUBE-SEP-M4RM3QHTJOBNSPNE all -- * * 0.0.0.0/0 0.0.0.0/0 /* default/my-service: */
最后执行 iptables -nvL KUBE-SEP-SKMF2UJJQ24AYOPG -t nat 查看其中一条通过 DNAT发送到其中一个 Pod 地址 10.42.0.7:80
Chain KUBE-SEP-SKMF2UJJQ24AYOPG (1 references)pkts bytes target prot opt in out source destination0 0 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 /* default/my-service: */ tcp to:10.42.0.7:80
从上问所述可知在 Service 创建时会生成大量的 iptalbes 规则当服务数量非常庞大时 iptables 规则也会成倍增长带来的问题是路由延迟和服务访问延迟而且由于 iptables 使用非增量式更新当规则数量庞大时添加或删除一条规则也有较大延迟, 为了解决该问题所以 kubernetes 在 1.11 之后版本推出了 ipvs 模式。
更多技术文章请访问https://opensource.actionsky.com/
关于 SQLE
爱可生开源社区的 SQLE 是一款面向数据库使用者和管理者支持多场景审核支持标准化上线流程原生支持 MySQL 审核且数据库类型可扩展的 SQL 审核工具。
SQLE 获取
类型地址版本库https://github.com/actiontech/sqle文档https://actiontech.github.io/sqle-docs/发布信息https://github.com/actiontech/sqle/releases数据审核插件开发文档https://actiontech.github.io/sqle-docs/docs/dev-manual/plugins/howtouse
