k8s服务发现和负载均衡-摩杜云开发者社区

概述：

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

举个例子，考虑一个图片处理 backend，它运行了3个副本。这些副本是可互换的 —— frontend 不需要关心它们调用了哪个 backend 副本。然而组成这一组 backend 程序的 Pod 实际上可能会发生变化，frontend 客户端不应该也没必要知道，而且也不需要跟踪这一组 backend 的状态。Service 定义的抽象能够解耦这种关联。

对 Kubernetes 集群中的应用，Kubernetes 提供了简单的 Endpoints API，只要 Service 中的一组 Pod 发生变更，应用程序就会被更新。对非 Kubernetes 集群中的应用，Kubernetes 提供了基于 VIP 的网桥的方式访问 Service，再由 Service 重定向到 backend Pod。

对一些应用（如 Frontend）的某些部分，可能希望通过外部（Kubernetes 集群外部）IP 地址暴露 Service。

Service 类型

ClusterIP：通过集群的内部 IP 暴露服务，选择该值，服务只能够在集群内部可以访问，这也是默认的 ServiceType。
NodePort：通过每个 Node 上的 IP 和静态端口（NodePort）暴露服务。NodePort 服务会路由到 ClusterIP 服务，这个 ClusterIP 服务会自动创建。通过请求 :，可以从集群的外部访问一个 NodePort 服务。
LoadBalancer：使用云提供商的负载局衡器，可以向外部暴露服务。外部的负载均衡器可以路由到 NodePort 服务和 ClusterIP 服务。
ExternalName：通过返回 CNAME 和它的值，可以将服务映射到 externalName 字段的内容（例如， foo.bar.example.com）。没有任何类型代理被创建，这只有 Kubernetes 1.7 或更高版本的 kube-dns 才支持。

定义 Service

一个 Service 在 Kubernetes 中是一个 REST 对象，和 Pod 类似。像所有的 REST 对象一样， Service 定义可以基于 POST 方式，请求 apiserver 创建新的实例。例如，假定有一组 Pod，它们对外暴露了 8080、8089等等端口，同时还被打上 “app=restapi” 标签。

apiVersion: v1
kind: Service
metadata:
  name: restapi
spec:
  selector:
    app: restapi
  ports:
  - name: dev
    port: 8080
    targetPort: dev #该处为前文章deployment 定义的port，可以由名称来引用
  - name: prod
    port: 8088
    targetPort: prod
  - name: https
    port: 443
    targetPort: https

上述配置将创建一个名称为 “restapi” 的 Service 对象，它会将请求代理到使用 TCP 端口 8080，并且具有标签 “app=restapi” 的 Pod 上。这个 Service 将被指派一个 IP 地址（通常称为 “Cluster IP”），它会被服务的代理使用（见下面）。该 Service 的 selector 将会持续评估，处理结果将被 POST 到一个名称为 “restapi” 的 Endpoints 对象上。

需要注意的是， Service 能够将一个接收端口映射到任意的 targetPort。默认情况下，targetPort 将被设置为与 port 字段相同的值。可能更有趣的是，targetPort 可以是一个字符串，引用了 backend Pod 的一个端口的名称。但是，实际指派给该端口名称的端口号，在每个 backend Pod 中可能并不相同。对于部署和设计 Service ，这种方式会提供更大的灵活性。例如，可以在 backend 软件下一个版本中，修改 Pod 暴露的端口，并不会中断客户端的调用。

Kubernetes Service 能够支持 TCP 和 UDP 协议，默认 TCP 协议。

在k8s内部，nodeip网、podip网和clusterip网之间的通信，采用的是k8s自己设计的一种编程方式的特殊路由规则

k8s服务发现和负载均衡_消息中间件_02

service如何进行服务发现

service可以将pod ip封装起来，即使pod发生重建，依然可以通过service来访问pod提供的服务，service还解决了负载均衡的问题

运行在每个node上的kube-proxy进程其实就是一个智能的软件负载均衡器，他负责把service的请求转发到后端的某个pod实例。

kube-dns可以解决Service的发现问题，k8s将Service的名称当做域名注册到kube-dns中，通过Service的名称就可以访问其提供的服务

------------------- 消息中间件Rabbitmq ----------------------------------

消息中间件Rabbitmq（01）

消息中间件Rabbitmq（02）

消息中间件Rabbitmq（03）

消息中间件Rabbitmq（04）

消息中间件Rabbitmq（05）

消息中间件Rabbitmq（06）

消息中间件Rabbitmq（07）

------------------- ---------- 云计算 -------------------------------------

云计算（1）——docker的前世今生

云计算（2）—— 体系结构

云计算（3）—— 容器应用

云计算（4）—— LAMP

云计算（5）—— Dockerfile云计算（6）—— harbor

云计算（7）—— 网络

云计算（8）—— jekins(1)

云计算（9）—— jekins(2)

关注公众号 soft张三丰

k8s服务发现和负载均衡_云计算_03