kubernetes in aws Overview（EKS）
上图是 kubernetes(EKS) 在 aws 上的整体情况，下面我会对每块进行展开说明
分解说明
kubernetes or eks
kubernetes 原生支持在 aws 上使用，具体如何启用可参考kuberenetes 云应用实践，这里不在累赘说明。既然选择在云上使用 k8s ，那就直接使用云本身提供的能力（EKS），就没必要自己再去适配一遍，毕竟云厂商已经提供了这样的服务，为什么不去使用呢？不过自己也可以去了解EKS为我们做了什么？怎么去管理它？
EKS
EKS 其实就是帮我们托管了master节点（3 master集群），其次更好的与aws资源进行了集成，帮助我们在上层更轻松的使用，EKS 默认会集成以下组件:
- kube-proxy
- coredns
- amazon-k8s-cni (网络插件-替代calico，下面会介绍为何使用它)
使用 EKS 后，我们就不需要在关注 k8s master 的安装以及高可用，以及怎么在云上（aws）的集成，同时在开源的 kubernetes 上做了优化。当然，你可以可以选择自建，毕竟这些你都可以搭建出来，我们在 aws 中国就是自建的，毕竟 EKS 在国内还未上线，但如果是在国外或者国内上线的前提下需衡量付出的时间成本是否合算？
如何管理
terrafrom or eksctl，最终我选择了后者，理由也很简单，在我看来一个就好比是”学生”，另一个则是”亲儿子”，eksctl 由 aws 官方提供专门为 EKS 提供的命令行工具，它提供了更多的参数同时管理起来也非常的方便，如果你是深度管理，则使用它，terrafrom 则是大众普照中的一个，提供的参数也是有限，如果简单管理可以使用它。
负载均衡器ELB
介绍
aws 官方提供了三种负载均衡器，我简单成为 clb、alb、nlb，clb 即将淘汰也是最早的一代，这里主要阐述 alb 7层负载 与 nlb 4层负载 ，该如何选择，则取决于你的业务，他们之间的特征也很明显，如果你是需要关注 header 头信息的，如 x-forward-for 或 x-forward-proto 等信息的则使用 alb，如果不需要则使用 nlb 性能高。具体想了解，可参考aws官方文档：https://aws.amazon.com/cn/elasticloadbalancing/
管理
同样我们也面临着管理的问题，是使用 terrafrom 还是别的呢？毕竟我们使用了 k8s ，它有很好的 ingress 帮我们管理着对外的访问不是么？最终，我选择了 alb-ingress-controller，同样也是 aws 出品，它很好的与 ELB 进行了集成，我们只需要编写 ingress 文件，加上对应的注解，就可以很方便的使用 ELB，目前支持 alb 与 nlb 这两个负载均衡器的使用。
对 alb-ingress-controller 的使用也有一定的注意，推荐是一个对外暴露服务一个 ingress, 同时注意不要人为去 aws consol 界面去修改已有通过 alb-ingress-controller 创建出来的负载均衡器，如果你修改了，你会发现过一会就会还原了，因为在 k8s 中的 alb 控制器会帮你复原，所以一切的变更请使用 ingress, 同时还有一个不好的弊端就是在 alb/nlb 目标群组中，后端协议只能二选一，无法 http/https 同时存在，唯一的方法是使用两个 ingress ，不过我们大多数后端访问都是 http 协议。
详细了解可参考：
- https://github.com/kubernetes-sigs/aws-alb-ingress-controller/
- https://kubernetes-sigs.github.io/aws-alb-ingress-controller/guide/controller/config/
- https://docs.aws.amazon.com/zh_cn/eks/latest/userguide/alb-ingress.html
- https://aws.amazon.com/cn/blogs/china/kubernetes-ingress-aws-alb-ingress-controller/
网络插件
同样，在网络插件上，我也面临着选择的问题，不过现在回想起来，居然选择了云，那就基本大概率上去拥抱云原生提供的插件，不是么，毕竟它和云结合的很好，这里我介绍下 amazon-k8s-cni。
amazon-k8s-cni 我就说一件事，pod 与你现有的 vpc 打通，但劣势也很明显，就是 pod 的 ip 会占有你划分的 vpc ip池，如果你的 subnet 网段规划的不好的话，你的 ip 将会很快用光，所有我建议你的 vpc 网段是 16 位，subnet 网段是 20 位的，具体不同的网段可以放多少个 pod 可以参考这边文章了解下：https://www.yiibai.com/ipv4/ipv4_subnetting.html， 这里也不在累赘。
同时 amazon-k8s-cni 对主机类型上能起多少 pod 也是有限制的，不同的机型上启动的 pod 数量是不一样的，这里我推荐尽可能的使用中等规模的机型来取缔多个小机型。具体可参考：vpc_ip_resource_limit
当然如果你是本地机房或者云未给提供网络插件的话，那我还是推荐你使用 calico，毕竟它还是非常的强大！有兴趣的伙伴还是可以好好了解下。
访问安全
容器访问安全也是令我非常困扰的一个问题，aws 在资源访问方面有着非常好的权限控制 iam role ，但放到 k8s 容器中，一切都变的非常不美好了， 直到最近 aws eks 推出了 service account for iam role， 在 eks 没正式推出 service account for iam role 之前，有两种方式可以进行访问控制：
- access key/secret key
- kube2iam
针对以上两个访问，都有一定的缺陷，用key来控制的问题在于本身管理key就是一件头痛的事情，key的泄漏和定期更换非常痛苦，使用 kube2iam 问题在于你需要保证这个插件的稳定性和性能，一旦出现问题，你会发现那就是灾难性的，而且也不易排查，毕竟多层组件就多提升了出问题的概率，毕竟还是如此重要的组件。
最后，我隆重推荐大家使用 service account for iam role ，具体教程可点击链接查看。 但对于自建的小伙们只能退而求其次 使用 key 或者 kube2iam 来进行管理控制了
Why kong?
为什么选型 kong ，我想它的官方文档能更好的为你阐述，我从0.9开始就使用它了，直到现在维持在0.14.1，往后引入了 service mesh 的概念，选型 kong 的理由也很简单，开源、插件丰富、易于二次开发。后面可以专门分享一下我们是如何使用 kong 作为我们的业务网关，同时我们是如何改造 JWT 插件来实现鉴授权，以及通过网关审计日志定位问题，对外核心服务进行了限流等控制。如果你的需求也是如此，让业务保持足够简单专注于业务的实现，跨语言，微服务化，但同时需要一些服务治理相关的需求，还没有上 k8s 或者还没到 isito 这种重 service mesh 的地步，那 kong 就是你最好的选择。
资源池划分
在资源池划分上，我将网关和业务的池子单独分开，同时开辟了一块竞价池，原因如下：
- 网关池划分： 网关作为业务对外流量的统一入口，提现出非常重要的地步，故而单独分配了一块资源池，同时需要与负载均衡器的配置，对机器权限的控制力度也是和普通业务池是不同的。
- 业务池划分：这个就什么好说的，用于承载你的业务，跑长期运行的服务。
- 竞价池划分： 这里需要配合 cluster autoscaler 一起使用更佳，用于跑一些离线任务，随用随起，用完即毁，方便至极。当然如何你使用的是 EKS 直接可以配合 fargate 来直接使用。
Cluster Autoscaler：
- https://docs.aws.amazon.com/zh_cn/eks/latest/userguide/cluster-autoscaler.html#ca-ng-considerations
- https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md
未来展望
目前，我们通过 kong 来实现了对外流量的管理与控制，但对内部服务之间的访问控制还未开始，也缺乏一些服务治理的手段，当然，使用 kong 也可以达到，但这样我们就会过渡依赖这个集中网关了，一旦故障，那是灾难性的，service mesh 的到来正式解决此类问题，让服务治理变的更游刃有余，后面我们会上 isito 来实现诸如灰度、蓝绿发布以及对内部服务调用限流、监控等控制能力的加强。
文档
