尤里卡和 Kubernetes [英] Eureka and Kubernetes
问题描述
我正在整理一个概念证明,以帮助识别同时使用 Spring Boot/Netflix OSS 和 Kubernetes 的问题.这也是为了证明Prometheus、Graphana等相关技术.
我有一个 Eureka 服务设置,它在我的 Kubernetes 集群中没有问题.这被命名为发现,并被命名为discovery-1551420162-iyz2c".添加到 K8 时使用
对于我的配置服务器,我试图根据逻辑 URL 使用 Eureka,因此在我的 bootstrap.yml 中我有
服务器:端口:8889尤里卡:实例:主机名:配置服务器客户:registerWithEureka: truefetchRegistry: 真服务网址:默认区域:http://discovery:8761/eureka/春天:云:配置:服务器:吉特:uri:https://github.com/xyz/microservice-config
我开始使用
kubectl run configserver --image=xyz/config-microservice --replicas=1 --port=8889
此服务最终运行,名为 configserver-3481062421-tmv4d.然后,我在配置服务器日志中看到异常,因为它试图定位 eureka 实例但无法定位.
我在本地使用 docker-compose 和链接进行了相同的设置,它可以毫无问题地启动各种容器.
发现:图片:xyz/discovery-microservice端口:- 8761:8761"配置服务器:图像:xyz/config-microservice端口:- 8888:8888"链接:- 发现
如何设置 eureka.client.serviceUri 之类的东西,以便我的微服务可以在不知道 K8 集群内固定 IP 地址的情况下定位它们的对等点?
如何设置 eureka.client.serviceUri 之类的东西?
你必须在 eureka pods/deployments 之上有一个 Kubernetes service然后将为您提供可参考的 IP 地址和端口号.然后使用该可引用地址查找 Eureka 服务,而不是8761".
进一步解决Eureka HA配置问题
每个 k8s 服务不应有超过一个 Eureka 的 pod/副本(请记住,pod 是短暂的,您需要一个可引用的 IP 地址/域名用于 eureka 服务注册表).要实现高可用性 (HA),请在每个 Pod 中启动更多 k8s 服务.
- Eureka 服务 1 --> 单个 Pod
- Eureka Service 2 --> 另一个 Pod
- ...
- ...
- Eureka Service n --> 另一个 pod
所以,现在你的每个 Eureka 都有可引用的 IP/域名(k8s 服务的 IP)..现在它可以相互注册了.
感觉有点矫枉过正?如果您的所有服务都在同一个 kubernetes 命名空间中,您可以通过 k8s 服务 + KubeDNS 附加组件实现 eureka 提供的所有内容(嗯,几乎所有内容,除了客户端负载平衡).阅读 Christian Posta 的这篇文章>
编辑
您可以使用 StatefulSets 正如 Stefan Ocke 指出的那样.
<块引用>与 Deployment 一样,StatefulSet 管理基于相同的容器规格.与 Deployment 不同,StatefulSet 维护每个 Pod 的粘性身份.这些 Pod 是从相同的规格,但不可互换:每个都有一个持久的它在任何重新调度期间维护的标识符.
I am putting together a proof of concept to help identify gotchas using Spring Boot/Netflix OSS and Kubernetes together. This is also to prove out related technologies such as Prometheus and Graphana.
I have a Eureka service setup which is starting with no trouble within my Kubernetes cluster. This is named discovery and has been given the name "discovery-1551420162-iyz2c" when added to K8 using
For my config server, I am trying to use Eureka based on a logical URL so in my bootstrap.yml I have
server:
port: 8889
eureka:
instance:
hostname: configserver
client:
registerWithEureka: true
fetchRegistry: true
serviceUrl:
defaultZone: http://discovery:8761/eureka/
spring:
cloud:
config:
server:
git:
uri: https://github.com/xyz/microservice-config
and I am starting this using
kubectl run configserver --image=xyz/config-microservice --replicas=1 --port=8889
This service ends up running named as configserver-3481062421-tmv4d. I then see exceptions in the config server logs as it tries to locate the eureka instance and cannot.
I have the same setup for this using docker-compose locally with links and it starts the various containers with no trouble.
discovery:
image: xyz/discovery-microservice
ports:
- "8761:8761"
configserver:
image: xyz/config-microservice
ports:
- "8888:8888"
links:
- discovery
How can I setup something like eureka.client.serviceUri so my microservices can locate their peers without knowing fixed IP addresses within the K8 cluster?
How can I setup something like eureka.client.serviceUri?
You have to have a Kubernetes service on top of the eureka pods/deployments which then will provide you a referable IP address and port number. And then use that referable address to look up the Eureka service, instead of "8761".
To address further question about HA configuration of Eureka
You shouldn't have more than one pod/replica of Eureka per k8s service (remember, pods are ephemeral, you need a referable IP address/domain name for eureka service registry). To achieve high availability (HA), spin up more k8s services with one pod in each.
- Eureka service 1 --> a single pod
- Eureka Service 2 --> another single pod
- ..
- ..
- Eureka Service n --> another single pod
So, now you have referable IP/Domain name (IP of the k8s service) for each of your Eureka.. now it can register each other.
Feeling like it's an overkill? If all your services are in same kubernetes namespace you can achieve everything (well, almost everything, except client side load balancing) that eureka offers though k8s service + KubeDNS add-On. Read this article by Christian Posta
Edit
Instead of Services with one pod each, you can make use of StatefulSets as Stefan Ocke pointed out.
Like a Deployment, a StatefulSet manages Pods that are based on an identical container spec. Unlike a Deployment, a StatefulSet maintains a sticky identity for each of their Pods. These pods are created from the same spec, but are not interchangeable: each has a persistent identifier that it maintains across any rescheduling.
这篇关于尤里卡和 Kubernetes的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!