扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
如何通过Kubernetes Ingress进行高级外部应用程序连接,很多新手对此不是很清楚,为了帮助大家解决这个难题,下面小编将为大家详细讲解,有这方面需求的人可以来学习下,希望你能有所收获。
创新互联是一家专注于网站设计制作、成都网站建设与策划设计,临漳网站建设哪家好?创新互联做网站,专注于网站建设十余年,网设计领域的专业建站公司;建站业务涵盖:临漳等地区。临漳做网站价格咨询:028-86922220
Kubernetes的Ingress文档页面将其描述为:
“用于管理对集群中服务的外部访问的API对象,通常是HTTP。Ingress可以提供负载均衡、SSL终结和基于名称的虚拟主机。”
CNI不提供Ingress功能。这意味着Kubernetes集群管理者通常要为其集群安装、管理和支持单独的Ingress控制器解决方案。
对于没有内置Ingress支持的本地和公共云中的Kubernetes部署,Tungsten Fabric捆绑了自己的Ingress控制器。它在后台使用HAProxy并实现了Kubernetes Ingress文档页面中所述的所有基本功能。
在AWS上运行时,可以将Kubernetes 配置为使用AWS的Application Load Balancer (ALB)为其Ingress服务。通过这种方式的设置,沙箱中的Kubernetes可以最紧密地反映典型的现实部署场景。
下图概述了示例应用程序的最终部署架构:
使用场景
Ingress控制器选项仅与使用HTTP或HTTPS的应用程序兼容。如果您的应用程序是这种情况,可能需要考虑使用Ingress来实现以下目标:
使用HTTPS保护应用程序,然后通过配置Ingress进行SSL卸载来将程序公开在网络上;和/或
基于请求中的HTTP路径,将传入请求定向到不同的Kubernetes Services,例如,/blog/可以转到Service A,而/account/可以转到Service B,等等。和/或
通过基于名字的虚拟主机,应用程序服务于多个DNS域,例如Host:头设置为test.project.com的应用去Service C,而那些具有prod.project.com的去Service D。
在探讨上述三种情况之前,让我们部署一个简单的Ingress示例应用程序,类似于我们对 LoadBalancer的做法,然后在此基础上进行构建。
确保您位于沙箱控制节点上,以root用户身份登录,并且位于正确的目录中:
#确认您是root账户
whoami | grep root || sudo -s
# 切换为清单目录
cd /home/centos/yelb/deployments/platformdeployment/Kubernetes/yaml
# 部署具有Ingress的示例程序
kubectl create -f cnawebapp-ingress-alb.yaml
几分钟后,部署过程应该完成了,我们应该能够从Internet访问示例应用程序。首先找到Ingress的DNS名称:
根据上面的输出,现在可以从Internet上的http://539db10e-default-yelbui-3c9c-1330819777.us-west-1.elb.amazonaws.com上访问我们的示例应用程序。
利用在环境中运行上述命令获得的DNS名称访问Yelb,以确保其有效。
对于此练习,我们需要生成自签名证书,并将其添加到AWS Certificate Manager。提供Ingress功能的AWS Application Load Balancer(ALB)需要使用此功能来执行加密。
注意:对于生产用途,可能需要通过AWS Certificate Manager的相应功能来获得完整注册域名的“适当”证书。由于我们只是在进行练习,因此将使用自签名的虚构域。
在安装了具有Access和Secret密钥的AWS CLI工具的主机上执行以下步骤。这里的密钥允许您对Certificate Manager进行更改。
# 为虚构的域名(yelb.mydomain.com)生成自签名证书:
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=yelb.mydomain.com"
#将新的证书加入到AWS Certificate Manager
# 注意“--region” -这必须是同一个AWS区域
# 在我们的例子中,运行Tungsten 沙箱时,它是“us-west-1”
aws acm import-certificate --certificate file://tls.crt --private-key file://tls.key --region us-west-1
如果一切顺利,最后一条命令将显示类似内容:
{
"CertificateArn": "arn:aws:acm:us-west-1:180612498884:certificate/e7341ff5-52ef-4a7b-94b5-05643ef6ab46"
}
我们将需要CertificateArn后面的值,以进行下一步。
确保您位于沙箱控制节点上,以root用户身份登录,并且位于正确的目录中:
# 确定您是root身份
whoami | grep root || sudo -s
# 切换为清单目录
cd /home/centos/yelb/deployments/platformdeployment/Kubernetes/yaml
现在,让我们创建一个新的Ingress定义:
接下来,我们将CertificateArn放入。在运行该命令之前对其进行编辑,并用执行步骤1时获得arn:aws:acm:us-west-1:180612498884:certificate/e7341ff5-52ef-4a7b-94b5-05643ef6ab46的值替换该命令CertificateArn。
sed-i"s#INSERT_CERT_ARN_HERE#arn:aws:acm:us-west-1:180612498884:certificate/e7341ff5-52ef-4a7b-94b5-05643ef6ab46#" ingress-https.yaml
如果命令成功运行,则ingress-https.yaml文件将具有自签名证书的ARN,而不是字符串INSERT_CERT_ARN_HERE。
# 创建新的 Ingress
kubectl create -f ingress-https.yaml
运行上述命令后,请等待几分钟,以使新的ALB Ingress出现。然后,让我们找到已为其分配的DNS名称,并尝试连接到它:
从上面的输出中,我们可以看到新Ingress的地址;让我们看看它是否有效:
这说明它有效——我们可以通过加密连接访问Yelb应用程序!
新拓扑看起来像这样(请注意,我们仍然具有未在此图中显示的原始HTTP Ingress):
除了增加最终用户的连接安全性、隐私性和数据完整性外,实现HTTPS Ingress还有一些好处:
应用程序消耗较少的计算资源,因为加密开销已转移到ALB;
应用程序现在支持HTTP / 2,这是一件好事;
可以轻松实现将 HTTP 自动重定向到HTTPS的功能。
让我们删除添加的HTTPS Ingress,因为在本章的其余部分中我们不再需要它:
kubectl delete -f ingress-https.yaml
然后,在执行步骤1(生成自签名证书并将其安装到AWS Certificate Manager中)的计算机上,运行以下命令以删除该证书,并确保使用您自己的值CertificateArn:
aws acm delete-certificate --certificate-arn arn:aws:acm:us-west-1:180612498884:certificate/e7341ff5-52ef-4a7b-94b5-05643ef6ab46
在某些情况下,您可能想在同一个DNS域名下运行多个应用程序。例如,www.corp.com可能支持您的主应用程序,而诸如WordPress之类的其他应用程序可能正在处理www.corp.com/blog。
对于本练习,我们假设您在“通过Ingress公开示例应用程序”这一章的开头按照说明运行了Yelb副本。如果您是从头开始,请跳至该部分,按照说明进行部署,然后再回来。
为了演示通过URL路径进行的路由,我们将在环境中添加另一个部署,并相应地更新Ingress的配置。在此新配置下,Ingress会将对/路径的请求定向到我们的主应用程序yelb,而对/echo的路径请求将定向为新的应用程序EchoServer。
这是目标状态的图:
我们应该已经将Yelb的部分放置到位,所以我们添加EchoServer:
# 创建EchoServer Deployment and Service 清单:
# 现在部署它:
kubectl create -f echoserver.yaml
接下来,我们将为Ingress创建一个更新的配置。为此,我们将从中复制Ingress资源cnawebapp-ingress-alb.yaml,并在路由部分进行两项更改:
1. 将yelb的路径从/*更新到/以免干扰echoserver;和
2. 添加新的/echo路径指向echoserver
注意:我们之所以要包含完整的资源定义而不是仅仅应用差异部分,是因为Ingress对象不支持战略性合并修补。
# 更新的Ingress资源:
# 现在部署它:
kubectl apply -f ingress-paths.yaml
这里会显示一个关于kubectl apply的警告,这个警告可以忽略。因为我们的更新资源在本质上与rules配置相同。
更新的配置在几秒钟内生效,之后我们就可以检查基于URL的路由是否有效。当我们请求基本URL /(或为空)时,我们应该到达Yelb,如果请求/echo,我们应该返回的输出是EchoServer。
# 获得Ingress的基本URL
baseUrl=$(kubectl get ing yelb-ui | grep amaz | awk '{print $3}')
echo "Our Ingress is at: ${baseUrl}"
# 尝试访问$baseUrl ; 应当可以得到Yelb UI页面的内容
curl http://${baseUrl}
# 现在尝试/echo ; 应当得到EchoServer的输出
curl http://${baseUrl}/echo
当您拥有多个域名,并且为每个域提供不同的应用程序,同时希望共享相同的Ingress基础结构,此场景中的解决方案就很有用。这有助于节省成本,并且在某些情况下,与每个域名拥有专用的Ingress实例相比,其复杂性更低。
此练习建立在上一个基于URL定向请求的练习的基础上。如果尚未完成,请回顾此前步骤,简单地剪切并粘贴创建和部署echoserver.yaml清单的步骤。我们将为Ingress新建一个,因此无需创建和部署ingress-paths.yaml。
准备好后,您应该已经有了yelb的副本和echoserver的副本。您的Ingress配置是什么都无所谓,因为我们将覆盖它。
在我们的目标状态下,Ingress将定义两个域名yelb.mydomain.com和echo.mydomain.com,并将根据Host:HTTP头中的值来路由传入的请求,Web浏览器会自动为您请求的URL的主机部分插入这些请求。
这是目标状态的图:
让我们为Ingress创建并部署配置,该配置将执行所需的路由:
# 更新的Ingress 资源:
# 现在部署它:
kubectl apply -f ingress-hosts.yaml
配置成功应用后,我们就可以进行测试了。由于域名和主机形成映射,因此我们将利用curl添加正确的Host:标头。当设置为yelb.mydomain.com,应该到达Yelb,设置为echo.mydomain.com时,应该返回输出EchoServer。
# Get the base URL of our Ingress
baseUrl=$(kubectl get ing yelb-ui | grep amaz | awk '{print $3}')
echo "Our Ingress is at: ${baseUrl}"
# 访问Ingress Host: 设置成 yelb; 我们应当可以得到Yelb UI页面的内容
curl http://${baseUrl} -H "Host: yelb.mydomain.com"
# 现场尝试访问Host:设置成 echo;我们应当可以得到 EchoServer的输出
curl http://${baseUrl} -H "Host: echo.mydomain.com"
一旦进行了足够的测试,请随时清理:
# 删除“yelb”和“hoserver”应用:
kubectl delete -f cnawebapp-ingress-alb.yaml
kubectl delete -f echoserver.yaml
# 删除我们创建的额外的清单:
rm -f echoserver.yaml ingress-paths.yaml ingress-hosts.yaml
看完上述内容是否对您有帮助呢?如果还想对相关知识有进一步的了解或阅读更多相关文章,请关注创新互联行业资讯频道,感谢您对创新互联的支持。
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流