flannel(网络层)和 kubernetes 中的入口有什么区别?

What is the difference between flannel (network layer) and ingress in kubernetes ?

我在 GCP 上设置了 2 个 VPC,我在每个 VPC 上设置了 kubeadm,我们称它们为 kubemaster 和 kubenode1。所以我 运行 kubemaster 和 kubenode1 上的 kubeadm :

当我试图 kubectl apply -f (a deployment which contains a pod with simple webapps inside)kubectl apply -f (a NodePort type of Service which target the deployment port)

在那之后,我只是从我的浏览器访问 webapps(在我的本地机器上,而不是在 GCP 上),它只是不能像我在 minikube 上尝试的那样工作(我也使用与上面相同的 kubectl apply 设置 minikube)。我进行了一些搜索,有很多人在谈论入口和网络层(kubernetes 网站示例中的法兰绒)

我的问题是这些 Ingress 和 flannel 是什么?如果我只想要我的 webapp 运行 ,哪一个是必需的或者两者都不是必需的?彼此如何对抗他人?因为根据我的理解,分层如下:

Traffic -> Services -> Deployments/Pods

这些防护服和法兰绒套装去哪儿了?如果不是关于它们,为什么我的应用程序不能按预期工作(我在 GCP 设置中打开所有端口,所以我想这不是安全问题),我尝试设置 Kubernetes Dashboard-UI、运行 kubectl proxy 而且我的浏览器仍然无法访问这两个服务(部署中的我的 webapp 和仪表板 API),可能我在这里有点迷路了。

法兰绒和Ingress是完全不同的东西。

flannel 是一个 CNI 或容器网络接口插件,其任务是在容器之间联网。正如 coreOS 所说:

each container is assigned an IP address that can be used to communicate with other containers on the same host. For communicating over a network, containers are tied to the IP addresses of the host machines and must rely on port-mapping to reach the desired container. This makes it difficult for applications running inside containers to advertise their external IP and port as that information is not available to them.

flannel solves the problem by giving each container an IP that can be used for container-to-container communication. It uses packet encapsulation to create a virtual overlay network that spans the whole cluster. More specifically, flannel gives each host an IP subnet (/24 by default) from which the Docker daemon is able to allocate IPs to the individual containers.

Kubernetes 支持其他一些 CNI 插件:Calico、weave 等。它们根据功能而有所不同(例如,支持用于限制资源的 NetworkPolicy 等功能)

Ingress 是一个 Kubernetes 对象,通常在网络堆栈 (HTTP) 的应用层运行,允许您对外暴露您的服务,它还提供 HTTP 请求路由、基于 cookie 的会话等功能亲和力、HTTPS 流量终止等。 (就像网络服务器 Nginx 或 Apache)

总的来说,法兰绒或 pod 到 pod 网络层使 pods 能够在 Kubernetes 中相互交谈。另一方面,Ingress Controller 是获取 Ingress 对象并将它们转化为通过 pod 到 pod 网络接收和转发(主要是)HTTP(S) 流量到支持服务的规则。

如您所见,从技术上讲,您只需要第一个(pod 到 pod 网络),因为您可以使用 NodePort 或 LoadBalancer 服务直接在某处公开您的服务,如果您使用 Ingress 非常方便公开多个服务(非常类似于您在经典 Web 服务器安装中使用虚拟主机。

除了现有的答案,我还想补充几点。

After that I simply access the webapps from my browser (on my local machine not on GCP), it just does not work as what I tried on minikube

您是否打开了 NodePort 的安全 rules/firewall 规则?您在哪个实例上打开以及您点击哪个实例来访问您的应用程序?

My question is what are these Ingress and flannel?

我建议你阅读官方文档。但无论如何,既然你问了这个问题,我想说几句话。

  • Flannel 是容器的覆盖网络,容器的子网可以跨越多个节点(与原生 docker networking-host n/w、NAT 等相反).每个容器在每次生成时都会获得自己的 IP。 flannel 更像是 K8s 内部容器网络的控制平面
  • Ingress 是负载均衡器的智能路由器(或者现在简单,我们可以说它将应用程序暴露在 K8s 之外)。它在应用程序级别工作。一旦你点击 "Ingress" enpoint,它将转发到服务(取决于入口规则)然后到应用程序 pod。

我看到你在谈论 ClusterIP。通常,ClusterIP 是 K8s 服务的 IP,这只不过是 "IP Tables Rules" 的魔术。一旦定义"Service",Kube-Proxy负责在每个节点中写入iptable规则。这些 ip table 规则或 ClusterIP 指向实际的 pod IP(由 flannel 守护程序分配的 IP)。我希望你能理解,flannel 和 "Ingress" 如何融入画面或一起工作或负责应用程序流量。(如果我错了请更正..!!

  • 可以粘贴ingress controller yaml内容吗?你定义的规则是什么?
  • 既然用的是GCP,不如试试GKE?我的意思是它很容易部署,此外您可以使用 LoadBalancer 而不是依赖 Ingress 访问您的应用程序(无论如何,它 none 我的业务 :-) )