本文所有相关链接pdf：https://tungstenfabric.org.cn/assets/uploads/files/tf-ceg-case-2.pdf
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公开示例应用
在探讨上述三种情况之前，让我们部署一个简单的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，以确保其有效。
使用HTTPS保护应用程序的安全
对于此练习，我们需要生成自签名证书，并将其添加到AWS Certificate Manager。提供Ingress功能的AWS Application Load Balancer（ALB）需要使用此功能来执行加密。
注意：对于生产用途，可能需要通过AWS Certificate Manager的相应功能来获得完整注册域名的“适当”证书。由于我们只是在进行练习，因此将使用自签名的虚构域。
步骤1：生成自签名证书，并将其添加到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后面的值，以进行下一步。
步骤2：建立Ingress定义
确保您位于沙箱控制节点上，以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。
步骤3：建立HTTPS Ingress并进行测试
#创建新的 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
根据URL路径定向请求
在某些情况下，您可能想在同一个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，并在路由部分进行两项更改：
-
将yelb的路径从/*更新到/以免干扰echoserver；和
- 添加新的/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
让我们为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 TF Carbide 评估指南--准备篇
第二篇：通过Kubernetes的服务进行基本应用程序连接
关注微信：TF中文社区 
来源：51CTO
作者：TF中文社区
链接：https://blog.51cto.com/14638699/2466459