kubernetes service（十分钟了解kubernetes的核心概念）

本文目录

• 十分钟了解kubernetes的核心概念
• Kubernetes——Service(SVC)服务
• 【K8s 精选】Kubernetes Service 介绍
• 简述Kubernetes Service分发后端的策略
• 简述Kubernetes Service类型
• kubernetes(九) Service介绍、类型及使用
• 简述Kubernetes Metric Service
• Kubernetes Service原理解析
• k8s的Service详解

十分钟了解kubernetes的核心概念

下文将简单介绍 kubernetes 的核心概念。因为这些定义可以 kubernetes 的官档中找到， 中文文档地址 ，所以下文中也会避免用大段枯燥的文字介绍。相反，我们会使用一些图表和示例来解释这些概念，借助它们我们可以全面理解晦涩难懂的一些概念。

kubernetes （k8s）是自动化容器操作的开源平台，这些操作包括布署，调度和节点集群间扩展。如果你曾经用docker容器技术布署容器，那么可以将docker看成kubernetes内部使用的低级别组件。kubernetes不仅仅支持docker，还支持rocker（另一种容器技术）。

使用kubernetes拥有下面的特点：

实际上，kubernetes只需一个部署文件，使用一条命里就可以布署多层容器（前后端）的完整集群。

集群是一组节段，这些节点可以是物理服务器或者虚拟机，之上安装了kubernetes平台。下图展示这样的集群，注意概图为了强调核心概念有所简化。

上图可以看到如下组件，使用特别的图标表示Service和Label：

Pod（上图绿色框）安排在节点上，包括一组容器和卷。同一个Pod里面的容器共享一个命名网络空间，可以使用localhost互相通信。Pod是短暂的，不是持续性实体。你可以有下面的问题：

如上图所示，一些Pod有Label。一个Label是attach到Pod的一对键值对，用来传递用户定义的属性。比如你可能创建了一个"tier"和"app"标签，通过Label(tier=frontend, app=myapp)来标记前端Pod容器，使用Label(tier=backend, app=myapp)标记后台容器，然后可以使用Seletors选择带有特定标签Label的Pod，并且将Service或Replication Controller应用到上面。

是否手动创建Pod，如果想要创建同一个容器的多份拷贝，需要一个个分别创建出来么？能否将Pods划分到逻辑组里面去。

Replication Controller确保任意时间都有着指定数量的Pod副本在运行。如果为某个Pod创建了Replication Controller并制定3个副本，它会创建3个副本，并且持续监控它们。如果某个Pod不响应，那么Replication Controller会替换它，

如果之前不响应的Pod恢复了，现在就有了4个Pod，那么Replication Controller就会将其中一个终止并保持总数为3。如果在运行中将副本总数改为5，Replication Controller就会立即启动2个新的Pod，保证总数为5。还可以按照这样的方式缩小Pod，这个特性在执行滚动升级时比较有用。

当创建Replication Controller时，需要执行两个东西：

现在已经创建了Pod的副本，那么在这些副本上如何进行均衡负载？我们需要的是Service。

如果Pods是短暂的。那么重启时IP地址可能会发生变化，怎么才能从前端容器正确可靠的指向后端容器呢？

Service是定义一些列Pod以及访问这些Pod的策略的一层抽象。 Service通过Label找到Pod组。因为Service是抽象的，所以在图表中通常看不到它们的存在，这也就让这一概念更难理解。

现在，假定有两个后台Pod，并定义后台Service的名称为‘backend-service’，label选择器为（tier=backend, app=myapp）。backend-service会完成如下两件重要的事情：

下图动画展示了Service的功能。注意该图做了很多简化。如果不进入网络配置，那么达到透明的负载均衡目标所涉及的底层网络和路由相对先进。

有一个特别类型的Kubernetes Service，称为‘LoadBlancer’，作为外部负载均衡器使用，在一定数量的Pod之间负暂均衡。

节点（上橘色方框）是物理机或虚拟机，作为kubernetes worker，通常称为Minion。每个节点都运行如下Kubernetes关键组件：

集群拥有一个Kubernetes Master（紫色方框）。Kubernetes Master提供集群的独特视角，并且拥有一系列组件，如Kubernetes API Service。API Server提供可以用来和集群交互的REST端点。master节点包括用来创建和复制Pod的Replication Controller。

十分钟带你理解Kubernetes核心概念

再下面会继续理解属于和概念，最后尝试使用。

Kubernetes——Service(SVC)服务

Kubernetes Service定义了这样一种抽象：一个Pod的逻辑分组，一种可以访问它们的策略 —— 通常称为微服务。这一组Pod能够被Service访问到，通常是通过Label Selector

Service能够提供负载均衡的能力，但是在使用上有以下限制：

Service 在 K8s 中有以下四种类型

svc基础导论

在 Kubernetes 集群中，每个 Node 运行一个kube-proxy进程。kube-proxy负责为Service实现了一种VIP（虚拟 IP）的形式，而不是ExternalName的形式。在 Kubernetes v1.0 版本，代理完全在 userspace。在Kubernetes v1.1 版本，新增了 iptables 代理，但并不是默认的运行模式。从 Kubernetes v1.2 起，默认就是iptables 代理。在 Kubernetes v1.8.0-beta.0 中，添加了 ipvs 代理

在 Kubernetes 1.14 版本开始默认使用ipvs 代理

在 Kubernetes v1.0 版本，Service是 “4层”（TCP/UDP over IP）概念。在 Kubernetes v1.1 版本，新增了Ingress API（beta 版），用来表示 “7层”（HTTP）服务

为何不使用 round-robin DNS？
DNS会在很多的客户端里进行缓存，很多服务在访问DNS进行域名解析完成、得到地址后不会对DNS的解析进行清除缓存的操作，所以一旦有他的地址信息后，不管访问几次还是原来的地址信息，导致负载均衡无效。

这种模式，kube-proxy 会监视 Kubernetes Service对象和Endpoints，调用netlink接口以相应地创建ipvs 规则并定期与 Kubernetes Service对象和Endpoints对象同步 ipvs 规则，以确保 ipvs 状态与期望一致。访问服务时，流量将被重定向到其中一个后端 Pod

与 iptables 类似，ipvs 于 netfilter 的 hook 功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意味着 ipvs 可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外，ipvs 为负载均衡算法提供了更多选项，例如：

注意： ipvs模式假定在运行kube-proxy之前在节点上都已经安装了IPVS内核模块。当kube-proxy以ipvs代理模式启动时，kube-proxy将验证节点上是否安装了IPVS模块，如果未安装，则kube-proxy将回退到iptables代理模式

clusterIP 主要在每个 node 节点使用 iptables，将发向 clusterIP 对应端口的数据，转发到 kube-proxy 中。然后 kube-proxy 自己内部实现有负载均衡的方法，并可以查询到这个 service 下对应 pod 的地址和端口，进而把数据转发给对应的 pod 的地址和端口

为了实现图上的功能，主要需要以下几个组件的协同工作：

创建 myapp-deploy.yaml 文件

创建 Service 信息

有时不需要或不想要负载均衡，以及单独的Service IP。遇到这种情况，可以通过指定 ClusterIP(spec.clusterIP)的值为“None”来创建 Headless Service。这类Service 并不会分配 Cluster IP,kube-proxy 不会处理它们，而且平台也不会为它们进行负载均衡和路由
主要的特点是通过无头服务的方式去解决hostname和portname的变化问题，也就是通过它去进行绑定

对于svc，一旦创建成功以后，它会写入到coreDNS中去，我们的svc的创建会有一个主机名会被写入到coreDNS，写入的格式体就是 svc的名称+命名空间的名称+当前集群的域名

意味着在无头服务中，虽然它没有ip了，但可以通过访问域名的方案依然可以访问服务下的pod

nodePort的原理在于在node上开了一个端口，将向该端口的流量导入到kube-proxy，然后由 kube-proxy进一步到给对应的pod

loadBalancer和nodePort 其实是同一种方式。区别在于 loadBalancer 比nodePort多了一步，就是可以调用cloud provider【云供应商】 去创建LB【负载均衡】来向节点导流

这种类型的 Service 通过返回 CNAME和它的值，可以将服务映射到externalName字段的内容（例如：hub.yibo.cn)。ExternalName Service 是Service的特例，它没有 selector，也没有定义任何的端口和Endpoint。相反的，对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务

当查询主机 my-service.defalut.svc.cluster.local（SVC_NAME.NAMESPACE.svc.cluster.local)时，集群的DNS 服务将返回一个值my.database.example.com的CNAME记录。访问这个服务的工作方式和其他的相同，唯一不同的是重定向发生在DNS层，而且不会进行代理或转发。

***隐藏网址***
***隐藏网址***
***隐藏网址***

参考：
***隐藏网址***

***隐藏网址***

【K8s 精选】Kubernetes Service 介绍

问题1： 为什么需要服务发现
① 容器 Pod 生命周期短暂，容器 IP 地址随时变化
② Deployment 中的 Pod 组需要统一的访问入口和负载均衡
③ 应用在不同部署环境需要统一部拓扑和访问方式

问题2： 如何提供外部访问和负载均衡的能力
Kubernetes Service 具备服务发现和负载均衡的功能，即 一方面提供了统一的访问入口，另一方面负载均衡到后端 Pod 。下图是 Service 的简约架构图，左侧表示 Service 提供了外部访问和 Pod 网络访问 ，右侧表示对接了一组 Pod，同时把请求负载均衡到这组 Pod。

① APIServer ：Kubernetes 所有对象都会注册到 APIServer上，监听这些对象的变化，例如 Pod、StatefulSet、Service 等。
② Controller Manager ：负责配置 LoadBalance 的一个负责均衡器给外部访问。
③ Coredns ：负责把 Service 名字（类似域名）解析为 Service 虚拟 IP 即 ClusterIP，同时观测 Service 的变化。
④ Kube-proxy ：负责把 Service 虚拟 IP 即 ClusterIP 转换为后端 Pod IP，同时观测后端 Pod 的变化。

如上架构图示例，Client Pod3 访问 Service 的步骤：
① Coredns 解析出 CluserIP ：Client Pod3 拿着 Service name （域名）请求 Coredns，Coredns 解析域名后返回 ClusterIP。
② Kube-proxy 拦截后负载均衡到后端 Pod ：Client Pod3 拿着 ClusterIP 请求宿主机网络后，被 Kube-proxy 所配置的 iptables 拦截了，随后负债均衡转发到后端 Pod。

① LoaderBalancer 转发请求到某节点的 NodePort ：外部请求通过 LoaderBalancer 转发到某节点的 NodePort，同时 LoaderBalander 通过 Controller Manager 监听 Service 的变化。
② Kube-proxy 把 NodePort 转换为 ClusterIP 并转发到后端 Pod ：NodePort 的请求被 Kube-proxy 所配置的 iptables 拦截并转发到 CluserIP，最终转发到后端 Pod。

① 直接使用 ClusterIP

② 直接使用 Service Name，Codedns 解析
{servicename}.{namespace}.svc.cluster.local

③ 使用环境变量访问

① 通过 Service Name 可以直接解析到所有后端 Pod IP
② 客户端可以自主选择需要访问的 Pod IP

简述Kubernetes Service分发后端的策略

Service负载分发的策略有：RoundRobin和SessionAffinity
RoundRobin：默认为轮询模式，即轮询将请求转发到后端的各个Pod上。
SessionAffinity：基于客户端IP地址进行会话保持的模式，即第1次将某个客户端发起的请求转发到后端的某个Pod上，之后从相同的客户端发起的请求都将被转发到后端相同的Pod上。我推荐你去看看时速云，他们是一家全栈云原生技术服务提供商，提供云原生应用及数据平台产品，其中涵盖容器云PaaS、DevOps、微服务治理、服务网格、API网关等。大家可以去体验一下。 如果我的回答能够对您有帮助的话，求给大大的赞。

简述Kubernetes Service类型

通过创建Service，可以为一组具有相同功能的容器应用提供一个统一的入口地址，并且将请求负载分发到后端的各个容器应用上。其主要类型有：
ClusterIP：虚拟的服务IP地址，该地址用于Kubernetes集群内部的Pod访问，在Node上kube-proxy通过设置的iptables规则进行转发；
NodePort：使用宿主机的端口，使能够访问各Node的外部客户端通过Node的IP地址和端口号就能访问服务；
LoadBalancer：使用外接负载均衡器完成到服务的负载分发，需要在spec.status.loadBalancer字段指定外部负载均衡器的IP地址，通常用于公有云。我推荐你去看看时速云，他们是一家全栈云原生技术服务提供商，提供云原生应用及数据平台产品，其中涵盖容器云PaaS、DevOps、微服务治理、服务网格、API网关等。大家可以去体验一下。
如果我的回答能够对您有帮助的话，求给大大的赞。

kubernetes(九) Service介绍、类型及使用

在kubernetes中，pod是应用程序的载体，我们可以通过pod的ip来访问应用程序，但是pod的ip地址不是固定的，这也就意味着不方便直接采用pod的ip对服务进行访问。

为了解决这个问题，kubernetes提供了Service资源，Service会对提供同一个服务的多个pod进行聚合，并且提供一个统一的入口地址。通过访问Service的入口地址就能访问到后面的pod服务。

Service在很多情况下只是一个概念，真正起作用的其实是kube-proxy服务进程，每个Node节点上都运行着一个kube-proxy服务进程。当创建Service的时候会通过api-server向etcd写入创建的service的信息，而kube-proxy会基于监听的机制发现这种Service的变动，然后 它会将最新的Service信息转换成对应的访问规则 。

规则有iptables，ipvs等，简单介绍下ipvs规则

10.97.97.97:80 是service提供的访问入口，当访问这个入口的时候，可以发现后面有三个pod 的服务在等待调用，kube-proxy 会基于rr（轮询）的策略，将请求分发到其中一个pod上去，这个规则会同时在集群内的所有节点上都生成，所以在任何一个节点上访问都可以。

kube-proxy目前支持三种工作模式:
userspace 模式
userspace模式下，kube-proxy会为每一个Service创建一个监听端口，发向Cluster IP的请求被Iptables规则重定向到kube-proxy监听的端口上，kube-proxy根据LB算法选择一个提供服务的Pod并和其建立链接，以将请求转发到Pod上。 该模式下，kube-proxy充当了一个四层负责均衡器的角色。由于kube-proxy运行在userspace中，在进行转发处理时会增加内核和用户空间之间的数据拷贝，虽然比较稳定，但是效率比较低。

iptables 模式
iptables模式下，kube-proxy为service后端的每个Pod创建对应的iptables规则，直接将发向Cluster IP的请求重定向到一个Pod IP。 该模式下kube-proxy不承担四层负责均衡器的角色，只负责创建iptables规则。该模式的优点是较userspace模式效率更高，但不能提供灵活的LB策略，当后端Pod不可用时也无法进行重试。

ipvs 模式
ipvs模式和iptables类似，kube-proxy监控Pod的变化并创建相应的ipvs规则。ipvs相对iptables转发效率更高。除此以外，ipvs支持更多的LB算法。

此模式必须安装ipvs内核模块，否则会降级为iptables，开启ipvs

Service的资源清单文件：

type：

在使用service之前，首先利用Deployment创建出3个pod，注意要为pod设置 app=nginx-pod 的标签
创建deployment.yaml，内容如下：

是集群内部地址，只能通过Node集群内部访问，创建service-clusterip.yaml文件

Endpoint

Endpoint是kubernetes中的一个资源对象，存储在etcd中，用来记录一个service对应的所有pod的访问地址，它是根据service配置文件中selector描述产生的。

一个Service由一组Pod组成，这些Pod通过Endpoints暴露出来， Endpoints是实现实际服务的端点集合 。换句话说，service和pod之间的联系是通过endpoints实现的。

负载分发策略
对Service的访问被分发到了后端的Pod上去，目前kubernetes提供了两种负载分发策略：

在某些场景中，开发人员可能不想使用Service提供的负载均衡功能，而希望自己来控制负载均衡策略，针对这种情况，kubernetes提供了HeadLiness Service，这类Service不会分配Cluster IP，如果想要访问service，只能通过service的域名进行查询。

创建service-headliness.yaml

在之前的样例中，创建的Service的ip地址只有集群内部才可以访问，如果希望将Service暴露给集群外部使用，那么就要使用到另外一种类型的Service，称为NodePort类型。NodePort的工作原理其实就是 将service的端口映射到Node的一个端口上 ，然后就可以通过 NodeIp:NodePort 来访问service了。

创建service-nodeport.yaml

LoadBalancer和NodePort很相似，目的都是向外部暴露一个端口，区别在于LoadBalancer会在集群的外部再来做一个负载均衡设备，而这个设备需要外部环境支持的，外部服务发送到这个设备上的请求，会被设备负载之后转发到集群中。

ExternalName类型的Service用于引入集群外部的服务，它通过 externalName 属性指定外部一个服务的地址，然后在集群内部访问此service就可以访问到外部的服务了。

简述Kubernetes Metric Service

在Kubernetes从1.10版本后采用Metrics Server作为默认的性能数据采集和监控，主要用于提供核心指标（Core Metrics），包括Node、Pod的CPU和内存使用指标。
对其他自定义指标（Custom Metrics）的监控则由Prometheus等组件来完成。我推荐你去看看时速云，他们是一家全栈云原生技术服务提供商，提供云原生应用及数据平台产品，其中涵盖容器云PaaS、DevOps、微服务治理、服务网格、API网关等。大家可以去体验一下。
如果我的回答能够对您有帮助的话，求给大大的赞。

Kubernetes Service原理解析

Service 是为一组具有相同功能的Pod提供一个统一的入口地址，并将请求进行负载均衡地分发到各个Pod上。

ClusterIP类型的Service是Kubernetes集群默认的Service, 它只能用于集群内部通信。不能用于外部通信。K8s会为每个Service分配一个虚拟IP，即ClusterIP。这个虚拟IP只能在集群内部访问。

。NodePort类型的Service会在集群内部的所有Node节点打开一个指定的端口。之后所有的流量直接发送到这个端口之后，就会转发的Service去对真实的服务进行访问。

LoadBalancer类型的Service通常和云厂商的LB结合一起使用，用于将集群内部的服务暴露到外网，云厂商的LoadBalancer会给用户分配一个IP,之后通过该IP的流量会转发到你的Service。

Ingress 其实不是Service的一个类型，但是它可以作用于多个Service，作为集群内部服务的入口。Ingress 能做许多不同的事，比如根据不同的路由，将请求转发到不同的Service上等等。

虽然Service解决了Pod的服务发现问题，但不提前知道Service的IP，怎么发现service服务呢？k8s提供了两种方式进行服务发现：

endpoint是k8s集群中的一个资源对象，存储在etcd中，用来记录一个service对应的所有pod的访问地址。service配置selector，endpoint controller才会自动创建对应的endpoint对象；否则，不会生成endpoint对象。
例如，k8s集群中创建一个名为k8s-classic-1113-d3的service，就会生成一个同名的endpoint对象，如下图所示。其中ENDPOINTS就是service关联的pod的ip地址和端口。

endpoint controller是k8s集群控制器的其中一个组件，其功能如下：

kube-proxy负责service的实现，即实现了k8s内部从pod到service和外部从node port到service的访问。
kube-proxy作为一个控制器，作为k8s和Linux kernel Netfilter交互的一个枢纽。监听kubernetes集群Services和Endpoints对象的变化，并根据kube-proxy不同的模式(iptables or ipvs), 对内核设置不同的规则，来实现路由转发。

在Iptables模式下，kube-proxy通过在目标node节点上的Iptables中的NAT表的PREROUTIN和POSTROUTING链中创建一系列的自定义链(这些自定义链主要是”KUBE-SERVICE”链， “KUBE-POSTROUTING”链，每个服务对应的”KUBE-SVC-XXXXXX”链和”KUBE-SEP-XXXX”链)，然后通过这些自定义链对流经到该Node的数据包做DNAT和SNAT操作从而实现路由，负载均衡和地址转化。

kube-proxy中，客户端的请求数据包在Iptables规则中具体的匹配过程为:

通过上面的这个设置便实现了基于Iptables实现了负载均衡。但是Iptbles做负载均衡存在一些问题:

***隐藏网址***

k8s的Service详解

Pod是非永久性资源，会动态创建和销毁，pod的ip会变化。这会导致一类Pod（业务1）访问另一类Pod（业务2）需要找出并跟踪Pod（业务2）的IP地址，再者Pod（业务2）是多个的，如何提供负载均衡呢？虽然Pod1通过轮询一组Pod的ip可以实现，但会Pod就需要增加负载均衡的逻辑，Pod就变得不纯粹了，不符合单一设计原则。于是有了Service，把一类Pods上的应用程序抽象成服务，并提供可以访问他们的策略。

有两种方式： 选择算符的Service 和 没有选择算符的Service

这是最常见的方式，指定 spec.selector 即通过打标签的方式，主要是针对集群内部同命名空间的Pod

创建上面的Service,会自动创建相应的 Endpoint 对象

查看自动创建的Endpoint对象

主要是针对希望服务指向另一个名字空间或者其他集群中的服务，比如外部的ES集群

此服务没有选择算符，因此不会自动创建相应的 Endpoint 对象, 需要手动动添加 Endpoint 对象，将服务手动映射到运行该服务的网络地址和端口

该模式下，节点上kube-proxy 持续监听 Service 以及 Endpoints 对象的变化，并设置进本地节点iptables，请求反向代理全部交给 iptables 来实现。每个Node节点都会配置所有Service进iptables，当捕获到Service的clusterIP和端口请求，利用注入的iptables，将请求重定向到Service的对应的Pod，v1.2版本之后的默认模式。

通过查看iptables规则可以看到：

kube-proxy 在 iptables 模式下随机选择一个后端Pod，利用Pod 就绪探测器验证Pod是否正常，kube-proxy只会把正常的Pod写入iptables，避免流量进入不正常的Pod。

kube-proxy 会监视 Kubernetes 控制平面对 Service 对象和 Endpoints 对象的添加和移除操作。 对每个 Service，它会在本地 Node 上打开一个端口（随机选择）。请求先经过iptables规则，当捕获到达Service 的 clusterIP和 Port 的请求，并重定向到代理端口（kube-proxy），再由代理端口再代理请求到后端Pod（v1.2版本之前的默认模式）

IPVS模式是利用linux的IPVS模块实现，同样是由kube-proxy实时监视集群的service和endpoint，调用netlink接口相应的创建ipvs规则，由ipvs实现负载均衡访问。IPVS 专为负载平衡而设计，并基于内核内哈希表，有更高的网络流量吞吐量（iptables 模式在大规模集群 比如10000 个服务中性能下降显著），并且具有更复杂的负载均衡算法（最小连接、局部性、 加权、持久性）。（v1.8以后新支持的）

上面讲的Pod之间调用，采用Service进行抽象，服务之间可以通过clusterIP 进行访问调用，不用担心Pod的销毁重建带来IP变动，同时还能实现负载均衡。但是clusterIP也是有可能变动，况且采用IP访问始终不是一种好的方式。通过 DNS 和 环境变量 可以实现通过服务名现在访问。

k8s采用附加组件（CoreDNS）为集群提供DNS服务，会为每个服务创建DNS记录，CoreDNS只为Service和Pod创建DNS记录。kubernetes强烈推荐采用DNS方式.

例如，如果你在 Kubernetes 命名空间 my-ns 中有一个名为 my-service 的服务， 则控制平面和 DNS 服务共同为 my-service.my-ns 创建 DNS 记录。 my-ns 命名空间中的 Pod 应该能够通过按名检索 my-service 来找到服务，其他命名空间中的 Pod 必须将名称限定为 my-service.my-ns 。 这些名称将解析为为服务分配的集群 IP。

***隐藏网址***

当 Pod 运行在 Node上，kubelet 会为每个活跃的 Service 添加一组环境变量。 简单的 {SVCNAME}_SERVICE_HOST 和 {SVCNAME}_SERVICE_PORT 变量。 这里 Service 的名称需大写，横线被转换成下划线。

举个例子，一个名称为 nginx-svc 的 Service 暴露了 TCP 端口 8080， 同时给它分配了 Cluster IP 地址 10.0.0.11，这个 Service 生成了如下环境变量：

进入example容器，env打印环境变量：

访问Nginx服务可以使用