概述:
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自己设计的一种编程方式的特殊路由规则
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张三丰