2. 第二部分
除了将 httpServer 应用优雅的运行在 Kubernetes 之上，我们还应该考虑如何将服务发布给对内和对外的调用方。
来尝试用 Service, Ingress 将你的服务发布给集群外部的调用方吧。
在第一部分的基础上提供更加完备的部署 spec，包括（不限于）：
Service
Ingress
可以考虑的细节
如何确保整个应用的高可用。
如何通过证书保证 httpServer 的通讯安全。
Service
Kubernetes 之所以需要 Service，一方面是因为 Pod 的 IP 不是固定的，另一方面则是因为一组 Pod 实例之间总会有负载均衡的需求。
Kubernetes 允许将 Pod 对象通过标签（Label）进行标记，并通过 Service Selector 定义基于 Pod 标签的过滤规则，以便选择服务的上游应用实例。
当 Service 的 Selector 不为空时，k8s Endpoint Controller 会侦听服务创建事件，创建与 Service 同名的 Endpoint 对象。
Selector 能够选取的所有 PodIP 都会被配置到 addresses 属性中：
- 如果此时 Selector 所对应的 filter 查询不到对应的 Pod，则 addresses 列表为空。
- 默认配置下，如果此时对应的 Pod 为 not ready 状态，则对应的 PodIP 只会出现在 subsets 的 notReadyAddresses 属性中，这意味着对应的 Pod 还没有准备好提供服务，不能作为流量转发的目标。
- 如果设置了 PublishNotReadyAddress 为 true，则无论 Pod 是否就绪都会被加入 readyAddress list。
Service、Endpoint 和 Pod 的对应关系：一个 Service 可以选择多个 Pod；一个 Pod 也可以发布成不同的服务，譬如发布 80 和 443 端口，因此 Service 和 Pod 是多对多的关系。而 Endpoint 类似于中间表，维护了 Service 和 Pod 间多对多的关联关系。当我们创建 Service 时，默认是一个 ClusterIP 类型的 Service。
service.yaml
apiVersion: v1 kind: Service metadata: name: httpserver spec: type: ClusterIP ports: - port: 80 protocol: TCP name: http selector: app: httpserver
Ingress
Service 是工作在第四层网络协议的负载均衡技术，它只能基于数据包的五元组（通常是指源 IP 地址，源端口，目的 IP 地址，目的端口和传输层协议）信息。
这就意味着它一定是只能做一些简单的网络地址转换，但是我们很多时候的需求不止如此，譬如基于 URL 或用户的请求体进行负载均衡等。
Ingress 是一层代理，反向代理软件的能力：它可以侦听一个地址，然后这个地址接收到请求以后，它可以配置一些规则（可以理解为配置文件），反向代理软件读取配置文件加载规则，并根据规则做转发。
那么配置文件如何生成？在 kubernetes 中抽象成了一个对象，就是 Ingress，它是用户用来描述真正的高层级跳转规则的抽象。
这个抽象由 Ingress Controller 控制器来监听 Ingress 对象，读取对象的规则配置，转化成反向代理软件能识别的的配置格式，然后重启或者热加载等方式让配置生效，比如 nginx HAProxy 或者 Envoy 的配置。
如何确保整个应用的高可用
实现高可用：冗余部署+负载均衡。
Kubernetes 中的负载均衡技术：基于 L4 的服务 和 基于 L7 的 Ingress。
冗余部署：至少多部署一个节点，避免单点问题。
基于 L7 的 Ingress：
- 外部网络到内部网络还是交给 Service 去处理，但是因为后面还有七层转发，所以四层转发就可以很简单。
- 我们可以把很多服务挂载在一个 API 网关上面，做统一的接入。
- 整个网站的微服务可能只用一个 ELB 上的虚 IP，所有网络流量都从统一的虚 IP 接入。
- 接入后，请求会按照 Service 的转发机制转到 Ingress Pod 里面去。
