标签: kubernetes-service

我明白

• StatefulSet -管理/维护稳定的主机名，网络ID和永久存储。
• HeadlessService -您需要为状态应用程序定义无头服务的稳定网络ID

FROM K8s Docs->有时您不需要或不需要负载平衡和单个服务IP。在这种情况下，可以通过为群集IP（.spec.clusterIP）指定“无”来创建“无头”服务。

我对“有状态与无状态”应用程序/组件的看法

1. UI属于无状态应用程序/组件，因为它不维护任何数据。但是它来自数据库并显示

2. DB，Cache（Redis的）是有状态应用/组件，因为它具有保持数据的

我的问题。

1. Persistence storage in Apps-为什么要考虑将postgress（例如）部署为StatefulSet？我可以定义PVS和PVC在Deployement将数据存储在PV。即使Pod重新启动，它也会获得PV，因此不会丢失数据。

2. Network-Redis（例如）应该以部署StatefulSet，这样即使在重启Pod之后，我们也可以每次都获得唯一的“网络ID” /名称。例如; Redis-0，Redis-1是StatefulSet的，我可以定义Redis-0为主，所以主name永远不会改变。现在为什么要考虑Headless Service使用StatefulSet应用程序？我可以直接访问/连接POD本身，对吗？有什么用Headless Service？

3. 我听说过Operators，这是管理StatefulSet应用程序的最佳方法。我在下面找到了一些例子。为什么这些（或其他一些）对于作为进行部署很重要StatefulSet。例如，Prometheus或ElasticSearch；我可以定义PVs和PVC存储数据而不会丢失。

   • https://github.com/krallistic/kafka-operator
   • https://github.com/coreos/prometheus-operator
   • https://github.com/upmc-enterprises/elasticsearch-operator

为什么/何时应该关心StatefulSet和Headless Serivice？

我在家里的 Ubuntu 服务器上运行microk8s集群，并将其连接到本地 NAS 服务器以进行持久存储。我一直用它作为学习 Kubernetes 的个人试验场，但我似乎在每一步都会遇到一个又一个问题。

我已经安装了NFS Client Provisioner Helm 图表，我已确认该图表可以正常工作 - 它将在我的 NAS 服务器上动态配置 PVC。我后来能够成功安装Postgres Helm 图表，至少我是这么认为的。创建后，我可以使用 SQL 客户端连接到它，感觉很好。

直到几天后，我注意到 Pod 显示 0/1 容器已就绪。有趣的是，nfs-client-provisioner pod 仍然显示 1/1。长话短说：我已经删除/清除了 Postgres Helm 图表，并尝试重新安装它，但现在它不再起作用。事实上，我尝试部署的任何新内容都不起作用。一切看起来好像都能正常工作，但随后就永远挂在 Init 或 ContainerCreating 上。

特别是对于 Postgres，我运行的命令是这样的：

helm install --name postgres stable/postgresql -f postgres.yaml

我的postgres.yaml文件如下所示：

persistence:
    storageClass: nfs-client
    accessMode: ReadWriteMany
    size: 2Gi

但如果我这样做，kubectl get pods我仍然会看到这个：

NAME                    READY  STATUS    RESTARTS  AGE
nfs-client-provisioner  1/1    Running   1         11d
postgres-postgresql-0   0/1    Init:0/1  0         3h51m

如果我执行 …

关于 NodePort 服务如何路由流量，似乎有两种相互矛盾的解释。服务可以将流量路由到两者之一，而不是两者：

1. 节点（通过 kube-proxy）根据kubectl explain Service.spec.externalTrafficPolicy和这篇增加了更多细节的文章，使用Service.spec.externalTrafficPolicy=Localset传入 NodePort 服务的数据包被路由到 kube-proxy，然后将数据包路由到其运行的相应 pod。
   • 这个kube-proxy 网络文档进一步支持这一理论，并补充说端点在服务的 IPtable 中添加了一个规则，通过 kube-proxy 将流量转发到节点。
2. 荚：服务更新从他们的IPtables endpoints，其中包含IP地址的豆荚，他们可以路线。此外，如果您删除服务的标签选择器并编辑端点，您可以更改流量路由到的位置。

如果其中一个是正确的，那么我一定是误解了一些东西。

• 如果服务路由到节点，那么为什么我可以在endpoints不破坏 IPtables 的情况下进行编辑？
• 如果服务路由到pods，那么为什么服务会在Service.spec.externalTrafficPolicy设置时遇到路由到节点的麻烦？

我正在尝试访问 clusterip 服务（通过 docker-for-mac 在我的笔记本电脑上运行 kubernetes）。

按照此处的说明，我能够像这样成功地 ping 服务：

kubectl run curl --image=radial/busyboxplus:curl -i --tty
curl -v http://10.106.1.204:8000/api/v0.1/predictions -d '{"foo": "bar"}' -H "Content-Type: application/json"

但我无法使用服务名称而不是 ip 使其工作。然后我尝试按照此处所述使用 kubectl 代理，但无法使其正常工作：

kubectl proxy --port=8080 &
curl -v http://127.0.0.1:8080/api/v1/proxy/namespaces/deploy-test/services/10.106.1.204:8000/api/v0.1/predictions

这给了我 404 错误以及以下所有内容：

curl -v http://127.0.0.1:8080/api/v1/proxy/namespaces/deploy-test/services/10.106.1.204:8000
curl -v http://127.0.0.1:8080/api/v1/proxy/namespaces/deploy-test/services/10.106.1.204:8000/predictions
curl -v http://127.0.0.1:8080/api/v1/proxy/namespaces/deploy-test/services/10.106.1.204:8000/api/v0.1/predictions

以及替换的所有组合8000用http在所有的上述和/或与服务名称的IP。

我可以确认代理正在正常http://127.0.0.1:8080/api/v1/namespaces/deploy-test/pods工作。

这是服务的描述。请注意，我特别尝试通过 clusterip 访问它，而不是使用 Ambassador。

kubectl describe svc -n deploy-test template-product-app-seldon-prediction-service
Name:              template-product-app-seldon-prediction-service
Namespace:         deploy-test
Labels:            seldon-app=template-product-app-seldon-prediction-service
                   seldon-deployment-id=template-product-app-seldon-prediction-service
Annotations: …

我有一个主服务和多个从服务。主服务使用来自 Google PubSub 的订阅者不断轮询主题。从属服务是 REST API。一旦主服务接收到消息，它将消息委托给从服务。目前我在 Kubernetes 中使用 ClusterIP 服务。我的一些请求很长，有些很短。

我碰巧观察到，有时如果在处理长时间运行的请求时有一个短时间运行的请求，它必须等到长时间运行的请求完成，即使许多 pod 可用而没有提供任何流量。我认为这是由于循环负载平衡。我一直在尝试寻找解决方案，并研究了诸如使用入口和内部 HTTP 负载平衡器设置外部 HTTP 负载平衡器之类的方法。但是我真的很困惑这两者之间的区别以及哪一个适用于我的用例。你能建议哪种方法可以解决我的用例吗？

我想将我的服务部署为 ClusterIP，但无法将其应用于给定的错误消息：

[xetra11@x11-work coopr-infrastructure]$ kubectl apply -f teamcity-deployment.yaml 
deployment.apps/teamcity unchanged
ingress.extensions/teamcity unchanged
The Service "teamcity" is invalid: spec.ports[0].nodePort: Forbidden: may not be used when `type` is 'ClusterIP'

这是我的 .yaml 文件：

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: teamcity
  labels:
    app: teamcity
spec:
  replicas: 1
  selector:
    matchLabels:
      app: teamcity
  template:
    metadata:
      labels:
        app: teamcity
    spec:
      containers:
      - name: teamcity-server
        image: jetbrains/teamcity-server:latest
        ports:
        - containerPort: 8111
---
apiVersion: v1
kind: Service
metadata:
  name: teamcity
  labels:
    app: teamcity
spec:
  type: ClusterIP
  ports:
  - …

我正在学习kubernetes的无头服务。

我毫无疑问地理解以下内容（如果我错了，请纠正我）：

• 无头服务没有集群 IP，
• 它用于与有状态应用程序通信
• 当客户端应用程序容器/pod 通过无头服务与数据库 pod 通信时，将返回 pod IP 地址而不是服务的 IP 地址。

我不太确定的是：

• 在我看来，互联网上许多解释无头服务的文章都很模糊。因为我发现的所有内容都只是直接陈述如下：

如果你不需要负载均衡，但想直接连接到pod（例如数据库），你可以使用headless服务

但这到底是什么意思呢？

因此，以下是我对 k8s 中无头服务的想法以及两个带有示例的问题

假设我在一个服务后面有 3 个 PostgreSQL 数据库实例的副本，如果它是一个常规服务，我知道默认情况下对数据库的请求将以循环方式路由到三个数据库 Pod 之一。这确实是一个负载平衡。

问题一：

如果使用无头服务，上面引用的语句是否意味着无头服务将坚持使用三个数据库 pod 之一，并且永远不会更改，直到 pod 死亡？我问这个问题是因为否则如果不坚持使用三个 Pod 之一，它仍然会进行负载平衡。有人可以澄清一下吗？

问题2：

我觉得无论是常规服务还是无头服务，客户端应用程序只需要知道服务的 DNS 名称即可与 k8s 集群中的数据库进行通信。不是这样吗？我的意思是，那么使用无头服务有什么意义呢？对我来说，只有当客户端应用程序代码确实需要知道它所连接的 Pod 的 IP 地址时，无头服务才有意义。因此，只要客户端应用程序不需要知道 IP 地址，它始终可以通过集群中的服务 DNS 名称通过常规服务或无头服务与数据库进行通信，我在吗？