Kubernetes服务发现、CNI和Istio的差异

ymdaylpp  于 2022-12-17  发布在  Kubernetes
关注(0)|答案(1)|浏览(194)

我正在研究K8如何使用clusterIP服务来解析服务,以及WeaveNet等CNI或Istio等服务网格如何为该功能提供附加特性。然而,我对该主题是新手,我想在此分享我的发现,看看是否有人可以扩展和纠正我的观点:

  • Istiod有一个服务注册表,这个服务注册表中填充了来自K8s服务clusterIPs(也就是K8s的服务注册表)和其他可能的外部服务的条目,这些外部服务定义为Kind:ServiceEntry(见第5.5节)这个服务注册表与更多关于虚拟服务和目的地规则的信息混合在一起。这些新的/添加的K8类型是来自Istio的CRD。它们给予了L7负载平衡的特性,允许通过HTTP头或URI路径分配流量。
  • 没有伊斯蒂奥K8s有不同的(3)实现clusterIPs服务概念的方法。该服务在L4提供负载平衡。https://kubernetes.io/docs/concepts/services-networking/service/目前最扩展的一种是iptables代理模式。Linux机器的iptables是根据kube-proxy提供的内容填充的。Kube-proxy从kube-apiserver和(可能是core-dns)。kube-apisever将依次查询etcd数据库以了解k8s clusterIP服务。iptables的条目使用clusterIP-〉pod IP填充,其中在clusterIP后面的部署可能是许多pod中的一个pod IP。如果使用正确的身份验证并获取pod地址,则容器中的任何代码/应用程序都可以直接调用kube-apiserver,但这并不实际
  • K8可以使用CNI(容器网络接口)。其中一个例子是Weavenet。https://www.weave.works/docs/net/latest/overview/ Wevenet使用Linux内核特性创建了一个新的第2层网络。一个守护进程设置这个L2网络并管理机器之间的路由,有多种方式将机器连接到网络。在这个网络中,容器可以暴露给外界。Weavenet在每个节点上实现了一个微型DNS服务器,你只需命名容器,路由就可以在不使用服务的情况下工作,包括在多个同名容器之间的负载平衡。
uklbhaso

uklbhaso1#

除了你在问题中提到的几点之外,
使用Istio这样的服务网格可以简化服务发现、路由和流量配置、加密和身份验证/授权以及监控和遥测等任务。特别是Istio,其设计无需对现有服务代码进行重大更改即可运行。例如,使用Kubernetes时,通过构建与现有应用程序资源一起工作的特定于Istio的对象,可以向集群中运行的应用程序添加服务网格功能
你仍然可以调用其他服务,就像你没有istio一样。你需要使用clusterIP service来公开服务,因为它只需要在集群中访问。Kubernetes DNS可以用来通过名称调用服务。服务通常可以在http(s)://namespace.service-name访问。你可以跳过url中的“namespace”来调用同一名称空间中的服务。
根据本文档,现场不需要虚拟服务
有关-cni-plugins-on-kubernetes的详细信息,请参阅此document

相关问题