当前位置: 首页 > 知识库问答 >
问题:

库伯内特斯云提供商

丁学
2023-03-14

我是Kubernetes的新手,他们的概念我不太清楚:云提供商。

  • 我已经使用RKE(Rancher引擎)安装了我的库伯内特斯集群。
  • 我的集群设置在rancher2的顶部。
  • 我的节点是托管OVH服务器的虚拟机。

我设法让运行中的应用程序具有L7入口和ClusterIP服务,但每次我尝试使用L4负载平衡器时,负载平衡器都处于挂起状态。根据https://github.com/rancher/rancher/issues/14424这是因为我没有任何CloudProvider。

但云提供商的确切目的是什么?是不是要运行Kubernetes节点、吊舱。。。在云端?如果是的话,如果我的应用程序已经在云中,并且由于我的配置,可以从外部访问,那么我为什么还要麻烦找一个云提供商呢。

因此,我的以下问题是:

  • CloudProvider的角色到底是什么?
  • 在我的环境中有用吗?
  • 是否必须使用CloudProvider才能运行L4负载均衡器?
  • L4负载均衡器的替代方案是什么?
  • 我不能拥有不依赖于此处列出的其中之一的自定义CloudProvider吗:https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/?就像运行NGINX或其他东西的自托管CloudProvider一样?

感谢您对此问题的任何澄清/建议-

共有1个答案

周阳波
2023-03-14

以防牧场主

外部云提供者是一个kubernetes控制器,它运行kubernetes运行所需的特定于云提供者的循环。这些循环最初是库贝控制器管理器的一部分,但它们将库贝控制器管理器与云提供者特定代码紧密耦合。为了释放这种依赖关系的kubernetes项目,引入了云控制器管理器。

这就引出了Kubernetes云控制器管理器的主题

库伯内特斯v1.6引入了一个新的二进制文件,称为云控制器管理器。云控制器管理器是一个嵌入特定于云的控制循环的守护程序。这些特定于云的控制循环最初位于库贝控制器管理器中。由于与库伯内特斯项目相比,云提供商的开发和发布速度不同,因此将提供商特定的代码抽象为云控制器管理器二进制文件允许云供应商独立于核心库伯内特斯代码进行发展。

关于负载平衡器部件:

  • 有一个指南显示了如何创建外部负载平衡器。上面写着:

您需要有一个库伯内特斯集群,并且必须将kubectl命令行工具配置为与您的集群通信。

  • 但是,如果您需要其他选择,您可能需要使用入口

管理对集群中服务(通常是HTTP)的外部访问的API对象。入口可以提供负载平衡、SSL终止和基于名称的虚拟主机。

如果你想更好地了解这个概念,而不是查看这个SO线程。

最后是关于自定义云提供商。可以为RKE启用不同的云提供商:

如果您想启用不同的云提供商,RKE允许自定义云提供商选项。必须提供名称,并且自定义云提供商选项可以在CustCloudProvider中作为多行字符串传入。

我希望这有帮助。

 类似资料:
  • 我有一个朋友允许我访问他的kube集群(托管在IBM云上)。 我可以通过IBM云控制台登录 但是,当我试图通过kubectl访问它们时:kubectl get节点 结果显示一条错误消息: 服务器错误(禁止):节点被禁止:用户https://iam.ng.bluemix.net/kubernetes#无法在群集范围内列出节点。 为什么控制台和CLI之间的访问(RBAC)会有所不同?

  • 我假设没有愚蠢的问题,所以这里有一个我找不到直接答案的问题。 现在的情况 我目前有一个运行1.15的Kubernetes集群。AKS上的x,通过Terraform部署和管理。AKS最近宣布Azure将在AKS上停用Kubernetes的1.15版本,我需要将集群升级到1.16或更高版本。现在,据我所知,直接在Azure中升级集群不会对集群的内容产生任何影响,即节点、豆荚、秘密和当前在那里的所有其他

  • 我正在学习Spring Bootkubernetes并尝试为我的服务设置Spring Cloud网关。我相信使用Spring Cloud网关,我们不再需要使用功能区来进行负载平衡。所以如果我不使用功能区,那么路由的配置也会改变。我查看了网站以寻求建议,我发现如下:- 在这种情况下,uri具有服务可用的端口的硬编码值。这是推荐的方法吗? 然后还有另一种配置的味道,看起来像这样,不确定url表达式想做

  • 我在Kubernetes是个新手。我想知道在kubernetes环境中最好的生产部署场景是什么。 在过去的学派中,我习惯于将Web服务器(例如Nginx或Apache)放在DMZ层,而将其放在其他层(我们称之为层)。这样,只有web服务器在DMZ上,恶意攻击只能在web服务器VM上进行。 据我所知,K8S部署不再需要这种方法;这是因为K8S自己处理网络、吊舱和流量。所以我在考虑最确定的部署方案。

  • 据我所知,作业对象应该在一定时间后收获豆荚。但是在我的GKE集群(库伯内特斯1.1.8)上,“kubectl get pods-a”似乎可以列出几天前的豆荚。 所有这些都是使用乔布斯API创建的。 我确实注意到在使用 kubectl 删除作业后,pod 也被删除了。 我在这里主要担心的是,我将在批量作业中在集群上运行成千上万个pod,并且不想让内部待办系统过载。

  • 我试图设置Kubernetes入口,将外部http流量路由到前端pod(路径/)和后端pod(路径/rest/*),但我总是得到400错误,而不是主nginx索引。html。 所以我在第https://cloud.google.com/kubernetes-engine/docs/tutorials/http-balancer页尝试了谷歌库伯内特斯的例子,但我总是得到400个错误。有什么想法吗?