常见类型的yaml文件如何编写?--kind: Service

基本说明

在 Kubernetes 中,Service 是一种抽象的方式,用于定义一组 Pod 的访问方式和网络服务。Service 提供了一个稳定的网络端点(Endpoint),使得其他服务或外部用户可以通过 Service 来访问被管理的 Pod。

负载均衡:Service 可以将流量均匀地分发到一组后端 Pod。通过使用 Service,您无需直接暴露和管理单个 Pod,而是通过访问 Service 来获得 Pod 的负载均衡能力。

服务发现:Service 使用标签选择器(selector)来识别一组后端 Pod。Pod 上的标签指定了所属的 Service,Service 根据标签选择器找到相应的 Pod,以便进行流量路由和负载均衡。这样,无论 Pod 在何处创建和删除,Service 都能自动调整,以便始终将流量导向匹配的 Pod。

抽象网络:Service 为后端 Pod 提供一个抽象的网络地址和端口。通过 Service,您可以在不影响应用程序的情况下调整后端 Pod 的网络配置。Service 还可以隐藏 Pod 背后的实际 IP 地址和端口,提供更方便和安全的访问方式。

内部和外部访问 :Service 在 Kubernetes 集群内提供内部访问,也可以通过外部负载均衡器实现外部访问。Service 的类型(Type)可以配置为 ClusterIP、NodePort、LoadBalancer 或 ExternalName,以定义不同的访问方式。

通过创建和管理 Service 对象,您可以使应用程序能够以灵活、可扩展且可靠的方式对外提供服务,并根据需要进行流量管理和请求转发。

基本样例

创建 kind: Service 对象需要至少定义以下字段:

复制代码
apiVersion: v1   
kind: Service
metadata:
  name: my-service       # Service 的名称
spec:
  selector:
    app: my-app          # 用于选择要控制的 Service的标签
  ports:                 # 定义 Service 暴露的端口。可以指定名称、协议和端口号等信息。
    - name: http         # 端口的命名
      port: 80           # 对外的暴漏的端口号
      targetPort: 8080   # 监控的内部的端口

样例说明

在上面的示例中,列出了一些常用的关键字和其含义,如下所示:

  • apiVersion: Service 对象的 API 版本。在这个示例中,我们使用 v1 版本的 API。

  • kind: 定义对象类型为 Service。

  • metadata:此字段包含了 Service 对象的元数据,如名称、标签等。

  • spec: Service 的规范,用于定义 Service 的行为。

    • selector:此字段定义了后端 Pod 的选择器,即该 Service 所负责的 Pod 的标签选择器。后端 Pod 必须包含此标签才能被 Service 管理。在上述例子中,选择器指定了标签 app: my-app,这意味着该 Service 负责管理标签为 app: my-app 的 Pod。

    • ports:此字段定义了服务对外公开的端口及其对应的目标端口。例如,在上述例子中,Service 对外公开的端口是 80 端口,后端 Pod 监听的端口是 8080 端口。

扩展字段

除了上述字段之外,kind: Service 还有其他可用的选项,例如:

  • spec.type:定义 Service 的类型,如 ClusterIP、NodePort、LoadBalancer 、ExternalName等。在示例中使用的是 ClusterIP 类型,它会为 Service 分配一个集群内部 IP 地址,使其他 Pod 内部能够通过该 IP 地址和端口访问 Service。

  • spec.externalIPs:指定一个或多个外部 IP 地址,Service 将绑定到这些 IP。

  • spec.loadBalancerIP:指定一个公有云提供商 IP 负载均衡器的 IP 地址。

  • spec.clusterIP:手动指定 Service 的 IP 地址。

  • spec.ports.protocol:定义端口使用的协议,如 TCP、UDP 等。

  • spec.sessionAffinity:定义负载均衡算法,如 ClientIP、None 等。

  • spec.externalName:Service 的类型为 ExternalName 时,定义向外部服务的别名。

相关推荐
March.s4 小时前
Kubernetes 全景导览:从部署演进到云原生底座
云原生·kubernetes·dubbo
熊出没5 小时前
云原生架构落地实践:Kubernetes 生产级配置与 Service Mesh 流量治理
云原生·架构·kubernetes·istio
CCblandy12 小时前
一致性哈希到底省了多少搬迁?本机实测 3 轮:取模 6→7 搬 85.8%,V=128 只搬 14.3%,虚拟节点太少会被倾斜骗
后端·python·云原生·性能优化·架构
code_slave(码畜)12 小时前
微服务架构落地:OpenFeign 服务远程调用 + 线程池隔离架构实战 —— 超时控制、重试机制、线程池隔离,防雪崩
spring boot·spring cloud·微服务·云原生·架构·openfeign
涵美女程序猿13 小时前
ChatCut online 剪微服务熔断测试录屏:仪表盘告警、降级日志与恢复时刻怎样对应
程序人生·微服务·云原生·架构·电脑
古城小栈13 小时前
Docker Compose 云原生的底座
docker·云原生·容器
分布式存储与RustFS15 小时前
训练集放在 RustFS 上,怎么像本地盘一样快?用 Curvine 加一层 POSIX 缓存
运维·云原生·开源·对象存储·分布式存储·s3·性能基准
easy_coder15 小时前
Kubernetes 三大探针:Startup、Liveness 与 Readiness
云原生·容器·kubernetes
KIDULT°17 小时前
Kubeadm 部署 Kubernetes v1.30.2 实战:Ubuntu24.04 三节点集群 + 排坑记录
ubuntu·云原生·容器·kubernetes·k8s
阿里云云原生1 天前
AgentLoop 审计:如何让企业级 Dify 应用的风险看得见、查得清
云原生·agent