最近被新规划的中台，忙到焦头烂额。回到EKS话题吧。
架构和网络的规划。EKS or self-manager K8S，最终投给了EKS，毕竟在我也尝过在AWS 多种部署K8S的方案。
选择EKS最关键的原因是：EKS 的自带CNI，所有的pods都可以无缝和vpc的EC2，无缝调用。
在构建EKS的 VPC，我们采用全public子网的模式，放弃了传统私有子网。原因是这个vpc，
EKS的node虽有公网IP，并没有附加弹性网卡，意味着ASG在伸缩后，node可能被重建了。那么在k8s 定义 service资源时，type选择为node type，并不可靠，毕竟node的IP本身就可能在重启后，变更掉。
其中也有一个小插曲，同事提出来用EKS集群方案，实现网络代理服务应用集群，提供代理IP给爬虫服务。开会中我也脑子热，居然认可了。冷静后，才发现不对劲啊。EKS 的CNI 让每一个pods都能分配到vpc的一个ip地址，但是pods的互联网访问，还是要通过附加在主机的network interface上互联网网关，也就是说通过这个network interface的ip出去呀。简单讲，就是pods 实际还是通过所在ec2的公网IP出去。完全就不是他说的，每个pods 都能搞到一个公网IP，大误啊！
5. EKS文档中，自带storageclass的例子，通过sc生产