有一个入口配置,比如
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: api-https
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: true
nginx.ingress.kubernetes.io/force-ssl-redirect: true
nginx.org/ssl-services: "api,spa"
kubernetes.io/ingress.class: nginx
spec:
tls:
- hosts:
- api.some.com
- www.some.com
secretName: secret
rules:
- host: api.some.com
http:
paths:
- path: /
backend:
serviceName: api
servicePort: 8080
- host: www.some.com
http:
paths:
- path: /
backend:
serviceName: spa
servicePort: 8081
gke创建了nginx ingress负载平衡器,但也创建了另一个具有后端的负载平衡器,就像如果没有选择nginx,而是选择gcp作为ingress一样。
下面的屏幕截图以红色显示了两个意外的LB,蓝色显示了两个nginx ingress LB,分别用于我们的qa和prod env。
kubectl的输出获取服务
xyz@cloudshell:~ (xyz)$ kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
api NodePort 1.2.3.4 <none> 8080:32332/TCP,4433:31866/TCP 10d
nginx-ingress-controller LoadBalancer 1.2.6.9 12.13.14.15 80:32321/TCP,443:32514/TCP 2d
nginx-ingress-default-backend ClusterIP 1.2.7.10 <none> 80/TCP 2d
spa NodePort 1.2.8.11 <none> 8082:31847/TCP,4435:31116/TCP 6d
gcp gke服务视图中错误信息入口的屏幕截图
这是意料之中的吗?
我是否错过了阻止创建此额外负载平衡器的任何配置?
在GKE集群上创建部署时,有两种可能公开它:
如果您可以在负载均衡器中看到它们,这意味着您可能已经创建了服务类型LoadBalancer,然后将其公开为入口。您正在打开相同的部署以从两个不同的IP(按服务和入口)访问。要确认此尝试:
$ kubectl get ingress
$ kubectl get svc
您将从这2个命令中获得2个ips,它们都将向您显示相同的页面。
配置它的更好方法是拥有服务类型NodePort,并将该服务公开为入口。这特别有用,因为您可以使用相同的入口来公开更多服务。
这样可以节省暴露的IP数量(并且不使用多个负载平衡器可以节省资金)。
在GCP GKE上,gcp入口控制器默认启用,并且在任何入口定义中始终会导致一个新的LB,即使指定了. class。
https://github.com/kubernetes/ingress-nginx/issues/3703
因此,要修复它,我们应该从集群中删除gcp入口控制器,如https://github.com/kubernetes/ingress-gce/blob/master/docs/faq/gce.md#how-do-i-disable-the-gce-ingress-controller
在Kubernetes中创建负载平衡器类型的服务时,它是创建一个全新的外部负载平衡器,还是只为负载平衡器类型的第一个服务创建一个负载平衡器,并将该负载平衡器重新用于负载平衡器类型的所有后续服务? 这个问题特别重要,因为为每个服务构建一个单独的负载平衡器对我来说成本太高。 如果它特定于云提供商,我使用Azure,但我很想知道其他云提供商是否不同。
Kubernetes如何知道其上运行的外部云提供商? 是否有任何特定的服务在Master中运行,以确定Kubernetes集群是否在AWS或Google云中运行? 即使它能够找出它是AWS或Google,它从哪里获取凭据来创建外部AWS/Google负载均衡器?我们是否必须在某个地方配置凭据,以便它从那里选择它并创建外部负载均衡器?
我正在尝试设置应用型负载均衡,以将流量转发到AWS中的Nginx入口控制器。要设置Nginx入口控制器,我使用的是从安装说明中获得的YML。 部署后,一切正常,流量正确转发到EKS pod。但是,上面的YML文件正在aws中创建“经典负载均衡器”,因为我想创建“应用型负载均衡器”。我将“service.beta.kubernetes.io/aws-load-balancer-type: elb”更
我有两条溪流。一个是事件流,另一个是数据库更新流。我想用从DB更新流构建的信息丰富事件流。 事件流非常庞大,使用5个字段进行分区。这给了我很好的分配。DB流不那么喋喋不休,并且使用两个字段进行分区。我目前正在使用两个公共字段连接这两个流,并使用flapMap来丰富第一个流。flatMap运算符使用ValueState维护状态,状态由两个公共字段自动键入。 除了实现自定义逻辑来手动提取键并更新维护状
我是微服务的新手。(学习阶段)。我有一个问题。我们在云中部署微服务。(例如 AWS)。云已经提供了负载平衡和日志。我们还在Spring Boot中实现了负载平衡(功能区)和日志(Rabbit MQ和Zipkin)。这两种实现有什么区别?我们两者都需要吗?有些人可以回答这些问题吗? 提前感谢。
所以我正在使用库伯内特斯作为一个辅助项目,它很棒。运行像我这样的小项目更便宜(一个3-5个实例的小集群基本上为我提供了大约30美元/月的GCP所需的一切)。 我唯一努力的领域是尝试使用kubernetes入口资源映射到集群并扇出到我的微服务(它们是小型Go或节点后端)。我有入口映射到不同服务的配置设置,没有问题。 我知道,在创建入口资源时,您可以很容易地让GCP启动负载平衡器。这很好,但这也意味着