Kubernetes之Service详解，kubernetes client

本文将从Service的发布方式、Service控制器的实现原理、使用规范等方面详细介绍Kubernetes中的Services。

一、Kubernetes 中的pod有哪些暴露服务的方式

Kubernetes 中暴露服务的每种方法都有自己的优点和缺点，根据您的具体使用场景和需求选择合适的方法非常重要。以下是每种方法的优缺点的快速概述：

1. Service (服务)

集群IP:

优势：

它高度安全，只能在集群内访问。高性能，无需通过网络传输。 缺点：

无法从集群外部直接访问它。节点端口：

优势：

通过节点的IP地址和指定端口可以直接访问服务。它相对简单明了，适合测试和开发环境。 缺点：

它的端口范围有限，不适合大规模使用。公共端口必须可由集群节点IP 访问。负载平衡器：

优势：

您可以自动创建外部负载均衡器以实现流量负载均衡和高可用性。支持集群外部直接访问。 缺点：

对云服务提供商支持的依赖可能会增加成本。配置和部署相对复杂，可能会导致延迟和额外的网络开销。外部名称：

优势：

提供一种将服务映射到外部服务别名的简单方法。不需要额外的代理或中间件。 缺点：

您只能将您的服务公开为外部DNS 记录，并且无法管理或路由您的流量。

2. Ingress (入口)

优势：

允许定义复杂的HTTP/HTTPS 规则和路径，并提供高级负载平衡功能。轻松管理多种服务的传入流量，提高灵活性和可维护性。 缺点：

配置和管理很复杂，并且需要额外的入口控制器来处理流量。需要额外的DNS 记录或负载均衡器来管理流量路由。

3. Port Forwarding (端口转发)

优势：

它简单、直接，适合单个Pod 的开发和调试。无需额外的网络配置或负载平衡器。 缺点：

它不适合生产环境，并且无法扩展到多个Pod 或多用户。取决于当地环境和网络连接稳定性。

4. ExternalIP (外部 IP)

优势：

服务可以与集群外部的指定IP地址关联，为您提供极大的灵活性。不需要额外的负载均衡器或路由器配置。 缺点：

这可能会造成IP 地址冲突和安全风险，必须谨慎管理。它不适合动态IP地址环境，例如云计算中的IP分配。

5. Headless Service (无头服务)

优势：

直接暴露每个pod的IP地址，适合一些特定的服务发现需求。它简单易用，不需要额外的代理或路由配置。 缺点：

需要额外的DNS 解析配置，这可能会影响性能和可维护性。不支持负载平衡和流量管理。

总结

应根据您的具体业务需求、安全需求、性能需求和云基础设施支持来选择合适的服务暴露方式。例如，在生产环境中，您可能会选择使用LoadBalancer或Ingress来管理流量并提高可用性，但在开发和测试阶段，NodePort或Port Forwarding更方便实用。综合考虑不同方式的优缺点，可以有效满足不同场景下的服务发布需求。

二、Deployment 、service、pod、container之前的关系

在Kubernetes 中，服务实现原理包括部署、服务、pod 和容器等多个组件。下面结合逻辑示意图详细介绍这些部件之间的关系及其工作原理。

组件关系和工作原理

介绍

定义应用程序的所需状态，包括Pod 数量、映像版本和更新策略。管理Pod 创建、更新和删除，以确保实际状态与所需状态匹配。服务

它在后台抽象出一组Pod，并提供稳定的网络访问方式。通过标签选择器选择关联的Pod。提供负载均衡和服务发现功能。荚

Kubernetes 中最小的可调度单元，由一个或多个容器组成。每个Pod 都有唯一的IP 地址，并共享网络和存储资源。容器

在Pod 内运行的实际应用程序实例。通过容器运行时（例如Docker）管理生命周期。

Service 的实现原理

定义并注册您的服务

当用户创建Service对象时，API服务器接收请求并将其存储在etcd中。 Service 对象包含服务名称、选择器、类型和端口等信息。端点对象

Kubernetes 自动创建并维护一个端点对象，其中包含与您的服务关联的pod 的IP 地址和端口。使用标签选择器选择目标Pod。 kube-proxy 组件

它运行在每个节点上，负责实现服务的网络代理功能。通过iptables、ipvs 或用户空间模式处理流量和负载平衡。 负载均衡和服务发现

kube-proxy 根据Endpoints 对象的IP 地址和端口转发流量。内置DNS 服务为每个服务创建DNS 记录，应用程序通过其DNS 名称访问服务。

逻辑示意图

下面是部署、服务、Pod 和容器之间关系的示意图。

+———————-+ +———+ +—— – ——- —+

| |

| 展开|—-|

| |

+——+ +———-+————+ +——– — ——– — +

|

| 选择

|

+————v————+

| |

| 端点|

| |

+————+————+

|

| 指向

|

+————v————+

| |

| 吊舱|

|（副本1）|

| |

+————+————+

|

包含|

|

+————v————+

| |

| 集装箱|

| |

+———————-+

解释

Deployment: 管理副本数量并更新Pod 策略，以确保您的应用程序按预期运行。 Service:通过标签选择器选择符合条件的Pod，并提供稳定的网络入口。 Pod:运行一个或多个容器，并为每个容器提供共享的网络和存储环境。在Container: Pod 内运行的实际应用程序实例通过容器运行时管理其生命周期。

该示意图展示了Kubernetes 组件之间的关系以及服务实现的基本原理。通过这些组件的协作，Kubernetes可以提供稳定高效的服务发现和负载均衡能力。

三、Service控制器工作流程

在Kubernetes 中，Service 控制器负责管理Service 对象和相关的Endpoints 对象。这可确保Service 始终匹配与其选择器匹配的Pod。下面是服务控制器的工作流程及其逻辑调用图。

Service 控制器的逻辑调用流程

定义并创建Service:

用户使用kubectl 或其他工具创建Service 对象。 Kubernetes API 服务器接收请求并将Service 对象存储在etcd 中。服务控制器监听：

服务控制器通过API服务器监听服务对象的创建、更新和删除事件。 更新端点：

当Service控制器检测到Service对象发生变化时，它会根据Service的选择器搜索所有匹配的Pod。服务控制器创建或更新包含所有目标Pod 的IP 地址和端口的Endpoints 对象。 kube-proxy 配置：

kube-proxy 监听API 服务器上Endpoints 对象的更改。 kube-proxy 根据Endpoints 对象更改更新iptables、ipvs 或用户空间代理规则，以确保流量正确定向到Pod。

逻辑调用示意图

下面是服务控制器的逻辑调用示意图。

+———————-+ +———————-+ +- — — —————+

| |

| 用户/客户|

|（kubectl 等）|

| |

+————+———-+ +————+————+ +— — – —-+———+

| |

| 创建服务|

+———————-|

| |

| |

| etcd 商店服务|

| +———————————+

| |

| 检测服务变化|

| |

| +———————————+

| |

| 查询匹配Pod |

| +————————————————

| |

| 创建/更新|

| 端点对象|

| +———————————+

| |

| 通知kube 代理。

| 更改端点|

| +———————————+

| |

+————v————+ +————v——— —+ +– —- —-v———-+

| |

| 库贝代理|

| |

+————+———-+ +————+————+ +— — – —-+———+

| |

| 获取端点|

+————————————————+ |

| |

| 更新iptables/ipvs/。

| 用户空间规则|

+————————– |

| |

+————v————+ +————v——— —+ +– —- —-v———-+

| |

| 集装箱|

| |

+———————-+ +———————-+ +- — — —————+

详细步骤说明

用户创建的服务：

用户通过kubectl向API服务器提交服务资源定义。 API 服务器对Service 对象进行身份验证并将其存储在etcd 中。服务控制器监听服务对象：

服务控制器监听API 服务器上服务对象的事件（创建、更新、删除）。当检测到新的Service对象或者Service对象发生变化时，Service控制器执行相应的操作。 更新端点对象：

Service 控制器根据Service 的选择器找到匹配的Pod。创建或更新Endpoints 对象以包含所有目标Pod 的IP 地址和端口。将Endpoints 对象的更改保存到etcd。 kube-proxy 配置：

kube-proxy 监视Endpoints 对象的更改。当检测到Endpoints 对象发生更改时，kube-proxy 会更新本地iptables、ipvs 或用户空间代理规则。验证流量是否正确路由到与您的服务关联的Pod。

通过上述步骤，Kubernetes 的服务控制器确保服务始终与其选择器匹配的pod 一致，从而允许通过kube-proxy 进行正确的流量路由和负载平衡。

四、Deploymen与Service使用规范

在生产环境中，部署和服务使用规范的结合可以让运维工程师更好地管理服务，保证应用的高可用性、可扩展性和易维护性。以下是一些推荐的使用指南和最佳实践。

Deployment 规范

使用版本标签管理图像

使用不同的映像版本标记（例如v1.0.0）而不是最新版本，以便您可以跟踪和控制版本。 适当设置份数

确保部署中定义的副本数量满足您的高可用性要求。使用horizontal pod autoscaler根据负载自动调整副本数量。 配置资源请求和限制

针对每个容器设置CPU和内存资源的请求和限制，以便Kubernetes更好地调度和管理资源。 配置健康检查

配置livenessProbe 和readinessProbe 以确保pod 运行状况和服务可用性。未通过运行状况检查的Pod 将重新启动或从服务中删除。 滚动更新策略

采用滚动更新策略（RollingUpdate）逐步替换旧的Pod，保证更新过程中服务的连续性。更新过程可以通过maxUnavailable 和maxSurge 参数来控制。

Service 规范

请选择合适的服务类型

根据您的应用程序需求选择适当的服务类型（ClusterIP、NodePort、LoadBalancer、ExternalName）。内部服务使用ClusterIP，外部访问使用LoadBalancer。 配置服务选择器

使用标签选择器显式指定与您的服务关联的Pod，以确保流量正确路由到目标Pod。 使用无头服务

对于需要直接访问Pod 的应用程序（例如StatefulSet），请使用无头服务（无clusterIP:）。服务发现和DNS

利用Kubernetes 内置的DNS 服务为每个服务创建DNS 记录，应用程序通过其DNS 名称访问服务，以避免直接依赖IP 地址。

网络和安全性

网络策略

使用网络策略来控制Pod 之间的网络流量并提高集群的安全性。定义允许和拒绝的流量规则，以确保只有需要通信的Pod 才能互相访问。 负载均衡和反向代理

使用Ingress 控制器管理HTTP 和HTTPS 流量、定义Ingress 资源并配置路由规则。验证外部流量是否正确路由到内部服务。 TLS 和证书管理

配置Ingress 控制器以使用TLS 进行加密通信。使用Cert-Manager 自动管理TLS 证书的创建和续订。

监控和日志

日志管理

使用集中式日志管理系统（例如ELK Stack或Loki）来收集和分析Pod日志。允许永久存储和检索日志。 监控报警

使用Prometheus 和Grafana 等监控工具监控集群和应用程序的状态。正确设置

的报警规则，及时发现和响应异常情况。

灾备和恢复

定期备份

定期备份 etcd 数据，确保集群配置和状态的持久化。使用工具（如 Velero）进行集群和应用数据的备份和恢复。 灾难恢复演练

定期进行灾难恢复演练，验证备份和恢复流程的有效性。确保在实际灾难发生时能够迅速恢复服务。

配置管理和自动化

配置管理

使用 ConfigMap 和 Secret 管理应用配置和敏感信息。确保配置的灵活性和安全性。 自动化工具

使用 Helm 或 Kustomize 管理应用的部署和配置。利用 CI/CD 工具（如 Jenkins、GitLab CI）实现自动化部署和持续集成。

示例 YAML 配置

以下是一个示例 YAML 配置，结合了 Deployment 和 Service 的最佳实践：

apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
labels:
app: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
– name: my-container
image: my-image:v1.0.0
resources:
requests:
memory: \”64Mi\”
cpu: \”250m\”
limits:
memory: \”128Mi\”
cpu: \”500m\”
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 15
periodSeconds: 20
readinessProbe:
httpGet:
path: /readiness
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
—
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-app
ports:
– protocol: TCP
port: 80
targetPort: 8080
type: ClusterIP

通过遵循上述规范和最佳实践，可以帮助运维工程师更好地管理 Kubernetes 中的 Deployment 和 Service，确保应用程序的稳定性、可扩展性和安全性。

完。

希望对您有用！关注锅总，可及时获得更多运维实用操作！

#以上关于Kubernetes之Service详解的相关内容来源网络仅供参考，相关信息请以官方公告为准！