为什么 Kubernetes 部署不支持服务？答案

【问题标题】：Why don't Kubernetes deployments support services?为什么 Kubernetes 部署不支持服务？
【发布时间】：2019-08-11 22:10:30
【问题描述】：

我是 K8s 的新手，所以仍在努力解决问题。我一直在关注 deployments 并且可以理解它们的用处。但是，我不明白他们为什么不支持服务（只有副本集和 pod）。

这是为什么？这是否意味着服务通常会部署在部署之外？

【问题讨论】：

标签： kubernetes

【解决方案1】：

是的，服务应该部署为单独的对象。注意deployment是用来升级或回滚镜像，在ReplicaSet之上工作

Kubernetes Pod 是必死的。他们出生，当他们死去时，他们并没有复活。 ReplicaSet 尤其是动态地创建和销毁 Pod（例如，在向外扩展或向内扩展时）。虽然每个 Pod 都有自己的 IP 地址，但即使是这些 IP 地址也不能随着时间的推移而保持稳定。这导致了一个问题：如果一组 Pod（我们称它们为后端）为 Kubernetes 集群内的其他 Pod（我们称它们为前端）提供功能，那么这些前端如何找出并跟踪该集合中的哪些后端？

Services.com 来救援。 Kubernetes 服务是一种抽象，它定义了一组逻辑 Pod 和访问它们的策略。 Service 所针对的 Pod 集合（通常）由标签选择器确定

【讨论】：

我了解服务的目的。我不明白的是为什么它们不能在部署对象以及 pod/副本集中描述。

【解决方案2】：

我认为它打算解耦和细粒度。

【讨论】：

【解决方案3】：

为了回答您的问题，Kubernetes 部署用于管理在集群中运行的无状态服务，而不是为有状态应用程序运行时构建的 StatefulSets。实际上，通过部署，您可以描述在实现过程中必须创建的所有底层对象的更新策略和路线图。因此，我们可以区分一些对象确定的单独规范字段，例如 Pod 的需要副本数，Pod 的模板通过描述应该在 Pod 中的容器列表等。

然而，正如@P Ekambaram 在他的回答中已经提到的那样，Services 表示 Kubernetes 集群内部网络通信模型的抽象层，他们声明了一种通过对应的Endpoints 访问集群内 Pod 的方法。服务与部署对象清单规范是分开的，因为它们的任务是为嵌套的 Pod 动态提供特定的网络行为，而不会在通过适当的服务Types 进行任何通信修改时影响或重新启动它们。

【讨论】：

【解决方案4】：

我刚刚学到的一些与我的问题有些相关的东西：多个 K8s 对象可以包含在同一个 yaml 文件中，由--- 分隔。比如：

apiVersion: v1
kind: Deployment
# other stuff here
---
apiVersion: v1
kind: Service
# other stuff here

【讨论】：