今天开始来分享Service 的基础知识，后续我们可以慢慢打磨，分享 Service 的进阶知识和原理
Service 基本概念
Service 是 K8S 最核心的概念了
我们可以通过创建 Service ，为一组具有相同功能的容器应用提供一个统一的入口地址，并且可以将请求分发到后端的各个容器应用上
我们来看看完成的 Service 是什么样子的，我们来手写一份
apiVersion: v1
kind: Service
metadata:
name: service name
namespace:
labels:
- name: label name
annotations:
- name: annotations name
spec:
selector: []
type: string
clusterIP: spec ip
sessionAffinity: string
ports:
- name: ports name
protocol: tcp/udp
port: int
targetPort: int
nodePort: int
status:
loadBalancer:
ingress:
ip: string
hostname: string
整一张表来解释一下上面某些字段的含义
| 属性字段 | 值类型 | 必须？ | 说明 |
|---|---|---|---|
| metadata.labels[] | list | no | 自定义属性标签 |
| metadata.annotations[] | list | no | 自定义注解标签 |
| spec.selector[] | list | yes | 配置 label selector 选择具有指定 label 标签的pod 作为管理范围 |
| spec.type | string | yes |
service 的类型 – ClusterIP 虚拟服务的 ip，用于 K8S 内部 的pod 相互访问 – NodePort 使用的是宿主机的端口，外部可以通过访问 node 的 ip 和端口，就可以达到访问内部服务的目的 – loadBalancer 使用外接的负载均衡器完成到服务的负载分发，需要在 loadBalancer 字段处指定外部负载均衡器的 ip 地址，并且同时需要定义 ClusterIP 和 NodePort |
| spec.ClusterIP | string | no | 虚拟服务的 ip 地址 如果 spec.type 指定的是 loadBalancer ，那么这个 ip 就需要写，其他的情况，可以不写，系统默认分配 |
| spec.sessionAffinity | string | no | 是否支持 session 默认值是空，可以填我们的 ClusterIP 功能是，将一个源 IP 地址的客户端访问的请求，都转发到同一个后端 pod |
| spec.ports[].port | int | no | 内部服务监听的端口 |
| spec.ports[].targetPort | int | no | 需要转发到 pod 的端口号 |
| spec.ports[].nodePort | int | no | 指定映射到物理机的端口号，这个时候需要 spec.type=NodePort |
| spec.status | object | no | 属于外部均衡器，status 下面的都是 外部均衡器的配置了 |
Service 的名称定义
对于 service 的对象名称的定义也是需要遵循规范的
点我查看名称定义
例如截一个官方说明的图
关于 service 的端口
定义 service 的时候，我们可以定义 1 个端口，也可以定义 多个端口的
例如这样的是 service 的 1 个端口 ，官方的案例是内部服务监听 80 端口，会转发到 pod 的 9376 端口，用的是 tcp 协议
这样的是 2 个端口，属于 service 的多端口定义
例如我们的服务开了多个端口，这些端口是不能定义冲突的，我们必须要定义好每个端口的名称，端口号，以及协议，不能有歧义，如下：
上述的 1 个端口和多个端口，都是 服务监听的端口号，都是作为服务端的，需要客户端来访问的
外部的 service
如果是我们的 service 需要访问外部的一个服务，需要和外部进行一个连接，例如数据库服务，或者访问外部的一个集群的时候，我们需要如何写我们的 service 呢？
我们可以通过在 yaml 中 创建一个 无 Label Selector 的 Service 实现
我们仔细看一下，上面官方写的 1 个端口 和 多个端口的 yaml，都会使用 Label Selector 来指定一个 app，目的是为了运行起来之后能够关联到对应的 pod
例如这样
那么我们来写一个 无 Label Selector 的服务吧
- 无 Label Selector 的 Service
apiVersion: v1
kind: Service
metadata:
name: xiaomotong-svc
spec:
ports:
- protocol: TCP
port: 80
targetPort: 80写完这个 service 发现，他不知道如何去找到 pod 的，那么我们可以写一个 endpoints，名称需要和 上面这个service 的名称一致，这样 endpoints 指定的 pod ，就可以被 上面这个service 访问到了
- 写一个 Endpoints
apiVersion: v1
kind: Endpoints
metadata:
name: xiaomotong-svc
subsets:
- addresses:
- IP: 10.253.33.3
ports:
- port: 8080 这样写，将 Endpoints 要和 上面的 service 就对应起来的， 感兴趣的 xdm 可以在自己的 k8s 集群上面玩一玩， 此处写的 subsets.addresses.IP 是一个能够运行的 pod ip
今天就到这里，学习所得，若有偏差，还请斧正
欢迎点赞，关注，收藏
朋友们，你的支持和鼓励，是我坚持分享，提高质量的动力
好了，本次就到这里
技术是开放的，我们的心态，更应是开放的。拥抱变化，向阳而生，努力向前行。
我是阿兵云原生，欢迎点赞关注收藏，下次见~
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
相关推荐: RestTemplate：简化HTTP请求的强大工具
文章目录 什么是RestTemplate RestTemplate的作用 代码示例 RestTemplate与HttpClient 什么是RestTemplate RestTemplate是一个在Java应用程序中发送RESTful HTTP请求的强大工具。本…
