189 8069 5689
如何通过Kubernetes Ingress进行高级外部应用程序连接，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。
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
看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注创新互联-成都网站建设公司行业资讯频道，感谢您对创新互联的支持。