在应用中，通常需要向外部公开某种HTTP服务。部署部分处理应用程序Pod的管理，服务提供多个Pod内部的负载均衡，而入口将应用暴露给外部。
入口的配置清单前文中说过，入口充当内部K8s服务的外部负载均衡或反向代理。下面的例子展示了如何公开内部服务到外网：
apiVersion: extensions/v1beta1kind: Ingress
metadata:
name: my-shop-backend-ingress
labels:
app: my-shop
system: backend
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- http:
host: api.my-shop.com
paths:
- path: /my-shop
backend:
serviceName: my-shop-backend
servicePort: 80
1. apiVersion、kind、metadata
同样，入口清单也包含API版本、类型和元数据。不同的是，入口的元数据还包含入口的名称以及关联对象的标签。
此外，还多了一个注释标签annotations。注释标签的工作原理与前面提到的标签很相似，也都是键值对。不同的是注释标签不能用来选择对象。
本例中，我们添加了注释nginx.ingress.kubernetes.io/rewrite-target，值为/。这个注释用到了Nginx入口控制器的一个特殊键值，用来告诉控制器重写传入请求的匹配路径为“/”。
例如，在以下路径收到一个请求：
/my-shop/orders/123入口控制器将重写到：
/orders/123
另外，为了使用入口，集群中需要部署一个入口控制器。每个入口控制器会有不同的特性，都需要不同的注释来配置。因此，入口配置清单可能会根据不同的作用而有所不同。
2. spec入口清单的spec部分包含配置由集群的入口控制器管理的反向代理所需要的全部规则。如果你用过Nginx、IIS或其它类似的反代，那应该会容易理解，规则很相似，都是定义了一组传入请求的规则，以决定将他们路由到什么路径。
入口清单可以定义多种规则，但一定要记着可部署单元的概念。我们应该为部署到K8s的每个应用配置单一入口，而不是跨应用去配置入口，尽管这样做技术上支持。
看上面例子的spec段：
spec:rules:
- http:
host: api.my-shop.com
paths:
- path: /my-shop
backend:
serviceName: my-shop-backend
servicePort: 80
通常我会习惯用主机来区分不同的应用，像例子中的api.my-shop.com。当然，您也可以通过匹配路径来定义，例如/my-shop。而这个会根据元数据中的重写定义注释被重写。
除了匹配传入的路径和主机外，清单中还需要定义请求转发的内部服务和端口。本例中，我们用了同样的80端口去路由到上一节中定义的后端服务中。
上面这个例子是最常见的一个入口清单定义，只将传入的请求与单个服务匹配。
有时候，可能会几种不同类型的Pod组成一个服务“微单元”。这种情况下，也可能会有几个K8s服务，并且基于路径将几个服务路由到单一入口内，这时候可以这样配置：
spec:rules:
- http:
paths:
- path: /orders
backend:
serviceName: my-shop-orders-service
servicePort: 80
- http:
paths:
- path: /history
backend:
serviceName: my-shop-order-history-backend
servicePort: 80
在K8s配置时，入口中可以加入很多配置。这部分如果有问题，可以去翻K8s文档。
如果只是需要将应用部署到K8s，那上边的内容基本够用了。唯一要注意的是集群中用了哪个入口控制器。
总结一下这篇文章是这个系列的第二篇。
这篇文章介绍了我们必须要知道的K8s的主要资源：Pod、部署、服务、入口的YAML基本配置，并列出了一些最重要的配置值。
K8s这个东西，做为一个大的分布式架构，肯定是比较复杂的。但实际应用中，不是每个内容都需要理解和应用。
做多了，就是套路。
蹚过了，就是经验。
（未完待续）
微信公众号：老王Plus