问题描述
我有一个运行 2 个随从的 kubernetes 集群.目前，我通过 2 个步骤来访问我的服务:
I have a kubernetes cluster running with 2 minions. Currently I make my service accessible in 2 steps:
- 启动复制控制器 &豆荚
- 获取minion IP(使用
kubectl get minions)并将其设置为服务的publicIPs.
- Start replication controller & pod
- Get minion IP (using
kubectl get minions) and set it as publicIPs for the Service.
向公众公开服务的建议做法是什么?我的方法似乎是错误的，因为我对单个 minion IP-s 的 IP-s 进行了硬编码.它似乎也绕过了 kubernetes 服务的负载平衡功能，因为客户端必须直接访问在单个 Minion 上运行的服务.
What is the suggested practice for exposing service to the public? My approach seems wrong because I hard-code the IP-s of individual minion IP-s. It also seems to bypass load balancing capabilities of kubernetes services because clients would have to access services running on individual minions directly.
设置复制控制器 &我使用的吊舱:
To set up the replication controller & pod I use:
id: frontend-controller
kind: ReplicationController
apiVersion: v1beta1
desiredState:
replicas: 2
replicaSelector:
name: frontend-pod
podTemplate:
desiredState:
manifest:
version: v1beta1
id: frontend-pod
containers:
- name: sinatra-docker-demo
image: madisn/sinatra_docker_demo
ports:
- name: http-server
containerPort: 4567
labels:
name: frontend-pod
设置服务(获取minion ip-s后):
To set up the service (after getting minion ip-s):
kind: Service
id: frontend-service
apiVersion: v1beta1
port: 8000
containerPort: http-server
selector:
name: frontend-pod
labels:
name: frontend
publicIPs: [10.245.1.3, 10.245.1.4]
推荐答案
正如我在上面的评论中提到的，createExternalLoadBalancer 是您正在寻找的合适的抽象，但不幸的是，它还没有为所有云提供商实现，特别是对于您在本地使用的 vagrant.
As I mentioned in the comment above, the createExternalLoadBalancer is the appropriate abstraction that you are looking for, but unfortunately it isn't yet implemented for all cloud providers, and in particular for vagrant, which you are using locally.
一种选择是将集群中所有 Minion 的公共 IP 用于您想要外部化的所有服务.发往该服务的流量将最终到达其中一个 minion 上，在那里它将被 kube-proxy 进程拦截并重定向到与该服务的标签选择器匹配的 pod.这可能会导致跨网络的额外跃点(如果您登陆的节点没有在本地运行 Pod)，但对于对网络延迟不是非常敏感的应用程序，这可能不会引起注意.
One option would be to use the public IPs for all minions in your cluster for all of the services you want to be externalized. The traffic destined for the service will end up on one of the minions, where it will be intercepted by the kube-proxy process and redirected to a pod that matches the label selector for the service. This could result in an extra hop across the network (if you land on a node that doesn't have the pod running locally) but for applications that aren't extremely sensitive to network latency this will probably not be noticeable.
这篇关于如何在不硬编码到 minion IP 的情况下向公众公开 kubernetes 服务?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，WP2