Kerbernetes的Service资源管理
作者：尹正杰
版权声明：原创作品，谢绝转载！否则将追究法律责任。
一.Service概述
1>.为什么需要Service资源
我们知道在Kubernetes当中运行的基本单元是Pod,其它资源都是为了丰富Pod本身的应用而实现的，比如Service可以为Pod提供一个固定的访问接口，并且尝试着能够为Pod动态变动提供一个服务发现机制的基础单元。
在K8S之上服务就是指Service资源，而服务注册，服务发现都是借助于Service在K8S集群上所跑的CoreDNS服务实现的，因此CoreDNS也是围绕我们的基础服务构建的。
Pod对象的动态性会给客户端带来困扰:
Pod资源对象存在生命周期且不可重现,必要对仅能创建一个新的替代者。
Pod对象在其控制器进行应用规模进行伸缩时,同一个应用程序的Pod对象会增加或减少。
Service资源为动态管理的Pod对象添加一个有着固定访问入口的抽象层:
Service通过标签选择器关联至拥有相关标签的Pod对象。
客户端向Service进行请求，而非目标Pod对象。
2>.Service及Proxy Mode
简单来讲,一个Service对象就是工作节点上的一组iptables或者ipvs规则，用于将到达Service对象IP地址的流量调度转发至相应的Endpoint对象指向的IP地址和端口之上。 工作与每个工作节点的kube-proxy组件通过API service持续健康着各Service及其关联的Pod对象，并将其创建或变动实时反映至当前工作节点上相应的iptables或者ipvs规则。 kube-proxy把请求代理至相应端点的方式有三种:userspace(用户空间,目前已经被废弃),iptables和ipvs。
3>.Service的代理代理模型
userspace代理模型:
userspace是指Linux操作系统上的"用户空间"。
对于每个Service对象,kube-proxy会随机打开一个本地端口，任何到达此代理端口的连接请求都将被通过SNAT转发至当前Service资源对象的后端各Pod对象。
Kubernetes 1.1及之前版本的默认模型，默认调度算法是轮询(round-robin)
kube-proxy还会为此类的Service对象创建iptables规则以捕获达到ClusterIP和端口的流量。
iptables代理模型:
对于每个Service对象,kube-proxy会创建iptables规则直接捕获到达ClusterIP和Port的流量,并将其重定向至当前Service对象的后端Pod资源。
对于每个Endpoints对象，Service资源会为其创建iptables规则并关联至挑选的的后端Pod资源对象;
相对于用户空间模型来说，iptables模型无需将流量再用户空间和内核空间来回切换,因此也就更为高效和可靠。
ipvs代理模型:
Kubernetes字1.9-alpha起引入ipvs代理模式,且自1.11版本起成为默认设置。
kube-proxy跟踪API Server上Service和Endpoints对象的变动,据此来调用netlink接口创建ipvs规则,并确保与API Server中的变动保持同步。
它与iptables规则的不同之处仅在于其请求流量的调度功能由ipvs实现，余下的其它功能仍由iptables完成。
类似于iptable模型,ipvs构建与netfilter的钩子函数之上,但它使用hash表作为底层数据结构并工作于内核空间,因此具有流量转发速度快,规则同步性能好的特性;
另外,ipvs支持众多的调度算法,例如:rr,lc,dh,sh,sed和nq等。
二.定义Service资源案例
编写服务(Service)规范:
selector
ports
不带选择器的服务(Service)：
服务通常抽象地访问Kubernetes Pods，但它们也可以抽象其他类型的后端。
您希望在生产中有一个外部数据库集群，但在测试中使用自己的数据库。
您要将服务指向另一个命名空间或另一个群集上的服务。
你把你的工作量导入了Kubernetes ，你的一些后端运行在Kubernetes 之外。
在这些场景中，您可以在不使用选择器的情况下定义服务：
由于此服务没有选择器，因此不会创建相应的Endpoints对象。
您可以手动将服务映射到自己的特定Endpoints对象。
[root@master200.yinzhengjie.org.cn ~]# kubectl explain service KIND: Service VERSION: v1 DESCRIPTION: Service is a named abstraction of software service (for example, mysql) consisting of local port (for example 3306) that the proxy listens on, and the selector that determines which pods will answer requests sent through the proxy. FIELDS: apiVersion <string> APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources kind <string> Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds metadata <Object> Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata spec <Object> Spec defines the behavior of a service. https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status status <Object> Most recently observed status of the service. Populated by the system. Read-only. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status [root@master200.yinzhengjie.org.cn ~]# [root@master200.yinzhengjie.org.cn ~]#