问题描述
(在学习Kubernetes时，我从未真正找到任何好的资源来解释这一点)
(While learning Kubernetes I never really found any good resources explaining this)
场景:
我拥有mywebsite1.com和mywebsite2.com，我想将它们都托管在Kubernetes集群中.
Scenario:
I own mywebsite1.com and mywebsite2.com and I want to host them both inside a Kubernetes Cluster.
我根据以下网站部署了通用的云入口控制器，其中2个
kubectl apply -f< url>命令. (mandatory.yaml和通用ingress.yaml)
https://kubernetes.github.io/ingress-nginx/deploy/
I deploy a generic cloud ingress controller according to the following website with 2
kubectl apply -f < url > commands. (mandatory.yaml and generic ingress.yaml)
https://kubernetes.github.io/ingress-nginx/deploy/
所以问题是该架构是什么样的?以及数据如何流入集群?
So the question is what does that architecture look like? and how does the data flow into the Cluster?
推荐答案
我将2个证书转换为2个.key和2个.crt文件
我使用这些文件制作了2个TLS机密(每个网站1个，因此它们将启用HTTPS)
我创建了2个Ingress对象:
I convert 2 certificates to 2 .key and 2 .crt files
I use those files to make 2 TLS secrets (1 for each website so they'll have HTTPS enabled)
I create 2 Ingress Objects:
-
一个表示website1.com/，指向名为website1fe的服务，并引用website1的HTTPS/TLS证书密钥.
(website1fe服务仅在端口80上侦听，并将流量转发到由website1fe部署产生的Pod)
one that says website1.com/, points to a service called website1fe, and references website1's HTTPS/TLS certificate secret.
(The website1fe service only listens on port 80, and forwards traffic to pods spawned by a website1fe deployment)
另一个表示website2.com/，指向名为website2fe的服务，并引用website2的HTTPS/TLS证书密钥.
(website2fe服务仅在端口80上侦听，并将流量转发到由website2fe部署产生的Pod)
the other says website2.com/, points to a service called website2fe, and references website2's HTTPS/TLS certificate secret.
(The website2fe service only listens on port 80, and forwards traffic to pods spawned by a website2fe deployment)
我有一个3节点Kubernetes集群，该集群存在于私有子网中.
他们有IP
I have a 3 Node Kubernetes Cluster that exists in a Private Subnet.
They have IPs
10.1.1.10 10.1.1.11 10.1.1.12
当我跑2时
kubectl apply -f< url>命令
生成的命令:
When I ran the 2
kubectl apply -f < url > commands
Those commands generated:
- Ingress Controller部署
- ClusterIP类型的L7 Nginx LB服务，侦听端口80和端口443
- 侦听端口80和端口443的L7 Nginx LB部署(此部署中的Pod由入口控制器Pod管理/配置，它将把Pod配置为入口对象指定的所需状态)
- NodePort类型的L7 Nginx LB服务(从30000-32767的范围内随机选择，但为清楚起见，我将说NodePort服务正在侦听端口30080和30443)
- 具有公共IP地址的L4 LB VM.
kubectl get svc --all-命名空间
给出L4 LB的IPv4 IP地址(假设为1.2.3.4)
kubectl get svc --all-namespaces
Gives the IPv4 IP address of the L4 LB (let's say it's 1.2.3.4)
由于我同时拥有两个域:我配置了Internet DNS，以便website1.com和website2.com都指向1.2.3.4
Since I own both domains: I configure internet DNS so that website1.com and website2.com both point to 1.2.3.4
注意:入口控制器是云提供商所知的，因此它会自动进行以下反向代理/负载平衡配置:
Note: The ingress controller is cloud provider aware so it automatically did the following reverse proxy/load balancing configuration:
L4LB 1.2.3.4:80 --(LB between)--> 10.1.1.10:30080, 10.1.1.11:30080, 10.1.1.12:30080
L4LB 1.2.3.4:443 --(LB between)--> 10.1.1.10:30443, 10.1.1.11:30443, 10.1.1.12:30443
KubeProxy使之能够将群集中任何节点的端口30080或30443上的请求转发到ClusterIP类型的L7 Nginx LB服务，然后将流量转发到L7 Nginx LB Pods.
L7 Nginx LB Pod终止HTTPS连接，并将流量转发到website1.com和website2.com服务，它们正在侦听未加密的端口80.
(因为我们位于集群中，所以没人解密它是可以的)正在监听流量.)
(L7 LB根据流量进入的L7地址知道要转发到哪个服务)
KubeProxy makes it so that requests on any node's port 30080 or 30443 get forwarded inside the cluster to the L7 Nginx LB Service of type ClusterIP, which then forwards the traffic to the L7 Nginx LB Pods.
The L7 Nginx LB pods terminate the HTTPS connection and forward traffic to website1.com and website2.com services, which are listening on unencrypted port 80.
(It's ok that it's unencrypted because we're in the cluster where no one would be sniffing the traffic.)
(The L7 LB knows which service to forward to based on the L7 address that traffic is coming in on)
请注意避免错误:假设website1.com希望访问website2.com上存在的一些资源
Note a mistake to avoid:Let's say that website1.com wants to access some resources that exist on website2.com
好website2.com实际上有2个IP地址和2个DNS名称.
website2fe.default.svc.cluster.local<-内部群集可解析的DNS地址
website2.com<-外部解析DNS地址
而不是让website1通过website2.com访问资源您应该具有通过website2fe.default.svc.cluster.local提供的website1访问资源.(这是更有效的路由)
Well website2.com actually has 2 IP addresses and 2 DNS names.
website2fe.default.svc.cluster.local <-- inner cluster resolvable DNS address
website2.com <-- Externally resolving DNS address
Instead of having website1 access resources via website2.comYou should have website1 access resources via website2fe.default.svc.cluster.local(It's more efficient routing)
这篇关于Kubernetes集群内部的流量如何流动?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！