白癜风多长时间能治愈 http://pf.39.net/bdfyy/bdfyw/160313/4786533.html题图摄于北京奥利匹克中心
本文选自马哥教育CEO马永亮老师撰写的《Kubernetes进阶实战（第2版）》，第十三章13.3.3-13.3.5节。马老师曾经到我司给云原生开发人员讲授Kubernetes的课程，讲解内容细致入微、条理清晰，受到学员一致好评。文末赠书活动，欢迎参加。
《Kubernetes进阶实战（第2版）》新增与重写多种知识点，基于Kubernetesv1.19与v1.20讲解新特性，值得推荐给大家。感兴趣的读者可参加文末赠书活动，或直接购买。
Contour是KubernetesIngress控制器的另一款开源实现，它以高性能的Envoy代理程序作为数据平面，支持开箱即用的动态配置和多种高级路由机制，支持TCP代理，并且提供了自定义资源（CRD）HTTPProxy扩展了IngressAPI，它以更丰富的功能集部分地解决了Ingress原始设计中的缺点，是Ingress控制器的较为出色实现之一。
本文主要就HTTPProxy基础、HTTPProxy高级路由、HTTPProxy服务韧性三个方面展开介绍HTTPProxy。
提示：本文中的操作需要读者部署完成了可用的Kubernetes集群，且部署了Contour作为IngressController。
(一)HTTPProxy基础
HTTPProxy资源几乎兼容Ingress资源的所有功能，只不过它使用独有的资源规范，具体的格式及简要说明如下所示。
apiVersion:projectcontour.io/v1#API群组及版本kind:HTTPProxy#CRD资源的名称metadata:namestringnamespacestring#名称空间级别的资源spec:virtualhostVirtualHost#定义FQDN格式的虚拟主机，类似于Ingress中的hostfqdnstring#虚拟主机FQDN格式的名称tlsTLS#启用HTTPS，且默认以将HTTP请求重定向至HTTPSsecretNamestring#存储证书和私钥信息的Secret资源名称minimumProtocolVersionstring#支持的SSL/TLS协议的最低版本passthroughboolean#是否启用透传模式，启用时控制器不卸载HTTPS会话clientValidationDownstreamValidation#验证客户端证书，可选配置caSecretstring#用于验证客户端证书的CA证书routes[]Route#定义路由规则conditions[]Condition#流量匹配条件，支持PATH前缀和标头匹配两种检测机制prefixString#PATH路径前缀匹配，类似于Ingress中的path字段permitInsecureBoolean#是否禁止默认的将HTTP重定向到HTTPS的功能services[]Service#后端服务，会对应转换为Envoy的Cluster定义nameString#服务名称portInteger#服务端口protocolString#到达后端服务的协议，可用值为tls、h2或者h2cvalidationUpstreamValidation#是否校验服务端证书caSecretStringsubjectNamestring#要求证书中使用的Subject值
需要特别说明的是，在同一个conditions字段中使用多个prefix前缀时，前缀间将存在串联关系，例如对于第一个前缀/api和第二个前缀/docs来说，该条件实际匹配的是/api/docs路由前缀。但通常在一个条件中只应该使用单个prefix。
我们以demoapp应用为例来说明如何通过HTTPProxy将应用发布到Kubernetes集群外部。为了隔离其它环境，我们下面先创建一个测试使用的名称空间，以dev为例，而后在该名称空间下分别创建deployments/demoapp和service/demoapp资源。
~kubectlcreatenamespacedev~kubectlcreatedeploymentsdemoapp–image=”ikubernetes/demoapp:v1.0“-ndev~kubectlcreateserviceclusteripdemoapp–tcp=80-ndev
下面配置清单中定义的HTTPProxy资源将demoapp以HTTP和HTTPS协议同时予以发布，客户端可通过其中任何一种协议发起访问请求。当然，我们也可以将“permitInsecure:true”中的值修改为“false”，从而将HTTP请求一律重定向至HTTPS。
apiVersion:projectcontour.io/v1kind:HTTPProxymetadata:name:
#和WeightedLeastRequest，默认为RoundRobinrequestHeadersPolicyHeadersPolicy#路由级别的请求报文标头策略reHeadersPolicyHeadersPolicy#路由级别的响应报文标头策略pathRewritePolicyPathRewritePolicy#URL重写replacePrefix[]ReplacePrefixprefixString#PATH路由前缀replacementString#要替换为的目标路径
需要特别说明的是，在同一个conditions字段中以不同的列表项分别定义的多个头部条件彼此间存在“逻辑与”关系，这意味着请求报文需要同时满足头部条件的定义才能匹配到设置的规则。
高级路由功能的应用场景通常会依赖同一应用程序两个或以上数量的版本，为了避免其他依赖，这里选择在dev名称空间下准备好的demoapp-v1.1和demoapp-v1.2两个版本的应用，它们都使用Deployment控制器编排，且分别有各自的Service对象。
~kubectlcreatedeploymentdemoappv11--image="ikubernetes/demoapp:v1.1"-ndevdeployment.apps/demoappv11created~kubectlcreatedeploymentdemoappv12--image="ikubernetes/demoapp:v1.2"-ndevdeployment.apps/demoappv12created~kubectlcreateserviceclusteripdemoappv11--tcp=80-ndevservice/demoappv11created~kubectlcreateserviceclusteripdemoappv12--tcp=80-ndevservice/demoappv12created
为了便于读者朋友们理解，下面将分别说明几种主流高级路由功能的配置方法。
1.基于标头的路由
基于标头的流量匹配机制是指检测请求报文的特定头部是否存在，或者其值是否满足表述的条件，而后仅路由测试结果为True的请求报文，不能满足测试条件的报文将被忽略，它们可能会由后续的其他路由规则匹配后进行路由，或者由默认路由指定的后端予以服务。在conditions字段中的同一个列表项中同时指定的header和prefix之间是“与”关系，即报文必须同时满足两个条件，而不同列表项表达的筛选条件间为“与”关系，报文也需要同时满足其全部条件。
下面的配置清单示例（
