这里描述使用 Kubernetes 来开发分布式应用可能会用到的模式，并非其内部实现模式。

Sidecar（边车、挎斗）

最常用模式，指在一个 Pod 中同时运行两个容器，共享网络和文件系统。这也是 Pod 对容器本身的一种扩展和抽象。 乍一看这很稀松平常，就和我们本地计算机运行同时运行多个程序并无二致，但可以成为最为广泛的模式了。 考虑到容器是一种程序的封装，这种 sidecard 模式就是封装的一种退化，也是容器之间最简单的交互方式。 如果 Kubernetes 更多的是强调模块的隔离和解耦，这个 sidecar 其实就是内聚的折中。

Java Web Application with Tomcat and Sidecar Container

把两个关系紧密的 container 放到一个 pod 里面，共享同样的文件系统。带来的好处是 Tomcat 和 sample 可以分开演化，image builder 的速度也加快了。k8s 的 “atomic” scheduling 保证了两个 container 是同时起来的，这样 Tomcat 总能访问到 war 文件，避免出现一前一后的尴尬问题。

Ambassador

Building Ambassador, an Open Source API Gateway on Kubernetes and Envoy

Ambassador和Istio：边缘代理和服务网格 Ambassador 是一个 Kubernetes 原生的微服务 API 网关，它部署在网络边缘，将传入网络的流量路由到相应的内部服务（也被称为“南北”流量）。Istio 是微服务的服务网格，旨在将L7的可观察性、路由和弹性加入到从服务到服务的流量中（也被称为“东西”流量）。Istio 和 Ambassador底层都使用了 Envoy。

Shard

Hands On: Implementing a Sharded Redis 的例子 Redis 存储分片之代理服务Twemproxy 测试 http://blog.jiguang.cn/redis-twemproxy-benchmark/

前端使用 Twemproxy 做代理，后端的 Redis 数据能基本上根据 key 来进行比较均衡的分布。 这个功能对于大数据比如 Ceph 来说，都是内置的。这个 proxy 必须知道 key 会再在哪台服务器上面。而使用 StatefullSet 的原因是这样能保证 redis 的 pod host name 不会变化，proxy 有 key-hostname 的映射，所以 hostname 不能变化。k8s service 虽然也不会变，但是这里是 twemproxy 直接连 pod，中间不用 service 做负载均衡，service 的目的只不过是用来形成 sharded-redis-0.redis 这种一致的 DNS。

Think

相比较经典的设计模式，这里的模式粒度更大（分布式），隔离性更好。通过网络的强制分离比原来的库、模块的隔离更为彻底，也带来了很多比如 log，monitor 的额外收益。通过网络的分离，也符合所有服务皆为微服务的宗旨。